Hotkey to move windows to predetermined location and geometry?

[Duncan]

Dotan Cohen posted on Tue, 13 Mar 2012 13:22:41 +0200 as excerpted:

> On Tue, Mar 13, 2012 at 03:22, Duncan <1i5t5.duncan at cox.net> wrote:

>> 2) The scriptable solution makes use of a very handy little app called
>> wmctrl.  You can call wmctrl with appropriate options to move and/or
>> resize to specific coordinates, close or move to other desktops various
>> already open windows, in a real-time manner.

> Thanks, Duncan! The wmctrl does seem to be what I am looking for. I
> installed it and tried playing with it a bit, but I could not get it do
> affect any windows. I'll start googling around as I am certain that I am
> missing some thing obvious.

First thing, be sure you're either running it as the user you're logged 
into kde as, in an environment inherited from kde (such as from a konsole 
window, not from a virtual terminal text login that doesn't know about 
your X session), or that you set the DISPLAY variable, etc.  In konsole 
it should be set automatically, tho.  You can check the variable in 
konsole by issuing the "echo $DISPLAY" command (no quotes of course).  
Here, it returns ":0" (no quotes).

Second thing, checkout the manpage, and first try the -l option (with 
some windows open, of course, for it to report on).  That should list the 
managed windows, including a plasma-desktop window for the desktop 
itself, and for each of the panels (so here I have three plasma-desktop 
windows listed, two panels plus the desktop).  Similarly, -d should list 
your desktops, and -m should list the window manager (KWin) and some info 
about it.  If those options aren't reporting anything, wmctrl isn't 
seeing your X/kde session for some reason.

You can then try wmctrl -d to list the desktops, wmctrl -n <number> to 
set it to one more than there were, and wmctrl -d again, to check that it 
took.  Of course you can then set it back to the normal number of 
desktops if you wish.

All these "basics" work, here.

Third, the following should be obvious, and probably will be in 
hindsight, but it still feels a bit weird to me, and if I hadn't been 
paying attention reading the manpage, I'd have gotten in wrong:

Near the bottom of the manpage it explains the <WIN> parameter notation.  
It's worth noting that we're working with WINDOWS here, NOT WHOLE 
PROCESSES, so feeding wmctrl a PID (process-ID) as you'd feed to kill, or 
feeding it a procname/exename, as you'd feed to killall, will probably 
*NOT* work as intended.

If you think about it, it couldn't work that way, since as I mentioned 
above, plasma-desktop for instance has three open windows here, and just 
using the PID or process name isn't enough to identify which window you 
intended to manipulate.

Instead, the <WIN> paramater by default substring-matches (case 
insensitive) against the window TITLE.  Thus, the TITLE is what you need 
to match against.

For instance, here, I have a konsole window sitting at the bash prompt, 
with bash in the titlebar.  I've ensured that it's the only one running 
ATM so the wrong one won't get matched, accidentally.  Typing this at 
that konsole prompt causes that window to close, as you'd expect from the 
manpage:

wmctrl -c bash

Meanwhile, wmctrl -c konsole doesn't close the window (tho it might close 
another one with konsole in the name if there is one), because that's the 
name of the app, not the title of the window.


Fourth, try the mentioned :SELECT: special string, as mentioned in the 
manpage under the <WIN> description, like this:

wmctrl -c :SELECT:

That should give you a cross-hairs pointer, that lets you click on a 
window to close it.  Don't click the wrong one! =:^)

Fifth, if the title matching isn't working but :SELECT: does, I'd guess 
it may have something to do with either unicode or possibly right-to-left 
window titles (I'm presuming...).  Try the workaround noted near the 
bottom of the manpage to see if that works.  If not, it's probably time 
to file a bug with either the wmctrl author or your distro, specifically 
mentioning R2L titles, UTF8, etc, as appropriate.  While I'm at least 
partially UTF8 here, I'm en_US, as close to basic POSIX as it gets other 
than the unicode, so wouldn't expect the trip-ups in that regard that 
someone with I'd guess native RtL Hebrew window titles might have.

>> [1] When kde4 broke multi-key hotkeys that worked just fine in kde3, I
>> rolled my own solution.  I'm not a C/C++ or even python/perl coder,
>> only a bash scriptor, so I coded the script in bash and run it in a
>> special konsole window with its own kwin window rules.  It's not fancy,
>> but it does a rather impressive job, considering it's all bash and kwin
>> rules, picking up where all kde4 left me was broken pieces of a
>> solution that USED to work!  A kde single-key hotkey still launches my
>> script tho there's independent hotkey solutions out there too, if kde
>> decides to break that as well.  My script in turn takes a category and
>> then an action selection key, to launch anything I use often enough to
>> have programmed a sequence for in a total of three individual key
>> presses.
>> For example, to open my browser of choice to bank's secure login site
>> is launcher, n, b.  Launcher is an "extra" key available on my
>> inet/media keyboard, n=net (category), b=bank (individual task in the
>> selected category).

> I would love to see your scripted hotkeys bash file. I use Krunner very
> heavily, and your solution might be even more efficient.

FWIW, it's actually a collection of several files, an initial trigger 
script, the main menu script, a keymap file that maps ctrl-key hotkeys 
(normal printing characters and shifted chars are native, ctrl-key combos 
need the mapping file and some like ctrl-J, newline, don't work anyway, 
it's just those three variants, normal, shifted and controlled), and of 
course the menu files.  The menu files are user owned/configured, the 
others are placed under the /usr/local/ location as system files.

There's actually a bit of kde config that goes along with it too.  I 
mentioned the kwin window rules and the single khotkeys based trigger key 
above.  The last bit of the puzzle is that I run a separate konsole 
profile for the menu, tho I believe it's optional.  (I tried it along the 
way, and had it setup when I got the thing working, so left it setup, but 
I don't think it's actually necessary.)

I'll probably post the collection, along with appropriate instructions, 
later.  I'm too tired to compose the instructions properly, ATM.

-- 
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

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.