DataEFLFindings
I had a bash at making an app with similar functionality to that of the Psion Series 5's Data application, so far it just supports opening, simple searching and modifying the first table within an sqlite file.
The main aim of doing this was to experience the application creation process using EFL and the suitability for creation of keyboard friendly applications.
Source: https://github.com/gemian/gka-data-e/
The following feedback is intended as constructive criticism, I was using the latest development EFL as a base so it is hoped issues found here can be fixed before the next public milestone release.
The EFL has all the bits needed to make fully featured applications, from menu's to file pickers, lists and text entry boxes. The API's are easy to work with.
I found that scrolling views in popup's refuse to take the minimum size hints and snap themselves shut, so to fix this the file open dialog is using a window where the size can be set. The label preferences dialog uses the action buttons along the right hand side to force the dialog to be big enough to show the list of contents.
I found that popup's don't always take the focus with them, so ended up making a focus stack containing both the popup and an initial focus item for the popup. I use this to set the focus on input boxes/lists as appropriate on both the showing and dismissal of the popup. The list box also has some quite crazy stuff going on with focus display in terms of adding/removing/moving list items about underneath it.
Note: There are console error messages about things not being right with the focus manager, I couldn't find any focus manager API's to be using and was following the pattens of API usage from EDI (the EFL IDE), so I think they are a problem internal to EFL rather than caused by miss-use of the API's.
Buttons don't respond to the keyboard at all, when enabled in the focus tree they can gain the focus highlight but enter/space don't activate them at all. They have been disabled from receiving focus.
Keyboard shortcuts have been added by disabling focus on all items but one per screen/dialog and then using a key press callback to detect and handle key presses.
It would be much better to have a new API to assign a keyboard short cut to each button. Also adding a theme option to display this shortcut on the buttons themselves for easy user feature discovery.
The menu doesn't respond to the keyboard at all, at a minimum the arrow keys/enter should let you navigate it, alt to open/close it. It would also be good if it was possible to follow the usual Linux practice of underlining the letter that Alt+[] will cause it to be activated. It could be an option in the theme to make this visible to the user or hidden. Likewise in the case of buttons a Ctrl+[] should be assignable and again the theme should have an option to add this to the display of the menu item for easy user feature discovery.
I've added hopefully temporary hacks to support keyboard menu navigation, Alt opens/closes the menu, and arrow keys let you navigate, Return selects the item. If you open the menu with the mouse and then again with the Alt key then it gets a little confused.
The underlying EFL is still in its feature development part of the cycle so the fact that valgrind reports plenty of leaks is only mildly worrying. Its also possible that the leaks are caused by miss use of the API's, which would make them a documentation bug as I'm fairly certain I'm doing the described level of tiding up.