lets start anyway, I guess so be it ok, cooking finished the agenda is at http://live.gnome.org/GTK+/Meetings looks like it is all me today... so I'll just start with my first item... i have something for misc but was too lazy to add sure 1) Adding a message area widget in 2.16 ? See #555344 I basically just wanted to hear peoples opinion on this it wasn't on the 2.16 feature list that we've discussed earlier do we have a netsplit, the channel is unusually empty and many usual suspects missingf but it is a relatively widespread ui pattern -f how would that look? we have a dialog in gimp that collects messages instead of popping 5 dialogs. is that the same? if you open a nonexisting file in gedit you see it in action the tooltip-colored area that pops up above the document ah that stuff it should derive from GtkBox of course ;) this pattern seems to have originated in browsers but it is widespread by now, in all document-based apps evince, eog, gedit, etc... they all copy code from gedit, afaics we even considered having it in the gimp image window for some messages there is some more work to do before this is really ready to land oooh it is the thing that slides in from above? I've put some of the remaining questions in the bug its not really sliding in i hope it slides ;) :( that would require animation support... we can take care of the animations in a later version of gtk+ the offscreen code can slide it in with 80% opacity yeah, we can make it nicer but at least I have an idea what the widget is about now the api is pretty much a copy of gtkdialog you can add buttons/action_widgets to an action area and theres a content area where you can put arbitrary widgets maybe it shouldn't copy the tooltip style, but instead assume that themes will adapt? thats one of the open questions I left in the bug... any label put into it may need to get the text color changed (gedit gets this wrong currently) yeah, also, it doesn't work right with hicontrast-inverser but thats more a bug of that engine so, the general sentiment seems to be that this would be an ok addition in 2.16 ? i could ask our gimp ui master and report back about the general concept i mean yeah I think it would be nice to have I'm not going to commit it tomorrow i agree I'll work on the remaining issues in the bug i am unsure about the api, but it seems it did have some real-world testing alreaddy Sounds like a reasonable addition to Gtk+ ok, next topic Timeline for next stable releases I wanted to let you know that I was planning on doing stable releases sometime next week well ahead of gnome 2.24.1 just so you can commit your fixes faster :-) and there was silence I am thinking about any pending fixes I have I don't think I have anything urgent ok, just holler if something is worth holding the release for I expect to start distchecking ~ 1 week from now maybe we could poke carlos to fix that filechooser bug good point I'll poke kris and i will also poke that should hurt enough ;) I went through curerntly open tooltip bugs last week didn't find much urgent except for that one crasher bug which seems to only happen when people are using certain language bindings for some reason heh there he is garnacho: maybe we could poke carlos to fix that filechooser bug which one? garnacho: about stable gtk release next week garnacho: the one that doesn't allow to navigate to remote uris mclasen: or did you mean another one? the other one I know of is the initial-size-is-wrong one heh but thats not carlos' oh other one hm? I'll have a look at the remote uris one * garnacho feeling a deja vu but federico is in Boston this week, so I don't expect to see a fix for the size problem next topic is also related to releases GLib 2.20 for Gnome 2.26 ? there was some demand for having a faster glib release again for which feature? mostly for new gio stuff, to make nautilus and gvfs behave better I see a small thing is the added api in the appinfo stuff that I committed earlier that lets nautilus handle deleting apps and reset mime associations frequent releases never hurt and another one that david and alex are currently working on is support for connected servers that requires some api additions in gvolume/gmount what's that? its one of the notable regressions in the gnome-vfs > gvfs move the ability to define shortcuts to servers ah nice and have them be presented on the desktop / places menu we've kinda emulated that badly with bookmarks for 2.24 but it is not comparable to the old gnome-vfs feature david really wants to have it back, since he used that feature :-) anyway, I don't think there is much wrong with cutting a faster glib release, as long as everybody is aware of it and I didn't hear and dissent... my last topic for today (phew): "Special-purpose features" - what is the 3.0 plan for GtkCurve etc ? you can't since the trombone made you deaf thats over by now (Thank god) :) the curve is particularly useless, does anyone use it? the question about the special-purpose features occurred to me recently when looking over the docs GtkRuler on the other hand is marked as "will move out of gtk", but so many apps use it no, 'special-purpose' is basically a polite way of saying 'useless', I think yes GtkGamma its a bunch of gimp 0.x stuff, i think we should deprecate it of course, the gimp has long since moved on probably Oct 07 16:28:32 * Lethalman has quit (Remote closed the connection) so, basically my question is if we need to make it clear that these things will be treated the same way as deprecated apis do you have some kind of list? why not deprecate them right away? that might be the easiest way to do this or GTK_DISABLE_CRUFT the list is basically this: http://library.gnome.org/devel/gtk/stable/SpecialObjects.html i vote for keeping the ruler though it's pretty common i think (note that gimp uses GimpRuler since 2.6 so i'm not speaking for myself) someone probably needs to do some research to find out whats used mitch: GtkHRuler and GtkVRuler should still be removed and replaced with a concrete orientable GtkRuler? Sonderblade: the orientable ruler is already there mclasen: and in this special case i would vote for really deprecating hruler and vruler not much impact here i think ok, fair enough oh i see I guess I'll put the special-purpose widgets on the gtk3 task list on the wiki good idea thats finishes the list of my topics i think the "Note" section in those widgets are pretty clear that they will go, even if the word "deprecated" isn't used mitch: you had a misc item ? Oct 07 16:33:15 * m8t|laptop (~mike@88.172.125.130) has left #gtk-devel yes i have this bug i'm totally undecided on and want to make a tiny poll here :) one sec... http://bugzilla.gnome.org/show_bug.cgi?id=516425 it's about allowing accelerators in ui-manager created popups there are two ways, one is specifying in the XML the other one is having a "popup-accelerators" boolean property on GtkAction opinions please I think putting it in the xml is fine that approach is also 100% implemented and reviewed i will end up with the same set of opinions as before ;) it is much more presentation-side than abstract-action-side move view than model, yea that's a good point why not put it in GtkSettings? but it makes it unswitchable at runtime, no clue if we would want that Sonderblade: because it should be per-menu mitch: why? Sonderblade: because $PLATFORM might have this main menu equalling the menubar, that should have the accels, but other popups shouldn't it's not a global policy decision that can be made for all popups i think i'll simply commit the xml based fix i'm done :) * mclasen needs to go see you guys later