< ebassi> as usual, the agenda is at: http://live.gnome.org/GTK%2B/Meetings < ebassi> • GTK3 cleanup tasks < ebassi> ‣ GtkObject deprecation / removal (bug: 615666) < ebassi> ‣ gtk_widget_hide_all deprecation / removal (bug: 438318) < ebassi> ‣ uri hooks cleanup (bug: 339745) < ebassi> ‣ remove notebook unneeded code (bug: 96834) < ebassi> ‣ GTK_POLICY_AUTOMATIC as default (bug: 468672) < ebassi> ‣ Since tags < ebassi> • coding style conventions < ebassi> • miscellaneous < ebassi> right, should we start? < mclasen> sure < ebassi> first item, clean up tasks: GtkObject deprecation < mclasen> this came in the context of dealing with widget flags < mclasen> and I proposed that instead of continuing to deal with the split in gtkobject and gtkwidget < mclasen> we should just ditch gtkobject < mclasen> which is a bit of work, but doable; I have have branch that does it < mclasen> it moves the destroy signal into gtkwidget, and makes all other gtkobject derived classes ginitiallyunowned derived < ebassi> Clutter used InitiallyUnowned as the base class, and we haven't had any issues < mclasen> I also have untested patches for some 20 gnome modules to remove gtkobject uses < mclasen> most of them trivial, the only non-widget use of destroy functionality < pbor> is there anything that uses destroy that is not a widget? < mclasen> is in gnomecanvas / eelcanvas < mclasen> which I solved by simply duplicating the destroy signal in the canvasitem class < pbor> can someone remind me what is difference between using destroy and using dispose? < ebassi> pbor: not much < mclasen> destroy is a signal < mclasen> dispose is not < mclasen> destroy gets emitted when you dispose a gtkobject < ebassi> mclasen: and generally nobody implements the destroy vfunc < mclasen> yeah, it is not very consistently implemented < mclasen> so, I basically just wanted to get some feedback if people think this is generally a good idea < mclasen> then I am ready to go forward with this, merge the branch and file all my patches < ebassi> mclasen: I see no problem < pbor> what is the alterantive of connecting to destroy? weakref? < mclasen> yeah, something like that < mclasen> but, as I said; there's damn few non-widget users of destroy < pbor> I am all for ditching gtkobject, my question is if we should ditch/deprecate the destroy signal altogether < mclasen> and for widgets, destroy will not change < ebassi> I think mitch had some ideas wrt the base class - at least we discussed this ages ago. but he's not here :-) < ebassi> pbor: a lot of code relies on the ::destroy signal < Company> mclasen: did you investigate getting rid of destroy for anything but windows? < ebassi> pbor: for 4.0 we might move to weak pointers and weak-ref :-) < mclasen> Company: yes, my gtkobject-removal branch does that < mclasen> Company: oh, windows < mclasen> no < pbor> ebassi: sure, that's why I said "deprecate" < Company> mclasen: you looked at the code, so you'd know if that'd be a useful idea < Company> mclasen: but i think we have generally way too much API attached to GtkWidget that'd be way better placed at GtkWindow < pbor> Company: if we keep it, it is not just for windows imho (e.g. you want to see when a tab in a notebook is destroyed or stuff like that) < mclasen> well, the usage is certainly 90% on dialogs and menus < Company> pbor: that's page-removed ;) < Company> i don't know so i have no opinion < Company> it's just gut feeling that window is a good idea < mclasen> I'll have a look at it again when I file the patches < mclasen> for now I'll leave it on widget, I guess < pbor> not that I think it is a reason to hold back, but what happens to widget sublasses that implement gtkobject->destroy? < pbor> do they need to ifdef gtk 2/3 < pbor> or is there some kind of hack possible? < Company> ifdef < mclasen> no < mclasen> well, yes < mclasen> they need to either set object_class->destroy or widget_class->destroy < Company> you can do a DESTROY_SIGNAL cast or sth of course < pbor> #define GtkObject GtkWidget :) < Company> not a bad idea < ebassi> typedef GtkWidget GtkObject < ebassi> typedef GtkWidgetClass GtkObjectClass < Company> i think in general apps should stop trying to compile the same code against gtk2 and gtk3 < ebassi> post-2.32, I agree < Company> they should track gtk2 now < Company> and convert to GTK3 after 2.32 has branched < Company> the mutter fixup for rendering-cleanup was painful < mclasen> agreed < mclasen> anyway, next topic ? < Company> and mutter doesn't even really use GTK < mclasen> unless somebody has more opinions on gtkobjects fate < pbor> I agree, but it kinda defeats all the work done until now < pbor> where apps compiling without warnings on 2.32 woudl work with 3.0 < Company> we've abandoned that idea anyway < pbor> okay < mclasen> pbor: building without warnings in 2.32 still gets you close to working with 3 < Company> we still want minimal changes, but there'll be changes < pbor> yeah, I guess that if the timeline does not slip anymore "close enough" is the best tradeoff < Company> so the upgrade path for your app should be: port to gtk 2.latest, then port to 3.0 < ebassi> right, next item: deprecation of GtkWidget.hide_all() < ebassi> +1 from me * pbor never used it, so sounds good :) < ebassi> +2 if that also means removing the hide_all() vfunc < ebassi> +3 if show_all() goes the same way < pbor> show all is kind of useful < mclasen> hide_all is very rare, show_all is very common < Company> ebassi: only f widgets are visible by default < pbor> Company: only if non-toplevel widgets are visible by default < aruiz> mclasen, dunno, it all depends if show_all is common because all objects are hidden by default? < aruiz> if that changes, and people are expect to hide on a case by case basis < Company> pbor: windows are always special < Company> :/ < ebassi> dunno, I show everything by default when adding, and then hide the container < ebassi> but it might be just me - hence my "+3" :-) < ebassi> I'd be happy with just hide_all going the way of the Dodo < pbor> for now I'd just stick to the agenda item, looks like everyone agrees on killing hide_all < mclasen> aruiz: changing the default value of visible to true doesn't work, at least not without redoing quite a bit of gtkwidget internals < Company> hp can do that while fixing event handling! < pbor> yup, default values is another can of worms, also for things like glade < aruiz> ebassi, I agree, at the same time, almost everybody uses show_all as most docs ask people to do so, so I'm not sure if causing all tha pain is actually worth it < aruiz> unless show_all causes a lot of trouble for maintainers or the flexibility of the codebase < ebassi> we can revisit the visibility issue for 4.0 :-) < ebassi> when we do s/GtkWidget/ClutterActor/g ;-P < Company> yay, no more GDK in GTK4 \o/ < ebassi> if we have general agreement on hide_all() we can probably skip to the URI hook cleanup < Company> go on * mclasen agrees on hide_all removal, fwiw < mclasen> so, uri hook cleanup < mclasen> the bug is about the problems that language bindings have with some of our setCallback / getCallback apis < mclasen> I have written a patch that solves this differently for gtklinkbutton and gtkaboutdialog < mclasen> for aboutdialog, I propose to simply nix the callback < mclasen> to leave room for some override capability, I've added a link-activated signal < mclasen> basically copying what we have in labels for links < mclasen> for gtklinkbutton, I've left the hook in place, but just ditched the 'return the old hook' part, since its unusable for bindings < mclasen> not sure if its worth keeping it, really < mclasen> I could be convinced to just do the link-activated signal there too < mclasen> opinions ? < ebassi> again, +1 on my side on the whole thing - the amount of ad hoc code in bindings is not funny < ebassi> I think the hook should go away in the LinkButton too < ebassi> the LinkButton already has the ::clicked signal, though < Company> yeah, signal and DTRT by default < mclasen> the one argument for the hook is that it lets you override globally, for all link buttons < mclasen> but then, you can just subclass and override the signal < ebassi> yeah, sub-classing is a better option < mclasen> ok, I'll nuke the hook from link buttons as well then. less api ! < ebassi> yey! :-) < Company> you can also add a signal hook to the clicked signal < mclasen> true < ebassi> or override the class handler < ebassi> okay, it's less convenient for the C developer, but hey: if you're using C you should be used to that :-) < mclasen> was there one more cleanup item ? < mclasen> ah, right https://bugzilla.gnome.org/show_bug.cgi?id=96834 < mclasen> I don't think this needs to be discussed, really < mclasen> its just removing dead code, just needs a volunteer to write a patch... < Company> write a patch * pbor still hopes that some day an hero comes along and just reimplements notebook from scratch fro gtk7 < Company> become #3 code remover < ebassi> bratsche also proposed removing scrolling tabs with the scroll button < Company> pbor: i hope someone writes a really awesome dock that has a notebook as a side effect ;) < mclasen> right, thats more discuss-worthy < Company> i'm for it < pbor> I seem to recall that when some cycles ago we added tab dragging it turned out there were some api screw-ups, it may be worth digging in the mailing list and see if it is fixable < ebassi> https://bugzilla.gnome.org/show_bug.cgi?id=630226 -- for reference < bratsche> Oh yeah, thanks ebassi < mclasen> as a compromise, we could make it optional and default-off < Company> pbor: i think most of it was fixed by deprecations later < Company> pbor: i just remember my blog post from back then < bratsche> Yeah, I can change it to be optional and default to off. < mclasen> since tab scrolling may have limited use cases in browser ui, but certainly is wrong in eg preference dialogs < pbor> Company: the problem is that it still sucks, for what is worth we simply do not use that functionality because you cannot detach tabs, unless you drop on the root window < Company> pbor: isn't that a DND failure more than a notebook failure? < pbor> both iirc < mclasen> pbor: if there are concrete change proposals, we can look at it < Company> http://www.advogato.org/person/company/diary/42.html < pbor> mclasen: unfortunately I think there arent, I am simply suggesting to at least take out failed experiments < mclasen> pbor: concrete examples for what you consider failed experiments would be good too < mclasen> I guess some of the things we deprecated in the tab dnd apis should just go away < pbor> mclasen: what Company linked < pbor> yep, that's what I meant < mclasen> right, some of those got addressed < mclasen> but most are still valid < mclasen> I guess I'll have a look at that < mclasen> moving on ? < ebassi> GTK_POLICY_AUTOMATIC as default (bug: 468672) < mclasen> yeah < bratsche> Any resolution on the scrolling? Do I need to change the patch to be configurable? < mclasen> I stumbled over that bug in bugzilla < mclasen> bratsche: I have no strong opinion on that, if scrolling is easy to implement in a subclass, then I'd tend to say just drop it < mclasen> if it involves much fiddling with internals, the option route might be better < Company> i'd say "drop it until someone files a bug, then make it configurable" :) < aruiz> hah < bratsche> Well, someone already filed a bug. That's how we have it in the first place. < bratsche> But my feeling is that it's a stupid feature.. either that or I just don't know of use cases where it's nice to have. < mclasen> so, lets be bold and remove it < bratsche> But I guess I still agree with Company.. I could remove it, and if someone comes back and has a great use-case we can figure out what to do. < bratsche> Okay, I'll commit that. < bratsche> Thanks. < mclasen> so, moving to the scrollbar policy < mclasen> I stumbled over a bug that proposed to change the default < mclasen> and it made some sense to me < ebassi> mclasen: not being auto by default is what never made sense to me :-) < aruiz> +1 < ebassi> so, general consensus is: we switch default to AUTOMATIC < ebassi> (silence implies consent :-)) * mclasen will make it so < ebassi> last item on the "cleanup" list is: Since tags < jdahlin> +1 for automatic < mclasen> the question here is: 1) do we want to nuke all since 2.x tags ? 2) do we need since: 3.0 ? < ebassi> personally, I don't see a problem in keeping them - except if you want to remove the index generation < mclasen> I already removed the indices, I believe < jdahlin> they're useful for stuff like glade, for which you target a specific gtk+ version < mclasen> right, within 2.x < mclasen> but does it make sense to know that an api appeared in 2.27.15 when you are building a gtk3 app ? < jdahlin> maybe glade/gtk3 shouldn't be able to support gtk2 apps < Company> gtk3 glade would have lots of fun displaying gtk2 widgets < jdahlin> dunno, IMHO they're not too much old baggage, don't think its too inconvenient to keep them along < mclasen> no, it is not < Company> i didn't add any since tags though < mclasen> we can certainly keep them around. no big deal < Company> and i didn't update since tags for function prototypes i changed < mclasen> ah, thats a good point < Company> i'd get rid of them because i think they're confusing < Company> also, i can't see anyone porting their apps from 3.0 to 2.22 < mclasen> any more opinions ? < mclasen> Company: do you think it is worth keeping the 3.0 annotations ? < mclasen> gives any easy way to see whats new, if nothing else... < Company> dunno < Company> there's "changed api" vs "new api" < Company> i'm not sure if gtk_paint_box() should be "Since: 3.0" < mclasen> no, it shouldn't < Company> it's different from the 2.x version though < Company> no idea really < mclasen> I tend to agree that we should remove the since tags, and start over with fresh since 3.x annotations < mclasen> anyway, lets not waste more time on it and move on < ebassi> given the rationale, yes < ebassi> final point: coding style < ebassi> for the joy of Company :-) < Company> i like the current coding style < mclasen> my proposal is that we basically adopt the clutter document that was pointed out on the list < mclasen> which essentially codifies the currrent gtk style < mclasen> a few things we should add are the clarifications that owen pointed out on the list wrt to nested ifs and if-else balancing < ebassi> I'll modify the clutter coding style with those as well anyway < aruiz> can anybody paste that link here? < mclasen> and some information about how to handle cleanups of the current code < aruiz> oh found it < ebassi> http://git.clutter-project.org/clutter/tree/doc/CODING_STYLE < aruiz> my only problem with current gtk+ style is the spaces for indentation < Company> which spaces? < aruiz> it basically forces everybody to visualize 2 spaces, whereas tabs are configurable < ebassi> aruiz: cairo uses mixed tabs+spaces < ebassi> aruiz: NOOOOOOOOOOOO < aruiz> Each new level is indented 2 or more spaces than the previous level: < ebassi> changing tabs to be anything bug 8 spaces is *wrong* < aruiz> mixed to aling stuff below another line? < aruiz> or mixed as "free for all"? < ebassi> no: start with tabs and finish with spaces < ebassi> http://cgit.freedesktop.org/cairo/tree/CODING_STYLE < Company> cairo has a coding style document? < Company> interesting < Company> anyway < aruiz> ebassi, I'm not advocating for mixing < ebassi> aruiz: never, ever redefine tabs < aruiz> ebassi, I'm saying we should use tabs for indentation and spaces for alingment < Company> i generally don't care about coding styles - if you want one you get to fix my patches or point me to a tool that does < ebassi> it will lead to death, taxes and the end of the universe < pbor> sorry I got distracted by other stuff, just to spend a line on the previous topic, I'd prefer to keep the "since" tags... I actually do forsee people having to "port" an app from gtk3 to gtk2 to make it work on rhel etc < pbor> and I really do not see the cost in keeping them < Company> pbor: so what should gtk_paint_box() say in your opinion? < Company> pbor: Since: 2.0, Since: 3.0? Or even Last-Changed: 3.0? < mclasen> Company: if we want to help people port, there probably needs to be a paragraph that starts "Once upon a time, gtk_paint_box() took a window..." < pbor> Company: since gtk 3 sounds fine, but I do not care particularly... the changed api are few, we should just not throw away all the rest < aruiz> ebassi, as I said, I don't really want a bikeshed, a well defined coding style is I don't agree with is way better than the current situation :-) < pbor> mclasen: nah, that's too much... if one does the backport he'll have to do his homework < aruiz> so +1 for using the Clutter one < pbor> I just do not see the win in throwing away what is already there < aruiz> ebassi, space indent and the extra indent for the braces really kills me :P < mclasen> was there any opinion on coding style updates for old code ? < Company> yes < Company> don't < aruiz> Company, why? < Company> git blame < aruiz> git history messup? < aruiz> yeah < aruiz> :-) < pbor> well, do if you are changing the code already < Company> right < Company> lines you modify may as well be perfect * aruiz wonders if we can have a git hook for this? < mclasen> Company: it is often very hard to only fix the lines you are touching, and resist the temptation to at least fix the remaining lines in the same block / function... < Company> mclasen: i guess that is fine from a git blame perspective < pbor> should we update the coding style of gtkbtree functions which are still K&R ? :-) < aruiz> mclasen, people who fix an area of the code may as well become responsible for that area of the code anyway, so that's not too bad < mclasen> ok, so to wrap up the coding style discussion, I get the impression that people would be fine with copying the clutter document and making small adjustments < ebassi> and investigate an indent script we can distribute < mclasen> do you have such a beast in clutter ? < ebassi> nope - well, usually it's me, channeling mitch < ebassi> but it should be possible to do < mclasen> hah < ebassi> I'll look into it < mclasen> ok, I guess we should come to an end ? < mclasen> I have to quick notes for 'misc' < Company> i'd like to summarize the soon-to-happen rendering-cleanup landing in master while everyone is listening < mclasen> right, thats my first point... < mclasen> go ahead < Company> rendering-cleanup will land any day now < Company> blocking on some discussion about my mutter patches < Company> it removes GdkPixmap, GdkColormap, and expose-events for gtk_widget_draw() < Company> see the list and the mail i'll send after landing < Company> it also makes GtkSizeRequest part of GtkWidget < Company> so it's a big chunk of API changes < mclasen> and you'll land fixes for mutter / gtk-engines in parallel, right ? < Company> chpe and me have ported some apps/libs already < Company> right, i'll land gtk-engines and mutter at the same time < pbor> Company: gregier started porting gsv and he has problem with the "gutter" (line numbers etc), it may be a simple bug, but it may also be a generic issue since textview has many windows, if you could have a look it'd be great < mclasen> it is probably worth sending a heads-up mail about this in advance, actually < Company> chpe has nautilus, gnome-terminal and dependencies fixed < mclasen> thats good < Company> pbor: will do < mclasen> together with the shell, thats almost a working desktop ! < Company> almost all other apps will go into "broken" state i suspect < Company> assuming they track gtk3 already < chpe> (nautilus is only 'semi-fixed', I still haven't debugged 2 problems :) < Company> and then we'll go around and fix them < Company> as always, if you have questions, poke me < Company> i'm way more excited about fixing stuff people care about than dumping patches in bugzilla that rot there < Company> i also expect this to be the last breakage of this size < mclasen> yeah, we should signal that in your mail < mclasen> I'll try to land my gtkobject removal soon after your merge < mclasen> to maximize the breakage in one sucky day < Company> sounds like a plan < mclasen> ok, my other point for misc < mclasen> is that I wanted to point out that we have asychronous error traps now < mclasen> which is kinda cool < mclasen> not sure if people have followed that work in git < Company> nope < mclasen> to make use of it, you have to use gdk_error_trap_pop_ignored() < mclasen> and remove the sync or flush calls you might have around your current pop call < mclasen> anyway, thats all I had < mclasen> endmeeting ? < ebassi> fine by me < mclasen> thanks, everybody * mclasen goes to look for food < ebassi> thanks for attending < ebassi> minutes on gtk-devel-list ASAP < ebassi> next meeting: October 5th, two weeks before the hackfest