1,079
edits
Difference between revisions of "GUI Themes/TODO"
→To Do: reordered & structured
m (adding link to the specs page) |
(→To Do: reordered & structured) |
||
| Line 6: | Line 6: | ||
== To Do == | == To Do == | ||
=== General === | |||
* 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 | |||
=== Widgets === | |||
* EditableWidget: Make it possible to specify a min/max length for the text | * EditableWidget: Make it possible to specify a min/max length for the text | ||
* EditableWidget: Let setEditString filter the string it gets | * 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. | * 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. | ||
* ScrollBarWidget: Add auto-repeat: if user clicks & holds on one of the arrows, then after a brief delay, it should start to contiously scroll. | * ScrollBarWidget: Add auto-repeat: if user clicks & holds on one of the arrows, then after a brief delay, it should start to contiously scroll. | ||
* List widget | * List widget | ||
** get mock-up from Krest | ** get mock-up from Krest | ||
| Line 29: | Line 23: | ||
* Scrollbar widget | * Scrollbar widget | ||
** The handle of the scrollbar widget leaves trails in 320xY resolution. Possibly, the shadow of the handle is drawn too wide. | ** The handle of the scrollbar widget leaves trails in 320xY resolution. Possibly, the shadow of the handle is drawn too wide. | ||
** About dialog | === Dialogs === | ||
* 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... | |||
* About dialog | |||
** looks bad. Probably add some shadows and text padding | |||
** fix glitch at the top of the dialog where part of the characters get stuck (see FIXME in about.cpp) | |||
** Chooser aka Add game dialog | ** [Classic theme] Text seems to be drawn over the dialog frame. At least at the top of the dialog. | ||
** The grey text (color 2, kStateDisabled) is hard to read in both the new and the classic theme. | |||
** Add a "fade" effect for the top/bottom text lines | |||
*** Several texts, e.g. vcMusicText, have their alignment set to kTextAlignRight, but are still drawn as left-aligned. | ** Maybe prerender all of the text into another surface, and then simply compose that over the screen surface in the right way. | ||
* Chooser aka Add game dialog | |||
** [Classic Theme] Adjust size and position of the chooser to Launcher | |||
* Options dialog | |||
** 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. | |||
** Several texts, e.g. vcMusicText, have their alignment set to kTextAlignRight, but are still drawn as left-aligned. | |||
** [Classic Theme] Adjust size and position of the "Options" dialog to Launcher | |||
** It would be nice if you could select theme from the GUI. The "Graphics" tab, perhaps? | |||
* Edit game dialog | |||
** [Classic Theme] Adjust size and position of the "Edit game" dialog to Launcher | |||
* Launcher dialog | |||
** Would be nice if the "Add Game..." button label would change to "Mass Add Games..." while shift is held, to give the user visual feedback about the changed behavior | |||
* The sliding action of the debug console takes a lot more CPU now than it used to. On my 450 MHz P3, I don't even see it slide in 2x mode. It seems to appear/disappear all at once. | |||
=== 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. | |||
* Antialiased fonts | |||
** This could be tricky, since the BDF fonts are bitmaps. Is it even possible, within this format, to store the alpha channel needed (?) to represent an anti-aliased glyph? One possibility might be to store a larger version of the font and scale it down to the desired size, but that seems wasteful. | |||
*** BDF fonts aren't suitable here since they're 1bpp. It could be done if font data would be 8bpp and thus, contain just the alpha channel, i.e. shades of gray which will be blended on rendering stage. | |||
*** Fingolfin says: It's *still* possible to use 1bpp fonts for antialiasing, by implemnting oversampling: By downscaling a 4x fold or 8x too big character, one can compute & render the antialiased output on the fly -- this worked even on some old 90 MHz PowerPC Macs, so it should be doable. Main concern would be memory usage, and the need to have a big version of all fonts around. Or we switch to a vector based font system (TrueType plus [http://www.freetype.org/index2.html Freetype]), at the cost of resources and possibly some portability -- we would have to research this a bit. Another advantage of using FreeType: Unicode support in the GUI would be possible. | |||
== Some ideas about theme caching == | == Some ideas about theme caching == | ||