Difference between revisions of "OpenTasks/Generic/GUI Improvement"

Jump to navigation Jump to search
m
typos
(Move OpenTasks onto unique pages with an Infobox and Category so we can collect them all up onto the summary page.)
 
m (typos)
Line 10: Line 10:
===Background:===
===Background:===


ScummVM's GUI delivers various functionality to smoothen the user's experience when playing games supported by ScummVM. A typical set of tasks include: the management of games, setting options for individual games, offering an uniform interface for saving and loading inside games. Since not all games and target platforms support all the possible features in ScummVM our GUI has to reflect that in an intuitive way to the user.
ScummVM's GUI delivers various functionality to smooth out the user's experience when playing games supported by ScummVM. A typical set of tasks include: the management of games, setting options for individual games, offering an uniform interface for saving and loading inside games. Since not all games and target platforms support all the possible features in ScummVM our GUI has to reflect that in an intuitive way to the user.


Consider the following example: A user wants to setup individual options for [[The Curse of Monkey Island]]. This game does not have any MIDI support nor does it support different graphic render modes. Currently we still show the "MIDI" and "MT-32" (both MIDI related) tabs in the options menu of the launcher for it. Albeit we disable all the widgets in the MIDI menu this is confusing for the user, especially since these settings are grayed out, it would be more intuitive if these tabs would be just not shown at all. Furthermore in the "Graphics" tab the user can still select a graphics render mode via the "Render mode" pop up menu. We might be able to disable the widget (and thus gray it out). This does not feel right though, a better solution would be to remove that widget from the "Graphics" tab in the options menu. The latter is currently not possible since the layout of all of our dialogs is done rather statically via a theme file, which just allows for adaptations of the existing widgets in a dialog to the screen resolution.
Consider the following example: A user wants to setup individual options for [[The Curse of Monkey Island]]. This game does not have any MIDI support nor does it support different graphic render modes. Currently we still show the "MIDI" and "MT-32" (both MIDI related) tabs in the options menu of the launcher for it. Albeit we disable all the widgets in the MIDI menu this is confusing for the user, especially since these settings are grayed out, it would be more intuitive if these tabs would be just not shown at all. Furthermore in the "Graphics" tab the user can still select a graphics render mode via the "Render mode" pop up menu. We might be able to disable the widget (and thus gray it out). This does not feel right though, a better solution would be to remove that widget from the "Graphics" tab in the options menu. The latter is currently not possible since the layout of all of our dialogs is done rather statically via a theme file, which just allows for adaptations of the existing widgets in a dialog to the screen resolution.
Line 21: Line 21:


* Get familiar with our current GUI design and implementation.
* Get familiar with our current GUI design and implementation.
* Collect a set of requirements we have on an improved GUI. All the requirements collected in this process should be put together in a document to allow for easy review and evaulation of your task later on.
* Collect a set of requirements we have on an improved GUI. All the requirements collected in this process should be put together in a document to allow for easy review and evaluation of your task later on.
* Create a new design for the GUI code/infrastructure to allow for all the collected requirements. (This design should of course be easily adaptable to requirement changes while in the process of this task and later on).
* Create a new design for the GUI code/infrastructure to allow for all the collected requirements. (This design should of course be easily adaptable to requirement changes while in the process of this task and later on).
* Implement the new GUI infrastructure, this should be done by a mix of refactoring of the current codebase and implementation of new features.
* Implement the new GUI infrastructure, this should be done by a mix of refactoring of the current codebase and implementation of new features.
2,051

edits

Navigation menu