< ebassi> yey, meeting time < awalton__> huzzah < bratsche> yay < kris> hello < ebassi> problem is: no mclasen :-) < kris> where is timmy < ebassi> hey kris < kris> timmy timmy timmy < awalton__> bratsche, thanks for adding gicon to the widget ;) < bratsche> awalton__: Thanks for the suggestion! < bratsche> awalton__: I'm finally trying to get back to work on this now. :) < timj> here < 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. < ebassi> bratsche: my gut feeling is "no more than one on each side" < awalton__> gotta side with ebassi on this one. it's one of the things that somewhat makes firefox's awesomebar feel cluttered < kris> I agree with that gut feeling < kris> and you prolly want to swap sides in RTL mode < bratsche> ebassi: Yeah, that's mine too I think. < bratsche> Does anyone happen to know how you actually active the different icons in Firefox using the keyboard? < ebassi> just as a note - the agenda for the meeting is here: http://live.gnome.org/GTK+/Meetings < awalton__> bratsche, or rather, can you? I don't think it's possible atm. < kris> ebassi: did mclasen say he would be late, or? < bratsche> awalton__: I'm not sure. I guess this discussion could be saved for when there's not a gtk meeting going on. :) < 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) < ebassi> kris: not to me < timj> ebassi: hm, can we just start to go through the agenda now? < ebassi> timj: fine by me :-) < ebassi> 1. # < ebassi> Migration of glib/gdk(-pixbuf)/gtk documentation from /tmpl to source (ensonic, awalton) < awalton__> ahh me first eh? < kris> I was wondering what is going to happen with all the "blurb" in the docs that are above the descriptions of all functions < awalton__> you can put them in the head of the section with gtkdoc < awalton__> you just have to do a SECTION:whatever comment < kris> will they move to the source or not? < ebassi> kris: to the source file < awalton__> indeed. all of it will. < kris> yea < kris> and where in the source file? < kris> is there an example? < ensonic> hi < awalton__> kris, all of GIO < kris> oh < awalton__> hello ensonic, right on time. < ebassi> kris: all of clutter, cairo < kris> sorry ;) < kris> all these components are so new < kris> I am getting old < bratsche> heh < awalton__> heh, I was new to it myself, but I like it,. < awalton__> I think having them in the code makes people more likely to focus on the docs as well. < kris> yes I fully agree with that < kris> because I was about to say that I never dared to touch the tmpl files < kris> until I think a year ago < ebassi> awalton__: like it myself - it's very nice to have documentation coupled with the functions; it might head to improvements in the docs :-) < rhult> it makes it really nice when reading to code too, to see the docs in the same place < kris> although I am a bit worried about inserting a 20K blurb at the top of certain source files < ebassi> hey mclasen < bratsche> yay * mclasen managed to miss the meeting < rhult> kris, yea it might not make sense for the "conceptual" doc pieces < kris> but I guess I am not allowed to complain < kris> rhult: yea < ebassi> kris: it's not xml - mostly would be plain text, and no section is that big < 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? < ebassi> mclasen: we just started < bratsche> mclasen: We're on item #1 in the agenda right now. < bratsche> http://live.gnome.org/GTK+/Meetings' < rhult> mclasen, we just started on the first item so you haven't missed a lot < bratsche> http://live.gnome.org/GTK+/Meetings < mclasen> ah, ok < kris> awalton__: yeah I think we'll manage < mclasen> I think the 'no tmpl' approach has worked pretty well for gio < kris> may I suggest maybe just ignoring all deprecated crap when moving stuff from tmp to source? < mclasen> as in 'leaving it behind in tmpl' or 'stripping its documentation out' ? < awalton__> well I'd hate to do that... but at least waving some more flags at people to ignore the function would be nice. < ensonic> kris: not really feasable < ebassi> kris: deprecated since 1.2? < ebassi> I would keep the deprecated-since-2.0 < kris> I was thinking of leaving behind, but that is not feasible? < ensonic> kris: the goal is also to get rid of the tmpl dir in total < kris> ok < kris> was just looking into saving some work for you guys ;) < kris> I think this will be very awesome to have btw ;) < ebassi> ensonic, awalton__: so, are you going to start an effort for the migration? < ebassi> if you need a hand, I can help this w/e * mclasen has migrated function docs every now and then, on a file-by-file basis < ebassi> I would really like to get this done :-) < ensonic> ebassi: its a lot of work, but for gstreamer it was the right thing to do < 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. < kris> I will promise to update tree view docs when this is done < kris> it should be summer and I should have time by then < awalton__> would it be a good idea to start a wikipage with the files that need migrated so that we're not overlapping work? < ebassi> awalton__: good idea < bratsche> Yeah. < jdahlin> I think it's a good idea to include the whole documentation in the sources, including initial blurbs etc < rhult> jdahlin, that's the plan (to get rid of all the tmpl stuff) < jdahlin> python/perl is usually documented just like that, and it's seldom an issue that you have too much documentation < 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 < jdahlin> rhult: just responding to kris worry that it might be too much documentation in the sources < ensonic> ack < kris> jdahlin: too much docs are never bad but only if they are relevant hehe < awalton__> I'm in full agreement < Sonderblade> isn't there some things you have to escape differently when writing in the c files than in tmpl files? < kris> jdahlin: but I figured I am not allowe dto complain, 20K of text on top of 460K of C shouldnt hurt < ebassi> Sonderblade: just HTML entities < 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? < ebassi> Sonderblade: gtk-doc has the documentation < jdahlin> kris: it might make sense to keep some documentation outside of the sources, but I cannot really point to specific use case < kris> jdahlin: (I should still write down my plans for the simple tree view wrapper) < mclasen> if all else fails we can also keep a few dedicated doc files in the srcdir, no ? < kris> jdahlin: (I actually wrote down a bunch of stuff at berlin airport when I left_) < awalton__> rhult, we could use that, along with someone who's familiar with the documentation to say if it's fresh or not. < jdahlin> kris: definitely, even 100K documentation to 460K C wouldn't be bad < Sonderblade> ebassi: and /* */ just something to keep in mind < ebassi> Sonderblade: usually, * for * < jdahlin> kris: please do, ideally in the wiki < kris> jdahlin: will hope to get to it soon < ebassi> there's a page already for some of the syntax: http://live.gnome.org/DocumentationProject/GtkDoc < jdahlin> kris: I even managed to write down some gobject-introspection notes and I thought I was late! < kris> jdahlin: uyea yea yea < kris> jdahlin: I've been busy with uni stuff (good enough excuse? ;) < ensonic> rhult: I can put some bullets on that wiki page - gnome task style < rhult> ensonic, great! < ebassi> should we move to point #2 - merge GSEAL (timj, kris) < ebassi> ? < ensonic> ebassi: the yelp manual of gtk-doc is more up-to-date < timj> ebassi: one last thing about docs.. < timj> ebassi: have you already started reviewing/fixing gobject tutorial doc snippets like you mentioned during the last meeting? < timj> (i was awaiting review snippets in my inbox but didn't see any) < ebassi> timj: not more than the ones I attached to the already existing bug; I need to start updating that < ensonic> ebassi: would be good if you can apply those, makes it easier to start doing futher updates there < ebassi> okay < timj> ok, i'm fine with moving on... < mclasen> next topic is yours... < timj> #2 - Merge G_SEAL (timj, kris) < 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 < bratsche> Does this encompass the other items in kris's email (implement class private data, etc)? < timj> bratsche: so far, this branch only adds GSEAL() and wraps structure fields in it < bratsche> Are all the structure fields already wrapped, or is there more work to do still there? < timj> bratsche: class private data and a few other things (like getting rid of WIDGET_SET_FLAGS, etc) are probably best handled via bugzilla. < ebassi> a question re: class private data - does that include the class handlers for signals? < timj> that's established practice for this kind of change already < jdahlin> timj: It's unfortunate that this is in an external git branch < timj> jdahlin: yeah, i'm coming to this ;) < jdahlin> I can fully understand the reasons why, but an svn branch would be easier for people to pick up < kris> bratsche: everything has been done already, minus a few files but they are probably going to be done within the next 7 days < 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. < 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 < timj> back to the GSEAL branch.... < mclasen> does the 'merge' in the topic mean 'merge now' or 'merge next week' or merge after 2.14 ? < 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 < 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 < mclasen> agreed < timj> a good portion of the changes is fairly clean and straight forward, so i'd imagine we could make good progress on this < kris> yes, that's really the case for over 50% of the files < timj> some require extra review though, e.g. i'll request a second review for gtkmenu* changes for instance before merging. < ensonic> timj: hmm, your bitten by cyclic gnome-doc-utils dependency < Sonderblade> timj: will gtk be compilable with -DSEAL_ENABLE or is that tbd? < timj> also, if anyone wants to comment on the changes in the current branch before its merged, that's appreciated < timj> ensonic: can we handle the gtk-doc issue on #gtk+ please? < ensonic> timj: jep < timj> Sonderblade: yes, see: http://git.imendio.com/?p=projects/gtk%2B.git;a=commitdiff;h=0a15a54a2d078a0cb191eeccea067af999c2361f < kris> I think he means if gtk+ it self will compile with SEAL_ENABLE on? < Sonderblade> kris: yeah many attributes e.g. widget->window doesn't have any accessor yet < kris> Sonderblade: they will get these accessors together with the sealing < 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 < timj> ok, if there're no further comments, i suggest we'll merge as proposed and move on in the agenda... * mclasen makes note to look at hte seal branch < jdahlin> timj: is there a reason not to use git-svn and a real gtk+ svn branch? < 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) < ebassi> okay, item #3: Finding volunteers for the GtkTasks (timj) - I'd leave the SCM discussion on a private /query :-) < 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 ;) < Sonderblade> timj: many of the internal attributes e.g. widget->window or widget->ref_count is very useful even for external code < 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) < timj> Sonderblade: ref_count is in gobject, and anything that's found useful gets an accessor. < mclasen> Sonderblade: using ref_count is always a bug < rhult> Sonderblade, that's why the branch adds accessors for everything that is not supposed to be private < jdahlin> I hope ref_count gets an accessor, it's pretty important for bindings. < timj> jdahlin: we want to merge the branch in the coming weeks anyway, so lets please move SCM to other forums < jdahlin> timj: well, you guys brought the subject up, not me! < Sonderblade> right, good to know that you don't lose access to the attributes totally :) < 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? < Hallski> jdahlin, using svn branches is a pain though, for everyone involved < pbor> s/steep/still < 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 < jdahlin> Hallski: well, less so if you use $VCSOFTHEDAY to merge to/from it < pbor> timj: ok, fair enough < Hallski> jdahlin, the gain for you as a third party would be quite minimal though < Hallski> (third party in the sense of not committing to the branch) < jdahlin> Hallski: right, but if I do want to contribute it is reducing the barrier < 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 < mclasen> nice segway into the next topic... < timj> #3 - Finding volunteers for the GtkTasks (timj) < timj> we have at least 4 open slots on the current tasks page < timj> actually 5, i think Xan isn't available for bug promoting anymore < 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. < timj> i'd appreciate input on how to find volounteers to sign up for some of these tasks. < 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. < mclasen> for 'implementing test programs', maybe we could do something to advertise the new facilities, and make them better known ? < xan> timj, yes, unfortunately I'm not < 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 < timj> xan: would be nice if you removed yourself from the list then < xan> sure < timj> bratsche: i have no complaints ;) i'm actually very thankful for the applying/commit help you've been providing ;) < 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. :) < timj> that'd be nice ;) < 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? < xan> dieguito, I think you should put yourself there, since you have been doing some work in the bug promotion stuff < timj> dieguito: http://live.gnome.org/GtkTasks#P7 < xan> (http://live.gnome.org/GtkTasks) < Sonderblade> bratsche: there is a test suite for gtk? < 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) < 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. < bratsche> Then I got busy at work, and it's sitting somewhere on my laptop now. < timj> dieguito: if you'd take over #P7 from Xan, that'd be great ;) < ebassi> dieguito: yeah, I can confirm xan mails were really helpful * mclasen does patch review in batches nowadays < dieguito> ok then I'll do some spam to gtk list, although last time I didn't get too far with that < mclasen> 50 patches every three months... < xan> well, that's nice to hear, I wasn't sure if they were helpful actually :) < 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. < mclasen> its on my list to flesh out the release howto some more < awalton__> to whomever's mailing about it: a detailedish description of what the jobs are would be nice < kris> if I had the time I wouldn't mind spinning tarballs ... too busy with university still unfortunately ... < mclasen> awalton__: click on the links in the table... < awalton__> mclasen, aahh didn't see that, thanks. < leio> #P10 involves just tarball creation and distchecking and such, not stabilizing the code for that, etc, right? < mclasen> leio: there is quite a bit of busywork involved, from fixing up make check to fixing up the doc build to collecing contributors < mclasen> of course, one could argue that making sure make check works falls under #P8 < leio> right, but everything a person with enough time and releasing or packaging related fixing experience can handle < mclasen> but in practise, it needs to get fixed up at release time < timj> leio: there are various kind of ways in which mclasen could be helped, and its something that one can incrementally get better at < timj> mclasen: yes, but since #P8 is currently untaken, fixing things up is left at least to #P10 ;) < 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. < 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) < timj> leio: if you're seriously thinking about signing up for the task, you meet 87.28% of the required qualification already ;) < timj> (kidding, just sign up, that'd be great) < timj> ok, to wrap this up... < 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) < timj> which leads to: < timj> #4 - FileChooser/GIO patch (mclasen) < mclasen> sorry, was away for a minute (family came home) * dieguito is a bit afk < mclasen> so, I think we should consider that patch for 2.13 < mclasen> but I wanted to know what the 'filechooser guys' think about it < mclasen> I haven't studied it in detail myself < ebassi> mclasen: the patch would reimplement filesystemunix or replace filesystem entirely? < 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 < 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. < ebassi> mclasen: or add a filesystemgio ? < jpeterse1> ebassi: replace < mclasen> timj: kris/federico, I guess < kris> eeeeeeeeeeeeeeeeek < bratsche> heh < ebassi> if it replaces filesystem, then +1 for merging it *now* < kris> I am not a filechooser person ;) < bratsche> kris: You've been promoted! < ebassi> no, better: *yesterday* < kris> I don't really see how we can replace gtkfilesystem < kris> it's semi-private though < kris> or semi-public < ebassi> or semi-cracktastic < kris> yea we can agree on that one < ebassi> (the great work you kris and federico did on it) < ebassi> (notwithstanding) < pbor> was the patch tested on win32? < mclasen> gtkfilesystemgio is what we already have in libgnomeui... < kris> oh, is that already in libgnomeui? < jpeterse1> kris: there are no longer any filesystem modules loaded ... < mclasen> so, do we know of any users of this semi-private interface ? < mclasen> maemo, who else ? < kris> I can see the file chooser solely using GIO calls < kris> certainly the way to go < kris> I am only wondering if we can actually get rid of GtkFileSystem in 2.x in a compatible fashion < mclasen> we have broken the filechooser abi before... < jpeterse1> there is a GTK_FILE_SYSTEM_ENABLE_UNSUPPORTED at the top of the header with a note: no stability guarantees < kris> mclasen: yea, but now we remove it ;) < kris> jpeterse1: I know < kris> but I wonder if that includes completely removing it < mclasen> again, do we know users beyond maemo ? < kris> I don't know < kris> maybe xfce? * kris checks < leio> http://www.google.com/codesearch?q=GTK_FILE_SYSTEM_ENABLE_UNSUPPORTED&hl=en&btnG=Search+Code < rhult> doesn't look that bad at least < kris> i really have to go to bed btw, I am collapsing < kris> (have been up for > 17h) < kris> sorry ;) < mclasen> ok, we can pick it up on the list, I guess < kris> mclasen: yea maybe some of the unknown users will respond there; ) < mclasen> I'll look over the patch in some detail and send mail to the list < timj> kris: i think we can remove "UNSUPPORTED" stuff, yes ;) < timj> kris: have a good night < ebassi> 'night kris < mclasen> night < ebassi> mclasen: the GIO patch will make the GtkFileChooser interface public once and for all? < ebassi> mclasen: we have our GtkFileChooser for poky, and having that interface public would solve the raping of the default file chooser widget < ebassi> mclasen: as well as for maemo I guess < mclasen> interesting * mclasen goes back to releasing