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