Track request for emacs snap

store-requests
#1

The latest development version of emacs includes support for an optional display backend called pgtk. This implements support for being a native Wayland client (rather than the traditional X/gtk display backend which uses XWayland).

However, it is only recommended to use this backend under Wayland - it has known bugs/regressions when being used under a traditional X server. However this new backend does come with additional features like high DPI support and others. As such there is a demand from users of the emacs snap to have this backend enabled and supported.

It is not really feasible to ship emacs builds both with and without this backend and dynamically choose which one to use on launch, so instead I am requesting a separate pgtk track for emacs where this can then be enabled and opted-in to by users who wish to do so. It is not clear when the known issues with pgtk under X will be fixed upstream (so the lifetime of this track is indefinite at this time) but if/when they are I would then plan to enable pgtk by default in the default track close this new track so users are diverted back to the default track but would still maintain feature parity.

Let me know if there is any other information that is required.

#2

Hi, I’m +1 on the pgtk track for emacs - builds of the same snap with slighly different requirements and supported infrastructure are a good use case for tracks.

Just one thing - " I would then plan to enable pgtk by default in the default track close this new track so users are diverted back to the default track" - keep in mind that tracks have no fallback mechanism; people who installed from the pgtk track will continue to “track” it even if you close it. You will probably have to notify pgtk users some other way to nudge them to switch back to the default (latest?) track.

If you want fallback, then you could use a branch instead - as an upside it will divert people back to latest once you close it, but as downsides, it’s not as easily discoverable as a track, and you will need to refresh it every 29 days so it doesn’t close automatically.

  • Daniel
#3

Thanks for clarifying my misunderstanding on track vs branch @roadmr - I think probably a track is going to be easiest still and then if/when this would be closed I will add something to nudge users to manually switch to the latest track as you suggest.

#4

+1 from me as well on the pgtk track for emacs to support the optional backend as explained.

#5

I’ve created the track.

  • Daniel
#6

Thanks @roadmr - muchly appreciated.