Devilspie2 integration

[Hack]

Hi,

Could it be possible to provide Qubes OS with Devilspie2 at first install?

Like this, we could have, by default? some virtual desktops attributed
to some task.

For example:

* Desktop 1 = administration tasks (sys-firewall, sys-net, etc…)
* Desktop 2 = Personal
* Desktop 3 = Work
* and so on

Maybe with some color "matching" on the tool bars?

Of course, with the option to customize it.

[Chris Laprise]

This is one of the things I love about using KDE on Qubes.

Chris

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

[Copying my reply from qubes-devel. Please don't send duplicate messages
to both lists.]

This seems far too subjective to be built-in by default in a sensible
way, even with customization options. User preferences vary wildly.
Some don't even use virtual desktops at all.

Why not simply install Devilspie2 (or a similar program) yourself and
set up your own virtual desktops as you please, if that's what you desire?

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYlBacAAoJENtN07w5UDAwgBUP/jeFcplQexNjPCLubJSUV5nI
jwE4waaAYdzBEkM7WllnrgKXeO1wqygcyyogGV4wJd65NG/TmryxBfwtAMkraOtQ
wOwZezY3WdAmGgCfiRPDFIt02H7FSRHQGVfqN7Il/rIzTIfHMmzGIh61fxI90HYw
z5+/9gMPLF6/mLe1WeHMLlXgju4YpIB6426PW+73nqTMhzfqpLdfFt9rVB+p0he9
PBNynaa6RLajQ+KafLF4L5kZaNUjY3rshFQ24ektvqKroiS+DsnD6PfC0HYnVHvx
z8XOVfNo3oqI6Nn+kbI19ZP22tCXPNCSleII1ksqydZ5E7jRxZAjkoWQ2GbR6Thf
y4X8g0Z8X+e2MOxiO9JExFfaZLNMyBcN3indiU3FlDlUykgvvvXchi3ibnJS690G
dU8NuvRAUum3ZWYMMNmIYLGAVZj1Ns11aNJdjJuiWFtTx48pSugCm7IwIX93kOKv
F9bSO3vwTjmmWwbkKhcklJ8+t1UvIyHpbYpKQr1+cNViX9Y7CvD7qFsRnQPLuKUX
mANc6eOHHvoXyOxiWnrmT9ur+23sEGnhWHUlsjI81qAKdoxS2oejdcw2k9INugve
Ki4M4F7CAzB3eL86E5NnAe17YmdDyfFZEyezBW7pBub9Sw4HEq7w4yEOhvH6IJoE
I+4CS4BiGHqRf1oyuSul
=RBJd
-----END PGP SIGNATURE-----

[Hack]

Yes, of course I can install Devilspie2, but I think it can be useful
for people, like me, who use virtual desktops.

It can be provided as an option during the installation. Thereby, we
could have the choice of having Devilspie2 installed by default (1
virtual desktop by Domain), and then, customize it, or not having
Devilspie2 "activated".

Because I think, it can be a good idea, *not only for me*, I suggest this.

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2017-02-02 23:13, Hack wrote:
> On 02/03/2017 06:35 AM, Andrew David Wong wrote: On 2017-02-02

> 06:09, Hack wrote:
>>>> Hi,
>>>>
>>>> Could it be possible to provide Qubes OS with Devilspie2 at
>>>> first install?
>>>>
>>>> Like this, we could have, by default? some virtual desktops
>>>> attributed to some task.
>>>>
>>>> For example:
>>>>
>>>> * Desktop 1 = administration tasks (sys-firewall, sys-net,
>>>> etc…) * Desktop 2 = Personal * Desktop 3 = Work * and so on
>>>>
>>>> Maybe with some color "matching" on the tool bars?
>>>>
>>>> Of course, with the option to customize it.
>>>>
>
> [Copying my reply from qubes-devel. Please don't send duplicate
> messages to both lists.]
>
> This seems far too subjective to be built-in by default in a
> sensible way, even with customization options. User preferences
> vary wildly. Some don't even use virtual desktops at all.
>
> Why not simply install Devilspie2 (or a similar program) yourself
> and set up your own virtual desktops as you please, if that's what
> you desire?
>
>>
>

> Yes, of course I can install Devilspie2, but I think it can be
> useful for people, like me, who use virtual desktops.
>
> It can be provided as an option during the installation. Thereby,
> we could have the choice of having Devilspie2 installed by default
> (1 virtual desktop by Domain), and then, customize it, or not
> having Devilspie2 "activated".
>
> Because I think, it can be a good idea, *not only for me*, I
> suggest this.
>

I see that you're intent on ignoring my request not to send duplicate
messages to qubes-devel and qubes-users. That's very disappointing.

At any rate, I've replied to you on qubes-devel:

https://groups.google.com/d/msg/qubes-devel/b0gJGe3OktY/edd3LbkXDQAJ

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYlDm7AAoJENtN07w5UDAw20EQAI5Bw0BhTth0exYk01Akxi2i
iVNtPXaOqBQd/BU56i+UVXQcEbtzCjsnEeRIWEhqtgwyU41fomcTzhS5nCsULHYO
sOuBgKiZZp6+Dqtbs+p9BXDBMOj60LeImbB3xsdTKq5xlv862+rdPWbKdVWmnH81
u/7ln1Oq3XBNw/lhUm9w0zUvC2SvAVA6IlPw6QyDRhk9rn3UREvbwMof01nm8PJw
QsCKJQJZ1XasxnUohWytSHbFjM+JC5RavadHsl0FUo5x7veanTfe9TgnDjHOtjuh
rPOTH8ysZA9bomP/ygXXE0C6LB/t3ASd6fzGJi7+1wKtvqSR6eCCdRSAbe+C8PiD
Q3Dr7dYjY8WbehbX+XA9UFoGoIOfwKu3cuPc4ZgiVe9uliWhDP/h4tVl5j99LEoO
INJVYzCTTSjg1Lx3XtYJewvB4hzwLbs5UoRVlY9pz9tclJ0gG/avsvGByH+7hDhI
I17hfuXfuP3xgR3yAn9EMoZqSw4HS78GXRqNdRlAouPO7g06kVD0cg0XV/TONUIQ
z9YGD4iyytCBjXYSLmkwGZ0nLwU9Pc6xN9fze1v9Es6/ah46re9VacjqCCLo9oBA
tTXBYT1esIWLXOwNqLcna1pbp36oA/+uh40gWiffHB45ZNr2iM2X/FPoxBd1lc3P
EGTJv8t+DXZy96XmweB6
=th9r
-----END PGP SIGNATURE-----

[Hack]

With all due respect, as Community Manager, you should always search
'for an excuse'…

I did not intend to ignore your message. I was barely awake, and screw up.

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2017-02-03 00:27, Hack wrote:
> On 02/03/2017 09:05 AM, Andrew David Wong wrote: On 2017-02-02

> With all due respect, as Community Manager, you should always
> search 'for an excuse'…
>

I understand where you're coming from. The problem I've found is that,
when one deals with as many trolls as I do on a daily basis, always
searching for an excuse simply invites further trolling.

> I did not intend to ignore your message. I was barely awake, and
> screw up.
>

No problem then. :)

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYlENJAAoJENtN07w5UDAwiRcQAJ9otMfHVJsp2xagpyL0vcR/
Isr8Bp9tiAlRXbEODCvr6yoy362MZoVou89S84wx4lqb8U9sF7+8YUK/+N420t1k
9Cd+6lfwQiDVMjdDF8mjh6mBYGd0CriuleEX0IUMj/hptxk5akYih0MLaQR1GB1n
Cl/hU2+1AAJw/g7z8ZKrM+tSpKf42jdMQKtqC1zlgeB1tlEd745rOVK7PbjJzTFb
3H1zEmZQKIVtaWbUa0k5zlUYbeX+8pwR7lkQIgFpNaDAMr5+01+sYXsICmBRVKJB
Tz9MeeHwsKVkILEq4RX0zjhCpr+rK8G/ohRzQDIhCq28Phj506F50H5AXQ2BkU3j
FAR7x3/FveVi+gBeG6VaJXIlYsKa22081soSQAQzfDQEJEOuRLUfA42fcc4VS78S
uAVKqbea/buQ2PQ+Icqxn+InIXUB6B4AkdMed7ZZezZ+02kxQlioRNdIrgVW0iJT
uGFxyUUnY+VKK3pL7DdBGCehwODBjUbk460JHP4X0PC5usWKbmMRn7r9a/CFniYn
X+fT1VGlCH1fniLMxfYpYyUZcQ/KW2IOqSK81s8d0iyabGIPRzmCwaHVpk23ATHD
MQ6MOMzrSM+HOBMocqIqv+n9FcirLbUP/S5fSIU8ZZ+wSd9lsBzMipyA2HgMINRk
xDN9NVHDOETg/YXKvY6X
=1Z+j
-----END PGP SIGNATURE-----

[WillyPillow]

Also, with AwesomeWM it should be possible to set up custom rules that automatically tags clients in different domUs, though I've never tried this.

--WillyPillow

----------

https://blog.nerde.pw/

PGP fingerprint = B57E 7237 B211 419C 35C4  AF5B EB4D 3264 A318 73CB

----------

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

[Please keep the list CCed.]

On 2017-02-06 12:31, Oleg Artemiev wrote:
>>> In general everyone using qubes (at least qubes 3.0 is using
>>> virtual desktops) uses virtual desktops: Xfce has virtual
>>> desktops and KDE has.
>> Just because they're included in the DE by default doesn't mean
>> everyone uses them.
> Last time I installed was long ago. After install you have no
> desktops on a panel? If you have at least two - you use them.

I imagine some people choose to disable them or simply ignore them
(e.g., by keeping all windows on the first virtual desktop), just like
many other features that are on by default.

> virtual desktop is a classic thing. Gnome made them unneed with
> their mouse operated window list (need to get mouse pointer into
> left upper conner), but gnome is not an option for Qubes (and I
> dislike the way them designed that).
>
>>> KDE has ability to stick application to a desktop from the box,
>>> but KDE is heavy and is not a default choice for Qubes
>>> anymore.
>> Indeed, but you can still use KDE on Qubes 3.2, if you want.
> Heavy manager + unrecomended.
>
>>> 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 seems like it would be suboptimal for the Qubes Project to try to
maintain a fork of Xfce that goes beyond Qubes-specific functions.

>>> 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, locking apps to virtual desktops, and saving state.

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.

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

>> 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?

>> Please don't take offense to these questions. I'm just trying to
>> encourage you to articulate the rationale underlying your
>> suggestions.
> it's okay.

>

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYmaRtAAoJENtN07w5UDAwoSsP/0fYc4INj8zgq0wUJipcWiHf
RPYYjHbyii7UI8Sz/WBsK4A+FJsoNlJRi00vnLUzEX03AlvlNa1uAeg/pUb2QrRa
bQgbFf5kg2I7KJ8vTvGgFR9TF3aZ25swgXB9UJOyadt/DCN2fZT62FvwV/FtMBlo
eYz46IRqOIaMmYVs50TvVLXfYYmnK72ERof8wFfLJK8w87SyFJrI3pPW0NF6W6OG
dWw0bhjIYUq1dIL00FNoDHfNLX3wPvTbvTqpJ8CvbN/lm0PizFZIx1zKMYCf1bxx
c3kt8iXFCIoNFDBNwi6+z9aw+YH80TyOlaiu4stVF+i6c3n+tX6MFFS1bs0wbYtC
3uXAQDOVKBG7/X1kxXW3yRHNqRfKg4iacmlqkUnx6xsf3+URTyG4M6zwNnrgUs9v
iqZSMpD3zlIpH5FhiK8tzJi5PrSq2nINNnU25NEyISRfsqXoFMMtsICcPozYkqFz
l3aErZFcQuabcQDky2xeoshHuk/MnVbP400Ubaj3fE6TLIIOAn/anAoSo00ORDVF
2l5xZduvLIH1WxE5bHDAd1IQmbIOwk44rq3BJMWX25zoKZJZxM3vBwfZyFM0drFY
xTB25TnpfJDg4gvtUMweURBlQLUY2nBdfwOSH2hpOaNn/DbJSv0LnBRDJ4VgkV0V
4Ow/r/ahf6TaQiMM0mQ3
=nawP
-----END PGP SIGNATURE-----

[Oleg Artemiev]

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.

> 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)
now the second step: allow users easily automate restrictions based on
that tool via qubes configuration interface.

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.

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

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

--
Bye.Olli.
gpg --search-keys grey_olli , use key w/ fingerprint below:
Key fingerprint = 9901 6808 768C 8B89 544C 9BE0 49F9 5A46 2B98 147E
Blog keys (the blog is mostly in Russian): http://grey-olli.livejournal.com/tag/

[Andrew David Wong]

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

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

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