"Domain: sys-usb" -> "Service VM: sys-usb"

[rootkovska]

I think this happened only after I recently regenerated Appmenus after installing recent updates.

[marmarek]

Which one is preferred?

[marmarek]

Which one is preferred?

[marmarek]

In other words, this is a feature.

[marmarek]

In other words, this is a feature.

[rootkovska]

To be consistent, I think it should be named "Service VM: sys-usb", just like for the sys-net.

[rootkovska]

To be consistent, I think it should be named "Service VM: sys-usb", just like for the sys-net.

[marmarek]

What about dropping "Domain:" prefix, we've discussed some time ago? Should "Service VM: " and/or "Template: " be still there? Also, maybe it should be "Service qube: "?

[marmarek]

What about dropping "Domain:" prefix, we've discussed some time ago? Should "Service VM: " and/or "Template: " be still there? Also, maybe it should be "Service qube: "?

[rootkovska]

The main idea is to have all the service VMs grouped together, rather than intermixed with the actual user AppVMs. I think it's ok to stay with the "Domain:" and "ServiceVM" names for now.

[rootkovska]

The main idea is to have all the service VMs grouped together, rather than intermixed with the actual user AppVMs. I think it's ok to stay with the "Domain:" and "ServiceVM" names for now.

[ERFier]

With my fresh R4rc2 install everything but the disposable VMs was named Domain instead of distinguish between Domains, Templates and AppVMs.

I like to throw in an other idea: What about allowing the user to group them into folders and create some of them during firstboot? E.g. one could have two folders "Services" and "Templates" containing all the Service and Template VMs that are now on the top level.

The rational behind that is that one barely need direct access to those VMs in the daily work once everything is set up. If the user usually don't need direct access to these VMs cause he doesn't installs now software every day why should they on the top level and cause distraction when the user reads thru the domain list to start the proper domain for its task.

[ERFier]

With my fresh R4rc2 install everything but the disposable VMs was named Domain instead of distinguish between Domains, Templates and AppVMs.

I like to throw in an other idea: What about allowing the user to group them into folders and create some of them during firstboot? E.g. one could have two folders "Services" and "Templates" containing all the Service and Template VMs that are now on the top level.

The rational behind that is that one barely need direct access to those VMs in the daily work once everything is set up. If the user usually don't need direct access to these VMs cause he doesn't installs now software every day why should they on the top level and cause distraction when the user reads thru the domain list to start the proper domain for its task.

[mfc]

this is a regression in 4.0 from 3.2. i suggest:

• templates have the prefix "Template: "
• services have the prefix "Service: "
• domains/qubes have the prefix "Domain: "

don't have the words "VM" or "qube" because they are redundant and would be in every entry.

obviously it would be great for the user to be able to customize ordering/categorizing of the VMs in the menu, i think that should live as a separate/additional issue. right now it would just be nice not have yet another UX regression in 4.0.

[mfc]

this is a regression in 4.0 from 3.2. i suggest:

• templates have the prefix "Template: "
• services have the prefix "Service: "
• domains/qubes have the prefix "Domain: "

don't have the words "VM" or "qube" because they are redundant and would be in every entry.

obviously it would be great for the user to be able to customize ordering/categorizing of the VMs in the menu, i think that should live as a separate/additional issue. right now it would just be nice not have yet another UX regression in 4.0.

[qubesos-bot]

Automated announcement from builder-github

The package qubes-desktop-linux-common-4.0.8-1.fc25 has been pushed to the r4.0 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-desktop-linux-common-4.0.8-1.fc25 has been pushed to the r4.0 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-desktop-linux-common-4.0.8-1.fc25 has been pushed to the r4.0 stable repository for dom0.
To install this update, please use the standard update command:

sudo qubes-dom0-update

Or update dom0 via Qubes Manager.

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-desktop-linux-common-4.0.8-1.fc25 has been pushed to the r4.0 stable repository for dom0.
To install this update, please use the standard update command:

sudo qubes-dom0-update

Or update dom0 via Qubes Manager.

Changes included in this update