Re: How do you hack on GNOME? How can we do better?

[Owen Taylor <otaylor redhat com>]

On Mon, 2015-07-20 at 16:35 -0700, Jasper St. Pierre wrote:
> I've hacked on things all the from 1-5. Everything has a different
> development process, as usual, and I don't think there's any sense in
> trying to unify them. Writing documentation and getting people 
> started quicker is always great, but everybody's going to have their 
> own little things.

We obviously can't make all developers work the same way, and we don't
want to. But there should be a way that we can recommend that actually
*does* work :-)

> As for shell hacking, it's got increasingly more difficult to hack on
> things in a state like this, even under X11: launching a shell from a
> terminal loses things like search providers or some applications.
> There's issues with pkexec and other friends. Automounting USB keys
> never works when using jhbuild run. It feels strangely unclean and
> frustrating to work with. I just don't run a full shell as an X11
> compositor through jhbuild anymore. I do what I need to, then reboot
> to get back to a clean state.

Yeah. This type of thing is especially hard on newcomers, or simply
people who don't continually work on the shell, because only through
constant practice do you know *what* weirdness is due to a restarted
shell.

> You can run gnome-shell in a nested mode, but gnome-shell's forceful
> grabbing of DBus names mean that the nested gnome-shell gets
> notifications, screen lock goes to it, etc. I tend to only use mutter
> in nested mode for Wayland hacking.
>
> Having scripts or a better setup to keep my jhbuild builds mostly
> in-line with the system ones would be great.
>
> Full KMS-style Wayland hacking, for me, is mostly a separate machine
> ssh'd into my main computer, there to debug and keep a session going
> at all costs. I have issues, though, sometimes the keyring acts up 
> and eprompts for my ssh key on the terminal. Other times, I tend to 
> "lose session-ness" and basically restart at that point to get things
> working again.

If we could get nested working reliably, it certainly would be handy.
Not everybody has access to a second computer. (Saying that as someone
who is working as a nomad with a laptop for a couple of weeks.)

The basic equation here is that nested == multi-seat; making nested
work properly is draining the swamp of multi-seat issues.

As far as I understand it, there's a strong push on the part of the
systemd team to move from a session bus to a user bus; this probably
means that a single user logging into multiple seats - into a nested
session - is impractical. A single bus with components running from
multiple versions of GNOME seems like an endless source of debugging
headaches, even if we did all the work to move away from bus-global
names.

So nested == cross-user nested.

But it probably is better to concentrate on getting VT switching to
work well first, since a nested session is only an approximation of the
real thing.

> What would really help is making VT switching work better. On my
> systems with external monitors (like the ones I hack on at work), a
> single VT switch takes 2-3 seconds from fbcon and back to X. I don't
> know if this is Xorg or fbcon or just the VT layer in general, but it
> is noticeable, and it is frustrating. I don't know if systemd
> -consoled / logind / "the VT replacement API" would help here at all.

Yep.

> Figuring out what "session-ness" means and how to gain it when simply
> ssh'd in would also be great, but I have a feeling it's simply twenty
> different environment variables I have to port over one by one.

As you know, there are multiple scripts floating around for this, all
pretty hacky. An official solution would be great.

- Owen