Meeting on irc.gnome.org:#gtk-devel Meeting started November 29 2004 16:03 EST (21:03 UTC) In attendence: Manish Singh (yosh), Owen Taylor (owen), Matthias Clasen (mclasen), Robert Ögren (roboros), John Ehresman (jpe), Sven Neumann (neo), Federico Mena Quintero (federico), Bill Haneman (billh), Maciej Katafiasz (mathrick), Ray Strode (halfline), Soeren Sandmann (ssp), Anders Carlsson (andersca) I guess we should start... Do we have any other agenda items, apart from old and new bugs ? I'd like to know when we can expect a gtk+-2.4.14 release Continuing last weeks discussion about milestoning, I have created owens proposed pool milestones for glib and gtk+, and have added some explanation to www.gtk.org/bugs.html So when moving bugs around the next time, we should probably move bugs from the "release target" milestones to "---", and then sort them back to the "pool milestones" I have also started to collect a list of mustfix bugs for 2.6, by moving them to the 2.6 milestone with high priority it would be great if everybody could add to that list for bugs in his area mclasen: where are you keeping the list? federico: In bugzilla, it sounds like... federico: the high priority bugs on the 2.6 milestone duh Nov 29 16:11:51 * federico reads again thanks :) there are currently 9 bugs on that list some of them are not really "mustfix" neo: is the ui manager performance still an issue for the gimp with glib, gtk+ head ? I'll add from the file chooser bugs to there what are the chances of getting some of those old a11y bugs cleared? mclasen: it works reasonably well with the gtk-2-4 branch as the perennial controversial bug, I'd like to resurrect the "esc doesn't close dialog boxes" one billh: We haven't really started talking about specific bugs yet. federico: Anythign there absolutley has to go through the UI team. owen: that wasn't a very specific question ;-) owen: basically, my opinion is that the UI team is being overly facetious on that issue *everyone* within novell complains about that bug, for instance billh: Well, I think the answer is "easy to fix bugs or bugs with a patch are good candidate to fix federico: does this bug have a number? neo: hold on federico: nod federico: Then that's good information to bring to the UI team (though I'm guessing that complaint refers almost exclusively to find dialogs...) esc should totally close dialogs owen: not really neo: #101293 owen: all low info, stateless dialogs qualify here federico: If the UI team is not making good UI decisions, the right fix isn't to ignore them I'd say message dialogs should get esc bound to dismiss by default federico: perhaps you want to adapt the GIMP's changes federico: GIMP dialogs close on escape mathrick: IMO, off topic for this meeting owen: k we haven't had any complaints about that behaviour owen: bugs that are >3 years old need fixes even if they are not easy, IMO billh: Great... billh: I assume that means that you'll be providing patches? owen: sure, with guidance on approach. owen: mostly we already have patches. w owen: ok, I'll see how to resurrect that discussion neo: (our package has a patch to enable esc for all dialogs) billh: could you attach the patches to the bugs in question ? the three bugs you mentioned in your mail don't seem to have any applicable patches, but tons of discussion my mail mentioned 5 bugs billh: Glancing at the bugs you listed (without actually rereading them)- 70986 wasn't clear for a long time if there was consensus, not sure if that was reached. 111031 relatively easy to fix though takes an afternoon of poking around in some unpleasant bits of pango. 62948 - absolutely no idea what the right fix is. I put some guesses in the bug report when I filed it, but still isn't clear. 89336 - mondo hard mclasen: my mail mentioned 5 bugs. Nov 29 16:25:05 * mclasen counts again... owen: I don't see any evidence of controversy in 70986. I think it's just lacking the implementation. federico: I think this is exactly what GimpDialog is doing owen: 62948 was one you logged, you seemed to have several ideas at the time. federico: it might be good to put some intelligence in here, like Esc closing settings dialog when nothing was changed, and undoing in other cases? That'd mean for all dialogs Esc wouldn't be good, but for example message dialogs should be safe to bind esc in them owen: sorry ;) billh: lack of implementation is also a considerable obstacle for fixing the bug... hmm, of course with the HIG suggested style of dialogs that have instant-apply but no way to revert the changes, that makes things difficult billh: 111031 seems like reasonable easy fix mclasen: not for the bug I refer to. Impl for that bug is trivial if we get the OK to add the feature. bug 155751 is all valid suggestions, (I think largely on other bugs as well), but doesn't seem particularly a11y related. owen: all typeahead-related stuff has a big a11y impact. But as I said, that's for you and Calum and the rest of the gtk+ & usability teams billh: It's also unclear to me why 62948 is a11y related. It's an internationalization issue mostly. The only concrete solution I had in there was "add a commit key sequence to GtkIMContextSimple" billh: One reason that's that been sitting around for a while is that it has a clear relationship to "validation" for dialogs owen, mclasen: so what I am hearing is: 111031 should be fixable soon (we needed your agreement on the API). Perhaps 62948 should be tabled for now. Since you want to force a commit pretty much exactly when you want to validate an input sequence owen: actually it could have big a11y impact - think of screenreaders, etc. i.e. what do they get from a text component that's partway through an input sequence? billh: Well, input-method + accessiibiltiy running at the same time is pretty much uncharted territory why do you say that? billh: But certainly changing preedit text to be part of the text buffer retrieved programmatically is not really something I'd consider obviously you need both for a11y i18n billh: have you guys been testing it? Do you expect it works? you gotta get that info somehow we've been mucking with it some. Things like this bug can get in the way. if it doesn't work, it'll just have to be fixed. If you need access to preedit text, you need to define ATK interfaces for preedit text . no way we have ATK interfaces, we just have to decide how to apply them to this situation. billh: After all, you have to represent to the screen reader that the text is preedit. true possibly via attribution ok, let's take that one offline. Is the beep-when-moving-off behavior acceptable? (70986)? billh: Do other platforms do it? Other toolkits? I don't have any memory of that for multiline controls yeah lots of apps do it, I believe windoze does it, terminal does it. It's part of the Windows Accessibility Guidelines. we probably want some global control about that, a setting... (The system beep is clearly entirely a too intrusive visual alert for that, but we don't have a lot of control there...) does gtk currently beep at all, ever ? Calum's given it the thumbs up since 2002 s/visual/audio/ mclasen: Did we add it for notebook tabs and radio buttons? owen: there are two system visual bell types available. The window-border one isn't very intrusive at all (possibly not intrusive enough) owen: right, agreed. err.. well no I am not sure I agree, but I understand. owen: I have never seen a notebook beep err, heard notebook seems to beep if you control-PageUp/Down off the end. All other occurrences of gdk_display_beep() in GTK+ seem to be for places where a g_warning() would be more appropirate owen: note 89336, mostly fixed by patch for 101309. Patch is from you :-) but never applied (since 2002) owen: the notebook behavior seems good. If it needed to be a system setting that'd be OK too, but I'd suggest one boolean for all the "beep when..." end-of-range navigation stuff billh: If it's right, it almost certianly needs to be on by default, at which point the system setting doesn't really have much attraction to me. (Personally, I just turn off the X bell entirely) yes, okay. I don't mind that. owen: do you use the metacity setting for that? (turning off the audio bell) If I put my own patch in bugzilla rather than applying it, that's a fairly strong sign that I wasn't entirely happy with it i have my bell actually unplugged at the hardware level billh: Not using a visual bell. I think I may have just turned the volume to zero in keyboard-properties owen: not many people outside the gtk+ team would attempt to rewrite one of your patches ;-) owen: you don't need to turn on the visual one in order to turn off the audio bell (from metacity). but this is not exactly mustfix stuff, even if these are important bugs which would be nice to get fixed for 2.6 if a patch appears soon billh: Well, at least getting review from someone inside the GTK+ time. billh: Why is metacity involved? where "soon" means during the next two weeks... mclasen: this stuff has been getting pushed from milestone to milestone for years. s/GTK+ time/GTK+ team/ billh: yes, unfortunately mclasen: and it's always the same answer. It doesn't work, in the end. The process is not working entirely well for a11y. what I would like to get marked with high priority for 2.6 at this point are regressions in existing features (e.g list store sorting not being stable) or brokenness in new features (e.g. icon view not working with sorted models) owen: because metacity is the best agent for delivering the visual effects.. and because philosophically it's not too far off base to put this in the WM functionality. It seemed silly to put the 'no audio bell' feature in a different piece of code from the 'visual bell' feature. billh: Well, we know we have a problem with that, which is the whole idea of the introduction of "pool milestones" billh: I will go over your list and comment on them, maybe we *can* get some of them fixed for 2.6 mclasen: I thought you fixed the list store stable sort bug? ssp: no, looked quickly into it, but it was unclusive err, unconclusive billh: the idea is that bugs will get nominated to be moved out of the pool onto a specific milestones only when we have a specific plan about how to get it fixed, and then it becomes quasi-mustfix for that release mclasen: thanks a lot mclasen: you tried taking the nodes from other end, and it didn't work? ssp: it crashed. maybe I made a mistake owen: okay - the plan stuff seems to get bogged down . seems the common characteristic of the bugs is that they went into some sort of stasis regarding the "plan" billh: Huh? It was only introduced last week!!! :-) billh: Oh, you mean not the new pool milestones plan, but the plan for the particular bug billh: Most of the ones listed there never had a specific plan for resolution. billh: part of the problem with these long winding bugs is that it can become unclear who has the ball, so to speak yes billh: a specific plan means a) what needs ot be done b) who is going to do it c) when is it going to be done by billh: and once a bug is beyond 20 comments, it becomes hard to pick up the ball again... owen: the process of agreeing seems muddy mclasen: I'll look at it then ssp: thanks billh: well, the idea is we'll do it at these meetings. Just that right now we're at the final-stages for 2.6.0 (two more weeks). owen: I know, it's a little late. mclasen: Are there other gtksequence bugs? I am not really keeping up with gtk+ bugzilla anymore. ssp: I'm not aware of others owen: thanks a bunch anyhow. Maybe we can get one or two into 2.6.0 ok. Should we spend the remaining 5 minutes on bugs from the last millenium ? mclasen: I think they are mostly "need a volunteer" bugs owen: 3355 looks like a wontfix candidate to me because providing a buffer to the entry doesn't actually make the entry contents much more secure... mclasen: Well, some. mclasen: The keystrokes leak out, but usually individually. But "968 bugs found" is a fairly strong argument for WONTFIX if we aren't just going to fix it immediately. it also has companion bugs which ask for glib facilities to allocate unpageable memory... mclasen: That is less important, since that can be easily worked around outside of glib. Reimplementing GtkEntry is harder true 1529 also looks like a wontfix candidate to me...you commented it as "I don't see this as all that fixable"... 1165 and 1579 probably need someone to make a list of all widgets which still need fixing, and an outline of the necessary steps, so that volunteers can easier attack them 1529 I think definitely should be WONTFIX'ed at the GTK+ level. If pkg-config wants to start doing it, it can start doing it. for 2250 we should probably verify that --disable-rebuilds works on a readonly srcdir, and mention it in the docs if it isn't sounds reasonable. But doesn't automake-1.7 require readonly srcdir for make distcheck to pass? dunno roboros, jpe: how does win32 currently look ? The filename encoding stuff is still affecting the file chooser ? mclasen: if 1.7 doesn't require readonly srcdir, then we likely will have to do a bunch of work to fix readonly srcdir when we upgrade to 1.9 owen: I'll investigate mclasen: tml added a little comment to bug 101792 err 159719 but it's probably not just the file chooser ugh -> /opt/gnome-2.10/bin/epiphany: relocation error: /opt/gnome-2.10/bin/epiphany: undefined symbol: g_get_language_names b roboros: just wondering if I should wait for win32 fixes before doing the next 2.5.x release...since it will be the last before 2.6.0, it would probably be a good idea to have it working on win32 and get people test it on win32 as well sorry, mis-paste mclasen: you have to ask tml how much work he thinks is left but it seems pango module loading, gtk immodule loading etc are also affected, at least from a quick test ok, I have to go now. I'll try to contact tml. My plan is to do 2.4.x and 2.5.x releases on Thursday. Bye this thursday? if the binaries are in a dir with a funky name this week thursday Meeting ended November 29, 17:15 EST (22:15 UTC)