Thread: Developers Discussion

Originally Posted by Borte

What about custom animations? Would it be possible to animate from a skin instead of creating a custom control?

Your gonna have to explain what you mean here. I imagine your used to skinning in roadrunner, and we do things differently. All skins have access to the openMobile control set. These are not "controls" like your used to in programming they just act that way to keep things easy. Skinners can use any of the controls from the control set and use any animations (in this case "transition effects") when changing between them. The control set also includes animated controls like the animated label demo'd above. The only reason a custom control would need to be used is for features open mobile doesn't provide. And even then it could just expand an existing control.

Originally Posted by Borte

In my personal opinon I don't think every possible feature should be built in from scratch, it would make more sence to keep it light and fast at the core and then the skinner could add whatever he likes at a later stage (by using the tools and posibilities from the core). This is where RideRunner fails, it has to much built in.

Well openMobile has "nothing" built in. The core provides a huge number of features but only the ones required by the skins and various plugins are even loaded. Everything has been designed from scratch for exactly the reason you will see that cf and rr are sooo slow. They try to hack together a whole bunch of other projects into something that works. We write everything from scratch so that its fast and very lightweight.

Originally Posted by justchat_1

Your gonna have to explain what you mean here. I imagine your used to skinning in roadrunner, and we do things differently. All skins have access to the openMobile control set. These are not "controls" like your used to in programming they just act that way to keep things easy. Skinners can use any of the controls from the control set and use any animations (in this case "transition effects") when changing between them. The control set also includes animated controls like the animated label demo'd above. The only reason a custom control would need to be used is for features open mobile doesn't provide. And even then it could just expand an existing control.



Well openMobile has "nothing" built in. The core provides a huge number of features but only the ones required by the skins and various plugins are even loaded. Everything has been designed from scratch for exactly the reason you will see that cf and rr are sooo slow. They try to hack together a whole bunch of other projects into something that works. We write everything from scratch so that its fast and very lightweight.

I'll try to explain a bit more...

I have never used RideRunner/RoadRunner or any of the other frontends. I have tested them all but have never used them in an application. I have always ended up programming my own frontends. First in VB and now in C#. The reason why I did this was because I wanted a faster loading system (that would run smoothly on my 600Mhz carputer) and also one that was not loaded with all kinds of things that I didn't need. Exactly the same reasons as you mentioned justchat_1.
I do like that OpenMobile aims to be a fast and lightweight system, I'm just worried that building "helper" functions into the core of the system will make it slower and harder to load. Even though that it's only loaded when needed to.
I have read all the wiki's and all the threads but I still fail to understand why things like calendars, contacts, weather and so on need to be a part of the core?
Don't get me wrong though, these are all functions I like but I just think the should be located outside of the core and be available for the skinner's as separate plugins.

I really like this project and I'd like to contribute to it (instead of always writing my own), but to be able to fully contribute I need to understand the underlying concepts of how things work under the "hood". I have downloaded the full source and have studied it several times to understand the concepts but I still don't think I get the big picture of how OpenMobile works (the reason for this might be that I compare it to the frontends that I built myself and try to understand it based on this).


Now onto the custom animations (the explanation is based upon how I did it in my personal frontends and might be a bit basic but I want try to explain it in a proper way):

When I created a control of some kind, I exposed the properties of that control so that they could be controlled directly from the skin (skin being an xml file in this case). Lets say that one of these properties where "Top". I could then control this property from the skin like this: "Picture.Top = 20;". So if I attached this command to an event (any event, but in this case a button click) I could make this control move to a location at the press of a button. If I wanted to animate it moving from one location to another I could just change the command that was executed on the event to:
i = 0;
while (i<100)
{
i = i+5;
Picture.Top = i;
}

This was all done directly in the skin itself.

I suspect that OpenMobile can do this but I have just failed to understand the concept of how to do it.

I hope this did clarify it somehow!

I have also attached and sample of my program that I tried to base this explanation on (this is in no way a fast and lightweight program since it's an early version that's using .Net3.5 and WPF but it shows the concept of what I was trying to explain. All animations and list functionallity in this program is programmed directly in the skin it self.

Ok much clearer. I get questions from users with all different levels of experience so sometimes it can be hard to figure out how technical/detailed to make my responses.

The "helper" functions aren't actually built into the core. Neither are things like the calendar, email, etc parts of the database. These are part of an external dll thats provided with alot of common functions to keep things standardized between the different plugins. The core itself is very very slim and fast (i don't know if you saw the benchmark thread but the whole program loads in ~200ms) The external dll not only provides a standard way for lets say plugin x to read emails from plugin y but also reduces the memory footprint of the app as a whole by allows functions and controls to be shared. The core itself only contains 5 classes.

Some other things to note (didn't really fit into the above):
* We use three different skinning systems but mainly we use compiled skins which load significantly quicker then xml skin files (as i'm sure your finding with your own FE). The skin designer has a quick and easy way to create most of the basics in a skin file and then automatically compiles it into a plugin dll.
* The program makes heavy use of threading to keep things fast. The first thing it does is draw the main UI and main menu, everything else happens in the background usually before you can even get your finger/mouse to a button.
* The loading only the functions needed is actually done by the .net jit compiler. Its constantly looking for the next set of functions that could be called, and compiling/optimizing them. Functions that aren't being called never even make it into memory.
* The calendars, contacts, weather that you saw in the wiki is only a struct definition of these things, not the actual plugins or any code that deals with them. Just makes it easy to save/retrieve things from the database and pass them around.

Sorry if that was a bit redundant - didn't get my cup of coffee yet

Custom Animations:
Yup thats all possible and pretty easy to do. Might make more sense to use a for loop though:

Code:

OMImage img=new OMImage()
for(int i=0;i<100;i+=5)
{
      img.Top=i;
      sleep(10); //Your code would have happened instantly so you never would have seen the move
}

The big thing to grasp with OpenMobiles controls is the concepts of panels and rendering controls.

In order for a control to be visible it has to be added to a panel (like a windows form) and that panel has to be visible. Whenever a control is in a visible panel it is rendered whenever needed by the UI. Changing things like height or text causes it to be redrawn.

Originally Posted by justchat_1

The "helper" functions aren't actually built into the core. Neither are things like the calendar, email, etc parts of the database. These are part of an external dll thats provided with alot of common functions to keep things standardized between the different plugins. The core itself is very very slim and fast (i don't know if you saw the benchmark thread but the whole program loads in ~200ms) The external dll not only provides a standard way for lets say plugin x to read emails from plugin y but also reduces the memory footprint of the app as a whole by allows functions and controls to be shared. The core itself only contains 5 classes.

Does that mean that lets say the GasStation class that's located in the namespace OpenMobile.Data won't be included in the framework? As far as I can understand from the code this has metods and properties for reading and writing data. But it seems to me as the data that this can pass are hardcoded to be of a specific structure. In this case data that contains priceDiesel, priceRegular, pricePlus and so on. What if this needs to be modefied / changed at a later stage. Does it mean that if these datanames doesn't match what is needed you can't pass the data? It's seems to me as this isn't really a function of the "core" but rather a support function. And the core shouldn't have to worry about what data it handles / passes along.

Originally Posted by justchat_1

Some other things to note (didn't really fit into the above):
* We use three different skinning systems but mainly we use compiled skins which load significantly quicker then xml skin files (as i'm sure your finding with your own FE). The skin designer has a quick and easy way to create most of the basics in a skin file and then automatically compiles it into a plugin dll.

So if I get the concept right: A skin is just c# code written either in an xml file thats compiled by the OpenMobile editor or a precompiled dll created in a program like Visual Studio.

Originally Posted by justchat_1

The big thing to grasp with OpenMobiles controls is the concepts of panels and rendering controls.

In order for a control to be visible it has to be added to a panel (like a windows form) and that panel has to be visible. Whenever a control is in a visible panel it is rendered whenever needed by the UI. Changing things like height or text causes it to be redrawn.

This is is the same behavior as I have used in my programs. But instead of having it precompiled I loaded what I needed in the background and then ran skin functionallity on the fly with a .net script languange (Script.Net) directly from the xml file.

Originally Posted by Borte

Does that mean that lets say the GasStation class that's located in the namespace OpenMobile.Data won't be included in the framework? As far as I can understand from the code this has metods and properties for reading and writing data. But it seems to me as the data that this can pass are hardcoded to be of a specific structure. In this case data that contains priceDiesel, priceRegular, pricePlus and so on. What if this needs to be modefied / changed at a later stage. Does it mean that if these datanames doesn't match what is needed you can't pass the data? It's seems to me as this isn't really a function of the "core" but rather a support function. And the core shouldn't have to worry about what data it handles / passes along.

I think your looking at an old version of the code. And if I remember right-the only version laid out that way. Those functions were moved to the helper framework as soon as they were finished, they just needed to be tested in the core during development.

The functions deal with storing and retrieving data from a shared database. Really its just more standardization. The structs themselves can be added to as we go along, as long as we don't remove any of the items we won't break any older plugins. Things that could change (unlike gas or weather) have custom fields and reserved fields to allow for values that we didn't think of and could be defined in the future.

Originally Posted by Borte

So if I get the concept right: A skin is just c# code written either in an xml file thats compiled by the OpenMobile editor or a precompiled dll created in a program like Visual Studio.

Pretty much. Seems redundant to have to put c# code in a skin file and suffer compiling during load when you could be doing it beforehand and use the full c# IDE or the openMobile skin designer. Of course the point and click code generation engine for the skin designer will turn all that upside down, but its going to be awhile before we even get that into alpha status.

Originally Posted by Borte

This is is the same behavior as I have used in my programs. But instead of having it precompiled I loaded what I needed in the background and then ran skin functionallity on the fly with a .net script languange (Script.Net) directly from the xml file.

Yea I saw...but it also took me about ~3 full sec to load the skin...imagine what thats going to be like when its fully done with music, obd, radio, etc.

Originally Posted by justchat_1

I think your looking at an old version of the code. And if I remember right-the only version laid out that way. Those functions were moved to the helper framework as soon as they were finished, they just needed to be tested in the core during development.

I updated to latest version, but I'll do a full download again just to make sure.

Originally Posted by justchat_1

Yea I saw...but it also took me about ~3 full sec to load the skin...imagine what thats going to be like when its fully done with music, obd, radio, etc.

The load time is not due to the skin load from XML or the script engine starting, it's the initialization of WPF wich is so damn slow.... I wish there was a faster way to load and initialize that. An frontend must load way faster than 3sec, so anything that can gain speed is a must. And it's even slower the first time starting it up after powering on a computer, due to the fact that .net also has to be initialized before it can start! Will the .net initializtion also be a problem for OpenMobile? The load time of ~200ms is that after a reboot of the computer?

glad you programers have this all figured out...you lost me at the first letter of the first word of the first sentence. I'll just stick to my graphics.

Justchat_1, you can expect the images you need by the end of the day on sunday EST.

Originally Posted by Borte

The load time is not due to the skin load from XML or the script engine starting, it's the initialization of WPF wich is so damn slow.... I wish there was a faster way to load and initialize that. An frontend must load way faster than 3sec, so anything that can gain speed is a must. And it's even slower the first time starting it up after powering on a computer, due to the fact that .net also has to be initialized before it can start! Will the .net initializtion also be a problem for OpenMobile? The load time of ~200ms is that after a reboot of the computer?

You would think a front end would need to load in faster then 3 seconds but according to the benchmark (and my eyes lol) most of them were 3.5+ seconds with one unnamed one taking almost ten times that.

For me the .net framework is loaded with windows startup so its ~20seconds from power on to open mobile on screen. When I disable loading on startup, it adds about a second and a half to the 200ms. Fortunately, theres a plan for that too. I've been experimenting with the automatic update tool that goes along with this (the one separate application), especially using it for AOT (ahead of time compilation). Basically everytime the software updates it takes the new files and compiles them to true bytecode from the clr code. I did some testing and this would mean updates take an extra 5 or so seconds but we maintain about a 400ms startup time (even on a cold boot), keep cross platform ability and should have a small speed increase on top of it.

UnusuallyGenius:
Sounds good...thanks.

Originally Posted by justchat_1

For me the .net framework is loaded with windows startup so its ~20seconds from power on to open mobile on screen. When I disable loading on startup, it adds about a second and a half to the 200ms. Fortunately, theres a plan for that too. I've been experimenting with the automatic update tool that goes along with this (the one separate application), especially using it for AOT (ahead of time compilation). Basically everytime the software updates it takes the new files and compiles them to true bytecode from the clr code. I did some testing and this would mean updates take an extra 5 or so seconds but we maintain about a 400ms startup time (even on a cold boot), keep cross platform ability and should have a small speed increase on top of it.

That sounds good! The slow load times that I was experiencing might be caused by the way I load things, I'm not entirely sure what is causing it.

Now that I'm starting to get the picture of how OpenMobile is working, I have a few more questions (This might be the wrong thread, if so let me know and I'll delete the post):

- Events: How exactly are events handled by the core? Is it a limit to what kind of events it can handle and what kind of data it can pass along?

- Controlling the GUI from an external source: How would it look like if I wanted to move the focus (active button) around on the screen based on some kind of external input (like arrow keys, numpads or any other source)? How would the events and controls respond to that?

- List data: Would data in a list form be limited to only be displayed in a list control or could this data be freely presented in a label type control in this manner: ListData[index]?

- How are the rules for contributing to the source? If I developed an MMI (I have an Audi) system with this would changes / suggestions / controls that I make be accepted into the source?

Cheers
Borte