Review Request: State machine architecture for PMC

Alessandro Diaferia alediaferia at gmail.com
Thu Apr 8 19:30:19 CEST 2010


2010/4/8 Marco Martin <notmart at gmail.com>

> On Thursday 08 April 2010, Alessandro Diaferia wrote:
> > 2010/4/8 Aaron J. Seigo <aseigo at kde.org>
> >
> > > On April 8, 2010, Christophe Olinger wrote:
> > > > One thing missing is the layout of the actual subComponents in the
> > >
> > > applets.
> > >
> > > > Currently they are just added in a row. For this we need the API. The
> > > > layout should recognize which type of applet arrives and lay it out
> > > > accordingly. That means lots of if/thens within tha applet code. This
> > >
> > > also
> > >
> > > > means adding new states with new subcomponents would mean adding
> > > > if/tehns to the actual addToLayout functions in the applets.
> > >
> > > what i'd recommend is to provide a way to tag subcomponents with values
> > > (e.g.
> > > an enum) that says something about what they do.
> > >
> > > divide up each MainComponent into "zones" (navigation, media playing,
> > > status,
> > > whatever :) and then each sub component can be tagged by the creator of
> > > the sub component (e.g. a state) with what it is.
> > >
> > > then the main components will know which zone they belong in.
> > >
> > > from there, i'd go with a naive implementation, at least at first, that
> > > just
> > > puts things into the respective zones on a first-come-first-placed
> basis.
> >
> > This makes me thinking about the MediaLayout object. Now it resides
> inside
> > the containment implementation.
> > Probably we should have something that specifies wher the subComponent is
> > suggested to be placed; this
> > can likely be:
> > - Fullscreen
> > - AppearingFromLeftEdge
> > - AppearingFromTopEdge
> > - AppearingFromBottomEdge
> > - AppearingFromRightEdge
> > - Invisible
>
> no i don't think those names should depend to appearance, but rather be
> more
> semantic, like mediabrowsing, control, informations, playing
>

Ok agreed, and then the layout will decide accordingly to the type rather
than the appearance.


> in the future i can see applets that register themselves as one of those so
> the central layout would know what to allow for each category, either for
> which forst come or for what the user configured, if he wants to use a
> different browser for instance (they could change for different formfactors
> perhaps), but that still has not so much point.
>

Yeah. Currently the containment doesn't allow more than one applet of the
same type to be present at the same time.
But which particular applet is still not decided by the containment and this
is how it should be.


>
> Cheers,
> Marco Martin
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>



-- 
Alessandro Diaferia
KDE Developer
KDE e.V. member
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/plasma-devel/attachments/20100408/4d4ae816/attachment.htm 


More information about the Plasma-devel mailing list