Meeting on irc.gnome.org:#gtk-devel Meeting started February 28 2005 16:04 EST (21:04 UTC) In attendence: Manish Singh (yosh), Owen Taylor (otaylor), Jonathan Blandford (jrb), Federico Mena Quintero (federico), Matthias Clasen (mclasen), Morten Welinder (gmorten), Johan Dahlin (jdahlin), John Ehresman (jpe), Lorenzo Gil Sanchez (lgs), Dan Winship (danw), Anders Carlsson (andersca) federico, can you put last weeks logs up on www.gtk.org ? ok, we actually have an agenda today should we start with the libglade discussion ? mclasen: what else is on the agenda? mclasen: the libglade discussion could dominate mclasen: do I have modify-fu? I wanted to ask about the general opinion wrt to adding bmp saving support in 2.6 oh, I guess I do federico: its all in cvs * federico cvs updates gtk-web but thats not that urgent, now that 2.6.3 went out so lets just discuss libglade first mclasen: that would be nice for windows people --- I'd like to fix the "malloc(whole_image_size)" bit first federico: that's pretty dreadful federico: it wasn't clear to me if the bmp saving alone is that useful, and I don't know if the "delayed rendering" parts of the patch qualify as 2.6 material without the delayed rendering stuff, as I understand it, cut and pasteis dead in the water for win32. but I think that is all win32 specific. I think I will bring that question up again when 2.6.4 comes closer and the bmp saving code in HEAD is in better shape gmorten: Well, cut-and-paste of images, perhaps. Which we don't really support very well on X .... so libglade, then? bring it on okay gmorten: I think it's basically up to tml whether it's important enough to make an API addition (BMP saving) in 2.6.x or not owen: not jsut images. html and xml too. (wish we had jamesh here for this) I sent a mail to the mailing list a few hours ago, with a few possible topics owen: it's 4am in perth What I forgot to mention in the mail is that we actually are a few who are prepared to do the work jdahlin: I know. It might have been nice to do an alternate time, but well, water over the dam. He'll just have to comment on-list owen: I'll send a summary to the blog afterwards the blog? gmorten, why is delayed rendering for xml and html cut-n-paste? mailing list, sorry owen: I talked to him a few hours ago, he seemed somewhat supportive about putting it in gtk+ Feb 28 16:12:42 * jdahlin is tired jpe: not quite sure. I wish our man in .hk was here, but hey it's the wee hours there too. So, what needs to be done is the following: - make libglade use GMarkup - add support for GObject (this will break the API) - add support for GtkUIManager (high priority for ui builders) will the gobject support not just be api additions ? - ideally, but not required; move the custom properties from libglade to the widgets themselves mclasen: no, GtkWidget * glade_xml_get_widget (...) should be GObject *glade_xml_get_object (...) jdahlin: nothing wrong 3with having both. jdahlin, we can add an alias and be backwards compatible it's doable without breaking the api, but since we're moving it to another library we can afford breaking it, no? the former just returning GTK_WIDGET of the latter. well, as gtk api it will be all new, so there is probably no need to add compat functions in gtk gmorten: right, can be made backwards compatible, but we'll end up with some duplication We basically need to be one place or the other One place: 100% absolute compatibility (and xml => gmarkup might be too much of a break) jdahlin: it is any reason to add pain for the existing library users? The other: completely new names for everything, can still use external libglade danw: you mentioned the need to have an interface like GimmeGUIEditorIface? gmorten: no, I'd like the API to be as close as possible federico: i did? when? danw: when you showed me that winforms book gmorten: libglade is still going to be around until 3.0 federico: oh. that's beyond "move libglade into gtk" though Renanming would allow us to kill the horrible GladeXML name... I wrote a small API, which I of course forgot to attach in the mail to the ML http://www.gnome.org/~johan/gtkobjectfile.h hmm, that naming clashes with GtkObject Maybe GtkResourceFile and forget that 'rc' stands for resource jdahlin: were we going to try to keep the file format the same or change that? which has all features of GladeXML but renamed jrb: I think it's worth keeping the file format jrb: I am already feeling the pain of that question... it shouldn't be "gtk"anything should it? should be gsomething jrb: If we can avoid a convert script, it would be very nice to do so jrb: however, we might need to add CDATA support in GMarkup, not sure if the libxml sax parser in libglade can handle that without warnings/errors danw: I think you are going to need at least the notion of GtkContainer in the file jdahlin: adding CDATA support should be easy danw: we discussed that, it could be put inside glib/gobject, but it's quite tied to widgets/containers And anything that lives in Gtk has to be Gtk*, unless you think we can do this as generic object tree serialization. BUt I'm skeptical of that mclasen: I agree, shouldn't be too hard GtkUIBuilder, GtkWidgetCreator etc i was thinking we were aiming for generic object tree serialization (because of the sizegroup, etc talk). but yeah, i don't actually see any need for that skinreader :) danw: in the long term probably, but I think it's too much work for 2.8 mclasen: what do you think about moving glade/glade-gtk.c into the respective widgets/objects? danw: Well, I think we need to represent non-widget objects, even for 2.8, likely. But that doens't mean dropping the notion of child properties, etc. mclasen: at least the custom properties danw: but there are no generic object trees, since gobject doesn't have containers mclasen: there is GtkListStore... which is not an object tree either...:-) rather than generic serialization, can we just hard-code stuff like gtksizegroup? what about Tristan Van Berkom reply to jdahlin email: talking about GContainerInterface? federico: gtksizegroup probably needs some hard coding you don't expect the gui builder to be able to handle any gobject type lgs: incompatible with the 2.8 timeframe, I'd say fair enough But that doesnt' mean to me there shouldn't be some reaosnably generic way to specify an arbitrary object into a glade file ... the basic object property stuff should work the same jdahlin: I haven't looked at all the custom properties and what glade-gtk.c does with them in detail Though I don't know if we have any use cases other than sizegurp and liststore, which both take hardcoding jdahlin: but reducing the need for special cases makes sense to me; once we have a glade-gtk.c equivalent in gtk, that can be done piecemeal, right ? jdahlin: jamesh seemed dubious about merging in the GtkUiManager files. Did you get a sense of why? tooltips, though they're basically like a sizegroup treeviewcolumns and renderers also mclasen: the concept is easy, you register a fake property (which can be specificed in the glade file), and we it see this property it calls a function, which does some magic and usally ends up calling an accessor (GtkProgress "format" - > gtk_progress_set_format for example) mclasen: can be done incremental, but I'd like to get rid of all custom properties (also treeview data) jrb: We could mix dtds conceivably, though it doesn't really matter if we use the UiManager XML notation or not as long as the same ideas can be expressed mclasen: and the need for having the GModule interface in libglade jrb: it's difficult for the parser, I think we just can get around it by using CDATA jdhalin: What's the difference between that and a real parser? jdahlin: yes, I mainly wanted to point out that getting rid of custom properties doesn't have to block the move of libglade sorry, real property? owen: it just seems really worthwhile keeping those in the same file. I didn't know why jamesh didn't think it was feasible owen: introspection jrb: I agree that you should be able to design your toplevel within your GUI editor coimpletely owen: it's basically patches on top of the objects to make them behave in a consistent way jdahlin: But inside GTK+, wnhy wouldn't we just add the properties to the widgets? mclasen: right, we could move libglade as it is right now, but we have the chance to break the api and make it a bit cleaner and thinner (Of course, leaving aside the possibility of glade having support for inherently broken pseudo-properties that we just want to support for back-compat) owen: I don't know why we shouldn't, I totally agree that they should be moved but it's a little bit of work, and it toches quite a few widgets touches btw., create-time only properties are a royal pain here. yes they are glade_register_custom_prop (GTK_TYPE_ENTRY, "invisible_char", entry_set_invisible_char); huh? I think libglade handles that with custom widget builders owen: yeah Oh, that's to take a string rather than a gunichar owen: glade serializes invisible_char as a string, but the real property is an int danw: What a screwup another problem are widgets that need arguments in their constructors yeah, that probably counts more as "working around glade brokenness" than "working around gtk brokenness" owen: yeah, the property should have been a string in gtk... gmorten: Well, possibly, but given that it isn't trying to paper that over in libglade rather than glade is not a good idea. gmorten: I'm pretty positive that the stupid 10 minute property editor in gtk+/tests gets it right GObject has no concept of converting types on the fly right? for example GtkSizeGroup needs the mode in its constructors, and that just make the parser harder owen: just wait until you see how .glade files handle notebook tabs. same with GtkAction and GtkActionGroup lgs: ? lgs: hmm, thats not even declared as a construct property owen, libglade uses g_object_new for building the widgets lgs: GtkSizeGroup takes the mode in the C convenience API, but doesn't require it and supports changing it at any time and later it sets the properties that they are found in the .glade file check out gtk_action_group_new owen, sorry, then it's a bug of the pygtk binding for GtkSizeGroup lgs: If it does that, it should be fixed to pass all the properties it can to g_object_new() ... that can be *considerably* more efficient owen, the only problem with that are construct only properties, like the 'type' property of GtkWindow lgs: thats a GtkActionGroup bug If we aren't requiring 100% compatribility, I think our goal shoudl be to eliminate glade-gtk.c. We can add some sort of mechanism to warn when encountering affected properties I totally agree As do I owen: you mean: get rid of all custom properties ? by eliminate glade-gtk.c, you mean 'get rid of all the special cases'?} well, some parts of glade-gtk.c will still be needed, it does several things jrb: Hmm, well, at least the special cases that aren't truly avoidable... GtkNotebook and the like might require special casing like defining internal_childs owen: yeah. I think we all have the goal of minimizing it.. owen: I have 33069 lines of glade files in gnumeric. Please don't rock the boat without very good reasons. we should take the occasion to rename that to internal_children... gmorten: But probably few clists... owen: none, I hope. mclasen: sorry, my fault, it's internal-child Anyways, I definitely dont' think we should splitt the property munging stuff in glade-gtk.c out into individual GTK+ widget files ... back compat hacks for existing glade files should be kept localized Maybe the build-children stuff could be made into a container vfunc ... I haven't really looked into how it works There are three functions that are interesting to us; New, BuildChildren and FindInternalChild jdahlin: What do you mean by "New"? gmorten: do you use the signal connection aspect of glade? owen: it's a function which is called when the widget is created, some widgets like GtkDialog seems to be handled slightly differently another issue is, there are some containers with that accept more than one children but, you can't add children to this type of container with a single API jrb: rarely, if ever. for example, GtkFrame, you add the *main* widget with gtk_container_add, but you can add another widget with gtk_frame_set_label_widget and paned and notebook and that's kind of hard for libglade /gui builders nodes jdahlin: YOu mean build_widget? lgs: That's the build_chidlren/find_internal_child stuff we are discussing lgs: thats basically the difference between array and struct... owen: the frame label isn't an internal child though owen: yes but that could be resolved by having a child property saying whether the child was label or content basically the same way box/table children work danrw: I really don't know the details of how libglade is structured owen, see this http://lists.ximian.com/archives/public/glade-devel/2005-February/000987.html another thing lgs raised is how to merge in the ui files for menubars and toolbars Basically, I think if we are going to do anything here, someone has to make sense of the whole internal children / push_composite_child / multiple child slots / etc. mess once and for all yes I'll discuss it with james we need widget groves ! Feb 28 16:53:14 * mclasen dreams back to his dsssl days huh jdahlin: One conceivable answer is that we just don't use UI files at all when creating stuff as glade file. I dont' know how that interacts with the possibility o fmenu editing jdahlin: or of menu merging does that mean you can't use uimanager if your main window is specified with glade? danw: you can still do it by hand. but it's not pretty danw: or as pretty as it really should be owen, I use CDATA for that right now in gazpacho gui builder owen: that'd be cleaner, but we'll need to reinvent parts of GtkUIManager, eg replacing everything with properties, childs, and everything lgs: but you don't have to use CDATA to embed one wellformed xml fragment in another... danw; I guess the question is "why would you care" ... what is the relevance of UI manager to the code of a app once the menus are created lgs: Oh, uck. XML in cdata is awful owen: so we from the same format can construct everything and not have two different ones mclasen, I know, but that was meant to don't break libglade DTD lgs: does libglade even validate the xml you feed it ? owen: the parser gets kinda complicated to embed one ui file into another, I'm not sure if this is easily done mclasen: it complains if you send in something it doesn't understand danw: (Question for discussion) mclasen, no, because I'm using a property it doesn't know about, but the DTD is compatible jdahlin: Sure a bit of work, but it's extremely tractable. lgs: I'd rather see the ui.xml be a separate file which is referred to in the glade file than doing such a CDATA hack mclasen, I support both ways owen: i'm not sure. i haven't used GtkUIManager for anything yet... mclasen, because users don't really want to have several files for their interfaces "users"? danw, programmers, in this case gosh. Surely we can get both in the same file... mclasen: I think it should be supported to have the ui files stored separately, but it should not be required jdahlin: agreed storing them separately has the advantage that you can update them independently (think menu editing) I don't see much reason to support storing them separtely mclasen: But the app is always going to be keeping the unedited version around somewhere mclasen, menu editing should be done inside the gui builder mclasen: also embedding in executables makes that easier lgs: mclasen means user menu editing which the mono gangs want lgs: at runtime ? mclasen, gui builder is something like gazpacho/glade sorry about the confussion ok, I'll be leaving in ca 5 minutes another thing is right now, you need to have differnet UI files if you want to be able to merge/unmerge widgets later haveing pieces of UI definitions inside the .glade files that can be assigned to their own ui-merge-ids would be nice so the important question for me is who is driving the libglade integration effort ? ...I don't have the time mclasen: I am great, thanks mclasen: together with lgs & jrb and hopefullly with jamesh advices I think andersca might be interested in helping out too lgs: definitely I can look at supporting CDATA in gmarkup, if that turns out to be useful mclasen: I think it's most useful for the TreeView data jrb: just CDATA attributes or CDATA marked sections as well ? CDATA marked sections are easier, since attributes would need dtd parsing mclasen: I'm not 100% sure we've thought it through fully. So I don't know yet and that is a big can of worms jdahlin: do we want to build off that page that jamesh started? jrb: I'm not sure, perhaps jrb: not everything makes sense, like keeping the API jdahlin: or should we just start a new one jrb: a new one and reference to james' one but if glade is migrating into gtk then the existing discussion there becomes pointless seems like a good aproach to me so why not just overwrite it? I I'm not sure if james is going to continue to maintain libglade ok, I'm leaving. I'll post the logs tomorrow. See you next week mclasen: thanks for your time Meeting ended February 28, 17:05 EST (22:05 UTC)