[kde-linux] Re: Setting DISPLAY variable on quicklaunch entry not working

[Allistar]

Duncan wrote:

> Allistar posted on Wed, 11 May 2011 16:25:46 +1200 as excerpted:
> 
>> I've just updated KDE to 4.6.2 on Gentoo Linux and to my surprise Plasma
>> now works on my second screen (screen in the X sense, not in the
>> physical monitor sense). Previously the only way to get am accelerated
>> triple head setup was to run e16 on the 2nd screen.

Hi Duncan,
  As always, it's a very lengthy post from you, but indeed much appreciated 
:-)

> Cool.  I'm running dual-monitor but single card and therefore single X
> screen.  But I had triple-monitor (dual X screen) years ago, and am
> familiar with all the howls of pain when kde4 originally wouldn't work
> with multiple screens and no xinerama (aka, in zaphod mode).
> 
> So it's good to see reports that it's working now.
> 
> Tho I didn't see you mention whether you're in zaphod or xinerama mode,
> but it appears given the separate instances comment below, that you mean
> zaphod mod.

I can't use Xinerama as that prevent 3D acceleration (via Compiz). Now I 
have compiz running on all 3 LCDs. Nice. I find Compiz to be still much 
nicer than "native" KDE desktop effects.

The two left LCDs (both 1680x1050) are driven off one nVidia card using 
TwinView. One of the reasons I use compiz is that I can tell it the 
boundaries of the actual monitors so maximising etc. works. Using the KDE 
WM, it doesn't see two LCDs, it sees one large one. That stuffs up window 
placement. From what I can tell there is a bug in how KDE (or the backend 
that it uses) determines actual monitor placement when there is more than 
one X screen.

This means the right hand screen (the 3rd monitor) is a separate kde/plasma 
instance. The mouse can move between screen 0 and screen 1, but windows or 
icons cannot. Essentially it's an independant X screen.
 
>> This means I now have two instances of KDE running, with 2 instances of
>> the plasma desktop. All good so far. When I add a panel to the second
>> plasma instahnce and in that panel I add the "Quick Launch" widget. To
>> that I add an icon for Konsole. When clicking on that icon it always
>> starts Konsole up on screen 0, not screen 1.
>> 
>>   Setting the icon command to be:
>> 
>> DISPLAY=":0.1" konsole
>> 
>> Doesn't work - it still starts it up on the wrong screen.
> 
> That's not surprising.  The environmental variable setting mechanism you
> used there is a shell concept.  AFAIK, the launcher doesn't launch a shell
> first, but instead, uses the existing environment.

And also oddly, if I make a bash script which does what I wrote above 
(setting DISPLAY first), and I put a link to that bash script on the pager, 
it still starts up on the first screen. I suspect if konsole is already 
running on one screen, there is some mechanism (DBUS?) which detects this 
existing instance and starts up another one on the same KE instance as the 
first as a way of using the same resources (perhaps?). Anyway, it's a pain.

>> Oddly, when I start it up from the K menu on the second screen,
>> it starts in the right place.
> 
> This would be due to kwin's configuration, not the DISPLAY environmental
> variable.  AFAIK it's a single kwin running over the whole thing (that was
> actually one of the original problems I believe, assumptions were made
> that there was only one screen or that xinerama mode was in use, that had
> to be corrected before things could work properly, that was part of the
> whole hubbub I read about...), with kwin controlling placement, so that's
> what you need to configure.

I can tell (by using ps) that there are two "kdeinit4: plasma-desktop" 
instances running.

>> How do I convince quicklaunch to honour the DISPLAY setting for the
>> current screen?
> 
> Again, I'm not personally experimentally familiar with current zaphod mode
> and wasn't aware it was even working.  However, you don't mention trying
> the following and failing, and some of these settings apply at least to
> xinerama mode, with which I /am/ familiar, so perhaps they apply in the
> newly possible zaphod mode as well...

By zaphod mode I assume you mean "two heads". That's provided by the two 
left hand monitors via nVidia TwinView. The right hand monitor is not a part 
of the same desktop as the left hand two - i.e. windows cannot be dragged 
from the left two to the right one.

> kcontrol (um... systemsettings, but they aren't systemsettings, they're
> user-specific kde settings, thus the kde3 kcontrol name remains more
> accurate and is what I still use), hardware, display and monitor, multiple
> monitors.

That "multiple monitors" applet only shows a single monitor when run from 
screen 0 (which is a TwinView spanning 2 monotirs).

> You may need USE=xinerama (despite zaphod not xinerama mode, you'd need it
> I believe for the kde-base/systemsettings package, tho it may take the
> same setting for something else as well to get it working properly) to get
> that kcontrol module, but I believe that's what you're looking for.

I already have the xinerama use flag enabled (this is Gentoo).

> Some
> of those may not work with zaphod mode (or for all I know, you get
> different options, but assuming you have the options I get here), pay
> particular attention to the "enable multiple monitor window placement
> support" checkbox, and the show unmanaged windows on <dropdown>.  For the
> xinerama mode I have here, I have all the options checked and that
> dropdown set to "display containing the pointer".

Doesn't work as KDE doesn't see multiple monitors. On screen 0 it sees one 
big display of 3360x1050.

> You may also find the windows rules settings useful.  These are available
> either in kcontrol, under workspace appearance and behavior, window
> behavior, window rules, or in the windows rules section of the window
> behavior configuration available as an option from any window menu.

Window rules don't allow yo to govern which X screen a window is placed on.
 
> Normally, these are for exceptions to the general rules, but if you setup
> a rule without specifying a whole lot in the first couple tabs (window and
> window extra), it should apply more generally.  At one point I had a
> problem with a number of apps wanting to start maximized when I wanted
> them normalized, so I set a non-specific window rule that I titled
> "General initial no-max".  Then on the geometry tab, I checked the
> maximized vertically and horizontally options at the left, enabling them,
> set "apply initially" in the dropdown, and left the on/off toggle checkbox
> UNCHECKED, so matching windows (that is pretty much everything since I
> didn't filter much in the first couple tabs) would appear un-maximized by
> default.
> 
> It worked, and didn't interfere with more specific rules I set for
> specific apps or app-windows, either. =:^)
> 
> If you try this route, you'll probably want to experiment with the window
> placement option at the bottom of the geometry tab.  You can also try the
> position option, but I'm not sure that'll work as you described for a
> general rule, tho it might come in handy for specific windows if you
> always want them in the same place.

That'll only work within one screen, and I don't have issues with window 
placement. Besides, window placement is all taken care of by Compiz, not by 
KDE.

> Do note that depending on how insistent the app is at placing itself, you
> may have to set (workarounds tab) strictly obey geometry FORCE OFF, and
> ingore requested geometry FORCE ON.  I've found that these work best of
> they're BOTH set at the same time, to OPPOSITE values.

Thanks for the tips, but window placement doesn't allow you to place a 
window to a different X server instance on a different X screen.
 
> I hope that helps.  Please do post your results as I'm interested in
> knowing how well they work for zaphod mode.  Also, let me know if you need
> USE=xinerama to get that kcontrol module or not, and if setting it for
> kde- base/systemsettings was enough or if it needed set for something else
> too.

Ta.