xfway: added support for alt-tab switcher

[Alex]

Hey Gaël,

great to hear that you are doing research for xfce4-panel wayland support !

I suppose you already saw the related GSoC proposal I added some months
ago [1] (that was before you picked up panel maintainership  .. the
proposal was not selected by anybody). I did not do that much research,
though I found wapanel [2] beeing nice as an rather minimal example, to
see how it can be done.

 > But for the time being, we can just make all plugins internal, since
their loading via GModule is the same whether they are internal or external

If that works out, it would be great ! Wapanel only does some rather
"raw" runtime-library-loading to load its plugins.

If you figured out the way to go for xfce4-panel wayland support, it
would be nice to have our wayland roadmap [3] up to date.

Cheers, Alex(xcons)

[1] https://wiki.xfce.org/projects/gsoc/start#xfce4-panel
[2] https://github.com/Firstbober/wapanel
[3] https://wiki.xfce.org/releng/wayland_roadmap

Am 02.08.22 um 19:31 schrieb Gaël Bonithon:
> I pretty much agree with all of this. I've been seriously looking into making the panel Wayland-compatible for the past few days, and it seems obvious that wlroots is the way to go.
>
> I'm thinking in particular of protocols layer shell [1] and foreign toplevel management [2]. For the first one, a library already exists to make things easier: Gtk Layer Shell [3]. For the second one, which covers at least part of the Libwnck features, a small library could be written, if necessary (I haven't tried to tinker with it yet).
>
> There is still the subject of external plugins, but that's another story. If we want to keep the idea of separate processes, it seems impossible to avoid making the panel itself a Wayland compositor to some extent, to find more or less the effect of the XEmbed protocol (Embedding Compositor in the official documentation [4], see also this recent discussion [5]).
>
> But for the time being, we can just make all plugins internal, since their loading via GModule is the same whether they are internal or external. This allows us to go ahead with the tests right away, as there is already enough to do with the above, knowing that each plugin may also have its own incompatibilities with Wayland.
>
> I tried to use the Xfwm4 port to Wayland-wlroots from adlo, but I couldn't use it from my current session. If it's not ready for that kind of use yet, or even if it is ready at all, maybe it's better to fall back to a stable and easy to configure/use wlroots-based compositor first. Because there are already enough problems that can come from what you test in the compositor. So I opted for Labwc [6], which seems to be quite good for this.
>
> I'm still hopeful that I'll eventually be able to merge Wayland compatibility into the current panel, but I haven't made enough progress to be sure. Maybe a separate component will be better. In any case, I guess I'll open an experimental merge request at some point, with Xfce 4.20 (minimum) as a horizon.
>
> Cheers,
> Gaël
>
> --
> [1] https://wayland.app/protocols/wlr-layer-shell-unstable-v1
> [2] https://wayland.app/protocols/wlr-foreign-toplevel-management-unstable-v1
> [3] https://github.com/wmww/gtk-layer-shell
> [4] https://wayland.freedesktop.org/docs/html/ch02.html#sect-Compositors-Embedding-Compositor
> [5] https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/74
> [6] https://github.com/labwc/labwc
>
> ------- Original Message -------
> On Monday, July 18th, 2022 at 9:08 PM, Andrzej <andrzejr at xfce.org> wrote:
>
>
>> On 18/07/2022 10:31, Alex wrote:
>>
>>>> All that to say, wlroots is probably the easiest way forward,
>>>> considering it replicates a lot of the EWMH design that xfce uses on X11.
>>> Great to hear that you would be open for that direction! Would you as
>>> well be fine with having Adlo's changes as a huge MR for xfwm4 sooner
>>> or later (assuming the x11 part will continue to work smoothly)
>>
>> I would vote for a solution that reuses as much of existing codebase and
>> preserves as many Xfce features as possible. Otherwise will end up with
>> a new environment inspired by Xfce, which will either have to be forced
>> upon Xfce users or work its way up the adoption ladder like any other
>> new DE. Both scenarios are bad.
>>
>>> Asking so, since I think it would be beneficial for Adlo and us to
>>> share the same long-term plans. If the changes have no hope for beeing
>>> merged into the current xfwm4 one day, I suppose it would make sense
>>> for Adlo to rename his project to something else than 'xfwm4', in
>>> order to dont confuse both projects.
>>
>> I would not merge anything more than a few ifdefs into Xfwm4 or other
>> existing Xfce applications. There is a lot of value in keeping the
>> existing X11 desktop stable and allowing it to evolve in parallel
>> without forcing anyone to fork and rename it first.
>>
>> Why not use xfway as the name of the compositor binary? It seems to fit
>> Xfce conventions well, both in the level of awkwardness and poorly
>> defined meaning ;-)
>>
>> I would like Xfway to be a part of Xfce (provided it will not hijack
>> it). The question is if Xfway itself is ready for incremental
>> development. Research and experimentation is still ongoing (and for a
>> good reason, this phase is important), wayland spec and implementations
>> (now wlroots, maybe something else someday) are evolving. Some cleanups
>> (naming and build system matching the rest of Xfce) would also be nice,
>> although this could be done later.
>>
>> Andrzej
>>
>>
>> _______________________________________________
>> Xfce4-dev mailing list
>> Xfce4-dev at xfce.org
>> https://mail.xfce.org/mailman/listinfo/xfce4-dev
> _______________________________________________
> Xfce4-dev mailing list
> Xfce4-dev at xfce.org
> https://mail.xfce.org/mailman/listinfo/xfce4-dev