Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 27

Thread: Developers Discussion

  1. #11
    Raw Wave
    Auto Apps:loading...
    justchat_1's Avatar
    Join Date
    Jul 2008
    Location
    Boston, Ma or NY,NY
    Posts
    1,783
    I moved the discussion to a new thread...

    Quote Originally Posted by Borte View 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?
    Thats far from a one word answer-so i'll go with it depends on the data, where its coming from and where its going to. For example type IOther plugins can pass any kind of data along (wrapped in an object). There is also an array of functions (eFunction) that can be executed or raised as system wide events. We also have system wide events that are raised in response to various system activities (For ex: When a disk is inserted, a system resumes from hibernation, volume changes, keys are pressed, etc). Then we have control specific events which can be hooked by the plugin that created them. Finally we have a message system that can be used to send messages between any of the plugins.
    Quote Originally Posted by Borte View Post
    - 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?
    I haven't finished the keyboard based control yet but any plugin could raise the "keypress event" and the UI would respond to it. So even if it was something like a space navigator you could have the plugin raise a up_arrow event when the device is pushed up.

    Quote Originally Posted by Borte View Post
    - 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]?
    Yup it could

    Quote Originally Posted by Borte View Post
    - 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?
    Depends on the changes/suggestions/controls.....but since the entire system is based on plugins worst I could say is make it a separate plugin. For the most part though as long as the changes move the project forward in the right direction i'll probably say ok.

  2. #12
    Maximum Bitrate Borte's Avatar
    Join Date
    Jan 2006
    Location
    Norway
    Posts
    443
    Quote Originally Posted by justchat_1 View Post
    Thats far from a one word answer-so i'll go with it depends on the data, where its coming from and where its going to. For example type IOther plugins can pass any kind of data along (wrapped in an object). There is also an array of functions (eFunction) that can be executed or raised as system wide events. We also have system wide events that are raised in response to various system activities (For ex: When a disk is inserted, a system resumes from hibernation, volume changes, keys are pressed, etc). Then we have control specific events which can be hooked by the plugin that created them. Finally we have a message system that can be used to send messages between any of the plugins.
    I haven't finished the keyboard based control yet but any plugin could raise the "keypress event" and the UI would respond to it. So even if it was something like a space navigator you could have the plugin raise a up_arrow event when the device is pushed up.
    Ok. I also assume that controls have events like GotFocus, LostFocus etc...?

    Quote Originally Posted by justchat_1 View Post
    Yup it could
    Sweet. This opens up for programming custom behavior for a list.

    Quote Originally Posted by justchat_1 View Post
    Depends on the changes/suggestions/controls.....but since the entire system is based on plugins worst I could say is make it a separate plugin. For the most part though as long as the changes move the project forward in the right direction i'll probably say ok.
    Good. Do you guys have a separate way of communicating or does alle the development talk happen here on the forum or in the wiki? Is it being developed manily by people from us?

    I still have a few more questions/comments while were at it (hope you dont mind)...

    Data behavior:
    If i want to display data X (provided from plugin Y) in a control will the control ask the plugin for data (ie poll) or will the control "subscribe" to data comming from the plugin (ie a push system)?
    Will changing a value trigg an event so I can execute some kind of code on change of data X from plugin Y?

    Also I've been wondering over this:
    Quote Originally Posted by justchat_1
    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.
    Wouldn't it be better to not having the core split the data? Then you wouldn't have to worry about breaking any old code or trying to think of any changes that might come up.

    Quote 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 did a full SVN checkout but the functions are still there, allthough changed to use SQLite.
    Failure is not an option...
    __________________________________________________ ______________________________
    The only full multizone / multiscreen cross platform open source Front End -> OpenMobile

  3. #13
    Raw Wave
    Auto Apps:loading...
    justchat_1's Avatar
    Join Date
    Jul 2008
    Location
    Boston, Ma or NY,NY
    Posts
    1,783
    Quote Originally Posted by Borte View Post
    Ok. I also assume that controls have events like GotFocus, LostFocus etc...?
    At the moment only click events because I haven't found the need for got and lost focus. When rendering you can query the mode property to find out if it has focus.

    But if anyone requests it, it would take about 5 seconds to add in. It could be a modeChanged event which would cover got focus, lost focus, mouse down, mouse up.

    Quote Originally Posted by Borte View Post
    Good. Do you guys have a separate way of communicating or does alle the development talk happen here on the forum or in the wiki? Is it being developed manily by people from us?
    So far its developed only by me lol....But i've had lots of suggestions and input from members of the community from i imagine all over. Also, have some great graphics work done by UnusuallyGenius.

    As far as communication yes mostly on the forums, wiki, pm's or through email (pm me and I can give you my email)

    Quote Originally Posted by Borte View Post
    I still have a few more questions/comments while were at it (hope you dont mind)...

    Data behavior:
    If i want to display data X (provided from plugin Y) in a control will the control ask the plugin for data (ie poll) or will the control "subscribe" to data comming from the plugin (ie a push system)?
    Will changing a value trigg an event so I can execute some kind of code on change of data X from plugin Y?
    Theres no one answer for that question. For some things its polling, for most things its a trigger. Theres even some things that the plugin pushes the data to the database when its ready and then other plugins pull from the database.
    You have to realize the reason we use the "core" for communication is that with plugins theres no way to no what controls or functionality it will provide beforehand so things need to be standardized. If you ask for data x the core takes care of figuring out how to get data x and provides it to you. It could come from plugin y or plugin z.

    What i'm trying to say is you have a single process view of how applications run. We don't run like a single process application This is the equivalent of many programs running in shared space, sometimes at the same time on different threads. Most of the time a plugin will have no idea about the other plugins that are loaded also (unless it asks).
    Quote Originally Posted by Borte View Post
    Also I've been wondering over this:
    Wouldn't it be better to not having the core split the data? Then you wouldn't have to worry about breaking any old code or trying to think of any changes that might come up.
    Not sure what you mean here. The core handling data is exactly what prevents us from breaking old code. Its also how we can guarantee lots of different plugins can talk to each other without having any idea what kinds of methods, or controls or code they contain.
    Quote Originally Posted by Borte View Post
    I did a full SVN checkout but the functions are still there, allthough changed to use SQLite.
    Im not sure why your still seeing it. The data classes should be in OpenMobile.Framework.dll only. Heres a view of the source online:
    http://openmobile.svn.sourceforge.ne...nd/OpenMobile/
    as you can see - no data classes.

  4. #14
    Maximum Bitrate Borte's Avatar
    Join Date
    Jan 2006
    Location
    Norway
    Posts
    443
    Quote Originally Posted by justchat_1 View Post
    Theres no one answer for that question. For some things its polling, for most things its a trigger. Theres even some things that the plugin pushes the data to the database when its ready and then other plugins pull from the database.
    You have to realize the reason we use the "core" for communication is that with plugins theres no way to no what controls or functionality it will provide beforehand so things need to be standardized. If you ask for data x the core takes care of figuring out how to get data x and provides it to you. It could come from plugin y or plugin z.

    What i'm trying to say is you have a single process view of how applications run. We don't run like a single process application This is the equivalent of many programs running in shared space, sometimes at the same time on different threads. Most of the time a plugin will have no idea about the other plugins that are loaded also (unless it asks).
    What I meant was based on something that I implemented in a later version of my frontend (not in the version posted here), wich was a "dataserver" that was running in the backgrund. This was a place for plugins to register its data, thereby making the data available to the rest of the system.
    Other plugins or the frontend (skin) could subscribe to a data or request a data. If data was subscribed the server would notify any subscribers of the change (thereby pushing the data out). If someone requested data then the server would get the newest available data from the source. Doing it this way would allow for data to be polled, pushed and browsed in any combination wanted. I assume this is equivalent to your multiprocess view? Also the when registering data in the server the method for updating the data was also registered so the server could be set to poll the data for you rather having the plugin push the data at a certain interval or the frontend poll it at a certain interval. Of course this beats the purpose of having an event based system but it was just to show that it was possible.

    Quote Originally Posted by justchat_1 View Post
    Not sure what you mean here. The core handling data is exactly what prevents us from breaking old code. Its also how we can guarantee lots of different plugins can talk to each other without having any idea what kinds of methods, or controls or code they contain.
    Sorry my bad, with core I meant Framework. And I think I don't fully understand the difference between the framework and the core.
    The core takes care of data handling and graphics, as the framework contains standard definitions of data (and interfaces) and helper functions, is that correct?
    Failure is not an option...
    __________________________________________________ ______________________________
    The only full multizone / multiscreen cross platform open source Front End -> OpenMobile

  5. #15
    Raw Wave
    Auto Apps:loading...
    justchat_1's Avatar
    Join Date
    Jul 2008
    Location
    Boston, Ma or NY,NY
    Posts
    1,783
    Quote Originally Posted by Borte View Post
    What I meant was based on something that I implemented in a later version of my frontend (not in the version posted here), wich was a "dataserver" that was running in the backgrund. This was a place for plugins to register its data, thereby making the data available to the rest of the system.
    Other plugins or the frontend (skin) could subscribe to a data or request a data. If data was subscribed the server would notify any subscribers of the change (thereby pushing the data out). If someone requested data then the server would get the newest available data from the source. Doing it this way would allow for data to be polled, pushed and browsed in any combination wanted. I assume this is equivalent to your multiprocess view? Also the when registering data in the server the method for updating the data was also registered so the server could be set to poll the data for you rather having the plugin push the data at a certain interval or the frontend poll it at a certain interval. Of course this beats the purpose of having an event based system but it was just to show that it was possible.
    By multi-process i'm talking about threading. The client<->server model your describing works fairly well for passing around data and messages when in a single application. The problem is a system like that would not be usable when you work with plugins. Anytime a new plugin is invented your system would require all the old plugins to be updated so that they knew what the new plugin could do and what types of data it could pass around.
    Quote Originally Posted by Borte View Post
    Sorry my bad, with core I meant Framework. And I think I don't fully understand the difference between the framework and the core.
    The core takes care of data handling and graphics, as the framework contains standard definitions of data (and interfaces) and helper functions, is that correct?
    Yup...the framework is like a toolbox full of things that make it easier for plugins to work well with each other. The core takes care of loading/unloading plugins, rendering all of the controls and visual effects, and passing messages/data around thats it.

  6. #16
    Maximum Bitrate Borte's Avatar
    Join Date
    Jan 2006
    Location
    Norway
    Posts
    443
    Quote Originally Posted by justchat_1 View Post
    By multi-process i'm talking about threading. The client<->server model your describing works fairly well for passing around data and messages when in a single application. The problem is a system like that would not be usable when you work with plugins. Anytime a new plugin is invented your system would require all the old plugins to be updated so that they knew what the new plugin could do and what types of data it could pass around.
    I am talking about threading, the server was running it's own thread separate from the rest of the system. And no change to any old pluging is needed even when you add a new / change a plugin. Registering of data happens dynamically at application startup so nothing is stored / coden in the server. This server also supports talking to applications outside of the frontend itself. All I had to do was connect to the server and all data to / from the frontend/plugins is available regardless of application.

    In fact the whole frontend was multithread, every script action in the skin could be executed in its own thread if needed. Is this the same way in OpenMobile?
    Failure is not an option...
    __________________________________________________ ______________________________
    The only full multizone / multiscreen cross platform open source Front End -> OpenMobile

  7. #17
    Raw Wave
    Auto Apps:loading...
    justchat_1's Avatar
    Join Date
    Jul 2008
    Location
    Boston, Ma or NY,NY
    Posts
    1,783
    Quote Originally Posted by Borte View Post
    I am talking about threading, the server was running it's own thread separate from the rest of the system. And no change to any old pluging is needed even when you add a new / change a plugin. Registering of data happens dynamically at application startup so nothing is stored / coden in the server. This server also supports talking to applications outside of the frontend itself. All I had to do was connect to the server and all data to / from the frontend/plugins is available regardless of application.
    Oh my bad about the threading. I think the problem is were talking about data in the general sense-if i make it more specific hopefully it will be clearer.

    Lets take a playlist for example...in your system we may have a plugin that has a playlist containing a song name, song url and a unique id as three fields. A year from now maybe you decide to change the uniqueid from a short to a double, and add an image field...well now your original plugin has no way to interface with the new playlists unless you rewrite it.

    Lets take another example-this one being more important. Lets say you want to add a movie database as a data provider. Two people work on different plugins and now in order to access movie data you need to know about the formats of both kinds of data. Maybe then another plugin is written and you need to change things again to support the third kind.
    With OpenMobile there would be one definition of movie data, and it would have the fields that all three plugins needed. So no matter what is added down the line, plugins written now will always be able to display movie data.

    Quote Originally Posted by Borte View Post
    In fact the whole frontend was multithread, every script action in the skin could be executed in its own thread if needed. Is this the same way in OpenMobile?
    Yea

  8. #18
    Maximum Bitrate Borte's Avatar
    Join Date
    Jan 2006
    Location
    Norway
    Posts
    443
    Quote Originally Posted by justchat_1 View Post
    Lets take another example-this one being more important. Lets say you want to add a movie database as a data provider. Two people work on different plugins and now in order to access movie data you need to know about the formats of both kinds of data. Maybe then another plugin is written and you need to change things again to support the third kind.
    With OpenMobile there would be one definition of movie data, and it would have the fields that all three plugins needed. So no matter what is added down the line, plugins written now will always be able to display movie data.
    I do agree that when using a server like I have done would cause the skin programmer to specifically know what kind of data to expect and vice versa. And I definitely agree that this might cause version specific solutions / problems down the line. But I don't quite see the difference between this system and what OpenMobile is built on.
    A movie database structure in OpenMobile is defined in a specific way now which is fine for keeping future compatibility, but what if the defined data structure doesn't fit the use from one location to another?
    An example here would be the gas prices data which has the fields regular, super and premium in us, but are completely different in Europe (In Norway they are 85, 95, 99, I donít know about the other countries). Then the data structure would be off already from the beginning. Thatís why I think it would be wise to have the data structures definable from the data provider itself. I know that you said that you could just expand the current structures and keep the original data fields as not to break compatibility but it would require an update of the framework every time extra data had to be added (like the gas prices). I just think it's hard to come up with all the different scenarios at this time.
    Failure is not an option...
    __________________________________________________ ______________________________
    The only full multizone / multiscreen cross platform open source Front End -> OpenMobile

  9. #19
    Maximum Bitrate Borte's Avatar
    Join Date
    Jan 2006
    Location
    Norway
    Posts
    443
    What if data structures was a suggestion rather than a demand? What I mean is that if you wanted to provide data / commands that the system could react to and control then the format had to be according to a default definition. But if it was accepted that a "skin" could be version specific then the data could be defined outside of the default scope.
    Failure is not an option...
    __________________________________________________ ______________________________
    The only full multizone / multiscreen cross platform open source Front End -> OpenMobile

  10. #20
    Raw Wave
    Auto Apps:loading...
    justchat_1's Avatar
    Join Date
    Jul 2008
    Location
    Boston, Ma or NY,NY
    Posts
    1,783
    Quote Originally Posted by Borte View Post
    I do agree that when using a server like I have done would cause the skin programmer to specifically know what kind of data to expect and vice versa. And I definitely agree that this might cause version specific solutions / problems down the line. But I don't quite see the difference between this system and what OpenMobile is built on.
    A movie database structure in OpenMobile is defined in a specific way now which is fine for keeping future compatibility, but what if the defined data structure doesn't fit the use from one location to another?
    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.
    Quote Originally Posted by Borte View Post
    An example here would be the gas prices data which has the fields regular, super and premium in us, but are completely different in Europe (In Norway they are 85, 95, 99, I donít know about the other countries). Then the data structure would be off already from the beginning. Thatís why I think it would be wise to have the data structures definable from the data provider itself. I know that you said that you could just expand the current structures and keep the original data fields as not to break compatibility but it would require an update of the framework every time extra data had to be added (like the gas prices). I just think it's hard to come up with all the different scenarios at this time.
    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).

Page 2 of 3 FirstFirst 123 LastLast

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
  •