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