Meeting on irc.gnome.org:#gtk-devel Meeting started December 6 2004 16:05 EST (21:05 UTC) In attendence: Manish Singh (yosh), Owen Taylor (owen), Matthias Clasen (mclasen), Jonathan Blandford (jrb), Robert Ögren (roboros), John Ehresman (jpe), Federico Mena Quintero (federico), Soeren Sandmann (ssp_), Douglas Pollock (desudation), Billy Biggs (vektor) ok, maybe we should start by talking about typeahead owen: you want to have it off by default for 2.6 ? I don't have a strong opinion, just thought it was something we should discuss the issue is that it catches "ordinary" keys and thus may interfere with apps, right ? I think that's the big issue. THere is a small issue that it (and the existing C-f search) causes selection behavior which can cause some apps to segfault. Not new bugs, but possibly more exposed bugs. do we have a separate property to turn it off (independent from the C-f search) ? I think jrb is away at the moment, and he's really needs to be in on this discussion ok, then we can maybe switch to the other urgent 2.6 issues until he returns I have looked at some of the bugs from billh's list of a11y bugs and have produced a patch for 111031 nor Hig NEW gtk+ GtkTextV 2.6.0 Unable to determine what character is at a point but the result confused me...ignoring "trailing" seemed to make the results worse. or maybe I am just misinterpreting the output of padraigs test case Without a graphical representation of the test string, it was hard for me to interpret the test results maybe we need a test case which prints out the character under the mouse on motion events that should make it relativly easy to check wether it matches or not owen: what really confused me in the output of padraigs test case with my patch was that "trailing" seems to vary more than I would expect I saw it jump from 0 to 5 or from 2 to 0... mclasen: it's I think the number of bytes to the end of the cluster, so 0 => 5 isn't suprising if it is a number of bytes, then isn't calling forward_chars(iter, trailing) wrong ? thats what GtkTextLayout does... Maybe it's number of chars. I forget. 5 is a little long, but not impossible for hindi I'll try to debug this a bit more over the next few days the next bug we need to discuss is 160063 nor Hig UNCO gtk+ GtkTreeV 2.6.0 gtk_list_store_sort_iter_changed() no longer emits rows_r... Dec 06 16:17:59 * jrb returns the problem here is that after the port to GtkSequence, said function no longer emits rows_reordered, but only row_changed even if it is moved to a different position this is a change of behaviour that broke e.g. the icon view on sorted models, and can conceivably break apps which do similar things but adding back the rows_reordered would be rather bad, since it forces the list store to be O(n^2), basically Would it be possible to emit delete/insert instead of row_changed? that would work for the icon view problem. not sure if it breaks row references tracking the row, though ah, yes, I think it does (dnd has the same problem) any other options ? we could add a flag to switch the behaviour... mclasen: I don't think we can change this behavior Is the rows_reordered => O(n^2) fundemental? Nautilus has been "broken" like this for a long time owen: yes, rows_reordered is O(n). There is no way around it How so? owen: well, rows_reordered has to include a full map old positions -> new positions ssp_: that's how we did DnD, and it was suboptimaal Well, O(n) isn't the same as O(n^2) owen: you could try and batch inserts together, of course owen: it is O(n) for each insert, so if you fill in n items, you get O(n^2) Hmmm, well, in the past filling a sorted list store didn't give reasonable performance, does this fix it, or is it just one of many O(n)? owen: I guess the sequence changed most of the n's to log n's owen: It made basically everything that could be O(log n) O(log n) owen: Then someone found basically the same problem with swap(), so that had to be made O(n) ssp_: That doesn't really answer the question :-) -- is filling a sorted list store now O(n log n) ? owen: yes owen: I meant everything that could theoretically be O(log n) became O(log n) we are optimal now... except for swap ... what is swap used for? what jrb pointed out is that we really should have an insert_with_values() which would allow to avoid most of the issue when filling up a sorted model since you currently have to append the iter, then set the values as a separate step, which resorts it owen: it swaps to rows mclasen: I'd much prefer that Does it? If you aren't appending in sorted order, it just chnages the prefactor, right? owen: you get a row_inserted for the listener owen: which means you don't ened to go through the whole level owen: if you insert the item in the right position, you never need to emit rows_reordered jrb: Ah mclasen: we should have that function anyway mclasen: someday, I'll find a spare couple months to write a new TreeModel interface..... jrb:Could we get away with insert_row() giving back some magic iter that didn't change the model unitl you set it? (probably not, inserting blank rows is legitimate :-() owen: we could arrange it so that the magic blank row becomes a regular blank row when you do anything else to the model... could we do the delete/insert only for the case of deleting a blank row at the end, and make blank rows sort at the end? owen: but it is probably easier to add insert_with_values() mclasen: we'll need to make sure we have a language binding friendly version too yes owen: the delete/insert would still break row references owen: I don't know why someone would have a row reference to a just added blank row, but still... mclasen: Why do we need a row reference to an empty row at the end of the store? mclasen: It's not "broken" in the sense of "broken invariants", just in the sense of "can't track the move" owen: you're adding it to modify later? Hmm. crazy idea: what if the array emitted by rows_reordered contained an extra field "behind" the pointer that indicated the first non-identity field? ssp_: How do you generate the array in non-O(n)? Just keep around a prefilled one and modify it? ssp_: would that make the signal emission any more efficient ? owen: yeah mclasen: does the signal emission copy the array currently? ssp_: doesn't seem to (see gtktreemodel.c:rows_reordered_marshal) Just adding an extra field wouldn't be enough though. Moving a row still generates O(n) non-identity entries But adding information "only one row moves: from pos m to n" could possibly work ssp_: that would allow users of the signal to avoid a lot of work, but wouldn't make the signal any faster to send, right ? we could just as well add a new signal, row_moved, and let apps use that in preference to rows_reordered mclasen: right, we still have to actually generate the O(n) entries to be compatible mclasen: While you could check for listeners on rows_reordered, that's rather evil it sucks to have an interface that inefficient by definition... owen: the alternative would be to make apps declare explicitly that they're not interested in rows_reordered That strikes me as unsafe, because an app doesn't really know that *nobody* is interested in rows_reordered g_signal_has_handler_pending() while evil, would be better than that hmm, true mclasen: except that's not what you want owen: if we go for the evil approach, would you add a new row_moved signal to emit instead/in addition to rows_reordered ? mclasen: you want to know when it is reordered, eg, when the sort function changes If we add the evil call, we could also use it to short-circuit expose/size-allocate/size-request Some sort of new signal... not sure if it should just be one-row or any number jrb: so you're saying has_handler_pending() doesn't work either, because there will be listeners even if we don't need the rows_reordered signal from sort_iter_changed() ? mclasen: I'm saying you need the handler. Just not in all cases ssp_: No, it exists. It doesn't tell you class closures though. hmm, so, what is the outcome of this discussion ? 1) we need to readd the rows_reordered() signal in sort_iter_changed() 2) would be good to have some insert_with_values() lookalike with language-binding sugar 3) not clear if we can find a way to avoid the rows_reordered overhead... ok, maybe we should get back to the first issue, now that jrb is back mclasen: concur with the summary. jrb: what about typeahead off by default ? do you agree, or oppose, and why ? mclasen: I think it should be on by default, as people won't turn it on. and if we were doing it from start, we'd have the search on by default the filechooser would turn it on, of course mclasen: however, it has broken slightly some applications thats the main argument for off by default... mclasen: yeah mclasen: iff the TreeView has focus, and the application has a one key mnemonic (such as evo) mclasen: it goes to the typeahead I have concerns about it swallowing key events. (both federico and vektor commented on this) what did they say ? mclasen: that they were surprised. (-; Hopefully they'll wake up and answer in their own words We (SWT/Eclipse) would be happy if we could turn it off with some kind of API call/property. desudation: you already can gtk_tree_view_set_enable_search ? does that influence only typeahead, or also C-f ? Okay. That's good. both do we need a separate flag ? In terms of design, we also find it a bit weird that it is positioned off the bottom right of the widget. It isn't necessarily where the user is working, and our i18n guy is worried about how this will interact with IME positioning. did my mail about enabling typeahead make it to the list? federico: didn't see it hmmm give me a sec desudation: there is a bug about it, from the eclipse team, I think We are also a bit worried that this feature is being backported by some distributions into patched versions of GTK+ 2.4.x mclasen: Yes, we filed a bug about the positioning. mclasen: I'm not sure that we have about the eating of key events. argh, it's in my Drafts folder desudation: note that we added the entry mostly for i18n basically Evolution doesn't like typeahead because it has single-letter commands I don't know how it implements them --- gtktreeview's key_press_event handler looks like if (arrow_key) { ...} jrb: I realize this, and it is a good idea. But, the location of the typeahead seems off somehow.... desudation: I don't think we can do something about the positioning for 2.6 else if (parent_handler_handles (event)) return; else handle_typeahead() but Evolution doesn't derive from the treeview, so I don't know how it manages to catch the keys before the tree does mclasen: What about the eating of key events? Would it be possible for the key events to be forwarded to listeners on the tree/table widget before sending them to the typeahead? jrb: was C-f enabled by default in 2.4 ? mclasen: it's always been on could we make the typeahead entry a) appear over the row that matches, directly above the corresponding renderer; b) make the tree center the row as you type? federico: I think it would be annoying to have the entry covering the selected row federico: it would jump around, no? or do you mean "over" as in "next to it" might be interesting to appear below the last line on lists that aren't full mclasen: some nice kind of "over" :) you could alpha-blend it in the future over the actual row, or whatever jrb: Arguably, the typeahead shouldn't appear if all of the lines can be displayed. mclasen: but in general, make it appear fairly close to the found row jrb: if C-f has always been on, then I would propose to add a separate flag for turning on typeahead, and make it default to off desudation: it scrolls mclasen: no one ever found c-f (why do we need the entry at all? what was the problem with making it invisible?) mclasen: that's why we added typeahead federico: partial inputs jrb: hmm, you have a point jrb: is there a way to know whether the user's language requires that? (technically, you could type that char in any language...) ok, I have some more bugs which I would like to get some input on before I have to leave... here is one: 160271 nor Hig UNCO glib general 2.6.0 g_get_language_names() always returns the same list (side note... do we have gtk_tree_view_set_text_when_empty (tree, "No items")?) the reporter complains that g_get_language_names() always returns the same list of names, and provides a patch to update the returned list if the locale changes is this something we need to handle ? We do handle it for get_encoding()... federico: we don't have that in most places (e.g combo boxes, menus) federico: we only have it in ui manager for empty menus now ok, I will have to break off in a few minutes... My plan for the next releases is to get something out at the beginning of next week I hope we can resolve most of the mustfix issues by then (ie what is on the 2.6 milestone with high prio) If not, we may either do another 2.5.x release and continue fixing for another week, or just add the issues to the release notes and do a 2.6 anyway how does cvs HEAD currently look on win32 ? have the filename encoding issues been completely resolved by now ? ok, have to go. see you next week see you Meeting ended December 6, 17:30 EST (22:30 UTC)