Skinning contest: One month to go (4 Viewers)

[bodiroga]

Many thanks to both for your help, I really appreciate all your effort with the development and the teaching part

I think that I'm understanding it, so I will write what I've understood till now to see if I'm correct or not.

For the HelloWorld plugin example we have two workflow files: the action and state workflow files.

As I understand, the workflow state is the main screen itself, which includes the general information about it, such as: an "ID" indicator to identify the screen over the program, the screen title,... In this "main screen" is where the "screen" itself (the folder has that name) will be added with all the skinning possibilities: dockpanels, grids, stackpanels, buttons,... So we can say that the workflow state is just like a white paper that has to be written, but with it's own identification to distinguish it from all the different white papers we have. (I hope that you are understanding what I'm saying, because with the difficulty of the concepts and my basic level of english...)

The workflow action is a link to that workflow state, just like a bridge between one workflow state (in this case the home menu workflow state) and the other (the helloworld workflow state). It's only a "jump" indicator, right?

The only thing that I don't understand is: what are then the workflow models???? Are they a bunch of workflow states connected between them and the model tells them how they are organized? I can't find any workflow model file to have a look at it...

And the last question... which are the differences between a workflow state and a file containing <window></window>?? Baboonanza said that workflow state were "stopping points in the GUI, like Windows or Dialogs", but which are the differences between them?

I hope that I'm in the right direction and I haven't said too many stupid things, please correct me if I'm wrong

Many thanks again for all your help, this is the main reason why I love Mediaportal so much: developers, skinners, normal users,... are always ready to help and do their best for others. Great work guys, you are just awesome!!!

Best regards,

Aitor

PS: Having a better look at the Plugins folder I can see that there aren't much folders that can be skinned. Configuration, HelloWorld (not in standard release), Media, SkinBase, SkinEngine (I can forget this folder) and Weather are the only folders with skin subfolders! Things are getting cleaner with the time

 

[Albert]

AW: Re: Skinning contest: One month to go

For the HelloWorld plugin example we have two workflow files: the action and state workflow files.

As I understand, the workflow state is the main screen itself, which includes the general information about it, such as: an "ID" indicator to identify the screen over the program, the screen title,...

Basically, 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.

In this "main screen" is where the "screen" itself (the folder has that name) will be added with all the skinning possibilities: dockpanels, grids, stackpanels, buttons,...

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.

So we can say that the workflow state is just like a white paper that has to be written, but with it's own identification to distinguish it from all the different white papers we have. (I hope that you are understanding what I'm saying, because with the difficulty of the concepts and my basic level of english...)

The workflow action is a link to that workflow state, just like a bridge between one workflow state (in this case the home menu workflow state) and the other (the helloworld workflow state). It's only a "jump" indicator, right?

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.

The only thing that I don't understand is: what are then the workflow models???? Are they a bunch of workflow states connected between them and the model tells them how they are organized? I can't find any workflow model file to have a look at it...

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.

PS: Having a better look at the Plugins folder I can see that there aren't much folders that can be skinned. Configuration, HelloWorld (not in standard release), Media, SkinBase, SkinEngine (I can forget this folder) and Weather are the only folders with skin subfolders! Things are getting cleaner with the 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.

 

[Baboonanza]

Re: AW: Re: Skinning contest: One month to go

The last thing that I'd add since it has been specifically put into so many words is that Workflow States and Actions are the higher-level layout of the application (the Workflow). You could (mainly) draw the workflow on a piece of paper with states as circles and actions as lines connecting them. It might be useful to add that diagram to the wiki actually.

Screens & Models are the implementation of the higher-level workflow.

 

[FreakyJ]

AW: Skinning contest: One month to go

Hey,

I'm trying to port something to MP
Now it still looks good^^

I have this Canvas:

<Canvas x:Name="ParticleHost" />

In WPF I can just access it with:

this.ParticleHost.Children.Add(ellipse);

But I can't find anything how I can access it in MPF oO

Maybe somebody could give me hint Would be very kind^^

 

[Albert]

AW: Skinning contest: One month to go

Ehm, your "WPF" code is C# code. Do you want to add skin elements in code or via XAML?

 

[FreakyJ]

AW: Skinning contest: One month to go

I want to add Elements via Code on a Canvas

I want to draw ellipses on a Canvas and then move them around on the canvas

var ellipse = new Ellipse();
//... some properties for the ellipse
// Add the Ellipse to the GUI
this.ParticleHost.Children.Add(ellipse);

I'm trying to make a particle background and got it to work with WPF, but not with MPF =)

//EDIT:
Oh, you are right, I found my little mistake in the post above.
I mean that I can access the WPF canvas Element with the following c# code^^

this.ParticleHost.Children.Add(ellipse);

//EDIT2:
If I'm right I have to use the MP Ellipse Control? At the moment I'm using the WPF ellipse Control and I think that won't work with MP, right? oO The same with the brushes and blur effects..., right?
Hopefully you can help me out. I will be on vacations for 4 days So if you can't help me with the information I gave to you, I will post my little WPF application after my vacations, but the code is very messed up, because of try and error xD I have to clean it up first^^

And back to my problem I described first: I think I have to work with the {} to get access to my canvas... but can't find the right way in the documentation, only for stings oO Also other Plugins, like the videoplayer doesn't give me a hint, also it use a canvas^^

//EDIT3:
Additional information: The MPF works, just the code behind doesn't, here is my current MPF:

<DockPanel Name="FastParticleBackground.Window1"
xmlns="www.team-mediaportal.com/2008/mpf/directx"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Context="{Model Id=5726DA5A-70D5-458f-AF67-611293D97912}"
Loaded="Window_Loaded">
    <Grid>
        <Grid.Background>
            <RadialGradientBrush Center="0.54326,0.45465" RadiusX="0.602049" RadiusY="1.02049" GradientOrigin="0.4326,0.45465">
                <GradientStop Color="#57ffe6" Offset="0"/>
                <GradientStop Color="#008ee7" Offset="0.718518495559692"/>
                <GradientStop Color="#2c0072" Offset="1"/>
            </RadialGradientBrush>
        </Grid.Background>
        <Canvas x:Name="ParticleHost" />
    </Grid>
</DockPanel>

 

[Albert]

AW: Skinning contest: One month to go

We don't support accessing screen elements via C# code. But to do animations, that is not necessary. WPF/MPF has a sophisticated animation API which can be used for that.

 

[FreakyJ]

AW: Skinning contest: One month to go

Oh that is sad...
Can you give me a hint how to realize this? Because the ellipses have different blur effects.

I attached the source of my WPF application, but the source is very ugly, so you are warned^^

 

[Baboonanza]

Re: AW: Skinning contest: One month to go

Are you sure that works? My understanding with that if the Canvas was created in XAML you must use FindResource (which exists as UIElement.FindResource in MPF) with it's get to obtain it. Only if you created the Canvas in code could you access it the way you are trying to.

So, in theory some interaction between code and XAML elements is possible in MPF using FindResource. I wouln't recommend it though, for one thing it would mean having to have a plugin with the code in.

Also, particle effects would be well suited to being added as a custom control, then you could have emitters and other more complex behaviours. It shouldn't be too difficult to do.

 

[FreakyJ]

AW: Skinning contest: One month to go

UIElement.FindResource doesn't exist... Sorry for so much questions, but it is hard to get something running without a clear example of how different things work...