Meeting on irc.gnome.org:#gtk-devel Meeting started Feb 23 17:12:15 EST (22:15 UTC) In attendance: Jonathan Blandford (jrb), Matthias Clasen (maclas), Tim Janik (rambokid), Noah Levitt (noah), Mark McLoughlin (markmc), Federico Mena Quintero (federico), Manish Singh (yosh), Soeren Sandmann (ssp), Owen Taylor (owen) Agenda item 1 - willfix list. I finally finished up going through Pango this morning, making a big punt/wontfix pass through gtk+/general now. Are we in good shape otherwise? all the gdk and menu bugs have patches attached GtkComboBox list mode looks much better now, after I discovered and extraneous +, the remaining stuff for combo box is robustness and code quality issues maclas: Good. owen: well, except for the a11y issue owen: still got to add my pet items, but fine with glib PATCH bugs otherwise GtkFileChooser is getting the GUI reworked, and the bugs don't look hard. The only slightly tricky one is #132894, but it's a simple matter of programming. I was going to file a bug of GtkFileChooser and tab completion, haven't done that yet tho there were several old input method bugs, so i just kinda picked a couple that seemed doable yosh: is it #135167? rambokid: did you still need a test case for the connect_object handler expiration thing? can't access bugzilla now. :/ stupid net OK, so sounds we have a handle on willfix to some extent. I have been fairly ruthless with the punting, perhaps too ruthless My goal is to finish up gtk+/gtk tonight then start on 2.3.3 ssp: There is no such thing as too ruthless yosh: yes. if you meant to cook one up, please do so. owen: but it still looks kinda large; with punt candidates; should we trim it more aggressively ? owen: is www.gtk.org down ? I can't get to that damn list... * maclas uses a local copy on the face of it owen appears to have been the least ruthless ;) noah: Or just had by far the biggest set of patches that I hadn't dealt with maclas: for glib, there's nothing more to trim. the ones i picked are pretty easy. maclas: I can't get to that list either, but yeah, it's large. I think we should work on fixing stuff though for now and see where we are in a little bit. owen, when do you think 2.3.3 will be ready ? rambokid: I think I have one for that bug when I worked on that quick fix.. I need to find the glib tree I did the work on ;) owen, it would be really great to have it for GNOME 2.5.90 (the beta) owen, which means wednesday latest prolly OK, next agenda issue is 2.3.3 / 2.3.4 releases. Probably since we only have 3 releases left, going with the current system will work, but I'd like to consider for the next devel cycle and 2.4.x getting away from "wait for owen to have time" markmc: I don't see any reason why we can't have it by tomorrow evening. owen, great, thanks owen: what does it take to make a release? owen: don't we have a howto-do-gtk-releases document somewhere ? maclas: it's in the docs directory release-HOWTO or something I was thinking that we might want to actually go to a system of rotating release makers. Either that, or someone else coudl volunteer to just take it over.... maclas: gtk+/docs/RELEASE_HOWTO federico: It's basically the same as any other module, except that it's a little bigger than most. And you need to have the right version of autotools installed since we have some libtool patches that we need federico: I guess there is the sync-to-gtk.org step, but I'm fine continuing to do that. I wouldn't mind doing releases once in a while, but I can't commit to doing it every time i like the rotating idea owen: I don't think we need to have a scheduled rotation, but it should not be a problem to increase the set of people who are able to do releases ssp: What I think I may try doing is just asking for a volunteer for each release. owen: sounds good OK, we'll do that first for 2.4.1. cool, that sounds fine does that apply to 2.2.? I'm getting asked for one :) federico/jrb: Status report on filesel GUI? federico: just volunteer... owen: work progressing owen: I think it'll be another week until it's done maclas: I can do it federico: It woudl apply to 2.2. though I want to take "2.2.x is dead" approach after 2.4.0 federico: So, timescale for 2.2.x is next two weeks. owen: yeah, there just some important fixes that should get out federico: Yeah, though we've stopped applying stuff to the 2.2.x branch recently. (But if you are going to do it, just make dist, don't worry about recent fixes) gtk.org is alive again jrb_: Would it be a good idea to add filechooser stuff to gtk-demo now? testfilechooser is, err, a little hard to maek sense of what is going on. owen: re the file chooser, from an ultra-quick test, it seems to work with the new GUI. We need an API to install save-as formats and icons. yeah. and it doesn't exactly highlight best practice; either owen: I'll do that. federico: how close is the filechooser to API freeze ? federico: seth was willing to leave the save-as-plus-type until later. We could possibly just leave that as extra_widget() for now might look funny given where we pack extra_widget. Though I'm thinking extra_widget should be above the expander, not below maclas: I'm happy with the existing stuff; I think we just need the API to set formats for save-as I'm a little worried with that scheme that we penalize people that don't hvae useful icons for their file formats (most people who aren't artists, really) (In fact, most people who are artists too. Bluecurve just sticks [jpeg] or whatever on top of the icon) owen: it doesn't sound hard, though... add_save_format (id, name, large_icon, small_icon); id get_save_format(); where was seth's mockup again ? maclas: http://www.gnome.org/~seth/filechooser-spec/ maclas: open-with currently looks pretty close to that federico: You at least need remove as well. Do you want GdkPixbuf arguments or just an icon name? Should there be a version that automaticlaly gets the right icon for a mie-type? owen: in that case, we could just show the text OK, we are getting into details here. Are there other genreal issues to discuss? owen: well, how do we know who is going to fix which bugs? while it maybe too late, TreeView DnD is the only outstanding one that I have oh, yes I started reading kris's mail last night, but didn't finish it let me do that for today ssp: should we assign bugs to avoid duplicate work ? ssp: Hmm. Do we need anything other than first-come-first-serve? (Add a note to a bug if you are working on it) owen: That might work, but I am worried that if we don't have bugs assigned to people, we will end up with unfixed bugs adding a note sounds good ssp: we likely will anyway...time-based and all that... ssp: The idea is that with willfix.html we have a finite list of bugs, and if we marked willfix bugs appropriately, it should be a manageable list. If people start from the bugs they think are most urgent, then any leftovers should be the least important ssp: Why don't we start that way, and then next week if the willfix list is too big too clearly see who is doing what in the last week, we'll assign bugs and punt the unassigned. OK, I think that finishes the agenda