GtkSizeGroup breakage (was Re: questions re: aux info, size request)
On Sun, 2010-09-12 at 01:01 -0400, Havoc Pennington wrote: > Hi, > > On Sun, Sep 12, 2010 at 12:45 AM, Tristan Van Berkom > wrote: > > While on this topic, there's this XXX comment I left dangling > > in gtksizegroup.c: > > http://git.gnome.org/browse/gtk+/tree/gtk/gtksizegroup.c#n677 > > > > I was thinking maybe that for all the widgets in a group to be > > effectively the same size, maybe we should be basing the minimum > > base requests from the natural requests of all widgets in a group. > > I would expect that GtkSizeGroup caused all widgets in the group to > request a min size of the largest min size in the group, and a natural > size of the largest natural size in the group. Then it Just Works, > right? Is there a reason that only one of min or natural can be picked > for size group? Ok this morning I wrote up a straight-forward patch that modifies the size-group code to take both minimum and natural requests into account... In doing so I opened a can of worms... to phrase the problem accurately; size-groups can only function normally under the assumption that every contextual height-for-width request made on the widget was a request which will be used directly to determine it's allocation. So for instance things will break when something like this happens: a.) Container requests minimum and natural width b.) Container requests height for the minimum width c.) Container requests height for an arbitrary width which fits inside the container's allocation d.) Container then allocates a height based on the last request (contextual to the allocated width). In this scenario, GtkSizeGroup height values are needlessly grown after step b... which may or may not have been a pertinent request; however the api does not mandate that the container not check the height for the minimum width for whatever reason the container desires. (I'm not even convinced that step b here should be discouraged, it may very well be a useful step for some containers). Some thoughts: - maybe only the non-contextual requests should be used with size-groups ? No; because that leaves out one dimension in every case. - maybe the GtkSizeRequestIface should distinguish between a widget's request and allocation phase ? Again most probably No; the idea here would be to only use the contextual request for size groups when requested _for_allocation() (or by checking some widget flag that we are in the allocation phase)... this would have a downside of queueing a resize on all the group widgets from the allocation phase: intensely iterative and would slow things down... if not lock-up GTK+ completely. - maybe we should say that you should never request a contextual height for a width you are not sure will be actually allocated ? For reasons I outlined in the above text, again probably not a good idea. Any ideas ? Cheers, -Tristan PS: I am inclined to commit my previous fix to size-groups to take natural size into account as well as minimum size; if only in the interest of having saner/better code in place before fixing the above scenario... ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ policy (was RE:rendering-cleanup-next)
On Sep 14, 2010, at 3:48 AM, Paul Davis wrote: > On Mon, Sep 13, 2010 at 6:27 PM, Matthias Clasen > wrote: >> 2010/9/13 Thomas Wood : >>> >>> Clutter's (very detailed) coding style document may be useful here, >>> since it has a very similar coding style to GTK+: >>> >>> http://git.clutter-project.org/clutter/tree/doc/CODING_STYLE >>> >> >> Yes, I think we could basically adopt this word-by-word. > > i know that coding styles are, as it says in the clutter guide, > "arbitrary", but i would just like to mention one little detail that i > find problematic when working on shared projects (and much less so on > non-shared projects). this rule: > > -- > Curly braces should not be used for single statement blocks: > > if (condition) >single_statement (); > else >another_single_statement (arg1); > --- To add to this, it does not specify how to deal with braces in nested if-statements. When I start to nest if-statements (also with a single-statement body) I typically start adding braces, because it is a bit clearer and avoids the dangling else problem. regards, -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ policy (was RE:rendering-cleanup-next)
On Mon, Sep 13, 2010 at 6:27 PM, Matthias Clasen wrote: > 2010/9/13 Thomas Wood : >> >> Clutter's (very detailed) coding style document may be useful here, >> since it has a very similar coding style to GTK+: >> >> http://git.clutter-project.org/clutter/tree/doc/CODING_STYLE >> > > Yes, I think we could basically adopt this word-by-word. i know that coding styles are, as it says in the clutter guide, "arbitrary", but i would just like to mention one little detail that i find problematic when working on shared projects (and much less so on non-shared projects). this rule: -- Curly braces should not be used for single statement blocks: if (condition) single_statement (); else another_single_statement (arg1); --- what's wrong with this? well, completely ignoring the risk of someone redefining single_statement() into a multiline statement (macros are noted as "to be avoided", not illegal), its something much more down to earth: if you are attempting to debug somebody else's code (which happens quite a bit when hacking the internals of GTK), this means that if you want to add a debug trace for either (or both) branch of the conditional, you have to *add* curly braces. when you're done, you need to remember to remove them. so this style makes more work for anyone trying to understand/debug the code, and also increases the chances of patches/commits that violate the style guide. this happens to me every time i'm working on GTK internals - i have to tediously add braces and remove them. if they were already there, i would simply be adding debug trace lines, and then deleting them. anyway, i wasn't trying to start a style war - just a reflection that distributed collaborative development has some different dynamics than more personal or local projects. coding habits that make it easier for other people to debug your code (even if that means adding debug output statements) has always seemed like a good thing. i have no actual position on whether the braces-always-present or not is actually better programming in the abstract sense, only that they help out when different people may need to make independent passes through a chunk of code to debug/understand its logic/operation. --p ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ policy (was RE:rendering-cleanup-next)
2010/9/13 Thomas Wood : > > Clutter's (very detailed) coding style document may be useful here, > since it has a very similar coding style to GTK+: > > http://git.clutter-project.org/clutter/tree/doc/CODING_STYLE > Yes, I think we could basically adopt this word-by-word. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RFC: Rules for distro-friendly packages
Hi folks, I've collected several rules that upstreams should follow to make distro maintainer's life much easier. Feel free to comment on this: http://www.metux.de/index.php/de/component/content/article/57.html cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: rendering-cleanup-next
On Sep 13, 2010, at 6:54 AM, Havoc Pennington wrote: > On Mon, Sep 13, 2010 at 12:05 AM, John Ralls wrote: >>> Could also make it a gdk_x11 api. >>> But maybe a hint that is a no-op on other backends is better. >> >> I'm in favor of keeping platform-specific stuff in platform-specific files >> and directories, but that's in large part just because I'm a bit compulsive >> when it comes to code organization. >> > > Making it gdk_x11 doesn't keep the platform-specific in > platform-specific files. It would make all files touched by > d3802ca8331ab09fe752407577b12d1525b5d89e now include gdkx.h and an > #ifdef'd call to the gdk_x11 API. So textview, layout, treeview, > viewport would all now have x11-specific code. > > The API need not be X specific, though the details depend on how > Windows and Mac work and I don't know them. I got a bit lost whether we are still going to add this API or not :) But for what it's worth, as far as I can see now, this API is fine from an OS X point of view. Especially with the two "conditionals" at the end of the function description there is likely enough room to do what is best suited for a given platform or to emulate the pieces that are required. -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ policy (was RE:rendering-cleanup-next)
On Sun, 2010-09-12 at 18:50 +0200, Javier Jardón wrote: > 2010/9/12 Matthias Clasen : > > We don't have a written-down policy, beyond 'fit in locally'. But I > > have become increasingly annoyed by trailing whitespace and mixed-in > > tabs, since they do show up in my editor nowadays. So maybe we should > > agree on a policy and put it in writing for 3.0. > > As a start point, we have an informal policy here: [1] > > [1] http://live.gnome.org/GTK%2B/BestPractices#Coding_Style > Clutter's (very detailed) coding style document may be useful here, since it has a very similar coding style to GTK+: http://git.clutter-project.org/clutter/tree/doc/CODING_STYLE Regards, Thomas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: rendering-cleanup-next
On Sep 12, 2010, at 9:54 PM, Havoc Pennington wrote: > Hi, > > On Mon, Sep 13, 2010 at 12:05 AM, John Ralls wrote: >>> Could also make it a gdk_x11 api. >>> But maybe a hint that is a no-op on other backends is better. >> >> I'm in favor of keeping platform-specific stuff in platform-specific files >> and directories, but that's in large part just because I'm a bit compulsive >> when it comes to code organization. >> > > Making it gdk_x11 doesn't keep the platform-specific in > platform-specific files. It would make all files touched by > d3802ca8331ab09fe752407577b12d1525b5d89e now include gdkx.h and an > #ifdef'd call to the gdk_x11 API. So textview, layout, treeview, > viewport would all now have x11-specific code. > > The API need not be X specific, though the details depend on how > Windows and Mac work and I don't know them. > > /** > * gdk_window_set_clears_background: > * @window: a #GdkWindow > * @value: #TRUE to clear window to its background when damage occurs > * Sure, so the declaration goes in gdkwindow.h and the implementation in x11/gtkwindow-x11.c with no-op stubs in quartz/gdkwindow-quartz.c and win32/gdkwindow-win32.c. I don't think the problem you're attacking actually occurs on quartz, so a no-op stub there should be fine. I don't know about Win32. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: rendering-cleanup-next
Hi, On Mon, Sep 13, 2010 at 4:26 AM, Alexander Larsson wrote: > I'm personally a tiny bit uneasy about dropping bg None, as in some > cases its really required to do flicker-free stuff in X. However, with a > modern Gtk+ these situations are quite rare, and I don't think any of > these changes really cause any flicker, since: > > 1) In practice almost all non-toplevel GdkWindows in a typical Gtk+ app > are client-side (i.e. have no corresponding native window). This means > that mapping them does not make X clear the area to the background, and > there is no flicker. > > 2) Even for windows with native windows there is often no flicker, as > the X11 gdk backend aggressively set+unsets background None around > things like moves, resizes, maps and reparents in order to not render > anything to the screen until we do the expose. Fair enough. It looked to me like the None still in GTK were all on scrollable areas (text and tree view, GtkLayout). So if those are just client-side anyway, None background isn't doing anything. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: questions re: aux info, size request
Hi,
On Mon, Sep 13, 2010 at 7:06 AM, Tristan Van Berkom
wrote:
> Heh, do you mean GtkWindow widgets or GtkWidgets that have their own
> GdkWindow ?
Widgets that have their own GdkWindow
i.e. I was proposing that when adjusting a size request,
if (gtk_widget_get_window(widget))
{
if (*minimum_size < 1) *minimum_size = 1
}
> I think essentially to allow 0x0 allocations we either need to
> allow GdkWindows to be created at a 0x0 size (currently they
> also force >= 1x1 internally)... or we need to add some special casing
> code to GtkWidget's to handle their GdkWindows with care at
> allocation time (naturally they all just call gdk_window_move_resize()
> unconditionally).
If you force the 1x1 request then in theory you would not ever get a
0x0 allocation, right? But to be sure could also force 1x1 allocation
(which is already done), but change that requirement to only apply if
gtk_widget_get_window() != NULL
I was proposing this approach - window widgets must be 1x1 - because
the alternative is to unmap when receiving a 0x0 allocation.
(HippoCanvas does the unmap thing, in fact 0x0 allocation and unmapped
are the same state in HippoCanvas, iirc.) I think the unmap-on-0x0
will be complicated to apply to GTK and maybe not that useful, since
the goal is to get rid of window widgets, keeping only the ones that
truly conceptually have a GdkWindow - toplevels and embeds - and
requiring toplevels to be 1x1 is actually logical.
Anyway the basic idea is to avoid changing anything too much, just
move the arbitrary 1x1 requirement only to those widgets that really
need it (those that have a GdkWindow)
Havoc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: padding cleanup
On Sun, Sep 12, 2010 at 9:50 PM, Havoc Pennington wrote: > Hi, > > I merged the main patch to master. I wrote docs (see attached) but did > not push them yet because I can't figure out how to actually document > a non-signal virtual function in a non-interface. > What I have here puts the text of the docs in the HTML but it doesn't > look nice. Does gtk-doc just not do this? I think the best gtk-doc can currently do is what you can see in http://library.gnome.org/devel/gobject/2.25/gobject-Type-Information.html#GTypeValueTable ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: questions re: aux info, size request
On Sun, 2010-09-12 at 12:53 -0400, Havoc Pennington wrote: > Hi, > > On Sun, Sep 12, 2010 at 1:33 AM, Tristan Van Berkom > wrote: > > Ok I see, so we end up with: > > - set_size_request() Can be used to increase the minimum request > > I was thinking this should stay backward compatible and allow lowering > it, fwiw. Though I can't actually come up with a use case, I'm just > being paranoid. > > btw - have you looked into allowing 0x0 allocations at all? (at 0x0, > draw() would not be called, I think, so draw() implementations would > not have to handle 0x0; also, 0x0 would not really work on window > widgets, but this could be addressed by forcing window widgets to have > at least a 1x1 minimum size. i.e. replace 1x1 min allocation with a > 1x1 min request for window widgets only) Heh, do you mean GtkWindow widgets or GtkWidgets that have their own GdkWindow ? I think essentially to allow 0x0 allocations we either need to allow GdkWindows to be created at a 0x0 size (currently they also force >= 1x1 internally)... or we need to add some special casing code to GtkWidget's to handle their GdkWindows with care at allocation time (naturally they all just call gdk_window_move_resize() unconditionally). Probably the former is better than the latter... even if the window has to do some hackery and hide itself when there is a dimension of 0 size. Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: rendering-cleanup-next
On Sat, 2010-09-11 at 18:57 +0200, Benjamin Otte wrote: > On Sat, Sep 11, 2010 at 6:29 PM, Havoc Pennington wrote: > > - in many languages GtkSizeRequest::get_width() is already just > > callable as widget.get_width() > > - plain get_width() more naturally gets request, anyhow > > > Ugh, I'd always assume that widget.get_width() would give me the width > of the widget, not the width the widget thought would be ideal but had > nothing to do with reality. Also, a width getter would never return 2 > values for me. > Should we maybe rename it to gtk_size_request_get_natural/minimum_width()? > Tristan? Thanks for poking me on irc as I really have not been following this thread (and it did not jump out at me with the explicit CC, I'll see if I can configure something for that in my mail reader... or try to at least glance at all or most of the gtk-devel traffic that rolls in) As we briefly discussed on irc; I don't really care so much about the name of the API so long as it make's sense. I suppose that if we desire to change the name; the most natural name will be to match clutter's get_preferred_width(). While on the topic of gtk_size_request_get[_preferred]_width(), I think we really should be keeping both minimum and natural values as 2 return values of the same api... because: - For any container code that needs to make a request, whether the natural or minimum size gets ignored or not; its better to at least force a some awareness about the height-for-width apis. In other words it should be impossible for a container widget author to use widget.get_minimum_width() and completely ignore the fact that there is a natural width (at least when a natural width is ignored, it should be obviously intentional or be code that needs fixing). - While the exported api could be different than the internal one, The signature should IMO be the same signature as the method invoked on the GtkSizeRequestIface - In most implementations of the ->get_width() request api there are some padding and border/style values to calculate which apply to both the minimum and natural size... so it makes sense to calculate both minimum/natural in a single pass (it would be a shame to make them be calculated twice in order to separate those calls). For allocation apis, I would still prefer using an api that is clear about the allocation (widget.get_allocation() or widget.get_allocated_width())... as that is somehow less ambiguous and forces the caller to understand at least a little bit about allocations. Cheers, -Tristan > > > > Something I just noticed, it looks like widgets are doing > > get_allocation and looking at allocation.x,y still because gtk_paint_* > > seems to assume that the cairo_t is not translated? > > > gtk_paint_*() does - at least in my branch - draw relative to the > passed in cairo_t. As almost all the paint functions take > x,y,width,height anyway it doesn't really matter where the origin of > the cairo_t is. You'll notice in all the "Port to draw vfunc" patches > that I removed allocation.x/y from the x/y parameters. > The original paint functions that took a GdkWindow were > window-relative so had to take into account allocation.x/y. > > Benjamin > ___ > 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
Re: rendering-cleanup-next
On Sat, 2010-09-11 at 11:16 -0400, Havoc Pennington wrote: > * > > I'm skeptical of removing ability to set window background to None. > This feature can be important to avoid visual artifacts on X11. The > API should maybe change to not involve a "NULL" pixmap; conceptually, > what this means is "window system should not auto-clear or auto-paint > the background on exposes" - I don't know if any other platform has > the concept. A new API could be > gdk_window_set_paint_background(gboolean) rather than set_pixmap(NULL) > > I think d3802ca "Remove calls that try to set GDK_NO_BG on their > windows" probably results in some things being more ugly. > (flashing/flicker) > > This almost goes away as an issue if dropping all subwindows, but I > think setting None on toplevels will still be important sometimes. I > guess in future-composited-desktop-world this also fades in importance > but I'm not sure on when/whether/details. I'm personally a tiny bit uneasy about dropping bg None, as in some cases its really required to do flicker-free stuff in X. However, with a modern Gtk+ these situations are quite rare, and I don't think any of these changes really cause any flicker, since: 1) In practice almost all non-toplevel GdkWindows in a typical Gtk+ app are client-side (i.e. have no corresponding native window). This means that mapping them does not make X clear the area to the background, and there is no flicker. 2) Even for windows with native windows there is often no flicker, as the X11 gdk backend aggressively set+unsets background None around things like moves, resizes, maps and reparents in order to not render anything to the screen until we do the expose. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a leather-clad ninja jungle king looking for 'the Big One.' She's a radical thirtysomething nun living homeless in New York's sewers. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
