Meeting on irc.gnome.org:#gtk-devel Meeting started July 27 2004 10:00 EST (14:10 UTC) In attendence: Owen Taylor (owen), Jonathan Blandford (jrb), Matthias Clasen (mclasen), Federico Mena Quintero (federico), Soeren Sandmann (ssp), Anders Carlsson (andersca), Ray Strode (halfline), Matthew Garrett (mjg59), Bill Haneman (billh), Padraig O'Briain (padraigo), John Ehresman (jpe) Looks like we're pretty complete now. (jrb is probably somewhere on the street between groton and westford...) hi, bill, padraig while we're getting started, is there a URI where Padraig and I can look for a list of new gtk+-2.6-slated stuff? hi federico billh: a highlevel overview is at http://www.gtk.org/plan/2.6 billh: querying bugzilla for the 2.6 api freeze and 2.6 milestones yields far too much stuff... yes, I was trolling the list archives... the 'plan' seems like the best starting point. thx billh: the icon view will need some a11y love mclasen: I expect so. who's available to help look at it? I notice that the sheet/drawer suggestions aren't in the 2.6-plan (yet) billh: Definitely out of scope for 2.6 billh: andersca and me did the most work on the icon view, so we're probably the best to ask about it 'sheet' is likely to take a lot of a11y work, the AtkTable API would need to be implemented. billh: The feature set for 2.6 is supposed to be more or less complete at this point owen: good to know, thanks. I can look at the icon list widget. I am nervous about the "about" dialog as the GNOMNE about dialog was highly inaccessible. billh: one more new widget which we want to get in 2.6 is the file picker. There is a patch for that somewhere in bugzilla if you want to look at that billh: "sheet" as in sheet/draw is actually different than sheet as in GtkSheet, but both are out-of-scope for this release just running the new 'about' with HighContrastInverseLargePrint theme would help flush out some issues, probably. * billh doesn't have the new about yet padraigo: it was? why? billh: the bug for the file picker is 148108 andersca: I don't remember the details off the top of my head. Perhaps Bill can. There are a lot of bugs open on it. billh: if you have 2.5.0 compiled, the new about dialog is demoed in the "app window" example in gtk-demo andersca: didn't theme properly, had un-keynavigable hyperlinks, and generally did stuff that wasn't keyboard-accessible. other stuff too. andersca: and was judged "too difficult to fix" by multiple people who looked at patching it :-( ok :/ Jul 27 10:20:07 * mclasen turns on HighContrastInvers mclasen: try the LargePrint variant too, it tries to make focus indication thicker and makes icons larger. hmm, one issue with GtkAboutDialog in HighContrastInverse is that the "credits" appear in white-on-light-gray... mclasen: and of course, bump up Font to 18 point or so, when time permits mclasen: sounds like the bg color isn't getting pulled from GtkStyle then billh: I have focus-width set to 10 for other reasons anyway...but I guess we should look at GtkAboutDialog in detail off-meeting :-) billh, mclasen: let me know if you come up with fixes, they should probably apply to GnomeAbout too andersca: isn't GtkAbout supposed to replace GnomeAbout ? billh: yes, but gnome 2.7 will still ship with GnomeAbout and it'd be nice if that was accessible ok, thats a nice transition to accessibility of existing widgets... is that on the schedule? andersca: (http://bugzilla.gnome.org/show_bug.cgi?id=125295 is one gnome-about bug) oh, that's the program gnome-about not the widget GnomeAbout ah sorry billh, padraigo: where does gtk 2.4 stand in your opinion, a11y-wise ? I guess the most problematic cases are combo box and file chooser, right ? federico, you provided an accessor for GtkCombo recently, right? Padraig, did that un-block your GailCombo patch? Bug #132847 is the problem with combo box. If that was fixed I have a patch for gail which fixes all currently reported issues. I have not seen what federico did recently. 132847 maj Nor NEW gtk+ combobox GtkComboBox widget is not accessible accessibility, PATCH 138085 nor Nor NEW gtk+ gtk cannot keynav to selectable labels accessibility, keynav, PATCH 131226 nor Nor NEW gtk+ GtkTreeV Unable to select listview files with keyboard accessibility, keynav, PATCH, usability I am not aware of any problems with the file chooser that are not combo box problems. billh: no, I didn't... what was being discussed is to move the a11y implementation for the combo box into gtk+ itself there's the discoverability problem with the entry box billh: I don't remember an accessor patch by federico for GtkComboBox. What I did for 2.5.0 was to make GtkCellView public and remove GtkCellViewMenuItem what I want to discuss, especially now that matthew is here, is the file chooser's (lack of an) entry In an ideal world, basic functionality wouldn't depend on an input method that behaves like a keyboard so I have a few questions for you guys :) mjg59: How does GtkFileChooser depend on an input method that behaves like a keyboard? ok - federico, before we leave GtkCombo, who should take the action to import padraig's two patches into gtk+ (existing patches are gtk+ accessor patch and libgail GailCombo patch) federico: Note that the relevant people aren't here for discussing UI redesign of GtkFIleChooser, if that's relevant owen: I could get calum owen: There's no means of getting the text entry widget without being able to send ctrl key sequences owen: I don't think we need a big redesign; just pick an appropriate place for the entry if it is really needed federico: Umm. federico: Adding an entry definitely is a major design change owen: I *think* the entry is useful if you know how your files are called, but I don't know if people who rely on a11y heavily tend to remember their filenames any better than people who don't use a11y owen: what was our take on the addition of gtk_combo_box_get_popup_accessible() ? owen, federico: my suggestion, which I think it a compromise, was to add a small GtkButton in the focus chain which popped up the entry. It could be labelled with just a small icon of some sort, and the appropriate AtkObject name. s/I think it/I think is hmm, could entry usability be a style property? s/usability/visibility/ that would make it theme-dependent, which would only solve the issues for some cases andersca: no, entries should always be usable :-) andersca: Doesn't strike me as appropriate use of style properties. If any sort of setting, a GtkSetting. mclasen: Which just called gtk_widget_get_accessible() on the popup? the popup bottom would be small/inobtrusive, but still discoverable and actionable via mouse or keyboard. mclasen: I don't think we discussed that option in particular owen: yes, padraig has a patch which does that, and sazs that it solves his problems mclasen: I prefer it to gtk_combo_box_get_popup_widget() certainly mclasen: (Not that it isn't equivalent since you can navigate both ways if I remember correctly, but it's more focused) owen: one of the reasons we opposed get_popup_widget() is gone now; GtkCellView is no longer private mclasen: I think it's probably OK. If padraig has it working that way, I'm not sure it's worth going to a lot of effort to do something else padraigo: Have you tested with both menu and list mode? owen: I don't remember. It is a long time since I have looked at it. billh: Adding a button might be OK if we had a proposal for where to add it. But I don't think it woudl address mjg59's concerns. Though I'm not sure exactly what those are mjg59: In some sense, for dasher, don't you really want more intimate connection where you are actually navigating through the filename space rather than the "text" space?" mjg59: In the more general "is it accesible at all through my input method" - certainly there are lots of other parts of GTK+ that are only keyboard accessible through shortcuts owen: having the button would allow to bring up the entry without using the keyboard, and would make the entry more discoverable, but I think many people who complained about the new file chooser would prefer to a) have the entry integrated in the dialog instead of in a popup which covers part of the dialog and b) visible by default yeah, how does dasher work with respect to lists? does it say, "oh, here's a list widget; let's fetch the text in the list items and let the user dash through them"? mclasen, owen: the button could be a toggle whose state persisted across invocations, and the entry could be integrated into the dialog layout. Or is that too complicated, implementation-wise? mclasen: The problem with integrating an entry into the dialog is that suddenly you no longer have the list focused by default and keynav works much less well mclasen: keynav and completion in the control-l dialog is very well defined. mclasen, owen: (i.e. functionally like an expander, but connected to a gtksetting) mclasen: keynav in the main dialog (once we get rid of C-f) is also convenient and well defined mclasen: But you can't put both into the same dialog and get something that is as nicely integrated. mclasen: The save as dialog expanded doesn't keynav particularly well some of the loudest complainers about the lack of an entry say that they would be happy if #137871 were fixed we could do some fancy stuff there, like switching folders when you press a / owen: Ideally yes, we'd detect file selectors and actually try to represent the filesystem in it. I'm not entirely sure how to do that sanely, though. owen: yea, C-f is a bit wierd. The popup doesn't even have a clear frame, it visually merges into whatever is underneath it... mclasen: theme bug there, probably. federico: I really think we should concentrate on fixing that first before we start looking at entries owen: There's several bits of GTK functionality where modifier keys are required, but the file selector is the major one where it actually hits the user - most functionality is exposed through widgets owen, mjg59: I think the discoverability issue is the main one here - dasher allows users to either enter text, or activate "actionable" widgets. The entry is more-or-less neither. billh: Exactly billh: I don't think so. its the same with all themes I tried. The popup needs a small black frame, I think, like most other popups have (e.g entry completion, combo box) owen, mjg59: that's why I think having an actionable component for the entry box would help - at least dasher could expose it via its AtkAction/GUI-controls interface. billh/mjg59: But isn't having to navigate to a little button tucked somewhere in the interface and activate it then type your filename pretty awful? owen: then we need to put interactive search in 2.4 owen: yes, but it's better than having to navigate to some control key followed by some other key, etc.. billh: We discussed this before right - couldn't there be an action on the filechooser widget to pop up the control-l dialog? owen: For accessibility applications, it doesn't matter - the size of the widget in the UI isn't represented in them It's certainly no worse than the current situation federico: 2.6 will be along before you can blink twice. I think we need to make 2.4 bugfix only and move on owen: that doesn't solve the discoverability issue for users which don't use a11y tools, though owen: but people won't be using gtk 2.6 until gnome 2.10 hits the streets, which is a long time from now owen: That does require special-casing filechoosers, though that's not inherently a problem (which reminds me, we really need to synchronize the gtk/gnome schedules) mclasen: But for those users is discovering that you can press a button really useful? If they want to keynav, they probably dont' want to use the mouse to click a button and or want to tab 4-5 ti times owen: but maybe we can label the button "C-L me" or something... owen: or put a tooltip there explaining C-L... federico: I think 6 months is too short for GTK+ owen: yeah, though exposing multiple actions on widgets gets tricky for ATs. federico: I'm not *inherently* opposed to a backport of C-f-less interactive search to 2.4, but I think it needs to get real world exposure on the unstable branch first owen: sure, we can do that owen: depending on the focus chain, it might not need to be 4-5 tabs; it could be just 'before' the list, so Shift-Tab would take you there from the initial focus point. federico: But gnome-2.8 is feature frozen, so we're aren't going to get it in users hands by your computation until gnome-2.10 anyways... owen: would one have to programatically enable interactive search in a tree view, or would it Just Work if you already enabled the C-f thingy? federico: That's one reason it needs to get real world testing. It's not clear to me whether existing apps break if typing with a treeview focused starts interactive searching federico: it should just work federico, owen: if there was agreement on C-f within gtk-devel, I doubt there would be much resistance to allowing it in gnome-2.8 as a freeze exception (we're only very recently frozen, no?) billh: I don't think there would be agreement within gtk-devel :-). It strikes me as the kind of potentially problematical change that freezes are there to prevent. Though that's just me. i mean, if it were considered appropriate for a gtk-2.4.X back-port... I don't think anyone would complain so, what remains to be done to put interactive search in HEAD? jrb: One thing we could do is through an interactive backport into fc3 and see what happens with that? federico: I had trouble w/ an offscreen entry owen: that's a good idea mclasen: (I agree about the frame for the entry box, should have a frame around it. Probably not hard-coded black, however :-)) Jul 27 11:00:07 * jrb really wants it to be snazzy and slightly-translucent. jrb: we can make it translucent in 2.8... mclasen: yeah. I can't wait. Black border will do for now speaking of discoverability of stuff in the file chooser there are two ways to make it show hidden files right now: through the context menu in the file list, and through typing a dotfile in the C-l dialog neither of which is particularly discoverable federico: looking for hidden files is pretty esoteric; and I don't think a context menu is that off-base where would we put a "click for a drop-down with options" button? I was thinking of the little square in the file list where h/v scrollbars would intersect jrb: people *still* complain about not having a way to show hidden files; it's just that they haven't right-clicked federico: what if the list is short enough to not have scroll bars ? mclasen: always display a vscrollbar and the button below it federico: discoverability again federico: actually, the "click-to-drop-down" thingy could be the same as the "click-for-entry-box" thingy - we could make the entry box a CheckMenuItem s/make the entry box/make the entry box option billh: the question is where to put that button sure - calum? Jul 27 11:08:03 * calum opens the fileselector to have a look I really don't like the idea of adding a GtkEntry as an option. The dialog is simply not going to be more usable for anyone with an entry, just more confusing. owen: I don't think there's agreement on that point. You may be in the minority. After all, dialogs have had entry boxes for a long time, on lots of toolkits. But on the other hand, dialogs haven't had pathbars or shortcut lists on most toolkits... you can't just combine elements from two designs and get something better owen: and what of 'save as'? there's a case where an explicit entry is needed, why should the two dialogs be dissimilar? the C-l dialog is useful if you have to open files in very scattered folders and you know the names of the folders by heart billh: As I said above, I'd really like to see what people think of better interactive search keynav before we start adding more controls the current selector is a problem though. hi so if I'm in /home/federico/Documents/Papers/blah and need to open /cvs/gtk+/gtk/gtkfoo.h, it's faster to type with autocompletion than go back to the filesystem shortcut, etc. *but* that's because I know the complete name of the folder, and I type fast if your working set of folders is small, bookmarks are just wonderful billh: The two dialogs are disimilar because the intended use cases are disimilar is it ok to ask questions about gtk+ 1.2 here? federico: I wish we had good keynav to the bookmarks Jul 27 11:14:28 * calum checks out the Longhorn file open dialog to see what they're doing Zimba: no Zimba: Nooooooooooo! wah! :-) Zimba: Here it's not even acceptable to ask questions about 2.4.4. Zimba: This is for disucssion of 2.4.5 and 2.5.1 and 2.6 and 2.8.... owen: I think it helps the user for these dialogs to be closely related to one another Zimba: Feel free to start your own #old-gtk channel, but you are going to be lonely there owen: i.e. I don't accept that navigating the filesystem for 'Open' is radically different from 'Save As...' if anything, I'd like a way to keynav to the shortcuts list quickly oh, i see.. so this chanel is for gtk developers, not for users. maybe have C-b go to the bookmarks, just like in epiphany or something Zimba: yes, and you just stumbled into a meeting :-) if i can make a suggestion.. make gtk as fast as possible. stop bloatware :-) federico: It woudl be sort of nifty if you pressed down control and little numbers appeared next to the shortcuts/bookmarks and you hit one of the numbers and it jumped to it. Something like that. federico: yeah. we really need better mnemonics on that dialog c u ooh... owen: Lotus Notes has something like that...I absolutely hated it billh: Do I have data to back up my opinion to the contrary? No. But what I don't want to do is start from a coherent design then piecemeal add one thing or the other and end up with something like the KDE file selector. If we want to make design changes, I think we need to make them as discrete proposals with new mockups, bring them up on gtk-devel-list, bring seth into the discussion mclasen: Out of curiosity, why? I guess it's sort of annyoing since the key shortcuts change if the list changes owen: epiphany uses alt-numbers to switch between tabs Jul 27 11:21:09 * owen alt-numbers back from a differnet tab in xchat... ok, I can implement that easily minor question; should the separator count as a number, so you hit Alt-5 or something and nothing happens? or should it skip to the next bookmark? owen: Maybe if was just the general LN ui from hell, or maybe it was because the also used that "numbered shortcut" feature in places where regular shortcuts whould have worked... federico: SHouldn't count as a number federico: separators should not be selectable at all. We need to fix treeview keynav to skip them... federico: how about when alt is pressed you show a new cell renderer that's right aligned federico: with the number owen: I am just pointing out that the current selector has known problem, which seem to be omissions of a sort that there's some shared opinion about. Of course new stuff shouldn't be a catch-all, but we shouldn't be afraid to fix stuff that isn't working. andersca: nice idea andersca: where does it get the number from ? first component of path ? mclasen: first component + 1 since you don't want alt+0 for the first one andersca: you get gaps for separators then, though billh: I'm generally of the opinion is that if you get lots of complaints with people wanting feature X it doesn't mean you should add feature X, you should go and figure out what's the problem they think adding feature X would solve for them btw, mclasen owen: the clear problem is that the current entry mechanism is neither discoverable by users in general, nor directly exposed to a11y mclasen: I think that the about dialogs should have the separators removed andersca: can you take care of that ? billh: But why do people want the control-l dialog? mclasen: sure mclasen: should I change the button to close instead of ok? (it's what GnomeAbout does currently) andersca: sounds right owen: in order to enter filenames directly (lots of different reasons why that's easier sometimes). For blind users, definitely more efficient, for instance. owen: and for dasher users, possibly more effective ( at least until/unless dasher gets more integrated into the list itself ) billh: so more efficient for most folks, probably... it's much easier to make (and harder to correct) typing errors with typeahead solutions, in my experience anyway... would getting typeahead in the list mitigate much of the need for the C-l dialog? OK, I'm not sure it's productive to have a UI design debate about filesel here. I'm certain it isn't productive to have it without seth around, and likely he's just waking up now. jrb: hard to say really, since as a side-effect it would probably generate a very busy event stream from at-spi - that might effective make it more broken than plain text entry. It would probably help dasher users (typeahead) Jul 27 11:34:55 * mclasen heard seth making noises in the next cubicle already, so he should be awake... mclasen: I'll make sure that the license scrolled window around the license textview has a shadow Wow, seth arrived and I (and the rest of the office) didn't hear him. That's a first.... andersca: if you're looking at the about dialog anyway, can you also investigate the theming bug (the credits dialog didn't seem to pick up theme colors) ? mclasen: sure Jul 27 11:36:30 * mclasen shortens his todo list IMO, if people really think we should say, change to a options menu that can turn on an embedded dialog, they should make up a rough mockup and a description of how it works, send it to gtk-devel-list. But if people want to continue the discussion here, I have lots of Pango work to do :-) owen: before we close this meeting, I'd like to quickly discuss 2.5.1 and 2.4.5 mclasen: Yes, that would be good oh, and the schedule for the next meeting...but first releases so, according to our 2.6 plan of doing 2.5.x releases every other week, we need a volunteer to release 2.5.1 sometime this week I have no time; have Real Work(tm) to do these days :( owen: can we recap the decisions that were made re a11y? owen: ignoring the filesel business billh: A) Someone needs to test GtkAbout B) We will add gtk_combo_box_get_popup_accessible() was there anything else? and what about the new widgets, a11y-wise? "someone" needs to be identified, as well billh: andersca said he can do A), I can do B) mclasen: thx. A is almost done I think padraigo said he can look at the icon view what of filepicker and icon list? My main concerns are that we get the support we need before API freezes, so the assessment and initial patches need to be done before then. padraigo, mclasen: thx, I see the icon list item's addressed. billh: according to plan/2.6, we're targeting approx mid august for 2.6 api freeze, but I main filepicker Qs are theming (HighContrastInverse), keynav for all features, and exposure of AtkObject and events but I'm sure we can handle minor a11y related additions after that mclasen: mid-august gives very little leeway, true. does the filepicker patch apply/build cleanly to HEAD now? I can do an initial eval if it does billh: haven't tried, but it should. don't forget to automake after applying the patch, though mclasen: sure ok, if nobody else wants to do it, I can try to do 2.5.1 next weekend Lets just very briefly discuss 2.4.5. federico, mitch seemed to think that 148420 is a serious problem in glib-2.4.4. Do we need to roll out a quick 2.4.5 to fix that ? mclasen: probably I need to mail the list about that there are several issues at playÑ : 1. prior to my patch to g_filename_{to,from}_uri(), there were cases where you would not be able to turn certain filenames into URIs 2. but the other day I was looking at RFCs, and they don't say anything about what you should get when you unescape a URI --- nothing is mentioned about encodings <- that is what is not defined in the standards 4. there is a draft RFC for some webdav craziness that says that you should first convert local filenames into UTF-8, *then* escape that for a URI (which is, essentially, what we had before (1)) federico: Check the nautilus code for what it does for human display of filename URIs? federico: It conceptually is no different than human display of filenames, though right? Someone has to interpret bytes as humna readable text, it's just a question of who do we guarantee roundtrips for file/uri <--> human readable text, or is that just a one-way conversion ? mclasen: No, we don't want to gaurantee roundtrips so, should we fix 148420 by removing the encoding check and do a 2.4.5 this week, given that 2.4.4 is probably almost unusable with non-utf8 filenames ? oh, and before everybody runs off for lunch, should we meet at the regular time (21:00 UTC) next week or keep the early schedule ? hey, any prospect for reviewing the a11y patches from padraig in the P1/P2 category from Calum's a11y buglist http://gnome.org/~calum/access-bugs-openonly.html ? for 2.4.5 I mean owen: it does nothing special, just unescape_uri(), convert to UTF-8 (brokenly, only paying attention to G_BROKEN_FILENAMES and not G_FILENAME_ENCODING), and displaying that billh: if we decide to do a 2.4.5 this week, it would only be glib...I can look over that list for gtk 2.4.5, probably... hmm, seems people are already disappearing for lunch... billh, padraigo: do you think the joint meeting was productive ? Should we do this again, say in a month or so ? You're of course welcome to join our meetings every week... mclasen: it was, except possibly the filesel deep-end... but I fear we didn't get to the main a11y issues. s/main/other billh: yea, I also had one more a11y q prepared for today, which we didn't get to: we have lots of hardcoded timeouts in gtk for things like scrolling, animations, popup delays, etc. Do you think we need to make them changeable via settings/style-properties ? mclasen: for hard-coded timeouts, the usual answer is "yes". but really, only if the resulting timers are actually significant to the user. i.e. does the animation provide information which the user might otherwise miss? Does the timer require the user to take action within a certain length of time? if answer==yes, then it has to be configurable. billh: I have a list of ca 35 constants, but they mostly fall into 2 or 3 groups, like text scrolling / other repeat functionality / animations billh: I can e.g. imagine that the spin button repeat is too fast for some users, and users are required to release the button fast enough to keep it from kicking in... yes - things like repeat functions definitely need to be configurable - probably totally turn-off-able too. mclasen: thanks I guess the meeting is effectively over now, I'll post the meeting logs shorty. Unless the a11y team expresses the desire to continue this discussion next week, I'll move the meeting back to the regular time next week, and we can do another joint meeting sometime later it helps a lot that you're thinking about these things billh: I'll try to summarize my findings in a bug and send a mail to gtk-devel I'd like to join in two weeks or so, just so we don't miss the 2.6.0 window billh: ok, I'll keep that in mind. Would half an hour later still be ok for you ? mclasen: more-or-less - I have another meeting that starts at 16:00 UTC, so I can only meet for 90 min then. billh: this meeting was unusually long, normally we keep it under an hour * mclasen goes off to find something to eat... Meeting ended July 27, 12:25 EST (16:25 UTC)