334
edits
Difference between revisions of "OpenTasks"
Jump to navigation
Jump to search
m
→GUI: some rewording
(→GUI: reworked our GUI task, that's my personal opinion of it, feel free to comment on it) |
m (→GUI: some rewording) |
||
| Line 55: | Line 55: | ||
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, | 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 | 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. | 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 | 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 | via an external theme file described [[GUI_Themes/Specs|here]]. Even though this has proven meet our needs | ||
it is too complex and hard to use. | it is too complex and hard to use. Furthermore our GUI layout is contained 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. | ||
requires custom renderer themes to be manually updated even though nothing on the renderer changed. | |||
Our current GUI implementation has some | Our current GUI implementation also has some further downsides. Currently we handle redraws very inefficiently, for example | ||
on a single widget change we redraw the whole GUI. Also our pixmap approach is pretty unsophisticated, | on a single widget change we redraw the whole GUI. Also our pixmap approach is pretty unsophisticated, and so the | ||
overall renderer efficiency suffers. Last but not least our complete widget handling could be cleaned up and a bit | overall renderer efficiency suffers. Last but not least our complete widget handling could be cleaned up and improved a bit. | ||
''The Task:'' | ''The Task:'' | ||
Rework our GUI implementation | Rework our GUI implementation completely. 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 | [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: | 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) | * 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 | * Layout and widget look should be pretty much the same as our current GUI | ||
* A vector graphics based renderer sounds like a nice thing for customizeability | * A vector graphics based renderer sounds like a nice thing for customizeability | ||
* Antialiased fonts for more | * Antialiased fonts for more powerful machines would be a nice addition | ||
* TrueType font support would be cool, but of course it should still be portable | * TrueType font support would be cool, but of course it should still be portable | ||
* Widgets should be | * Widgets should be configurable in the layout description, i.e. font to use, text, position etc. | ||
* Internalization support would be nice, but of course a lot | * Internalization support would be nice, but of course this is a lot of extra work | ||
* Eye candy like highlighting buttons while hovering etc. would be a really nice addition for high end machines | * 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 | * Support at least 15/16 bits per pixel screen depths, additional support for 24BPP and 32BPP would be nice | ||