trunk

[Ben Cooksley]

On Thu, Apr 16, 2009 at 8:25 PM, Aaron J. Seigo <aseigo at kde.org> wrote:
> On Tuesday 14 April 2009, Mathias Soeken wrote:
>> SVN commit 953524 by msoeken:
>>
>> This is our proposal for replace System Settings in KDE 4.3. It is a
>> reimplementation based on plugins, so that we provide an Icon Mode (System
>> Settings) and a Classic Tree Mode (kcontrol in KDE3)
>
> cool; really nice to see some movement in this area!
>
> some thoughts/observations while (ab)using it:
>
> * i really like the placement of the buttons on the multiple items pages
>
> * the code does look pretty clean, so that's cool :) it's reasonably fast
>
> * why aren't the big tooltips on by default? :)
I would like some feedback from the Usability people before I do this,
but it is very easy to change.

>
> * it's a bit odd to have a configuration and about entry in the toolbar. could
> those go into the Advanced tab or something along those lines?
The buttons cannot be placed anywhere in the central view ( rules out
the advanced tab ) since that is the area supplied by the individual
views. It needs to be possible for users to change view if they are
having problems with one view.

>
> * if that space is open, then what could happen when you go into a multi-panel
> page is that the search bar could be hidden (it doesn't do anything then that
> the user can see anyways) and the icons of the panels popped up there toolbar
> style; the icons on the left side just feel so .. out of place in that
> application
>
> * there is no quit action, see attached patch
Thanks, this has now been implemented.

>
> * the search needs a keyboard shortcut imho; alt+s?
Sounds fine to me, I have added Ctrl + F as the keyboard shortcut for now.

>
> * it'd be great to see the search not destroy the layout of the icons but just
> fade out the ones that don't match. much less jarring effect; simply greying
> out the icons won't do in this case i think, though ... probably desaturate
> and paint them with a .6 alpha or something ...  that should let the matches
> really stand out nicely, and then you can actually learn where they are so
> next time you might just move your mouse to the right place :)
This probably simply involves altering the items flags, so shouldn't
be too hard to implement. Will also look into this.

>
> * there's some sort of flicker happening when changing into a page of widgets.
> the second attached patch addresses the worst of it, though if you look
> closely you'll see that there's a blank grey area; something's painting when
> it shouldn't still. unfortunately it's 1am here and i don't have the energy to
> look...
Thanks for the patch, I have applied it.

>
> * i too think that if this goes into svn it should be renamed systemsettings
> for continuity
>
> * is the plan to continue to work on this application? system settings
> currently is a bit of an abandonware piece which is unfortunate; it'd be great
> to see active maintainership  on such an important bit of the workspace.
> things that would be terrific to see in later releases would be better support
> for 3rd part non-kcm modules, "related panels" suggestions and other such fun
> stuff.
Yes, I plan to continue development and maintain System Settings. Not
sure how easy it will be to add support to 3rd party non KCM modules
though...

>
> * the term "BaseMode" for the X-KDE-ServiceTypes is a bit generic. consider
> SystemSettings/BaseMode
Changed to SystemSettingsView  which was the name of the desktop file
that was already being installed.

>
> * while streets faster than kcontrol from kde3 and at least as fast as
> systemsettings, startup speed could be improved quite a bit still:
>
>        * while it's purely a perception thing, showing the window immediately,
> hitting the event loop and then (e.g. with a singleShot timer) doing
> initMenuList, preparing the BaseData, loading the plugins and calling
> changePlugin gets the window up an extra ~.3-.5s faster; it's quite
> noticeable.
This has been implemented. Compared to the current System Settings, it
now loads 4 times faster perceptively.

>
>        * all the view plugins are loaded on startup, even though only one is shown
> at a time; each takes anywhere from .2-.6s to create (depending on which one
> it is and the phase of the moon when the app is started) which means that the
> two default views combined are responsible for 30-50% of the start up time of
> the app. perhaps just load the view that will be used, and rely on KSycoca to
> find that one for you even. while doing some basic profiling i noticed that
> the tree view takes quite a bit to put together compared to the icon view, so
> we're losing some .3s at startup for something we never actually see
I will look into some form of a delayed loading mechanism, not
creating the widgets will probably produce the desired effect.

>
>        * why does the icon view even need to be a plugin? this could be built right
> in and provided as a hot path; it would short-circuit the need to load it from
> disk; that looks like a .16s saving right there. personally i don't see any
> compelling reason to have all the views as plugins? heck, compile in both the
> treeview and icon view even .. :)
KControl4 currently uses the KService objects of the plugins to
retrieve information about them ( Configuration dialog ) and allowing
them to store settings ( BaseData ) among other things. It can only be
done if the relevant KService objects can be created.

>
>        * a third of a second is spent creating the widgets in initEvent in IconView,
> most of it in the foreach( MenuProxyModel *proxyModel, d->proxyList ) { loop;
> don't know if much can be done about that, but it's a good candidate for
> delayed loading anyways :)
>
>
> --
> Aaron J. Seigo
> humru othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>
> KDE core developer sponsored by Qt Software
>
>
Thanks for the review Aaron,
Ben Cooksley