Re: wine louses up display

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2012-09-04 at 21:00 -0400, Doug wrote:
> On 09/04/2012 05:13 PM, Martin Gregorie wrote:
> > On Tue, 2012-09-04 at 16:34 -0400, Doug wrote:
> >> Running PCLOS, KDE desktop, everything latest version.
> >> Under certain conditions--one I can 100% repeat is Wine (Microsoft)
> >> Pinball--when I shut it down, by any means (escape key is straight-forward)
> >> the desktop will come back up with the widgets scattered all over the
> >> place, most of them moved towards the top left of the display.
> >> This happens in spite of the fact that the widgets were locked beforehand.
> >> I have been advised that wine (or at least Pinball) changes the screen
> >> resolution, which is what louses up the display when the KDE desktop
> >> comes back.
> >>
> >> Looking for a solution that will automatically restore the screen to
> >> what it was before activating Wine Pinball.
> >> (I found a similar situation with DOSBox. Would like a solution for that
> >> also.)
> >>
> > Run the Wine app from a small (5 line) shell script:
> >
> >
> > #!/bin/bash
> > export WINEPREFIX=$HOME/.wine_prefix_name
> > cd $WINEPREFIX/path_to/app?install_dir
> > wine appname
> > xrandr  --size "1280x800"
> >
> >
> > This assumes that 1280x800 is your normal screen size - use
> > "xrandr --current" to check that. You can point a launcher at the script
> > if you want to run it by clicking an icon.
> >
> > This approach should work for DosBox as well, though I've never seen any
> > problems like you describe from running it.
> >
> > Martin
> >   
> Thank you for the input.  I have to ask a couple of questions, being 
> somewhat dense.
> The expression above, ".wine_prefix_name" refers to what?
>
Wine creates a structure, called the Wine prefix, which is a directory
containing things that a Windows app expects to find, such as the
skeleton of the C: drive and the standard set of directories and files
created when Windows is installed on a PC, a set of drive letters, etc.

By default this is a directory called .wine and is in your login
directory. The latter's absolute name is in the $HOME shell variable.
 
>  Is this the 
> name of the
> script?
>
No. The normal convention is that scripts that are only used within a
single Linux user are kept in a directory called $HOME/bin, but if you
put them there you need to add the line

export PATH="$PATH:$HOME/bin"

as the last line in $HOME/.bash_profile. The script must have its user
read and execute flags set: "chmod u+rx bin/scriptname" Alternatively,
you can put them in /usr/local/bin and make them executable by all
users: "chmod uga+rx /usr/local/bin/scriptname"

>  I assume it is, and that as a result, instead of having an icon 
> (widget) on the
> desktop called Pinball, I would have an icon for a file called, perhaps, 
> "Run_Pinball" ,
>
Almost right. The launcher would use "/home/userdir/bin/scriptname" or
"scriptname" as the command to be run and, if you don't like the default
icon, set it to reference an image file (.png or .jpg) of the
appropriate size (32x32 pixels). Of course the script can be called
whatever you like: I'd probably just call it "pinball". 

> and at this point in the script, rather than writing .wine_prefix_name I 
> would write
> Run_Pinball. Is this correct?
>
That's correct.

> Under xrandr, I would put 1920x1080, I assume, since that is the normal 
> resolution
> of my display. Is that correct?
> 
Yes.

> (I checked a couple of other programs that run under Wine, and do not 
> have the problem
> that Pinball creates. They don't run full screen, as does Pinball. 
>
You should be able to control that with the "winecfg" utility. 

You can use more than one Wine prefix. In fact its recommended because
some Windows apps need winecfg settings, winetricks tweaks or DLLs that
will cause other apps installed in the same wine prefix to crash. I tend
to use a separate prefix for each app unless they are a set of apps that
are from the same source and that are explicitly designed to work
together.

> DOSBox also runs full screen,
> and that's probably why I see the problem there.
>
Interesting: my copy, which was installed as a standard Fedora package
(I run RedHat Fedora) runs in its own window.

>  I don't remember, but 
> maybe when I
> set up DOSBox I selected to make it full screen, if it hadn't been.)
> 
That sounds likely. The command "less ~/.dosbox/dosbox-0.74.conf" shows
the default configuration for my copy (version 0.74) and has
"fullscreen=false" set.


Martin





[Index of Archives]     [Gimp for Windows]     [Red Hat]     [Samba]     [Yosemite Camping]     [Graphics Cards]     [Wine Home]

  Powered by Linux