< ebassi> as usual, the agenda is at: http://live.gnome.org/GTK%2B/Meetings < ebassi> • how to deal with gtk-requiring libraries, with regards to the API/ABI break < ebassi> • GApplication and GtkApplication < ebassi> • review GBinding < ebassi> • review GController/GObject::thaw-notify < ebassi> • Editable label: sub-class or class feature+ABI break? < ebassi> • get rid of GtkProgress < ebassi> • deprecation of gtk_quit_add_full() to remove GtkArg < ebassi> other items? * mclasen had one * mclasen thingks < mclasen> ah right < mclasen> fixing up distcheck < mclasen> I was trying to get a release out today, but got stuck on that old 'someone else committed during my distcheck' < mclasen> so I want to finally figure out how to make distcheck not touch any files under source control < walters> (cd ..; git clone gtk+ gtk-distcheck; cd gtk-distcheck; make distcheck) ? < walters> really, tarballs should be built automatically on gnome servers, and not from developer machines < leio> as long as said gnome servers don't have broken intltool versions on them like various maintainers do have a lot < walters> (and eventually turned off once operating system builders have better version control based tools) * jjardon thinks that the new admin will have a lot of work to do < mclasen> walters: the problem is that currently make distcheck touches files that I have to commit to get a tag on the tarball contents < walters> mclasen: yeah, my first command suggestion would work around that < mclasen> walters: I don't know how < walters> er...wait maybe not < walters> nevermind =) < mclasen> it doesn't address the 'get the tag on the contents' part < mclasen> the only alternative would be to create a small branch for each release < mclasen> and merge it back afterwards < mclasen> but then the tag sits on that branch, not on master < mclasen> so fixing distcheck would be better, I think < mclasen> not much to discuss here, though. I just need to figure out file-by-file why it is touched < 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 < mclasen> the biggest headache is the old copy of po/Makefile.in.in that we have < mclasen> which has an update-po in make dist < mclasen> for I don't know what reason < mclasen> thats all tangled up with glib-gettextize vs upstream gettext and has a long histroy < jjardon> someone suggest that we should switch to upstream gettext, instead glib-gettextize, but maybe this is OT < mclasen> proposing that is easy < mclasen> someone needs to do the work... * mclasen attends to his other meeting for a minute < ebassi> it would be good to have at least a list of requirements; I might give it a go < jjardon> ebassi, I think the proper solution is port glib-gettextize to upstream gettext < jjardon> as lots of projects are using glib-gettextize now < ebassi> I'm afraid I'm going to get saddled with gettext itself :-/ < 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 < mclasen> anyway, lets move on; I'll work on fixing up distcheck for the release I still want to do today < ebassi> okay; second point: how to deal with libraries depending on gtk < ebassi> so, as a maintainer of a library indirectly depending on gtk+ -- what happens with gdk-pixbuf in gtk 3.0? < ebassi> has it been renamed to gdk-pixbuf-3.0? < mitch> it becomes gdk-pixbuf-3.0 < mitch> it must, there is no other way < mclasen> it has been renamed, yeah < ebassi> okay, so we'll need clutter to depend on that < ebassi> no problem < mclasen> alternatives would have been to move it out or to radically rewrite it on top of cairo (like some people want) < 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 < ebassi> move it out would make my life much easier < walters> the libraries-depending-on-gtk+ seems to subdivide into libraries which expose GTK+ APIs publicly versus those that don't < walters> clutter is the latter right now < ebassi> yep < mitch> ebassi: clutter also needs a new library name then, or everything will break < ebassi> clutter-gtk will bump up to gtk+ 3.0 < ebassi> mitch: ugh < mitch> it doesn't matter if it's exposing api or not, it *must* be a new library < mitch> or you get distros into hell < mclasen> the problem is linking, not api < mitch> exactly < jjardon> ebassi, clutter-gtk3 ? < walters> maybe the best thing with gdk-pixbuf is to keep it as is and have any radical rewrite use new symbols < ebassi> jjardon: no, clutter-gtk 1.0 < ebassi> walters: we might move it to an internal copy < jjardon> ebassi, the new name, I mean < mclasen> do we have a volunteer to work on standalone gdk-pixbuf ? < ebassi> jjardon: no, the new name would be clutter-gtk 1.0 :-) < jjardon> okis ;) < 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) < ebassi> it's something we wanted to do anyway < mclasen> nice, thanks < 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 < jjardon> we can say in the minutes that It's planned, if someone makes the work < jjardon> maybe someone more is interesed in working on it < ebassi> mclasen: we need to communicate this on desktop-devel or desktop-announce < mclasen> yes < mclasen> rpm -q --whatrequires "libgtk-x11-2.0.so.0()(64bit)" | grep "^lib" | wc -l < mclasen> -> 26 < mitch> we knew that from the start, so let the whining begin :P < mclasen> right, its nothing new < mclasen> just something to remind people of < mclasen> of those 26 I found, some 5-6 are obsolescent anyway < 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? < walters> (61 here on f13) < mclasen> walters: yeah, but my install is not minimal by any measure... < jjardon> maybe a good GnomeGoal? < mclasen> not really, I don't think < ebassi> jjardon: no < ebassi> it's limited in size, but not limited to the GNOME platform < jjardon> well, we can make the GnomeGoal for GNOME. Other libraries can take a look to the GnomeGoal for help about the transition < jjardon> or we can create a GtkGoal instead :P < 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 < mclasen> the right decision for each library may be different < mclasen> for some it maybe best to just leave them in gtk2.x land < mclasen> and port apps away to newer gtk apis < mclasen> anyway, I'll draft a mail on this topic for gtk-devel-list/desktop-announce-list < mclasen> should we move on? < ebassi> sure < ebassi> GApplication and GtkApplication < walters> so they were merged, but there's still work to do, which i am doing as we speak * davidz sent some feedback to walters and mclasen in private < mclasen> I merged them now since I didn't get much feedback on the list last week < 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 < mclasen> and promptly got a lot of feedback in bugzilla < ebassi> yup; I also have a proposal for multi-windows applications; will open a bug with a patch < mclasen> so thats good, on some level, I guess < davidz> in particular I'm concerned that about the scope - it sounds like it's only intended for Gtk and Mx < mclasen> ebassi: have you seen what I added last week, add_window ? < davidz> in which case GApplication shouldn't be instantiable e.g. < walters> well...if we made dbus work in the legacy unix contexts it could be useful < ebassi> mclasen: yes; I still think that we should allow overriding create_window() < walters> primarily in ssh < walters> ebassi: no objections to that < ebassi> mclasen: well get_window() → get_default_window(), add create_window() < ebassi> the first window added using add_window() will become the default one < mclasen> davidz: one concern is that you don't expect commandline stuff or daemons to show up in your application menu < mclasen> but I guess, since they are never 'active' in a shell sense, that wouldn't happen anyway < davidz> mclasen: hah! - that's a cheapshot... < davidz> one question I asked is whether GApplication should be used for, say, gnome-user-share < davidz> e.g. a session-based headless daemon < davidz> we don't have to decide on that right here right now < davidz> but the docs should be very clear about this < davidz> also < davidz> the failure mode should be brutal if people are doing it wrong < 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) < davidz> in which case making GApplication instantiable is not a good idea < davidz> anyway < davidz> I felt a want for design docs on that level < davidz> when I looked at it < davidz> it's not at all clear to me how and when GApplication should be used < walters> if you don't know, don't use it? < davidz> that's not a very compelling answer < walters> the main problem is inability to guarantee any kind of semantics < walters> mainly because of the concept of linux distributions < davidz> that's not really the point < 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 < davidz> you can make it as narrow or as wide as you want - but please just make it apparent when reading the docs < walters> okay, i'll add something to the docs < walters> anything else? < davidz> thanks < davidz> well, there are some other practical issues in my mail < davidz> I'll just file that in bugzilla < mclasen> biggest concern from my side is that we still lack implementations for win32 or os x < walters> yeah < mclasen> and, from looking at http://live.gnome.org/TwoPointThirtyone/PortabilityMatrix < walters> there are two parts - i know we can do uniqueness and arg passing on both < mclasen> just merging it is no guarantee of an implementation showing up < walters> the question mark is _add_action < ebassi> walters: I've followed the discussion with chpe < mclasen> secondary concern is figuring out some of the scope questions that david raised, e.g. do we want/need session management in GtkApplication < walters> which? < ebassi> walters: the one on bugzilla < walters> david was only talking about GApplication < walters> ebassi: there were several =) < mclasen> oh right < ebassi> walters: bug #620957 < ebassi> I think the biggest question about the action support is that we need some design on the interaction model < ebassi> what can and cannot be done < ebassi> apart from the wiki page for gnome-shell, I haven't seen much < davidz> mclasen: well, there are really two concerns here < 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 < 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 < davidz> mclasen: here I'm talking about GIO/gvfs < davidz> and the auto-spawning of session bus instances and all that < davidz> and the auto-spawning of session bus instances and all that < jjardon> about session managment: hp said: https://bugzilla.gnome.org/show_bug.cgi?id=79285#c26 < davidz> so from a practical point of view it would be nice to have a story for developers < davidz> so they know what APIs to use and when to use it < davidz> instead of undocumented APIs leaving people to guess whether to use it or not < mclasen> since gdbus doesn't do autolaunching, we're safe for now, right ? < walters> this is the second time you've mentioned that < walters> i will again mention i will add something to the docs < mclasen> undocumented is a bit harsh, anyway < davidz> mclasen: gdbus will probably need to do autolaunching < walters> ebassi: so...what can and cannot be done from the perspective of an app author? < davidz> sorry if I'm being too harsh < ebassi> walters: multiple action groups? what is the smallest subset of features that can be reasonably portable? < ebassi> walters: also, how does this map to the main menu that a quartz GtkApplication would support? < 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? < 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 < 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 < jjardon> Here the code of ige-mac-integration: http://github.com/jralls/ige-mac-integration/tree < mclasen> exporting widgets like that is just icky, I don't like it at all < 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 < ebassi> anyway, we can worry about that when we start receiving odd patches ;-) < leio> silence, next topic? < ebassi> right, if nothing's left for application, there's gbinding < ebassi> (exo-like binding between object properties, for people that don't follow twitter) < ebassi> https://bugzilla.gnome.org/show_bug.cgi?id=348080 < mclasen> I don't follow twitter - what are concrete uses for this facility ? < ebassi> mclasen: evo and other apps are already using copy-and-paste API similar to it < ebassi> evo and gedit and seahorse, according to the bug < ebassi> it's also similar to the GSettings binding API < ebassi> it can be used to link two widgets for sensitivity, or two adjustments with a conversion function < mitch> gimp has that for 5 years or so ;) < mitch> ehm < mitch> it should clearly become part of gobject * mclasen has not looked at the patch in detail < mclasen> but it seems fairly obvious; we have several users, we have a working patch, it has docs, and tests < ebassi> the latest patch moves it from gio to gobject, and adds documentation < mclasen> docs still say "since GIO 2.26" in places < ebassi> ugh, right - will fix that < mclasen> so, I think this should go in; any other opinions ? < ebassi> seems not :-) < mclasen> is there ever a case where you want to bind multiple properties at the same time ? < bratsche> Wouldn't you want to do that for linking properties in a compound widget or something? < ebassi> mclasen: you can create multiple bindings < bratsche> Or maybe the child widgets would be reflecting the property of the container widget, I dunno. < mclasen> yeah, I guess having them in on binding would just be a minor optimization < ebassi> but since property notification is expensive, we're down to the next item -- add GObject::thaw-notify signal, to allow bulk notification :-) < ebassi> https://bugzilla.gnome.org/show_bug.cgi?id=617446 < mclasen> I'm not 100% clear on how that avoids the overhead < mclasen> thaw-notify is only emitted if there's more than one notify queued up, right ? < ebassi> mclasen: you get a single signal instead of N < mclasen> so how do you catch the individual updates that might also happen to properties you are interested in ? < mclasen> don't you have to listen for notify after all, anyway ? < ebassi> mclasen: it is emitted - in the current incarnation - whenever the notification queue is thawed last < mitch> i was just wondering the same < ebassi> mclasen: the idea is that you don't listen to ::notify if you're interested in many properties < mitch> so you simply want GObject::dispatch_properties_changed() to be a signal? < mclasen> but then you loose ::notify emissions that are not batched ? < ebassi> mclasen: no, you still get those even when n_pspecs == 1 < ebassi> mitch: yes, thaw-notify is essentially the signal form of dispatch_properties_changed() < mclasen> oh, I see < mitch> that makes sense < mclasen> the name mislead me into thinking it was only emitted for freeze/thaw pairs < mclasen> bad name... < ebassi> yeah, I realize that :-) < mitch> why not simply "properties-changed"? < ebassi> mitch: that might work < mclasen> actually, rays comment is in that vein too < mclasen> just the implementation ends up working differently < mitch> or *actually* a signal emission on the topmost freeze/thaw pair might be useful too < mitch> listeners might want to stop doing stuff on freeze() and resume on thaw() < mitch> theoretically speaking, i have no real use case in mind, given everything is within one call tree here < mclasen> that sounds like adding more overhead, instead of avoiding overhead..., < mitch> yeah maybe ;) < mitch> the problem here might be that sometimes the order of properties matters, but that's up to the listener then < mitch> they can choose to connect to notify anyway < mitch> hm no ignore me, thaw fucks up the order anyway < ebassi> well, the order would be the same as the one you get ::notify emissions < mitch> really? < mitch> um < ebassi> mitch: if you exclude the duplicates < mitch> sure < ebassi> the reasoning behing bulk notification is for libraries that use a lot of properties that change in block - like clutter :-) < 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 < mitch> we do that in gimp a lot < mitch> well s/a lot/in one or two places/ ;) < jjardon> ebassi, just curious, Did you do any performance test? < ebassi> yeah; allocation in Actor notifies 5 properties in the worst case; animations are pretty bad as well < mitch> GtkAdjustment does that too now < ebassi> jjardon: we did profiling and if you start animating, you can see it on sysprof < mclasen> ebassi: and that (requiring subclassing) is the motivation for this signal addition? < ebassi> jjardon: no micro-benchmarking for stress-testing < ebassi> mclasen: yes, mostly; we don't have a GtkObject at the bottom of our class hierarchy < mitch> would that signal get the same array of properties as dispatch_properties_changed()? < ebassi> mitch: yes < ebassi> it's a concentrated notify emission < mitch> the longer i thnk about it the more often i have worked around exactly that problem using dispatch_properties_changed() in a subclass < mitch> i think that signal makes sense, given that signals with no listeners are essentially nops < mclasen> are they ? < mitch> iirc they are < mitch> aren't they? :) < mitch> timj to the rescue < mclasen> I believe various patches to that effect were rejected as micro-optimization < mitch> heh < mitch> so if this new signals involves yet another motex lock/unlock we should indeed maybe think twice < mitch> mutex* < mitch> gah < mclasen> the patch looks like context->dispatcher really wants to be the default handler for thaw-notify < mclasen> but I'm sure there's complications that prevent that... < tadeboro> http://git.gnome.org/browse/glib/tree/gobject/gsignal.c#n2879 < tadeboro> Looks like there are some optimizations inside signal emission machinery. < mitch> doesn't look like a nop to me < mclasen> still a lock there, though < mitch> yeah < mclasen> hard to avoid though < mitch> unavoidable for looking up the signal i guess < ebassi> the unlocks are all over the place < mclasen> we do lockless lookup of interfaces now, though ? < ebassi> yep < mclasen> any other topics ? < ebassi> editable label: sub-class or not? < ebassi> the sub-class idea was due to the "we can't break ABI and we're out of slots on LabelClass" < ebassi> I guess now we can simply extend that < mclasen> I must admit I never fully grokked the idea of an editable label as a widget < mitch> haha i agree < mclasen> isn't that just a notebook with a label and an entry ? < mitch> it's a WTF < ebassi> well, nautilus has them to rename files :-) < ebassi> it's a bit ad hoc, though < mitch> ebassi: aren't these tree rows? < ebassi> no < ebassi> in icon view < ebassi> not in list view * mclasen has done a lot of label + editable widget in a notebook in the accountsdialog < jjardon> It's needed to replace EelEditableLabel: Its one of the items of ProjectRidley: http://live.gnome.org/ProjectRidley < mclasen> it can be tricky sometimes to get focus handling right < ebassi> jjardon: yep, EelEditableLabel is what nautilus is using (in tree) < jjardon> bug here: https://bugzilla.gnome.org/show_bug.cgi?id=310693 < ebassi> dunno if there are other projects using it, though < 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 < jjardon> cosimoc offered to make a patch if an implementation was decided here < jjardon> mclasen, yeah It's pretty cool ;) < 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 < 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 < mclasen> the thing is that label and entry have distinct feature sets < mclasen> there's a big overlap, certainly < mclasen> but there is also a difference < garnacho> I see, should check the use cases < mclasen> labels do urls, they can or cannot be selectable, they can wrap,.. < mclasen> entries can be invisible, they can show icons, they can not wrap, etc etc < garnacho> a GtkLabel subclass makes sense then < mclasen> what will that class do ? reimplement gtkentry ? < ebassi> and in case of word wrapping, does it become a text area? :-) < jjardon> There is already a patch here: https://bugzilla.gnome.org/show_bug.cgi?id=310693#c10 * mclasen will put his thoughts in that bug < 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) < mclasen> any other topics ? < leio> • get rid of GtkProgress < leio> • deprecation of gtk_quit_add_full() to remove GtkArg < mclasen> right, gtkprogress < mclasen> I wrote a patch one evening last week that strips out GtkProgress < jjardon> bug and patch here: https://bugzilla.gnome.org/show_bug.cgi?id=620618 < mclasen> and moves enough pieces into GtkProgressBar to make the non-deprecated functionality work < mclasen> took a few hours, but wasn't as hard as I thought < mclasen> it is obviously not abi compatible < mclasen> but other than that, it works fine < mclasen> I just wondered what people's thoughts are on that ? should I just commit it ? < ebassi> ship it, it's done :-) < leio> so no sharing with GtkEntry progress stuff? < leio> (interface) < jjardon> well, It's for GTK+3, is abi compatibily required? < mclasen> leio: there was never any sharing with the entry progress stuff, api wise < 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 < mclasen> the drawing is shared, of course < ebassi> which would be still fill odd anyway < leio> feels similar to GtkOrientable, sort of < 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. < bratsche> (at least, I think this is how it works right now) < leio> GtkProgressBar is a non-editable GtkEntry with no text in it *grin* < mclasen> it is shorter/thinner < leio> except there is a label. Anyway, considered, decided, then GtkProgress is not useful if not serving an interface < mclasen> ok, cool < bratsche> Oh, then I'm just smoking crack I guess. < mclasen> deprecation of quit_add_full - last point < jjardon> yeah, I asked murray about it. He commented in the bug < jjardon> pygtk uses that function, but GI based bindings no < mclasen> in an essential way, or easily avoidable ? < mclasen> I would assume the essential point is that bindings need a destroynotify < jjardon> murray words: 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. * mclasen needs to run out < mclasen> your conclusions on a postcard... < mclasen> later < ebassi> ugh * ebassi just saw GtkArg for the first time < jjardon> ebassi, Do you know anything about the perl case? < jjardon> :) < jjardon> I saw that current perl bindings use that functions one time. But the GI based no < jjardon> oh, here is the bug with the murray comment: https://bugzilla.gnome.org/show_bug.cgi?id=619671 < ebassi> jjardon: perl-Gtk2 binds it < ebassi> but we don't use it in code < ebassi> so, since perl-Gtk2 binds gtk+-2.0, it's not a big deal < ebassi> and as soon as we switch over to GI, it's not going to be a problem ever again < jjardon> indeed, It's only used here: http://git.gnome.org/browse/perl-Gtk2/tree/xs/Gtk2.xs#n491 < jjardon> and here in gtkmm: http://git.gnome.org/browse/gtkmm/tree/gtk/src/main.ccg#n252 < jjardon> the problem is that gtkmm bindings are not GI based (for now) < ebassi> so, dunno; at this point, should we rename the function? break it without pity since it's fairly unused? < ebassi> jjardon: gtkmm will have to bump up anyway < jjardon> yeah, or maybe use GCallback instead GtkCallbackMarshal < jjardon> in these functions < jjardon> as murray suggest in the bug report < ebassi> sounds reasonable to switch to GCallback and let GtkCallbackMarshal die a painful death * tadeboro rather goes directly to hell that being listed on ebassi's deprecation list ... < ebassi> right, so we can adjurn the meeting < jjardon> ok, Is there time for leio concerns about performance? < ebassi> oh, right < ebassi> though we have hit the 2:30hrs mark < leio> I'm not personally prepared to argue any counter arguments, so some "unofficial" chatter is fine < ebassi> okay; I can still put it in the minutes - it's up to you < 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 < leio> http://live.gnome.org/GTK%2B/Meetings?action=AttachFile&do=view&target=20100323.txt < jjardon> one moment, let me check < leio> 21:50 < leio> in the raw log < 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) < 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 < 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 < ebassi> though, obviously, it would be good to have numbers before making the build even more hacktacular than it is < ebassi> (not that I don't doubt that function call + argument type checking > direct access < ebassi> in terms of time, obviously) < 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 < ebassi> still, internally, the compiler could do tricks; and we could have the cross-file boundary inlining at some point < leio> is GTK+ already using function calls internally, or that is one of jjardon's gsoc projects? < ebassi> leio: for things that are exposed publicly, we use the public accessor internally as well < 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 < jjardon> I added some internal functions functions, but without type checking < leio> I'm not sure what build hacks would be involved here < ebassi> right - internal functions should not have type checking < 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 < ebassi> which is the biggest risk as soon as you start making Private data structure project-wide < 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 < ebassi> leio: it might probably rate lower on the build hacks scale than, say, the aliasing stuff ;-) < ebassi> anyway, it's a good discussion that should be brought up on the mailing list < 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 < jjardon> yeah, but thinking more on this, waht id the advantage of _gtk_accesible_set_widget (a, w) over a->priv->widget = w ? < leio> yeah, jjardon suggested in a meeting :P < ebassi> leio: since people have gone offline, and since we probably need more bandwidth, the mailing list is usually the next step < ebassi> leio: it's much appreciated, though < leio> agreed < 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 < ebassi> we've had this discussion on IRC, in various shapes and forms < leio> gtk-2-90 is in master now? < jjardon> leio, I'm pushing my work here: http://gitorious.org/gtk3/gtk/commits/refactor < ebassi> leio: yes < jjardon> leio, gtk-2-90 is obsolete now < jjardon> It was merged in master some time ago < leio> looks like even GtkWidget code itself internally does gtk_widget_get_realized function calls with type checking all over the place < ebassi> leio: yep < leio> anyway, I think this is not for the meeting channel anymore < leio> as we didn't have time :) < ebassi> okay; leio: thanks for the patience :-) < ebassi> next meeting in two weeks < ebassi> good night everyone; will send the minutes soon