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
shouldn't be too hard i'd imagine with a new ServiceType category:
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.
> > * 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.
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...
Size: 197 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel