[Panel-devel] Plasma and Amarok

[Aaron J. Seigo]

On Monday 16 July 2007, Leo Franchi wrote:
> On 7/16/07, Aaron J. Seigo <aseigo at kde.org> wrote:
> > shoot anyone if there a few extra spaces here and there, but it would be
> > nice
> > to follow things as closely as possible.
>
> sorry about that. i tried to figure out if there was a consistent
> coding convention (especially for spaces inside parenthesis) but it
> seemed like it was pretty even between
> spaces-between-parens and no spaces. as Amarok code uses spaces, that

it's mostly my fault. we started with the same style i used in kicker, then 
moved to the kdelibs style when it arrived, and then i realized that the 
kdelibs style does not do spaces within ()s. so... yeah. we went through one 
major and one minor revolution already. mix in some deviations here and there 
from various committers that innevitably slip in and i can see how it would 
be easy to get mistaken here.

> > - why do you need the list of loaded applets from Corona
> > (loadedApplets())?
> > (not saying it's not valid, just wondering what the use case is)
>
> this is so there is a way to clear the corona. as applets are started
> by the user, currently from the controlbox, the contextscene (corona
> subclass) needs to know what is on
> the corona itself so it can a) save the state b) clear it c) set next
> state. as the user plays a track, for example, the corona should clear
> the "home" state and display context-
> relative information. this is all done in the subclassed ContextScene, but
> as the applet list is in the dptr, it needs access to it.

ah! ok.. this makes things much clearer. i was just about to add a 
clearApplets() method to Corona, but figured i might end up causing you some 
conflicts doing that.. so i'll add it after you commit your patch, unless you 
add it to your patch. that should take care of one of the use cases..

the other one, switching layouts, is very interesting. Alexis has just started 
working on saving/restoring applet locations and one of the eventual goals 
has always been to allow one to save/restore layouts at runtime by passing in 
a different configuration. so perhaps you may not need access to the applets 
themselves directly ... i'm ok with keeping the loadedApplets() method there 
(it might be useful for someone and can get you guys going in the meantime) 
but i'm glad i know the use case you have now so we can work towards 
supporting that sooner...

i also assume that context menus will become an issue. 
Corona::contextMenuEvent will be problematic for amarok, i assume. in fact, 
it's already going to be an issue for plasma with panels. i'll look into a 
solution for that here...

> > for the time being until someone comes up with a good reason for why they
> > need their own svg theme but not applets, or vice versa
>
> ok, i don't really know much about krunner so i had no idea of the
> repercussions of that change :)

that's why we do peer review =)

> tomorrow i'll fix up the patch and look to doing things how you have
> suggested.

great =) i'm sure we'll get your patch in within the next day or so.

p.s. i see in the commit digest the amarok peeps were trying to get a hold of 
me. irc isn't the most reliable mode for me these days, but email tends to 
work just fine =)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/amarok-devel/attachments/20070716/2cf20581/attachment.pgp