178
edits
m (Add TODO Infobox.) |
(→Dialogs: Showing hidden files is already possible.) |
||
(8 intermediate revisions by 4 users not shown) | |||
Line 33: | Line 33: | ||
* PopUp widget (aka drop-down list) | * PopUp widget (aka drop-down list) | ||
** get mock-up from Krest | ** get mock-up from Krest | ||
* Scrollbar widget | * Scrollbar widget - The handle leaves trails in 320xY resolution. Possibly, the shadow of the handle is drawn too wide. | ||
** Can't replicate in latest git master. Fixed by 1b2485f4af2010f262bd4f6e149a8c2d96b893cc? | |||
* Add a new "BoxWidget" / "GroupBoxWidget", which can be used to group other widgets | * Add a new "BoxWidget" / "GroupBoxWidget", which can be used to group other widgets | ||
** This widget makes it easy to group widgets and control them together; e.g. disable the box widget, and all children get disabled, too | ** This widget makes it easy to group widgets and control them together; e.g. disable the box widget, and all children get disabled, too | ||
Line 72: | Line 72: | ||
** [Classic theme] Text seems to be drawn over the dialog frame. At least at the top of the 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. | ** The grey text (color 2, kStateDisabled) is hard to read in both the new and the classic theme. | ||
*** Reported as {{Tracker|id=5833}}. Fixed in Modern by fee19d. Fix for classic still needed? i.e. make lighter there as background is black (as opposed to Modern, which has almost white background). | |||
** Add a "fade" effect for the top/bottom text lines | ** Add a "fade" effect for the top/bottom text lines | ||
** Maybe prerender all of the text into another surface, and then simply compose that over the screen surface in the right way. | ** Maybe prerender all of the text into another surface, and then simply compose that over the screen surface in the right way. | ||
Line 79: | Line 80: | ||
*** Alternatively, add "Reset to Default" buttons to each path setting, possible similar to the one used with the soundfont (which is a rather too cryptic, IMO) | *** Alternatively, add "Reset to Default" buttons to each path setting, possible similar to the one used with the soundfont (which is a rather too cryptic, IMO) | ||
** Several texts, e.g. vcMusicText, have their alignment set to kTextAlignRight, but are still drawn as left-aligned. | ** Several texts, e.g. vcMusicText, have their alignment set to kTextAlignRight, but are still drawn as left-aligned. | ||
** Add ability to adjust debuglevel (int). Useful for command line less ports i.e. Android. | |||
* Engine Options Dialog | |||
** Currently only bool (checkbox) options are supported. Add support for int (slider) options. Needed for: | |||
*** walkspeed (int) | |||
*** gfx_details (int - SWORD2) | |||
*** t7g_speed (int - GROOVIE) | |||
** reverse_stereo (bool - SWORD2) is also currently missing. Make this a global option as it is likely to apply to a number of engines? | |||
* 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. | * 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. | ||
* File browser dialog | * File browser dialog | ||
** Right now we "visualize" that an entry is a folder/directory by appending a slash "/" to the name. This is not really intuitive for non-Unix users. Maybe we could add small file / directory icons? And maybe also an up-arrow for the "up" button. | ** Right now we "visualize" that an entry is a folder/directory by appending a slash "/" to the name. This is not really intuitive for non-Unix users. Maybe we could add small file / directory icons? And maybe also an up-arrow for the "up" button. | ||
=== 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. | ||
* Antialiased fonts | * <s>Antialiased fonts</s> | ||
** 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. | ** <s>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.</s> | ||
*** 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. | *** <s>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.</s> | ||
*** | *** <s>It's *still* possible to use 1bpp fonts for antialiasing, by implementing 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.</s> | ||
=== Collaborative work with the OpenUsability Project === | === Collaborative work with the OpenUsability Project === | ||
Line 123: | Line 130: | ||
Probably there will be some optimisations in loadAll() method, which will malloc one big chunk of those vars, and since we have their keys as ''const char *'', then it can alloc one big chunk for variables name as well and then pass pointers inside of it to respective members. Of course, that will be specially flagged as it will not be possible to free() any of those chunks deliberately. | Probably there will be some optimisations in loadAll() method, which will malloc one big chunk of those vars, and since we have their keys as ''const char *'', then it can alloc one big chunk for variables name as well and then pass pointers inside of it to respective members. Of course, that will be specially flagged as it will not be possible to free() any of those chunks deliberately. | ||
edits