Summer of Code (March 17,2015)

Caolán McNamara caolanm at
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, 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
patch of
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
GtkTreeView-alike view.

-------------- next part --------------
A non-text attachment was scrubbed...
Type: text/x-patch
Size: 1233 bytes
Desc: not available
URL: <>

More information about the LibreOffice mailing list