[E-devel] EWL Developments

[Nathan Ingersoll]

As promised, here's a look at what the current development plan is for EWL.

Constructor API:
I have never liked the parameter inconsistency in the widget constructor calls, but have been content to support them as people are used to it from other toolkits, and it can save them some extra lines of code. As part of a general cleanup, dan and I decided that we valued API consistency over the minimal savings in lines of code. So constructors such as ewl_entry_new(char *text) become ewl_entry_new(), and followed by a call to ewl_entry_text_set(Ewl_Entry *entry, char *text) to set it's text. A fixed number of parameters to a constructor is also more consistent with Evas and Edje. The API conversion is almost complete with just a couple widgets remaining that are undergoing further work.

Tree container:
There have been complaints about the ease of retrieving data from the current list design. The idea of the original design was to depend on the end programmer to maintain their data, and maintain row pointers when necessary to alter the tree. Unfortunately, there is a tendancy to want to iterate over the tree accessing it's members for data manipulation. This also required a series of widgets to be created for each row in the tree. Most of the major toolkits that I've seen or used the API's for (Swing, GTK+, QT) have addressed the tree problem by using an MVC pattern, which pushes the user to worry more about their data maintenance and less on walking the widget structure.

After much thought put into how we could improve performance and data manipulation on the EWL tree, it seems the inevitable approach is to use an MVC pattern as well. But we've seen some things in other APIs that we would like to avoid. First, allow mixed data types within a column. Second, make the simple case simple by providing sane defaults and easy methods for overriding to more powerful methods. Lastly and primarily, we want to maintain the use of arbitrary widgets in the tree. If a generic widget has been implemented, I see little reason to prevent that widget from being displayed in a tree.

So the proposed API would consist of a tree, similar in internal layout to what we have now (header, scrollpane, branch points, rows and cells), but the exposed API would allow for using standard container functions, as well as attaching arbitrary data to the tree with methods for calling back to the data model to receive the row data for display. The tree would accept a series of data provider handles, these handles contain methods for retrieving data from the arbitrary data type when passed a row and column index. Along with data retrieval, a handler must provide a method for creating a widget for display, and a method to set the data on that retrieved widget.
    Ewl_Widget *(*widget_get)();
    void *(data_get)(void *data, int row, int column);
    void (*widget_data_set)(Ewl_Widget *widget, void *data);
So internally, the tree would use data_get to retrieve data for a row/column index, if data is returned, it would then request a widget to display the data via widget_get, and set the data on the widget with widget_data_set. There should also be methods for retrieving the number of rows in the tree, optionally flagging fixed height rows, enabling and disabling the headers and scrollpane, and flagging the tree as dirty at various points (rows deleted, size changed, etc). I'll follow up with some sample API's and uses, as this message is getting rather wordy.

Object caching:
The widget model in EWL insists that widgets maintain any visible state requirements within their widget structure and not rely on the underlying theme (Edje/Evas Objects) to maintain it for them. This does incur some extra overhead per-widget, but allows for EWL to play some tricks behind the scenes to reduce the number of objects Evas has to deal with. This should be an overall win from a memory perspective as well as improve the CPU time spent recalculating renders and clipping in Evas. I did complete an implementation of this object caching and saw large improvements, but there would be significant debugging required to consider it safe to add. So I have been slowly merging the features so we can test them in more reasonable stages, while hopefully maintaining stability for applications using EWL.

Text:
dan has recently ported the text widgets to textblock2. This should allow us to fix up some of the problems in the text widget related to blank lines and correctly mapping cursors. This also gives raster more freedom to drop tb1 from the evas code base.

If anyone has questions or comments about any of these developments or anything else EWL related, please reply to the list so we can keep more people in the loop.

Thanks,
Nathan