playground plasmoid redux

[Jason Stubbs]

I missed this mail. Mixed feelings about gmail's interface.

2008/10/10 Aaron J. Seigo <aseigo at kde.org>:
> On Saturday 04 October 2008, Jason Stubbs wrote:
>> Aaron J. Seigo wrote:
>> > On Friday 03 October 2008, Rob Scheepmaker wrote:
>> >> On Thursday 02 October 2008 22:08:41 Aaron J. Seigo wrote:
>> >>> systray-refactor - needs the plasmoid protocol finished out, but
>> >>> generally there. (notifications?)
>> >>>   kuiserver - should be added to the systemtray?
>> >>
>> >> Or maybe just keep as a seperate plasmoid which can of course be used
>> >> through the systray's plasmoid protocal.
>>
>> This would mean that kuiserver's extender would be different to
>> systray's thus negating the purpose of integrating the two.
>>
>> >> Because as opposed to the
>> >> notifications applet, the kuiserver applet really needs an icon to
>> >> open/close the popup. Transfers often take a while, and you don't want
>> >> to have the popup open all the time while a transfer of multiple hours
>> >> is running, while you do want to open it sometimes to take a look at how
>> >> for the transfer is.
>>
>> I hadn't considered this.
>>
>> > the KUIServer protocol in systray-refactor could create the icon, which
>> > the systray would then add
>>
>> This is definitely a possibility, but I'm not sure it's really possible
>> to accomplish by October 19th. Assuming that the icon would show/hide
>> the extender, there are issues such as the interaction between the
>> kuiserver hide/show and knotify notifications, or how an icon adding
>> through the Task protocol can even get access to the extender.
>
> the attached patch addresses this issue. (along with a couple of other minor
> items, like removing the direct use of the Manager from the TaskArea class)

-    QGraphicsWidget* widget();
+    QGraphicsWidget* widget(Plasma::Applet *host);

^^^ is the most important part of the patch, I take it? Yeah, that
works. My main concern is/was that strong dependencies would start
popping up between the parts. The above change allows the entire U/I
to be rewritten from scratch without any changes to core/ or
protocols/ so I'm happy. :)

> i also realized while writing the patch that the plasmoid protocol has a fatal
> flaw: it creates one widget per task, but the tasks are global (shared between
> all instances of the tray). part of the solution here is to actually implement
> configuration management which we can do more easily once we have access to the
> applet object in question, which this patch brings us one step closer to.

I still haven't looked closely at the plasmoid protocol, but this
likely comes from the fact that it was derived from the FDO protocol,
which of course cannot have more than one widget per task.

> (it also doesn't allow more than one of the same applet, but that's another
> matter =)

I didn't notice this, but if you are referring to typeId being used as
the "unique" key, FDO has exactly the same problem.

>>>>>
WM_CLASS
WM_CLASS, STRING

 This hint should be set as it would be for a normal toplevel window,
as defined in the ICCCM. The system tray can use it to distinguish
different kinds of tray icon. This is useful for example if the system
tray wants to save and restore the positions of the icons in the tray.
>>>>>

FDO's typeId is based on this and so is of course not unique. I'm not
sure it's possible to have any protocol provided unique id.

> i think we will need to pass in a KConfigGroup to Protocol::init, and not
> create the protocols when the manager is created but have an init on the
> Manager class as well.

I don't see exactly where you're going, yet. Looking at your patch,
though, it looks like you're way ahead of me and going in the right
direction. :)

> most of the awkwardness in systray-refactor comes from parts of it being
> written as if it were a 3rd party library to be re-used elsewhere when that
> really isn't the case. a bit more coupling in the right places between the
> core/ and ui/ classes will make things a lot easier.

Actually, my intention was/is to split out everything other than ui/
into a separate library. Not much has been done with the systray and
friends in KDE4, I think mostly because the code is very hard to
approach. Moving the internals to a separate library would allow for
more U/I experiments. If it could be made a data engine, even better.

> which is all to say that the barrier to adding something like the KUIServer
> stuff to this is absolutely solvable, is completely orthogonal to any other
> stabilization work that would be left to do and that i'm willing to put the
> work in to make it happen over the next 5 weeks.

Can't argue with that! ;)

Seriously though, my only real concern is that I don't have time to do
it myself due to work and that I'll be busy moving back to Australia
(finally! yay!) during the RC period through the first couple of weeks
after release. I, personally, don't want to do much more than spend
the next 2 months making sure that the fdo protocol is working the
best it can be (or at least the best i can make it. :)

Just don't be surprised if you find me replying to a lot of commits. ;)

--
Jason Stubbs