Plasma Media Center and state machines

[Shantanu Tushar Jha]

On 4/4/10, Aaron J. Seigo <aseigo at kde.org> wrote:
> On April 1, 2010, Shantanu Tushar Jha wrote:
>> Hi Christophe, now I'm able to understand most of what you've
>> proposed. Somehow, I don't like having just one state machine for the
>> whole MC, the main reason being that we're going to support
>> extensibility through custom plugins, so the MC can no longer assume
>> that it knows exactly how many states are present.
>
> there are two different things here:
>
> * how the states are created / registered
>
> * how the states interact with the user interface
>
> they are separate issues: regardless of how they interact with the UI, they
> can be created statically using a hard coded list of "new ThisState; new
> ThatState;" type calls, by iterating over a static set of enums or
> completely
> through plugins.
>
> the key here is that each top level mode (e.g. each item that appears on the
> home page) will be a top level state.
>
> that means that "the MC can no longer assume it knows exactly how many
> states
> are present" is completely and wholy irrelevant to the topic of "should we
> use
> a state machine".
>
> where "we want plugins" does matter is when it comes to "how do they
> interact
> with the user interface".
>
> let's try to lay down some axioms so we can discuss this fruifully:
>
> * there will be a shared home page
>
> * there will be a set of shared / common components available, such as the
> playlist, media browser and control bar
>
> * there will be some set of shared / common sub-components, such as a global
> pause button in the control bar
>
> * a state may also need to provide custom sub-components
>
> * a state may also want to provide a custom component for the main viewing
> area (e.g. a full screen plasmoid for weather, or a special browsing widget)
>
> if we can agree on those points, then we can ask: how can plugins work?
>
> well, it becomes evident that we should provide a way to define which common
> components and sub-components are useful in a given context from a state.
>
> we also need to allow states to register custom sub-components and provide a
> "main viewing area" component as well. (additional components that live on
> screen edges, augment the home page, etc. can be something we think about
> later once we have something releasable in hand today).
>

Exactly. Right now the Media Browser supports writing custom plugins.
So, if we extend that so that the whole Media Center supports plugin,
I think we can have a great system.
As you said, the plugin can specify what media to show, what player to
use, what controls it supports etc.
So, it will be like we'll have plugins and load them using Traders, right?

Right now, I'm fixing up the media player's playlist problem, will put
the patch on reviewboard when done.
Chris, regarding the Files browser existing right now, Aaron and Marco
said that to make it better visible on all devices, we can make it
show 3 columns at once (so to make the icons resizable, and later
maybe allow the user to zoom in/out), I tried but there is a small
problem somewhere, so I'd like if you can help with this. Is it fine?
If yes, I'll reply back with the patch :)

Cheers,

> a state should be able to enumerate child states as well. this will allow
> the
> home page entries to list all the things you can do, for instance, with
> "Photos" (browse, slideshow, add, whatever) if we so wish (see how the PS3,
> XBox 360 or moovida displays sub-menus on main entries)
>
> a state will need to be able to interact with the shared components as well,
> e.g. add an entry to the playlist.
>
> so this means we need to define some concrete APIs for playlist interaction,
> media browser population (both of categories and entries).
>
> note that all of the above is true regardless of whether we use a state
> machine to drive the whole thing or not.
>
> what the state machine gets us is a way to do the above in a modular fashion
> without writing all of the state machine boilerplate ourselves. if we really
> want (and if it is more undertandable for everyone involved) we could just
> as
> easily write the plugins in a more "traditional" fashion. we'll still end up
> with a state machine for all intents and purposes because the modes are
> mutually exclusive and full screen.
>
> the only exception to all of this is the playing of individual media. that
> is
> yet another topic, however. the above is all about the navigation and
> control
> UI which must work together seemlessly (visually and interation wise). how a
> mode (plugin or not) provides media playing is another matter (and
> personally
> i'm leaning towards providing a shared mechanism for that which is in PMC
> itself, so a state / plugin can just say "start playing this video" or
> "start
> playing this set of images"), just as the media browser should provide.
>
> --
> Aaron J. Seigo
> humru othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>
> KDE core developer sponsored by Qt Development Frameworks
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>


-- 
Shantanu Tushar    (UTC +0530)
http://www.shantanutushar.com