Summer of Code (March 17,2015)

classic Classic list List threaded Threaded
5 messages Options
Jessie Dowding Jessie Dowding
Reply | Threaded
Open this post in threaded view
|

Summer of Code (March 17,2015)

To Whom it May Concern,

I was looking through the project ideas listed on Google Summer of Code and I have a couple of questions:
  1. Refactor god objects:

    1. Could I get some pointers to the god objects and to identifying the largest god objects?

  2. More and better tests:

    1. So you would like the tests written in java to be modified to be written in C++?

    2. What sort of automated tests do you already have? And, what automated tests are there a  need for, right now?

  3. Rework the Expert Configuration dialog:

    1. Are there any current ideas as to how the Expert Configuration Dialog should be reworked?

  4. Review of the modeless dialogs & their moving to sidebar:

    1. The project description showed an example: “the Insert -> Cross-reference…” , what are the exact difficulties with this modeless dialog? And how many more are there that should be moved to a sidebar?

Thank you,


Jessie Dowding



_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Efe Gürkan YALAMAN Efe Gürkan YALAMAN
Reply | Threaded
Open this post in threaded view
|

Re: Summer of Code (March 17,2015)

Hi o/

2015-03-17 19:51 GMT+02:00 Jessie Dowding <[hidden email]>:

  1. Rework the Expert Configuration dialog:

    1. Are there any current ideas as to how the Expert Configuration Dialog should be reworked?


So, currently the problem with the Expert Configuration is the way it is implemented. Right know, It implemented as a direct copy of Mozilla Firefox's about:config page. It is just a table with 4 columns, with about 130,000 entries. When the accessibility tools are open, it tries to create a lot of labels for each entry I think and it makes it really slow. 

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.


Have fun,

--
Efe Gürkan YALAMAN

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Caolán McNamara Caolán McNamara
Reply | Threaded
Open this post in threaded view
|

Re: Summer of Code (March 17,2015)

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.

C.


_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Jan-Marek Glogowski Jan-Marek Glogowski
Reply | Threaded
Open this post in threaded view
|

Re: Summer of Code (March 17,2015)

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.

Is the tree view able to filter the content, like the Gtk+ one allows
via GtkTreeModelFilter?

JMG
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Caolán McNamara Caolán McNamara
Reply | Threaded
Open this post in threaded view
|

Re: Summer of Code (March 17,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
patch of
http://lists.freedesktop.org/archives/libreoffice/2014-January/059081.htmlhttp://lists.freedesktop.org/archives/libreoffice/2014-January/059081.html
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.

C.

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

proto.a11y.expert.config.speedup.patch (1K) Download Attachment