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 <[email protected]> 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 > [email protected] > https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Jasper _______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
