trunk

[Ben Cooksley]

On 4/17/09, Aaron J. Seigo <aseigo at kde.org> wrote:
> 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?
No
>
> 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.
It isn't the problem of the user not finding it, I don't want to leave
a user stranded because of a duff module. The only way out of this
situation if the configuration was another item in the listing would
be to manually edit the configuration file and insert an internal name
( icon_mode and classic_mode I think.... )

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

>
>> > * 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 ;)
Seems like an idea. I will probably implement that for 4.4.

>
> 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..
This has now been implemented, although a small amount of widget
initialization must still occur so that the control center can connect
to the views ModuleView.

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

Cheers,
Ben Cooksley.