[Bug 2947] Might and Magic VI doesn't close properly when told to do so, wine must be killed

[Wine Bugs]

http://bugs.winehq.org/show_bug.cgi?id=2947

------- Additional Comments From [e-mail]  2005-09-05 23:47 -------
I can't believe I made a mistake like that! I even remember looking at the
attachments after uploading, to make sure they were correct... but when I follow
the "correct behaviour" link now, the image definitely does depict the correct
behaviour (decorations not visible).

And actually, I was unclear about the resolution change. The resolution changes
under Wine just as it does under Windows; that is the correct behaviour, and
that's how it behaves. Where the difference lies is in what is and is not
possible to do after the resolution has already been changed.

Under Windows, you can do three things: a) keep going (i.e. play the game) at
the new resolution; b) use the game's Exit command to quit the game, which
restores the previous resolution; or c) use Alt-Tab to switch out of the game
and back to the rest of the OS (which also restores the previous resolution, and
minimizes the game into the Taskbar).

Under Wine, you can still do both a) and b), and you could presumably use
Alt-Tab to switch to a background window if you wanted to. But switching focus
in that way would *not* automatically change resolution, nor would it minimize
(iconify) the game window until you tried to give that window the focus again.

Under my system's configuration (I don't know how universal it is), the
resolution change involved in a) and b) under Wine is done simply by reducing
the size of the viewport. Under that same configuration, when the resolution of
the current viewport is smaller than the resolution of the current desktop,
moving the mouse pointer to an edge of the viewport which is not also an edge of
the desktop will 'scroll' the viewport in that direction. This latter effect,
while not always desirable, has no corresponding functionality under Windows.

Additionally, under my system configuration (and probably most others), I can
use Ctrl-Alt-NumpadPlus to switch my viewport to the next lower resolution
listed in my X config file; similarly, I can use Ctrl-Alt-NumpadMinus to switch
to the next higher resolution (if there is no higher/lower resolution to switch
to, it wraps around to the opposite end of the list). This means that I can
change the resolution myself, independent of what MM6 wants to do; I do it not
infrequently, to consult and edit notes I've made during gameplay.

I don't use icons since I moved to Linux, and I don't minimize/iconify windows;
I would not like for the only way to switch out of MM6 without terminating the
program to be to make the window disappear like that, since my preferred Linux
desktop style does not include a taskbar of any sort (and thus it'd be rather
hard to get the window back). For window manager configurations which aim to
more closely resemble the Windows look and feel, and as such include a taskbar,
it might arguably be desirable to mimic the Windows behaviour in this instance -
but I don't know of any way, short of a user-set configuration option, for Wine
to reliably tell whether or not the environment in which it is being used is
meant to that closely resemble Windows.

I also wouldn't like to see the ability to switch resolutions whenever and
however I like go away.

On top of all possible undesirability issues, I'm fairly sure that there is no
practical way for Wine to enforce the Windows style for most of these
behaviours; furthermore, the only one for which I think it might be potentially
desirable is the 'scroll the viewport by moving the mouse pointer' one, and on
that I think it likely that - at least in my case - the loss of the ability to
go look at other programs without quitting MM6 would more than offset the
decreased aggravation of needing to avoid accidentally scrolling the viewport.

Part of the issue here is that this is not purely a matter of how the Windows
program behaves, but also a matter of how it interacts with the surrounding OS
interface. Windows provides certain rules and a certain framework for how
programs can behave; any given *nix environment does the same thing, but unlike
under Windows, there is no guarantee that any two *nix systems will provide the
same framework and the same rules. The way MM6 behaves under Windows makes sense
for Windows' framework and rules, but it does not necessarily make sense for all
of the frameworks and rules possible on various *nix systems, and I do not think
it is sane to try to enforce it on them.

(This sounds more like the sort of philosophy argument that I'd expect to find
on a project's development list...)