Announcement

Collapse
No announcement yet.

Developers Discussion

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Developers Discussion

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

    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.
    Failure is not an option...
    __________________________________________________ ______________________________
    The only full multizone / multiscreen cross platform open source Front End -> OpenMobile

  • #2
    Originally posted by Borte View Post
    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 View Post
    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.
    openMobile - An open source C# Front End (why choose openMobile?)
    - Always Recruiting Developers -
    Like what you see? Donations are always welcome

    Comment


    • #3
      Originally posted by justchat_1 View Post
      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.
      Attached Files
      Failure is not an option...
      __________________________________________________ ______________________________
      The only full multizone / multiscreen cross platform open source Front End -> OpenMobile

      Comment


      • #4
        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.
        openMobile - An open source C# Front End (why choose openMobile?)
        - Always Recruiting Developers -
        Like what you see? Donations are always welcome

        Comment


        • #5
          Originally posted by justchat_1 View Post
          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 View Post
          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 View Post
          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.
          Failure is not an option...
          __________________________________________________ ______________________________
          The only full multizone / multiscreen cross platform open source Front End -> OpenMobile

          Comment


          • #6
            Originally posted by Borte View Post
            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 View Post
            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 View Post
            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.
            openMobile - An open source C# Front End (why choose openMobile?)
            - Always Recruiting Developers -
            Like what you see? Donations are always welcome

            Comment


            • #7
              Originally posted by justchat_1 View Post
              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 View Post
              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?
              Failure is not an option...
              __________________________________________________ ______________________________
              The only full multizone / multiscreen cross platform open source Front End -> OpenMobile

              Comment


              • #8
                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.
                - Project: Unified Car Control
                - Original OpenMobile Interface Designer

                Comment


                • #9
                  Originally posted by Borte View Post
                  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.
                  openMobile - An open source C# Front End (why choose openMobile?)
                  - Always Recruiting Developers -
                  Like what you see? Donations are always welcome

                  Comment


                  • #10
                    Originally posted by justchat_1 View Post
                    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
                    Failure is not an option...
                    __________________________________________________ ______________________________
                    The only full multizone / multiscreen cross platform open source Front End -> OpenMobile

                    Comment


                    • #11
                      I moved the discussion to a new thread...

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

                      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

                      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.
                      openMobile - An open source C# Front End (why choose openMobile?)
                      - Always Recruiting Developers -
                      Like what you see? Donations are always welcome

                      Comment


                      • #12
                        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...?

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

                        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:
                        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.

                        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

                        Comment


                        • #13
                          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.

                          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)

                          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).
                          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.
                          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.
                          openMobile - An open source C# Front End (why choose openMobile?)
                          - Always Recruiting Developers -
                          Like what you see? Donations are always welcome

                          Comment


                          • #14
                            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.

                            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

                            Comment


                            • #15
                              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.
                              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.
                              openMobile - An open source C# Front End (why choose openMobile?)
                              - Always Recruiting Developers -
                              Like what you see? Donations are always welcome

                              Comment

                              Working...
                              X