kdelibs/kdeui

[Thomas Zander]

On Sat, Jun 22, 2002 at 06:01:54PM +0200, Matthias Kretz wrote:
> On Saturday 22 June 2002 17:06, Thomas Zander wrote:
> > Simon has a good point, I don't think this is a good idea from a usability
> > POV, since this makes lazy loading of config modules a lot easier, which
> > then makes for an inconsistent GUI.
> 
> What do you mean with lazy loading? Loading by accident?
I mean the initializing of the config-dialog based on the loading of the
external program.
In the case of plugins and more even for kparts I can see that at program-
start not all parts/plugins are loaded. The config modules will then only
become visible after the specific part has been loaded.

> The way I'm doing it 
> for my KView plugins is:
> (void)new KViewPluginnameConfModule( this );
> And that works just great, because when the plugin is deleted the module 
> disappears automatically (thanks to QObject).

But that is just my problem with regards to the usability.  How is the user
going to be able to see that configuring a XML markup plugin for Kate (I'm just
making that up, no idea if there is one :) is only possible when the user has
opened a file that forced the loading of the plugin.
In other words; the presense of an option or the config-module should not be
based on what has been done in the past in the applications life.


> > Plus that is makes the design of the dialogs a lot harder since the naming
> > can 'conflict'. Two parts that configure 'general' seems a bit stupid...
> 
> With design you're only talking about overlapping naming of modules? Hmm, what 
> about the way Kate does it? Using a KDialogBase::TreeList and creating 
> entries for the application and every part. Modules are then inserted as 
> subentries.
> 
> OK, if you think it's bad using the Singleton Pattern I'd like to hear an 
> alternative. Currently I can't imagine anything better than what I wrote ;-)

Well, your solution is based on the idea that one dialog will show all the config
modules.  Therefor I don't see an easy solution.  To go back to the KWord/KSpread
issue (i.e. kparts) each would have its own menu-entry, and thus its own configuration
dialog.  This can be done based on a singleton with a key (the application name).

Plugin-configs that are only visible when loaded is not nice, but I don't see a
solution based on what I understand your class does.  The loading of the config
module could be seperate from the loading of the plugin itself, or something.
My knowledge on the structure there is limited, so I leave you with my thoughts
to 'do the right thing' :)

Thanx.

-- 
Thomas Zander                                           zander at planescape.com
                                                 We are what we pretend to be
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20020622/15204ae7/attachment.sig>