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
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.