plasma application policies

[Marco Martin]

On Tuesday 28 July 2009, Aaron J. Seigo wrote:
> hi all ...
>
> while looking at https://bugs.kde.org/show_bug.cgi?id=201663 i found that
> the problem is that setHasConfigurationInterface (potentially useful
> information) turns off the config option even though Applet provides global
> short settings.
>
> i've "fixed" it locally so that the applet setting has config interface
> doesn't change that at all.
>
> <braindump>
>
> however, there are two situations where this is going to completely fall
> apart:
>
> * usage outside of a global desktop shell app like plasma-desktop (e.g.
> amarok)
>
> * a script engine or other applet that provides it's own configuration
> interface from scratch (e.g. google gadgets (used to?) and the current icon
> plasmoid (silly thing ;))
>
> in the first case of application usage, it would be really useful to be
> able to set some policies. i tend to view Corona as the "QApplication" of a
> plasma instance, so whatever ends up happening this should probably go 
into
> Corona. or maybe just some static methods in the Plasma namespace 
directly?
> (the difference is that if it's in Corona, then an app can have different
> coronas that behave differently and then this code would end up in the
> appication in the same place as other Corona-driven customizations)
>
> i'm thinking of adding the ability to set some "Plasma::Attributes" to turn
> on/off things like shortcuts. the API would be simple and modelled after
> the QWidget::setAttribute API.

attributes that must be set on the applets?
i was also thinking about something that is returned by corona, like
an applet to see whether it has a configuration dialog can do

if (hasConfigurationInterface() ||  (corona()->requiredCapabilities() & 
ShortcutConfiguration))

>
>
> the individual applet case is a bit odder, but i really think that
> overriding showConfigurationInterface in an applet is Wrong(tm) and should
> be considered an implementation bug.
>
>
> the script engine situation is probably the easiest of the bunch: just add
> a method to the script engine that states what it does with configuration
> (e.g. setProvidesCustomizedConfiguration(bool)) and query that when
> deciding what to do with the configuration action.
>
>
> thoughts?


-- 
Marco Martin