[Panel-devel] Plasma and Amarok

Tue Jul 17 11:17:52 CEST 2007

On 7/17/07, Aaron J. Seigo <aseigo at kde.org> wrote:
>
> 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...

ah... thats interesting. i'll wait and see what comes out of the work
on saving/restoring
sessions.

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...

yeah, i had kind of ignored that issue.

> > 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.

ok, i attach the new patch. a few things: first of all, i did things
the "first way" that you talked about, using a global prefix variable
with getters/setters, instead of a global KTrader namespace with more
constraints. the reason is this: in order to add more constraints we
would need to add more getters
and setters to each individual class that needs them, because we can't
re-implement functions that call data in the dptrs. this is
nevertheless probably a good
thing to discuss in the future and can be resolved with some coordination.
for now, though, this should work.

also, i first had a static variable with the serviceType in the Applet
class (as well as DataEngineManager) but that wouldn't work because if
the client app chooses to change
the prefix, the variable would still have the old value. what was
happening was the value was being initialized before the prefix setter
was called. this way, it looks up
the prefix on every query.... which might not be ideal performance
wise, but i'm not sure of any other simple way to do it.

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 =)

IRC isn't ideal for me either (at least for a while) as i'm still on
vacation in europe and on dialup, so am rarely online. lets keep to
email :)

cheers,
leo

> --
> 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
>
> _______________________________________________
> Amarok-devel mailing list
> Amarok-devel at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel
>
>
>

-- 
______________________________________________________
Leo Franchi                    angel666 at myrealbox.com
4305 Charlemagne Ct         lfranchi at gmail.com
Austin                                 cell: (650) 704 3680
TX, USA                              home: (650) 329 0125
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/amarok-devel/attachments/20070717/db27bf59/attachment-0002.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: plasma.patch
Type: application/octet-stream
Size: 8811 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/amarok-devel/attachments/20070717/db27bf59/attachment-0002.obj 
-------------- next part --------------
_______________________________________________
Panel-devel mailing list
Panel-devel at kde.org
https://mail.kde.org/mailman/listinfo/panel-devel