<br><br><div class="gmail_quote">2010/4/3 Aaron J. Seigo <span dir="ltr"><<a href="mailto:aseigo@kde.org">aseigo@kde.org</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On April 1, 2010, Shantanu Tushar Jha wrote:<br>
> Hi Christophe, now I'm able to understand most of what you've<br>
> proposed. Somehow, I don't like having just one state machine for the<br>
> whole MC, the main reason being that we're going to support<br>
> extensibility through custom plugins, so the MC can no longer assume<br>
> that it knows exactly how many states are present.<br>
<br>
</div>there are two different things here:<br>
<br>
* how the states are created / registered<br>
<br>
* how the states interact with the user interface<br>
<br>
they are separate issues: regardless of how they interact with the UI, they<br>
can be created statically using a hard coded list of "new ThisState; new<br>
ThatState;" type calls, by iterating over a static set of enums or completely<br>
through plugins.<br>
<br>
the key here is that each top level mode (e.g. each item that appears on the<br>
home page) will be a top level state.<br>
<br>
that means that "the MC can no longer assume it knows exactly how many states<br>
are present" is completely and wholy irrelevant to the topic of "should we use<br>
a state machine".<br>
<br>
where "we want plugins" does matter is when it comes to "how do they interact<br>
with the user interface".<br>
<br>
let's try to lay down some axioms so we can discuss this fruifully:<br>
<br>
* there will be a shared home page<br>
<br>
* there will be a set of shared / common components available, such as the<br>
playlist, media browser and control bar<br>
<br>
* there will be some set of shared / common sub-components, such as a global<br>
pause button in the control bar<br>
<br>
* a state may also need to provide custom sub-components<br>
<br>
* a state may also want to provide a custom component for the main viewing<br>
area (e.g. a full screen plasmoid for weather, or a special browsing widget)<br>
<br>
if we can agree on those points, then we can ask: how can plugins work?<br>
<br>
well, it becomes evident that we should provide a way to define which common<br>
components and sub-components are useful in a given context from a state.<br>
<br>
we also need to allow states to register custom sub-components and provide a<br>
"main viewing area" component as well. (additional components that live on<br>
screen edges, augment the home page, etc. can be something we think about<br>
later once we have something releasable in hand today).<br></blockquote><div><br></div><div><br class="Apple-interchange-newline">Probably I've never said it clearly but i think that we *should* use plugins for the PMC states.</div>
<div>The thing is, exactly, defining a way to make shared components accessible by everyone and sub-components</div><div>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 </div>
<div>in order to put down some ideas about a possible API for MCStates plugins.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
a state should be able to enumerate child states as well. this will allow the<br>
home page entries to list all the things you can do, for instance, with<br>
"Photos" (browse, slideshow, add, whatever) if we so wish (see how the PS3,<br>
XBox 360 or moovida displays sub-menus on main entries)<br> </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
a state will need to be able to interact with the shared components as well,<br>
e.g. add an entry to the playlist.<br>
<br>
so this means we need to define some concrete APIs for playlist interaction,<br>
media browser population (both of categories and entries).<br></blockquote><div><br></div><div>This part is a bit convoluted. We currently have an API for MCApplets themself. The particular implementation</div><div>of the MediaBrowser Applet has, itself, its own plugin system that makes it possible to write plugins to show different kind</div>
<div>of media types providing a QAbstractItemModel. The way data is fetched is completely transparent to the Applet but it is</div><div>suggested to make use of the DataEngines PMC already provides. Such DataEngines are there and they're Video DataEngine and</div>
<div>Picture DataEngine (both written together with the Silk team). Both are extensible themself through plugins. They're supposed to work as data source</div><div>for MediaBrowser models.</div><div><br></div><div>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.</div>
<div>We have, again, an API that defines how Playlist Applet should be implemented, and, of course, we have the PMC implementation. This implementation makes</div><div>use of the Playlist dataengine that was meant to be a shared component for every multimedia-application within KDE.</div>
<div>This way an Amarok user could fill-in his playlists and find them there when he launches his PMC. And vice-versa of course.</div><div><br></div><div>The playback is then controlled by the MediaPlayer Applet and the MediaController which, again, are the implementations of a public API too.</div>
<div><br></div><div>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.</div><div>Later, together with Marco, we decided to abandon that in order to just put the playback control inside the API.</div>
<div><br></div><div>Do you think it is the case to resume that work and make it available to the states implementations?</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
note that all of the above is true regardless of whether we use a state<br>
machine to drive the whole thing or not.<br>
<br>
what the state machine gets us is a way to do the above in a modular fashion<br>
without writing all of the state machine boilerplate ourselves. if we really<br>
want (and if it is more undertandable for everyone involved) we could just as<br>
easily write the plugins in a more "traditional" fashion. we'll still end up<br>
with a state machine for all intents and purposes because the modes are<br>
mutually exclusive and full screen.</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
the only exception to all of this is the playing of individual media. that is<br>
yet another topic, however. the above is all about the navigation and control<br>
UI which must work together seemlessly (visually and interation wise). how a<br>
mode (plugin or not) provides media playing is another matter (and personally<br>
i'm leaning towards providing a shared mechanism for that which is in PMC<br>
itself, so a state / plugin can just say "start playing this video" or "start<br>
playing this set of images"), just as the media browser should provide.<br></blockquote><div><br></div><div>Agreed and this is related to what i wrote above.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<font color="#888888"><br>
--<br>
</font><div><div></div><div class="h5">Aaron J. Seigo<br>
humru othro a kohnu se<br>
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43<br>
<br>
KDE core developer sponsored by Qt Development Frameworks<br>
_______________________________________________<br>
Plasma-devel mailing list<br>
<a href="mailto:Plasma-devel@kde.org">Plasma-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/plasma-devel" target="_blank">https://mail.kde.org/mailman/listinfo/plasma-devel</a><br>
</div></div></blockquote></div><br>Regards<br clear="all"><br>-- <br>Alessandro Diaferia<br>KDE Developer<br>KDE e.V. member<br><br>