< ebassi> meeting time :-) < ebassi> as usual, the agenda is on the wiki: http://live.gnome.org/GTK%2B/Meetings < ebassi> • GApplication and GtkApplication < ebassi> • Revise 'deprecatable' list < ebassi> • Change default values for properties < walters> ok so, GtkApplication status quickly - we reworked GAppliaction's API significantly based on comments, and various fixes landed. I've been working a bit today on documentation and more minor fixes < walters> there are still big picture items outstanding like win32/osx backends, but I think the general feedback there is that it wouldn't hurt at least, and can potentially help < ebassi> I've been looking at re-implementing UniqueApp in terms of GtkApplication - or at least porting it inside GtkApplication itself (basically, the message passing) < ebassi> it's not ready, yet, but this week I've allocated time to finish it off and propose it < mclasen> ok, I have a few additions to the agenda < mclasen> - xi2 merge < mclasen> - minor api cleanup possibilities < mclasen> so, what do we start with ? < ebassi> mclasen: do you have other things to say, re: gapplication? < ebassi> otherwise we can start with xi2 merge < mclasen> my main concern re gapplication is to get some prototype implementation for win32/osx < mclasen> but lets start with xi2 merge then < jjardon> Do somebody know the nick of the guy that makes the ige stuff? < mclasen> paul davis is las, I don't know if john ralls is on irc < mclasen> status of xi2: carlos created the xi2-for-master branch last week < mclasen> and I spent some time fixing up distcheck and docs on it < mclasen> and it works fine, as far as I can see < mclasen> today I committed the gdk sealing patch to master < mclasen> and merged it to xi2-for-master < mclasen> so from my perspective, the branch is good to be merged < mclasen> I would have loved to have garnacho look over things one more time, but he seems not around this week < ebassi> I'd say go for it :-) < mclasen> yeah, my feeling as well < mclasen> oh < mclasen> ok, if there is no further discussion on it, I'll merge it later, and do a snapshot with it < mclasen> garnacho said he'd work on some more docs, but that clearly doesn't have to block the merge < mclasen> next topic ? < ebassi> "minor API cleanup possibilities" < mclasen> thats mine, I guess ? < mclasen> some things I noticed while looking through api docs yesterday... < mclasen> We still have GtkArg in the headers, with gtk_main_add_quit_func_full (or similar) being the only user < mclasen> we could consider replacing that with GParameter, which has the same purpose < jjardon> indeed, GtkArg is already deprecated < mclasen> it would be an api break, for an almost never-used api < mclasen> another small thing I noticed in passing is an unused GtkForeachData in gtkcontainer.c < mclasen> but thats not in any headers, I think < mclasen> and the last one I had on my list was GtkWidgetHelpType - is that something that is used/useful ? < ebassi> doesn't seem used at all < mclasen> iirc the gimp used it at some point < mclasen> not sure if they still do < ebassi> wasn't that some sort of windows95 kind of "help topic"? < ebassi> to get quick help about controls < mclasen> yeah < mclasen> the original idea was to click on a help button in the window frame, and then on a control < mclasen> or something like htat < mclasen> never implemented < jjardon> mclasen, gimp doesnt have GtkWidgetHelpType in its code < mclasen> anyway, I just wanted to throw these out here to maybe inspire some thought or patches < mclasen> no need to decide anything on the spot < kalikianatoli> ^^ Hopefully somebody takes notes on these deprecation items < mclasen> the last topic I'd like to get a quick vote on is the flipping of orientables < mclasen> last week we said that we'd try to do the default value changes that were holding this up for all this time < jjardon> kalikianatoli, I'll, Should I file a bug for each item < jjardon> ? < mclasen> but when jjardon and I looked at it, it turned out that changing visible to default to true does not work < kalikianatoli> jjardon, yeah, if you don't mind, that would be nice < mclasen> it breaks all kinds of assumptions inside gtkwidget.c < mclasen> so I think it is essentially undoable < mclasen> the only other default changes that were on the wiki are already in place < mclasen> (that was box expand and fill child properties) < kalikianatoli> so can we have non-abstract orientables then? < leio> jjardon: GtkWidgetHelpType seems to be a parameter of GtkWidgetClass::show_help btw, so some GtkWidget derivatives outside gtk+ that implement show_help use the symbol as its in the prototype of the vfunc per google codesearch < jjardon> This was the patch: http://pastebin.com/Sx5pn87b < mclasen> kalikianatoli: that is my proposal: make orientables instantiable anyway < mclasen> I have a patch to do so ready to go < mclasen> just want to see how others feel about that < ebassi> I don't mind < kalikianatoli> You have my thumbs up < ebassi> would allow me to stop using VBoxes and HBoxes < mclasen> yeah, only boxes from now on < mclasen> so, I'm done with my topics. whats next ? deprecation list ? < ebassi> yep < ebassi> 'revise deprecatable list' < ebassi> the TearoffMenuItem bug is getting ridiculous < mclasen> so, where's the list, and what revisions are proposed ? < ebassi> people asking for a discussion on the list, but not sending email < jjardon> the bugzilla query: https://bugzilla.gnome.org/buglist.cgi?status_whiteboard_type=casesubstring;status_whiteboard=deprecations;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;bug_status=NEEDINFO < jjardon> Decission about GtkHSV, GtkRuler, GtkVruler and GtkHRuler should be taken < jjardon> Also GtkAdjustment signal tadeboro reported < kalikianatoli> I vote for Gtk[HV]Ruler, it's hardly used, and Gimp for example has its own fork and doesn't use it iirc < mclasen> my position on this is that I think it is much more important that we get all the currently deprecated stuff cleaned up < mclasen> we don't have to go overboard deprecating yet more stuff at the last minute < kalikianatoli> I agree in terms of it being not important at all. If somebody does it, fine, if not, doesn't hurt, I think < tadeboro> And about GtkAdjustment::(value-)?changed signals, GtkAdjustment with all of it's (now GSEALed) public files will make one hell of a mess all across the gtk's code. < tadeboro> So I think mclasen's proposal to clean already deprecated stuff first is completelly in place. < jjardon> mclasen, I think onyl gtkprogress deprecated api remains < jjardon> because It's used by GtkProgressBar < jjardon> check with git grep "ifndef GTK_DISABLE_DEPRECATED" in gtk/ < mclasen> jjardon: there's a bunch of deprecated stuff in gdk, I believe < jjardon> mclasen, yeah, I try to work on that, but some stuff is pretty low level. Anyway I submitted a patch to remove GdkColors today < mclasen> ok, cool < jjardon> Tracker bug here fot GDK: https://bugzilla.gnome.org/show_bug.cgi?id=597742 < mclasen> looking at the bug list, I would sort rulers, hsv and non-multihead-safe api at the bottom of the priority list < mclasen> tearoff menu items are a somewhat borderline case... pretty much fallen out of use and fashion, but there's a small group of lovers of that feature < mclasen> they do complicated the menu code quite a bit < jjardon> mclasen, ok, but should these be deprecated if someone makes the patches or is not a good idea? < jjardon> rules, I mean < ebassi> mclasen: I'd even settle for an early 3.x deprecation < jjardon> and hsv < mclasen> jjardon: hsv, I just don't care. I don't even remember why we made it public at some point. was there an external user ? < mclasen> seems to be bug 547270 < mclasen> so mitch made it public in 2.14 < mclasen> is the gimp using it ? < jjardon> mclasen, in modules/color-selector-wheel.c < jjardon> (only) < jjardon> jjardon@rhun:~/git/gimp(master)$ git grep gtk_hsv < jjardon> ChangeLog.pre-2-6: * modules/color-selector-wheel.c: declare gtk_hsv_get_type() if < jjardon> modules/color-selector-wheel.c: wheel->hsv = gtk_hsv_new (); < jjardon> modules/color-selector-wheel.c: gtk_hsv_set_color (GTK_HSV (wheel->hsv), hsv->h, hsv->s, hsv->v); < jjardon> modules/color-selector-wheel.c: gtk_hsv_set_metrics (GTK_HSV (wheel->hsv), size, size / 10); < jjardon> modules/color-selector-wheel.c: gtk_hsv_get_color (hsv, < mclasen> for rulers, do we have any known users ? < mclasen> the gimp has its own right ? since they have all kinds of corner thingies < jjardon> mclasen, not many results in google code search ... < mclasen> gimp has its own, indeed < leio> dia < leio> xsane maybe < tadeboro> claws-main also I think (checking now ...) < tadeboro> claws does use GtkHRuler < mclasen> things like bug 610346 (allow-shrink vs resizable) seem more worthwhile to me < mclasen> cleaning up real sore spots in our api, as opposed to killing innocent widgets < mclasen> maybe we should talk about the adjustment stuff, quickly ? < jjardon> I think tadeboro has something to say here < tristan> 9 * tristan excuses < jjardon> This is the GtkAdjustment bug: https://bugzilla.gnome.org/show_bug.cgi?id=619493 < tadeboro> I did some experiments with GtkAdjustment lately and making it behave like any other GObject will couse some real pain. < tadeboro> Most obvious thing is, a lot of code uses GSEALed public fileds. < tadeboro> More troubling thing is "delayed emission of signals". A lot of code currently modifies some value and only emits signal later. < tadeboro> One such example is GtkRange with it's various update policies. < mclasen> is that purely for batching of changes ? < tadeboro> One thing is batching, but other (more troublesome) use is making sure that GtkAdjustment is in consistent state when signal is emitted. < tadeboro> For example, if direct accessors are to be used, it will become impossible to prevent emitting two ::changed signals when changing :upper and :lower. < tadeboro> First emission in this case will likely cause some trouble for widgets, because there is a real chance that GtkAdjustment is unusable at the moment of first emission (for example, upper might be less than lower). < ebassi> freeze/thaw pair? < tadeboro> Currently this is possible, but when I proposed a solution based on this couple of days ago, owen was not impressed. < kalikianatoli> there's gtk_adjustment_configure for that < ebassi> true < tadeboro> kalikianatoli, but you need to provide all of the values there and that function is in the end a simple wrapper around g_object_set(). < mclasen> also you can just object_freeze/thaw < ebassi> it's more the signal emission that's messing up < kalikianatoli> tadeboro, yes of course. because it makes a lot of sense if the values depend on each other < mclasen> but the signal emission is tied to property notification < tristan> I was wondering if anyone is ever going to want to subclass the adjustment, and if triggering the notification/setting the values should be tied together so strong at all < mclasen> in fact, adjustment_configure was added when we sealed GtkAdjustment in 2.14 < tristan> I was also wondering if keeping the manual notification apis around was justified, if only for the purpose of less integral code... that needs to force an update for some obscure reason < tristan> just some thoughts < jjardon> Bugs to remove GtkArg, GtkWidgetHelpType and GtkForeachData filed < tadeboro> The way I see it after couple of days looking and thinking about it is: < tadeboro> - make accessors replacement for direct field setting and leave signal emission to the owner < tadeboro> - make accessors wrappers for g_object_set() and emit signals together with ::notify signal < tadeboro> I do have some prototype code for second scenario and it works quite nice actually. < tadeboro> As an additional benefit, second method also offers a way to make sure GtkAdjustment is in sane state when property setting is done. < mclasen> that leaves delayed-apply use cases uncovered ? < tadeboro> For example, one can ensure that upper >= lower, lower <= value <= upper - page_size, 0 < page_size < upper - lower ... < mclasen> ie the gtkrange update policy you cited < mclasen> I don't think the last constraint is valid, btw < mclasen> page_size could well be larger than upper - lo wer < tadeboro> Both methods proposed would cover all cases; direct accessors as proposed yesterday would fail to do so. < tadeboro> But does it make sense to have page_size larger than the whole range? < tadeboro> Scrollbars cannot do anything with this scenario, spin button will be fixed to lower value, ... < mclasen> tadeboro: I could see some ui using upper, lower and pagesize to somehow visualize what fraction of a page is currently shwon < mclasen> you are right though, it'll pin the value to lower in any case < mclasen> maybe we should call it good for this week ? < mclasen> my takeaway from the discussion is: a) make orientables flippable b) merge xi2 c) do a release < mclasen> and the application stuff needs another week to simmer < ebassi> sounds good to me < tadeboro> I'll finish my GtkAdjustment patch and offer it for revision and let people decide when they see some code. < ebassi> tadeboro: thanks < mclasen> thanks < jjardon> I'll try to work on remove more deprecated code < mclasen> I'll further sit on Company to get 2.22 building again < mclasen> and to get the region stuff into master as well