Keyboard shortcut to open terminal in same VM as front-most window

andrewdavidwong commented 7 years ago

Scripts created by @jpouellet: https://gist.github.com/jpouellet/0f74459699433cabc26c389caf36b455

Can we integrate this functionality into Qubes?

marmarek commented 7 years ago

Looks very useful :) There is a lot of space of some race conditions, but I think the worst that could happen, is getting terminal from a different VM.

jpouellet commented 7 years ago

Looks very useful :)

To be honest, I'd be surprised if an equivalent hasn't already been re-implemented a dozen times by different people in isolation. Sure you don't have one yourself? :P

edit: oh hey! look what i found...

There is a lot of space of some race conditions, but I think the worst that could happen, is getting terminal from a different VM.

Indeed. EWONTFIX ;)

I suppose I should re-implement this in python to avoid needing perl as a dependency of core-admin[-linux]...

jpouellet commented 7 years ago

Mine is more conservative with the interpretation of the output of xprop, but @SietsevanderMolen's is unquestionably more readable.

I also like his generalized terminal selection.

I also now remember my reasoning for implementing this in perl: runtime startup cost. I run this command literally hundreds of times a day (definitely already paid off), and if the delay between the keyboard shortcut being pressed and the terminal opening in the VM is too slow then it can miss the first key(s) I try to type into it. This actually happened in practice with the shell version (due to invoking awk) and perl's startup time is consistently <20ms whereas python's can be >50ms (at least as observed on my system).

marmarek commented 7 years ago

On Wed, Mar 15, 2017 at 05:25:59PM -0700, Jean-Philippe Ouellet wrote:

Looks very useful :) There is a lot of space of some race conditions, but I think the worst that could happen, is getting terminal from a different VM.

Indeed. EWONTFIX ;)

I suppose I should re-implement this in python to avoid needing perl as a dependency of core-admin[-linux]...

Or, create separate, optional package for just one (two?) script, and a perl dependency ;) Perl is installed in dom0 anyway, so this isn't a problem itself. Rather - having some perl script means that working on (some parts of) Qubes would require knowledge of one more programming language...

Actually, I'm slightly in favor of creating separate repository for this script. And maybe move some parts of core-admin-linux (tools/qvm-xkill?) there.

-- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

jpouellet commented 7 years ago

Speaking of saving time opening things in particular VMs, I also have a better application launcher I should really get around to finishing. Searching for a particular VM in the xfce "Q" menu can be super annoying when you have ~90 VMs and are in a hurry.

jpouellet commented 7 years ago

Actually, I'm slightly in favor of creating separate repository for this script. And maybe move some parts of core-admin-linux (tools/qvm-xkill?) there.

I agree that core-admin-linux right now seems a bit too much of a core-misc-crap, but it's not clear to me what the most logical separation of it would be. In my long-term effort to get *BSDs as first-class qubes guests, I've considered that we will eventually probably need a core-admin-posix and core-admin-linux, but that time hasn't come yet (currently blocked on finding time to re-implement vchan under not-GPL).

jpouellet commented 7 years ago

core-util-linux?

marmarek commented 7 years ago

Some insight on naming: https://blog.invisiblethings.org/2013/03/21/introducing-qubes-odyssey-framework.html

"admin"/"agent" - component for "dom0" or "VM" "core"/"gui"/... - "base things", "gui passthrough related things", ...

So, maybe "utils-admin-linux"? Or "linux-utils-admin"? ("linux-utils" repo was naming fail, should be "utils-linux")

jpouellet commented 7 years ago

Hmm. I suppose utils-admin-linux is the most consistent with the intended scheme, if a bit confusing. Without being certain what even belongs together, it's hard to determine what those groupings should be called. Naming is hard... I miss my bsd source tree where everything is an intuitive 3-5 letter subdir.

As long as the choice isn't as visually similar to an existing repo as core-agent-linux and core-admin-linux are to each other, I'll be fine :)

rustybird commented 7 years ago

Allow me to pile on another qvm-terminal. ;) Probably slower than pure Perl, though.

jpouellet commented 7 years ago

Hmm... I wonder if we should write one in C instead.

Benefits:

lowest startup cost
even faster by eliminating need to exec xprop or equivalent (twice!)
narrows race between getting focused window id from property on root window & that window disappearing or changing before getting its _QUBES_VMNAME
wouldn't add another language to the list of those used for base qubes code

marmarek commented 7 years ago

Hmm... I wonder if we should write one in C instead.

It's too easy to shoot yourself in the foot, so I'd avoid that if it isn't really necessary (either for performance reasons, or need to do some really low level stuff). As for avoiding xprop calls, you can do that directly from python, see here for example.

rustybird commented 7 years ago

Replacing qvm-run VM CMD with /usr/lib/qubes/qrexec-client -e -d VM user:CMD shaves off some noticeable startup time.

SietsevanderMolen commented 7 years ago

I don't think this needs to be rewritten in another language, especially not for performance reasons. I made copies of these and other tools in Ada (at least as fast as any version in C), for fun, but it's useless. It's more important that they're easy to change. Window managers are a very personal thing, everybody's i3 is different, and this way everybody can easily modify it to work however they want without having to recompile or learn a new language.

jpouellet commented 7 years ago

What is the best keyboard shortcut for this script?

Personally, I have it on Ctrl+Enter. This is inspired by i3. We're constantly pressing enter in terminals, so ctrl-enter to open a terminal feels natural.

Every time I've tried to work on a feature which involves keyboard shortcuts, somebody disagrees about the choice of key, and then it goes nowhere. [1] [2] [3] I think we should just reserve a single key as the Qubes modifier to allow us to freely pick shortcuts involving it (guaranteed non-conflict), and would provide other nice properties like the ability to prevent AppVMs from sniffing the beginning of shortcuts. I think more people voted for windows key for this purpose than people voted against it, but no clear consensus was reached.

The simplest things cause the largest discussions... sigh.

Which one is the best roght now?

You mean which qvm-terminal implementation? The yet-to-be-written one which incorporates the best parts of all the others :P

I think we need page at the Qubes Documentation which will describe all available utils as packages. As for me I read fist time about some utils like this.

You mean like https://www.qubes-os.org/doc/dom0-tools/ and https://www.qubes-os.org/doc/vm-tools/?

When this util will be available as package?

When someone gets around to the following:

combining the best parts of the above-linked implementations into a single better implementation
creating an appropriate new repo to house such tools so qubes-core-admin-linux doesn't continue to accumulate things which are irrelevant to qubes core but have no better home

I'll do it eventually if nobody else beats me to it. I'm rather busy with IRL stuff at the moment.

jpouellet commented 7 years ago

@marmarek how about qubes-desktop-linux-common as a suitable repo/pkg name? (for this, qvm-xkill, and the the accumulating miscellany of things which don't belong to core but have no better home at the moment)

jpouellet commented 7 years ago

See https://github.com/jpouellet/qubes-desktop-linux-common

jpouellet commented 7 years ago

I plan to re-write this in python using xcb directly instead of shelling out to xprop (twice).

The qvm-xkill move to new new repo in no way depends on this issue and can proceed independently.

jpouellet commented 7 years ago

Indeed. The most challenging part of the GUI DoS mitigation is having people know it's there and think to use it, without being able to look it up while their GUI is being DoSed ;) Due to this, I wonder how useful (if at all) it would really be in practice. You have no reason to care until such a time as you are unable to figure it out and are perhaps more likely to just hold the power button.

I agree that having a single page documenting all qubes-specific shortcuts would be nice. Not sure about a shortcut to show it though - if the problem is people not knowing of or remembering shortcuts, trying to solve that by introducing yet another shortcut seems unlikely to be helpful.

andrewdavidwong commented 7 years ago

@evadogstar: Well, it's up to @marmarek when this actually gets integrated. There will be no new features for 3.x, but perhaps 4.0 is more likely than 4.1. :)

jpouellet commented 7 years ago

@evadogstar requested in https://github.com/QubesOS/qubes-issues/issues/2449#issuecomment-290559738 to also have a shortcut for something like qvm-filemanager

andrewdavidwong commented 2 years ago

Would still love to have this (and the file manager one) in Qubes!

QubesOS / qubes-issues

Keyboard shortcut to open terminal in same VM as front-most window #2706