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