1 < ebassi> as usual, the agenda is at: http://live.gnome.org/GTK%2B/Meetings 2 < ebassi> • GTK3 cleanup tasks 3 < ebassi> ‣ GtkObject deprecation / removal (bug: 615666) 4 < ebassi> ‣ gtk_widget_hide_all deprecation / removal (bug: 438318) 5 < ebassi> ‣ uri hooks cleanup (bug: 339745) 6 < ebassi> ‣ remove notebook unneeded code (bug: 96834) 7 < ebassi> ‣ GTK_POLICY_AUTOMATIC as default (bug: 468672) 8 < ebassi> ‣ Since tags 9 < ebassi> • coding style conventions 10 < ebassi> • miscellaneous 11 < ebassi> right, should we start? 12 < mclasen> sure 13 < ebassi> first item, clean up tasks: GtkObject deprecation 14 < mclasen> this came in the context of dealing with widget flags 15 < mclasen> and I proposed that instead of continuing to deal with the split in gtkobject and gtkwidget 16 < mclasen> we should just ditch gtkobject 17 < mclasen> which is a bit of work, but doable; I have have branch that does it 18 < mclasen> it moves the destroy signal into gtkwidget, and makes all other gtkobject derived classes ginitiallyunowned derived 19 < ebassi> Clutter used InitiallyUnowned as the base class, and we haven't had any issues 20 < mclasen> I also have untested patches for some 20 gnome modules to remove gtkobject uses 21 < mclasen> most of them trivial, the only non-widget use of destroy functionality 22 < pbor> is there anything that uses destroy that is not a widget? 23 < mclasen> is in gnomecanvas / eelcanvas 24 < mclasen> which I solved by simply duplicating the destroy signal in the canvasitem class 25 < pbor> can someone remind me what is difference between using destroy and using dispose? 26 < ebassi> pbor: not much 27 < mclasen> destroy is a signal 28 < mclasen> dispose is not 29 < mclasen> destroy gets emitted when you dispose a gtkobject 30 < ebassi> mclasen: and generally nobody implements the destroy vfunc 31 < mclasen> yeah, it is not very consistently implemented 32 < mclasen> so, I basically just wanted to get some feedback if people think this is generally a good idea 33 < mclasen> then I am ready to go forward with this, merge the branch and file all my patches 34 < ebassi> mclasen: I see no problem 35 < pbor> what is the alterantive of connecting to destroy? weakref? 36 < mclasen> yeah, something like that 37 < mclasen> but, as I said; there's damn few non-widget users of destroy 38 < pbor> I am all for ditching gtkobject, my question is if we should ditch/deprecate the destroy signal altogether 39 < mclasen> and for widgets, destroy will not change 40 < ebassi> I think mitch had some ideas wrt the base class - at least we discussed this ages ago. but he's not here :-) 41 < ebassi> pbor: a lot of code relies on the ::destroy signal 42 < Company> mclasen: did you investigate getting rid of destroy for anything but windows? 43 < ebassi> pbor: for 4.0 we might move to weak pointers and weak-ref :-) 44 < mclasen> Company: yes, my gtkobject-removal branch does that 45 < mclasen> Company: oh, windows 46 < mclasen> no 47 < pbor> ebassi: sure, that's why I said "deprecate" 48 < Company> mclasen: you looked at the code, so you'd know if that'd be a useful idea 49 < Company> mclasen: but i think we have generally way too much API attached to GtkWidget that'd be way better placed at GtkWindow 50 < 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) 51 < mclasen> well, the usage is certainly 90% on dialogs and menus 52 < Company> pbor: that's page-removed ;) 53 < Company> i don't know so i have no opinion 54 < Company> it's just gut feeling that window is a good idea 55 < mclasen> I'll have a look at it again when I file the patches 56 < mclasen> for now I'll leave it on widget, I guess 57 < pbor> not that I think it is a reason to hold back, but what happens to widget sublasses that implement gtkobject->destroy? 58 < pbor> do they need to ifdef gtk 2/3 59 < pbor> or is there some kind of hack possible? 60 < Company> ifdef 61 < mclasen> no 62 < mclasen> well, yes 63 < mclasen> they need to either set object_class->destroy or widget_class->destroy 64 < Company> you can do a DESTROY_SIGNAL cast or sth of course 65 < pbor> #define GtkObject GtkWidget :) 66 < Company> not a bad idea 67 < ebassi> typedef GtkWidget GtkObject 68 < ebassi> typedef GtkWidgetClass GtkObjectClass 69 < Company> i think in general apps should stop trying to compile the same code against gtk2 and gtk3 70 < ebassi> post-2.32, I agree 71 < Company> they should track gtk2 now 72 < Company> and convert to GTK3 after 2.32 has branched 73 < Company> the mutter fixup for rendering-cleanup was painful 74 < mclasen> agreed 75 < mclasen> anyway, next topic ? 76 < Company> and mutter doesn't even really use GTK 77 < mclasen> unless somebody has more opinions on gtkobjects fate 78 < pbor> I agree, but it kinda defeats all the work done until now 79 < pbor> where apps compiling without warnings on 2.32 woudl work with 3.0 80 < Company> we've abandoned that idea anyway 81 < pbor> okay 82 < mclasen> pbor: building without warnings in 2.32 still gets you close to working with 3 83 < Company> we still want minimal changes, but there'll be changes 84 < pbor> yeah, I guess that if the timeline does not slip anymore "close enough" is the best tradeoff 85 < Company> so the upgrade path for your app should be: port to gtk 2.latest, then port to 3.0 86 < ebassi> right, next item: deprecation of GtkWidget.hide_all() 87 < ebassi> +1 from me 88 * pbor never used it, so sounds good :) 89 < ebassi> +2 if that also means removing the hide_all() vfunc 90 < ebassi> +3 if show_all() goes the same way 91 < pbor> show all is kind of useful 92 < mclasen> hide_all is very rare, show_all is very common 93 < Company> ebassi: only f widgets are visible by default 94 < pbor> Company: only if non-toplevel widgets are visible by default 95 < aruiz> mclasen, dunno, it all depends if show_all is common because all objects are hidden by default? 96 < aruiz> if that changes, and people are expect to hide on a case by case basis 97 < Company> pbor: windows are always special 98 < Company> :/ 99 < ebassi> dunno, I show everything by default when adding, and then hide the container 100 < ebassi> but it might be just me - hence my "+3" :-) 101 < ebassi> I'd be happy with just hide_all going the way of the Dodo 102 < pbor> for now I'd just stick to the agenda item, looks like everyone agrees on killing hide_all 103 < mclasen> aruiz: changing the default value of visible to true doesn't work, at least not without redoing quite a bit of gtkwidget internals 104 < Company> hp can do that while fixing event handling! 105 < pbor> yup, default values is another can of worms, also for things like glade 106 < 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 107 < aruiz> unless show_all causes a lot of trouble for maintainers or the flexibility of the codebase 108 < ebassi> we can revisit the visibility issue for 4.0 :-) 109 < ebassi> when we do s/GtkWidget/ClutterActor/g ;-P 110 < Company> yay, no more GDK in GTK4 \o/ 111 < ebassi> if we have general agreement on hide_all() we can probably skip to the URI hook cleanup 112 < Company> go on 113 * mclasen agrees on hide_all removal, fwiw 114 < mclasen> so, uri hook cleanup 115 < mclasen> the bug is about the problems that language bindings have with some of our setCallback / getCallback apis 116 < mclasen> I have written a patch that solves this differently for gtklinkbutton and gtkaboutdialog 117 < mclasen> for aboutdialog, I propose to simply nix the callback 118 < mclasen> to leave room for some override capability, I've added a link-activated signal 119 < mclasen> basically copying what we have in labels for links 120 < mclasen> for gtklinkbutton, I've left the hook in place, but just ditched the 'return the old hook' part, since its unusable for bindings 121 < mclasen> not sure if its worth keeping it, really 122 < mclasen> I could be convinced to just do the link-activated signal there too 123 < mclasen> opinions ? 124 < ebassi> again, +1 on my side on the whole thing - the amount of ad hoc code in bindings is not funny 125 < ebassi> I think the hook should go away in the LinkButton too 126 < ebassi> the LinkButton already has the ::clicked signal, though 127 < Company> yeah, signal and DTRT by default 128 < mclasen> the one argument for the hook is that it lets you override globally, for all link buttons 129 < mclasen> but then, you can just subclass and override the signal 130 < ebassi> yeah, sub-classing is a better option 131 < mclasen> ok, I'll nuke the hook from link buttons as well then. less api ! 132 < ebassi> yey! :-) 133 < Company> you can also add a signal hook to the clicked signal 134 < mclasen> true 135 < ebassi> or override the class handler 136 < ebassi> okay, it's less convenient for the C developer, but hey: if you're using C you should be used to that :-) 137 < mclasen> was there one more cleanup item ? 138 < mclasen> ah, right https://bugzilla.gnome.org/show_bug.cgi?id=96834 139 < mclasen> I don't think this needs to be discussed, really 140 < mclasen> its just removing dead code, just needs a volunteer to write a patch... 141 < Company> write a patch 142 * pbor still hopes that some day an hero comes along and just reimplements notebook from scratch fro gtk7 143 < Company> become #3 code remover 144 < ebassi> bratsche also proposed removing scrolling tabs with the scroll button 145 < Company> pbor: i hope someone writes a really awesome dock that has a notebook as a side effect ;) 146 < mclasen> right, thats more discuss-worthy 147 < Company> i'm for it 148 < 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 149 < ebassi> https://bugzilla.gnome.org/show_bug.cgi?id=630226 -- for reference 150 < bratsche> Oh yeah, thanks ebassi 151 < mclasen> as a compromise, we could make it optional and default-off 152 < Company> pbor: i think most of it was fixed by deprecations later 153 < Company> pbor: i just remember my blog post from back then 154 < bratsche> Yeah, I can change it to be optional and default to off. 155 < mclasen> since tab scrolling may have limited use cases in browser ui, but certainly is wrong in eg preference dialogs 156 < 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 157 < Company> pbor: isn't that a DND failure more than a notebook failure? 158 < pbor> both iirc 159 < mclasen> pbor: if there are concrete change proposals, we can look at it 160 < Company> http://www.advogato.org/person/company/diary/42.html 161 < pbor> mclasen: unfortunately I think there arent, I am simply suggesting to at least take out failed experiments 162 < mclasen> pbor: concrete examples for what you consider failed experiments would be good too 163 < mclasen> I guess some of the things we deprecated in the tab dnd apis should just go away 164 < pbor> mclasen: what Company linked 165 < pbor> yep, that's what I meant 166 < mclasen> right, some of those got addressed 167 < mclasen> but most are still valid 168 < mclasen> I guess I'll have a look at that 169 < mclasen> moving on ? 170 < ebassi> GTK_POLICY_AUTOMATIC as default (bug: 468672) 171 < mclasen> yeah 172 < bratsche> Any resolution on the scrolling? Do I need to change the patch to be configurable? 173 < mclasen> I stumbled over that bug in bugzilla 174 < 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 175 < mclasen> if it involves much fiddling with internals, the option route might be better 176 < Company> i'd say "drop it until someone files a bug, then make it configurable" :) 177 < aruiz> hah 178 < bratsche> Well, someone already filed a bug. That's how we have it in the first place. 179 < 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. 180 < mclasen> so, lets be bold and remove it 181 < 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. 182 < bratsche> Okay, I'll commit that. 183 < bratsche> Thanks. 184 < mclasen> so, moving to the scrollbar policy 185 < mclasen> I stumbled over a bug that proposed to change the default 186 < mclasen> and it made some sense to me 187 < ebassi> mclasen: not being auto by default is what never made sense to me :-) 188 < aruiz> +1 189 < ebassi> so, general consensus is: we switch default to AUTOMATIC 190 < ebassi> (silence implies consent :-)) 191 * mclasen will make it so 192 < ebassi> last item on the "cleanup" list is: Since tags 193 < jdahlin> +1 for automatic 194 < mclasen> the question here is: 1) do we want to nuke all since 2.x tags ? 2) do we need since: 3.0 ? 195 < ebassi> personally, I don't see a problem in keeping them - except if you want to remove the index generation 196 < mclasen> I already removed the indices, I believe 197 < jdahlin> they're useful for stuff like glade, for which you target a specific gtk+ version 198 < mclasen> right, within 2.x 199 < mclasen> but does it make sense to know that an api appeared in 2.27.15 when you are building a gtk3 app ? 200 < jdahlin> maybe glade/gtk3 shouldn't be able to support gtk2 apps 201 < Company> gtk3 glade would have lots of fun displaying gtk2 widgets 202 < jdahlin> dunno, IMHO they're not too much old baggage, don't think its too inconvenient to keep them along 203 < mclasen> no, it is not 204 < Company> i didn't add any since tags though 205 < mclasen> we can certainly keep them around. no big deal 206 < Company> and i didn't update since tags for function prototypes i changed 207 < mclasen> ah, thats a good point 208 < Company> i'd get rid of them because i think they're confusing 209 < Company> also, i can't see anyone porting their apps from 3.0 to 2.22 210 < mclasen> any more opinions ? 211 < mclasen> Company: do you think it is worth keeping the 3.0 annotations ? 212 < mclasen> gives any easy way to see whats new, if nothing else... 213 < Company> dunno 214 < Company> there's "changed api" vs "new api" 215 < Company> i'm not sure if gtk_paint_box() should be "Since: 3.0" 216 < mclasen> no, it shouldn't 217 < Company> it's different from the 2.x version though 218 < Company> no idea really 219 < mclasen> I tend to agree that we should remove the since tags, and start over with fresh since 3.x annotations 220 < mclasen> anyway, lets not waste more time on it and move on 221 < ebassi> given the rationale, yes 222 < ebassi> final point: coding style 223 < ebassi> for the joy of Company :-) 224 < Company> i like the current coding style 225 < mclasen> my proposal is that we basically adopt the clutter document that was pointed out on the list 226 < mclasen> which essentially codifies the currrent gtk style 227 < 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 228 < ebassi> I'll modify the clutter coding style with those as well anyway 229 < aruiz> can anybody paste that link here? 230 < mclasen> and some information about how to handle cleanups of the current code 231 < aruiz> oh found it 232 < ebassi> http://git.clutter-project.org/clutter/tree/doc/CODING_STYLE 233 < aruiz> my only problem with current gtk+ style is the spaces for indentation 234 < Company> which spaces? 235 < aruiz> it basically forces everybody to visualize 2 spaces, whereas tabs are configurable 236 < ebassi> aruiz: cairo uses mixed tabs+spaces 237 < ebassi> aruiz: NOOOOOOOOOOOO 238 < aruiz> Each new level is indented 2 or more spaces than the previous level: 239 < ebassi> changing tabs to be anything bug 8 spaces is *wrong* 240 < aruiz> mixed to aling stuff below another line? 241 < aruiz> or mixed as "free for all"? 242 < ebassi> no: start with tabs and finish with spaces 243 < ebassi> http://cgit.freedesktop.org/cairo/tree/CODING_STYLE 244 < Company> cairo has a coding style document? 245 < Company> interesting 246 < Company> anyway 247 < aruiz> ebassi, I'm not advocating for mixing 248 < ebassi> aruiz: never, ever redefine tabs 249 < aruiz> ebassi, I'm saying we should use tabs for indentation and spaces for alingment 250 < 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 251 < ebassi> it will lead to death, taxes and the end of the universe 252 < 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 253 < pbor> and I really do not see the cost in keeping them 254 < Company> pbor: so what should gtk_paint_box() say in your opinion? 255 < Company> pbor: Since: 2.0, Since: 3.0? Or even Last-Changed: 3.0? 256 < 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..." 257 < 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 258 < 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 :-) 259 < pbor> mclasen: nah, that's too much... if one does the backport he'll have to do his homework 260 < aruiz> so +1 for using the Clutter one 261 < pbor> I just do not see the win in throwing away what is already there 262 < aruiz> ebassi, space indent and the extra indent for the braces really kills me :P 263 < mclasen> was there any opinion on coding style updates for old code ? 264 < Company> yes 265 < Company> don't 266 < aruiz> Company, why? 267 < Company> git blame 268 < aruiz> git history messup? 269 < aruiz> yeah 270 < aruiz> :-) 271 < pbor> well, do if you are changing the code already 272 < Company> right 273 < Company> lines you modify may as well be perfect 274 * aruiz wonders if we can have a git hook for this? 275 < 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... 276 < Company> mclasen: i guess that is fine from a git blame perspective 277 < pbor> should we update the coding style of gtkbtree functions which are still K&R ? :-) 278 < 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 279 < 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 280 < ebassi> and investigate an indent script we can distribute 281 < mclasen> do you have such a beast in clutter ? 282 < ebassi> nope - well, usually it's me, channeling mitch 283 < ebassi> but it should be possible to do 284 < mclasen> hah 285 < ebassi> I'll look into it 286 < mclasen> ok, I guess we should come to an end ? 287 < mclasen> I have to quick notes for 'misc' 288 < Company> i'd like to summarize the soon-to-happen rendering-cleanup landing in master while everyone is listening 289 < mclasen> right, thats my first point... 290 < mclasen> go ahead 291 < Company> rendering-cleanup will land any day now 292 < Company> blocking on some discussion about my mutter patches 293 < Company> it removes GdkPixmap, GdkColormap, and expose-events for gtk_widget_draw() 294 < Company> see the list and the mail i'll send after landing 295 < Company> it also makes GtkSizeRequest part of GtkWidget 296 < Company> so it's a big chunk of API changes 297 < mclasen> and you'll land fixes for mutter / gtk-engines in parallel, right ? 298 < Company> chpe and me have ported some apps/libs already 299 < Company> right, i'll land gtk-engines and mutter at the same time 300 < 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 301 < mclasen> it is probably worth sending a heads-up mail about this in advance, actually 302 < Company> chpe has nautilus, gnome-terminal and dependencies fixed 303 < mclasen> thats good 304 < Company> pbor: will do 305 < mclasen> together with the shell, thats almost a working desktop ! 306 < Company> almost all other apps will go into "broken" state i suspect 307 < Company> assuming they track gtk3 already 308 < chpe> (nautilus is only 'semi-fixed', I still haven't debugged 2 problems :) 309 < Company> and then we'll go around and fix them 310 < Company> as always, if you have questions, poke me 311 < Company> i'm way more excited about fixing stuff people care about than dumping patches in bugzilla that rot there 312 < Company> i also expect this to be the last breakage of this size 313 < mclasen> yeah, we should signal that in your mail 314 < mclasen> I'll try to land my gtkobject removal soon after your merge 315 < mclasen> to maximize the breakage in one sucky day 316 < Company> sounds like a plan 317 < mclasen> ok, my other point for misc 318 < mclasen> is that I wanted to point out that we have asychronous error traps now 319 < mclasen> which is kinda cool 320 < mclasen> not sure if people have followed that work in git 321 < Company> nope 322 < mclasen> to make use of it, you have to use gdk_error_trap_pop_ignored() 323 < mclasen> and remove the sync or flush calls you might have around your current pop call 324 < mclasen> anyway, thats all I had 325 < mclasen> endmeeting ? 326 < ebassi> fine by me 327 < mclasen> thanks, everybody 328 * mclasen goes to look for food 329 < ebassi> thanks for attending 330 < ebassi> minutes on gtk-devel-list ASAP 331 < ebassi> next meeting: October 5th, two weeks before the hackfest
Attached FilesTo refer to attachments on a page, use attachment:filename, as shown below in the list of files. Do NOT use the URL of the [get] link, since this is subject to change and can break easily.
You are not allowed to attach a file to this page.