Difference between revisions of "GUI Themes/TODO"

Jump to navigation Jump to search
1,727 bytes added ,  12:52, 1 December 2006
Move and update from common TODO
(Added note about the font renderer and BDF fonts)
(Move and update from common TODO)
Line 6: Line 6:


== To Do ==
== To Do ==
* EditableWidget: Make it possible to specify a min/max length for the text
* EditableWidget: Let setEditString filter the string it gets
* EditableWidget: Right now, custom filtering requires the user to subclass; it would be nice if there was simply a "validator hook" or so. Maybe take some inspiration from Java's Swing in this matter.
* Add a new "options" dialog which is used by all frontends: for this, we'd agree on a hotkey used in all engines to invoke that dialog; it would sport settings for the volume, graphics, paths, etc.; it would co-exist with the engines "native" option dialogs. The about dialog would be reachable from here, too, as well as a quit button. Justification: This ensures that all settings are really reachable from all of the engines, which is not the case currently. Problem: It's not fully clear to me how to "best" deal with global vs. local settings here...
* There is currently no way to unset the SoundFont from the GUI, if any was set. Maybe add a 'clear' button for it? The same holds for other path settings.
* ScrollBarWidget: Add auto-repeat: if user clicks & holds on one of the arrows, then after a brief delay, it should start to contiously scroll.
* AboutDialog: Add a "fade" effect for the top/bottom text lines
* AboutDialog: Maybe prerender all of the text into another surface, and then simply compose that over the screen surface in the right way.
* Add tab-focus support, i.e. make it at least possible to use the "tab" key (and also "shift-tab" to cycle through the edit fields.
* Even nicer would be general "tab cycle" support, allowing tab to cycle the focus for all items where it makes sense (buttons, checkboxes, etc.), to make the GUI fully keyboard controllable
* Fonts
* Fonts
** The BDF fonts can have characters that are both wider and taller than expected. For instance, the letter Ã… extends one pixel above the top of the line. This can lead to glitches since we update the screen based on font height and character width, not bounding boxes. The List widget is one example of this.
** The BDF fonts can have characters that are both wider and taller than expected. For instance, the letter Ã… extends one pixel above the top of the line. This can lead to glitches since we update the screen based on font height and character width, not bounding boxes. The List widget is one example of this.

Navigation menu