Page 3 of 3 FirstFirst 123
Results 21 to 27 of 27

Thread: Developers Discussion

  1. #21
    Maximum Bitrate Borte's Avatar
    Join Date
    Jan 2006
    Location
    Norway
    Posts
    527
    Quote Originally Posted by justchat_1 View Post
    Well the goal is to create structs that are universally compatible (more below). The two systems are very similar-your right-but let me try a different angle. Plugins for this application will be developed by many separate developers. Additionally, the high and low level plugins are completely separate interfaces. In order for one plugin to be able to handle data from the other it needs type information (yes there are ways around that using reflection but they are very expensive). Since these two plugins do not share code there would be no way for them to have any idea what types the other is using without redefining the structure and type casting (again expensive).

    As an example lets create a high level plugin for playing songs and low level plugins for vlc, winamp and itunes. If i asked you to create a data structure for each of those three, they would probably all look different. This would present a big problem to the creator of the media player high level plugin-because each time a low level plugin comes out he would need to rewrite his plugin to add support for it and define whatever data structure it uses.

    By requiring a basic standard (IAVPlayer), open mobile forces all music player plugins to conform to the same standards and any additional functionality is separate. This allows a developer to create a high level music player before any of the low level plugins are even created. It also allows that same plugin to handle any new low level plugins that come out.

    The key here being that the type definition is stored in a universal location-the open mobile framework. On top of that theres a message system in place so that specialized functions not defined by the framework can still be used by the plugins that know about them.
    Sorry about all the comments I'm just trying to understand your way of thinking, and maybe add a few other points of views to the table!

    I do agree with the way that this is solved as long as it doesn't block or close down any other options further down the line. And as far as I have understood it doesn't. And for the music player I definitely agree as this is an typical case where data can be well defined. But I'm a bit more thoughtful (is that a word?) about things like the gas prices, movie listings etc. since they are of a more undefineable nature.

    But it's definitely a good point to be able to create a player without having to worry about the provider!

    Quote Originally Posted by justchat_1 View Post
    Thats an excellent point-and a great example of how valuable someone with a more international view is to the project. In the above regular refers to 85, plus refers to 95 and premium refers to 99 but those are U.S. terms so I'll change the definitions to be octane based and allow for more then 3 (I looked into it after reading this and it turns out some countries have 4 or even 5 grades)

    The goal is to make structures where things really wont change (for example a weather forecast) as defined as possible. Then for things that, like you say, would be hard to think of all possibilities ahead of time, we use more loose definitions (like raw hardware).
    See my comment above.


    Also I started looking at creating a "mmi" similar to what I had in the frontend I posted (with the same animations and so on) but ran into a few questions...

    In OpenMobile.Core you're loading UI.dll (which I think is the "floating" bar) and MainMenu.dll (which I expect is everything else). Why are they loaded as two different dll's? Shouldn't only one entry point for a skin be hardcoded (ie. MainMenu.dll) and the rest be loaded from there rather than from the core?

    Also why are the UI.dll and MainMenu.dll (basically skin dll's) located in the plugin folder rather than the skin folder? It seems to me as these should be a part of the skin / graphics rather than a plugin. Since that if I'm changing the graphics I would also probably change the way they behave.

    Transition is just a word for switching from one panel to another? It doesn't necessary have anything todo with the graphical effect while changing (I know it can have a graphical effect), but used without parameters will just change it without any effect. Right?

    Why is the "checkVolumeChange" in the UI rather than being in its own plugin? I'm sure it’s a good reason for it but it seems a bit out of place.

    If I wanted to display the current system time on a panel, would I have to use a timer and poll it? Or could a "system data plugin" push it to the panel? I personally don't like polling for data as this defeats the purpose of event driven programming. I know the system time might be a bad example (since its a cyclically changing data) but what if it where the currently playing song or something else?

    an OMPanel doesn't have Left, Top, Height and Width properties. Wouldn't it make sense to put that in there and have all the controls located on that panel placed itself relative to the panel? Doing it this way would make it easier to move a group of controls around.

    Rendering a control:
    All rendering is located in the OpenMobile.FrameWork.Renderer, even the specific rendering for a control. Why is this located there rather than being located in the control itself where it kinda belongs? That way when changing / adding a control the only place to make a change would be in the specific control class itself. Structured correctly each class (control) could render its part and don't having to worry about the rest of the rendering. I made a quick test to show what I meant if you’re interested.

    I hope you’re not offended in any way by all my questions / comments; they are only meant to be constructive to help create a better product.
    Failure is not an option...
    __________________________________________________ ______________________________
    The only full multizone / multiscreen cross platform open source Front End -> OpenMobile

  2. #22
    Raw Wave
    Auto Apps:loading...
    justchat_1's Avatar
    Join Date
    Jul 2008
    Location
    Boston, Ma or NY,NY
    Posts
    2,359
    Quote Originally Posted by Borte View Post
    Sorry about all the comments I'm just trying to understand your way of thinking, and maybe add a few other points of views to the table!

    I do agree with the way that this is solved as long as it doesn't block or close down any other options further down the line. And as far as I have understood it doesn't. And for the music player I definitely agree as this is an typical case where data can be well defined. But I'm a bit more thoughtful (is that a word?) about things like the gas prices, movie listings etc. since they are of a more undefineable nature.

    But it's definitely a good point to be able to create a player without having to worry about the provider!
    I guess it depends...and maybe theres things i'm overlooking (like i overlooked the octane thing)...but I couldn't think of any situations where a gas station would need more then:

    Station Name
    Station Location
    Array of:
    Octane
    Price

    That to me would cover any type of fuel (diesel would be cetane not octane-but could use the same struct). Movies, I probably will discuss when it gets time to define anything related to that-and you may be right we may have trouble defining it.
    Quote Originally Posted by Borte View Post
    Also I started looking at creating a "mmi" similar to what I had in the frontend I posted (with the same animations and so on) but ran into a few questions...

    In OpenMobile.Core you're loading UI.dll (which I think is the "floating" bar) and MainMenu.dll (which I expect is everything else). Why are they loaded as two different dll's? Shouldn't only one entry point for a skin be hardcoded (ie. MainMenu.dll) and the rest be loaded from there rather than from the core?
    Technically yes we could load just the UI and have it load the main menu. The reason the two were both defined individually was for performance reasons. Since any skin will require a UI and a main menu-these two are loaded first before the initialization sequence of the rest of the plugins to ensure minimum time until the full UI is displayed and drawn (our 200ms startup).

    Another thing to note is the difference between UI and MainMenu. UI is an always loaded and always on top panel. Its at the skinners discretion if it contains just a back button or a full top bar and sliding panels for various notifications. Main menu is the first screen loaded but can be transitioned in and out as needed and works like any other panel.
    Quote Originally Posted by Borte View Post
    Also why are the UI.dll and MainMenu.dll (basically skin dll's) located in the plugin folder rather than the skin folder? It seems to me as these should be a part of the skin / graphics rather than a plugin. Since that if I'm changing the graphics I would also probably change the way they behave.
    Interesting point, I had originally put them there because I was considering a skin dll a "high level plugin" but rethinking it now we could certainly put them in the skins folder instead, it would just mean having to look in two folders at startup, which could have a small performance penalty.

    Quote Originally Posted by Borte View Post
    Transition is just a word for switching from one panel to another? It doesn't necessary have anything todo with the graphical effect while changing (I know it can have a graphical effect), but used without parameters will just change it without any effect. Right?
    I don't think i've uploaded the latest version of the code yet but im depreciating the load panel command in favor of the transition commands. Transition with a transition type set to none will do the same thing-yes.

    Quote Originally Posted by Borte View Post
    Why is the "checkVolumeChange" in the UI rather than being in its own plugin? I'm sure itís a good reason for it but it seems a bit out of place.
    In order to detect a volume change on windows you need to set a callback to a windows form. Now I could (and may in the future) create a form thats never drawn just to handle callbacks but for now im using the UI for winproc messages. During testing I had kept the check volume function there for debugging and forgot to move it out. I'll move it into osspecificlib where it belongs.

    Quote Originally Posted by Borte View Post
    If I wanted to display the current system time on a panel, would I have to use a timer and poll it? Or could a "system data plugin" push it to the panel? I personally don't like polling for data as this defeats the purpose of event driven programming. I know the system time might be a bad example (since its a cyclically changing data) but what if it where the currently playing song or something else?
    Yes system time would have to be pulled but the important things like a currently playing song are pushed. Your plugin would hook the OnMediaEvent event and respond to the play function.

    Actually on second thought yes a data plugin could push the system time via a message but it certainly wouldn't be considered "good practice".

    For the most part i'm aiming to keep cyclically changing data as pull type events and randomly changing data as push type events. I think overall that should work best but certainly welcome input if i'm overlooking anything.
    Quote Originally Posted by Borte View Post
    an OMPanel doesn't have Left, Top, Height and Width properties. Wouldn't it make sense to put that in there and have all the controls located on that panel placed itself relative to the panel? Doing it this way would make it easier to move a group of controls around.
    That was definitely something I tossed around-and you'll see in the next code upload that panels have gotten some nice upgrades. I still feel that panels should take the full screen every time. I want to say the reason is for simplicity but for some reason it doesn't feel like it would fit in with the rest of the design. In some ways it would also complicate the UI's handling of layering. The idea that I had wanted to do instead was a group box. This would be an instance of the base interface OMControl with properties such as an optional background color, and optional border or title (similar to a windows forms groupbox). But the default would be a borderless transparent container for controls that can have any size and position. This would allow you to do exactly what you are talking about-and could be infinitely nested-but would maintain the control structure of the application.

    The only think that I haven't figured out is how to handle scaling-thats certainly going to need a unique solution. Obviously actually drawing the controls scaled is easy, but figuring out by how much is difficult.
    Quote Originally Posted by Borte View Post
    Rendering a control:
    All rendering is located in the OpenMobile.FrameWork.Renderer, even the specific rendering for a control. Why is this located there rather than being located in the control itself where it kinda belongs? That way when changing / adding a control the only place to make a change would be in the specific control class itself. Structured correctly each class (control) could render its part and don't having to worry about the rest of the rendering. I made a quick test to show what I meant if youíre interested.

    I hope youíre not offended in any way by all my questions / comments; they are only meant to be constructive to help create a better product.
    I'm not at all offended by the questions/comments i'm actually quite grateful. By having to think about the answers to a lot of your questions it allows me to rethink why I did many things and in a few cases picked up on some things I had overlooked. The end goal is exactly that-to create the best product we can and you are certainly helping to achieve that.

    Now-for the renderer class:
    Your absolutely right-each control should have the rendering done inside the render function. When I first started working on the control set, the rendering was done by that class but after adding the render function to IHighLevel, newer controls do their rendering there (Slider, MessageBox, AnimatedLabel). I started moving some of the functions back but certainly need to finish that.

    I think the goal will be to move the control rendering of most things back into their respective classes but I plan to leave some of the more general functions in the renderer class to make it easier for newer controls (so they don't have to re-invent the wheel). Things like drawing a string formatted and with the right font and transparency, or drawing a semi-transparent image...stuff that will likely need to be used by many controls. I'll also have to take a look at all the rendering functions and see if theres anything in common between a few of them that I might want to move to a separate function.

  3. #23
    Maximum Bitrate Borte's Avatar
    Join Date
    Jan 2006
    Location
    Norway
    Posts
    527
    Quote Originally Posted by justchat_1 View Post
    I guess it depends...and maybe theres things i'm overlooking (like i overlooked the octane thing)...but I couldn't think of any situations where a gas station would need more then:

    Station Name
    Station Location
    Array of:
    Octane
    Price

    That to me would cover any type of fuel (diesel would be cetane not octane-but could use the same struct). Movies, I probably will discuss when it gets time to define anything related to that-and you may be right we may have trouble defining it.
    I think your data structure for the gas station is better now. Basically it all comes down to figuring out the correct data structure, but to do that one has to have the "big picture" if you know what I mean.

    Quote Originally Posted by justchat_1 View Post
    Technically yes we could load just the UI and have it load the main menu. The reason the two were both defined individually was for performance reasons. Since any skin will require a UI and a main menu-these two are loaded first before the initialization sequence of the rest of the plugins to ensure minimum time until the full UI is displayed and drawn (our 200ms startup).

    Another thing to note is the difference between UI and MainMenu. UI is an always loaded and always on top panel. Its at the skinners discretion if it contains just a back button or a full top bar and sliding panels for various notifications. Main menu is the first screen loaded but can be transitioned in and out as needed and works like any other panel.
    Now I understand why you load both. I wasn't aware that the UI is an always on top panel. I tought it was just the same as any other panel. But I still have a question: What if I want to hide the UI? Is that possible?

    Quote Originally Posted by justchat_1 View Post
    Interesting point, I had originally put them there because I was considering a skin dll a "high level plugin" but rethinking it now we could certainly put them in the skins folder instead, it would just mean having to look in two folders at startup, which could have a small performance penalty.
    It basically comes down to covering what would be changed around if someone where to swap between different skins. I think it should be a folder named skin that has a subfolder with the name of the skin that contains everything needed to run that skin.

    Quote Originally Posted by justchat_1 View Post
    In order to detect a volume change on windows you need to set a callback to a windows form. Now I could (and may in the future) create a form thats never drawn just to handle callbacks but for now im using the UI for winproc messages. During testing I had kept the check volume function there for debugging and forgot to move it out. I'll move it into osspecificlib where it belongs.
    Would it be wise to move system functions out into a separate system plugin thats always there? I think it might make for a better structured code (but might have an impact on performance). I'm just picky when it comes to structuring code, I don't like it when things are all over the place (like RR's code!).

    Quote Originally Posted by justchat_1 View Post
    That was definitely something I tossed around-and you'll see in the next code upload that panels have gotten some nice upgrades. I still feel that panels should take the full screen every time. I want to say the reason is for simplicity but for some reason it doesn't feel like it would fit in with the rest of the design. In some ways it would also complicate the UI's handling of layering. The idea that I had wanted to do instead was a group box. This would be an instance of the base interface OMControl with properties such as an optional background color, and optional border or title (similar to a windows forms groupbox). But the default would be a borderless transparent container for controls that can have any size and position. This would allow you to do exactly what you are talking about-and could be infinitely nested-but would maintain the control structure of the application.

    The only think that I haven't figured out is how to handle scaling-thats certainly going to need a unique solution. Obviously actually drawing the controls scaled is easy, but figuring out by how much is difficult.
    I'm not at all offended by the questions/comments i'm actually quite grateful. By having to think about the answers to a lot of your questions it allows me to rethink why I did many things and in a few cases picked up on some things I had overlooked. The end goal is exactly that-to create the best product we can and you are certainly helping to achieve that.

    Now-for the renderer class:
    Your absolutely right-each control should have the rendering done inside the render function. When I first started working on the control set, the rendering was done by that class but after adding the render function to IHighLevel, newer controls do their rendering there (Slider, MessageBox, AnimatedLabel). I started moving some of the functions back but certainly need to finish that.

    I think the goal will be to move the control rendering of most things back into their respective classes but I plan to leave some of the more general functions in the renderer class to make it easier for newer controls (so they don't have to re-invent the wheel). Things like drawing a string formatted and with the right font and transparency, or drawing a semi-transparent image...stuff that will likely need to be used by many controls. I'll also have to take a look at all the rendering functions and see if theres anything in common between a few of them that I might want to move to a separate function.
    I'm still working on sample for the control / renderer setup that I mentioned earlier. If you don't mind I'll create a working sample and upload it here so you could have a look at it. I think it might help for structuring the controls and make it easier to create new ones. I used the way that you did it in open mobile but with a few tweaks to make it easier to render the different parts (at least in my opionion but I might be overlooking something so I'd like your input on it and maybe you could use it in OM).
    Failure is not an option...
    __________________________________________________ ______________________________
    The only full multizone / multiscreen cross platform open source Front End -> OpenMobile

  4. #24
    Raw Wave
    Auto Apps:loading...
    justchat_1's Avatar
    Join Date
    Jul 2008
    Location
    Boston, Ma or NY,NY
    Posts
    2,359
    Quote Originally Posted by Borte View Post
    I think your data structure for the gas station is better now. Basically it all comes down to figuring out the correct data structure, but to do that one has to have the "big picture" if you know what I mean.
    Exactly!

    Quote Originally Posted by Borte View Post
    Now I understand why you load both. I wasn't aware that the UI is an always on top panel. I tought it was just the same as any other panel. But I still have a question: What if I want to hide the UI? Is that possible?
    As of this moment-no...but that is certainly a necessary feature-it just hasn't been a priority yet.

    Quote Originally Posted by Borte View Post
    It basically comes down to covering what would be changed around if someone where to swap between different skins. I think it should be a folder named skin that has a subfolder with the name of the skin that contains everything needed to run that skin.
    Yea thats certainly the "standard" way of skinning. And once things got further along I was planning on moving to a system where we have a skins folder and inside is a folder called default and other folders labeled as their skin name. We could also just have a folder per skin name and a setting stored that selected where to look.

    The challenge though is in the unique skinning/plugin system used here. Roadrunner uses a system where a skin needs to have "support" for every possible plugin it might use. In OpenMobile skinning is pretty automatic. If you have a red theme and download a media player plugin, its now going to use your red buttons and other controls on top of your red themed background and UI. For quite a few plugins that means automatic skinning without any plugin specific work involved. It seems wasteful to have to store that same plugin in the red skin folder, the blue skin folder, the green skin folder and the mp3car skin folder.

    That was my thinking for storing things in the plugins folder but obviously theres a pretty good argument for keeping skins together with skin images.
    Quote Originally Posted by Borte View Post
    Would it be wise to move system functions out into a separate system plugin thats always there? I think it might make for a better structured code (but might have an impact on performance). I'm just picky when it comes to structuring code, I don't like it when things are all over the place (like RR's code!).
    I'm also usually pretty picky about how code is structured. The problem is i'm very picky going through code but rather sloppy when i'm on attempt number 50 getting something to work correctly. So usually everything gets tidied up by the time its committed and then looks really good after I go over it again and optimize everything.

    In this case I moved everything to OSSpecificLib with exactly the intention of having that be a separate library. For simplicity its staying there for now instead of a separate dll but breaking that folder off later should be very easy.
    Quote Originally Posted by Borte View Post
    I'm still working on sample for the control / renderer setup that I mentioned earlier. If you don't mind I'll create a working sample and upload it here so you could have a look at it. I think it might help for structuring the controls and make it easier to create new ones. I used the way that you did it in open mobile but with a few tweaks to make it easier to render the different parts (at least in my opionion but I might be overlooking something so I'd like your input on it and maybe you could use it in OM).
    Yea I would be happy to take a look. The svn server is about a week behind on code because I need to stabilize and test all the changes made but there have been a lot of changes to how the rendering is done. Hopefully not the same idea your working on....

  5. #25
    Maximum Bitrate Borte's Avatar
    Join Date
    Jan 2006
    Location
    Norway
    Posts
    527
    Quote Originally Posted by justchat_1 View Post
    It seems wasteful to have to store that same plugin in the red skin folder, the blue skin folder, the green skin folder and the mp3car skin folder.
    It is wasteful but only on hardisk space. Not performance. Usually hd space is not an issue. It would also help for distribution of skins.

    Quote Originally Posted by justchat_1 View Post
    I'm also usually pretty picky about how code is structured. The problem is i'm very picky going through code but rather sloppy when i'm on attempt number 50 getting something to work correctly. So usually everything gets tidied up by the time its committed and then looks really good after I go over it again and optimize everything.
    Don't worry, I know exactly what you mean.


    Quote Originally Posted by justchat_1 View Post
    Yea I would be happy to take a look. The svn server is about a week behind on code because I need to stabilize and test all the changes made but there have been a lot of changes to how the rendering is done. Hopefully not the same idea your working on....
    Hopefully not... lol!
    Iv'e just restructured the controls a bit. I created a base class called bcObject (bc is short for BorteCar to don't mix it up with OM controls) that contains all code and functions that all objects should have. I then broke the controls down into smaller pieces like a circle, rectangle, text and so on. Then these can inherit each other to form a complete control. Like a label would have bcObject (base functionality) -> bcRectangle (label frame and background) -> bcLabel (text output). I'm also working on creating a system that can inherit clipping, this would allow an ineheritance like this: bcObject -> bcCircle -> bcImage that would clip the image to the shape of a circle. It's kinda similar to the idea that WPF is based on. I don't think I'll have this ready before the weekend though.
    Failure is not an option...
    __________________________________________________ ______________________________
    The only full multizone / multiscreen cross platform open source Front End -> OpenMobile

  6. #26
    Raw Wave
    Auto Apps:loading...
    justchat_1's Avatar
    Join Date
    Jul 2008
    Location
    Boston, Ma or NY,NY
    Posts
    2,359
    Quote Originally Posted by Borte View Post
    It is wasteful but only on hardisk space. Not performance. Usually hd space is not an issue. It would also help for distribution of skins.
    Yea true for the most part space wouldn't be an issue...but what about updates to plugins? If I make a new JustinsMediaPlayer.dll I now have to update it in each skin folder (but only the ones that had it in the first place). It probably wouldn't be that big of a deal for installers, but if a user had to install it them self it might cause some problems.

    Quote Originally Posted by Borte View Post
    Hopefully not... lol!
    Iv'e just restructured the controls a bit. I created a base class called bcObject (bc is short for BorteCar to don't mix it up with OM controls) that contains all code and functions that all objects should have. I then broke the controls down into smaller pieces like a circle, rectangle, text and so on. Then these can inherit each other to form a complete control. Like a label would have bcObject (base functionality) -> bcRectangle (label frame and background) -> bcLabel (text output). I'm also working on creating a system that can inherit clipping, this would allow an ineheritance like this: bcObject -> bcCircle -> bcImage that would clip the image to the shape of a circle. It's kinda similar to the idea that WPF is based on. I don't think I'll have this ready before the weekend though.
    Its an interesting idea...since c# doesn't support multiple-inheritance i'm not even sure how your going to pull this off. Definitely looking forward to finding out

  7. #27
    Maximum Bitrate Borte's Avatar
    Join Date
    Jan 2006
    Location
    Norway
    Posts
    527
    Quote Originally Posted by justchat_1 View Post
    Its an interesting idea...since c# doesn't support multiple-inheritance i'm not even sure how your going to pull this off. Definitely looking forward to finding out
    I've sent you a PM.
    Failure is not an option...
    __________________________________________________ ______________________________
    The only full multizone / multiscreen cross platform open source Front End -> OpenMobile

Page 3 of 3 FirstFirst 123

Similar Threads

  1. Mp3car Blog Discussion
    By Fiberoptic in forum Mp3Car Blog Talk
    Replies: 3
    Last Post: 03-18-2011, 01:55 AM
  2. Linux Ice and Nghost looking for developers
    By wirelessdreamer in forum LinuxICE
    Replies: 5
    Last Post: 08-16-2009, 06:05 AM
  3. StreetDeck Developers Table of Contents
    By nationapn in forum Wiki Discussion Threads
    Replies: 0
    Last Post: 11-03-2007, 12:36 PM
  4. Developer discussion thread
    By avidan in forum MacCar
    Replies: 82
    Last Post: 09-21-2005, 12:43 AM
  5. "Revolutionary" Product
    By CaffeineAddict in forum Off Topic
    Replies: 5
    Last Post: 06-16-2002, 03:06 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •