RFC: Resource editing and validation

[Reece Dunn]

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