[kde-linux] KDE - What is 'Meta'?

[Duncan]

Mark Knecht posted on Sun, 05 May 2013 09:36:48 -0700 as excerpted:

>> On Sat, 4 May 2013 15:16:51 -0700 Mark Knecht <markknecht at gmail.com>
>> wrote:
>>
>>> I want to enable keyboard shortcuts for moving windows from screen to
>>> screen. (monitor to monitor on the same desktop) When searching around
>>> on the web I see people doing it with Meta+F1, Meta+F2, etc., but
>>> somehow I am not discovering what Meta is.
>>>
>>> What's 'Meta'?

> Tom, Pable & Duncan,
>    Thanks for the responses. They make sense and I'm attempting to
> implement. This is mostly just a thank you + status report.
> 
> 1) Found the place to set the meta key behaviour. Chose the very simple
> Meta-F1/F2/F3 to move between screens. Unfortunately nothing happens
> when I use those key combinations.

I don't use move-to-screen (tho I do use move-to-desktop, but most often 
with (configurable) the wheel on titlebar action, not keyboard 
shortcuts), preferring dragging the window for that, but I might try 
experimenting with it later to see if it works here, or if I duplicate 
your problem...

> 2) As per Duncan's response, I do already have the
> Move-to-Desktop/Move-to-Screen options available when right clicking the
> application's title bar, and those options do work.

Good.  That eliminates one set of possible issues to investigate! =:^)

> 3) Interestingly, I do not at this time have the options in System
> Settings for identifying screens. I seem to remember some button you
> could push that popped big numbers up on each screen but I no longer
> have it or at least cannot find it right now. None the less the
> Move-to-Screen implies my screens are 1-2-3 left-to-right which is
> consistent with the way I wrote my xorg.conf file.

Try kcontrol/system-settings, hardware, display and monitor, size and 
orientation, identify outputs button.  Note that I'm using open drivers 
(radeon on my workstation, intel on my netbook) RandR based multi-monitor 
support, however, and you mention the nVidia drivers and xinerama, and 
I'm not sure how they show up there or whether they've switched to RandR 
or still use the old xinerama method.

(I seem to remember that there was another way to get essentially the 
same numeric display, possibly via plasma, but don't remember how to get 
to that, and I'm not sure it's an accurate memory in any case.  But the 
above kcontrol/hardware/display path works as expected here.)

> 4) I do have Xinerama turned on in xorg.conf
> 
> c2RAID6 ~ # cat /etc/X11/xorg.conf | grep Xinerama
>     Option         "Xinerama" "1"
> c2RAID6 ~ #

As I hinted in the point above, xinerama per se isn't used so much any 
more, at least for native xorg/linux-drm/kms drivers.  RandR has nearly 
completely replaced it altho the xinerama protocol is still used at the 
xorg client app level in many cases, whether the underlying 
implementation is randr or xinerama doesn't matter in that case.  But 
what the servantware drivers do I'd not know, so...

> 5) From memory, turning off Xinerama resulted in each screen acting like
> a completely disconnected desktop. I don't think I was able to move apps
> from screen to screen or get my multi-monitor Virtualbox Windows VMs
> working on separate screens without Xinerama on. Unless I'm wrong &
> someone can correct me on those items then likely things need to stay
> more or less the way they are, at least for now.

Likely correct for the nVidia drivers.  For native/open drivers, as I 
said, randr.  However, there's different randr configuration that would 
be done in place of the xinerama configuration in xorg.conf(.d/).

> 6) With two separate and different model Nvidia cards, at least when
> using the nvidia-drivers package, none of the really nice KDE OpenGL
> features like Alt-F8 (I think) where I get a picture of all desktops
> work right now. I think that's because OpenGL only supports the first
> adapter and there's no way to virtualize the video from the second card,
> but that's just a guess on my part.

AFAIK that's true, altho one would think nVidia would have worked around 
that.

> 7) Sort of contrary to Duncan's response, I'd actually _LOVE_ it if new
> apps appeared where the mouse pointer was. In my case ALL new apps come
> alive from the KDE task bar start menu which is on the bottom of Screen
> 1 only. I'd like all new apps to start on Screen 1 as it would feel
> natural to me but they actually show up where the most recent active app
> was and not where the cursor is. For instance, if I have a VMWare VM on
> Screen 3, I move my mouse to Screen 1 and start a copy of konsole, it
> shows up on Screen 3. (Sometimes below the maximized VMWare VM so I
> cannot even see it.

This is where things get interesting.  Again, I'm not entirely sure about 
the differences in behavior with servantware drivers, but definitely with 
RandR, it should be possible, because that's EXACTLY the config I'm 
using, and it has worked well and been bug-free as far as I can see for 
quite some time, so the behavior seems quite stable, here.

Quoting my previous reply...

>> kcontrol, workspace appearance and behavior, window behavior, window
>> behavior, focus tab.  Take a look at the separate screen focus and
>> active screen follows mouse options. 

Here's what I have set here:

Separate screen focus: UNCHECKED.

Active screen follows mouse: CHECKED.

The help info for separate screen focus says that enabling it limits 
focus operations to the active xinerama screen only.  The active xinerama 
screen is normally where the active application is, which seems to be the 
behavior you're currently seeing.  Thus, see if UNCHECKING this helps.

The help info for active screen follows mouse says that when enabled, the 
active screen follows the mouse, when disabled, it's the screen 
containing the focused window.  Thus, I have it CHECKED since I want the 
app to appear on the screen with the mouse.

I will often deliberately move the mouse to the screen I want the window 
on then launch, if launching with hotkeys, or will click a link in my 
feed or list reader then immediately move the mouse to the screen where I 
want the browser window to appear, hoping I can move fast enough to get 
there before the window appears.  Since firefox takes a bit to start, I 
usually can, if no other firefox windows are open at the time.  Otherwise 
the window appears too fast, beating my pointer move, and I have to drag 
the window to the screen I intended it to appear on.

After writing that, come to think of it, perhaps having hotkeys to move 
the window to the appropriate screen isn't such a bad idea.  Dragging the 
window isn't terrible when I lose the pointer move race, but just hitting 
a hotkey would be nice, too.

I just have to figure out an appropriate hotkey, since the usual suspects 
are already reserved for desktop switching, etc...  But maybe I'll try it 
later and see what I can come up with...  Watch this space. =:^)

> 8) And yes, guilty as charged, I love Gentoo. ;-) I've been Gentoo for
> over a decade but a KDE user (which I love almost as much as Gentoo and
> far more than the Windows VMs that pollute my screens all day long) for
> only about 2 years.
> 
> Anyway, I'll keep poking around at this. Thanks again for the inputs.

Please report any further progress, as I definitely find the subject 
interesting. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman