On Fri, Apr 2, 2010 at 5:54 PM, Shantanu Tushar Jha <jhahon...@gmail.com> wrote:
>>
>> Shan proposed to have states for each applet. I my mind this means that a
>> plugin would need to write states for all applets, so actually similar to
>> the above, except that the instructions are closer to the applets and
>> seperated in individual state objects. Sounds more complicated to extend in
>> my head.
>
> Hehe, just because I like simplicity doesn't mean I'm always right. I
> noted Marco's comment that even this doesn't solve the problem. /me
> thinks, If I get an idea, I'll post.

uhm, let's see: what about
qstates built and selected not from an enum but from strings.
the plugin says
my state is called foo.
for the player control applet i want those features (an or of stuff
like play, net,progress etc)
for the browser applet i want this..
and maybe i want also my own applet positioned here

the loader builds the proper states from that, knowing what each
plugin wants to enable/disable
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Reply via email to