Meeting on irc.gnome.org:#gtk-devel Meeting started March 8 2004 17:09 EST (22:09 UTC) In attendance: Jonathan Blandford (jrb), Anders Carlson (andersca), Matthias Clasen (maclas), Murray Cumming (murrayc), Tim Janik (rambokid), Noah Levitt (noah), Tor Lillqvist (tml), Mark McLoughlin (markmc), Federico Mena Quintero (federico), Soeren Sandmann (ssp), Manish Singh (yosh), Owen Taylor (owen), Sebastian Wilhelmi (seppi) OK, first item -- how ready, not ready, doomed, etc. are we for 2.4.0? for the filesel, I think we're less doomed than expected jrb: Hmm. I'm not sure how to take that ;-( owen: the UI is done (e.g. no missing elements), except for bugs owen: if we're comfortable with the end-user behavior shifting over the next few weeks, then we're okay owen: I'm about to test a patch which morten claims makes it handle file system errors much better jrb: I guess I'm not particullarly comfortable if you feel the end user behavior is at a point in which you think it requires shifting... owen: some smallish things still need doing; like tabbing in the C-l dialog, adding a mnemonic to it; making the shortcut list single click; expanding rerooting hmm, tabbing? I thought completion would be enough? andersca: we half overload completion jrb: How many of those *need* to be done? Lots of code movement isn't good right before we go final for gnome-2.6 owen: for the UI, it's minor things at this point; one or two-liners at most, except for DnD in the shortcuts list owen: hard to call. If I had to prioritize, getting 'Desktop' rerooted (since it's an untranslated string) and the single click are the highest priority for me. I guess the remaining big one is to impelment is_local jrb: Is single click doable without GtkTreeView API changes? owen: yes owen: I'm pretty sure I know how to do it * jrb qualifies his yes jrb: Hmm, I don't want to get into details, but I don't really see how you can deal with focus without selection for that widget, which seems like a prerequisitte jrb: My basic concern is that I'd like to have a release without major code churn before gnome-2.6 OK, other than the filechooser, how are we doing * jrb tries his quick fix For Pango, I could push a 1.4.0 like it is now... there are things I'd *like* to fix (129741, 122330) but they could be dot-release fixed without worrying me. owen: apart from the appears-as-list drawing bug you just pointed out, I think the combobox is in good shape for 2.4 owen: I'd like the width patch to go in, but it can wait for 1.4.1 if you think that's best maclas: It was sort of worrying me looking at the code this morning (hence the scarily big patch I checked in), but behavior seems pretty good maclas: Did you end up looking at the hide-the-cellview-when-no-active row issue? maclas: I had to back out the "select first row when filling an empty combobox" thing, and so you really see some weird behavior now since the CellRenderer is shared between the menu items and the CellView owen: I looked at it, but didn't come to a conclusion yet owen: hopefully empty comboboxes are a really rare thing yosh: I think it looked OK to commit if you are comfortable that it won't regress things with current fontconfig maclas: Well, I think it's pretty common that people will write code that fills the combobox without selecting anything, and currently, it's not very obvious what is going on maclas: I could *easily* see someone spending hours trying to figure things out as they are now owen: yeah, I tested a bunch of combinations. no regressions murrayc: Do you understand http://bugzilla.gnome.org/show_bug.cgi?id=135899? I can't really figure out the problem there's also the GPid issue wrt windows owen: I can maybe look at that for 2.4.1. not sure whether I can get much done tonight yosh: For the GPid issue, I'm comfortable with leaving it as is, though I'd really like Tor to comfirm ok it's really judgement call whether to cause compile breakage now and get problems fixed sooner, or punt and hope people just use GPid by themselves before Win64 breakage owen: Don't worry about 135899. If it's really broken, then I don't think you can fix it, not without an #ifdeclaredasfunction that works like an #ifdef. Wait, why is a GTK+ header file depending on ENABLE_NLS murrayc: My issue is why you'd be getting both libintl and the no-i18n branch of tha tfile s/GTK+ header file/glib header file/ I think it's more of a "header file that you might find useful to include in your application". It's not a regular glib header file - you don't get it with glib.h and I don't think it's used by glib itself. murrayc: Yeah, but still, depending on #defines like ENABLE_NLS is really dubious. owen: Well, I don't understand it all, but I'm not very worried about it for gtkmm. And we do require gettext to be present to compile glib murrayc: I don't think it has anything to do with C++.... includes order is often a problem with that gettext() stuff. bonobo has/had similar problems. murrayc: Except that iostream is (?) pulling into libintl.h owen: the contents of gi18n.h are directly copied from gtkintl.h (brooooken, if that's the case) maclas: Yeah, but gtkintl.h is internal header file, so it's free to depend on config.h stuff owen: Yes, and it might be specific to a redhat g++. I don't think this bug is worth the time here. murrayc: Err, it worries me that you have to define ENABLE_NLS. Though, hmmm, I guess you have to have all the gettext machinery around to use gettext efficiently. Anyways, I guess I understand the isuse I have never properly understood gettext defines/build/includes. http://bugzilla.gnome.org/show_bug.cgi?id=136446 needs, in my opinion, to be fixed before 2.4.0 owen: A simple fix is to destroy the children in the opposite order (The problem is that every time you delete one item, you move all the ones below it up one row, emitting a million notiifcations) So, marco can workaround it for now with some signal magic maybe. owen: the problem is that removing an item needs to update the properties on all the other items making the whole operation O(n^2) Sounds like that is useless when they are all going to be destroyed anyway. murrayc: No, no, no, 500 item menus need to work But he's talking about 5 seconds to remove all menu items (indirectly, when deleting the window), not one. murrayc: I think he's just talking about gtk_widget_destroy (menu), which removes all the items just removing them in the opposite order should make it O(n) instead of O(n^2) ssp: Reversing the order possible. Another possibility is to set a flag when destroying the menu owen: to speed up gtk_widget_destroy(menu) when menu item removal is O(n_items)? rambokid: removing the first item in the menu is O(n_items) rambokid: that's because we emit the child notifications for moving all the items below it up the easiest thing for that would be while (last_child) gtk_widget_destroy(last_child); in the gtk_menu_shell destroy handler rambokid: actually, that's still O(n) though a faster O(n) - setting a flag to alter the usual notification behaviour is hackish. and it's not even entirely clear you wouldn't need proper notification at that point. rambokid: (because we hvae to loop through all menu items to find out which ones are below) rambokid: I wasn't suggesting turning off notification, I was suggesting turning off the "moving up" behavior during destroy,since we know we are removing everything owen: why not, in the destroy handler, do container_get_children(), then destroy each one? ssp: do container_get_children(), sort the result, then destroy each one, you mean? owen: backwards, I mean ssp: that's the same as walking menu_shell->children backwards ssp: Remember we don't know that menu_shell->children is in geometric order Hey tml that's a GLIST with prev btw sorry for being late, watched "scarface" with the wife... OK, we're getting off into technical-detail territory, probably don't need to do that as a group owen: yeah, or rely on the fact that get_children() will return the children in the right order owen: I'll come up with a patch for that bug tonight (or an explanation, if I can't) ssp: Cool, thanks. owen, ssp: in grid mode, we don't move up IIRC, so a quick way to avoid moving up might be to add a second column... ssp: i'd guess that the while(last_child) loop i suggested above is fast enough for real world scenarios, since you just compare positions per child, and don't emit notifications for each maclas: Urg. :-) OK, do we have other real showstoppers for 2.4.0 that people know of? owen: I haven't really tested the Location dialog in the file chooser, so I don't know if there are GtkENtryCompletion issues with it owen: it's probably not a showstopper, but I would like the patch on http://bugzilla.gnome.org/show_bug.cgi?id=134230 to go in federico: did the response_id problem ever get fixed? owen, http://bugzilla.gnome.org/show_bug.cgi?id=135962 (treeview crash with Ctrl-F in FileChooser) seems pretty serious to me jrb: no, it's not obvious how to do it federico: Eeek, it isn't usable currently... comes up with the entire path and only the last "/" selected owen: I thought I changed it to select all owen: http://bugzilla.gnome.org/show_bug.cgi?id=136539 will make test-child fail on linux < 2.6 the whole thing is supposed to be selected markmc: yeah. That ones worth getting in seppi: Oh, yeah, I meant to mention that. 'make check' has to pass on common platforms one way or the other andersca: I may not have rebuilt since this morning federico: Is it using GtkEntryCompletion at all? It feels like my old nautilus-style completion code andersca: it's happenting for me now, too I think it might be hmm, how weird owen: it does use GtkEntryCompletion, but I don't know if it uses it properly owen: I'd love someone to look into that; as I don't know the API very well federico: Doesn't GtkEntryCompletion have a dropdown? Hmm, I guess it isn't working as well as my old code used to do, occasionally it just autocompletes as I type and jumps me ahead Which is really really annoying EntryCompletion normally has a drop down. OK, quick poll Are we a) ready to do a 2.4.0 as soon as we close 1 or 2 showstoppers b) need to slip a day or two c) need to slip more than a day or two owen: it does have a dropdown * jrb votes b federico: How do you get it to come up? * andersca b owen: press Down, I think federico: That focuses me down to the widget below FWIW, I think release-team would prefer (c) to (b) if it meant getting another 2.3.x release today/tommorrow [ with a contingent on listing explicitly the bugs that are blocking ] (assuming we can't do 2.4.0 today) Yeah, a release today, regardless, please. markmc: So your saying 2.3.6 today and 2.4.0 before rc1 next monday basically? owen, yes, that would be fine with us * maclas votes b or c, depending on how ready the filechooser guys think it is owen, I don't think there's too much point (as far as GNOME is concerned) to rushing 2.4.0 out today instead of next week maclas: a week would make me more comfortable; markmc: do you think we could ask for and get volunteers to fix 2.4 milestone bugs? federico: Do you think that would help? federico: we're having enough trouble dealing w/ gmorten's patches as it is federico, shrug, I'd fix some myself ... buts its not easy for anyone to jump in really ... hmm federico: Acutally, we need to get the 2.4 milestone bug count reasonable. Or all the things 2.4.0 milestoned for GtkTreeView really critical for 2.4.0? s/GtkTreeView/GtkFileSel/ owen: I'm not sure; the file chooser has a bunch of little annoyances which people could easily fix federico: 33 on 2.4.0... Every list of bugs gets 1 or 2 fixes. jrb: If we do a week, I'd really like to see that as a couple of days of changes, and the rest as stabilization owen: me too * tml votes a) from Win32 POV... Win32 parts prolly won't get much more work done on it during the next days anyway. but OTOH, if it slips by a week, maybe something more will get fixed by the way are there two components, file-chooser and GtkFileSel in bugzilla? andersca: no, jsut GtkFileSel just filesel ok tml: Oh, since you are here, GPid - what do we do there about the MSVC "API breakage"? I'm willing to keep it as is, but then again, I don't have to deal with complaints on that :-) we should ditch/update the will-fix list yeah jrb: We probably need to rename that component to "file selector" or something yeah OK, I'm going to suggest we go with the 2.3.6 now, 2.4.0 in a week approach, because I think that's going to give us the best chance for a quality 2.4.0. (and it's going to take probably 2 days to just get the release out anyways) (As much as I'd *really* like not to have 2.4.0 hanging over me next weekend) willfix list ... IMO, it's not working out well because GtkComboBox, GtkFileChooser, we keep on getting new stuff in constantly I'd be inclined to retire it and push hard to keep the bugzilla milestones reasonable instead. But then again, I have pretty good connectivitiy to bugzilla to constantly rerun queries. * owen listens to the deafening silence owen: sorry; going throuhg my milestones owen: retiring willfix and going on the 2.4.0 milestone is prolly good jrb: If I could get you to triage GtkTreeView in bugzilla, that would be great. owen: yeah owen: will give that a quick look jrb: It can be quick, but just make sure the end result is bugs that actually are going to get fixed before 2.4.0 :-) (So, be ruthless, not superficial) * jrb pulls out the machette owen: i agree with retiring the willfix list * ssp too it would be useful to me if it reflected reality, but not if it doesn't. bugzilla with reality-reflecting milestones is just as good I can update the milestones on the "menu" and "gdk" components ssp: I already did a machete job on menu earlier today, but further attention you want to give to that would be appreciated hrm. owen spells better than I jrb: I was going to say hachette but I couldn't figure out how to spell that, so.... Machetes are usually used on trees of course ... Is the meeting ajourned? ssp: Yeah, seem to be talking spelling now I'll assume nobody objected to the schedule proposal Meeting ended Mar 01 18:26 (23:26 UTC)