Open main menu

GUI Themes/TODO

< GUI Themes
Revision as of 00:57, 19 November 2005 by Fingolfin (talk | contribs) (Some thoughts about the new GUI (incomplete))
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

We plan to implement a new GUI look & feel in ScummVM, roughly based on the new look of our web site.

Current state

No coding has been done yet. Some concept drafts of the new look can be found here: http://www.kressline.de/wip/scummvm/


General Ideas & plans

The new GUI will rely on bitmaps / pixmaps for drawing the GUI widgets, like buttons, edit fields, tabs etc. This poses various problems and challanges but also some nice benefits (besides the obvious one, the improved look and feel :-).

Some random thoughts, ideas and statements:

  • TODO



Some components of the new GUI code

ImageManager / GraphicsManager (singleton)

  • 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 query for a graphic by a name and/or an ID surface imageMan->getGraphic("button_leftSide");
  • data stored/returned as a Graphics::Surface
  • 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
  • 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

 button_leftSide.bmp
 button_leftSide.bmp.gz

The precise list of supported file types could be hardcoded (easier to write, maintain, port, takes up less resources, but also is less flexible); or we could make it plugable so that arbitrary formats can be supported. My oppinion: Let's start simple, if we need multiple formats we already have an abstraction layer in place and can safely rewrite the internals of ImageManager later on


ImageLoader / ImageDecoder

  • not sure if we really need this class; it could encapsulate

the code used to load & decode BMPs, and would in the future allow loading other formats, too (if desired), like PNG


AppearanceManager (singleton?)

TODO