search

WayfireWM / wayfire-plugins-extra

Additional plugins for Wayfire
MIT License
66 stars 29 forks source link

Background-view very unstable #128

Closed UltraBlackLinux closed 2 years ago

UltraBlackLinux commented 2 years ago

Hey there, I've been using background-view for quite a while now, but it's a bit unstable, if you are using programs that need to be restarted to apply settings. It mostly seems to come down to wayfire crashing, when starting/stopping the background-view plugin while the background process is dead. Please fix this, I assume that the other toggling crashes will be fixed by something like this! Thanks!

soreau commented 2 years ago

Hi, if you need to restart the app, a workaround could be to toggle the plugin disabled/enabled, while the app is still running. This should restart the app in question. This would only be a workaround, of course we don't want wayfire to ever crash. I will have to look into this further to see how we can fix it.

UltraBlackLinux commented 2 years ago

This is sadly not really a workaround, if the program crashed when it's started, so wayfire will crash trying to kill the process.

soreau commented 2 years ago

Can you post the backtrace from wayfire when it crashes? It should be the last thing in the log, which is the stdout of wayfire.

soreau commented 2 years ago

Can you see if #129 fixes the issue you are having?

UltraBlackLinux commented 2 years ago

Can you see if #129 fixes the issue you are having?

This did fix the instability issues, but now the background-view windows are no longer in the background, but rather opened as a seperate window, and this on every desktop

soreau commented 2 years ago

Are you sure you have set the application identifier field correctly? It must match the app-id for the window or else it won't be placed on the background. If you don't know what it is, wayfire outputs this information in the log.

UltraBlackLinux commented 2 years ago

Are you sure you have set the application identifier field correctly? It must match the app-id for the window or else it won't be placed on the background. If you don't know what it is, wayfire outputs this information in the log.

I am sure, yeah. It was working before, when it was very unstable

soreau commented 2 years ago

Yes but before, there were two mechanisms. One for app-id and another for pid match. Since pid matching is unreliable, I removed this, so the app-id must match or else it won't work. It is working here in my tests, so I think that you should double or triple check the app-id is correct including case.

soreau commented 2 years ago

another way to check the app-id is with wf-prop which is included with dbus plugin, which is built when passing -Denable_dbus=true to w-p-e meson. Run wf-prop in a terminal, click the window and see the app-id for it.

EDIT: Don't forget to enable dbus plugin first.

UltraBlackLinux commented 2 years ago

Yes but before, there were two mechanisms. One for app-id and another for pid match. Since pid matching is unreliable, I removed this, so the app-id must match or else it won't work. It is working here in my tests, so I think that you should double or triple check the app-id is correct including case.

is the app-id not what you see as process name in ps aux?

soreau commented 2 years ago

No, the app-id is something different. Applications set their app id using the wayland xdg protocol. If you install and enable dbus plugin, wf-prop will be available and it's probably the best/easiest way to get the app-id for any surface, reliably.

UltraBlackLinux commented 2 years ago

another way to check the app-id is with wf-prop which is included with dbus plugin, which is built when passing -Denable_dbus=true to w-p-e meson. Run wf-prop in a terminal, click the window and see the app-id for it.

EDIT: Don't forget to enable dbus plugin first.

Trying this failed annoyingly: 

../subprojects/dbus/dbus_interface.cpp:28:10: fatal error: wayfire/plugins/common/view-change-viewport-signal.hpp: No such file or directory
   28 | #include <wayfire/plugins/common/view-change-viewport-signal.hpp>
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.

I figured this is supposed to be shipped with wayfire-git, but the file just doesn't exist there.

soreau commented 2 years ago

Aha, thanks for letting me know. Apparently I still have this file from old. You will have to install it separately from here or apply this patch to subprojects/dbus.

UltraBlackLinux commented 2 years ago

Aha, thanks for letting me know. Apparently I still have this file from old. You will have to install it separately from here or apply this patch to subprojects/dbus.

FAILED: subprojects/dbus/wf-prop.p/wf-prop.cpp.o
ccache c++ -Isubprojects/dbus/wf-prop.p -Isubprojects/dbus -I../subprojects/dbus -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/sysprof-4 -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/giomm-2.4 -I/usr/lib/giomm-2.4/include -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -Wextra -std=c++17 -O3 -DWLR_USE_UNSTABLE -DWAYFIRE_PLUGIN -pthread -MD -MQ subprojects/dbus/wf-prop.p/wf-prop.cpp.o -MF subprojects/dbus/wf-prop.p/wf-prop.cpp.o.d -o subprojects/dbus/wf-prop.p/wf-prop.cpp.o -c ../subprojects/dbus/wf-prop.cpp
In file included from /usr/include/glib-2.0/glib/glib-typeof.h:39,
                 from /usr/include/glib-2.0/glib/gatomic.h:28,
                 from /usr/include/glib-2.0/glib/gthread.h:32,
                 from /usr/include/glib-2.0/glib/gasyncqueue.h:32,
                 from /usr/include/glib-2.0/glib.h:32,
                 from /usr/include/glib-2.0/gobject/gbinding.h:28,
                 from /usr/include/glib-2.0/glib-object.h:22,
                 from /usr/include/glib-2.0/gio/gioenums.h:28,
                 from /usr/include/glib-2.0/gio/giotypes.h:28,
                 from /usr/include/glib-2.0/gio/gio.h:26,
                 from ../subprojects/dbus/wf-prop.cpp:10:
/usr/include/c++/12.1.0/type_traits:44:3: error: template with C linkage (a lot of these now, somewhat the same)

What is this now - I just applied the patch

soreau commented 2 years ago

This should do the trick, if ran starting from the wayfire-plugins-extra directory:

cd subprojects/dbus
git reset --hard HEAD
git checkout c705bf1
git pull origin master
curl https://github.com/soppelmann/wayfire-plugin_dbus_interface/commit/dbd06ec085851c4e08bc984bb7903b9b363b654b.diff | git apply
cd ../..

then try the build again.

UltraBlackLinux commented 2 years ago

This should do the trick, if ran starting from the wayfire-plugins-extra directory:

cd subprojects/dbus
git reset --hard HEAD
git checkout c705bf1
git pull origin master
curl https://github.com/soppelmann/wayfire-plugin_dbus_interface/commit/dbd06ec085851c4e08bc984bb7903b9b363b654b.diff | git apply
cd ../..

then try the build again.

Oh yeah this worked, so I guess I applied the patch incorrectly?

So how do I use wf-prop? there is no way to set a window for it to scan xD

soreau commented 2 years ago

Well first you have to restart wayfire since installing a new plugin so the metadata is read by wf-config. Then you need to enable dbus. Once you have dbus plugin enabled, you run wf-prop in a terminal and the cursor will turn into a crosshair. Then you click on any window and wf-prop will return information about the window in the terminal.

UltraBlackLinux commented 2 years ago

I did enable dbus and didn't have to restart wayfire, but just tried logging out and back in again, and yet wf-prop refuses to show the crosshair-cursor. The wayfire dbus interface doesn't exist either.

wf-prop l: 

ERROR:../subprojects/dbus/wf-prop.cpp:550:int main(int, char**): assertion failed (error == NULL): GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.wayland.compositor was not provided by any .service files (g-dbus-error-quark, 2)
Bail out! ERROR:../subprojects/dbus/wf-prop.cpp:550:int main(int, char**): assertion failed (error == NULL): GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.wayland.compositor was not provided by any .service files (g-dbus-error-quark, 2)
zsh: IOT instruction (core dumped)  wf-prop l
soreau commented 2 years ago

It sounds like dbus isn't enabled for your session. You can also find the app-id in the log, which is the stdout of wayfire. If you redirect the output of wayfire to file, then that is the log. You can find the app-id there, which appears as a message like this:

II 21-05-22 12:01:02.836 - [src/view/xdg-shell.cpp:201] new xdg_shell_stable surface: Wayfire Config Manager app-id: wcm

So when you enable background-view and it starts the app, there should be some messages like this in the log and you can match the app-id in the plugin.

UltraBlackLinux commented 2 years ago

It sounds like dbus isn't enabled for your session. You can also find the app-id in the log, which is the stdout of wayfire. If you redirect the output of wayfire to file, then that is the log. You can find the app-id there, which appears as a message like this:

II 21-05-22 12:01:02.836 - [src/view/xdg-shell.cpp:201] new xdg_shell_stable surface: Wayfire Config Manager app-id: wcm

So when you enable background-view and it starts the app, there should be some messages like this in the log and you can match the app-id in the plugin.

Dbus is enabled, and I am actively using it for some compatibility stuff, that I read about in the wayfire wiki (dbus-update-activation-environment --systemd WAYLAND_DISPLAY DISPLAY XAUTHORITY XDG_CURRENT_DESKTOP)

Also how do I obtain those logs. They don't get sent to journalctl. I can open a mini-wayfire inside of wayfire, but I can't open programs there because all keybinds just open programs in my window

... Why is it so hard to just get the background-view to work

soreau commented 2 years ago

when you open wayfire nested inside of wayfire, you should see the output in the terminal. So wayfire |& grep app-id and then start the app, it should spit the id.

UltraBlackLinux commented 2 years ago

when you open wayfire nested inside of wayfire, you should see the output in the terminal. So wayfire |& grep app-id and then start the app, it should spit the id.

... this is weird: new xdg_shell_stable surface: WallpaperEngine app-id: (null)

soreau commented 2 years ago

Ok, so just make the app-id blank?

UltraBlackLinux commented 2 years ago

Ok, so just make the app-id blank?

isn't that kinda dangerous if other apps also get blank app-ids?

Also that didn't work

soreau commented 2 years ago

After doing some debugging, you should set it to "nil" and it should match. There shouldn't be any danger matching other apps because it only matches the first nil app-id after launching the app, and ignores others after that.

UltraBlackLinux commented 2 years ago

Yep, I can confirm, that nil works, though one question still persists: Why is dbus not working? I would love to use wf-msg, since I think swaymsg is a very useful program. Also wf-robs seems pretty useful, but I can't use that if the dbus thing does not appear when enabling the dbus plugin

The problem might be related to the glib-main-loop plugin, that it wants to be activated, but which I can't activate, because it doesn't have a way to do so

marcusbritanicus commented 2 years ago

@UltraBlackLinux you'll have to debug it by starting a wayfire session in your currently running session. If there was some problem in loading the dbus plugin, that would be printed on the terminal output of your new wayfire session.

However, I wonder how it could be related to glib-main-loop: when you enable dbus plugin, glib-main-loop is automatically loaded.

soreau commented 2 years ago

I built the same dbus code I had you build and it is indeed broken as you described. To get it working here I did this:

cd subprojects/dbus
git reset --hard c705bf1
curl http://ix.io/3YmU | git am
cd ../..

build dbus again and restart wayfire.

UltraBlackLinux commented 2 years ago

I built the same dbus code I had you build and it is indeed broken as you described. To get it working here I did this:

cd subprojects/dbus
git reset --hard c705bf1
curl http://ix.io/3YmU | git am
cd ../..

build dbus again and restart wayfire.

Back to this again. This is a very annoying procedure apparently. EDIT: Fix link

soreau commented 2 years ago

Yes, I think you need this so I added it to the patch. Run the same set of commands again to apply the patch again.

UltraBlackLinux commented 2 years ago

Yep, that worked. Dbus is now visible in the list of dbus compositors and wf-prob works (only the crosshair doesn't, but that's a minor issue, that you can probably ignore)

Please push this, I don't want it gone, when I update WPE