-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2017-02-10 15:32, Oleg Artemiev wrote: > On Tue, Feb 7, 2017 at 1:41 PM, Andrew David Wong > <a...@qubes-os.org> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 >> >> [Please keep the list CCed.] >>>>> why do we use operating systems at all? Because them >>>>> provide some set of default pretty >>>>> functionality/environment from the box. Why each time I >>>>> power down my PC and power it up back I have to waste time >>>>> on placing windows between desktops? Why the hell I can't >>>>> power on and smoke then get back and see everything same >>>>> way organised as I had on my last power up? >>>> Well, you can install Devilspie2 (or equivalent) in dom0 and >>>> automate your setup. (Remember, the foregoing discussion is >>>> about whether it should be installed *by default*.) >>> Yep. KDE by default has this from the box. Xfce has nothing >>> for this. That's why "by default" >> Hm, then perhaps it's really Xfce who should integrate this >> upstream? > It would be nice. > > Who will ask them for an integration? I guess unless enough people > will do - no one will decide to implement. >
Users who care enough to ask. :) >> It seems like it would be suboptimal for the Qubes Project to try >> to maintain a fork of Xfce that goes beyond Qubes-specific >> functions. > you haven't to fork and maintain Xfce entirely. All you need - an > option for restriction in qubes configuration for a VM and a script > that will autogenerate configuration of restrictions offered by a > tool you choose. > > 1st step is done: you adding a tool allowing such a restriction > (the tool is already selected for a future Qubes, AFAIK) See: https://groups.google.com/d/topic/qubes-users/jtjyq8N6bY0/discussion According to that thread, wmctrl (which is supposed to be like Devilspie2) is already installed by default, and xdotool, which is different, will be pre-installed in a future version. > now the second step: allow users easily automate restrictions based > on that tool via qubes configuration interface. > But this is still a nontrivial amount of work, and it's yet another thing that the Qubes team would have to maintain. Help from the community would probably be required. >>>>> The only thing I would like is having choice on restore as >>>>> it was and run new session. People at firefox made good >>>>> work and algorithm is well known, why not to apply this to >>>>> Qubes: On start show what is going to be started, if user >>>>> chooses "restore last state" - exactly that set left at >>>>> session abort/power off is shown, if user is in doubt - new >>>>> tab is always available. if user doesn't want to start same >>>>> or partial set - give him/her clean new session. What a >>>>> problem to do same way w/ desktop placement and VM autorun? >>>>> People spend a lot of time starting same things on next >>>>> power up. Firefox behaviour in case when firefox >>>>> configured "restore previouse state" and was killed/aborted >>>>> is best behaviour I've seen on restoring workspace. >>>> This sounds like it would indeed be a nice feature. Care to >>>> contribute a patch? >>> Not. :( A lot of questions appear to understand where to make >>> changes at 1st. Unsure that I'll be able to make such a >>> patches. >> >>>>> Locking application to some desktop set is a very good >>>>> feature and, afair and adding this functionality via some >>>>> utility in Dom0 default package set is work in progress for >>>>> current qubes. Just choose one app we're okay with, hug it >>>>> with qubes vm manager and users will love ability to use >>>>> it. :) I don't vote for this one utility - I vote for >>>>> similar functionality available to user _by_default_ . >>>> Why _by default_? As I explained above, we need to take a >>>> disciplined approach in deciding which features get included >>>> by default. If we include by default everything that everyone >>>> wants, Qubes will suffer from the consequent software bloat >>>> and feature creep. >>> That is not what every one want but this is what _everyone_ >>> usually wastes time on - when powered down and powered up to >>> continue . >>> >>>> We must resist the temptation to push for the default >>>> inclusion of features simply because *we* like them. There >>>> has to be a stronger reason than that. We have to ask >>>> ourselves the hard questions: Why do you want it to be the >>>> default? To save you from having to configure it yourself? >>>> Because you think other people should share your personal >>>> preferences? >>> Isn't the reason "every one wastes time that way" above is not >>> enough to add in whish list "make life better for every one" >>> by enabling option to restore last state of running VMs this >>> way"? >>> >> >> It sounds like you're conflating a few different ideas here: > >> including Devilspie2 by default, > you should include by default at least one of tools allowing such > a restriction - choose within Qubes team. I've no idea which is > better automated from outside w/o requirements for user > interaction. > (See above. wmctrl is already included by default. I have no idea whether it's good for the purpose you describe, though.) >> locking apps to virtual desktops, > Yep. > >> and saving state. > Yep. > >> I think the case for the last one is probably stronger than the >> first two (given what has been said so far), but maybe this is a >> question for the UX experts. > Yep, every one is wasting time restoring state, not every one > needs desktop-bound appllications. > >>>> Also, why is it so important to restrict certain domains to >>>> certain virtual desktops? >>> All these restrictions are about: >>> >>> 0. Save time - all appears same place (mean desktop set) - no >>> annoying window reorder . 1. Easier to group desktops and >>> activities by roles. >> These might be particularly subjective to the user's workflow. > Yep, but when you've lots of VMs running at the same time w/o > desktops this looks messy. > But this is about how individual users organize their own windows, how they conceive of window organization on a desktop, and whether their sensibilities about orderliness happen to match your own. Again, it's very subjective. This is a bit like saying that some of your neighbors' rooms are too messy for your taste, so your apartment complex should instate new rules governing orderliness inside their apartments. Also, remember that some people are RAM-limited and only run 1-2 VMs at a time (or simply prefer to use Qubes that way). >>>> Why not just place those windows on that virtual desktop if >>>> you want to, and not place any other ones there? Why does it >>>> have to be enforced by the OS? >>> I did not request to enforce everyone work that way. I request >>> putting an _option_ that user could _enable_, not forced to >>> use by default. >> Well, that's what I mean. Why do you want to have the option to >> have your OS force you to keep certain windows on/off certain >> virtual desktops? Why not just place them there (or not) >> yourself? Is it about preventing user error or something? > It is about: > > - adding some stability for user workplace. > > - stop wasting time searching windows of a certain role - if role > is bound to a desktop set - have no need to click one by one all > 12 desktops i use. For example - make instant messaging window > always be in one place. > > - stop annoyng mess when workflow on a role is interrupted by a > window from another role > > - workaround on lack of colors within qubes - I've only 8 and two > of them are subject for static color binding - "insecure things for > any role", "secure things for any role","Dom0 color". So only 5 > left. I.e. I could mark 5 extra roles within single human > activity. Okay, but what is I want to work as diffrent persons? Or > more common when I work for two companies and want to 've diffrent > colors for same activity in each of them? If I cannot mark by color > - I'd then mark by desktop. > > - easier activity grouping within a role. > > other users may add here more usecases. > Ok, thanks. I agree that there is the potential for sensible Qubes integration/features here. Tracking: https://github.com/QubesOS/qubes-issues/issues/2627 Note, however, that the issue of wanting more than eight colors is already being tracked separately: https://github.com/QubesOS/qubes-issues/issues/2523 - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYnreHAAoJENtN07w5UDAwHsQP/0LbZsRDeFO8VfarD3qk+hHp 4Im2wJc88zRgZEQLrCK6JwzVN7Z/5h6Lvo4Pt7Ix3qYwNw8OmloIqPakjJYOqoB+ aCMm43nFpM6T9M0ysBgyU/VjkaJKyMKkKPPS9cwT9WiWmYA/F0+7yRUFYhtPL353 PoRRdBBL2bCDXj+nISkk8VRDZuo+nvjyeaH1DfeNDiMswAsWxSpoeecCfGi6MI+8 OrvHxIPXi5KoK05c4VNg51T67lF/Kp3E3T1wF0r+m+3EZQbfgkleCjjX8X5CvhEY /aH6akUg9ct4or4qucnO6K2g2Mk/e+mw977kdqdAS5ItLIGWKOcttA4wYoGGqmFc BmJT5bOLoort5grTH2OPsu5K/13WjhGnPvNfscuC4+W8uUC9te9aqb4qIdKJ5zYq stNmV5oTEZmClIntosEM41bi35et6NUJc+tTz7flgHoecNyKhzF4z7UMxhARyC4L 3WEqwd8VBJZIkKMwbV06rM+fBMRThKNN7FZjd1EzJXAMY3o9yeFBV6zxqE7vgisQ iR6VdltMGeJM/Vg0Rs1ujRyPwihiCo/QJfbeIFvxzd6zbdEbtav3iBesaE97KhvJ yUdmbpJufsrVwvs0CE6WnYhWCatJSqhhRbPd2VmoIaXDXqWjcYDgkw7w7OKdKn9m SdDoJsBCkscbIKengXsa =FduN -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/d92c62a9-e68d-109e-c1e6-acb42d298bcd%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
