Hi,
This is something I have been thinking about for a while and is triggered by a comment by Austin on the "How can we improve WINE" thread that is floating around.
In short, this is aiming to discuss and seek a resolution to issues encountered when editing resource files -- in particular dialogs -- and how to resolve them. There is also the wider issue of improving the warnings produced by the resource compiler to cover usability errors, like specifying duplicate mnemonics (clashing mnemonics on a dialog), multiple mnemonics (a control having two or more mnemonics) and partial mnemonics (a control ending in an '&' character).
= EDITING RESOURCES =
There are various issues that need addressing here (feel free to add any more that you find): 1. editing resources - especially dialogs - is hard without some sort of graphical editor; 2. not everyone has access to graphical resource editors (e.g. Visual Studio), so it is harder for people to make dialog changes; 3. graphical resource editors tend to mess up resource files, moving things around at random (Visual Studio, I'm looking at you); 4. it is difficult to make a layout change and apply it across the various language blocks consistently; 5. resource translators would like to use a gettext-style of resource translation; 6. people editing resources don't usually follow Windows resource layout guidelines and usability guidelines.
What I want to propose is to write a resource editor for Wine that follows best layout and usability guidelines, that makes it easier for people editing the resources to do so. I would like to have this handle various control sizes, borders and padding and make it simple and intuitive where Visual Studio is not.
There are some questions around this on whether to have these resource representations checked into the git repository and auto-generate the RC files at build time (preferrable), or whether to keep the RC files and have the editor process them to/from the editor format.
What I am thinking of at the moment is to use XUL to represent the resources and gettext po to handle the translation. The build-time tools would then handle the translation to keep the dialogs consistent. There should also be a mechanism to adjust a dialog on a specific language -- but if this is just relative size and positioning, that should be handled by the XUL+PO -> RC transformation tool.
Initially, a XUL+PO <==> RC conversion utility can be written to transform between the two. A graphical editor can then be built on top of this as desired.
= Layout Guidelines (Example set) =
- Dialog boxes have a 7 DLU inner border. - Command buttons are 50x14 DLUs. - Any control without an explicit name (e.g. a text edit box or list view) must have a static text label that is immediately before it in tab order (for accessibility requirements).
NOTE: There are various dialogs (e.g. on Winecfg) that use different spacing between controls. This gives an inconsistent look, and adds to the "Wine is ugly" effect.
Thoughts? Suggestions?
- Reece