Forms
I feel that letting GBA influence !QTune will put enormous restrictions on the PC application. I think the UI requirements are different enough to separate the two from the start... The GBA stuff should be in it's own "branch" but both applications should call on OtherTuningSoftware/CommonInfrastructure for their core functions.
The wording is important there: The core should offer functions and services but the GUI should call them, not the other way around. This allows for feature-rich mouse-driven PC implementations (with hot keys / accessibility for in-car use), and also a clean GBA UI, without compromising either application.
I can only suggest starting with some sketches or screen shots to start with. I imagine a GBA UI would use a phone-like icon or text page, that can be navigated by the arrow keys. A PC app could use something similar, but menus and key-shortcuts etc are more familiar to most users...
The GUI stands of small, simple widgets. Things to be solved:
Customization of widgets
- texts (i18n)
- fonts
- images
For the nintendo software, config at compile time is OK. For PC, it ain't hurt if it's runtime.
http://www.flightgear.org/ has some nice gauges and (aircraft) panels made from them.
Packing of widgets
- bad solution is fixed packing: many windows programs sucked because of this
- simple, but powerful (I'd say perfect in this case) solution is to pack at configuration-time. It's next to impossible to use a mouse during tuning, so windows should be organized efficiently beforehand. If we provide reasonably packed screens for 240x160, 640x480 and 1024x768, that's perfect.
- complex solution is to allow resize at runtime. This is desirable in most applications, but not in this case.
Interaction between widgets
Also called as events or signals. Eg. when a value is entered into one widget, another one has to be scheduled to be updated (soon).
Navigation between input widgets
Also called as "changing the input focus". Jumping from input field to the next.
Remember that it must be possible without a mouse. Simple but powerful solution is needed. Maybe
- tree-menu is the most common approach when number of buttons is limited. Most laser-printers and TFT monitors (and even televisions) use this. The tree deltph is usually low (max 2..3). This requires an up/down and enter/back (perfectly suits the GBA buttons up/down and left/right). At the bottom of the hierarchy, a specific value can be adjusted. The adjust +/- keys can be the same as the up/down keys, in this case it's important to press "enter" to adjust the "value", while independent (from the up/down) +/- buttons allow adjusting without pressing enter (and back at the end). GBA allows this as well.
- in a special case, at the cost of +2 buttons, elements of a particular tree-level can be arranged in a 2D matrix and use arrow keys for navigation: the 1D and alt-tab is too slow when there are many elements in a tree-level, but too many elements on a tree-level might be a bad idea for other reasons ? The popular motec software has many elements in the main menu.
- This even works on Nintendo: 4 arrow keys for navigation, 2 keys for change++ and change-- and there are still 2 (or 4?) free keys left for special modes.
can this be done in graphics mode, not input fields? Like FAST's tuningsoft.. much nicer! //Emil
Utils for the above
While qt provides off the shelf methods for all the above, we have to take care that
- a solution is used that works everywhere, not only on linux and win32.
- very efficient without a mouse
Maybe using wrappers instead of the direct Qt calls.
I personally think that we should rely on a simple, small set of basic functions (at the very minimum, just copying rectangular imagemaps to the screenbuffer) like one of the APIs on OtherTuningSoftware/WidgetSet would work better than a complex widgetset where we'll find it hard to provide implementation on nintendo or other platform.
If we use some simple calls only, they will be available everywhere. By this we would lose a lot for a spreadsheet program or mp3 player, but we'll gain a lot for a tuningsoftware app.
The same config tabs as for megatunix can maybe be reused here?