Summer of Code (March 17,2015)
caolanm at redhat.com
Thu Mar 19 14:06:37 PDT 2015
On Thu, 2015-03-19 at 18:12 +0100, Jan-Marek Glogowski wrote:
> Am 19.03.2015 um 10:20 schrieb Caolán McNamara:
> > On Wed, 2015-03-18 at 21:04 +0200, Efe Gürkan YALAMAN wrote:
> >> Somewhere in the bugzilla I think Caolan mentioned it can be
> >> implemented as a tree-view because the options are in a tree structure
> >> and it would fit better then a simple table. Also it solves the
> >> dialog's usability issues too. I hope that will solve the
> >> accessibility problems too.
> > Yeah, I think that's the best approach, to try and use a tree in there.
> > (a SvTreeList I suppose) because the amount of elements in the list is
> > just crazy, 30,000+ IIRC. Ideally on-demand loaded, e.g. tree is
> > collapsed and just shows +com.sun.star, when you expand that, then only
> > then is the subtree inserted, and so on. So the full 30,000+ list isn't
> > actually in the widget, only the expanded portion.
> Not sure if it would be better - performance wise. I guess most people
> actually want to search and I'm not sure if it's better to rebuild the
> tree with partial data based on the search string.
FWIW, the basctl TreeListBox is an example of what I had in mind, see
the RequestingChildren and so forth there for something similar.
The last time I had a look at the a11y performance there is an insanely
slow a11y-caused iterate-over-the-whole-view to get to the right index
loop triggered by every insert into the model. I attach the experimental
that highlights that hot-spot.
> Is the tree view able to filter the content, like the Gtk+ one allows
> via GtkTreeModelFilter?
I don't think so, well not on a quick look anyway, mostly seems that
SvTreeList is the GtkTreeModel-alike model and SvTreeListBox is the
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1233 bytes
Desc: not available
More information about the LibreOffice