xbc5 / qubes-awesome Goto Github PK

Create a contextual (modal) toggle for the file manager (i.e. Ranger). Incorperate #6 into this.

No description provided.

When switching from a scratch (e.g. dev console) back to the previous scratch, every second time it focuses the window behing it. I have two hunches:

1. it has something to do with the client properties that are set -- perhaps one of them prevents proper history tracking; or the client isn't recognised as a typical client;
2. the order of the client history gets messed up when switching between two winows repeatedly;

Does it have something to do with the drawing order (as suggested on Matrix)? How does one change the drawing order? The suggestion was ontop=true, but is ther another way?

No description provided.

When on a VM specific tag (e.g. dev:b): activating a scratch should activate it for that VM -- UNLESS one has a a client from another VM focused, which takes precedence.

or the tag is a compound of multiple VMs -- perhaps in that case it should start all.

In addition to that, don't switch to the workspace if ALL VMs are not present, simply execute the start routine, notify, then one can switch over manually when ready. This will save wasted effort, and needless switching back and forth.

This is an extension to the current behaviour, which activates modals based on the client's VM.

For multi-screen setups we shall set static screens via awful.screen. Most of the tag related functions do not need a screen as an argument (because we will use a set of unique tags across all screens).

Go through all of the tag related functions and remove the screen argument (in most cases). If we need to search for a screen, combine all screens and perform a (black-box) search -- the client should not care about the screen.

For example, launching the fin client will launch several a client is already open. This is because the logic checks for an existing client, but there's usually time between booting and starting a client. Spamming the button will launch multiple. It needs a way to track state, but process callbacks do not work due to qvm-run not returning until the app closes.

Use Mod, Control, Shift + KEY to activate the default set of clients.

This assumes two things:

• the Tag as a set of default clients;
• the Tag knows which qubes it's associated with;

I call this a "client spec":
{{ name = "myapp", rule = { class = {"myapp"} }, qube = "theqube" }, ...};

Use classes, and encapsulate all of the creation logic -- right now it's stupidly difficult.

This loosely relates to #10, and requires that workspace (tags) have some notion about the VM to which they belong.

When switching to a specific workspace, and there is no client, run the client for that workspace and VM. Also map a key that allows one to open additional clients.

If the VM isn't running, don't immediately change to the workspace, instead send a notification; then another when the client is ready.

This relates to #7, so don't duplicate the work there. Perhaps do that issue first.

Use Python; embed it within a window; give it Vim controls.

No description provided.

But also only for its designated tag. For example, activating stop on ANY dev tag will stop the VM; activating it on a compound tag will stop all VMs.

Athough this is desirable behaviour, it's also a bug.

The issue (I think) is that qvm-run processes do not exit immediately (they do not fork), so a callback after the client opens does not execute. This nees more investigation.

This is annoying: waiting several seconds for a VM to start, then for it to steal focus. Simply issue a notification (which Qubes already does) when the VM starts, and hit the key again to make it visible.

Colourise the VM name, possibly remove the brackets; embolden the app name.

Create the launcher scripts too