27 April 2003
This document was written to explain the current status of eboxy, where it is headed in the future and what needs to be done in order to get there. It should highlight some of the important issues that need to be considered in development and eventual use of future versions of the application. It also gives potential developers an idea of what they might be able to work on, should they wish to assist the project.
At the start, eboxy was simply a GUI shell used to launch other applications, and for the most part this is still the case. In general, the idea is to rely less and less on external applications and build more of the required functionality for a set-top box into the application (as plugins), while still providing a small core application that can be customised and used for other purposes. An important goal to keep in mind is to provide advanced functionality to the user without forcing dependent applications upon them that are difficult to install and/or set up.
Hobbyists - people who are building their own set-top boxes or other devices that require a simple GUI. Currently these people would be fairly experienced Linux users as the entry barrier is high (see below), but will definitely appreciate efforts to make things easier for them.
Developers - people who are developing a commercial set-top box or open-source application using eboxy. These types of users are likely to be experienced Linux users and are less likely to be worried by having to edit configuration files, etc.
End users - once eboxy becomes more user-friendly and easy to set up, more users may be interested in using eboxy. Currently, end user exposure is limited to those who use eboxy-based systems set up by one of the two aforementioned groups.
Following are some of the problems which face eboxy in its current form. In some cases solutions are suggested; in other cases, no solution is immediately apparent.
Adding new widgets is difficult. You have to write a new widget, write a wrapper class for it, change the eboxy code to make it recognise the new class, add code to the skin parser, and modify the XML DTD.
There is widget-specific code in main.cpp for handling widget input. This needs to be abstracted out back into the widget wrapper classes.
Adding properties to widget wrapper classes could be easier. For this, objects and lists should be used rather than flat code.
Adding command line options could be easier. A single array containing short, long, and description fields would be useful here.
Lists should be based on a dynamic type list that receives notifications when an object is freed.
The current method of plugins creating named objects means that you can't have (for example) two filebrowsers on one page.
Plugin properties and methods do not have very clean string handling. Some functions return constant strings; others need to allocate and build them up, returning a string which (because it is const char *) is never freed. This results in memory leaks.
The current scripting system is simple; in particular it has no looping and no conditional statement. This has not yet presented a serious problem, and the current solution has been to move anything that needs these elements into a proper plugin written in C.
The existing SDL_gui GUI library is limited and outdated. It causes installation hassles for end users, does not have broad enough widget support, and lacks proper back-to-front drawing which means that overlapping two or more widgets doesn't work properly.
However, using another library requires significant changes. These include:
Some things that might motivate the choice of library:
Clearly, changing GUI library is going to cause major upheaval - it is unlikely that existing skins will be able to be made compatible.
There is a high entry barrier for eboxy right now. You have to compile the source, install the app, set up a skin, and combine it with other applications to get a working system. The ideal would be to have two versions: the developer version, which is completely customisable; and an end-user version, which would be a binary kit of components with a default skin. This would require a decent skin, as well as some way to make features that aren't available invisible. Also, some way of configuring remote buttons and other settings easily would be useful.
One idea which would help out with this would be to create some sort of integration plugin, which would auto-generate menus on the fly depending on what "modules" were installed. Modules would consist of plugins and enough information to tie them together at runtime. Note that this would be separate from the look and feel and would depend heavily on some aforementioned core changes to the way the UI is generated.
With an integration system, the user would be freed from having to edit the XML file to enable new plugins - they would just install them into the system and new functionality would immediately appear. Of course, it would be difficult to get this to work and still allow a lot of flexibility, so quite a bit of thought needs to be put into this.
This would require borrowing code from MythTV or other projects. There is simply not the time to write this all from scratch when it has been done so well. However, there is some merit in writing a separate scheduling library (see below) which would enable the use of external capture utilities.
Radio would be best implemented by creating a plugin to control fmio, which is the most comprehensive application for controlling radio devices. However, it would also be worth examining the fmio code to see if it is worth porting in as a plugin instead.
This needs an interface. A plugin to control cdda2wav or similar should be sufficient.
For adequate library functions a database is needed, or at least a way of storing metadata in flat files. eboxy is hampered by the fact that it does not have a grid widget.
Automatic generation of playlists (by voting or querying by characteristics) would be good.
Integration with XMLTV. Again, lack of a grid-type widget makes building a GUI for this difficult. XMLTV is difficult to install, so other back-ends/data sources should be supported.
A separate code library which can be used by applications to schedule tasks, such as recording live TV or radio. It would take care of conflicts and concurrent tasks, and rely on cron/at to carry things out (no point in reinventing the wheel here). This could be reused for all sorts of things.
Lack of capability in the existing GUI library and associated code in eboxy is holding back development of eboxy as a mature application from an end-user's perspective. So it is clear that major changes to the core of eboxy are required in order to progress forward. The first and foremost of these changes is to find a capable and currently maintained GUI support library. The second is to use this library to allow on-the-fly generation of user interfaces at runtime.
A side project which will be useful is a scheduling library, that will be useful not only for scheduling recordings in eboxy, but also as a reusable library in its own right. This would immediately allow for the use of external video capture and radio recording utilities.