Review Request: State machine architecture for PMC

[Christophe Olinger]

The medialayout mistake was a very small one, I just removed the class
MediaLayout from the mediacenterstate.h, and took the includes for the
medialyout from mediacenterstate.cpp into mediacenterstate.h

Little C++ mistake from my side. Sorry

On Thu, Apr 8, 2010 at 7:30 PM, Alessandro Diaferia
<alediaferia at gmail.com>wrote:

>
>
> 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
>
>
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/plasma-devel/attachments/20100408/b7a437cf/attachment-0001.htm