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

[andrewdavidwong]

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

Can we integrate this functionality into Qubes?

[marmarek]

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.

[marmarek]

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]

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]

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]

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

[jpouellet]

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]

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?

[marmarek]

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]

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]

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]

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]

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]

core-util-linux?

[jpouellet]

core-util-linux?

[marmarek]

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

[marmarek]

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]

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

[jpouellet]

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]

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

[rustybird]

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

[jpouellet]

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

[jpouellet]

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]

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.

[marmarek]

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]

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

[rustybird]

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

[SietsevanderMolen]

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.

[SietsevanderMolen]

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.

[evadogstar]

1. What is the best keyboard shortcut for this script?
2. Which one is the best roght now?
3. 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.
4. When this util will be available as package?

[evadogstar]

1. What is the best keyboard shortcut for this script?
2. Which one is the best roght now?
3. 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.
4. When this util will be available as package?

[jpouellet]

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]

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]

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

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

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

[jpouellet]

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

[jpouellet]

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]

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.

[evadogstar]

Shortcuts help.
There are a lot of shortcuts and some other very useful information that newbie Qubes/linux user must know. How about to add one more shortcut ie. Ctrl+F1 to show some very quick help for user with all of this shortcuts description? Maybe with some info how to access full Qubes help online/offline and some other "must know and hard to remember" help? maybe show at this help all QUBES SPECIFIC shortcuts and bash terminal shortcuts.

Or at least the page to docs with all of this shortcuts?

#2449 QubesOS/qubes-manager#19 #2229 #881 #2002 #1448 #1019

https://groups.google.com/forum/#!topic/qubes-devel/poVtf6X0-BM/discussion

[evadogstar]

Shortcuts help.
There are a lot of shortcuts and some other very useful information that newbie Qubes/linux user must know. How about to add one more shortcut ie. Ctrl+F1 to show some very quick help for user with all of this shortcuts description? Maybe with some info how to access full Qubes help online/offline and some other "must know and hard to remember" help? maybe show at this help all QUBES SPECIFIC shortcuts and bash terminal shortcuts.

Or at least the page to docs with all of this shortcuts?

#2449 QubesOS/qubes-manager#19 #2229 #881 #2002 #1448 #1019

https://groups.google.com/forum/#!topic/qubes-devel/poVtf6X0-BM/discussion

[jpouellet]

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.

[jpouellet]

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.

[evadogstar]

Why it have so far in the future milestone? @jpouellet sh script works good.

[evadogstar]

Why it have so far in the future milestone? @jpouellet sh script works good.

[andrewdavidwong]

@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. :)

[andrewdavidwong]

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

@evadogstar requested in #2449 (comment) to also have a shortcut for something like qvm-filemanager

[jpouellet]

@evadogstar requested in #2449 (comment) to also have a shortcut for something like qvm-filemanager