1 < ebassi> as usual, the agenda is at: http://live.gnome.org/GTK%2B/Meetings 2 < ebassi> • how to deal with gtk-requiring libraries, with regards to the API/ABI break 3 < ebassi> • GApplication and GtkApplication 4 < ebassi> • review GBinding 5 < ebassi> • review GController/GObject::thaw-notify 6 < ebassi> • Editable label: sub-class or class feature+ABI break? 7 < ebassi> • get rid of GtkProgress 8 < ebassi> • deprecation of gtk_quit_add_full() to remove GtkArg 9 < ebassi> other items? 10 * mclasen had one 11 * mclasen thingks 12 < mclasen> ah right 13 < mclasen> fixing up distcheck 14 < mclasen> I was trying to get a release out today, but got stuck on that old 'someone else committed during my distcheck' 15 < mclasen> so I want to finally figure out how to make distcheck not touch any files under source control 16 < walters> (cd ..; git clone gtk+ gtk-distcheck; cd gtk-distcheck; make distcheck) ? 17 < walters> really, tarballs should be built automatically on gnome servers, and not from developer machines 18 < leio> as long as said gnome servers don't have broken intltool versions on them like various maintainers do have a lot 19 < walters> (and eventually turned off once operating system builders have better version control based tools) 20 * jjardon thinks that the new admin will have a lot of work to do 21 < mclasen> walters: the problem is that currently make distcheck touches files that I have to commit to get a tag on the tarball contents 22 < walters> mclasen: yeah, my first command suggestion would work around that 23 < mclasen> walters: I don't know how 24 < walters> er...wait maybe not 25 < walters> nevermind =) 26 < mclasen> it doesn't address the 'get the tag on the contents' part 27 < mclasen> the only alternative would be to create a small branch for each release 28 < mclasen> and merge it back afterwards 29 < mclasen> but then the tag sits on that branch, not on master 30 < mclasen> so fixing distcheck would be better, I think 31 < mclasen> not much to discuss here, though. I just need to figure out file-by-file why it is touched 32 < chpe> the biggest problem is that it updates the po files, isn't it? intltool's Makefile.in.in used to have that problem too, but it was fixed not to 33 < mclasen> the biggest headache is the old copy of po/Makefile.in.in that we have 34 < mclasen> which has an update-po in make dist 35 < mclasen> for I don't know what reason 36 < mclasen> thats all tangled up with glib-gettextize vs upstream gettext and has a long histroy 37 < jjardon> someone suggest that we should switch to upstream gettext, instead glib-gettextize, but maybe this is OT 38 < mclasen> proposing that is easy 39 < mclasen> someone needs to do the work... 40 * mclasen attends to his other meeting for a minute 41 < ebassi> it would be good to have at least a list of requirements; I might give it a go 42 < jjardon> ebassi, I think the proper solution is port glib-gettextize to upstream gettext 43 < jjardon> as lots of projects are using glib-gettextize now 44 < ebassi> I'm afraid I'm going to get saddled with gettext itself :-/ 45 < ebassi> but it would also be good to see if glib-gettext can be fixed not to make our lives miserable by default - since we control it 46 < mclasen> anyway, lets move on; I'll work on fixing up distcheck for the release I still want to do today 47 < ebassi> okay; second point: how to deal with libraries depending on gtk 48 < ebassi> so, as a maintainer of a library indirectly depending on gtk+ -- what happens with gdk-pixbuf in gtk 3.0? 49 < ebassi> has it been renamed to gdk-pixbuf-3.0? 50 < mitch> it becomes gdk-pixbuf-3.0 51 < mitch> it must, there is no other way 52 < mclasen> it has been renamed, yeah 53 < ebassi> okay, so we'll need clutter to depend on that 54 < ebassi> no problem 55 < mclasen> alternatives would have been to move it out or to radically rewrite it on top of cairo (like some people want) 56 < leio> moving it out would be nice for some wanting to use the librsvg gdk-pixbuf module without gtk+ on a server setup. We've had such a request 57 < ebassi> move it out would make my life much easier 58 < walters> the libraries-depending-on-gtk+ seems to subdivide into libraries which expose GTK+ APIs publicly versus those that don't 59 < walters> clutter is the latter right now 60 < ebassi> yep 61 < mitch> ebassi: clutter also needs a new library name then, or everything will break 62 < ebassi> clutter-gtk will bump up to gtk+ 3.0 63 < ebassi> mitch: ugh 64 < mitch> it doesn't matter if it's exposing api or not, it *must* be a new library 65 < mitch> or you get distros into hell 66 < mclasen> the problem is linking, not api 67 < mitch> exactly 68 < jjardon> ebassi, clutter-gtk3 ? 69 < walters> maybe the best thing with gdk-pixbuf is to keep it as is and have any radical rewrite use new symbols 70 < ebassi> jjardon: no, clutter-gtk 1.0 71 < ebassi> walters: we might move it to an internal copy 72 < jjardon> ebassi, the new name, I mean 73 < mclasen> do we have a volunteer to work on standalone gdk-pixbuf ? 74 < ebassi> jjardon: no, the new name would be clutter-gtk 1.0 :-) 75 < jjardon> okis ;) 76 < ebassi> mclasen: I'll talk with my manager and see if I can get team time to work on it (and fix it, while we're at it) 77 < ebassi> it's something we wanted to do anyway 78 < mclasen> nice, thanks 79 < mclasen> but even with gdk-pixbuf out of the way, there's still plenty of libraries that will have to do the abi jump with us 80 < jjardon> we can say in the minutes that It's planned, if someone makes the work 81 < jjardon> maybe someone more is interesed in working on it 82 < ebassi> mclasen: we need to communicate this on desktop-devel or desktop-announce 83 < mclasen> yes 84 < mclasen> rpm -q --whatrequires "libgtk-x11-2.0.so.0()(64bit)" | grep "^lib" | wc -l 85 < mclasen> -> 26 86 < mitch> we knew that from the start, so let the whining begin :P 87 < mclasen> right, its nothing new 88 < mclasen> just something to remind people of 89 < mclasen> of those 26 I found, some 5-6 are obsolescent anyway 90 < walters> mclasen: you probably want to use repoquery --whatrequires libgtk-x11-2.0.so.0 | grep '^lib' since the former will only list things you have installed, right? 91 < walters> (61 here on f13) 92 < mclasen> walters: yeah, but my install is not minimal by any measure... 93 < jjardon> maybe a good GnomeGoal? 94 < mclasen> not really, I don't think 95 < ebassi> jjardon: no 96 < ebassi> it's limited in size, but not limited to the GNOME platform 97 < jjardon> well, we can make the GnomeGoal for GNOME. Other libraries can take a look to the GnomeGoal for help about the transition 98 < jjardon> or we can create a GtkGoal instead :P 99 < jjardon> the idea is to have a list to track the progress of the most important libraries. And to have all the info in the same place 100 < mclasen> the right decision for each library may be different 101 < mclasen> for some it maybe best to just leave them in gtk2.x land 102 < mclasen> and port apps away to newer gtk apis 103 < mclasen> anyway, I'll draft a mail on this topic for gtk-devel-list/desktop-announce-list 104 < mclasen> should we move on? 105 < ebassi> sure 106 < ebassi> GApplication and GtkApplication 107 < walters> so they were merged, but there's still work to do, which i am doing as we speak 108 * davidz sent some feedback to walters and mclasen in private 109 < mclasen> I merged them now since I didn't get much feedback on the list last week 110 < walters> the biggest outstanding thing is still a prototype win32 or os X backend, but there is some debate about how that should work nwo 111 < mclasen> and promptly got a lot of feedback in bugzilla 112 < ebassi> yup; I also have a proposal for multi-windows applications; will open a bug with a patch 113 < mclasen> so thats good, on some level, I guess 114 < davidz> in particular I'm concerned that about the scope - it sounds like it's only intended for Gtk and Mx 115 < mclasen> ebassi: have you seen what I added last week, add_window ? 116 < davidz> in which case GApplication shouldn't be instantiable e.g. 117 < walters> well...if we made dbus work in the legacy unix contexts it could be useful 118 < ebassi> mclasen: yes; I still think that we should allow overriding create_window() 119 < walters> primarily in ssh 120 < walters> ebassi: no objections to that 121 < ebassi> mclasen: well get_window() → get_default_window(), add create_window() 122 < ebassi> the first window added using add_window() will become the default one 123 < mclasen> davidz: one concern is that you don't expect commandline stuff or daemons to show up in your application menu 124 < mclasen> but I guess, since they are never 'active' in a shell sense, that wouldn't happen anyway 125 < davidz> mclasen: hah! - that's a cheapshot... 126 < davidz> one question I asked is whether GApplication should be used for, say, gnome-user-share 127 < davidz> e.g. a session-based headless daemon 128 < davidz> we don't have to decide on that right here right now 129 < davidz> but the docs should be very clear about this 130 < davidz> also 131 < davidz> the failure mode should be brutal if people are doing it wrong 132 < davidz> e.g. maybe it's fine that GApllication is only useful for UI apps... in which case the failure mode should be that we abort() if there's no UI server (e.g. no X server) 133 < davidz> in which case making GApplication instantiable is not a good idea 134 < davidz> anyway 135 < davidz> I felt a want for design docs on that level 136 < davidz> when I looked at it 137 < davidz> it's not at all clear to me how and when GApplication should be used 138 < walters> if you don't know, don't use it? 139 < davidz> that's not a very compelling answer 140 < walters> the main problem is inability to guarantee any kind of semantics 141 < walters> mainly because of the concept of linux distributions 142 < davidz> that's not really the point 143 < leio> How does it all interact with the same program being ran on the same computer, but locally and over remote X (ssh forwarding), in particular can applications decide if they want it to be X client unique, or X server unique 144 < davidz> you can make it as narrow or as wide as you want - but please just make it apparent when reading the docs 145 < walters> okay, i'll add something to the docs 146 < walters> anything else? 147 < davidz> thanks 148 < davidz> well, there are some other practical issues in my mail 149 < davidz> I'll just file that in bugzilla 150 < mclasen> biggest concern from my side is that we still lack implementations for win32 or os x 151 < walters> yeah 152 < mclasen> and, from looking at http://live.gnome.org/TwoPointThirtyone/PortabilityMatrix 153 < walters> there are two parts - i know we can do uniqueness and arg passing on both 154 < mclasen> just merging it is no guarantee of an implementation showing up 155 < walters> the question mark is _add_action 156 < ebassi> walters: I've followed the discussion with chpe 157 < mclasen> secondary concern is figuring out some of the scope questions that david raised, e.g. do we want/need session management in GtkApplication 158 < walters> which? 159 < ebassi> walters: the one on bugzilla 160 < walters> david was only talking about GApplication 161 < walters> ebassi: there were several =) 162 < mclasen> oh right 163 < ebassi> walters: bug #620957 164 < ebassi> I think the biggest question about the action support is that we need some design on the interaction model 165 < ebassi> what can and cannot be done 166 < ebassi> apart from the wiki page for gnome-shell, I haven't seen much 167 < davidz> mclasen: well, there are really two concerns here 168 < davidz> mclasen: first, both headless and UI programs often need several "Application Services".. such as inhibiting the screensaver or the PM and so on.. it would be nice to at least be able to add it to something like GApplication at some point in the future... I don't know 169 < davidz> mclasen: the second is that of documentation and failure modes... we've learned the very hard way what disasters can happen if people use D-Bus-using libraries in the wrong way 170 < davidz> mclasen: here I'm talking about GIO/gvfs 171 < davidz> and the auto-spawning of session bus instances and all that 172 < davidz> and the auto-spawning of session bus instances and all that 173 < jjardon> about session managment: hp said: https://bugzilla.gnome.org/show_bug.cgi?id=79285#c26 174 < davidz> so from a practical point of view it would be nice to have a story for developers 175 < davidz> so they know what APIs to use and when to use it 176 < davidz> instead of undocumented APIs leaving people to guess whether to use it or not 177 < mclasen> since gdbus doesn't do autolaunching, we're safe for now, right ? 178 < walters> this is the second time you've mentioned that 179 < walters> i will again mention i will add something to the docs 180 < mclasen> undocumented is a bit harsh, anyway 181 < davidz> mclasen: gdbus will probably need to do autolaunching 182 < walters> ebassi: so...what can and cannot be done from the perspective of an app author? 183 < davidz> sorry if I'm being too harsh 184 < ebassi> walters: multiple action groups? what is the smallest subset of features that can be reasonably portable? 185 < ebassi> walters: also, how does this map to the main menu that a quartz GtkApplication would support? 186 < ebassi> walters: does the gnome-shell decide what to put in the application menu, or applications are supposed to tag the actions that should go in it, on the gnome platform? 187 < walters> ebassi: quartz - i believe they have an API that just exports a GtkMenu; we could just export that under #ifdef GDK_WINDOWING_QUARTZ as gtk_application_set_menu() i guess 188 < walters> ebassi: the basic idea is apps have an action group with their app-global stuff and we export that as best we can everywhere 189 < jjardon> Here the code of ige-mac-integration: http://github.com/jralls/ige-mac-integration/tree 190 < mclasen> exporting widgets like that is just icky, I don't like it at all 191 < ebassi> walters: sounds reasonable; though I expect people will start asking for that API on linux as well, for embedding the app menu somewhere else 192 < ebassi> anyway, we can worry about that when we start receiving odd patches ;-) 193 < leio> silence, next topic? 194 < ebassi> right, if nothing's left for application, there's gbinding 195 < ebassi> (exo-like binding between object properties, for people that don't follow twitter) 196 < ebassi> https://bugzilla.gnome.org/show_bug.cgi?id=348080 197 < mclasen> I don't follow twitter - what are concrete uses for this facility ? 198 < ebassi> mclasen: evo and other apps are already using copy-and-paste API similar to it 199 < ebassi> evo and gedit and seahorse, according to the bug 200 < ebassi> it's also similar to the GSettings binding API 201 < ebassi> it can be used to link two widgets for sensitivity, or two adjustments with a conversion function 202 < mitch> gimp has that for 5 years or so ;) 203 < mitch> ehm 204 < mitch> it should clearly become part of gobject 205 * mclasen has not looked at the patch in detail 206 < mclasen> but it seems fairly obvious; we have several users, we have a working patch, it has docs, and tests 207 < ebassi> the latest patch moves it from gio to gobject, and adds documentation 208 < mclasen> docs still say "since GIO 2.26" in places 209 < ebassi> ugh, right - will fix that 210 < mclasen> so, I think this should go in; any other opinions ? 211 < ebassi> seems not :-) 212 < mclasen> is there ever a case where you want to bind multiple properties at the same time ? 213 < bratsche> Wouldn't you want to do that for linking properties in a compound widget or something? 214 < ebassi> mclasen: you can create multiple bindings 215 < bratsche> Or maybe the child widgets would be reflecting the property of the container widget, I dunno. 216 < mclasen> yeah, I guess having them in on binding would just be a minor optimization 217 < ebassi> but since property notification is expensive, we're down to the next item -- add GObject::thaw-notify signal, to allow bulk notification :-) 218 < ebassi> https://bugzilla.gnome.org/show_bug.cgi?id=617446 219 < mclasen> I'm not 100% clear on how that avoids the overhead 220 < mclasen> thaw-notify is only emitted if there's more than one notify queued up, right ? 221 < ebassi> mclasen: you get a single signal instead of N 222 < mclasen> so how do you catch the individual updates that might also happen to properties you are interested in ? 223 < mclasen> don't you have to listen for notify after all, anyway ? 224 < ebassi> mclasen: it is emitted - in the current incarnation - whenever the notification queue is thawed last 225 < mitch> i was just wondering the same 226 < ebassi> mclasen: the idea is that you don't listen to ::notify if you're interested in many properties 227 < mitch> so you simply want GObject::dispatch_properties_changed() to be a signal? 228 < mclasen> but then you loose ::notify emissions that are not batched ? 229 < ebassi> mclasen: no, you still get those even when n_pspecs == 1 230 < ebassi> mitch: yes, thaw-notify is essentially the signal form of dispatch_properties_changed() 231 < mclasen> oh, I see 232 < mitch> that makes sense 233 < mclasen> the name mislead me into thinking it was only emitted for freeze/thaw pairs 234 < mclasen> bad name... 235 < ebassi> yeah, I realize that :-) 236 < mitch> why not simply "properties-changed"? 237 < ebassi> mitch: that might work 238 < mclasen> actually, rays comment is in that vein too 239 < mclasen> just the implementation ends up working differently 240 < mitch> or *actually* a signal emission on the topmost freeze/thaw pair might be useful too 241 < mitch> listeners might want to stop doing stuff on freeze() and resume on thaw() 242 < mitch> theoretically speaking, i have no real use case in mind, given everything is within one call tree here 243 < mclasen> that sounds like adding more overhead, instead of avoiding overhead..., 244 < mitch> yeah maybe ;) 245 < mitch> the problem here might be that sometimes the order of properties matters, but that's up to the listener then 246 < mitch> they can choose to connect to notify anyway 247 < mitch> hm no ignore me, thaw fucks up the order anyway 248 < ebassi> well, the order would be the same as the one you get ::notify emissions 249 < mitch> really? 250 < mitch> um 251 < ebassi> mitch: if you exclude the duplicates 252 < mitch> sure 253 < ebassi> the reasoning behing bulk notification is for libraries that use a lot of properties that change in block - like clutter :-) 254 < ebassi> but since the only way to get bulk notification is to override dispatch_properties_changed, it can only be done in sub-classes of GObject 255 < mitch> we do that in gimp a lot 256 < mitch> well s/a lot/in one or two places/ ;) 257 < jjardon> ebassi, just curious, Did you do any performance test? 258 < ebassi> yeah; allocation in Actor notifies 5 properties in the worst case; animations are pretty bad as well 259 < mitch> GtkAdjustment does that too now 260 < ebassi> jjardon: we did profiling and if you start animating, you can see it on sysprof 261 < mclasen> ebassi: and that (requiring subclassing) is the motivation for this signal addition? 262 < ebassi> jjardon: no micro-benchmarking for stress-testing 263 < ebassi> mclasen: yes, mostly; we don't have a GtkObject at the bottom of our class hierarchy 264 < mitch> would that signal get the same array of properties as dispatch_properties_changed()? 265 < ebassi> mitch: yes 266 < ebassi> it's a concentrated notify emission 267 < mitch> the longer i thnk about it the more often i have worked around exactly that problem using dispatch_properties_changed() in a subclass 268 < mitch> i think that signal makes sense, given that signals with no listeners are essentially nops 269 < mclasen> are they ? 270 < mitch> iirc they are 271 < mitch> aren't they? :) 272 < mitch> timj to the rescue 273 < mclasen> I believe various patches to that effect were rejected as micro-optimization 274 < mitch> heh 275 < mitch> so if this new signals involves yet another motex lock/unlock we should indeed maybe think twice 276 < mitch> mutex* 277 < mitch> gah 278 < mclasen> the patch looks like context->dispatcher really wants to be the default handler for thaw-notify 279 < mclasen> but I'm sure there's complications that prevent that... 280 < tadeboro> http://git.gnome.org/browse/glib/tree/gobject/gsignal.c#n2879 281 < tadeboro> Looks like there are some optimizations inside signal emission machinery. 282 < mitch> doesn't look like a nop to me 283 < mclasen> still a lock there, though 284 < mitch> yeah 285 < mclasen> hard to avoid though 286 < mitch> unavoidable for looking up the signal i guess 287 < ebassi> the unlocks are all over the place 288 < mclasen> we do lockless lookup of interfaces now, though ? 289 < ebassi> yep 290 < mclasen> any other topics ? 291 < ebassi> editable label: sub-class or not? 292 < ebassi> the sub-class idea was due to the "we can't break ABI and we're out of slots on LabelClass" 293 < ebassi> I guess now we can simply extend that 294 < mclasen> I must admit I never fully grokked the idea of an editable label as a widget 295 < mitch> haha i agree 296 < mclasen> isn't that just a notebook with a label and an entry ? 297 < mitch> it's a WTF 298 < ebassi> well, nautilus has them to rename files :-) 299 < ebassi> it's a bit ad hoc, though 300 < mitch> ebassi: aren't these tree rows? 301 < ebassi> no 302 < ebassi> in icon view 303 < ebassi> not in list view 304 * mclasen has done a lot of label + editable widget in a notebook in the accountsdialog 305 < jjardon> It's needed to replace EelEditableLabel: Its one of the items of ProjectRidley: http://live.gnome.org/ProjectRidley 306 < mclasen> it can be tricky sometimes to get focus handling right 307 < ebassi> jjardon: yep, EelEditableLabel is what nautilus is using (in tree) 308 < jjardon> bug here: https://bugzilla.gnome.org/show_bug.cgi?id=310693 309 < ebassi> dunno if there are other projects using it, though 310 < mclasen> I would invite anybody to study the accountsdialog set of label-that-turns-into-entry, label-that=turns-into-button, label-that-turns-into-combo 311 < jjardon> cosimoc offered to make a patch if an implementation was decided here 312 < jjardon> mclasen, yeah It's pretty cool ;) 313 < mclasen> so, I'd be more interested in investigating if there is a more general pattern of editable-uneditable widget that we can support, instead of just copying eeleditablelabel 314 < garnacho> I wonder if it doesn't make more sense to make it the other way around, a non-editable entry that looks like a label 315 < mclasen> the thing is that label and entry have distinct feature sets 316 < mclasen> there's a big overlap, certainly 317 < mclasen> but there is also a difference 318 < garnacho> I see, should check the use cases 319 < mclasen> labels do urls, they can or cannot be selectable, they can wrap,.. 320 < mclasen> entries can be invisible, they can show icons, they can not wrap, etc etc 321 < garnacho> a GtkLabel subclass makes sense then 322 < mclasen> what will that class do ? reimplement gtkentry ? 323 < ebassi> and in case of word wrapping, does it become a text area? :-) 324 < jjardon> There is already a patch here: https://bugzilla.gnome.org/show_bug.cgi?id=310693#c10 325 * mclasen will put his thoughts in that bug 326 < leio> the agenda topic seemed to be whether the feature should be in a sub-class, or directly inside GtkLabel with an ABI break (due to GtkLabelClass being out of padding) 327 < mclasen> any other topics ? 328 < leio> <ebassi> • get rid of GtkProgress 329 < leio> <ebassi> • deprecation of gtk_quit_add_full() to remove GtkArg 330 < mclasen> right, gtkprogress 331 < mclasen> I wrote a patch one evening last week that strips out GtkProgress 332 < jjardon> bug and patch here: https://bugzilla.gnome.org/show_bug.cgi?id=620618 333 < mclasen> and moves enough pieces into GtkProgressBar to make the non-deprecated functionality work 334 < mclasen> took a few hours, but wasn't as hard as I thought 335 < mclasen> it is obviously not abi compatible 336 < mclasen> but other than that, it works fine 337 < mclasen> I just wondered what people's thoughts are on that ? should I just commit it ? 338 < ebassi> ship it, it's done :-) 339 < leio> so no sharing with GtkEntry progress stuff? 340 < leio> (interface) 341 < jjardon> well, It's for GTK+3, is abi compatibily required? 342 < mclasen> leio: there was never any sharing with the entry progress stuff, api wise 343 < ebassi> leio: there's no real common interface anyway - unless you want to a) add a GtkProgressable interface b) deprecate the whole overlapping GtkProgressbar and GtkEntry API and c) implement the interface 344 < mclasen> the drawing is shared, of course 345 < ebassi> which would be still fill odd anyway 346 < leio> feels similar to GtkOrientable, sort of 347 < bratsche> I think right now if there is no text in the GtkProgressbar it's still full-height.. I'd kind of like to change it so that it's shorter/thinner when there is no text in it. 348 < bratsche> (at least, I think this is how it works right now) 349 < leio> GtkProgressBar is a non-editable GtkEntry with no text in it *grin* 350 < mclasen> it is shorter/thinner 351 < leio> except there is a label. Anyway, considered, decided, then GtkProgress is not useful if not serving an interface 352 < mclasen> ok, cool 353 < bratsche> Oh, then I'm just smoking crack I guess. 354 < mclasen> deprecation of quit_add_full - last point 355 < jjardon> yeah, I asked murray about it. He commented in the bug 356 < jjardon> pygtk uses that function, but GI based bindings no 357 < mclasen> in an essential way, or easily avoidable ? 358 < mclasen> I would assume the essential point is that bindings need a destroynotify 359 < jjardon> murray words: <murrayc> jjardon: *_full() functions are generally needed to maintain state, by associating user_data with a callback function. Bindings and well-written apps do need that, yes. 360 * mclasen needs to run out 361 < mclasen> your conclusions on a postcard... 362 < mclasen> later 363 < ebassi> ugh 364 * ebassi just saw GtkArg for the first time 365 < jjardon> ebassi, Do you know anything about the perl case? 366 < jjardon> :) 367 < jjardon> I saw that current perl bindings use that functions one time. But the GI based no 368 < jjardon> oh, here is the bug with the murray comment: https://bugzilla.gnome.org/show_bug.cgi?id=619671 369 < ebassi> jjardon: perl-Gtk2 binds it 370 < ebassi> but we don't use it in code 371 < ebassi> so, since perl-Gtk2 binds gtk+-2.0, it's not a big deal 372 < ebassi> and as soon as we switch over to GI, it's not going to be a problem ever again 373 < jjardon> indeed, It's only used here: http://git.gnome.org/browse/perl-Gtk2/tree/xs/Gtk2.xs#n491 374 < jjardon> and here in gtkmm: http://git.gnome.org/browse/gtkmm/tree/gtk/src/main.ccg#n252 375 < jjardon> the problem is that gtkmm bindings are not GI based (for now) 376 < ebassi> so, dunno; at this point, should we rename the function? break it without pity since it's fairly unused? 377 < ebassi> jjardon: gtkmm will have to bump up anyway 378 < jjardon> yeah, or maybe use GCallback instead GtkCallbackMarshal 379 < jjardon> in these functions 380 < jjardon> as murray suggest in the bug report 381 < ebassi> sounds reasonable to switch to GCallback and let GtkCallbackMarshal die a painful death 382 * tadeboro rather goes directly to hell that being listed on ebassi's deprecation list ... 383 < ebassi> right, so we can adjurn the meeting 384 < jjardon> ok, Is there time for leio concerns about performance? 385 < ebassi> oh, right 386 < ebassi> though we have hit the 2:30hrs mark 387 < leio> I'm not personally prepared to argue any counter arguments, so some "unofficial" chatter is fine 388 < ebassi> okay; I can still put it in the minutes - it's up to you 389 < leio> jjardon should have a link to some March meeting about function calls vs direct access stuff with some options on how to proceed. Trying to find the right place 390 < leio> http://live.gnome.org/GTK%2B/Meetings?action=AttachFile&do=view&target=20100323.txt 391 < jjardon> one moment, let me check 392 < leio> 21:50 393 < leio> in the raw log 394 < leio> so, basically I'm saying what desrt said there. I see no reason to go with slower (doing accessor function calls for things that are available internally directly) 395 < leio> just put the private structures in a foo-private.h header instead of on the top of the *.c and don't install it 396 < ebassi> one of the options was: add a macro that expands to a direct access when GTK_COMPILATION is defined, and to a function if not 397 < ebassi> though, obviously, it would be good to have numbers before making the build even more hacktacular than it is 398 < ebassi> (not that I don't doubt that function call + argument type checking > direct access 399 < ebassi> in terms of time, obviously) 400 < leio> argument type checking is quite expensive, for example gstreamer is going out of its way to do direct casts when it knows it's correct, saving tens of percentage of instructions in the process 401 < ebassi> still, internally, the compiler could do tricks; and we could have the cross-file boundary inlining at some point 402 < leio> is GTK+ already using function calls internally, or that is one of jjardon's gsoc projects? 403 < ebassi> leio: for things that are exposed publicly, we use the public accessor internally as well 404 < leio> because if it isn't already using function calls internally, it's probably easier to spread some ->priv around rather than converting to public accessors 405 < jjardon> I added some internal functions functions, but without type checking 406 < leio> I'm not sure what build hacks would be involved here 407 < ebassi> right - internal functions should not have type checking 408 < ebassi> the idea is that if you take out some code from gtk+ it won't blow up in your face; and even internally, the code won't become a tangled mess of direct accesses to private structures 409 < ebassi> which is the biggest risk as soon as you start making Private data structure project-wide 410 < leio> I've never heard or read about the GTK_COMPILATION idea before, but it sounds neat, albeit probably can be considered a build hack 411 < ebassi> leio: it might probably rate lower on the build hacks scale than, say, the aliasing stuff ;-) 412 < ebassi> anyway, it's a good discussion that should be brought up on the mailing list 413 < leio> I do not have the time resource right now to do any concrete measuring of how much slower it is, I think this should definitely have been done BEFORE making it obviously slower - measure if it's not measurable 414 < jjardon> yeah, but thinking more on this, waht id the advantage of _gtk_accesible_set_widget (a, w) over a->priv->widget = w ? 415 < leio> yeah, jjardon suggested in a meeting :P 416 < ebassi> leio: since people have gone offline, and since we probably need more bandwidth, the mailing list is usually the next step 417 < ebassi> leio: it's much appreciated, though 418 < leio> agreed 419 < jjardon> <jjardon> leio, I already ported some widgets. I'd suggest you to sent a mail to gtk-devel-list if you can't attend :P 420 < ebassi> we've had this discussion on IRC, in various shapes and forms 421 < leio> gtk-2-90 is in master now? 422 < jjardon> leio, I'm pushing my work here: http://gitorious.org/gtk3/gtk/commits/refactor 423 < ebassi> leio: yes 424 < jjardon> leio, gtk-2-90 is obsolete now 425 < jjardon> It was merged in master some time ago 426 < leio> looks like even GtkWidget code itself internally does gtk_widget_get_realized function calls with type checking all over the place 427 < ebassi> leio: yep 428 < leio> anyway, I think this is not for the meeting channel anymore 429 < leio> as we didn't have time :) 430 < ebassi> okay; leio: thanks for the patience :-) 431 < ebassi> next meeting in two weeks 432 < ebassi> good night everyone; will send the minutes soon
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.