Re: GTK+ 2.21.6

[Jose Aliste]

On Wed, Aug 18, 2010 at 4:15 PM, Paul Davis  wrote:
> On Wed, Aug 18, 2010 at 2:01 PM, Jose Aliste  wrote:
>
>> After looking at the git log, you interpret correctly, but  I fail to
>> see why do you perceive this as being bad. So, some GDK API is marked
>> as deprecated, it seems fair to me that Gtk+ maintainers ensure the
>> deprecated API is not used in gtk+ itself anymore. It is also a good
>> test that you are not deprecating something that can't be deprecated
>> (i.e. there is no equivalent functionality in cairo).
>
> i think you missed my point. this is not about the deprecations. its
> about the fact that 2.22 will contain a complete reimplemenation of
> the GDK draw routines. this is happening in a branch this is
> supposedly "stable". i don't understand how this can reconciled. no
> API is changed in order for this to happen, but the implementations
> are all new. existing programs will compile and run, but if linked
> against 2.22 they will be testing an implementation that was (i
> thought) aimed at the 3.0 release line. surely this stuff that should
> be in 2.90 ?
>
aha, now I understand and I believe  you are missing something here.
AFAIK, the Gdk draw functions are NOT being reimplemented. The only
thing that has  happened (if I understand correctly after reading some
of the commits in git) is that the Gtk+ methods
that before used the deprecated GDK API  now use the cairo API instead.

Greetings

José
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: cairo drawing commands to gdk_invalidate_region

[Dov Grobgeld]

The problem of deciding what areas to expose are imho opinion too hard for
the motion handler to deal with. E.g. if the rubberband is e.g. of an
ellipse outline then you need quite a bit of mathematics to figure out what
areas to expose. You can of course expose the entire bounding box, but that
is very expensive for a large areas if it needs to be done several times a
second. The idea of painting a low res mask takes care of it.

Regarding the draw() routine, as you can see in the actual code, I do pass a
boolean flag that indicates whether it is the low res mask that should be
drawn or the actual drawing. This can be used to avoid drawing gradients and
other expensive drawing operations during mask creation.

In any case, thanks for your input.

Dov

On Wed, Aug 18, 2010 at 14:47, Paul Davis wrote:

> On Tue, Aug 17, 2010 at 4:22 PM, Dov Grobgeld 
> wrote:
>
> > The solution won't work if the default expose-event handler returns TRUE.
> > I would still like to resolve the issues that Paul has with my
> description
> > of the code. Paul, why don't you like the fact that I call draw() twice?
>
> that's overstating it a little bit. what i was taking issue with is
> that *unless* draw() has some way to be able to tell that it is being
> called from an expose event handler (and that would presumably have to
> be some global variable, since nothing is passed to it as an
> argument), it is by definition doing the wrong thing *if* it is
> responsible for all the rendering that occurs in the expose handler.
> why? because that would imply that it actually renders in both the
> pre-expose call and the expose-event call, but you should only be
> rendering (to the window at list) in the expose event call.
>
> you asked:  How is update() supposed to know what region to invalidate?
>
> in your original description, you showed the flow as:
>
># motion event calls update()
> # update() calls draw() in order to get regions to expose.
> # update() calls gdk_invalidate_region() based on output from draw
> # exposure-event callback calls draw() to carry out the drawing
> for each region
>
> so you have logic that knows what regions are affected by the motion
> event (the above description makes it sound as if that logic is inside
> draw()). update should have that logic so that it can call
> gdk_invalidate_region(), and then the expose-event call to draw()
> should use the event region list to redraw.
>
> if your code works, that's fine. i'm just trying to describe to you
> what i *think* is the right way to do this so that its portable to all
> backends of GTK and is following the overall drawing model embedded in
> GTK.
>
> --p
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK+ 2.21.6

[Paul Davis]

On Wed, Aug 18, 2010 at 2:01 PM, Jose Aliste  wrote:

> After looking at the git log, you interpret correctly, but  I fail to
> see why do you perceive this as being bad. So, some GDK API is marked
> as deprecated, it seems fair to me that Gtk+ maintainers ensure the
> deprecated API is not used in gtk+ itself anymore. It is also a good
> test that you are not deprecating something that can't be deprecated
> (i.e. there is no equivalent functionality in cairo).

i think you missed my point. this is not about the deprecations. its
about the fact that 2.22 will contain a complete reimplemenation of
the GDK draw routines. this is happening in a branch this is
supposedly "stable". i don't understand how this can reconciled. no
API is changed in order for this to happen, but the implementations
are all new. existing programs will compile and run, but if linked
against 2.22 they will be testing an implementation that was (i
thought) aimed at the 3.0 release line. surely this stuff that should
be in 2.90 ?
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [Gobject Introspection] GIRepository.gir seems incorrect

[Steve Frécinaux]

On 08/18/2010 07:32 PM, Mildred Ki'Lya wrote:

Hi,

I'm trying to use the GIRepository library in order to access GI
information and create a compile time binding for the Lisaac language.

I don't like C very much, and I'm going to use Vala. But the vala
compiler complains that it can't find the type "filename".


GObject introspection use a "filename" string type to mark strings that 
represent file names, because those are not utf8 strings, rather 
bytestrings with exceptions.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK+ 2.21.6

[Jose Aliste]

Hi,

On Wed, Aug 18, 2010 at 1:12 PM, Paul Davis  wrote:
> On Wed, Aug 18, 2010 at 12:57 PM, Behdad Esfahbod
>  wrote:
>> On 08/18/10 12:50, Paul Davis wrote:
>>> On Wed, Aug 18, 2010 at 12:44 PM, Matthias Clasen
>>>  wrote:
>>>
 I don't see how that follows. All that is happening in 2.22 is that
 some things are getting deprecated. You can still use them. We are not
 going to take them away from you during 2.x
>>>
>>> i wasn't really worried about the deprecations. replacing the
>>> implementation of all internal drawing methods is OK to do in a stable
>>> branch?
>>
>> From what I understand reading the thread, that's your wrong impression.  The
>> rendering-cleanup branch is NOT being merged into 2.22.  Just that some new
>> functions where added, and some old ones marked deprecated.  You are 
>> imagining
>> things that are simply not true.
>
> the announcement declared:
>
> Overview of Changes from GTK+ 2.21.5 to 2.21.6
> ==
>
> * Most drawing done by GTK+ itself has been ported from
>  GDK drawing APIs to cairo
>
> did I interpret that incorrectly?

After looking at the git log, you interpret correctly, but  I fail to
see why do you perceive this as being bad. So, some GDK API is marked
as deprecated, it seems fair to me that Gtk+ maintainers ensure the
deprecated API is not used in gtk+ itself anymore. It is also a good
test that you are not deprecating something that can't be deprecated
(i.e. there is no equivalent functionality in cairo).

Please observe that many of the deprecated API (maybe all?) were
already using cairo internally, so, as it has been  already pointed
out,
you probably don't need to worry that much. Of course if gtk-2.22 DOES
eventually broke something for you, then you should raise your voice
high and complain ;)

Greets

José


> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Gobject Introspection] GIRepository.gir seems incorrect

[Mildred Ki'Lya]

Hi,

I'm trying to use the GIRepository library in order to access GI
information and create a compile time binding for the Lisaac language.

I don't like C very much, and I'm going to use Vala. But the vala
compiler complains that it can't find the type "filename".

When I look at the .gir file, I find:


  

  

  

  

And the  seems suspect.

The vala error is:

valac -v --pkg=GIRepository-2.0 -o gilisaac main.vala
error: The type name `filename' could not be found
Compilation failed: 1 error(s), 0 warning(s)

Do you think it's a problem in Vala or the gir file?
I'm using the gobject-introspection version 0.6.9 (the Fedora package).


Mildred

-- 
Mildred Ki'Lya
╭─ ｍｉｌｄｒｅｄ５９３＠ｏｎｌｉｎｅ．ｆｒ ──
│ Jabber, GoogleTalk: 
│ Website:    GPG ID: 9A7D 2E2B
│ Fingerprint: 197C A7E6 645B 4299 6D37 684B 6F9D A8D6 9A7D 2E2B


0x9A7D2E2B.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK+ 2.21.6

[Paul Davis]

On Wed, Aug 18, 2010 at 12:57 PM, Behdad Esfahbod
 wrote:
> On 08/18/10 12:50, Paul Davis wrote:
>> On Wed, Aug 18, 2010 at 12:44 PM, Matthias Clasen
>>  wrote:
>>
>>> I don't see how that follows. All that is happening in 2.22 is that
>>> some things are getting deprecated. You can still use them. We are not
>>> going to take them away from you during 2.x
>>
>> i wasn't really worried about the deprecations. replacing the
>> implementation of all internal drawing methods is OK to do in a stable
>> branch?
>
> From what I understand reading the thread, that's your wrong impression.  The
> rendering-cleanup branch is NOT being merged into 2.22.  Just that some new
> functions where added, and some old ones marked deprecated.  You are imagining
> things that are simply not true.

the announcement declared:

Overview of Changes from GTK+ 2.21.5 to 2.21.6
==

* Most drawing done by GTK+ itself has been ported from
 GDK drawing APIs to cairo

did I interpret that incorrectly?
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK+ 2.21.6

[Behdad Esfahbod]

On 08/18/10 12:50, Paul Davis wrote:
> On Wed, Aug 18, 2010 at 12:44 PM, Matthias Clasen
>  wrote:
> 
>> I don't see how that follows. All that is happening in 2.22 is that
>> some things are getting deprecated. You can still use them. We are not
>> going to take them away from you during 2.x
> 
> i wasn't really worried about the deprecations. replacing the
> implementation of all internal drawing methods is OK to do in a stable
> branch?

>From what I understand reading the thread, that's your wrong impression.  The
rendering-cleanup branch is NOT being merged into 2.22.  Just that some new
functions where added, and some old ones marked deprecated.  You are imagining
things that are simply not true.

behdad
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK+ 2.21.6

[Paul Davis]

On Wed, Aug 18, 2010 at 12:44 PM, Matthias Clasen
 wrote:

> I don't see how that follows. All that is happening in 2.22 is that
> some things are getting deprecated. You can still use them. We are not
> going to take them away from you during 2.x

i wasn't really worried about the deprecations. replacing the
implementation of all internal drawing methods is OK to do in a stable
branch?
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gtk_widget_draw()

[Paul Davis]

On Wed, Aug 18, 2010 at 12:27 PM, Havoc Pennington  wrote:
> Hi,
>
> On Wed, Aug 18, 2010 at 7:56 AM, Paul Davis  
> wrote:
>> On Tue, Aug 17, 2010 at 5:04 PM, Federico Mena Quintero
>>  wrote:
>>
>>  [ ... ]
>>
>> its quite amusing to me how what is being described is slowly
>> converging on something extremely close to a canvas model in many of
>> its most fundamental aspects. am i the only one seeing this? does it
>> matter?
>
> See http://log.ometer.com/2008-03.html#7 perhaps.

Yes, absolutely. I've seen this before and I think it probably helped
get me thinking along these lines. I think it doesn't quite go far
enough, but something that combines these ideas with what has already
happened regarding CSW and drawing methods moves things a good bit of
the way. I also find it interesting that in some sense, Wayland is
just another scene graph, but at a different level (able to eat X
Window in a single bite-kind-of-level).
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK+ 2.21.6

[Matthias Clasen]

On Wed, Aug 18, 2010 at 12:27 PM, Paul Davis  wrote:
> On Wed, Aug 18, 2010 at 12:21 PM, Bastien Nocera  wrote:
>
>> New functionality is available in both when it makes sense to do so, and
>> deprecated functionality is marked as much.
>>
>> You shouldn't see any difference in usage if you don't use the new
>> functionality.
>
> We distribute a version of GTK as part of our product for OS X. We had
> selected 2.22 as the branch to follow for this, on an apparently
> faulty understanding that 2.22 was a relatively stable branch at this
> point. Replacing every gdk_draw_* method doesn't qualify for
> "relatively stable" in my opinion. We now have to drop our tracking of
> 2.22 entirely and simply sit at the current (arbitrary) revision that
> we currently use for the build. Frustrating.

I don't see how that follows. All that is happening in 2.22 is that
some things are getting deprecated. You can still use them. We are not
going to take them away from you during 2.x
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gtk_widget_draw()

[Havoc Pennington]

Hi,

On Wed, Aug 18, 2010 at 7:56 AM, Paul Davis  wrote:
> On Tue, Aug 17, 2010 at 5:04 PM, Federico Mena Quintero
>  wrote:
>
>  [ ... ]
>
> its quite amusing to me how what is being described is slowly
> converging on something extremely close to a canvas model in many of
> its most fundamental aspects. am i the only one seeing this? does it
> matter?

See http://log.ometer.com/2008-03.html#7 perhaps.

Another way to think of "canvas" (different than in the above slide
deck), is what I call "just a canvas" vs. "toolkit stuff" - toolkit
stuff is all the global singletons, the GApplication, the main loop,
the window system abstraction layer.

A really nice thing about HippoCanvas was that the canvas items didn't
really see "above" themselves to parent items, or most of all they
didn't poke at toplevel windows or a "stage" or a global backend
thingy such as a display. Instead HippoCanvas is totally recursive -
events get to leaf items by being sent to parent items that then
forward to the leaf items, to draw the whole screen you just draw the
root item, etc. This then makes it very easy to be in that
gtk_widget_draw() type of world where you can draw items to other
contexts such as to print them.

I think both GTK 2.x and Clutter have fairly suboptimal code where
there's a good bit of leakage of the global window system goo into the
actors/widgets, and part of this thread is about mopping that up.

A nice thing about having actors and widgets separate from all the
"toolkit stuff" is that it makes it a good bit simpler to mix two
different kits together.

Anyway that's one aspect of this, and the other I think is more in the
slides I linked to, which is that canvas items are generally more
flexible than widgets (have transforms, don't have to be a rectangle,
etc.)

Havoc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK+ 2.21.6

[Paul Davis]

On Wed, Aug 18, 2010 at 12:21 PM, Bastien Nocera  wrote:

> New functionality is available in both when it makes sense to do so, and
> deprecated functionality is marked as much.
>
> You shouldn't see any difference in usage if you don't use the new
> functionality.

We distribute a version of GTK as part of our product for OS X. We had
selected 2.22 as the branch to follow for this, on an apparently
faulty understanding that 2.22 was a relatively stable branch at this
point. Replacing every gdk_draw_* method doesn't qualify for
"relatively stable" in my opinion. We now have to drop our tracking of
2.22 entirely and simply sit at the current (arbitrary) revision that
we currently use for the build. Frustrating. We went through this
earlier (at about 2.14), when we had to stop tracking releases because
of the breakage being caused to non-X11 backends by changes to various
parts fo the system. I guess we just do the same again. It only
affects a handful of developers but it also pretty much blocks anyone
from ever being able to "easily" build our GPL'ed app on OS X for
themselves because there will never be a release version of GTK that
corresponds to what is required.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK+ 2.21.6

[Bastien Nocera]

On Wed, 2010-08-18 at 12:14 -0400, Paul Davis wrote:
> On Wed, Aug 18, 2010 at 12:04 PM, Bastien Nocera  wrote:
> > On Wed, 2010-08-18 at 11:52 -0400, Paul Davis wrote:
> >> On Mon, Aug 16, 2010 at 8:48 PM, Matthias Clasen  
> >> wrote:
> >> > GTK+ 2.21.6 is now available for download at:
> >>
> >> is this really a correct description of 2.21:
> >>
> >> > Overview of Changes from GTK+ 2.21.5 to 2.21.6
> >> > ==
> >> >
> >> > * Most drawing done by GTK+ itself has been ported from
> >> >  GDK drawing APIs to cairo
> 
> [  ]
> 
> >> I though that this work was mostly in the 2.9/3.0 branch ?
> >
> > The old methods still need to be marked as deprecated and replacements
> > available in 2.x to ease GTK+ 3.x porting, otherwise you're left having
> > to port everything before you can test it out.
> 
> i wasn't aware that the drawing switch was planned for 2.22. this now
> makes this branch barely 2.X at all, from our perspective. it
> fundamentally makes it a completely new implementation of GDK, within
> a supposedly stable branch of GTK. this is quite problematic, i think.
> i was under the impression that 2.22 was going to be the last release
> of 2.X, not a preview of what 3.0 would contain.

New functionality is available in both when it makes sense to do so, and
deprecated functionality is marked as much.

You shouldn't see any difference in usage if you don't use the new
functionality.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gtk_widget_draw()

[Federico Mena Quintero]

On Wed, 2010-08-18 at 09:37 +0200, Alexander Larsson wrote:

[Border around windows so you can "glow" around a widget]
> There are all sorts of ways you can hack it into GtkButton or any
> specific widget, I'm sure. However, its hard to do in a more generic way
> for a theme. I was thinking the theme could just set a style property to
> have the widget enlarge its border, and then the theme just draws a bit
> outside in its normal rendering operation. No hacks, no special code,
> works for all widgets.

Hmm.  I just think it's overkill to complicate the GdkWindow abstraction
just for themes' sake.

Correct me if I'm wrong, but I think you imagine the
glow-around-a-button to actually have allocated space around the button

   
   * +--+ * +--+
   * |button| * |button|
   * +--+ * +--+
   

while I'm imagining that the glow actually overlaps anything around the
widget

   **
   *  +--+ +*-+
   *  |button| |*utton|
   *  +--+ +*-+
   **

The latter is doable if the theme creates a temporary window as a child
of the toplevel, on top of all the other subwindows.

[Do we just lack the "don't clip" flag on windows]
> To fully take advantage of it we would also like to remove no-window
> widgets in Gtk and make getting a "standard" window easy via some
> default realize handler setup.

I guess InputOnly windows are trivial when we get the transparent
windows we've been talking about - you just never draw to them.  Old
apps could still use them to get events.

Getting rid of no-window widgets would be trivial in GTK+, but it would
break a lot of code that already uses that trick and does all the
coordinate-munging on its own... maybe we should make "no-window" mean
"you won't know it, but you really get a cairo_t with a transformation
relative to your parent widget"?  That way you still have to make the
changes to take a cairo_t instead of a GdkWindow (for the draw()
method), but you don't have to change your delicate code that deals with
coordinates.

  Federico

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK+ 2.21.6

[Paul Davis]

On Wed, Aug 18, 2010 at 12:04 PM, Bastien Nocera  wrote:
> On Wed, 2010-08-18 at 11:52 -0400, Paul Davis wrote:
>> On Mon, Aug 16, 2010 at 8:48 PM, Matthias Clasen  wrote:
>> > GTK+ 2.21.6 is now available for download at:
>>
>> is this really a correct description of 2.21:
>>
>> > Overview of Changes from GTK+ 2.21.5 to 2.21.6
>> > ==
>> >
>> > * Most drawing done by GTK+ itself has been ported from
>> >  GDK drawing APIs to cairo

[  ]

>> I though that this work was mostly in the 2.9/3.0 branch ?
>
> The old methods still need to be marked as deprecated and replacements
> available in 2.x to ease GTK+ 3.x porting, otherwise you're left having
> to port everything before you can test it out.

i wasn't aware that the drawing switch was planned for 2.22. this now
makes this branch barely 2.X at all, from our perspective. it
fundamentally makes it a completely new implementation of GDK, within
a supposedly stable branch of GTK. this is quite problematic, i think.
i was under the impression that 2.22 was going to be the last release
of 2.X, not a preview of what 3.0 would contain.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gtk_widget_draw()

[Paul Davis]

On Wed, Aug 18, 2010 at 12:06 PM, Paul Davis  wrote:

 sometimes i hate gmail keybindings ... so, to finish what i was saying ...

> in my mind,  a canvas does two things:
>
> 1) composites together the result of a variety of different objects
> drawing themselves/ it does

this paying attention to the area of a window that needs to be redrawn
according to external information (e.g. "expose" events) and the
internal state of the canvas (e.g. invalidated state in something that
is displayed within the window). the primary information required to
do this is the extent of each object. most canvases would also take
z-order stacking into account when ordering the redrawing, but this
isn't actual critical to this basic model of what is happening.

> 2) event distribution

i.e. finding the correct object to deliver an event to in the first
instance, and then propagating that to other objects until the event
is handled according to some kind of logical rule or rules.

it seems to me that GTK (like some other toolkits) is increasingly
converging on this model, without any specific awareness that this is
likely where it all ends up.

--p
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gtk_widget_draw()

[Paul Davis]

On Wed, Aug 18, 2010 at 11:49 AM, Federico Mena Quintero
 wrote:
> On Wed, 2010-08-18 at 07:56 -0400, Paul Davis wrote:
>
>> its quite amusing to me how what is being described is slowly
>> converging on something extremely close to a canvas model in many of
>> its most fundamental aspects. am i the only one seeing this? does it
>> matter?
>
> In my mind a canvas does two things:
>
> 1. Retained drawing.  You draw something and you get a handle back to it
> so that you can modify it (move it, recolor it, etc.).  GDK doesn't do
> retained drawing; it does direct drawing where you draw something but
> you have no way to modify it afterwards.
>
> 2. Hit detection.  You get events relative to the objects that you drew.
> This is a lot more sophisticated than "something happened inside this
> rectangular window" :)

in my mind,  a canvas does two things:

1) composites together the result of a variety of different objects
drawing themselves, most likely with z-axis ordering. it does

2) event distribution
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK+ 2.21.6

[Bastien Nocera]

On Wed, 2010-08-18 at 11:52 -0400, Paul Davis wrote:
> On Mon, Aug 16, 2010 at 8:48 PM, Matthias Clasen  wrote:
> > GTK+ 2.21.6 is now available for download at:
> 
> is this really a correct description of 2.21:
> 
> > Overview of Changes from GTK+ 2.21.5 to 2.21.6
> > ==
> >
> > * Most drawing done by GTK+ itself has been ported from
> >  GDK drawing APIs to cairo
> 
>[  ]
> 
> > * Deprecations:
> >  - GtkNotebookPage
> >  - The GtkRecenManager::limit property
> >  - All GDK drawing functions, ie gdk_draw_*. Use cairo instead
> >  - All GdkGC functions. Use cairo instead
> >  - All of GdkImage. Use cairo instead
> >  - All of GdkRGB. Use cairo instead
> >  - gdk_{bit,pix}map_create_from_data
> 
>[ ... ]
> 
> > * New cairo-related APIs:
> >  - gdk_window_create_similar_surface
> >  - gdk_window_get_background_pattern
> 
> I though that this work was mostly in the 2.9/3.0 branch ?

The old methods still need to be marked as deprecated and replacements
available in 2.x to ease GTK+ 3.x porting, otherwise you're left having
to port everything before you can test it out.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK+ 2.21.6

[Paul Davis]

On Mon, Aug 16, 2010 at 8:48 PM, Matthias Clasen  wrote:
> GTK+ 2.21.6 is now available for download at:

is this really a correct description of 2.21:

> Overview of Changes from GTK+ 2.21.5 to 2.21.6
> ==
>
> * Most drawing done by GTK+ itself has been ported from
>  GDK drawing APIs to cairo

   [  ]

> * Deprecations:
>  - GtkNotebookPage
>  - The GtkRecenManager::limit property
>  - All GDK drawing functions, ie gdk_draw_*. Use cairo instead
>  - All GdkGC functions. Use cairo instead
>  - All of GdkImage. Use cairo instead
>  - All of GdkRGB. Use cairo instead
>  - gdk_{bit,pix}map_create_from_data

   [ ... ]

> * New cairo-related APIs:
>  - gdk_window_create_similar_surface
>  - gdk_window_get_background_pattern

I though that this work was mostly in the 2.9/3.0 branch ?

--p
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gtk_widget_draw()

[Federico Mena Quintero]

On Wed, 2010-08-18 at 07:56 -0400, Paul Davis wrote:

> its quite amusing to me how what is being described is slowly
> converging on something extremely close to a canvas model in many of
> its most fundamental aspects. am i the only one seeing this? does it
> matter?

In my mind a canvas does two things:

1. Retained drawing.  You draw something and you get a handle back to it
so that you can modify it (move it, recolor it, etc.).  GDK doesn't do
retained drawing; it does direct drawing where you draw something but
you have no way to modify it afterwards.

2. Hit detection.  You get events relative to the objects that you drew.
This is a lot more sophisticated than "something happened inside this
rectangular window" :)

  Federico

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

RE: GLib 2.25.14

[Matthias Clasen]

On Wed, 2010-08-18 at 10:36 +0800, Zhang, Qiang Z wrote:
> Thanks for your quick reply.
> 
> As glib is the low level library, so I think it would be released ahead of 
> time. Right?
> Can glib 2.26 be released end of August? Then we feel better about including 
> it in MeeGo 1.1, and we have enough time to test.

Not much, this time around. There is still changes expected to land in
the new GApplication apis, and there is a bunch of outstanding
network-related functionality that people want to include. GDBus and
GSettings should be pretty much done as of 2.25.14, though.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gtk_widget_draw()

[Alexander Larsson]

On Wed, 2010-08-18 at 07:58 -0400, Matthias Clasen wrote:
> On Wed, Aug 18, 2010 at 3:37 AM, Alexander Larsson  wrote:
> 
> >
> > There are all sorts of ways you can hack it into GtkButton or any
> > specific widget, I'm sure. However, its hard to do in a more generic way
> > for a theme. I was thinking the theme could just set a style property to
> > have the widget enlarge its border, and then the theme just draws a bit
> > outside in its normal rendering operation. No hacks, no special code,
> > works for all widgets.
> a solution.
> 
> We are just about to remove that style property, called
> GtkWidget::draw-border, since it has some overhead, and nobody ever
> used it.
> 
> See bug http://bugzilla.gnome.org/show_bug.cgi?id=426924

Seems to not be very interesting then.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander LarssonRed Hat, Inc 
   al...@redhat.comalexander.lars...@gmail.com 
He's a Nobel prize-winning native American matador on a mission from God. 
She's a supernatural thirtysomething angel from beyond the grave. They fight 
crime! 

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK+ 2.90.6

[Matthias Clasen]

>> * Allow windows to be dragged by clicking on empty
>>   areas in menubars and toolbars
>
> Can this be disabled, please?
>

Yes, it can (per theme)
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gtk_widget_draw()

[Matthias Clasen]

On Wed, Aug 18, 2010 at 3:37 AM, Alexander Larsson  wrote:

>
> There are all sorts of ways you can hack it into GtkButton or any
> specific widget, I'm sure. However, its hard to do in a more generic way
> for a theme. I was thinking the theme could just set a style property to
> have the widget enlarge its border, and then the theme just draws a bit
> outside in its normal rendering operation. No hacks, no special code,
> works for all widgets.
a solution.

We are just about to remove that style property, called
GtkWidget::draw-border, since it has some overhead, and nobody ever
used it.

See bug http://bugzilla.gnome.org/show_bug.cgi?id=426924
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gtk_widget_draw()

[Paul Davis]

On Tue, Aug 17, 2010 at 5:04 PM, Federico Mena Quintero
 wrote:

 [ ... ]

its quite amusing to me how what is being described is slowly
converging on something extremely close to a canvas model in many of
its most fundamental aspects. am i the only one seeing this? does it
matter?
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: cairo drawing commands to gdk_invalidate_region

[Paul Davis]

On Tue, Aug 17, 2010 at 4:22 PM, Dov Grobgeld  wrote:

> The solution won't work if the default expose-event handler returns TRUE.
> I would still like to resolve the issues that Paul has with my description
> of the code. Paul, why don't you like the fact that I call draw() twice?

that's overstating it a little bit. what i was taking issue with is
that *unless* draw() has some way to be able to tell that it is being
called from an expose event handler (and that would presumably have to
be some global variable, since nothing is passed to it as an
argument), it is by definition doing the wrong thing *if* it is
responsible for all the rendering that occurs in the expose handler.
why? because that would imply that it actually renders in both the
pre-expose call and the expose-event call, but you should only be
rendering (to the window at list) in the expose event call.

you asked:  How is update() supposed to know what region to invalidate?

in your original description, you showed the flow as:

# motion event calls update()
# update() calls draw() in order to get regions to expose.
# update() calls gdk_invalidate_region() based on output from draw
# exposure-event callback calls draw() to carry out the drawing
for each region

so you have logic that knows what regions are affected by the motion
event (the above description makes it sound as if that logic is inside
draw()). update should have that logic so that it can call
gdk_invalidate_region(), and then the expose-event call to draw()
should use the event region list to redraw.

if your code works, that's fine. i'm just trying to describe to you
what i *think* is the right way to do this so that its portable to all
backends of GTK and is following the overall drawing model embedded in
GTK.

--p
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK+ 2.90.6

[Petr Tomasek]

> 
> Overview of Changes from GTK+ 2.90.5 to 2.90.6
> ==
> 
...>
> 
> * Allow windows to be dragged by clicking on empty
>   areas in menubars and toolbars

Can this be disabled, please?

P.T.

-- 
Petr Tomasek 
Jabber: but...@jabbim.cz


EA 355:001  DU DU DU DU
EA 355:002  TU TU TU TU
EA 355:003  NU NU NU NU NU NU NU
EA 355:004  NA NA NA NA NA



___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gtk_widget_draw()

[Alexander Larsson]

On Tue, 2010-08-17 at 16:04 -0500, Federico Mena Quintero wrote:
> On Tue, 2010-08-17 at 21:10 +0200, Alexander Larsson wrote:

> > Additionally I was thinking one could specify a "border" on the window
> > such that for clipping purposes and calculation of what has to be
> > repainted we grow the window by the border width, while for events and
> > the rest we use the normal size. This makes it easy to implement themes
> > that have a more organic look, for instance having a "glow" on an active
> > button that extends outside the button without affecting events, etc.
> 
> Do you need that?  Can't you create a separate window overlaid on your
> button, and paint the glow on *that* one?  (The window would extend past
> the "normal" window's edge; it would probably need the toplevel to be
> its parent so the glow can go over everything, etc. - but it sounds
> doable like that...)

There are all sorts of ways you can hack it into GtkButton or any
specific widget, I'm sure. However, its hard to do in a more generic way
for a theme. I was thinking the theme could just set a style property to
have the widget enlarge its border, and then the theme just draws a bit
outside in its normal rendering operation. No hacks, no special code,
works for all widgets.

> > > Who uses reparenting, anyway?
> > 
> > Dnd of toolbars items, detachable docks, putting plugs in sockets, etc. 
> 
> I don't think reparenting is needed for toolbar items and detachable
> docks - unless X forces you to do it to get really smooth painting.
> 
> Plug/socket is special anyway, as you need to cross into the actual
> window system.

Yeah, but the way you do this is via gdk. It is the bridge to the native
windowing system. Just ignoring that is not gonna help us.

> > Event masks affect more than performance though. They are combined to
> > decide which window gets each event. For instance, if you have a window
> > somewhere with a bunch of child hierarchies, and the window has the
> > event mask for mouse motion, then it will get mouse motion even over the
> > child windows, unless the child window sets mask for mouse motion too.
> > So, just sending everything everywhere is not a solution.
> 
> Ah, OK :)  I guess this is due to X not having event callbacks and the
> "boolean means whether the callback handled the event" thing...

Such callbacks would be very costly in an client-server over-network
model, since there will be many roundtrips per event.

> So, apart from the general pending cleanup, are we just lacking the
> "don't clip" flag discussed above for transparent windows?

To fully take advantage of it we would also like to remove no-window
widgets in Gtk and make getting a "standard" window easy via some
default realize handler setup.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander LarssonRed Hat, Inc 
   al...@redhat.comalexander.lars...@gmail.com 
He's a bookish moralistic stage actor on the hunt for the last specimen of a 
great and near-mythical creature. She's a strong-willed French-Canadian 
barmaid trying to make a difference in a man's world. They fight crime! 

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Minutes of the GTK+ Team Meeting - 2010-08-17

[jp0409]

Hi,


- GAction, allows named actions + parameters (local+remote invocation)
  + only name, no visual/UI-related attributes
  + :enabled
  + (optional) state
- GActionGroup, allows grouping of actions
- GApplication, handles groups of actions
- parametrized actions will be available on D-Bus
- GtkAction is the presentation layer for GAction
- other backends are still a question mark
  + probably unable to implement parametrized actions, but UI elements
should be easy to write


Can you undo an action? Any relation to a generic undo/redo framework?

Regards,
J-P Iivonen

__
Saunalahdelta mullistava uutuus Nokia N97 ja kaiken kattava TotaaliMAX nyt 
ennakkomyynnissä uskomattoman edullisesti! Paketissa puhelut ja viestit (3000 
min/kpl/kk), huippunopea mobiililaajakaista sekä Nokia N97 yhdellä kk-maksulla 
vain 59,95 e/kk (24 kk sopimus).
Katso http://saunalahti.fi/totaalimax

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list