we can begin, then wrt to "next gio release" err, next glib release that has happened yesterday partly because I was confused about stable vs devel deadlines... and I think it should have all of the major api changes for gio at this point mclasen: a question about gio usage - is it safe to start using gio in gtk+ trunk? I have a patch for getting the mime types for the recent files on unix/win32 using gio and I wanted to start using the file monitor as well for reducing power consumption I think it is safe, certainly the file monitor api did change in 2.15.1 but it should be final now okay, thanks what about the filesystem backend? is that ready for libgnomeui (feature freeze for 2.22 is next week) ? we have had it it in rawhide for some weeks now, and it seems to work as well as the rest of the file chooser... I do not think it's a major issue, but note that a gio backend for for the filechooser is a bit of a regression for apps still using gnome-vfs (since it cannot browser ftp etc) chpe: mostly I think, I cant cook a patch today or tomorrow garnacho: can or can't ? :) pbor: Thats more of a general regression chpe: argh, can :) garnacho: that's be great pbor: At the moment it looks likely that we won't get an ftp backend for 2.22 I would love it if someone wanted to work on onw one alex_: sure, but an apt can "opt in" to use gio as a lib, while the filechooser is what it gets from gtk app* pbor: sure, but the file manager (and thus the "desktop") uses gio alex_: would a generic wrap-a-gnome-vfs-backend-into-a-gvfs-backend backend be easier? so the ftp regression is general alex_: anyway as I told you the other day I don't think it's a big problem, just something to be aware of danw: I'm not sure really. An ftp backend shouldn't be to much work I think getting a gnome-vfs mapping backend going is easy but getting it to work well in the corner cases will be quite hard alex_: what are the other major "missing-backend" regressions at this point ? computer:, network:, burn:, http/dav, obex-ftp dont want to interrput the discussion but I checked the gvfs base class for some days ago and found that it has an callbackfunc named *delete isnt this a reserved word in some languages like c++? Could this give problems when write bindings? I'll probably finish computer tomorrow alex_, webdav/http is importtant backend * jdahlin reserves tickets to the berlin hackfest then i'll do network and burn gicmo/danw is working on http/dav danw: status? is there no one working on http/webdav backends? hupps alex_: i still wasn't working on it. i was looking for gicmo on irc this morning but he wasn't around rhult started on obex-ftp but had to stop due to lack of time alex_: confirm the ftp backend non-availability, i haven't had time to work on it danw: yeah, he's been away during xmas danw: but was around yesterday a bit danw: He seems busy alex_: so i don't know what the state is, or even where the code is alex_: busy-with-http-backend or too busy to work on it? danw: Maybe you can mail him and ask about the status yeah danw: maybe he needs some help with it danw: busy-with-life as i read it mailed tielie: So, i'm no c++ expert tielie: but being a keyword seems sort of bad anyone know c++ details like that? alex_: C++ keyword in header is definitely a problem. we had that in gtk+ a few times, there's a test for it now to avoid them or at least I thought there was a test, can't seem to find it now alex_: pango has a test to compile all headers with c++. check pango/cxx-test.C. I remember tbf doing something similar in glib? maybe it was gtk behdad: gtk, afair nah, glib/tests/cxx-test is there alex_: just hook up gio into it and gthread probably (and gio-unix.h) coming back to the filechooser backend seems to work.. putting it in libgnomeui in _addition_ to the gnome-vfs one shouldn't block on the regressions, right ? yes, I assumed it wouldn't _replace_ the gnome-vfs one, just be parallel to it mclasen: well, as far as I understand you can have just one default backend... so if the gio backend is used you'll see the regressions even if the gnome-vfs backend is there... or am I misunderstanding? still, how does an app pick the backend? pbor: right alex_: there is a gconf key apps can override it when constructing the file chooser, but they rarely do i though it was just a "can use uris" or not thats a separate thing can we check, that gnome-vfs is initialized? One wierd thiong i notivced in the gtkfilechooserbackend was that the sftp mount didnt showup in the backend even if the volume code was exactly the same as in nautilus? I commited the updated cxx-test. Works fine with gio. in that case load the gnome-vfs backend, otherwise gvfs? (i know: whack idea) kinda hard to do without linking to gnome-vfs, isn't it? Also, doesn't e.g. libgnomeui init gnome-vfs? i thought libgnomeui set gtk to use the gnome-vfs backend rather than the default backend? it does, yes danw: g-s-d does, via the libgnome schema entry for it alex_: should the toplevel gio include be gio.h instead of gio/gio.h? I mean: #include #include #include #include doesn't look right behdad: it was discussed on the list we're not really consistent in the stack how about making the gio backend opt-in for 2.22? ie. the schema stays at gnome-vfs backend, and apps that are gio-aware explicitly set the gtksetting to "gio" ? with e.g. gtk being gtk/gtk.h right, but in the same module at least... but if you already discussed, fine. I kinda like the subdir thing behdad: between glib and gtk+, the damage is already done seems less namespace polluting in terms of consistency maybe make the old ones also work like new ones. that is, make glib/glib.h work more obvious that the thing is some library rather than a local include yes chpe: I don't really think apps should do anything special; having the opt-in be a user decision is fine for me until we are ready to do the switch mclasen: Its really an app decision though mclasen: its the app that loads the file returned by the file selector and if it loads with gnome-vfs, it should get a gnome-vfs uri and vice versa Now, in practice the uris are the same I don't think the file chooser returns anything gnome-vfs specific, does it ? so its mostly a problem with regressions in gvfs backend support btw, as for gtk+ 2.16, are there any plans wrt the filechooser backend? mclasen: one could imagine a gio backend that gnome-vfs doesn't support mclasen: kinda surprising for the app But, in practice, probably not an issue alex_: I guess apps have to always be prepared for errors when loading from uris anyway, no ? yeah garnacho: i'd assume that for gtk 2.16 we'd drop the file selector backend and just use gio its already a vfs abstraction alex_: yeah, makes completely sense :) alex_: there is a bit of a compatibility question though since people might have custom backends that stop to work at that point not a common thing to do though i guess... Do we care about that? the filesystem api is only partially api/abi stable, and we already changed it Anyway, are there more gio questions? not from me, at least except for one mclasen, alex_ , if there is people have custom backend that breaks then we should help them fixit. Atleast me will be glad to replace it :-D what api additions do you foresee before gnome 2.22 ? davidz had a few things I think the major one is a way to get some sort of identifier for the backing object for GVolume/GDrive/GMount so you can go e.g. from a GVolume for a gphoto:/// mount to something you can feed to libgphoto and do more stuff There was also some talk about having a content type for mounts (i.e. music or photos) but thats probably gonna be prototyped in nautilus first ok what was the next topic ? I was also thinking today if we want defines for e.g. "standard::*" file attribute matchers? what would that be ? just some define to say ALL_IJN ALL_STANDARD_ATTRIBUTES ? G_FILE_ATTRIBUTE_STANDARD_ALL ? Maybe it just complicates stuff alternatively, you could do defines for the namespaces and teach the matcher to treat "standard" like "standard::*" ? alex_: did you want to add the size-in-bytes attribute, btw ? I wonder if it doesn't do that actually mclasen: oh, yeah. Maybe we should do that I dunno how important it is though not very, I think hmm.... your little loop is some master piece anyway, lets move on ok, before we leave glib does anybody have urgent api additions in the queue ? otherwise, I'd like to do an api frozen release as soon as the last gio additions are in probably next wewek * pbor has a gthread api which would like to see in... but I need a bit of time to get back to it well gthreadpool mclasen: not really urgent, bug #449565 would be nice to have note that we need release team permission now for api changes better to keep them to a minimum mclasen: I'd like for someone to comment on g_format_time_for_display() (bug 325064) chpe: you need to track down tjafk for that one ok tim seems to be quite busy those days... chpe: and G_DEFINE_INTERFACE ;) and G_DEFINE_QUARK tbf: I think he was sick mclasen: ah, ok. the gthreadpool one I was referring to: http://bugzilla.gnome.org/show_bug.cgi?id=456182 yes please to both those G_DEFINE_* macros ebassi: I'll look at it again xan: the INTERFACE variant has its own bug, #320482 chpe, yep, I remember and we need to comment there because in ephy we use it in the way that it would break with the proposed impl iirc ok we are over time already the G_DEFINE_INTERFACE patch probably should be updated for the latest in g_once goodness too anything else we need to discuss today ? guess extended layout also can be discussed on list? tbf: what is the latest news on that ? did you get it to work with size groups ? oh, wrt to #defines mclasen: sent patches with implement something similiar to havoc's api for gtklabel and gtkhbox i had to make my own for a G_IMPLEMENT_INTERFACE for dynamic modules mclasen: and got behdads natural size allocation right now mclasen: for size-groups vs. natural size i'd still like to hear some opinions G_IMPLEMENT_INTERFACE_DYNAMIC alex_: file a bug so we don't lose them behdad: just replacing minimum-size with natural-size in size groups breaks your distribution goals behdad for natural size aware containers honestly I don't quite know how size groups interact with allocation maybe I should study them a bit behdad: basically they just figure out the minimum size for all attached widget, and tweak the size-request each widget reports accordingly tbf: currently size groups use the max of the min-sizes right ? behdad: well, plus some graph coloring and such to deal with widgets attached to multiple size groups mclasen: yup right and the question is what to do with the natural sizes ? so, the individual widgets report the group's desired sizes, right? like max or some kind of average behdad: http://bugzilla.gnome.org/show_bug.cgi?id=508157 yup so, natural size for group should be max natural size of children 'cause otherwise natural size aware allocation breaks size groups min size for group should be max min size of children how does that work? size groups work with the assumtion, that widgets without expand flags will never get expanded over the minimum size humm, I see ok I see where the problem is now probably make widgets in a size group always get their natural size or something, no stretch. s/their size/their size groups natural size/ right which is the max. natural size of all widgets we can improve it later behdad: at least that would look somewhat correctly yeah * mclasen needs to pay attention to the washing machine repair man later