EWL Development Ideas

We historically used the bug tracker for discussing development ideas. More of the general discussion should be moved to this page, and only finalized actionable plans submitted to the bug tracker.

The bug tracker server crashed but xcomp was able to recover the data from the drives, it is working well now.

Planned / In Progress

Stuff that is currently being worked on, or needs to be done at some point in the near future.

Text Widget Optimization

While working on an IO manager, Peter found that repeatedly appending and modifying text in ewl_text can trigger poor performance. This is primarily because the formatting tree essentially turns into a long linked list with extra nodes, because it doesn't rebalance.

Ideas to explore:

• Change the tree to rebalance (difficult without tracking node indexes as keys)
• Cached index walking
• Reduce temporary allocations or move to alloca.
• Use a skip list to track the nodes (may have the same problem as the balanced tree, but seems easier to overcome)

Cached walking

The current tree code always walks from the current position. It doesn't bother to try to walk from the start/end of the list. We may want to add this but the formatting is now pretty fast. Might not be worth the complexity. Would need to do some testing and determine if it's going to buy us much.

Skip List

21:22 < dj2> i don't think a skip list will work....

21:22 < dj2> you don't store extra nodes per leave

21:22 < dj2> just that each node has extra pointers to different parts

21:22 < dj2> which means we don't have the rollup lengths

12:47 <@RbdPngn> dj2: not sure I follow

12:59 <@RbdPngn> my line of thinking was that each node had an id for a key

13:00 <@RbdPngn> just so you can easily identify it for debugging

13:00 <@RbdPngn> and contain a length

13:01 <@RbdPngn> when searching for a position in the skip list, keep a stack of the last node traversed at each level

13:02 <@RbdPngn> if you change the length at the bottom level, walk back up the stack and modify each of the nodes in the stack to adjust for the change in length

Example with nodes depicted as (position, length), position would be calculated, not stored for each node:

In preparation of the skip list conversion, dan has committed a patch to convert the text formatting tree to a doubly linked list which should be more similar to the way the skip list will work. Also, Nathan and Brian have each created basic implementations of the skip list hybrid structure that will be necessary.

• Nathan's skip list: http://ningerso.edevelop.org/files/skip.c
• Brian's skip list: http://fiona.rephorm.com/files/skip2.c

Each was written with the same goals in mind, but were done independently in order to have some different input in how to structure and implement the code. These will need to be reviewed and appropriate features selected for the text formatting skip list.

There is a bug present in both implementations. If a node is inserted at the leaf node level, and the probabilities determine that it should be present higher in the list, then node splitting must occur higher up. Brian's implementation does not perform the splitting, it just adds the length to the parent, while Nathan's performs the splitting but does not assign the correct child to the new nodes. Part of the problem with the splitting is that it can result in two new nodes in a parent list when in a traditional skip list, only one would have been added. This could quickly result in the parent lists becoming the same length as the leaf node list, which nullifies the advantages of a skip list, and in fact is worse than a doubly linked list because of the extra memory allocated. A proposed solution is to generate a second random number and use the combination of random numbers to determine how to split the parent list nodes. Brian sketched out the four possible results of this test and posted the results: http://fiona.rephorm.com/files/skip_example

In addition to this bug, neither implementation provides code for deleting nodes from the list. This will be necessary for the text to be able to remove formatting information.

Tree2 Updates

Ewl Tree2 Thoughts shows what we're thinking of changing the API to for the models and views it better work with the tree.

Optimizing

As part of the optimization work, we also need to implement an internal box that will only create widgets for the visible region of the tree, and cache the height geometry for the rest. This box will also destroy widgets as they get obscured. This is more overhead for a redraw, but greatly reduces the load for large numbers of entries in the tree.

Freebox

Ewl_Freebox has a lot of the features of Ewl_Iconbox. Any missing iconbox features need to be ported over to freebox so we can eventually remove Ewl_Iconbox from the system.

The missing features include:

• Selection support
• Menus per icon

UI Translations

We will eventually need to build multi-language capabilities into EWL. We're currently holding off on this until EWL is a lot closer to release. The reason for this is that we still change and tweak the internal strings and we don't want to burn the translators out fixing everything we change.

Also, we want to get it in place correctly. The system will need to be able to handle EWLs internal translations along with allowing the users application to specify their own translations.

This will probably end up being done with gettext but we'll need to investigate further to decided what's the best route to take.

Combo

There is currently only one way how the combo presents its data. The popup is fit to its content and doesn't care about the size of the base. When you select one item it'll be the new header. The idea is to collect here all possible or for EWL relevant possibilities and then to decide how to implement them (as a mode, as different widget, as a subclass etc.).

Here is a list with some ideas, please feel free to add suggestions.

• a uri, font etc. list: the width of the pop-up is the same as the width of the base. If the list is to long to fit on the desktop (or another user set size) there'll be a scrollpane so can scroll through the content. If you select one item it will be the new header.
• a undo/last button + list: the pop-up is in most cases wider than the base. If you select a item the undo/last button will stay.
• perhaps also the way it is at the moment.
• i probably missed some :)

I'm not exactly sure what you're looking for here. You want different ways to present the combo data? I think what needs to happen is: We allow the user to specify the header as being static so it'll never change. (This takes care of your undo/last button). We need to allow the combo dropdown to be wider then the combo box itself. This might be done when the user sets a max size on the combo? We need to put the combo contents into a scrollpane. Then, when the combo is > then say 100px (or some theme defined size) we show the scrollpane. These changes should give us all the items you listed above and cover most ways the combo should work. (It also needs a new theme, heh.) User:dj2

We can support two ways of sizing the dropdown, one way is to fit it to the combo size and the other is to let the dropdown take the size it needs. Do we want, in the first case, to set the preferred size of combo to the size of the dropdown if this is greater? To directly set the maximum size of the popup is not possible (from the user view), but we could provide a function to do this (e.g. ewl_combo_popup_maximum_h_set()). I think a maximum size from the theme isn't a good idea, but IMHO we can care for that the popup is not bigger than the available place. I'm not sure if the submenus will still work with a scrollpane (I don't know if they work atm). But anyhow we need a scrollpane. And you are right a new theme would be nice :) Pfritz 13:27, 14 November 2006 (MST)

Ok here are some ideas, how that could look code-wise.

void ewl_combo_static_header_set(Ewl_Combo *c, int sh);
int ewl_combo_static_header_get(Ewl_Combo *c);
void ewl_combo_scrollable_set(Ewl_Combo *c, int sc);
int ewl_combo_scrollable_get(Ewl_Combo *c);
void ewl_combo_popup_fit_to_header_set(Ewl_Combo *c, int fit);
int ewl_combo_popup_fit_to_header_get(Ewl_Combo *c);

Besides that we can now use a context menu instead of a popup widget. So we could easily provide expandable combo entries. I'm not sure though, how that works with MVC, but since the tree2 is using it, it should be possible. We only need to change the appearance of the context menu and of the menu entries and maybe some other tweaks. Pfritz 07:08, 8 March 2007 (MST)

Context Menu

The current way to have a context menu (like in iconbox and filepicker) are more or less hacks and anything but comfortable. It would be nice to have an easy-to-use context menu widget. It could inherit from ewl_popup, so we have the smart placing (Ewl_Popup need some tweaks for that, but nothing difficult) and we can get the submenu nodes to popup up if we (ab)use the menubar mechanism, i.e. we set the Ewl_Menu::menubar_parent to the context menu. That should work fine. The API would only give two functions to add or to remove active areas, i.e. areas where the menu will popup on right click.

If this all will work, we can then reuse the context menu inside the normal menu instead of the popup. And we'd solve the current problem of the menu that the submenus don't poupup up on mouse in.

The context menu is now in cvs and is ,as proposed, reused in the menu.

Speculative

Items we're considering working on but have no timeline at the moment.

HTML Renderer

One option is to use WebKit as a basis for the HTML rendering widget. The GDK port is still quite basic and would probably be the easiest place to start.

http://trac.webkit.org/projects/webkit/browser/trunk/WebCore/platform/gdk

Carbon Engine

Would be really cool to implement a Carbon (or Cocoa I guess) engine. Would then be able to, hopefully, get drag and drop to work from apps running on OS X.

Would need a lot of investigation into this, probably writing an Evas engine and an Ecore engine at the same time.

Alternative X11 Engines

For alternative X11 engines, there are a few rendering systems we could look at.

• http://www.gegl.org/
• http://librsvg.sourceforge.net/

Spell Checker

A Spellchecher for Ewl_Entry would be cool. The most common lib therefore is aspell. As far as I have seen, the API isn't really nice, but it is in C and LGPL, so we could use it if we want. Other spell checker libraries with nice and simple API are enchant, it is a wrapper around various spell checkers libraries, downside is that it has glib as dependency. And last but not least hunspell it is used by OOo and firefox, hence it is written in C++, but it has a C API, too.

Completed / In Testing

These items are currently committed into CVS. We've left them here until we're finished testing and are confident they work. Once testing is done they'll be removed from this page.

Toolbar

A toolbar would be a nice thing. And it should be really simple to implement it. The whole placing stuff can be inherit from the box widget, actually I think the best thing is, when it inherits from menubar. Set to it a different appearance; that's it. Next step is to have symbols that can show or hide their text and with a single function call you could hide or show all the labels of the toolbar symbols (can they inherit from icon or is icon even capable of this right now? Or would it be better to inherit from button?). Another nice feature would be to recognice groups of symbols and set the state of them to right, hmiddle or left (or top, vmiddle, bottom) depending of the position of the symbols, then the themer can give them different themes.

Ok, I thought a bit about it. I think a widget inheriting from button would be the best, because the button has the all the feature you need for a toolbar symbol, a label, an image (especially stock symbols). Only the defaults has to be a bit different, e.g. a vbox instead of a hbox for the body, etc. Does this sounds reasonable?

Just for the record: We now decided to use Ewl_Icon for the (toolbar) icons. To also have the stock functionality, we abstract the stock types out and now button and icon do inherit from ewl_stock.

We need to make some enhancements to Ewl_Icon to support this. We'll need to add a couple of flags to the icon. We need a way to specify if the icon has a long label (will have a \n in it), if it does use Ewl_Text, else use Ewl_Label. We also need a way to flag the icon as requiring thumbnailing of the icon. In the case of filedialog and toolbar this would be set to false, other wise (and by default) it will thumbnail the item set into the icon. This should make the icon simple enough to handle the toolbar but still able to handle what iconbox will require.

Tree2 Updates

Expandable rows

Expandable rows have been added, but they build the entire data tree at load time. This is a very heavy-duty approach to the problem and needs to be reduced to the single level.

Also, views should get another callback for fetching sub-views when they are expandable (view->expansion.get) to allow mixing different views across expansion points.

Header handling

There should be header calls in both the model and the view to keep the interfaces consistent. The model should fetch the header data and the view should accept the header data and return widgets.