Plasma Media Center and state machines

[Shantanu Tushar Jha]

On 4/4/10, Alessandro Diaferia <alediaferia at gmail.com> wrote:
> 2010/4/3 Aaron J. Seigo <aseigo at kde.org>
>
>> 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).
>>
>
>
> Probably I've never said it clearly but i think that we *should* use plugins
> for the PMC states.
> The thing is, exactly, defining a way to make shared components accessible
> by everyone and sub-components
> exported to the PMC. I don't think this is too difficult to do and, anyway,
> we can just decide a day for a meeting on IRC
> in order to put down some ideas about a possible API for MCStates plugins.

What about this Sunday? I think everybody is free at that time.

>
>
>> 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).
>>
>
> This part is a bit convoluted. We currently have an API for MCApplets
> themself. The particular implementation
> of the MediaBrowser Applet has, itself, its own plugin system that makes it
> possible to write plugins to show different kind
> of media types providing a QAbstractItemModel. The way data is fetched is
> completely transparent to the Applet but it is
> suggested to make use of the DataEngines PMC already provides. Such
> DataEngines are there and they're Video DataEngine and
> Picture DataEngine (both written together with the Silk team). Both are
> extensible themself through plugins. They're supposed to work as data source
> for MediaBrowser models.
>
> The playlist stuff, together with the ability to make the general state able
> to control the playback is another matter we need to talk deeper about.
> We have, again, an API that defines how Playlist Applet should be
> implemented, and, of course, we have the PMC implementation. This
> implementation makes
> use of the Playlist dataengine that was meant to be a shared component for
> every multimedia-application within KDE.
> This way an Amarok user could fill-in his playlists and find them there when
> he launches his PMC. And vice-versa of course.
>
> The playback is then controlled by the MediaPlayer Applet and the
> MediaController which, again, are the implementations of a public API too.
>
> I, originally, was working on a thing similar to a Phonon::MediaObject
> wrapper that would have allowed us to expose the playback to the whole PMC
> components.
> Later, together with Marco, we decided to abandon that in order to just put
> the playback control inside the API.
>
> Do you think it is the case to resume that work and make it available to the
> states implementations?
>
>>
>> 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.
>>
>
> Agreed and this is related to what i wrote above.
>
>
>>
>> --
>> 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
>>
>
> Regards
>
> --
> Alessandro Diaferia
> KDE Developer
> KDE e.V. member
>


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