Implement the native OS/2 style for widgets

[dmik]

To give Qt applications a true look and feel of native OS/2 applications, we need to implement the native OS/2 style for widgets. At the beginning, we can just mimic all controls in the OS/2 Warp 4 style using drawing primitives and bitmaps supplied by OS/2 (those we can reach: check boxes, radio buttons etc.). So the best name for the class is QWarp4Style.

Later we might want to create a more sophisticated style that will detect the presence of any look and feel enhancers (eStyler, eSchemes etc.) and will use API provided by these enhancers to draw the controls as a whole (buttons with gradient fills, titlebars with images, etc.) to be always in tune with the current look and feel. The proposed name for this class is QEComStationStyle, because, at least for now, the primary target of the mentioned ehnahcers (and where they are or will be present by default) is the eComStation system.

This task (at least in the first part) is not that difficult, but quite time consuming, because requires a lot of diligent work. So, we definitely want a guy that will take it over.

[dmik]

Or a girl, of course :)

[komh]

by Cornelis Bockemühl (currently just a "guest" here)

Since January 2007 I am now busy with this job! My target is to create a "Warp4" style that makes use of whatever the system tells about any settings "legally" (like colors, fonts, icons, bitmaps etc.), but not to go into any "hacks" the different eCS stylers may use to get even more out of the system.

Currently I am in the middle of the work, nothing yet checked into SVN. Some controls are finished or almost finished (like buttons, progress bar, notebook alias "tab widget", menus etc.), while others are still entirely untouched (lists, tables, scroll bars etc.). But you would already feel a bit "familiar" even with the current status! ;-)

Of course some compromises will have to be made, because the Qt "widgets" and the PM controls are not in any case 100% identical in functionality - in some cases the Qt widgets are more powerful, in others the PM controls, and sometimes just the concept is somewhat different.

Examples so far:

• The "notebook control" alias "tab widget" cannot match 100%. For example is it possible to have "pages" without a tab for Qt tab widgets, so the functionality of the + and - buttons would be redundant. So we can either somehow still get the Warp4 like page header section with these buttons to make the "look and feel" as Warp4-ish as possible, or leave that feature out and gain some space for the dialog.

• The display of lists with columns and column headers is for PM the "details view" of a "container". Column width is automatic, but there is a movable separator that separates a left and a right half of the table. For Qt the table columns can all be resizable by the user, and the column headers can be buttons with a function (like sorting), and no left/right separator is available. This is an example where I can make the table look somewhat "Warp4-ish", but certainly not duplicate the functionality of the PM "details view"!

• There is no real "progress bar" control for Warp4, but most programs are "abusing" the slider control with some specific settings for that purpose, so that is what I am going to simulate.

etc. - just to name a few examples!

[komh]

by Cornelis Bockemühl

Question about fonts to be used by default (actually already answered for the moment in a mail exchange between Dmitry and myself). There are currently two ways how a program could determine its "default font" on an OS/2 system:

1. The "old standard" would be: Look into the OS2.INI for PM_SystemFonts/DefaultFont. If an entry exists there, use it, or otherwise go for 10.System Proportional. On a fresh installation (from OS/2 2.0 up to eCS 1.2, AFAIK), this INI setting is not defined, so 10.System Proportional would be used in that case. This is how OS/2 programs do it currently, and it would somehow make sense to also follow that strategy. This is what I originally advocated.

2. Look for the PM_SystemFonts/WindowText setting in the OS2.INI. I am not 100% certain, but I have the impression that this INI setting is set to 9.WarpSans by default since some time (Warp 3? Warp 4? eCS something?). It also looks like some "more recent" applications look into that settings on their own and use that font because it looks "nicer" on modern screens with current resolutions. From that point of view it would thus make sense to use it in Qt as well per default. This is what Dmitry preferred from the beginning.

In the meantime I am now also tending to the second solution, mainly because I found another good argument for it. "Old style" dialogs of OS/2 programs are internally scaled using "dialog units" that have to be converted to pixels at runtime by the PM automatically. For that purpose it looks like it makes use of the DefaultFont setting, so if you change that, all dialogs will be resized as well. This is the only way how the old style static dialogs could be adapted to other screen resolutions etc.! But the problem is that many dialogs are not any more 100% correct with any other font than with 10.System Proportional: The scaling factor is global, but not all strings are really "mean size", so some will be cut with another font. Furthermore, some programmers did some own drawing with bitmaps etc. within the dialogs, not really taking into account the dialog resizing mechanism of the PM.

Bottom line: It can be advantageous for "older" (but indeed also quite recent!) programs NOT to change the DefaultFont setting! And many OS/2 users may not even know about that possibility.

OTOH, there is that "new" WindowText setting that has no effect on "dialog unit" calculations (on which Qt dialogs and windows do not rely) and is set to a more "modern" font by default.

This latter reasoning made me finally switch to the opinion of Dmitry, but please tell us if there are other, maybe even better arguments in this case!

[dmik]

Thanks for joining the project, Cornelis!

Replying to guest:

2. Look for the PM_SystemFonts/WindowText setting in the OS2.INI. I am not 100% certain, but I have the impression that this INI setting is set to 9.WarpSans by default since some time (Warp 3? Warp 4? eCS something?). It also looks like some "more recent" applications look into that settings on their own and use that font because it looks "nicer" on modern screens with current resolutions.

Just a small clarification. The entire WPS and most system-provided PM programs in Warp 4 and eCS use 9.WarpSans, not some of them, so we should definitely respect that (besides my personal sympathy :).

The default value of PM_SystemFonts/WindowText (and all other like MenuText etc) is 9.WarpSans on those systems but the weird thing is that these keys are not always used by the system to determine window fonts. For example, if you change PM_SystemFonts/WindowText to something different, only a half pages in the e.g. Desktop Properties notebook will actually use it, the rest will continue to use the (hard-coded) 9.WarpSans... Well, we know how well IBM can surprise. Of course, in case of hard-coded fonts, even PM_SystemFonts/DefaultFont doesn't change anything.

I can also confirm that dialog units always depend on metrics of the PM_SystemFonts/DefaultFont, even if another font is actually used assigned to the control. This makes this concept of dialog units totally useless because setting PM_SystemFonts/DefaultFont to anything else but 10.System Proportional will break those WPS dialogs where WarpSans is hard-coded and control sizes (in 10.System Proportional-based units) are set to fit it. It means that we cannot freely change PM_SystemFonts/DefaultFont or mean to change it (i.e. what you already said).

Another interesting investigation is that not every font is suitable for PM_SystemFonts/DefaultFont. At least in terms of metrics for dialog units, PM seems to respect only bitmap fonts (System Proportional, Helv, WarpSans etc.). Which means, we have to completely forget about PM_SystemFonts/DefaultFont at all -- it is being (mis-)used by PM in a not reliable manner.

[dmik]

And again about the bended page corner in the notebook control. We argued if we should keep the additional inner half-border. I think that we should display the bended corner and this half-border despite the absence of the sub-page concept in Qt -- but only if we make this corner act like tab switcher (as it does in PM when there are no sub-pages).

[dmik]

Finally, the initial implementation of the Warp4 style contributed by Cornelis Bockemuehl is committed in r174. Good work, Cornelis!

Here is a list of changes I've applied to your patches before committing:

1. Integrated qwarpstyle_p.h, qiconfactory_pm.h and qiconfactory_pm.cpp into qwarp4style.cpp (there is no point of making this separation because all this stuff is internal and very platform-dependent).
2. Replaced QTPM_USE_TABWIDGET_PANELHEADERS, QTPM_NO_TABWIDGET_PANELHEADERS with QT_PM_NO_TABWIDGET_HEADERS (which isn't set by default and needs to be set globally during library compilation if one wishes so).
3. Replaced QTPM_USE_DEFAULTFONT, QTPM_USE_WINDOWFONT with QT_PM_NO_DEFAULTFONT_OVERRIDE (which isn't set by default and needs to be set globally during library compilation if one wishes so). Note that due to the new global nature of these defines I've removed your comments from the source files but I will add them to the description of these defines in the Qt/OS2 documentation.
4. Renamed QT_PM_QUEUE to QT_PM_DEBUG_QUEUE and QT_PM_FILE to QT_PM_DEBUG_FILE.
5. Reformatted the code to conform to the Qt3 formatting style.

Also, while playing with the Warp4 style, I've found several problems with it. Here they are:

1. The main menu isn't closed by ESC sometimes (I wasn't yet lucky enough to find a good way to reproduce).
2. Icons on tool buttons are scrolled up one pixel so that if the first scan line of the icon isn't transparent, it will be cut (look at the the WhatsThis icon in the "widgets" example).

3. "&" characters (used in tab titles to define implicit Alt-letter accelerators) are not removed when title text is drawn as the tab page's header text.
4. Tab page's headers are not removed when changing styles on the fly ("themes", "widgets" examples). I suppose that you should hide appropriate helper widgets in the QWarp4Style::unPolish (QApplication *) method.
5. "Fat" raised tab page's margins are not removed when changings styles on the fly ("themes", "widgets" examples). Probably, same as 4 above.
6. Garbage is drawn in the Edit menu of the "widgets" example. This menu contains customarily drawn menu items so this must be the problem.
7. I think that when QT_PM_NO_TABWIDGET_HEADERS is set, the half-border element of the tab page decoration should not be drawn too, because w/o the bended corner it looks confusing. In other words only the "fat" raised margins should be drawn in this case.

Feel free to fix these problems and send me patches. I will be trying to fix these problems too when I have time. After it is done, we will set Warp4 as the default Qt style under OS/2.

And sorry that it took me three months to put my hands on and commit.

[dmik]

Issue 2 is fixed in r178. Issue 3 is fixed in r179.

[dmik]

Issues 4, 5 and 7 are fixed in r181.

[dmik]

Issue 6 is fixed in r182.