contextview themeing: plasmification?

Sat Jul 7 17:33:22 CEST 2007

note to all: my amarok was unusably slow, which was a reason for my desire
to change,  but it runs WAAY faster in a native kde4 environment (nested
Xephyr) rather than in kde3 as i was testing. so, the speed issue is more
moot than i thought.

leo

p.s. if you're not running it in a full kde4 environment, i suggest you try,
plasma + amarok +everything else is much much faster

On 7/7/07, Leo Franchi <lfranchi at gmail.com> wrote:
>
>
> On 7/7/07, Nikolaj Hald Nielsen <nhnfreespirit at gmail.com> wrote:
> >
> > Other attendes at aKademy spent a lot more time time looking into
> > plasma than me, but I will give you my thoughts on the issue.
> >
> > I like the general idea, but as I mentioned to the other devs at
> > aKademy, I think we need to start seriously narrowing the scope of
> > features we will try to implement for Amarok 2.0 in order to have at
> > least a usable beta by the time KDE 4.0 ships. This particular feature
> > does sound like it could eat up a LOT of time.
>
>
> i definitely understand this concern. we need to have a working amarok relatively soon, at least in time for
> KDE4.0. but IMHO if,
>
> after we put all of this work into the CV, it is still dog-slow and unusable, then we'll just have wasted a lot of time. also, this architecture
> doesn't need to be *that* complicated. when i said it would take a while i means a few weeks maximum, not months :) i mean, most of the
>
> code exists already in plasma, i would need to port and adapt it.
>
>
> Also, and maybe more significantly, there are ideas floating around to
> > make the plasma canvas "embeddable" in applications in a future
> > release of KDE. This would mean not only theming support, but also the
> > ability to drag the context items to the desktop or wherever
>
>
> this is definitely a very interesting concept. problem i see with this is that its still an "idea floating around". and "future release of KDE" also does not sound
>
>
> like something we can rely upon. either way, we need something to rely on that makes amarok2 awesome and that is usable. pinning our hopes on a
> yet-to-materialize feature of KDE does not seems like the best way to approach this. furthermore, if this feature does ever come to exist,
> then we would
> of course refactor to support it.
>
>
> - Nikolaj
> >
> > On 7/7/07, Leo Franchi <lfranchi at gmail.com> wrote:
> > > hey everyone-
> > >     so as leinir mentioned to me yesterday, the guys over at akademy
> > were
> > > discussing the problem of themeing in the context view, and  a
> > solution that
> > > was similar to the plasma theme engine came up. now, everyone at
> > akademy a)
> > > knows more about how plasma works internally than i do (even after a
> > few
> > > hours of grokking the code) b) has already thrown this idea around. i
> > just
> > > want to open it up to everyone else and see what people think.
> > >
> > > basically, how it works is plasma renders SVG pixmaps onto the
> > QGraphicsView
> > > desktop. it works something like this: 1) widget loads the svg widget
> > theme
> > > 2) when time comes to display data, the widget paints the data
> > "through" the
> > > SVG-- it takes care of the layout. 3) rendered pixmap is put onto
> > desktop.
> > > this is very good for many reasons, including resolution independence,
> > but
> > > most importantly, artists can provide theme packages of SVGs that
> > completely
> > > control the layout of the widgets. this would fit exactly with our
> > needs.
> > > also, it does caching of the SVGs so apparently its quite efficient.
> > >
> > > the con  that i can see right now is this: it's quite significantly
> > more
> > > complicated than the current system. not that that is necessarily bad,
> > but
> > > its just going to take longer to implement/perfect.
> > >
> > > also, plasma is fast :) and right now amarok2 is really slow.
> > especially
> > > (but not only) the contextview. so if this helps, i'm all for it. i'm
> > also
> > > willing to code this up, but basically want to gauge your guys'
> > reactions:
> > > do you think it's a good idea? comments? problems?
> > >
> > > leo
> > >
> > > --
> > > ______________________________________________________
> > > Leo Franchi                    angel666 at myrealbox.com
> > > 665 Channing Ave         lfranchi at gmail.com
> > > Palo Alto                        cell: (650) 704 3680
> > > CA, USA                        home: (650) 329 0125
> > > Junior,
> > > Palo Alto High School,   http://euthydemus.homelinux.net
> > > 65 Embarcadero Road,
> > > Palo Alto,
> > > CA, USA
> > >
> > > GPG Key Fingerprint: 713F 1C92 11E3 4696 D067  B681 72D5 EAF0 1499
> > 8B03
> > > Key ID: 14998B03
> > > Public key: http://euthydemus.homelinux.net/pub_key.txt
> > >
> > > _______________________________________________
> > > Amarok-devel mailing list
> > > Amarok-devel at kde.org
> > > https://mail.kde.org/mailman/listinfo/amarok-devel
> > >
> > >
> > _______________________________________________
> > 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

-- 
______________________________________________________
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/20070707/3c820f26/attachment.html 