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

["Jasper St. Pierre" <jstpierre mecheye net>]

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 
> bigger.
>
> 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
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list



-- 
  Jasper