trunk

Aaron J. Seigo aseigo at kde.org
Thu Apr 16 09:25:40 BST 2009


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? :)

* 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?

* 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

* the search needs a keyboard shortcut imho; alt+s?

* 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 :)

* 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...

* 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.

* the term "BaseMode" for the X-KDE-ServiceTypes is a bit generic. consider 
SystemSettings/BaseMode

* 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.

	* 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

	* 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 .. :)

	* 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: kcontrol4_quit_action.diff
Type: text/x-patch
Size: 600 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090416/9d17b8a1/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kcontrol4_less_flicker.diff
Type: text/x-patch
Size: 631 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090416/9d17b8a1/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090416/9d17b8a1/attachment.sig>


More information about the kde-core-devel mailing list