1 <ebassi> we can begin, then 2 <mclasen> wrt to "next gio release" 3 <mclasen> err, next glib release 4 <mclasen> that has happened yesterday 5 <mclasen> partly because I was confused about stable vs devel deadlines... 6 <mclasen> and I think it should have all of the major api changes for gio at this point 7 <ebassi> 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 8 <mclasen> I think it is safe, certainly 9 <mclasen> the file monitor api did change in 2.15.1 10 <mclasen> but it should be final now 11 <ebassi> okay, thanks 12 <chpe> what about the filesystem backend? is that ready for libgnomeui (feature freeze for 2.22 is next week) ? 13 <mclasen> 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... 14 <pbor> 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 15 <pbor> (since it cannot browser ftp etc) 16 <garnacho> chpe: mostly I think, I cant cook a patch today or tomorrow 17 <chpe> garnacho: can or can't ? :) 18 <alex_> pbor: Thats more of a general regression 19 <garnacho> chpe: argh, can :) 20 <chpe> garnacho: that's be great 21 <alex_> pbor: At the moment it looks likely that we won't get an ftp backend for 2.22 22 <alex_> I would love it if someone wanted to work on onw 23 <alex_> one 24 <pbor> alex_: sure, but an apt can "opt in" to use gio as a lib, while the filechooser is what it gets from gtk 25 <pbor> app* 26 <alex_> pbor: sure, but the file manager (and thus the "desktop") uses gio 27 <danw> alex_: would a generic wrap-a-gnome-vfs-backend-into-a-gvfs-backend backend be easier? 28 <tbf> so the ftp regression is general 29 <pbor> alex_: anyway as I told you the other day I don't think it's a big problem, just something to be aware of 30 <alex_> danw: I'm not sure really. 31 <alex_> An ftp backend shouldn't be to much work 32 <alex_> I think getting a gnome-vfs mapping backend going is easy 33 <alex_> but getting it to work well in the corner cases will be quite hard 34 <mclasen> alex_: what are the other major "missing-backend" regressions at this point ? 35 <alex_> computer:, network:, burn:, http/dav, obex-ftp 36 <tielie> 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? 37 <alex_> I'll probably finish computer tomorrow 38 <tielie> alex_, webdav/http is importtant backend 39 * jdahlin reserves tickets to the berlin hackfest 40 <alex_> then i'll do network and burn 41 <alex_> gicmo/danw is working on http/dav 42 <alex_> danw: status? 43 <tielie> is there no one working on http/webdav backends? 44 <tielie> hupps 45 <danw> alex_: i still wasn't working on it. i was looking for gicmo on irc this morning but he wasn't around 46 <alex_> rhult started on obex-ftp but had to stop due to lack of time 47 <hpj> alex_: confirm the ftp backend non-availability, i haven't had time to work on it 48 <alex_> danw: yeah, he's been away during xmas 49 <alex_> danw: but was around yesterday a bit 50 <alex_> danw: He seems busy 51 <danw> alex_: so i don't know what the state is, or even where the code is 52 <danw> alex_: busy-with-http-backend or too busy to work on it? 53 <alex_> danw: Maybe you can mail him and ask about the status 54 <danw> yeah 55 <alex_> danw: maybe he needs some help with it 56 <alex_> danw: busy-with-life as i read it 57 <danw> mailed 58 <alex_> tielie: So, i'm no c++ expert 59 <alex_> tielie: but being a keyword seems sort of bad 60 <alex_> anyone know c++ details like that? 61 <chpe> 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 62 <chpe> or at least I thought there was a test, can't seem to find it now 63 <behdad> alex_: pango has a test to compile all headers with c++. check pango/cxx-test.C. I remember tbf doing something similar in glib? 64 <behdad> maybe it was gtk 65 <tbf> behdad: gtk, afair 66 <behdad> nah, glib/tests/cxx-test is there 67 <behdad> alex_: just hook up gio into it 68 <behdad> and gthread probably 69 <behdad> (and gio-unix.h) 70 <mclasen> coming back to the filechooser backend 71 <alex_> seems to work.. 72 <mclasen> putting it in libgnomeui in _addition_ to the gnome-vfs one shouldn't block on the regressions, right ? 73 <chpe> yes, I assumed it wouldn't _replace_ the gnome-vfs one, just be parallel to it 74 <pbor> 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? 75 <alex_> still, how does an app pick the backend? 76 <mclasen> pbor: right 77 <mclasen> alex_: there is a gconf key 78 <mclasen> apps can override it when constructing the file chooser, but they rarely do 79 <alex_> i though it was just a "can use uris" or not 80 <mclasen> thats a separate thing 81 <tbf> can we check, that gnome-vfs is initialized? 82 <tielie> 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? 83 <alex_> I commited the updated cxx-test. Works fine with gio. 84 <tbf> in that case load the gnome-vfs backend, otherwise gvfs? 85 <tbf> (i know: whack idea) 86 <alex_> kinda hard to do without linking to gnome-vfs, isn't it? 87 <alex_> Also, doesn't e.g. libgnomeui init gnome-vfs? 88 <danw> i thought libgnomeui set gtk to use the gnome-vfs backend rather than the default backend? 89 <chpe> it does, yes 90 <chpe> danw: g-s-d does, via the libgnome schema entry for it 91 <behdad> alex_: should the toplevel gio include be gio.h instead of gio/gio.h? 92 <behdad> I mean: 93 <behdad> #include <glib.h> 94 <behdad> #include <gmodule.h> 95 <behdad> #include <glib-object.h> 96 <behdad> #include <gio/gio.h> 97 <behdad> doesn't look right 98 <alex_> behdad: it was discussed on the list 99 <alex_> we're not really consistent in the stack 100 <chpe> 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" ? 101 <alex_> with e.g. gtk being gtk/gtk.h 102 <behdad> right, but in the same module at least... 103 <behdad> but if you already discussed, fine. 104 <alex_> I kinda like the subdir thing 105 <mclasen> behdad: between glib and gtk+, the damage is already done 106 <alex_> seems less namespace polluting 107 <mclasen> in terms of consistency 108 <behdad> maybe make the old ones also work like new ones. that is, make glib/glib.h work 109 <alex_> more obvious that the thing is some library rather than a local include 110 <behdad> yes 111 <mclasen> chpe: I don't really think apps should do anything special; having the opt-in be a user decision is fine for me 112 <mclasen> until we are ready to do the switch 113 <alex_> mclasen: Its really an app decision though 114 <alex_> mclasen: its the app that loads the file returned by the file selector 115 <alex_> and if it loads with gnome-vfs, it should get a gnome-vfs uri 116 <alex_> and vice versa 117 <alex_> Now, in practice the uris are the same 118 <mclasen> I don't think the file chooser returns anything gnome-vfs specific, does it ? 119 <alex_> so its mostly a problem with regressions in gvfs backend support 120 <garnacho> btw, as for gtk+ 2.16, are there any plans wrt the filechooser backend? 121 <alex_> mclasen: one could imagine a gio backend that gnome-vfs doesn't support 122 <alex_> mclasen: kinda surprising for the app 123 <alex_> But, in practice, probably not an issue 124 <mclasen> alex_: I guess apps have to always be prepared for errors when loading from uris anyway, no ? 125 <alex_> yeah 126 <alex_> garnacho: i'd assume that for gtk 2.16 we'd drop the file selector backend and just use gio 127 <alex_> its already a vfs abstraction 128 <garnacho> alex_: yeah, makes completely sense :) 129 <mclasen> alex_: there is a bit of a compatibility question though 130 <mclasen> since people might have custom backends that stop to work at that point 131 <mclasen> not a common thing to do though 132 <alex_> i guess... Do we care about that? the filesystem api is only partially api/abi stable, and we already changed it 133 <alex_> Anyway, are there more gio questions? 134 <mclasen> not from me, at least 135 <mclasen> except for one 136 <tielie> 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 137 <mclasen> what api additions do you foresee before gnome 2.22 ? 138 <alex_> davidz had a few things 139 <alex_> I think the major one is a way to get some sort of identifier for the backing object for GVolume/GDrive/GMount 140 <alex_> so you can go e.g. from a GVolume for a gphoto:/// mount to something you can feed to libgphoto and do more stuff 141 <alex_> 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 142 <mclasen> ok 143 <mclasen> what was the next topic ? 144 <alex_> I was also thinking today if we want defines for e.g. "standard::*" file attribute matchers? 145 <mclasen> what would that be ? just some define to say ALL_IJN 146 <mclasen> ALL_STANDARD_ATTRIBUTES ? 147 <alex_> G_FILE_ATTRIBUTE_STANDARD_ALL ? 148 <alex_> Maybe it just complicates stuff 149 <mclasen> alternatively, you could do defines for the namespaces 150 <mclasen> and teach the matcher to treat "standard" like "standard::*" ? 151 <mclasen> alex_: did you want to add the size-in-bytes attribute, btw ? 152 <alex_> I wonder if it doesn't do that actually 153 <alex_> mclasen: oh, yeah. Maybe we should do that 154 <alex_> I dunno how important it is though 155 <mclasen> not very, I think 156 <tbf> hmm.... your little loop is some master piece 157 <alex_> anyway, lets move on 158 <mclasen> ok, before we leave glib 159 <mclasen> does anybody have urgent api additions in the queue ? 160 <mclasen> otherwise, I'd like to do an api frozen release as soon as the last gio additions are in 161 <mclasen> probably next wewek 162 * pbor has a gthread api which would like to see in... but I need a bit of time to get back to it 163 <pbor> well gthreadpool 164 <chpe> mclasen: not really urgent, bug #449565 would be nice to have 165 <behdad> note that we need release team permission now for api changes 166 <behdad> better to keep them to a minimum 167 <ebassi> mclasen: I'd like for someone to comment on g_format_time_for_display() (bug 325064) 168 <mclasen> chpe: you need to track down tjafk for that one 169 <chpe> ok 170 <tbf> tim seems to be quite busy those days... 171 <xan> chpe: and G_DEFINE_INTERFACE ;) 172 <tbf> and G_DEFINE_QUARK 173 <mclasen> tbf: I think he was sick 174 <tbf> mclasen: ah, ok. 175 <pbor> the gthreadpool one I was referring to: http://bugzilla.gnome.org/show_bug.cgi?id=456182 176 <behdad> yes please to both those G_DEFINE_* macros 177 <mclasen> ebassi: I'll look at it again 178 <chpe> xan: the INTERFACE variant has its own bug, #320482 179 <xan> chpe, yep, I remember 180 <xan> and we need to comment there because in ephy we use it in the way that it would break with the proposed impl iirc 181 <mclasen> ok we are over time already 182 <danw> the G_DEFINE_INTERFACE patch probably should be updated for the latest in g_once goodness too 183 <mclasen> anything else we need to discuss today ? 184 <tbf> guess extended layout also can be discussed on list? 185 <mclasen> tbf: what is the latest news on that ? 186 <mclasen> did you get it to work with size groups ? 187 <alex_> oh, wrt to #defines 188 <tbf> mclasen: sent patches with implement something similiar to havoc's api for gtklabel and gtkhbox 189 <alex_> i had to make my own for a G_IMPLEMENT_INTERFACE for dynamic modules 190 <tbf> mclasen: and got behdads natural size allocation right now 191 <tbf> mclasen: for size-groups vs. natural size i'd still like to hear some opinions 192 <alex_> G_IMPLEMENT_INTERFACE_DYNAMIC 193 <behdad> alex_: file a bug so we don't lose them 194 <tbf> behdad: just replacing minimum-size with natural-size in size groups breaks your distribution goals 195 <tbf> behdad for natural size aware containers 196 <behdad> honestly I don't quite know how size groups interact with allocation 197 <behdad> maybe I should study them a bit 198 <tbf> behdad: basically they just figure out the minimum size for all attached widget, and tweak the size-request each widget reports accordingly 199 <mclasen> tbf: currently size groups use the max of the min-sizes right ? 200 <tbf> behdad: well, plus some graph coloring and such to deal with widgets attached to multiple size groups 201 <tbf> mclasen: yup 202 <behdad> right 203 <mclasen> and the question is what to do with the natural sizes ? 204 <behdad> so, the individual widgets report the group's desired sizes, right? 205 <mclasen> like max or some kind of average 206 <alex_> behdad: http://bugzilla.gnome.org/show_bug.cgi?id=508157 207 <tbf> yup 208 <behdad> so, natural size for group should be max natural size of children 209 <tbf> 'cause otherwise natural size aware allocation breaks size groups 210 <behdad> min size for group should be max min size of children 211 <behdad> how does that work? 212 <tbf> size groups work with the assumtion, that widgets without expand flags will never get expanded over the minimum size 213 <behdad> humm, I see 214 <behdad> ok I see where the problem is now 215 <behdad> probably make widgets in a size group always get their natural size or something, no stretch. 216 <tbf> s/their size/their size groups natural size/ 217 <behdad> right 218 <tbf> which is the max. natural size of all widgets 219 <behdad> we can improve it later 220 <tbf> behdad: at least that would look somewhat correctly 221 <behdad> yeah 222 * mclasen needs to pay attention to the washing machine repair man 223 <mclasen> later
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.