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

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

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

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.


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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]