1,079
edits
Difference between revisions of "GUI Themes/TODO"
Jump to navigation
Jump to search
no edit summary
(Some thoughts about the new GUI (incomplete)) |
|||
| Line 3: | Line 3: | ||
== Current state == | == Current state == | ||
No coding has been done yet. Some concept drafts of the new look can be found here: | No real coding (besides some quick and dirty proof-of-concept hacks) has been done yet. Some concept drafts of the new look can be found here: | ||
http://www.kressline.de/wip/scummvm/ | http://www.kressline.de/wip/scummvm/ | ||
== | == Ideas & plans == | ||
The new GUI will rely on bitmaps / pixmaps for drawing the GUI widgets, | The new GUI will rely on bitmaps / pixmaps for drawing the GUI widgets, | ||
like buttons, edit fields, tabs etc. This poses various problems and | like buttons, edit fields, tabs etc. This poses various problems and | ||
challenges but also some nice benefits (besides the obvious one, the | |||
improved look and feel :-). | improved look and feel :-). | ||
Some random thoughts, ideas and statements: | Some random thoughts, ideas and statements: | ||
* | * Using pixmaps has the drawback of taking more memory, and possibly more CPU power. So as a fallback, it would be good if we could still work w/o the pixmaps (possibly reverting to the current UI). | ||
* To make that easy, use a kind of "ThemeManager" or "AppearanceManager", which is used by widgets to render themselves | |||
* This means we should try to seperate widget logic (what happens if a click occurs, managing data contained in the widget etc.) from widget drawing as much as possible. Ideally, widgets only know how to react to events etc. and whenever they need to draw something, they invoke suitable methods of the AppearanceManager | |||
* We'd provide two basic apperances: The current one, re-tooled to use a special | |||
AppearanceManager "plugin"/"module", and a new one, which uses pixmaps to render all widgets. Care should be taken to make it possible to add new ones or disable the pixmap based ones (for ports that are low on memory) | |||
* Anti-aliased fonts: Some of the concept drafts use anti-aliased fonts; while that looks nice and nifty, it also adds a lot to the complexity of text rendering. For now we'll try to work without it. | |||
* Image data can both be stored in external files | |||
* ... | |||
== Customizability == | |||
== Data formats == | |||
We probably will use BMP as the format for our pixmaps, optionally compressed using zlib / gzip. Reason: It's very easy to read BMPs (or at least certain BMPs, we don't have to implement a fully generic BMP loader), and we already use zlib. So this causes the least overhead (compared to using e.g. libpng for PNG support), and the resulting file sizes are not much bigger than those of PNGs. | |||
It will also be possible to integrate pixmaps into the array, in the form of global/static arrays. We'll probably provide a tool that takes a BMP and generates a C++ source file from it. Note that here, zlib compression can be used, too (to reduce the size of the ScummVM binary). | |||
| Line 24: | Line 39: | ||
=== ImageManager / GraphicsManager (singleton) === | === ImageManager / GraphicsManager (singleton) === | ||
* a singleton (?) which manages a set of graphic objects | * a singleton (?) which manages a set of graphic objects | ||
* client code can register graphics by name / ID imageMan->registerGraphic("button_leftSide", surface); | * client code can register graphics by name / ID | ||
* client code can query for a graphic by a name and/or an ID surface imageMan->getGraphic("button_leftSide"); | imageMan->registerGraphic("button_leftSide", surface); | ||
* client code can query for a graphic by a name and/or an ID | |||
surface = imageMan->getGraphic("button_leftSide"); | |||
* data stored/returned as a Graphics::Surface | * data stored/returned as a Graphics::Surface | ||
* client code must unregister images when the corresponding surface is deleted, else crashes may occur! | * client code must unregister images when the corresponding surface is deleted, else crashes may occur! | ||
* The idea of being able to "register" images is that it makes it possible to load image data both from files and from static arrays, as part of the executable | * The idea of being able to "register" images is that it makes it possible to load image data both from files and from static arrays, as part of the executable | ||
* If an image is request which has not been registered, the | * If an image is request which has not been registered, the ImageManager will search for image files matching the name, e.g. in the above example it might search for | ||
ImageManager will search for image files matching the | |||
name, e.g. in the above example it might search for | |||
button_leftSide.bmp | button_leftSide.bmp | ||
button_leftSide.bmp.gz | button_leftSide.bmp.gz | ||
| Line 39: | Line 54: | ||
=== ImageLoader / ImageDecoder === | === ImageLoader / ImageDecoder === | ||
Not sure whether we really need this class; it could encapsulate | |||
the code used to load & decode BMPs, and would in the future | the code used to load & decode BMPs, and would in the future | ||
allow loading other formats, too (if desired), like PNG | allow loading other formats, too (if desired), like PNG | ||
=== AppearanceManager === | |||
This could be a very simple singleton which only manages a list of "Appearances" or "Themes". The real work would be then done by instances / subclasses of GUI::Theme or so... | |||
class Theme { | |||
public: | |||
virtual int getButtonHeight(); | |||
virtual void drawButton(Rect r, String label); | |||
virtual void drawDialogBackground(Rect r); | |||
virtual void drawCheckbox(Rect r, String label, bool checked); | |||
... | |||
}; | |||
=== | === Widget === | ||
We need to modify all Widget subclasses to use the active Theme to draw themselves. | |||