trunk

[Ben Cooksley]

On 4/17/09, Aaron J. Seigo <aseigo at kde.org> wrote:
> On Thursday 16 April 2009, Ben Cooksley wrote:
>> 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.
>
> i see .. well, there are a few kinds of possible causes of failure that i
> can
> think of:
>
> a) a view plugin that doesn't list that entry; that would not be the ones we
> ship and would obviously be a bug. i don't see many view plugins appearing
> in
> the future, so i doubt quality control of this sort is an issue worth
> compromising the UI for
>
> b) the .desktop file for the configuration panel is missing or broken, but
> that would be a broken installation like any missing dependency
>
> c) no plugins load successfully -> well, not much can be done about that
> even
> with a configure button
True, it currently informs the user that no views are available if
they try to access the configuration when none are available.

>
> d) the plugin loaded actually crashes; but then not having a configure
> button
> will only matter if the crash occurs when opening the configure panel. a
> crash
> at start or module load == fail no matter where the config button is
Unless it is the way the view is written that causes the crash.

>
> d) ..?
>
> are there others? none of these seem at all to be normal cases, and using
> the
> UI space for the common case would seem to make more sense?
Yes.

>
> if the plugin itself doesn't load (doesn't exist, , that's something easily
> caught and dealt with by falling back to a different plugin. so no big deal
> (just a few hundred wasted ms) ...
This is already done. it falls back to the first available plugin if
it can't find the one mentioned in the config file.

>
> the possibility that a third party module might not show any/all modules
> certainly exists, but seems so amazingly remote .... then again, it may be
> the
> _intention_ of this module to do exactly that for reasons of vendor
> customization.
>
>> >> 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.
>
> very nice :) it now starts very quickly indeed ...
>
> btw, why is Quit in the toolbar?
Oops, that has been removed.

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

I asked on #kde-usability and seele agreed that the toolbar wasn't the
best place to access the configuration through, but was better than an
independent module in the listing, and recommended that it remained in
the toolbar until a better solution could be found. I can't think of
anywhere else though...

The only solution I could think of was adding a drop down menus ( like
the KGet button in Konqueror ) on the toolbar, with About, Configure,
Report Bug, etc. This would fix the problem.

Ben Cooksley