On 4/4/10, Alessandro Diaferia <alediafe...@gmail.com> wrote: > 2010/4/3 Aaron J. Seigo <ase...@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@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 _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
