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