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

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.

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.

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

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.

On Mon, Jul 20, 2015 at 4:11 PM, Owen Taylor <otaylor redhat com> wrote:
As we move to Wayland, some of the ways we used to work on the core parts of GNOME (like gnome-shell 
--replace) no longer work. I think this is a good time to look at how we hack on GNOME, how we can make it 
more standard and obvious for newcomers, and how we can make it easier.

We can classify hacking on "GNOME" (taken very widely) into the following:

 1) Hacking on system components that require hardware access (kernel drivers, NetworkManager)
 2) Hacking on system components that don't inherently require hardware access (kernel filesystems, 
systemd, polkit, gdm)
 3) Hacking on session level components (gnome-session, gnome-shell, gnome-settings-daemon), and the 
libraries they use (gnome-desktop, clutter)
 4) Hacking on libraries (gtk+)
 5) Hacking on applications

Which ones of these do you do? How do you do it? Is 'jhbuild run' sufficient for your needs? Do you log 
into a jhbuild session? as yourself? as a test user? Do you replace system level components? With 'make 
install'? By building packages? Do you use gnome-continuous?

4 and 5 are handled pretty well by jhbuild. I think we can do better in the future for 5 using xdg-app - 
application checkouts could be entirely self-contained, with 'make' automatically downloading the right 
version of the GNOME SDK if not already present.

3 seems like a place where we can make progress - the vague idea I have is:

 - Move our standard install location back to /opt
 - Have utility scripts that set up a test user
 - Have hotkeys that switch directly back and forth between the main session and the test user session and 
respawn the test session

We could theoretically address 2 by having our standard test setup to run in a VM, but a lot of aspects of 
the system don't test well in a VM - touchscreen input, multimonitor, networking UI, sound, etc. And 
running in a VM isn't possible with jhbuild, so we'd have to switch to gnome-continuous for builds, and 
it's not really designed for the same use case as jhbuild - the initial build and cycle times are much 

Addressing 1 systemically would not only require us to switch to gnome-continuous, it requires actually 
rebooting into the gnome-continuous tree - so in essence the user would be working in an ostree based 
operating system. This seems very much out of scope.

Thoughts? I feel that we don't have a good story for someone coming in and wanting to hack on the core 
parts of GNOME right now, but perhaps there are things that I'm not aware of.

- Owen
desktop-devel-list mailing list
desktop-devel-list gnome org


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