Refactoring Ideas
From The Neuros Technology Wiki
Contents |
[edit] What ideas do we need ?
As detailed in the "Refactoring OSDmain" OdNT post, Neuros wants to lay down a plan to refactor and to a certain extent redesign both osdmain and Neuros-Cooler in a way that will make it easier, somewhere down the road, to remove Neuros-Cooler and to replace it with another toolkit. No toolkit suggestions or trolling here please. we do not yet know which toolkit will be used, and frankly at this stage it's too early to even care.
Any idea and suggestion that can increase the separation of functionality and presentation (GUI) is welcome, as well as general suggestions on making things less monolithic so that the process of switching can be done incrementally.
[edit] How to add your contribution
Please be respectful of contributions of others, and put your signature with timestamp (two dashes "-" and four tildes "~" will make it appear automatically). Like this: --Nerochiaro 17:36, 3 March 2007 (CST)
I hope this won't turn in to a mess, in which case we'll figure out something else to get this rolling along better.
[edit] Deadline
Presumably this will continue to evolve to some extent, but some level of closure is expected on the IRC meeting on Mar 17, 2007
[edit] Ideas
[edit] osdmain
- Model View Controller architecture: where possible, we should strive to follow the MVC pattern to abstract input and GUI from the actual functionality and logic of the application. For introduction on MVC pattern: [[1]]. Originally proposed by may1937 --Nerochiaro 17:36, 3 March 2007 (CST) --May1937 13:29, 4 March 2007 (CST) For a brief and decent introduction to the MVC design pattern, see wikipedia. For an example of this see the item in the examples section at bottom of this page.
- Nano-x based Window Manager: Michael Gao is working on this, it will allow multiple apps to run at the same time (although only one app full screen at a time, which is ok for OSD usage patterns). This allows the following point, splitting osdmain in multiple apps. --Nerochiaro 17:36, 3 March 2007 (CST)
- Split into multiple apps: once the WM is in place, we can split osdmain in smaller apps, for example video player, audio player, settings panel, image browser and so on. this will allow each one sub-app to be ported independently of the others if needed. --Nerochiaro 17:36, 3 March 2007 (CST)
- OSDMain as Desktop application: once the WM is in place, and applications split from osdmain into smaller apps OSDMain becomes a desktop/icon/shortcut manager used to start the individual programs. --Crweb 02:06, 4 March 2007 (CST)
- Abstraction for configuration/settings screens: this will remove the repetitive (and error prone) code that is currently needed for all the settings screens and push them into a common config screen. The idea is to create a data structure that is passed to a single generic config screen builder. The config screen builder constructs and manages configuration of settings. --Sourcerror 22:14, 3 March 2007 (CST) --Nerochiaro 05:14, 4 March 2007 (CST) This might not be possible for all config screens, but for most of them it will work.
- Coding standards (indentation/spacing) --May1937 13:29, 4 March 2007 (CST) There is also a big problem with inconsistent indentation. People are mixing tabs and spaces, and there is no rhyme nor reason to where brackets are placed. This makes the code less readable and certainly looks less professional. --Nerochiaro 03:27, 5 March 2007 (CST) This was discussed long on ML and I think it was made clear by Gao that discussion that this is never going to be fixed, and we should learn to live with it (unless someone whips up pre-commit SVN scripts that beautify/standardify code)
[edit] Neuros-Cooler
- Split into task-specific libraries: cooler right now is made up of a GUI toolkit, functions to access media, and lots of miscellaneous utilities. We should cleanly split cooler in at least three, possibly more libraries, by functionality. --Nerochiaro 17:36, 3 March 2007 (CST) More specifically the libraries should not depend on each other. For example applications that use only cooler utils and no GUI don't have to ship cooler GUI libs. --Crweb
- Removal of NMS functions from Cooler: cooler right now contains nms-client and other functionality suited better for the Neuros Media Sever. Need to decide which is is going to be, Media functionality in Cooler, or in NMS. -- Crweb 02:09, 4 March 2007 (CST)
- Consistency in API function names: add a cooler prefix (specific to the sub-library, e.g. coolerUI, coolerMedia) to functions, global variables, enumerations, and #defines. This will go a long way to helping others navigate and use the cooler API even where there is no good documentation. It also helps avoid name collisions. --Sourcerror 22:14, 3 March 2007 (CST)
- Full utf8 support: (presumably starting by adding appropriate fonts). This is useful for people (like myself) who are multilingual and deal with non-ascii7 filenames as well as international markets. If utf8 support isn't there now, it should be added (unless we're to drop the toolkit at some point) --Pgunn 00:30, 4 March 2007 (CST) --Nerochiaro 05:11, 4 March 2007 (CST) Most other toolkits already support this, so adding this to cooler will make it easier when we transition.
- Focus manager (within Forms): cooler has currently no way to automatically move focus among widgets within the same Form (kind of like the TAB key generally does it in desktop applications). adding this to cooler will remove from osdmain a lot of repetitive (and error prone) GUI code that is currently needed in all Forms. It will make transition easier since all toolkits basically have this support already (and much less code to port inside osdmain) --Sourcerror 22:14, 3 March 2007 (CST) --Nerochiaro 05:11, 4 March 2007 (CST) Edited for clarity and moved to cooler section.
[edit] Examples
[edit] Model View Controller architecture
By breaking apart the GUI display code, and the code which manages the data it is displaying, we will have a MUCH easier time in the future when and if we decide to change toolkits. From a very high level, the idea is to break up the code into three separate subsystems: the model (which knows how to store and modify data), the view (which knows how to display data stored in the model, and how to update the display when the model changes) and the controller (which responds to user events and updates the model). If the code is properly isolated, when a toolkit change is mandated, the only code which will have to change is the view, and possibly the small portion of the controller which handles toolkit-specific bindings to events. For a specific example, I will use the file nw-statusbar.c in linux-r3-main-app/osdmain/src/ui. This is somewhat contrived since the code is so simple, but even in this case we have a situation where separating the display code will facilitate future maintainability. OnTimer1Timer() - The controller would initiate this change and would set a new time value in the model. This change would be reflected the next time the view examines the model and decides what to draw. CreateFormStatusBar() - The display code would belong in the view's initialization of this display mode, responding to the contoller's signal to bring up this display. Again, the setting of the time would need to be moved the controller, but the data would reside in the model. The toolkit-specific data which is initialized here, such as picture1, label1, etc, belong in the view. Even though it is technically data, it is intrinsically tied to our specific toolkit, and we need to separate that from both the model and controller. The rest of the functions in the file would need to be split into a controller and view portion. Again, the controller initiates the view calls when responding to a user action, and the view just does whatever toolkit-specific function is necessary. --May1937 13:29, 4 March 2007 (CST)
