-
Notifications
You must be signed in to change notification settings - Fork 626
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] Support wayland with layer shell #1139
Conversation
FWIW, Mir supports it too, and KDE has expressed interest in using it. |
7729b62
to
87c6239
Compare
Based on sardemff7 previous wayland attempt
- Fix mouse support - Handle key repeats - Positioning - Fix periodic count updates
a2b9d2d
to
9614a5d
Compare
I've simplified some code to remove duplication to a minimum and added support for high dpi (getting scale factors from the compositors, not using the Please have another look at the final result if you can ( |
From a user:
|
I couldn't find any problem calling If the problem persists I can try to reproduce it with more details (setup, nix derivation...). |
I can reproduce a segfault upon Esc with
{ stdenv, lib, fetchFromGitHub
, pkgconfig, libxkbcommon, pango, which, git, wayland-protocols
, cairo, libxcb, xcbutil, xcbutilwm, xcbutilxrm, libstartup_notification
, bison, flex, librsvg, check, meson, ninja, wayland }:
stdenv.mkDerivation rec {
pname = "rofi-wayland-unwrapped";
version = "unstable";
src = fetchFromGitHub {
owner = "lbonn";
repo = "rofi";
rev = "1806903a29b06acefee9d333c2a4ae44b9d702a2";
sha256 = "1f1p3d4y37phlyfa4f5wv0mgq35g57ahqc6xqynq2433gisxwir8";
fetchSubmodules = true;
};
preConfigure = ''
patchShebangs "script"
# root not present in build /etc/passwd
sed -i 's/~root/~nobody/g' test/helper-expand.c
'';
nativeBuildInputs = [ meson ninja pkgconfig ];
buildInputs = [ libxkbcommon pango cairo git bison flex librsvg check
libstartup_notification libxcb xcbutil xcbutilwm xcbutilxrm which
wayland-protocols wayland
];
doCheck = false;
meta = with lib; {
description = "Window switcher, run dialog and dmenu replacement";
homepage = "https://github.com/davatorium/rofi";
license = licenses.mit;
maintainers = with maintainers; [ mbakke ];
platforms = with platforms; linux;
};
}
{ symlinkJoin, lib, makeWrapper, hicolor-icon-theme
, pkgs, theme ? null, plugins ? [] }:
let
rofi-wayland-unwrapped = pkgs.callPackage (import ./default.nix) {};
in symlinkJoin {
name = "rofi-wayland-${rofi-wayland-unwrapped.version}";
paths = [
rofi-wayland-unwrapped.out
] ++ (lib.forEach plugins (p: p.out));
buildInputs = [ makeWrapper ];
preferLocalBuild = true;
passthru.unwrapped = rofi-wayland-unwrapped;
postBuild = ''
rm -rf $out/bin
mkdir $out/bin
ln -s ${rofi-wayland-unwrapped}/bin/* $out/bin
rm $out/bin/rofi
makeWrapper ${rofi-wayland-unwrapped}/bin/rofi $out/bin/rofi \
--prefix XDG_DATA_DIRS : ${hicolor-icon-theme}/share \
${lib.optionalString (plugins != []) ''--prefix XDG_DATA_DIRS : ${lib.concatStringsSep ":" (lib.forEach plugins (p: "${p.out}/share"))}''} \
${lib.optionalString (theme != null) ''--add-flags "-theme ${theme}"''} \
${lib.optionalString (plugins != []) ''--add-flags "-plugin-path $out/lib/rofi"''}
rm $out/bin/rofi-theme-selector
makeWrapper ${rofi-wayland-unwrapped}/bin/rofi-theme-selector $out/bin/rofi-theme-selector \
--prefix XDG_DATA_DIRS : $out/share
'';
meta = rofi-wayland-unwrapped.meta // {
priority = (rofi-wayland-unwrapped.meta.priority or 0) - 1;
};
} Running NixOS 20.03 and Sway. |
@ralsei Thanks! I've spawned a qemu image running nixos 20.03 but could not reproduce the segfault. Roughly followed this guide to build the derivation: https://sandervanderburg.blogspot.com/2014/07/managing-private-nix-packages-outside.html. Sway, rofi and everything were running with default configuration. This default.nix can be used to spawn a
Could you maybe try to get a traceback with gdb? |
@ralsei I just added this Rofi branch as an overlay in NixOS 20.03, using your Nix expression. I didn't change wrapper.nix (or the @lbonn |
Yes, that's a known limitation, there is no wm-agnostic way to get a full window list on wayland as far as I know. As a replacement, I'm using this external program with rofi in dmenu mode under sway https://github.com/lbonn/i3-focus-last/tree/menu-plus. |
You may want to use the wlr-foreign-toplevel-management protocol for this. Maybe it would be better to keep this for a follow-up pull request, to keep this easier to review. |
After an irc chat, the maintainers declared they would veto any code using wlroots-specific protocols, in particular layer shell, as a matter of principle. The exact reason seems to be that they don't want to encourage a broader adoption of what they consider a bad design, too close to what exists on X11 and too different from another proposal that they made. This small battle does not really concern me, so I will soon open a simple fork of rofi with the changes from this PR. |
wlr-layer-shell is not specific to wlroots. implementations exist in Mir and in a Weston fork. KDE is definitely interested in implementing it as well. layer-shell is a candidate for inclusion in the ext namespace of wayland-protocols. If rofi vetos layer-shell, that just means it won't ever properly work on Wayland, sadly (since e.g. GNOME isn't interested in allowing third-party clients to draw shell UI components). |
The battle against layer shell has long, long since past. It's either layer shell or no Wayland support for rofi. Let your tired political nonsense die already, @sardemff7 |
small correction, because this does not seem to match what I said on IRC: I (I can only speak for myself) never said I would veto anything. I just mentioned that I do not have knowledge of wayland, the used protocols etc. and therefor I feel not comfortable to make a decision on the topic. I am currently very busy, so I don't have the time to dive into the topic. IRC quotes
|
@DaveDavenport Sorry if you feel I misrepresented your position. I will try to develop a bit further. There is no question that the problem is not that the review is taking too long (don't really mind waiting really). What I understood is that you trusted the judgement of @sardemff7 on this matter at the moment and he threatened to leave the project if it supported layer shell. He also said he left the final decision to you but to be honest I have the impression this was done to keep the question in an uncertain limbo state. De facto, this is blocked forever and, again, this is your right as maintainers. I was just a bit surprised as this situation was not clear to me at all by simply reading the existing public resources related to the project. Basically what I read was that maintainers were not interested in doing it themselves and asked people to stop asking them for this (perfectly understandable). Hopefully, there is no hard feeling, I just wanted to clarify the situation for the posterity. |
@sardemff7 hasn't written any rofi code in over a year so that threat seems a bit hollow. |
@sardemff7 has been and is a great support for me in this project. Him leaving because of this is not acceptable for me. I find it sad this discussion needs to take this tone. I would like to find a solution that will work for everybody.. |
Yeah, so do I. Just make sure the blame points the right direction. |
@lbonn I am interested in a Wayland fork. It could be called @DaveDavenport It sounds like Wayland support in mainline Rofi is not feasible right now. If the situation changes, a merge with the Wayland fork might be possible. |
It feels like having a rofi fork for wayland might be the right solution for now. I would like to make sure we keep in 'sync'. |
Sorry there were some misunderstanding (I'm in part to blame). Maintainers would still be ok for this to land when they have more review bandwidth and if we manage to craft a cleaner, less coupled architecture. So in the middle term I also agree we would have to keep a fork (as I believe the feature is already usable). I'll host something on my account in the following days and will close this PR to limit noise on this repo when it's ready. |
I'm glad to hear that a option for Wayland support is in the works. Please leave a comment here when it's ready. |
Here it is, in the default branch named wayland: https://github.com/lbonn/rofi |
Wow, that was remarkably easy and straightforward, what a great candidate for upstreaming |
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
As suggested in the discussions of #446, here is an implementation using the layer shell protocol.
I've based this work on the original wayland branch attempt from 2017.
Check list:
-normal-window
in wayland mode (optional)-monitor
in wayland mode (optional){wayland,xcb}/view.c
As far as I know, this protocol is only supported by wlroots compositors but broader adoption is hopefully on the way. This branch is my daily driver under sway and has been tested briefly on hikari and wayfire.
The code can probably be adapted to use xdg-shell (for example when running with -normal-window) and have basic support on any wayland compositor.
When compiling with wayland enabled, the original xcb implementation is still accessible when running with
-x11
or when launched in X11. One difference is that the window mode is not inmodi
in the default configuration in this case.About the code: while I tried to remove some duplication it still look a bit messy. Any input on ways to improve the organization would be welcome.
Ah and I've only touched meson, not autoconf. Is there a plan to only keep one of these two?