GTK Team Meeting tomorrow
hi all, Just a reminder that we're planning to have a GTK Team Meeting tomorrow, Tuesday September 7 at the usual time and place. See the details here: http://live.gnome.org/GTK+/Meetings Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[REMINDER] GTK+ Team Meeting, 2010-09-07
hi everyone; this is a reminder that the next GTK team meeting is scheduled for: Tuesday, September 7th, 2010 channel: #gtk-devel on irc://irc.gnome.org agenda: • G(tk)Application status • possible GTK3 cleanup tasks ‣ alternative button order cleanup ‣ text direction / start-end / left-right consistency ‣ primary handling ‣ uri hooks cleanup ‣ reconsider module loading ? ‣ undo combobox / option menu mix ? ‣ gtksettings -> gsettings ? ‣ gtksearchengine refactor ‣ GdkPoint ?! ‣ Improve testgtk and/or gtk-demo • Deprecate/remove GtkRequisition (bug: 626939) • Case insensitive search for GtkTextView (bug: 61852) • Miscellaneous as usual, changes in the agenda and/or time are going to be listed on the wiki: http://live.gnome.org/GTK%2B/Meetings ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
combo/option (was Re: [REMINDER] GTK+ Team Meeting, 2010-09-07)
Hi, On Mon, Sep 6, 2010 at 10:06 AM, Emmanuele Bassi wrote: >> ‣ undo combobox / option menu mix ? what is the argument on this? sounds like going in circles ;-) Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
magic expand flag on GtkWidget
Hi, This is a major enough change it should probably hit the list and not just bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=628902 The patch needs finishing as noted in the bug but you can already play with it, it just is missing some production details. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
legacy-free grid container
With https://bugzilla.gnome.org/show_bug.cgi?id=628828 and https://bugzilla.gnome.org/show_bug.cgi?id=628902 Box and Table are pretty much all messed-up. They have a bunch of redundant flags to specify, and their redundant fill flag is a problem because it has the wrong default (must always be true to make the widget flags work). Rather than churn up Box and Table in-place, maybe it would be nicer to create a legacy-free new GtkGrid. The basic idea of GtkGrid is: * it just puts things in rows and columns, and implements homogeneity; expand, fill, padding are now all in Widget * it is an infinite grid, not a fixed size at construct time like GtkTable. so you don't have to keep construct size in sync with what you add. It auto-resizes to hold stuff. * the coordinate system goes into negative numbers, so you can add things on either side of the axes * its "default" mode if you just container_add() is like a box, in that it just keeps appending children to the axis. they are then in a single-row or column table. this lets it replace Box. * but you can also do an add_at(grid, child, x, y, cells_wide, cells_high) (note, coords then WxH in cells, rather than annoying "attach points" where you have to change both numbers to move) * you could also do add_by(grid, existing_child, child, side_of_existing_child, cells_wide, cells_high) which lets you build things up relatively. this is nice because if you want a stack of stuff above the foobar, and you insert something before the foobar, you don't have to go and redo all your coordinates * have separate "h" and "v" homogeneous flags to force all rows or all columns to be the same height * have separate "h" and "v" spacing which would be the same between all rows or all columns * minor thing: kill SHRINK mode in table, it's broken (esp. in a world with min size separate from natural) * an issue: the naming of the cell-based access (x,y) is a mess if you allow it to be GtkOrientable like box. but if you require an add_on_axis(orientation, child) then it's not as convenient as box. Anyway something like that. It's just a box if you create and container_add(), but it can become a table if you just start packing things off the main axis (no more "box regret" - "I wish I'd used a table now that I'm halfway into this!"). And it lacks the redundant padding, expand, fill confusion when mixed with the new patches. Probably there are better plans but that's the one I thought of. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk DirectFB backend (again...)
On Sun, 2010-09-05 at 15:37 +0100, Emmanuele Bassi wrote: > On Sat, 2010-09-04 at 19:47 +0200, Lionel Landwerlin wrote: > > > Last week, I have seen that GTK+ 3.0 has drop the DirectFB backend > > because no maintainer was carrying it (which I wasn't aware of). > > that's frankly odd, since the backend has been known to be broken since > the 2.14 release, which happened two years ago. And it was fixed by me during the 2.14 release cycle. Honestly I don't have the time though to keep it working on a regular basis. That's why I asked Lionel to step up as the maintainer of the backend. That said, let's see how the work on the backend in Lionel's git repository evolves... Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk-OSX
Am 03.09.2010 02:48, schrieb John Ralls: > > On Sep 1, 2010, at 7:53 PM, John Ralls wrote: > >> >> On Sep 1, 2010, at 12:38 PM, Olav Vitters wrote: >> >>> On Tue, Aug 31, 2010 at 09:56:12AM -0700, John Ralls wrote: It's now on Sourceforge because when Richard decided with his partner wind up Imendio and to withdraw from Gtk+, he asked on his forum for someone to take over maintaining the build system. I bit, and after some probing discovered that he'd not been successful in getting anyone to take over *any* of the components; he had some hope that one or more of his former Imendio employees who were still involved with Gtk+ would take over maintaining the Gtk+ parts. I quickly discovered that it would take some time and a lot of work to get a project started at Gnome.org. It took a week at Sourceforge, and only that long because I did a hostile takeover of a moribund project that was a fork of Gtk 1 whose name I wanted. >>> >>> If you want a Git account so you can commit to Gtk+, it should be pretty >>> easy. Three steps basically: >>> 1. For the person requesting it: follow http://live.gnome.org/NewAccounts >>> 2. A gtk+ maintainer: approving the Git account >>> 3. Accounts team: setting it up >>> >>> This can all be done very quickly. >>> >>> If for some reason there is a delay in above process, feel free to >>> send me a message. >> >> It seems likely that no. 2 will be the rub: I don't have a long track record >> compared to others who don't have git commit priv (Paul Davis comes to >> mind)... but maybe they never asked. So I just did. We'll see what happens, >> eh? > > > Well, much to my surprise, my Git account was approved in short order. > > So now the question is which pieces belong where? > > Gtk-quartz-engine already has a repo, so that's obvious. The > GtkOSXApplication half of ige-mac-integration can go in gtk+/gtk, and its > Python bindings to PyGtk if the devs over there are willing. > > But what about the build stuff and the proxy packages for docbook and > gtk-doc-utils? I think I heard somewhere that you have a kind of dummy gtk-doc to satisfy the build deps. I wonder if we can fix this somehow better. Can you either ping me in #gtkdoc (gimpnet-irc), write to gtk-doc mailing list or even to me in person and describe the problem. Also let me know where I can look at the dummy package that you are using. Stefan > Is there a logical home for them, should they have a new project on Gnome, or > should they stay on SourceForge? > > Regards, > John Ralls > ___ > 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: Gtk-OSX
On Sep 6, 2010, at 12:13 PM, Stefan Kost wrote: > > I think I heard somewhere that you have a kind of dummy gtk-doc to satisfy the > build deps. I wonder if we can fix this somehow better. Can you either ping me > in #gtkdoc (gimpnet-irc), write to gtk-doc mailing list or even to me in > person > and describe the problem. Also let me know where I can look at the dummy > package > that you are using. No, it's gnome-doc-utils that's faked to satisfy the build deps, along with a package of DocBook DTDs (that the real gnome-doc-utils would provide if it wasn't faked). I thought that it had to do with not wanting to deal with scrollkeeper, but that doesn't seem to have anything to do with gnome-doc-utils. At this point, I don't really know why it's there; perhaps one of the Lanedo folks still here knows or can find out from Richard Hult. I'll experiment with just using the real gnome-doc-utils instead. If it works, then gnome-doc-utils-fake and gtk-osx-docbook can go away. If it doesn't, then when time permits I'll see about fixing it. It doesn't look like either gnome-doc-utils-fake or gtk-osx-docbook should migrate to gnome.org. Gtk-doc works fine and is a supported module. I even used it to write the documentation for GtkOSXApplication. The code is at http://github.com/jralls/gnome-doc-utils-fake, but I doubt that you'll find it interesting. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: legacy-free grid container
On Mon, Sep 6, 2010 at 1:48 PM, Havoc Pennington > > The basic idea of GtkGrid is: > > * it just puts things in rows and columns, and implements homogeneity; > expand, fill, padding are now all in Widget > * it is an infinite grid, not a fixed size at construct time like > GtkTable. so you don't have to keep construct size in sync with what > you add. It auto-resizes to hold stuff. > * the coordinate system goes into negative numbers, so you can add > things on either side of the axes > * its "default" mode if you just container_add() is like a box, in > that it just keeps appending children to the axis. they are then in a > single-row or column table. this lets it replace Box. > * but you can also do an add_at(grid, child, x, y, cells_wide, > cells_high) (note, coords then WxH in cells, rather than annoying > "attach points" where you have to change both numbers to move) > * you could also do add_by(grid, existing_child, child, > side_of_existing_child, cells_wide, cells_high) which lets you build > things up relatively. this is nice because if you want a stack of > stuff above the foobar, and you insert something before the foobar, > you don't have to go and redo all your coordinates > * have separate "h" and "v" homogeneous flags to force all rows or all > columns to be the same height > * have separate "h" and "v" spacing which would be the same between > all rows or all columns Sounds like a nice plan to obsolete both GtkBox and GtkTable in GTK 4. > * an issue: the naming of the cell-based access (x,y) is a mess if you > allow it to be GtkOrientable like box. but if you require an > add_on_axis(orientation, child) then it's not as convenient as box. I don't think cell-based access is going to be a problem. The way I see it, the orientation will determine if plain add() works like an hbox or like a vbox, and changing the orientation of an already populated grid will simply flip all x/y coordinates of existing children. One thing to keep in mind is that GtkBox has been updated to do hfw/wfh, but GtkTable hasn't yet. If we decide to go for a new, more flexible container, we should perhaps not waste time on making GtkTable do hfw and instead focus on GtkGrid. Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: magic expand flag on GtkWidget
On Mon, Sep 6, 2010 at 12:53 PM, Havoc Pennington wrote: > Hi, > > This is a major enough change it should probably hit the list and not > just bugzilla: > https://bugzilla.gnome.org/show_bug.cgi?id=628902 > > The patch needs finishing as noted in the bug but you can already play > with it, it just is missing some production details. I like this idea a lot. In particular the automatic window resizability will be nice. I do foresee some complications in the expand-propagation for more complicated containers, though: - Just because a tab label expands, the notebook should probably not. - a table/grid can only expand vertically if it has an entire row of vertically expanding children (I think ?) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: legacy-free grid container
We should also make GtkWrapBox legacy-free by removing packing and padding child properties from it before it goes stable. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: magic expand flag on GtkWidget
Hi, On Mon, Sep 6, 2010 at 8:18 PM, Matthias Clasen wrote: > In particular the automatic window resizability will be nice. Unfortunately this part is scary ;-) a whole lot of the gtkwindow.c code related to this was last touched by me in 2001, some was last touched even earlier than that, and I remember having to revise my rewrite of this code many many times to handle all the corner cases. But maybe this feature is relatively superficial and won't interact with the scary stuff, right? ... But yeah, this is kind of the cool part. At the same time we can fix gtkwindow to take advantage of natural size to set default size, and I think in order to do that, we need to constrain the default size to the monitor work area. > I do foresee some complications in the expand-propagation for more > complicated containers, though: > > - Just because a tab label expands, the notebook should probably not. > > - a table/grid can only expand vertically if it has an entire row of > vertically expanding children (I think ?) > Right. I think the containers should be able to fix this stuff in their compute_expand. Also, for similar cases an app may have, they can set an explicit expand=FALSE on a container and expansion will not propagate upward any further. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_container_new_child (was Re: Wrapping Box Container)
I forgot that GtkWidget::parent already works: g_object_new (TYPE_FOO, "parent", box, "blah", 42, NULL) This is a pretty nice solution I think. You don't even have to save a pointer to the new object if you aren't doing anything other than adding it to parent and setting a couple of props. 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
On Sat, 2010-09-04 at 21:37 -0400, Havoc Pennington wrote: > Hi, > > several questions looking at this code, Sorry it took me a while to answer this mail. > > 1. I may be nuts but I really thought set_size_request() could reduce > a size request below the widget's normal request, back in the day. > However, won't this code allow set_size_request to *increase* min size > only? > > http://git.gnome.org/browse/gtk+/tree/gtk/gtksizerequest.c#n311 > > i.e. cached_size->minimum_size = MAX (cached_size->minimum_size, > group_size); > > and cached_size->minimum_size is straight from the widget itself. > > Am I reading something wrong or was this an intentional change or a bug? Not intentional... my mistake/bug (I was not aware you could reduce the base size request using set_size_request()). > > 2. The use of AuxInfo in gtkscrolledwindow.c is weird weird weird > > http://git.gnome.org/browse/gtk+/tree/gtk/gtkscrolledwindow.c#n1873 > > scrolledwindow uses the forced size request of the child (done with > set_size_request) but does not use the actual size request of the > child? what? > > This appears to be ancient 12-year-old weirdness, see commit 0d15bc66, > http://git.gnome.org/browse/gtk+/diff/gtk/gtkscrolledwindow.c?id=0d15bc6687e9a9718273a37b3d880f6526fa91ce > > In an era of min size, I think we should declare this silly and just > use the min size of the child. The commit introducing this seems to be > in a world where "set_usize()" (the old set_size_request name) meant > "user-explicitly-set size" instead of its current meaning of "minimum > size request" I agree its weird weird weird, the scrolled window hfw changes were delicately effected in the hope of not breaking anything (granted, completely reconsidering the scrolled window code would have been better). That being said the next thing on my list is to seriously reconsider how scrolled windows should work with height-for-width (as my current patches for height-for-width treeviews has some evil hacks in place to avoid infinite recursions when placed in scrolled windows). For a taste of what's in store for scrolled windows you can read through Owen's prior work here: https://bugzilla.gnome.org/show_bug.cgi?id=611740 > 3. The use of AuxInfo in gtklabel.c I don't really understand, plus seems > buggy > > Basically, in a w-for-h h-for-w world, why does label need to look at > this itself and include it in its size request up front? I can imagine > the motivation back in the days when wrapped labels had to be hacky, > but now they should not have to be hacky. What is the story on this? > > If it is used, the buggy is that it seems to ignore the GtkMisc > padding etc. properties and assume that set_size_request only sets the > size of the text itself, rather than the entire widget. Right... again as with scrolled window I tried to make the least changes as possible (originally I was hypothetically targeting GTK+ 2.x series). Some good refactoring and even optimization is also possible in gtklabel.c, the problem here is that everything is done through gtk_label_ensure_layout() which is called way too often, recreating the label's layout for the sake of any request. That being said... we can probably safely just remove the bit that consults aux_info from inside gtk_label_ensure_layout(), this must be there historically so that gtk_label_ensure_layout() creates a layout at the right height when doing a "size-request" for a word-wrapping label. Cheers, -Tristan ___ 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 Sat, 2010-09-04 at 22:20 -0400, Havoc Pennington wrote: > Also, > > 4. AuxInfo still contains x,y, x_set, y_set and code reads them, but > commit 0d322676dcb06be62329a7d4373c497993509fbd removed set_uposition > and now there is no way to set these - so they should die, right? The removed gtk_widget_set_uposition() docs mention that it is not useful for a widget that is inside a container, however the variables are used in the default allocator: gtk_widget_real_size_allocate(). For GtkWindows we already have gtk_window_move(), and imo the fact that the rarely used default allocator accesses these is some kind of hack that I would like to see disappear. So yes... lets kill x_set/y_set/x/y on the AuxInfo (now that you cannot set them from any public API... theres no excuse afaics to keep them around). While looking at the mentioned commit that removes set_uposition() I find that we have _gtk_window_reposition() which does nothing except call the public API gtk_window_move()... it would be nice to hunt down and remove instances of these useless private functions as well... Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
