Reply to thread

Message: <blockquote data-quote="Albert" data-source="post: 677828" data-attributes="member: 67886">AW: Re: Skinning contest: One month to goBasically, yes. I would express it a bit different; the state is not exactly equal to the screen which is presenting it. Basically you can say that a screen always presents some workflow state (there is always a workflow state active), but a workflow state can have multiple screens if the plugin dev builds it like that. The workflow state is basically the backend state while the screen is a kind of frontend state. But typically you're right, one screen corresponds to one workflow state and vice-versa.You can say: A screen is identified by its name. When we're talking about a screen, we basically are refering to the abstract idea of any screen which has that name and thus fills the template (or white paper, as you call it). Lets say you have a screen A. In one skin, the screen implementation can have a yellow background while in the other skin, the screen looks blue. Both screen implementations fill the same screen template. Both have the name A.Now take a look at one screen file. Maybe the "Home" screen implementation of the default skin. You're right, basically, you only see the controls/panels/etc. of the content area of that screen (the lower right area). But that file also defines the other areas (title, menu etc.). How is that done? It's done by the included "master_menu" screen, which provides all those general screen contents. Almost each screen looks like that: It either includes "master", "master_menu" or one of the dialog templates. That makes all screens have the same general contents.Yes, correct. When the system collects the menu entries to be shown, it looks through all available menu actions (which are defined by each plugin in its menu actions worklow file) and collects those, whose source state fits to the current workflow state.There are also other actions which don't switch workflow states but which call some code in the background or other funny things.Screens are a bit like HTML pages. They contain layout containers, controls etc. They can also contain animations. But to trigger actions in the system (collect a list of things, play items, save a playlist, ...) and to get complex data (current date and time, a list of media items etc.), you need code. Screens refer to such code and bind buttons to actions in that code or they bind lists or labels to data in that code.Code, which can be referred to by the screen, is called a "model".Workflow models are a special kind of model; skinners don't need to understand what the difference is. Workflow models always know the current worklow state while "normal" models don't know that. For example the media navigation behaves different depending on the workflow state (it provides different item lists depending on the folder you're browsing). That's because the media model is a workflow model.The model which provides the date and time in the Home screen is a normal model. It's behaviour doesn't depend on the workflow model. It always provides the current date and time.Correct. Only plugins which provide workflow states and screens must provide default screen implementations for them.And, of course, there might be plugins which provide complete skins. Those plugins will also contain a Skin folder although they don't bring in new workflow states.</blockquote>

Verification