Queries about some 'usability' points
Lionel Ulmer
lionel.ulmer at free.fr
Thu Oct 27 14:51:52 CDT 2005
Hi all,
There are just two (unrelated) points that I would like to discuss:
= the possibility to add a 'wine' launcher. Basically what happens is that
some (maybe only one :-) ) application takes as an assumption that it is
started via 'double clicking' on the .EXE file or via the installed link.
From what I know, both these actions will start the game from its .EXE
directory and with the full qualified path as the exe name.
So the application crashes if you start it with 'wine foo.exe', you need
to type 'wine D:\\Foo\\foo.exe' to get it running.
One could then imagine having either 'wine' be a launcher that qualifies
the name, changes to the good directory and just start the 'real' wine or
do the reverse: publicize to new users that they should use 'winelaunch'
to start applications and keep 'wine' how it is now.
= in the current Wine tree, if Wine crashes, some persistant X settings are
changed (for example desktop resolution for people using XRandR)... And
as most people do not know the 'xrandr' command line tool, they tend to
kill X to restore their resolution (which tends to annoy them :-) ).
In the same vein, I would like to disable mouse acceleration when DInput
mode is entered but actually fear to do so for the above-mentionned
reasons (I fear gettint these kind of lines in the IRC channels: 'Wine is
crap, when it exits, I need to restart X to get my mouse acceleration
back'). Well, there is 'xset' but most 'normal' users have no idea that
it even exists...
For that one, the most robust way would be at the X level (basically
having 'connection-linked' configurations - i.e. the settings has changed
up until the point in time that the client quits) but if we do not want
to change X, the most robust way would be to do it at the wineserver
level (I often get Wine crashing, it's more rare to get the server to
crash). Of course, injecting X code in the server is maybe not to AJ's
liking :-)
So the other solution would be to be able to hook somehow some 'clean-up'
functions from DLLs to the Wine process that could be called when Wine
exits (whether normally or when crashing). Of course, people 'kill-9'ing
their Wine would get nothing but I do not think it's really a problem.
Lionel (in rant mode :-) )
--
Lionel Ulmer - http://www.bbrox.org/
More information about the wine-devel
mailing list