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