Re: one desktop, two people, two keyboards and mice

[Niels De Graef via desktop-devel-list]

Hey Richard,

If I understood correctly, then the definition you are looking for is
called *multi-seat* (where a "seat" represents a mouse/keyboard/...).

First things first: unless something recently changed, I don't think
multi-seat is supported in any Wayland compositor, so you'll have to
fall back to X for now.

Next, I'm not an expert on this, but apart from some Google searching,
these pages seem to be quite helpful in your journey (especially
depending on your distro):

* https://wiki.ubuntu.com/Multiseat
* https://wiki.debian.org/Multi_Seat_Debian_HOWTO
* https://wiki.archlinux.org/index.php/Xorg_multiseat

Good luck!

Cheers,
Niels


On Sun, Mar 22, 2020 at 8:09 PM Richard Henwood via desktop-devel-list
 wrote:
>
> Hi All,
>
> I have a large monitor, and I would like to use my computer with my child. My 
> vision is for me and my child to have our own keyboards and mice. I imagine 
> working away on 'my side' of the screen, while they are working on their 
> side. Occasionally, I will 'reach across' and help them with what they are 
> working on.
>
> I think libinput is part of the solution here. I added two mice it roughly 
> worked but there are mice cursor artifacts. I guess that GNOME or possibly 
> Wayland also needs some concept of multiple simultaneous inputs? I am on an 
> Ubuntu 18.04 distro, so may be things have improved with more recent releases?
>
> So, in short, does anyone have any pointers or suggestions for me to 
> follow-up with?
>
> best regards,
> Richard
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Heads up: Geary mainline development branch renamed to `mainline`

[Niels De Graef via desktop-devel-list]

On Fri, Apr 26, 2019 at 10:14 AM Ask Hjorth Larsen via
desktop-devel-list  wrote:
>
> Am Mi., 24. Apr. 2019 um 13:57 Uhr schrieb Michael Gratton :
> >
> > On Wed, Apr 24, 2019 at 13:31, Daniel Mustieles García
> >  wrote:
> > > So hardcoding the name "mainline" to the list of branches that Damned
> > > Lies' looks up resolves the problem for you... and tomorrow another
> > > maintainer decides to rename it's master branch to
> > > whatever_non_offensive_name and DL breaks again until a patch is
> > > submited... no, sorry but this is not a solution for this.
> >
> > I agree, which is why I have been working to fix it places where it's
> > hard coded.
>
> When actually working on the project, you probably type the branch
> name now and then.  This means you need to be aware of it - it is a
> piece of information which must reside within your short-term memory.
> This is not a problem if you work on one project.  It is a problem if
> you work on hundreds of projects.  Then you need to run things like
> git branch and git status, read the output, and decide what to type
> based on that.  A good workflow seeks to minimize the risk that humans
> make mistakes, and that means making things as simple as possible.
> Please do not remove this particular piece of simplicity from our
> lives.

Hi Ask,

Note that you don't need to script this kind of stuff, if you use the
following tricks:

# 1. This creates a symbolic link from master to mainline, which
solves your problem already.
$ git symbolic-ref refs/heads/master refs/heads/mainline

# 2. This worfklow doesn't even need you to specify a branch if you
start from mainline/master
$ git checkout -b feature/
# work, work, work and commit
# If you no longer want to continue on this branch, you can go back to
the previous one with
$ git checkout -

Also note that cloning Geary will immediately take you to the default
branch of the remote (so no need to specify 'mainline' or anything).

> I can also script my way out of this for most of the tasks I need to
> do.  But inconsistencies have never made life easier in computing, and
> this is an inconsistency which we could simply choose not to deal
> with.

We _could_, but if we want to (which is still Mike's decision as
maintainer of Geary), we can. Every change has its trade-offs, and
given the work Mike has put into this to make it a smooth(er)
transition, I'd say there is little inconsistency left to care about.
At least it would take less time then all the mails I (in hindsight
regrettably) read on d-d-l.

Kind regards,
Niels


> Best regards
> Ask
>
> >
> > //Mike
> >
> > --
> > ⊨ Michael Gratton, Percept Wrangler.
> > ⚙ 
> >
> >
> > ___
> > gnome-i18n mailing list
> > gnome-i...@gnome.org
> > https://mail.gnome.org/mailman/listinfo/gnome-i18n
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: I believe we should reconsider our sys-tray removal

[Niels De Graef via desktop-devel-list]

Hey Justin,

You can do so by going to the following link: 
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

At the bottom, you will find the appropriate button to unsubscribe.

Cheers,
nielsdg

On ma, Mar 25, 2019 at 11:18 AM, Justin Joseph via desktop-devel-list 
 wrote:

Sorry, how do I unsubscribe from this list? I can't find any option.

On Mon, 25 Mar, 2019, 2:27 PM Allan Day via desktop-devel-list, 
 wrote:

Hey Britt,

Britt Yazel  wrote:


I want to re-poen an old argument now that we have seen the effects 
of removing the sys-tray/app-indicator tray for well over a year. 
In short, the users are not happy.


As I recently wrote on GitLab [1], I'm open to re-evaluating this 
from a design perspective. However, I think we'd need a different 
implementation from GtkStatusIcon, and to my knowledge acceptable 
alternative isn't available.


I believe our goals of putting pressure on application developers 
to ditch the antiquated app-indicator model fell mostly on deaf ears


The goal was never to force app developers to do anything, and they 
can include a status indicator if they want. It's just that it won't 
be shown by default. If you haven't seen it, I wrote a lengthy 
account on my blog [2].


An example of this biting us in the arse is that with 3.32 TopIcons 
is causing the CPU usage to run through the roof, and people are 
blaming the Shell for the CPU usage, not the extension, leaving our 
users with a bad taste in their mouths.


Can we can do a better job at sign-posting which extension people 
should use?


Allan
--
[1] 
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1014#note_457856

[2] https://blogs.gnome.org/aday/2017/08/31/status-icons-and-gnome/
 ___
 desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list



___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list