1 < ebassi> meeting time!
   2 < ebassi>  :-)
   3 < ebassi> as usual, the agenda is at: http://live.gnome.org/GTK+/Meetings
   4 < ebassi> 1. Decisions about the latest missing accessor functions
   5 < ebassi> 2. Potential API changes for better introspection/bindings. See Bug #621590
   6 < ebassi> 3. GDateTime in GLib? See Bug #50076
   7 < ebassi> 4. Proxy suport in GIO ? (need for reviewer) Bug #580341
   8 < ebassi> 5. miscellaneous
   9  * mclasen still in another meeting
  10 < jjardon> for the accessors, I think the most importatn ones are the ones that block some applications to be GSEAL-compatible. check the blue lines in http://live.gnome.org/GnomeGoals/UseGseal
  11 < ebassi> I think that mclasen said in a couple of occasions that he's not expected to comment on every single new accessor - but the GtkMessageDialog issue is an example of requiring some reviewe
  12 < jjardon> Altougth the problem with gnome-terminal was fixed today by federico
  13 < mclasen> I think the remaining ones are mostly head-scratchers where it is not clear that they represent a valid use case or should be done in a different way
  14 < jjardon> We should mark them as not valid then
  15 < mclasen> after sufficient head-scratching, yes
  16 < jjardon> make _gtk_window_group_get_current_grab() public has some explanations by the devels: https://bugzilla.gnome.org/show_bug.cgi?id=620832
  17 < jjardon>  GtkButton::in_button and GtkRange->has_stepper_X are less clear
  18 < jjardon> also, I propossed gtk_font_selection_dialog_get_font_selection () for glade and for completeness: we already have gtk_color_selection_dialog_get_color_selection ()
  19 < mclasen> I'm pretty sure I remember prior discussion with owen where he was opposed to exposing too much of the grab machinery
  20 < mclasen> but I can't find the bug now
  21 < jjardon> yeah, the problem is thar fontsel is exposed by the GtkBuilder api: http://git.gnome.org/browse/gtk+/tree/gtk/gtkfontsel.c#n1702
  22 < mclasen> this may be what I remember: https://bugzilla.gnome.org/show_bug.cgi?id=69934
  23 < mclasen> an oldie...
  24 < ebassi> nice :-)
  25  * jdahlin would like to add glib extensions such as bug 622396 to point 2) of the agenda
  26 < ebassi> anyway, I guess most of this stuff requires some sort of work around or API addition
  27 < ebassi> so - discussion in either the mailing list or bugzilla
  28 < jjardon> gsealed GNOME is scheluded to nex week
  29 < ebassi> jdahlin: eeek, iterator API!
  30 < mclasen> I think that is an artificial rush
  31 < ebassi> architecture astronauts
  32 < jdahlin> ebassi: only useful for language bindings, intended to solve real problems
  33 < jjardon> well, the glade bug is lees important as there won't be gsealed glade by next week
  34 < mclasen> things should get ported, yes, but only when they (and gtk) are ready for it..
  35 < ebassi> also, API/feature freeze date is aug 2/4
  36 < ebassi> so - seriously, we still have one month
  37 < mclasen> I think it is perfectly fine to have the one or other corner case not work with 2.90.x, either
  38 < mclasen> like libnotify using stuff
  39 < ebassi> it's not like distributions will switch to gtk 3.0 istantaneously
  40 < ebassi> and never ship gtk 2.x ever again
  41 < jjardon> My reasoning is that is not a valid use case, we shold mark them as that
  42 < mclasen> we will likely ship 2.x forever...
  43 < ebassi> forever, and then some
  44 < jjardon> yeah, but It would be nice that at least the GNOME core apps use GTK+3
  45 < jjardon> what about the gtk_font_selection_dialog_get_font_selection () api addition?
  46 < mclasen> bug # ?
  47 < ebassi> jjardon: you mean set_font_selection()?
  48 < jjardon> no bug, but is needed to gseal glade
  49 < jjardon> http://bugzilla.gnome.org/show_bug.cgi?id=594957
  50 < ebassi> do we bother sealing deprecated libraries?
  51 < kalikianatoli> no
  52 < ebassi> for deprecated libraries, I mean
  53 < ebassi> or you mean glade-the-application?
  54 < jjardon> fontselection is not deprecated
  55 < jjardon> oh, glade -the app, yes
  56 < kalikianatoli> deprecated means "already dying", dosn't it? so why would it help to seal it?
  57 < ebassi> mmh, tristan doesn't think Glade is going to be ready anyway
  58 < ebassi> so I'd say there's no hurry for that
  59  * mclasen fails to keep up with 2 meetings
  60 < kalikianatoli> would seem a bit sad, though, if Glade is supposed to be the standard gtk+ designer :-/
  61 < ebassi> kalikianatoli: yeah; but it would mean a lot of people starting to fix glade
  62 < jjardon> There are only 2 issues in glade: GTK_FONT_SELECTION_DIALOG (dialog)->fontsel and GTK_WIDGET_UNSET_FLAGS (widget, GTK_TOPLEVEL)
  63 < mclasen> I don't think a get_font_selection() method is going to be a problem
  64 < mclasen> we should probably just add it
  65 < jjardon> but the last one is not trivial
  66 < ebassi> or at least a single, highly motivated developer
  67 < kalikianatoli> jjardon, imho the unset flags use case is something that should change in glade
  68 < kalikianatoli> not trivial, though
  69 < mclasen> but as I said elsewhere, we really need someone to do a altogether new font dialog
  70 < ebassi> kalikianatoli, jjardon: maybe switching glade to GtkOffscreenWindow/Widget/Whatever
  71 < jjardon> ok, I'll add the new getter
  72 < jjardon> ebassi, yeah, that's the plan I think
  73 < jhs> mclasen: shouldn't be that difficult, see http://live.gnome.org/Design/GTKFontDialog/MockupSet1
  74 < kalikianatoli> mclasen, how do we find out what design is preferred? I would certainly be interested, but the discarded ideas make it seem difficult :-)
  75 < mclasen> mairin and behdad were looking at doing  a font dialog design at some point
  76 < jjardon> jhs, nice, I didn't know that page
  77 < ebassi> it would be nice to have some UI interaction designer time on that
  78 < jhs> kalikianatoli: look at my link
  79 < mclasen> I can ask them if anything came out of that
  80 < kalikianatoli> jhs, do you belong to the font dialog crew?
  81 < jhs> jjardon: maybe search/file a bug and CC some interested people
  82 < jhs> kalikianatoli: no
  83 < kalikianatoli> ah, misinterpretaed the "my" then
  84 < ebassi> okay, let's not sidetrack the discussion :-)
  85 < ebassi> new font selection dialog can be a topic for gtk 3.2 ;-)
  86 < mclasen> in any case, a new dialog would be a new widget, so is not affected by us adding accessors to the guts of the current one...
  87 < kalikianatoli> it *could* be the same as soon as the sealing is done ;-)
  88 < jjardon> kalikianatoli, are you sure?
  89 < jjardon> what will happen with the current api exposed bu GtkBuilder?
  90 < kalikianatoli> Well, I'm guessing the api we have is not too specific, we'll see when we have it
  91 < jjardon> I mean http://git.gnome.org/browse/gtk+/tree/gtk/gtkfontsel.c#n1702
  92 < kalikianatoli> Poke me when you find out what the preferred mockup is :-]
  93 < ebassi> jjardon: other issues with sealings?
  94 < jjardon> yeah
  95 < jhs> ebassi: Ihttps://bugzilla.gnome.org/show_bug.cgi?id=622186
  96 < jjardon> this ^
  97 < jhs> It's kind of a hack though. I rather would like to have a cleaner solution for the problem than using in_button directly but seems tricky.
  98 < ebassi> jhs: you're using in_button to basically simulate a enter/leave?
  99 < jjardon> ebassi, context: https://bugzilla.gnome.org/show_bug.cgi?id=577469#c16
 100 < kalikianatoli> jhs, that is not "kind of", that is pretty obviously working around a problem :-D
 101 < kalikianatoli> it even says literally so in the bug
 102 < jhs> kalikianatoli: yeah but I am just not so much into gtk+ details to know how to fix it and I didn't create the hack that is used. gdl code base is rather old...
 103 < ebassi> GtkButton::leave-notify-event already sets the in_button to FALSE - why is it required to set it explicitly?
 104 < ebassi> by the code, faking a leave-notify-event with that event would lead to in_button = FALSE
 105 < jhs> ebassi: faking?
 106 < ebassi> (though I admit that faking an event is not the best way to handle this kind of stuff)
 107 < ebassi> jhs: you're creating a CrossingEvent and then emitting ::leave-notify-event directly
 108 < ebassi> in gdl_dock_item_grip_fix_iconify_button()
 109 < kalikianatoli> goes a bit in the direction of the pressed/ released functions which were deprecated
 110 < ebassi> yeah
 111 < jhs> ebassi: ok, sounds kind of reasonable! I would very much appreciate if someone could attach some example code to the bug. Otherwise seems fine - let's go on.
 112 < jjardon> ok, the last one GtkRange->has_stepper_X: https://bugzilla.gnome.org/show_bug.cgi?id=621250
 113 < jjardon> It's blocking gtk-engines
 114 < kalikianatoli> the last comment seems pretty clear to me
 115 < ebassi> yup
 116 < kalikianatoli> maybe I can have a look at that tomorrow, should be straightforward
 117 < mclasen> should not be hard, indeed
 118 < mclasen> there's examples of this kind of stuff in gtktreeview, eg
 119 < jjardon> so: I'll make a getter for the fontsel, there are solutions for the rest and _gtk_window_group_get_current_grab() needs mor discussion
 120 < ebassi> cool
 121 < mclasen> I'll ask owen if he remembers the old discussion about grabs
 122 < jjardon> If anyone can provide some code to jhs issue would be great
 123 < ebassi> jjardon: the patch looks already good - without the explicit in_button = FALSE
 124 < ebassi> right, next item?
 125 < mclasen> did we have more topics ? I'm sure we did
 126 < ebassi> • Potential API changes for better introspection/bindings. See Bug #621590
 127 < jjardon> ebassi, comment in the bug then ;)
 128 < ebassi> jjardon: roger
 129  * mclasen comments in 621590
 130 < ebassi> so, walters was asking if we could bend the rule of minimal recompilation for API that's hard/impossible to bind
 131 < kalikianatoli> is this about gtk_quit_add?
 132 < mclasen> gtk_tree_path_get_indices
 133 < jjardon> well, as people has already to do some port work (use accessor functions), I think little changes like this can be allowed
 134 < jjardon> If they are really needed
 135 < kalikianatoli> it would suck for anyone trying to keep supporting gtk2
 136 < kalikianatoli> which is one of the reasons to not allow it
 137 < pbor> on the other hand we could come up with a slightly different name, keep both in gtk2 and just the new one in gtk3
 138  * kalikianatoli is with pbor on that one
 139 < jjardon> yeah, I was going to suggest the same as pbor 
 140 < jjardon> and deprecate the old one
 141 < mclasen> what better names are available ?
 142 < ebassi> get_path_indices()
 143 < ebassi> though a bit redundant
 144 < ebassi> get_components(), though slightly a misnomer
 145 < ebassi> split()
 146 < ebassi> decompose()
 147 < kalikianatoli> _get_current_indices
 148 < ebassi> to_indices()
 149 < kalikianatoli> (based on the documentation calling it that)
 150  * mclasen had thought about to_
 151  * tadeboro votes for to_
 152  * kalikianatoli likes to_ as well
 153 < ebassi> we have from_indices(), from_string() and to_string()
 154 < ebassi> so to_indices() would map
 155 < kalikianatoli> a good chance to increase consistency :-)
 156  * ebassi likes symmetry ;-)
 157 < jjardon> great, anyone can comment in the bug?
 158 < ebassi> sure
 159 < kalikianatoli> I will do
 160 < jjardon> Also, we should announce that we are open to this kind of fixes to help bindings people
 161 < jjardon> ebassi, Can you in the meeting minutes?
 162 < ebassi> sure
 163 < mclasen> tbh, I don't see how this specifically helps bindings 
 164 < mclasen> the function was already there, just with a slightly clunky name...
 165 < ebassi> mclasen: overriding the name requires ad hoc code that introspection-based bindings not always can afford
 166 < mclasen> do we have annotations that let us fix that, theoretically ?
 167 < jjardon> mclasen, http://live.gnome.org/GObjectIntrospection/WritingBindingableAPIs
 168 < jjardon> and the mail from tomeu: http://mail.gnome.org/archives/desktop-devel-list/2010-June/msg00105.html
 169 < mclasen> like do-not-bind and bind-as-some-other-name ?
 170 < davidz> Rename To:?
 171 < ebassi> mclasen: we can hide functions, but I don't think bind-as-another-name is implemented/works
 172 < davidz> I saw Rename to: being used in gdbus for the _with_closures() stuff....
 173 < davidz> (see http://live.gnome.org/GObjectIntrospection/Annotations )
 174 < mclasen> ah, nice
 175 < davidz> see http://git.gnome.org/browse/glib/commit/?id=45e604d029980f90a7304b6311fc43cc0cc2ab69
 176 < davidz> for the commit
 177 < mclasen> in this case, and we should just take the _to_indices name it to improve the C api  (with proper deprecations for the _with_depth variant)
 178 < mclasen> but good to know that a renaming facility exists
 179 < ebassi> right, so the message is: we can fix API warts that make the life of bindings harder, but only by deprecation+addition, not changes
 180 < danw> no
 181 < danw> you can leave the warty method as is, and rename the more-bindable method to have the name of the old warty method
 182 < mclasen> well, the problematic part is having the same name for different functions in 2.x and 3
 183 < danw> and then C sees the old method still, but bindings see the new method (with the old name)
 184 < jdahlin> there are both ways to hide apis from introspection and export apis with different names
 185 < mclasen> next topic ?
 186 < ebassi> GDateTime
 187 < ebassi> but 50076
 188 < ebassi> another oldie, but goldie
 189 < ebassi> I did a review - there are some issues
 190  * mclasen just doesn't have the time and inclination to get involved with that
 191 < ebassi> mostly: the timezone support in the API relies on tz_data, and this means not supporting XP pre-SP2
 192 < ebassi> AFAIR
 193 < ebassi> the API looks good, and in theory we could land the timezone API at a later date
 194 < ebassi> I'd just wish to have a proper date/time API in glib :-)
 195 < mclasen> how does this relate to GDate ? does it obsolete it, extend it, or none of the above ?
 196 < thiagoss_> None of the above
 197 < jjardon> then can be used in GtkCalendar 
 198 < ebassi> thiagoss_: well, no - it mostly obsoletes it, though a date-only API can be kept if you need day/month resolution
 199 < mclasen> I would be much more receptive if it was a wholesale replacement
 200 < mclasen> having a GDate and GDateTime unrelated next to each other in the same library seems like a nonstarter
 201 < thiagoss_> ebassi: I guess you're right. Everything in GDate API could be done in a GDateTime as well
 202 < ebassi> yeah
 203 < ebassi> I see DateTime as an enhancement with smaller granularity
 204 < ebassi> you can ignore the Time part and still have a propert Date API
 205 < jjardon> So, GDateTime can deprecate GDate. Rigth?
 206 < kalikianatoli> yes
 207 < ebassi> I'd like to see GtkCalendar get some support for it as well; then we could judge the impact
 208 < jjardon> ebassi, Did you ask tml about the tz_data issue and XP ? Maybe he knows
 209 < ebassi> jjardon: that was thiagoss_ task :-)
 210 < jjardon> thiagoss_, ^^ ;)
 211 < ebassi> jjardon: in theory, XP post-SP2 (which is what microsoft supports) has the API
 212 < ebassi> pre-SP2 is not supported any more
 213 < jjardon> not a bug problem then, I'd say
 214 < jjardon> big*
 215 < kalikianatoli> ah, so that sounds good enough then. I thought it were vista-only
 216 < danw> and if people are running pre-SP2, we can just hack into their machines remotely to upgrade them
 217 < ebassi> and, if we wanted to support it, we could eventually ship the tz_data database ourselves - though it would require sync with upstream
 218 < kalikianatoli> (imho good enough)
 219 < ebassi> danw: hahahaha
 220 < danw> we don't want to ship tz_data ourselves
 221 < ebassi> g_date_time_win32_hack_xp_and_update()
 222 < danw> it changes too often, and it's vaguely important that it be up-to-date-ish
 223 < kalikianatoli> well, we could leave anyone who *really* wants, to ship it
 224 < jjardon> danw, or install other thing directly :P
 225 < ebassi> agree
 226 < danw> btw i think glib may currently still support windows 2000, though i'm not certain of that
 227 < thiagoss_> FYW libgweather has a --timezone-info-dir configure option that allows people to tell where their tzdata is installed. If pre-sp2 xp users want it, they can install and configure with this option
 228 < danw> and it might just be a "nothing has broken it yet" thing rather than than a "this is important" thing
 229 < thiagoss_> let me get the list of supported windows versions
 230 < thiagoss_> (for the timezone api, that is)
 231 < kalikianatoli> so... do we mostly agree on leaving the ancient windowses to those who care to ship the archive?
 232 < ebassi> aye
 233 < kalikianatoli> cool
 234 < danw> i think we should have a special magic name for "the local timezone", and on pre-API windows, glib would only support 
 235               the local timezone and UTC, and it would just not recognize any other timezone names
 236 < kalikianatoli> danw, yeah, that's what I suggested sometime before, to hardwire "local" and "UTC"
 237 < thiagoss_> According to: http://msdn.microsoft.com/en-us/library/system.timezoneinfo.aspx -> Windows 7, Windows Vista SP1 or later, Windows XP SP3, Windows Server 2008 (Server Core Role not supported), Windows Server 2008 R2 (Server Core Role not supported), Windows Server 2003 SP2
 238 < danw> that's a .NET API not a Win32 API...
 239 < ebassi> we probably need tml's expertise on this
 240 < ebassi> right, we can punt this until we know what kind of support win32 has and how much alcohol do we need to stop caring :-)
 241 < mclasen> sorry, I lost network here
 242 < mclasen> so I missed the last 10 minutes
 243 < ebassi> thiagoss_: it would be nice to get tml's opinion on the bug
 244 < thiagoss_> ebassi: Ok, I'll keep searching here for the correct win32 API
 245 < thiagoss_> I've seen it around once, just can't find it anymore
 246 < ebassi> mclasen: generally, the idea is that win32 has some issues with the timezone data
 247 < ebassi> mclasen: we can ideally ignore that and just allow localtime+UTC on win32
 248 < ebassi> mclasen: tml will probably know more
 249 < ebassi> thiagoss_: thanks
 250 < jjardon> mclasen, http://pastebin.com/SutJnfFF
 251 < ebassi> I'll keep reviewing the patch
 252 < mclasen> me ? win32 ? no
 253 < thiagoss_> Think I found it: http://msdn.microsoft.com/en-us/library/ms725473(v=VS.85).aspx
 254 < thiagoss_> Doesn't look promising to full timezone support
 255 < mclasen> where do timezones show up in the api currently ? 
 256  * mclasen doesn't see it
 257 < kalikianatoli> mclasen, in g_date_time_new_full
 258 < kalikianatoli> you can pass it as the last argument
 259 < mclasen> but there seems no way to query the timezone ?
 260 < mclasen> if that makes conceptual sense in the first place
 261 < kalikianatoli> the patch was stripped for easier review
 262 < kalikianatoli> I think we likely want that in the end
 263 < thiagoss_> mclasen: I have another patch that adds a _get_time_zone
 264 < ebassi> mclasen: in theory, you can create a GTimeZone by giving it the name - glib would fetch the data from the timezone database
 265 < ebassi> that would be the automagic way of having a per-timezone date+time and then converting it
 266 < thiagoss_> So, summarizing: we need to ask tml about win32 support availability and I need to port GtkCalendar to use it?
 267 < ebassi> thiagoss_: yes to the former, would-be-nice to the latter
 268 < ebassi> you always find interesting caveats when porting API :-)
 269 < danw> see what they do for evolution... maybe they're already shipping tzdata for that i guess...
 270 < ebassi> right, good point
 271 < ebassi> okay, final point?
 272 < ebassi> well, apart from jdahlin's iterator api?
 273 < ebassi> • Proxy suport in GIO ? (need for reviewer) Bug #580341
 274  * danw pokes stormer
 275 < stormer> yeah, so as it says 
 276 < stormer> We need a reviewer
 277 < danw> part of this is "when is the feature freeze for glib?" is it the same as GNOME?
 278 < sjoerd> danw: assuming for a moment that it is the same, (thus august 2, would that be problematic?
 279 < sjoerd> or are you worried that glib should be freezing earlier even?
 280 < danw> not "should" but maybe "is"
 281 < danw> glib and gtk are often on an earlier schedule than the rest of gnome
 282 < jjardon> AFAIK, not in the latest releases
 283 < danw> anyway, there's problems either way, which is that stormer and i disagree on how it should work and alex is mostly missing this cycle and no one else is paying attention, and so regardless of whether we do it my way or stormer's way, there's a chance that it will be wrong
 284 < sjoerd> gtk was quite late in the last round, not sure about glib
 285 < jdahlin> ebassi: 
 286 < jdahlin> ebassi: I'll think a bit more about it
 287 < sjoerd> Right so basically we need some other people to pitch in/speed up the discussion?
 288 < stormer> danw, one of the problem is that you never took time to explain on what you disagree exactly
 289 < danw> i thought i did several times?
 290 < danw> https://bugzilla.gnome.org/show_bug.cgi?id=580341#c39 in particular seems to sum it up
 291 < stormer> I've been continuasly updating the code
 292 < danw> and the problem is, *i don't know if i'm right*
 293 < stormer> Ok, conclusion we need more people in that loop
 294 < danw> right
 295 < sjoerd> I'm happy to spend some time to go through the discussion and give my pov if that would be helpful
 296 < sjoerd> Is there anyone else knowledgeble about the gio networking stuff we could try to get involved?
 297 < danw> alex, desrt, maybe Company
 298 < stormer> sjoerd: I think as one of the user of GSocketClient it would be great
 299 < danw> but i don't know if any of them know anything about proxies either...
 300 < danw> my worry is that the API is being tailed for a use case that affects like 0.0001% of users
 301 < danw> tailored
 302 < sjoerd> Which use-case is that ?
 303 < danw> gssapi encrypted socks
 304 < sjoerd> I can agree that's a not very important one, but it would be nice to at least have the possibility to support it right ?
 305 < danw> as currently written, adding support for that means we cannot support using GSocket directly when there is a proxy
 306 < stormer> I think we can accept the compromize the you cannot have tunneled proxy with GSocket
 307 < danw> OTOH, i'm not sure that people are really using plain GSocket
 308 < sjoerd> I never saw a reason to use plain GSocket
 309 < stormer> I don't see a reason either, for me GSocket is just a thin wrapper over FD to make it friendlier
 310 < sjoerd> That might be because where i'm coming from, but i want to be able to layer may communications protocol over whatever underlying thing (which may not have a direct socket)
 311 < sjoerd> Also i'm guessing in a lot of cases you want to be able to work over SSl anyway, in which case GSocket is also not very useful?
 312 < danw> well, SSL is another problem; all the SSL libraries assume a posix-like API underneath then, and it's extremely awkward to try to put a GIOStream underneath them instead (as already discussed in that bug)
 313 < sjoerd> That's what we do in wocky and it works quite well for us tbh
 314 < sjoerd> both gnutls and openssl you can use without giving them the fd directly..
 315 < danw> are you using async I/O?
 316 < sjoerd> I'd actually suggest not given gnutls a socket, we used to have loads and loads of pain in loudmouth because of bugs there
 317 < sjoerd> all our I/O is async yes
 318 < danw> well, i'll have to look at your code then
 319 < sjoerd> I'm not familiar with nss unfortunately
 320 < sjoerd> Our code actually came from gnio back in the day and was hacked up to our needs a bit
 321 < danw> for purposes of the current discussion, it behaves identically to gnutls and openssl
 322 < danw> oh, well, yeah, but that code is kind of a monstrosity as compared to using a GSocket directly
 323 < sjoerd> That code is scary yes, but that's more because of how it's written then anything else imho
 324 < danw> no, it's inherent to the problem
 325 < danw> anyway
 326 < danw> so perhaps the outstanding question is, do we expect applications to use GSocket directly?
 327 < danw> s/expect/want to encourage/
 328 < sjoerd> I'd encourage them not to
 329 < stormer> Aside UDP of course
 330 < sjoerd> One of the nice things about GIO is to have these nice stackable streams, encouraging apps to use GSocket breaks that part
 331 < sjoerd> To give you an idea of the crack we might be doing in telepathy at some point: we want to create direct secure peer to peer connections through nat, for which we use a reliable protocol over udp (which can punch a nat).. Which in turn we want to expose as a GIOStream to higher levels
 332 < sjoerd> If we can just stack SSl on top of such an io stream that would be immensely helpful
 333 < danw> yeah...
 334 < sjoerd> That's a quite extreme use-case but still :)
 335 < danw> still no mclasen. guess we lost him for good
 336 < stormer> he said he had network issues
 337 < danw> yeah, he disappeared before but eventually reappeared
 338 < sjoerd> I guess it's basically impossible to target both TLS and proxy support for this glib round, so imho we should focus on getting the proxy stuff done
 339 < sjoerd> Shall i go through the bug and some of stormers code and maybe start a discussion on gtk-devel (or is there a better list for this) to see if we can get more attention to it ?
 340 < ebassi> sjoerd: gtk-devel would be good
 341 < danw> or d-d-l
 342 < danw> let me try to re-sum-up some of the issues in the bug
 343 < danw> i think i'm convinced on the socket vs socketconnection thing
 344 < danw> definitely feel free to look through the code though
 345 < ebassi> okay, we finished the items on the agenda - unless someone has new items (though we ran over the 2 hours mark) we can close the meeting for tonight?
 346 < danw> also, we lost mclasen, so...
 347 < stormer> good for me, danw we could start back on the mailing list tomorrow and start with the remaining issues, will let people think and have a look maybe
 348 < ebassi> right :-)
 349 < ebassi> next meeting should be july 6th
 350 < ebassi> then I guess we can have something at guadec
 351 < ebassi> depending on the attendance
 352 < ebassi> I personally look forward to a real-life gtk meeting; if it's like the past years, I'll bring knives and other weapons
 353 < jjardon> haha
 354  * stormer hmm wonders if GUADEC safe place to go finally ?
 355 < ebassi> jjardon: you weren't there in istanbul - that was fun ;-)
 356 < ebassi> it was the time when we started discussing the 3.0 roadmap
 357 < jjardon> ebassi, oh
 358 < jjardon> I understand now ;)
 359 < ebassi> have a good night/evening/afternoon everyone