1 < ebassi> yey, meeting time
   2 < awalton__> huzzah
   3 < bratsche> yay
   4 < kris> hello
   5 < ebassi> problem is: no mclasen :-)
   6 < kris> where is timmy
   7 < ebassi> hey kris 
   8 < kris> timmy timmy timmy
   9 < awalton__> bratsche, thanks for adding gicon to the widget ;)
  10 < bratsche> awalton__: Thanks for the suggestion!
  11 < bratsche> awalton__: I'm finally trying to get back to work on this now. :)
  12 < timj> here
  13 < bratsche> I just got the tooltips working a little while ago.  But I need to rethink how the icons are in the entry, and if it should support multiple icons on each side.
  14 < ebassi> bratsche: my gut feeling is "no more than one on each side"
  15 < awalton__> gotta side with ebassi on this one. it's one of the things that somewhat makes firefox's awesomebar feel cluttered
  16 < kris> I agree with that gut feeling
  17 < kris> and you prolly want to swap sides in RTL mode
  18 < bratsche> ebassi: Yeah, that's mine too I think.
  19 < bratsche> Does anyone happen to know how you actually active the different icons in Firefox using the keyboard?
  20 < ebassi> just as a note - the agenda for the meeting is here: http://live.gnome.org/GTK+/Meetings
  21 < awalton__> bratsche, or rather, can you? I don't think it's possible atm.
  22 < kris> ebassi: did mclasen say he would be late, or?
  23 < bratsche> awalton__: I'm not sure.  I guess this discussion could be saved for when there's not a gtk meeting going on. :)
  24 < bratsche> ping me when we get to #2 on the list, because I want to find out how I can help with this (and other related things kris posted to gtk-devel-list)
  25 < ebassi> kris: not to me
  26 < timj> ebassi: hm, can we just start to go through the agenda now?
  27 < ebassi> timj: fine by me :-)
  28 < ebassi> 1. #
  29 < ebassi> Migration of glib/gdk(-pixbuf)/gtk documentation from /tmpl to source (ensonic, awalton)
  30 < awalton__> ahh me first eh?
  31 < kris> I was wondering what is going to happen with all the "blurb" in the docs that are above the descriptions of all functions
  32 < awalton__> you can put them in the head of the section with gtkdoc
  33 < awalton__> you just have to do a SECTION:whatever comment
  34 < kris> will they move to the source or not?
  35 < ebassi> kris: to the source file
  36 < awalton__> indeed. all of it will.
  37 < kris> yea
  38 < kris> and where in the source file?
  39 < kris> is there an example?
  40 < ensonic> hi
  41 < awalton__> kris, all of GIO
  42 < kris> oh
  43 < awalton__> hello ensonic, right on time.
  44 < ebassi> kris: all of clutter, cairo
  45 < kris> sorry ;)
  46 < kris> all these components are so new
  47 < kris> I am getting old
  48 < bratsche> heh
  49 < awalton__> heh, I was new to it myself, but I like it,.
  50 < awalton__> I think having them in the code makes people more likely to focus on the docs as well.
  51 < kris> yes I fully agree with that
  52 < kris> because I was about to say that I never dared to touch the tmpl files
  53 < kris> until I think a year ago
  54 < ebassi> awalton__: like it myself - it's very nice to have documentation coupled with the functions; it might head to improvements in the docs :-)
  55 < rhult> it makes it really nice when reading to code too, to see the docs in the same place
  56 < kris> although I am a bit worried about inserting a 20K blurb at the top of certain source files
  57 < ebassi> hey mclasen 
  58 < bratsche> yay
  59  * mclasen managed to miss the meeting
  60 < rhult> kris, yea it might not make sense for the "conceptual" doc pieces
  61 < kris> but I guess I am not allowed to complain
  62 < kris> rhult: yea
  63 < ebassi> kris: it's not xml - mostly would be plain text, and no section is that big
  64 < awalton__> kris, if it's a huge amount of text, it could be included externally, but I'm not sure we have many places where that'd be a problem?
  65 < ebassi> mclasen: we just started
  66 < bratsche> mclasen: We're on item #1 in the agenda right now.
  67 < bratsche> http://live.gnome.org/GTK+/Meetings'
  68 < rhult> mclasen, we just started on the first item so you haven't missed a lot
  69 < bratsche> http://live.gnome.org/GTK+/Meetings
  70 < mclasen> ah, ok
  71 < kris> awalton__: yeah I think we'll manage
  72 < mclasen> I think the 'no tmpl' approach has worked pretty well for gio
  73 < kris> may I suggest maybe just ignoring all deprecated crap when moving stuff from tmp to source?
  74 < mclasen> as in 'leaving it behind in tmpl' or 'stripping its documentation out' ?
  75 < awalton__> well I'd hate to do that... but at least waving some more flags at people to ignore the function would be nice.
  76 < ensonic> kris: not really feasable
  77 < ebassi> kris: deprecated since 1.2?
  78 < ebassi> I would keep the deprecated-since-2.0
  79 < kris> I was thinking of leaving behind, but that is not feasible?
  80 < ensonic> kris: the goal is also to get rid of the tmpl dir in total
  81 < kris> ok
  82 < kris> was just looking into saving some work for you guys ;)
  83 < kris> I think this will be very awesome to have btw ;)
  84 < ebassi> ensonic, awalton__: so, are you going to start an effort for the migration?
  85 < ebassi> if you need a hand, I can help this w/e
  86  * mclasen has migrated function docs every now and then, on a file-by-file basis
  87 < ebassi> I would really like to get this done :-)
  88 < ensonic> ebassi: its a lot of work, but for gstreamer it was the right thing to do
  89 < awalton__> sure, I'd love to see it happen, and it's something I'm at least familiar with so I'll throw my hat in.
  90 < kris> I will promise to update tree view docs when this is done
  91 < kris> it should be summer and I should have time by then
  92 < awalton__> would it be a good idea to start a wikipage with the files that need migrated so that we're not overlapping work?
  93 < ebassi> awalton__: good idea
  94 < bratsche> Yeah.
  95 < jdahlin> I think it's a good idea to include the whole documentation in the sources, including initial blurbs etc
  96 < rhult> jdahlin, that's the plan (to get rid of all the tmpl stuff)
  97 < jdahlin> python/perl is usually documented just like that, and it's seldom an issue that you have too much documentation
  98 < ebassi> I'd say -- ACTION: awalton, ensonic will start a wiki page with a file-by-file migration of the tmpl files to the source
  99 < jdahlin> rhult: just responding to kris worry that it might be too much documentation in the sources
 100 < ensonic> ack
 101 < kris> jdahlin: too much docs are never bad but only if they are relevant hehe
 102 < awalton__> I'm in full agreement
 103 < Sonderblade> isn't there some things you have to escape differently when writing in the c files than in tmpl files? 
 104 < kris> jdahlin: but I figured I am not allowe dto complain, 20K of text on top of 460K of C shouldnt hurt
 105 < ebassi> Sonderblade: just HTML entities
 106 < rhult> does it make sense to also have a very brief snippet on how to move things? in case more people want to help out? or is it easy enough that's not needed?
 107 < ebassi> Sonderblade: gtk-doc has the documentation
 108 < jdahlin> kris: it might make sense to keep some documentation outside of the sources, but I cannot really point to specific use case
 109 < kris> jdahlin: (I should still write down my plans for the simple tree view wrapper)
 110 < mclasen> if all else fails we can also keep a few dedicated doc files in the srcdir, no ?
 111 < kris> jdahlin: (I actually wrote down a bunch of stuff at berlin airport when I left_)
 112 < awalton__> rhult, we could use that, along with someone who's familiar with the documentation to say if it's fresh or not.
 113 < jdahlin> kris: definitely, even 100K documentation to 460K C wouldn't be bad
 114 < Sonderblade> ebassi: and /* */ just something to keep in mind
 115 < ebassi> Sonderblade: usually, &ast; for *
 116 < jdahlin> kris: please do, ideally in the wiki
 117 < kris> jdahlin: will hope to get to it soon
 118 < ebassi> there's a page already for some of the syntax: http://live.gnome.org/DocumentationProject/GtkDoc
 119 < jdahlin> kris: I even managed to write down some gobject-introspection notes and I thought I was late!
 120 < kris> jdahlin: uyea yea yea
 121 < kris> jdahlin: I've been busy with uni stuff (good enough excuse? ;)
 122 < ensonic> rhult: I can put some bullets on that wiki page - gnome task style
 123 < rhult> ensonic, great!
 124 < ebassi> should we move to point #2 - merge GSEAL (timj, kris)
 125 < ebassi> ?
 126 < ensonic> ebassi: the yelp manual of gtk-doc is more up-to-date
 127 < timj> ebassi: one last thing about docs..
 128 < timj> ebassi: have you already started reviewing/fixing gobject tutorial doc snippets like you mentioned during the last meeting?
 129 < timj> (i was awaiting review snippets in my inbox but didn't see any)
 130 < ebassi> timj: not more than the ones I attached to the already existing bug; I need to start updating that
 131 < ensonic> ebassi: would be good if you can apply those, makes it easier to start doing futher updates there
 132 < ebassi> okay
 133 < timj> ok, i'm fine with moving on...
 134 < mclasen> next topic is yours...
 135 < timj> #2 - Merge G_SEAL (timj, kris)
 136 < timj> as Kris mentioned earlier today in his email "Steps to get to GTK+ 3.0", we have started ca. 2 months ago on a GSEAL branch in a git mirror repo: http://git.imendio.com/?p=projects/gtk%2B.git;a=shortlog;h=refs/heads/GSEAL
 137 < bratsche> Does this encompass the other items in kris's email (implement class private data, etc)?
 138 < timj> bratsche: so far, this branch only adds GSEAL() and wraps structure fields in it
 139 < bratsche> Are all the structure fields already wrapped, or is there more work to do still there?
 140 < timj> bratsche: class private data and a few other things (like getting rid of WIDGET_SET_FLAGS, etc) are probably best handled via bugzilla. 
 141 < ebassi> a question re: class private data - does that include the class handlers for signals?
 142 < timj> that's established practice for this kind of change already
 143 < jdahlin> timj: It's unfortunate that this is in an external git branch
 144 < timj> jdahlin: yeah, i'm coming to this ;)
 145 < jdahlin> I can fully understand the reasons why, but an svn branch would be easier for people to pick up
 146 < kris> bratsche: everything has been done already, minus a few files but they are probably going to be done within the next 7 days
 147 < bratsche> I'm interested in helping to work on these things, so I just want to find out (maybe now, maybe after the meeting sometime) what I can do.
 148 < timj> ebassi: classes should also be sealed in gtk+3, so we'll prolly add some convenience API to setup class handlers instead of using *Class slots in the future
 149 < timj> back to the GSEAL branch....
 150 < mclasen> does the 'merge' in the topic mean 'merge now' or 'merge next week' or merge after 2.14 ?
 151 < timj> we're currently in the process of finishing the last bits of it and think it makes sense to merge this into upstream soon
 152 < timj> mclasen: i'm thinking of doing this incrementally. hopefully we're done before guadec, but it wouldn't be the end of the world if it's not completed by then
 153 < mclasen> agreed
 154 < timj> a good portion of the changes is fairly clean and straight forward, so i'd imagine we could make good progress on this
 155 < kris> yes, that's really the case for over 50% of the files
 156 < timj> some require extra review though, e.g. i'll request a second review for gtkmenu* changes for instance before merging.
 157 < ensonic> timj: hmm, your bitten by cyclic gnome-doc-utils dependency
 158 < Sonderblade> timj: will gtk be compilable with -DSEAL_ENABLE or is that tbd?
 159 < timj> also, if anyone wants to comment on the changes in the current branch before its merged, that's appreciated
 160 < timj> ensonic: can we handle the gtk-doc issue on #gtk+ please?
 161 < ensonic> timj: jep
 162 < timj> Sonderblade: yes, see: http://git.imendio.com/?p=projects/gtk%2B.git;a=commitdiff;h=0a15a54a2d078a0cb191eeccea067af999c2361f
 163 < kris> I think he means if gtk+ it self will compile with SEAL_ENABLE on?
 164 < Sonderblade> kris: yeah many attributes e.g. widget->window doesn't have any accessor yet
 165 < kris> Sonderblade: they will get these accessors together with the sealing
 166 < timj> ah. well sealing structures within gtk itself would significantly increase the amount of required work and not have a clear immediate benefit. so no, gtk internals aren't forced to use accessors. this is something that could (at least partially) be done in the fiuture though
 167 < timj> ok, if there're no further comments, i suggest we'll merge as proposed and move on in the agenda...
 168  * mclasen makes note to look at hte seal branch
 169 < jdahlin> timj: is there a reason not to use git-svn and a real gtk+ svn branch?
 170 < timj> mclasen: that'd be great. the above commit url i pasted is the start of it (though we intend to rebase the branch soon, since it was spawned off in march)
 171 < ebassi> okay, item #3: Finding volunteers for the GtkTasks (timj) - I'd leave the SCM discussion on a private /query :-)
 172 < timj> jdahlin: yes, svn succiness in branches, also i think not everyone who contributed to the current branch actually has SVN commit access. OTOH anyone who has git can clone our repo and start hacking and tell us to pull from him. that's why ideally we should use git for gtk+ at some future point ;)
 173 < Sonderblade> timj: many of the internal attributes e.g. widget->window or widget->ref_count is very useful even for external code 
 174 < jdahlin> timj: you could still keep on using git, but just store the 'master' version in svn, so other developers doesn't have to learn git (such as myself)
 175 < timj> Sonderblade: ref_count is in gobject, and anything that's found useful gets an accessor.
 176 < mclasen> Sonderblade: using ref_count is always a bug
 177 < rhult> Sonderblade, that's why the branch adds accessors for everything that is not supposed to be private
 178 < jdahlin> I hope ref_count gets an accessor, it's pretty important for bindings.
 179 < timj> jdahlin: we want to merge the branch in the coming weeks anyway, so lets please move SCM to other forums
 180 < jdahlin> timj: well, you guys brought the subject up, not me!
 181 < Sonderblade> right, good to know that you don't lose access to the attributes totally :)
 182 < pbor> timj: a last question about gseal... how does it interact with debugging? if I run with gdb can I steep peek at internal fields?
 183 < Hallski> jdahlin, using svn branches is a pain though, for everyone involved
 184 < pbor> s/steep/still
 185 < timj> pbor: yes, GSEAL() just obfuscates field names for public headers by adding a prefix. for debugging code compiled into gtk, the original field names will be used, for debugging code stored in application code, you'll see the field name prefixed
 186 < jdahlin> Hallski: well, less so if you use $VCSOFTHEDAY to merge to/from it
 187 < pbor> timj: ok, fair enough
 188 < Hallski> jdahlin, the gain for you as a third party would be quite minimal though
 189 < Hallski> (third party in the sense of not committing to the branch)
 190 < jdahlin> Hallski: right, but if I do want to contribute it is reducing the barrier
 191 < jdahlin> anyway, I won't argue since I can't even fool myself that I have time & bandwidth for that kind of work right now
 192 < mclasen> nice segway into the next topic...
 193 < timj> #3 - Finding volunteers for the GtkTasks (timj)
 194 < timj> we have at least 4 open slots on the current tasks page
 195 < timj> actually 5, i think Xan isn't available for bug promoting anymore
 196 < bratsche> I may have been falling down on the job in this recently, I have been very busy at work and just getting some more time now.
 197 < timj> i'd appreciate input on how to find volounteers to sign up for some of these tasks. 
 198 < timj> i have two ideas so far: 1) cross-post a volounteer search email on the gtk* lists; 2) raise this again during the next foundation meeting, to see if we can get some more corporate sponsoring for some of the tasks.
 199 < mclasen> for 'implementing test programs', maybe we could do something to advertise the new facilities, and make them better known ?
 200 < xan> timj, yes, unfortunately I'm not
 201 < timj> mclasen: yes, many people have been asking me about unit tests during the hackfest. i have another blog post about that in the queue
 202 < timj> xan: would be nice if you removed yourself from the list then
 203 < xan> sure
 204 < timj> bratsche: i have no complaints ;) i'm actually very thankful for the applying/commit help you've been providing ;)
 205 < bratsche> timj: I've still got an unfinished unit test for the sensitivity/crossing bug.  I should try to finish that up now that I've got a little bit of time. :)
 206 < timj> that'd be nice ;)
 207 < dieguito> may I drag your attention to http://live.gnome.org/GtkLove/PatchTriaging regarding GtkTasks? I'm looking for advice on how to handle the triaged pathes, ping a maintainer? commit if simple enough?
 208 < xan> dieguito, I think you should put yourself there, since you have been doing some work in the bug promotion stuff
 209 < timj> dieguito: http://live.gnome.org/GtkTasks#P7
 210 < xan> (http://live.gnome.org/GtkTasks)
 211 < Sonderblade> bratsche: there is a test suite for gtk?
 212 < timj> dieguito: Xan has in the past posted emails to gtk-devel-list with easy-to-review bugs, i think that worked failry well to draw core maintainer attention (at least for me)
 213 < bratsche> Sonderblade: I started to write a unit test for #56070 in the hopes that we could maybe commit the work for this and use the unit test to try to catch any related issues in the future.
 214 < bratsche> Then I got busy at work, and it's sitting somewhere on my laptop now.
 215 < timj> dieguito: if you'd take over #P7 from Xan, that'd be great ;)
 216 < ebassi> dieguito: yeah, I can confirm xan mails were really helpful
 217  * mclasen does patch review in batches nowadays
 218 < dieguito> ok then I'll do some spam to gtk list, although last time I didn't get too far with that
 219 < mclasen> 50 patches every three months...
 220 < xan> well, that's nice to hear, I wasn't sure if they were helpful actually :)
 221 < timj> anyone else has comments regarding (1) or (2) or more ideas? i think it's especially important that fill #P10 to relieve mclasen somewhat.
 222 < mclasen> its on my list to flesh out the release howto some more
 223 < awalton__> to whomever's mailing about it: a detailedish description of what the jobs are would be nice
 224 < kris> if I had the time I wouldn't mind spinning tarballs ... too busy with university still unfortunately ...
 225 < mclasen> awalton__: click on the links in the table...
 226 < awalton__> mclasen, aahh didn't see that, thanks.
 227 < leio> #P10 involves just tarball creation and distchecking and such, not stabilizing the code for that, etc, right?
 228 < mclasen> leio: there is quite a bit of busywork involved, from fixing up  make check to fixing up the doc build to collecing contributors
 229 < mclasen> of course, one could argue that making sure make check works falls under #P8
 230 < leio> right, but everything a person with enough time and releasing or packaging related fixing experience can handle
 231 < mclasen> but in practise, it needs to get fixed up at release time
 232 < timj> leio: there are various kind of ways in which mclasen could be helped, and its something that one can incrementally get better at
 233 < timj> mclasen: yes, but since #P8 is currently untaken, fixing things up is left at least to #P10 ;)
 234 < leio> ok, we can continue on that later elsewhere, as the topic for the meeting seems to be how to get the slots filled (kind of advertising related). I might be interested to try to help out.
 235 < rhult> just having someone run make distcheck regularly and fixing up or filing bugs could probably help streamline the release process so there isn't a lot of issues piling up (not sure if that usually is the case though)
 236 < timj> leio: if you're seriously thinking about signing up for the task, you meet 87.28% of the required qualification already ;)
 237 < timj> (kidding, just sign up, that'd be great)
 238 < timj> ok, to wrap this up...
 239 < timj> i'll do (1) and (2) at some point, and if leio and dieguito could help out with some of the tasks already, that'd solve allmost half of our remaining open slots (certainly the more important ones)
 240 < timj> which leads to:
 241 < timj> #4 - FileChooser/GIO patch (mclasen)
 242 < mclasen> sorry, was away for a minute (family came home)
 243  * dieguito is a bit afk
 244 < mclasen> so, I think we should consider that patch for 2.13
 245 < mclasen> but I wanted to know what the 'filechooser guys' think about it
 246 < mclasen> I haven't studied it in detail myself
 247 < ebassi> mclasen: the patch would reimplement filesystemunix or replace filesystem entirely?
 248 < dieguito> timj: I'll keep doing patch triaging, and I'll send summaries to gtk list if that's the best way to get them applied or reviewed
 249 < timj> mclasen: not sure who that is... federico isn't here, and carlos told me to tell you he'll do "his homework" with regards to the patch.
 250 < ebassi> mclasen: or add a filesystemgio ?
 251 < jpeterse1> ebassi: replace
 252 < mclasen> timj: kris/federico, I guess
 253 < kris> eeeeeeeeeeeeeeeeek
 254 < bratsche> heh
 255 < ebassi> if it replaces filesystem, then +1 for merging it *now*
 256 < kris> I am not a filechooser person ;)
 257 < bratsche> kris: You've been promoted!
 258 < ebassi> no, better: *yesterday*
 259 < kris> I don't really see how we can replace gtkfilesystem
 260 < kris> it's semi-private though
 261 < kris> or semi-public
 262 < ebassi> or semi-cracktastic
 263 < kris> yea we can agree on that one
 264 < ebassi> (the great work you kris and federico did on it)
 265 < ebassi> (notwithstanding)
 266 < pbor> was the patch tested on win32?
 267 < mclasen> gtkfilesystemgio is what we already have in libgnomeui...
 268 < kris> oh, is that already in libgnomeui?
 269 < jpeterse1> kris: there are no longer any filesystem modules loaded ...
 270 < mclasen> so, do we know of any users of this semi-private interface ?
 271 < mclasen> maemo, who else ?
 272 < kris> I can see the file chooser solely using GIO calls
 273 < kris> certainly the way to go
 274 < kris> I am only wondering if we can actually get rid of GtkFileSystem in 2.x in a compatible fashion
 275 < mclasen> we have broken the filechooser abi before...
 276 < jpeterse1> there is a GTK_FILE_SYSTEM_ENABLE_UNSUPPORTED at the top of the header with a note: no stability guarantees
 277 < kris> mclasen: yea, but now we remove it ;)
 278 < kris> jpeterse1: I know
 279 < kris> but I wonder if that includes completely removing it
 280 < mclasen> again, do we know users beyond maemo ?
 281 < kris> I don't know
 282 < kris> maybe xfce?
 283  * kris checks
 284 < leio> http://www.google.com/codesearch?q=GTK_FILE_SYSTEM_ENABLE_UNSUPPORTED&hl=en&btnG=Search+Code
 285 < rhult> doesn't look that bad at least
 286 < kris> i really have to go to bed btw, I am collapsing
 287 < kris> (have been up for > 17h)
 288 < kris> sorry ;)
 289 < mclasen> ok, we can pick it up on the list, I guess
 290 < kris> mclasen: yea maybe some of the unknown users will respond there; )
 291 < mclasen> I'll look over the patch in some detail and send mail to the list
 292 < timj> kris: i think we can remove "UNSUPPORTED" stuff, yes ;)
 293 < timj> kris: have a good night
 294 < ebassi> 'night kris 
 295 < mclasen> night
 296 < ebassi> mclasen: the GIO patch will make the GtkFileChooser interface public once and for all?
 297 < ebassi> mclasen: we have our GtkFileChooser for poky, and having that interface public would solve the raping of the default file chooser widget
 298 < ebassi> mclasen: as well as for maemo I guess
 299 < mclasen> interesting
 300  * mclasen goes back to releasing