trunk

Aaron J. Seigo aseigo at kde.org
Thu Apr 16 21:27:52 BST 2009


On Thursday 16 April 2009, Ben Cooksley wrote:
> On Thu, Apr 16, 2009 at 8:25 PM, Aaron J. Seigo <aseigo at kde.org> wrote:
> > * 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.

well, to put it another way: 

is it really so important to be able to configure which view is being used 
that the configuration app needs a configure button in its toolbar area?

could it not be just another settings panel in the listing? or are the views 
_so hard to use_ that we're afraid the user will not be able to find it? if 
that's the case, then we have much, much bigger problems at hand. however, i 
don't think that is the case at all.

we can do better things with that real estate ...

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

shouldn't be too hard i'd imagine with a new ServiceType category:

m_externalModules(KServiceTypeTrader::self()-
>query("SystemSettingsExternalMOdule") );

or something less verbose perhaps ;)

then when launching it, KRun the .desktop file, which should use the Exec= 
line. voia. :)

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

perfect :)

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

woo-hoo!! :)

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

yeah, most likely.. that's where the bulk of the time was spent in the 
profiling i did..

-- 
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: 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/a47f964b/attachment.sig>


More information about the kde-core-devel mailing list