[Panel-devel] Yo

[Aaron J. Seigo]

moving to panel-devel where this really belongs, including lots of context so 
everyone can catch up =)

On Sunday 08 July 2007, you wrote:
> On 7/6/07, Aaron J. Seigo <aseigo at kde.org> wrote:
> > On Friday 06 July 2007, you wrote:
> > > tried to get in touch with you on irc, but you've been gone :)
> > >
> > > Anyway, I was playing around with making a panel and have basically
> > > come to the realization that we need to make these changes:
> > >  Corona -> Container
> > >  CoronaView -> Corona
> > >
> > > Basically the idea behind this is that panels are going to be
> > > containers, which is pretty much what our current "Corona" is now. Not
> > > to mention the fact that a Corona is supposed to be a visible layer
> > > (if I'm not mistaken) and so the CoronaView doesn't make too much
> > > sense phonetically. Anyway, let me know what you think. Either way, I
> > > think a Panel is going to have to be more like an extension, rather
> > > than an applet - it's going to have to do some stuff that I think we
> > > don't want Applets to be able to do.
> >
> > panels were never meant to be applets. they were always intended to be
> > containers. corona is exactly what it should be, as is coronaview. in
> > particular, coronaview is a full screen view of a portion of the
> > corona/qgraphicsscene.
> >
> > the panels should probably be simple qgraphicsviews of their own (not
> > coronaviews; need different background painting, etc). whether or not
> > they have their own corona is an interesting question, however.
> >
> > i'm quite interested in seeing if this can work: make panels QGVs that
> > view areas of the main Corona which are "off screen" for the desktop
> > CoronaView(s). this would give us just one scene to work with, and the
> > panels, desktop and other layers simply become different views of the
> > same scene. thoughts?
>
> OK, that makes a lot of sense then. Regarding whether we use a
> different QGraphicsScene or not - I think for the time being they
> should be separate scene's.  Having them simple "off screen" makes it
> harder for us as presumably, we'd have to keep moving them as the
> desktop gets bigger, etc?

that's really the only complication, and we may be able to work around it by 
putting panels at negative coordinates? i haven't tried that yet, so don't 
know how that would work, if at all. in any case it's a minor inconvenience, 
compared with what we win:

- dead simple movement between panels, screens, etc.. as we just move the 
item's pos() in the scene
- a single save/load pass rather than one per-panel, screen, etc as currently 
in kicker
- lower overhead due to fewer objects around in memory

> Plus the best way  to implement this 
> universal graphics scene idea, IMO, is to create some sort of
> QGraphicsProxyScene class (like QSortFilterProxy for models) to be
> used at the corona's for different scenes.

a corona is a scene =)
and while a proxy type class might be possible, it would also make a lot of 
other things, like collision detection, an amazingly difficult thing to get 
working properly in all cases. 

> Anyway, small steps. What I 
> _do_ think is a big deal for right now is encapsulating the idea of a
> container. The Panel class is going to have to be able to add
> Plasmoids and SuperKarambas like the Corona can, despite the fact that
> they need different background drawing (I'm not sure this is true
> even.. if we make a capable background renderer).

this is another thing i like about keeping the scene in Corona and the desktop 
in CoronaView, with a third class for panels that also subclasses 
QGraphicsView: we don't reimplement -anything- between desktop and 
panels -except- for background drawing, which is part of QGraphicsView. iow, 
perfect!

CoronaView should then be renamed to FullScreenView or some such and the new 
panel class could be PanelView, both subclassing QGraphicsView and both 
showing areas of a Corona. preferably the same one.

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

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- 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/panel-devel/attachments/20070716/5c55569c/attachment.pgp