561
edits
Difference between revisions of "OpenTasks"
→GUI: reworked our GUI task, that's my personal opinion of it, feel free to comment on it
(→Generic infrastructure tasks: -- add virtual keyboard and keymapper task) |
(→GUI: reworked our GUI task, that's my personal opinion of it, feel free to comment on it) |
||
| Line 54: | Line 54: | ||
''Background:'' | ''Background:'' | ||
ScummVM implements its own GUI code. We can't use any of the portable GUI kits out there, as they are mostly not portable enough, use too many resources, or simply are not flexible enough to work atop our backend system. Also, our GUI must look equally good with 8bit, 16bit or 32bit graphics, at 320x200, 320x240 or 640x480 resolutions -- and ideally also at 240x200 or at 1280x1024. | ScummVM implements its own GUI code. We can't use any of the portable GUI kits out there, as they are mostly not portable enough, | ||
use too many resources, or simply are not flexible enough to work atop our backend system. Also, our GUI must look equally good | |||
with 8bit, 16bit or 32bit graphics, at 320x200, 320x240 or 640x480 resolutions -- and ideally also at 240x200 or at 1280x1024. | |||
Currently we have a quite flexible system for defining the look and feel of our GUI. Almost every aspect of it can be specified via external theme file described [[GUI_Themes/Specs|here]]. | Currently we have a quite flexible system for defining the look and feel of our GUI. Almost every aspect of it can be specified | ||
via external theme file described [[GUI_Themes/Specs|here]]. Even though it is quite flexible and has proven to stand our needs | |||
it is too complex and hard to use. Also our GUI layout is written in the same config file as the renderer configuration, which | |||
requires custom renderer themes to be manually updated even though nothing on the renderer changed. | |||
Our current GUI implementation has some other downsides too. We handle redraws very inefficient currently, for example | |||
on a single widget change we redraw the whole GUI. Also our pixmap approach is pretty unsophisticated, because of this the | |||
overall renderer efficiency suffers. Last but not least our complete widget handling could be cleaned up and a bit improved. | |||
''The Task:'' | ''The Task:'' | ||
Rework our GUI implementation completly. To achieve this you should look at different GUI implementations out there like | |||
[http://www.paragui.org/ ParaGUI] and of course at our GUI. With the information you gather from that, design and implement | |||
a GUI to fit our needs. Here is a small list of features we would like to have: | |||
* | * Support for low end devices, like the Nintendo DS with 4 MB of RAM and a slow CPU (ARM with 67MHz) | ||
* | * Layout and widget look should be pretty much the same as our current | ||
* | * A vector graphics based renderer sounds like a nice thing for customizeability | ||
* | * Antialiased fonts for more powerfull machines would be a nice addition | ||
* | * TrueType font support would be cool, but of course it should still be portable | ||
* | * Widgets should be configureable in the layout description, i.e. font to use, text, position etc. | ||
* | * Internalization support would be nice, but of course a lot whole of extra work | ||
* | * Eye candy like highlighting buttons while hovering etc. would be a really nice addition for high end machines | ||
* Support at least 15/16 bits per pixel screen depths, additional support for 24BPP and 32BPP would be nice | |||
* Extendable design, which should make it easy to support new widgets | |||
=== New Rendering Pipeline === | === New Rendering Pipeline === | ||