* mclasen looks for the agenda http://live.gnome.org/GTK%2B/Meetings ok, so what do we start with ? small api additions ? ok are there any left that people want to land before the next devel snapshot ? wiki page: http://live.gnome.org/GTK%2B/SmallApiAdditions Would be nice to have the simpler GtkBuilder api; http://bugzilla.gnome.org/show_bug.cgi?id=447969 (with patch) mclasen, I would like to get gdk_image_get_shared_pixmap() in if thats reasonable I think kris also had some api changes required to make GtkTooltips deprecated (some api explicitely use GtkTooltips) (this one for reference: http://bugzilla.gnome.org/show_bug.cgi?id=441853) tristan: I don't know if it is reasonable, I'd rather not add random new things to the list at this point mclasen, ok, we'll be using a patched gtk+ for that though jdahlin: same goes for convenience api on top of GtkBuilder, I think; I think we should concentrate on sorting out the issues with the current api, like refcounting mclasen: when is the API freeze? I guess that is what we are trying to determine here ? I'd like to declare the next snapshot api frozen if at all possible I agree that the reference counting is more important, it's actually a requirement before that convenience function can written properly so what is the status of refcounting stuff, just docs to be written or people want the behaviour to change ? can we sort out the small api stuff before shifting to GtkBuilder, it's nex on the agenda it needs to change, the current behavior is not sufficient sure, sorry ok ok sorry :) pbor: ok, the one api addition that I kinda promised to look at is the pixbuf orientation thing and I'm going to look at it tomorrow mclasen: ok should I add it to the list on the wiki? it is on the wiki ah, oops i guess the one somewhat important item on that wiki page is the tooltip positioning but kris is not here to talk about it yes, and also the new tooltips stuff kris noticed today after deprecating GtkTooltips I guess we should ask kris when he's around yes so I guess we are done with small api... should we move to GtkBuilder? all the other things on the wiki page look like convenience api, or committed or unimportant yep ok, GtkBuilder integration status now reference counting is the last major todo (447967) strictly speaking, it won't require API changes, but it's important to get it right before people starts using it jdahlin: so, what exactly is the current proposal for how things should work ? mclasen: I posted a little bit of my thoughts to the mailing list earlier today I'd like to make it possible to unref the builder and make all objects not fetched (or references by a fetched object) to be freed as soon as you unref the builder itself hmm. i am late. it might be more than we actually need though, the memory used by the builder is much less than the memory used by libglade jdahlin: that should work fine for objects, but for toplevel windows, it doesn't quite work, I think so it might not matter too much to have the builder lying around as long as the process/interface live * tristan just commented on that bug sorry for being late in catching up so, we want orphaned objects to be cleaned up... why ? as outlined already today: keeping the builder around can make things quite convinient mclasen: so what should be done for top-levels? jdahlin: I think if they are not fetched and destroyed by the app, they are leaked mclasen: right, that's what we need to decide the builder could destroy them, but it is a bit hard to know for the builder which ones to destroy and which ones not should the gtkbuilder claim ownership of all objects, or is it up to the application? I think everything should be leeked * tristan thinks the latter completely rambokid: do you have an opinion? objects passed to the outside by the builder could have their ref-count raised an object that was built by the builder but never seen by the application code, might still be doing something usefull too tbf: no, we don't have reffing getters, the app needs to ref itself so everything attached would stay alive, even even if the builder gets destroyed mclasen: so the methods cannot have an "_get_" in their name gtk_builder_steal_object() ? :) the builder is a sort of factory so returning a reffed object may make sense... pbor: +1 if we leak everything (ie don't unref when the builder goes away), then you don't have to return a new reference the application can just use the initial one jdahlin: i'm not quite sure what the problem is. isn't it ok if the builder returns objects like they are created? i.e. non-toplevels are floating, and toplevels are being refernced by the toplevel-list anyways... mclasen, nod, which is classic libglade behaviour i.e. make it behave exactly like g_object_new I think that is fine rambokid: the problem, in my opinion is that the application developer needs to know about all the objects created by a userinterface (models, ui manager, sizegroups etc) and unref them when not using them any longer jdahlin, if they put unused objects in the interface, they are to blame for not using them no ? its like calling g_object_new() and then forgetting the return value the problematic aspect I see is that the builder returns a bunch of objects in different states, ownership-wise some are toplevels that need to be destroyed, some are floating, tristan: it's more like that the application developer might not be aware that a treemodel or sizegroup is created when a certain operation is done in the user interface designer some are straight objects jdahlin, thats another can of worms though and more importantly - an object never seen by the application code might still be doing something important. urm, no. the application developer should *only* deal with toplevel handles. that is not a problem for non-toplevel widgets that are children, since those are referenced by their containers. so the only questionable thing are non-widget objects, right? in general, keeping such widgets around only makes sense in the context of a window. so the best thing to do here is to g_object_set_qdata_full(window, "key-for-this-object-kind", sinke_ref(o bject), g_object_unref). for some types, e.g. size groups, you need a list though. I'd think everything should be owned by the builder until you ask for it (gtk_builder_ref_object ?) what about a destructor for gtk builder similiar to g_string_free(str, free)? earlier there was talk of allowing non-toplevel widgets as root objects in builder files mclasen, I believe thats already allowed and rambokid, usually you dont care about dealing with the window, you just want a handle on some button so you can set it insensitive later on yes, but if we introduce the concept rambokid just mentioned we'd have to treat toplevels which are widgets but not windows differently tristan: you always care aout a window, because a window is the only thing that makes sense showing and hiding and every app has to decide that individually for every window. and all that complexity scares the crap out of me rambokid, sure, unless its initially visible ok. tristan: that's mostly a bad idea anyway jdahlin: not really, you could do the same for those, i.e. attach references as QData. the only difference is that you hand them out floating, i.e. still you behave like g_object_new rambokid: okay, that sounds reasonable I think that if I asked the builder to build something and it dissapears after unreffing the builder, thats a little unfair rambokid: not at all, in the app I just care about a window, but enforcing to create the whole window from builder is wrong... I may just want to build some part of the ui and stick it in a sidepane of my main app window but also, if toplevels, non-widget GObjects and GTK_WIDGET_TOPLEVEL objects all get cased differently... only chaos can ensue :-S tristan: also, windows are the single object class that the developers have to conciously destroy, so there's no way of getting rid of dealing with a window handle for a developer. but from that, everytihng else can automatically follow via qdata and ref_sink/unref rambokid, what about actions ? tristan: absolutely, especially since ref/unref is a memory managment issue, and widget appears/dosappears is a user visible effect, i.e. part of the user experience/interface. memory management issues should *never* have user visible effects (i.e. have widgets disappear because a gc is run ;) they have to be explicitly destroyed I would think anyway, it seems that builder refcounting still needs some thought... maybe this discussion should be carried on in bugzilla/mailinglist and we should move on? pbor++ true pbor: right, i'm not saying the builder should be constrained to toplevel creation. the point is just to keep all non-widget references from the "toplevel" object created by the builder and handed out to the user. and that could still be a floating non-window object (i.e. mimicking g_object_new which you can also use for windows and widgets) I just realized that I need to change two of the builder apis to include a reference to the builder itself as the first argument it'll be needed for pixbuf handling, but that can wait, just as long as we get the API change in rambokid: ok ok, so what is the timeframe for sorting out the builder refcounting ? I'd like to have that fixed in the next snapshot, ideally can we get that sorted out this week ? I'll give it a shot, rambokid gave me some useful hints, which shouldn't be too difficult to implement I can't promise that it'll be finish this week though, it should probably be reviewed for instance. sure when do you plan to release the next snapshot? as soon as possible, I guess end of this week sounds like a realistic goal okay, let's see if we can make it before jdahlin: ok. apart from refcounting and those small api changes you mentioned, anything else regarding gtkbuilder? docs I said I'd give it a go, and failed last week but I made some inroads towards it last night pbor: we have two apis which should probably be put off to 2.14, due to lack of time I committed a libglade converter which is pretty good but would need some more work, can be done post 2.12 too. jdahlin: what about the "root" widget argument issue... it seems everyone uses it and it keeps coming up on the mailing list (gedit, murrayc. muntyan, etc)? jdahlin: does your converter warn if it meets an unsupported construct ? mclasen: no, it doesn't. I think it's possible to support everything libglade does oh, I know, I just wondered if the builder is verbal about what is not done yet pbor: it have to wait, I don't have to time address that oh, the builder itself will complain or crash.. one hopes for the former... is the error handling in the builder in good shape ? it's better than it was initially, but still not perfect jdahlin: fair enough: "don't have time" is one thing "will never support it" is another (though I have to admit that it disappoints me, gtkbuilder was merged on the basis that missing thing would be added before 2.12 otherwise it would have not been merged...) really ? that was my impression at least pbor: is partial object tree construction a required feature? it would require API changes at least pbor: personally, the "regression" argument is kind of moot; the builder is much more than libglade ever was, and the partial object construction was exploiting a missing functionality in libglade jdahlin: would it be hard to add a "root" (construct-only) property later on for those needing this feature? jdahlin: for me to use it is and judging from the mailing list looks like I am not the only one, but I am not the one making the call whether is a required feature or even builder_parse_subtree() api... ebassi: it shouldn't be done in the constructor I think, rather when adding a file pbor, the builder wont be unusable for people who formerly used the "root" argument correct ? jdahlin: right jdahlin: gtk_builder_add_from_file_with_root() is ugly, but would require an api addition instead of a change wouldnt't that define "required" ? ebassi: a property or method could also be done, set_root() for instance ebassi: doesn't look too ugly to me jdahlin: yep, that too mclasen: I tend to be wary of using many prepositions inside a single call :-) ebassi: discussing whether is or isn't a regression is of no use, what matters is if builder is powerful enough for all usecases of libglade and/or it will at least be in the future... otherwise we end up with another half cooked thing in gtk that real apps do not use pbor: don't get me wrong, I'd like to support it. But it's very difficult the way the parser was written lest we add a dom-like parser in glib * ebassi runs pbor: the first version of the builder patch I wrote did the parsing in a similar way to libglade (2 steps), but people seem to prefer doing the whole construction in one go jdahlin: at the risk of sounding like a asshole, I do not care about the internal detail just about the fact that my usecase is taken into account or a valid alternative provided :) pbor, splitting up your dialogs into individual files is not a valid alternative ? sure the root argument is "nice" if you want it all in one file, but is it a valid use case ? tristan: they already are, but requiring to hand edit files is not what I call nice pbor: I'll probably add an option to the converter script, which will do that for you and how would I edit them afterwards? you can't anyway, since there's no gtkbuilder designer out there yet heh, I'm making no promises for glade 3.4 pbor: would the convenience api proposed by havoc cover your use case involving root ? * pbor wonders if the fact that there is no designer is a symptom that we are rushing things mclasen: lemme re read it pbor: chicken and egg problem, really.. pbor, not at all, we've been holding tight waiting for the mythical builder to appear if the builder ever happens, we'll start spending our time supporting it pbor: let me try to have a look at supporting partial tree building this week, it might be possible to make it work without rewriting the parser are there any other use cases for root beside filtering a parent GtkWindow required by glade/libglade? mclasen: I just see two mails by havoc on the archive and they do not seem to contain related stuff... jpetersen_: good point, I'm not sure there are jpetersen_, sure, you can be allowed to store everything in one file and parse windows individually jpetersen_: the glade files are really done in that way since it's easier to have one glade file represent the whole project, for all toplevels only a matter of preference though if you ask me pbor: for instance, writing a separate parser which only task will be to filter out unneeded parts jdahlin: ok thanks, I didn't want to sound too negative pbor: let me find the bug http://bugzilla.gnome.org/show_bug.cgi?id=447969 I still fail to see how that utilities relate to non toplevels root elements... well, it allows you to explicitly load named objects but maybe we should move to the next agenda item mclasen, it allows you to assign loaded objects to pointer values as a convenience - I dont see it ommitting parents though mclasen: well, if objects can be non toplevels (and the relative toplevels not be created) than ok, but as far as I understood the problem was not the api but the underlying implementation mclasen: anyway I agree we should move on now tristan: I assume it is the kind of convenience api that constructs the builder internally, and throws away all the objects that are not explicitly assigned or children of those next agenda item is "filechooser bugzilla status" dunno who put that up ? ebassi: ? I put it on the agenda mclasen, I dont read it that way but sure... lets move on :) short story: there are some file chooser bugs in bugzilla with a patch attached; I went through those and I'd also like to go through the list of file system issues tristan is now known as tristan|away most of these bugs either are crashers hard to reproduce or deal with the appearance of the file chooser so I'd like to put them on a fast track for review and commit before 2.12 (I'll have to put the list on the wiki, if we are going to have a small bugs list) end of request :-) ebassi, if they are not on my llist, and you think it serves any purpose, and you already have your list done, you could send it to me one bug already went down tonight (bug #324543) xan: yeah, a couple are on your list, I'll send you the rest ok, I actually don't remember if I managed to go through all of them or not (it's exhausting) ok, next point ? small bugs list xan: yes, it is - also most of them were reported agains 2.4 or 2.6, so it's really uncertain whether they still apply mclasen: that was something you mentioned on irc last week - having a list like the small api list, right? oh, ok I guess we should just move on to the last point then well if no one has one I have one of such small bugs: http://bugzilla.gnome.org/show_bug.cgi?id=448313 though it looks like more in the behdad field of competence pbor: I'll poke behdad on that one thanks ok, last agenda item is next devel snapshots I said earlier that I think getting them done by the end of the week is realistic but we should probably re-evaluate where we stand wrt to the outstanding gtkbuilder and tooltips api issues later in the week I'll do my best to sort out the remaning issues. ok, so meeting is over? should I put the logs one the wiki given that ebassi was not here when we started? the tooltip positioning issue is blocking a couple of changes around the file and recent chooser widgets (removing the uri from the treeview to make it more compact) pbor: you can send them to me (at least the part before 21:45) for editing and minutes kris had a reasonable looking api proposal for tooltip positioning, I think ebassi: ok, sure