[Panel-devel] Yo

[Matt Broadstone]

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

OK that sounds good, so basically we need to add logic to Corona to
understand positions of various Panels and Areas so we can say
loadApplet to x identified area. Regardless of the implementation
details this makes a lot more sense we only handle loading/containing
of items in one place (the scene). Cool.

Perhaps instead of adding items offscene, we can just maintain
available screen geometry within the scene, and in the FullscreenView
subclass we can only display a certain subset of the geometry of the
scene. If we add the panel items in some sort of negative space then
we once again lose the collision detection that you were talking
about.

Matt


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