Experiences with KDE-CVS at LinuxWorldExpo

[Marc Mutz]

On Sunday 10 November 2002 22:30, Havoc Pennington wrote:
<snip>
> FWIW an idea people have had to make this *much* easier is
> "config-aware" widgets, or even better, config-aware widgets that the
> GUI builder understands.

Yepp, Danimo and mine (for the KDE side of this). Danimo went off to 
implement them, but I don't know how far he's come. The task should be 
pretty easy to do: Just make an interface and let each widgets you need 
inherit it (using multiple interitance). Like

class ConfigAware {
public:
	ConfigAware( const QString & group=QString::null,
				const QString & key=QString::null )
	: mGroup( group ), mKey( key ) {}
	virtual ~ConfigAware() {}

	QString configGroup() const { return mGroup; }
	QString configKey() const { return mKey; }

	void setConfigKey( const QString & key ) { mKey = key; }
	void setConfigGroup( const QString & group ) { mGroup = group; }

	virtual void apply() const = 0;
	virtual void setup() = 0;
	virtual void loadDefaults() = 0;
protected:
	QString mKey, mGroup;
};

The problem with this is that you either end up with almost all simple 
widgets coming in a config-aware and a non-config-aware version or 
every app developer has to inherit from most simple widgets if she 
wants config aware widgets. The only solution I have yet come across to 
solve thsi nicely doesn't work for Qt: Make ConfigAware a template 
class that inherits from it's template parameter (mix-in).

mSpin = new ConfigAware<KSpinBox>( this );
mSpin->setGroup( "myGroup" );
mSpin->setKey( "myKey" );

> i.e. you might have a spin button that is tied to a particular config
> key, and automatically handles updating/disabling/etc. when
> appropriate.
>
> Would still not be perfect, you'd have to do things manually
> sometimes, and ideally locked-down stuff might vanish instead of just
> disabling, but would make it a lot easier to handle all the simple
> cases.

Locked down stuff should never vanish automatically, since that makes 
layouting dialogs quite a challenge and more importantly, may hide 
essential information from the user. Eg. in a mail application the 
admin might want to lock down the default identity settings, which the 
user should nevertheless be able to inspect in the normal place of the 
apps' config dialog.

> I think in the end though to make this fly we'll need someone
> actively testing/fixing locked-down setups. I don't think the QA task
> is that much harder in principle than say making sure every label
> that should has a mnemonic/shortcut key on it, it's just another task
> that has to be done, and it's not getting enough testing right now.
<snip>

I'm not aware of _any_ KDE app that tests for immutable config keys and 
uses that information to change something in it's config dialog. I 
might be totally wrong, though, since lxr.kde.org doesn't like being 
queried currently.

Marc

-- 
We do not believe it draws the proper balance in a democratic society
for the activities of government to be concealed from public scrutiny
while the private activities of citizens are made open to government.
       -- EPIC letter to the President of the EU Council of Ministers
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20021111/fc98a3f7/attachment.sig>