Difference between revisions of "OpenTasks"

Jump to navigation Jump to search
(→‎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, or simply are not flexible enough to work atop our backend system. Also, our GUI must look equally good
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 it is quite flexible and has proven to stand our needs
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. Also our GUI layout is written in the same config file as the renderer configuration, which
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 other downsides too. We handle redraws very inefficient currently, for example
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, because of this the  
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 improved.
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 completly. To achieve this you should look at different GUI implementations out there like
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 powerfull machines would be a nice addition
* 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 configureable in the layout description, i.e. font to use, text, position etc.
* 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 whole of extra work
* 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