Meeting on irc.gnome.org:#gtk-devel Meeting started August 10 2004 10:08 EST (14:08 UTC) In attendence: Jonathan Blandford (jrb), Matthias Clasen (mclasen), Owen Taylor (owen), Soeren Sandmann (ssp), Federico Mena Quintero (federico), Bill Hanemann (billh), Padraig O'Briain (padraigo), Billy Biggs (vektor) so, I don't know if bill and padraig will actually appear, lets maybe wait for 5 more minutes (but not more, since the we (RH) people have another meeting at 11) ok, maybe we should start with something else than a11y then... my plan was to do another 2.4.x release by the end of the week for the next gnome beta. mclasen: that sounds nice; I need to finish fixing some file chooser bugs federico: just the high-prio ones on 2.4.5, or are there others ? hi everyone, sorry I'm late hi bill hi bill hi jrb the nastiest bug on the list of high-prio 2.4.5 bugs is the broken fixed height mode of the tree view, but I guess there is little chance to get that fixed... billh: we started discussing 2.4.5, lets finish that off before we get to a11y... mclasen: want to post a link? mclasen: of course jrb: just a second mclasen: just the high-priority ones, but there's a new bug which should be fixed, and I'm not sure if I marked it 2.4.5; I'll check that. jrb: http://bugzilla.gnome.org/show_bug.cgi?id=135955 federico: ok jrb: the bug has a testcase which clearly shows that the tree view doesn't update the adjustments at all in fixed height mode... mclasen: I can try to look at that this afternoon, after fixing a python problem (and after the meetings...) jrb: cool, thanks. treeview bugs can be intimidating... ok, so tentative date for 2.4.5 is this Friday lets move on to a11y now is interactive search for the treeview on topic for a11y / file chooser? Aug 10 10:16:37 * federico has been a slacker and has not tested jrb's patch federico: it's in CVS now, dude federico: you should update and just try it padraig: I saw that you created a patch to implement a11y inside gtkiconview.c padraig: how much does that depend on the internals of the icon view ? Would it completely break if we decide to use cell renderers in the icon view ? mclasen: Currently it depends on the internals of gtkiconview. There would be a certain amount of rework if you decide to use cell renderers. jrb: ooooh (but the a11y for the tree view proves that, in principle, cell renderers are not inaccessible, I guess) mclasen: yes. mclasen: I would be interested in some feedback on my proposal to create a few high-level settings to control the speed of repetition/animation inside gtk+. Would it be adequate to have, say enable-animation, enable-repetition, animation-speed, repetition-speed, scroll-speed and animation-delay, scroll-delay, repetition-delay settings that's a polite way to talk to your subconscious mclasen: have a half-finished reply there; sorry federico: I'm doing that from time to time, normally not in public, though... mclasen: would those be shared across all widgets, rather than each having specific settings? federico: that was basically my idea: have a global double setting repetition-speed, and then all the timeouts we use to implement repetitions get multiplied by that factor... mclasen: for a11y, the first order requirement is to be able to turn animations off altogether. mclasen: this implies some loss of information however, so animations are inherently problematic (if they are providing any useful information, that is) mclasen: do we really need a tunable value, or would it be enough to have slow/medium/fast settings? federico: OFF setting billh: "animation" includes repetition, like spinbutton repeat if you keep the button pressed ? billh: does one need to be able to turn off repetition for scrolling? mclasen: that's a different thing: repetition rate definitely needs to be fully tuneable federico: I think the difference between having just off/slow/medium/fast and a double ranging from 0.0 - 100.0 would be marginal, implementation-wise. I"d say mclasen: but it might be best to have one "repetition rate" that was shared across various widgets that had repeat I propose: repetition on/off, with a range of values for initial delay and repeat rate (analogous to key repeat). I guess we would want to avoid repetition for keyboard activation and just let the key repeat take care of it... ? I guess by "animation" I mean visual depiction of moving images or transient visual phenomena. (and I would exempt text caret flashing from the general setting, since some users want _only_ the caret to flash, but no other animation) we use animation so sparingly, anyway federico: but we recently introduced a bit more, in the toolbar, and probably want more in general, don't we ? billh: thanks for the feedback. thats probably good enough to produce an initial patch. Do you have any proposals regarding the speed ranges ? billh: like "slow" would be 4x slower than currently, while "fast" would be 2x faster... ? for animation, I guess we have to see a) where we use it; b) if it makes sense to tune the speed --- do you really need slo-mo for a web browser's throbber? for scrolling, we have to figure out a range of useful speeds billh: what is the objection to animation? scrolling pixel by pixel is useless; scrolling by more than a page is not useful federico: for scrolling we may want to use at different other things, e.g. ssp worked on "smooth scrolling" in the text view billh: just so we can try to understand how it should be avoided There are basically three kinds of problems. (1) some users are confused or distracted by changing onscreen images, or worse, so we want to minimize onscreen movement (2) for magnification, etc., each screen update or movement requires the magnifier to re-compute the "relevant" area of the display to decide if the magnified viewport needs to be adjusted (3) for blind users, animation can result in pointless chatter as the assistive technology detects and reports the changes if we try to fix #3 by not reporting the changes, then we are likely to interfere with cases where the user actually _does_ want to be notified when the onscreen information changes. Lastly, there's the "Pokemon problem": we can't have anything that flashes on the screen in the range between 2Hz and 50Hz, since that can trigger seizures in some cases (and although a tiny moving arrow , etc. is unlikely to have this effect, a11y legal requirements don't distinguish between "dangerous" flashing and other kinds of flashing). billh: does that affect the text caret as well ? <50 is not mclasen: I believe so, we can't flash the text caret faster than 2Hz billh: The text caret speed is already configurable ... I assume someone is allowed to *configure* a speed between thoes ranges... owen: yes, of course. I think the current range for the text caret was set with this in mind. owen: actually, regarding _configuring_, I am not sure. OK, I haven't been paying a lot of attention here, but this discussion seems to be drifting a bit owen: I think perhaps with something as common as the text caret, it could be a bad idea (shared kiosk, etc.) Aug 10 10:47:05 * billh points to jrb's question owen: didn't mean to deep-end here I don't mean what you were saying in particular, I meant the whole conversation ... just wanted to see if we could get back to more specific issues, action items, etc. billh: no -- this is good. It'd be really good to get this summary sent to the list in reply to matthias's query so that we have an archive of the issues jrb: I can take care of that (If we are done with all specific issues, then drifting is fine) owen: this was in regards to matthias's animation query owen: I'd like to use the remaining few minutes (have to run for the shower in ca 5 min) to discuss 2.6 questions; what do we do with ssp's sequence-based list store, e.g ? jrb: My general feeling is that extended technical discussion shouldn't be the primary focus of the meeting, but whatever mclasen: I'd be willing to try it BTW, thanks, it looks to me as if the GtkCombo a11y issues got sorted. padraig, is that right? do we go forward and just replace the current list store implementation, or, considering the memory footprint issue, do we add it as an alternative implementation ? mclasen: What's the *relative* memory delta mclasen: It adds 16 bytes per row, right? But how many bytes per row are we using for a 1-column integer GListStore in a GtkTreeView? owen: 16 bytes per node ssp: ~32 bytes per row then? billh: I believe that GtkCombo a11y is OK. Of course, we may see bug reports when people start using it in anger. owen: no, 16 bytes per row ssp: I guess you also have a logarithmic overhead of internal nodes, don't you ? ssp: But there are roughly 2*n nodes for n rows, or? billh: GtkCombo->GtkComboBox mclasen, owen: no, there n + 1 nodes total ssp: no internal nodes ? fwiw, each GtkRBNode is bigger than the SequenceNodes The internal nodes are also used for data jrb: but the number of rb nodes is proportional to the visible area of the tree, so basically constant, isnt it ? jrb: Yeah, 28 bytes mclasen: not in a list mclasen: same number mclasen: The RB tree is covering the entire tree I think why doesn't gtkliststore just use a garray with a buffer-gap thingy for insertions? jrb: ah, but only the expanded part of the tree... mclasen: yeah. and on a list, it's all expanded federico: You can't do iters-persist with an array federico: Plus, gapped buffers don't work for sorted insertion which is the main thing that GSequence is trying to fix Aug 10 10:56:44 * mclasen runs for the shower; sorry about the little mess in gtk+ HEAD, btw. I hope to have that sorted out by tomorrow... Aug 10 10:57:22 * mclasen is back; 11am meeting got canceled... ssp: my initial intention was to use GtkRBTree for GtkListStore/GtkTreeStore mclasen: it was? oh, lucky jrb: walters claimed it... yeah -- I see now owen: I'm wondering how frequent it is to insert things in the middle of a list store; isn't it simpler to keep it unsorted, have O(1) appends, and just have a sort model on top of it? Can I use your time machine when you are done with it? federico: I actually think you'd have trouble keeping the sort model having good performance there, but I could be wrong federico: But it would certianly require major internal and some API redesign Aug 10 11:03:11 * owen killed that conversation.. it was getting too technical anyway... The conversation should happen on gtk-devel instead I think we should be very reluctant to introduce GtkListStore and GtkListStorePerformsBetterButUsesLessMemory if it uses less all is fine.... it really should be GtkListStorePerformsBetterButUsesMoreMemoryButLessThanTheView (MoreMemory). So I'd definitely be in favour of GSequence globally. But someone shoudl do some more detailed memory analysis ok, next topic: file picker. I have to admit that I haven't looked at Jimbobs last patch in detail yet... owen: I think the memory analysis is fairly simple in the GtkListStore case: 16 bytes extra per row ssp: Analysis I'm interested is how much is being used now ssp: If we are using 100 bytes per row (and i think we are using something in that range) then 16 bytes isn't much of a change Aug 10 11:16:31 * mclasen heads for the shower anyway now... if we are seriously considering including more new stuff like filepicker in 2.6, could we get some help with the ATK implementation and testing? Aug 10 11:29:25 * billh guesses that was taken as a rhetorical question ;-) billh: Well, mclasen and ssp have left... owen: just back billh: In terms of testing, I don't think you are going to get a lot of help from the GTK+ team ... most of us don't even know how to set things up, much less what you expect billh: as far as I see, the only candidates for new 2.6 stuff at this point are the file picker and some hig api in gtkmessagedialog owen: but why is that? owen: I have used at-poke before... owen: I mean, there is substantial new info on the website (since gtk+ 2.2 anyhow) billh: "new info"? mclasen, owen: yes, the worst/most obvious stuff can probably be seen easily with at-poke even if you're not sure what you're looking for billh: Oh, on the gap page owen: docs on testing yesh s/sh/ah billh: I just dont' think you can expect us to have the cycles to aggressively test ... the team isn't large, we have a lot of stuff to do. So we should concentrate on where we have knowledge / skills, which is implementation and patch review. owen: still not exactly a cookbook, but probably enough so that if a developer made a 'good effort' to read and apply the docs, we'd get 90% of the way there owen: but understand that implementation requires some knowledge of testing owen: and patch review isn't efficient if there isn't gtk+ team involvement from the outset, in sketching out approaches. owen: I understand the resourcing restraints (all too well!), but line-for-line it's a hundred times more efficient for the gtk+ team to do some of this stuff. owen: I don't expect "aggressive testing" but I would hope that the gtk+ team would look at at-poke/atk alongaside everything else when examining candidate widgets. That's all I'm looking for. billh: a11y certainly is on my mental checklist for stuff a good widget needs to do, right after theming and rtl owen: and padraig or I can help with the implementation and give feedback on behavior - it's just tough to do both test and implementation without concurrent input from the gtk+ core team billh: I guess I just have no idea what I'd expect to see in at-poke for something like GtkFileButton mclasen: thanks, I can see that from your comments and email queries, which have been helpful. (Not that I'm doing any GTK+ work at the moment...) billh: but whereas for theming and rtl the action is "fix it yourself", for a11y it is "ask a11y team" owen: GtkFileButton? is that in the FilePicker patch? billh: FilePicker, whatever its called. billh: thats the tentative name of the file picker (ref. GtkColorButton, GtkFontButton) billh: the current patch is in http://bugzilla.gnome.org/show_bug.cgi?id=148108 owen: right. I guess the main thing is, "does the important onscreen info appear in at-poke ?" owen: to some extent if the answer is yes, the rest is just nitpicking owen: (I mean, questions of whether it's organized in the best way, etc.) mclasen: I meant to apply and test already, but ran out of time Aug 10 11:43:20 * billh DLs the patch did I hear correctly that HEAD is a little wonky ATM? billh: yes, I hope to sort it out today mclasen: will it build? Aug 10 11:51:11 * billh finds out billh: let me know.. (-; jrb: heh, no make[4]: *** No rule to make target `x11/libgdk-x11.la', needed by `libgdk-x11-2.0.la'. Stop. Aug 10 11:55:29 * billh tries building in gdk/x11 first gdkalias.h is very unhappy Bug 149757. vektor: my prob looks like a different bug, possibly. (lots of warnings, but gtkalias.h is there OK) billh: I have a fix from arjan in my inbox, let me see if that helps ok, I guess this meeting is over for some time now, i'll post logs. owen, did you put up last weeks logs on www.gtk.org, or can you give them to me, then I"ll put them up as well. mclasen: Just mailed it to you owen: thanks Meeting ended August 10, 12:06 EST (16:06 UTC)