May you please have a look?
make[2]: Leaving directory '/root/rpmbuild/BUILD/xfce4-session-4.19.1/xfsm-shutdown-helper'
make[2]: *** No rule to make target 'xfce-wayland.desktop.in', needed by 'xfce-wayland.desktop'. Stop.
make[2]: *** Waiting for unfinished jobs....
make[2]: Entering directory '/root/rpmbuild/BUILD/xfce4-session-4.19.1'
/usr/bin/msgfmt --desktop --template xfce.desktop.in -d ./po -o xfce.desktop
make[2]: Leaving directory '/root/rpmbuild/BUILD/xfce4-session-4.19.1'
make[1]: *** [Makefile:608: all-recursive] Error 1
make: *** [Makefile:498: all] Error 2
No wayland! No xfce-wayland.desktop after make dist.
The difference between checking out screenshooter vs. settings (as example) is, that inside the protocols directory is a Makefile.am. Maybe a make dist tries to process the protocols folder compared a normal make dist. The instructions for ignoring WAYLAND is explicit mentioned inside that file. The libxfce4windowing for example also has a Makefile.am inside the protocols folder and reacts on ignoring it correctly. So I assume that this may be related to the issues triggered.
I've checking it out via
git clone --depth="1" --recurse-submodules https://gitlab.xfce.org/apps/xfce4-screenshooter.git
It generates a protocol subfolder inside xfce4-screenshooter
Please have a look in how the tree is processed in the atteched file. For the settings and other xfce related modules that require the procotols the same checkout with recursing submodules work properly.
Hi,
trying to build a new screenshooter version from git. But the recent changes prevents giving me a dist tarball. make works fine. make dist fails. Please have a look at the provided logs.
Hi,
I've switched from Fedora 39 to Fedora Rawhide (for testing purposes) and detected that the Vala Binding provided with Fedora Rawhide has issues with Gtk.MenuShell.append. I had to manually go through two files (the generated .c files) in the lib directory and had to set explicit casts there to get the plugin compiled again.
May I ask the maintainer of the notes plugin to have a review to my patch. I am sure the changes have to appear within the vala files so they properly generate correct *.c files.
Please note that on Fedora 39 everything is perfectly fine.
Rawhide: libvala-0.56.14-1.fc40.x86_64 vala-0.56.14-1.fc40.x86_64
Reference Issue: https://gitlab.gnome.org/GNOME/gtk/-/issues/5870
Thank you.
Please also check libxfce4windowing. Same issue.
I build xfce4 every week from git using the lines below together with a fresh checkout.
autogen.sh --prefix=/usr --sysconfdir=/etc --localstatedir=/var --enable-maintainer-mode --disable-debug --disable-gtk-doc --disable-wayland
make dist
I want the tar.bz2 files!
A normal "make" works... btw. The same issue with libxfce4windowing. make dist fails while make works.
Entirely new git clone. But I must admit that I did not clone any submodules or something like that.
Hi
I'm not using wayland here therefore libwindowing is compiled without wayland support. That one worked but settings still has some references to the wlr protocols. Maybe this needs to be looked into ?
Build Configuration:
* Installation prefix: /usr
* Debug Support: no
* X11 Support: yes
* Xrandr support: yes
* Xcursor support: yes
* Xorg libinput support: yes
* Libxklavier support: yes
* Libnotify support: yes
* Wayland Support: no
* UPower support: no
* Colord support: yes
* Mime settings (gio-unix) support: yes
* Sounds settings support: no
Now type "gmake" to compile.
make dist-bzip2 am__post_remove_distdir='@:'
make[1]: Entering directory '/home/xxx/Documents/xfce4-settings-master'
make distdir-am
make[2]: Entering directory '/home/xxx/Documents/xfce4-settings-master'
(GIT_DIR=./.git git log > .changelog.tmp \
&& mv .changelog.tmp ChangeLog; rm -f .changelog.tmp) \
|| (touch ChangeLog; echo 'Git directory not found: installing possibly empty changelog.' >&2)
fatal: not a git repository: './.git'
if test -d "xfce4-settings-4.19.0"; then find "xfce4-settings-4.19.0" -type d ! -perm -200 -exec chmod u+w {} ';' && rm -rf "xfce4-settings-4.19.0" || { sleep 5 && rm -rf "xfce4-settings-4.19.0"; }; else :; fi
test -d "xfce4-settings-4.19.0" || mkdir "xfce4-settings-4.19.0"
(cd protocols && make top_distdir=../xfce4-settings-4.19.0 distdir=../xfce4-settings-4.19.0/protocols \
am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: distdir)
make[3]: Entering directory '/home/xxx/Documents/xfce4-settings-master/protocols'
**make[3]: *** No rule to make target 'wlr-output-management-unstable-v1.c', needed by 'distdir'. Stop.**
make[3]: Leaving directory '/home/xxx/Documents/xfce4-settings-master/protocols'
make[2]: *** [Makefile:670: distdir-am] Error 1
make[2]: Leaving directory '/home/xxx/Documents/xfce4-settings-master'
make[1]: *** [Makefile:664: distdir] Error 2
make[1]: Leaving directory '/home/xxx/Documents/xfce4-settings-master'
make: *** [Makefile:772: dist] Error 2
/home/xxx/Documents
That you for our feedback. Even if this is the expected behaviour, this still is irritating.
Explaination: Monitor = Display (in case we use different terminologies)
Display left <-> Display Notebook <-> Display right
I open xfce4-terminal on the Notebook and make it fullscreen I open gcalculator on the left display I pick up, drag and move gcalculator from the left display over to the right display crossing the notebook display
Intended expected behaviour:
What is irritating 1:
What is irritting 2:
What I expect: And this is regardless of some specifications. Is that when I drop a window ontop of something fullscreen, that it stays there ontop because I want it there - ontop - and not behind.
From a use case perspective I opened the gcalculator and moved it intentionally where I want it to be. Close to some numbers that came out from e.g. a command line tool inside xfce4-terminal, so I can sum them up in the calculator.
I mean. Even the xfce4-panel pops up instantly to the front. Regardless of some layering issue.
Hi! This is causing problems. I have a multi monitor system. When I open e.g. xfce4-terminal on one of them and putting it into fullscreen, I used to be able to move another window from a different monitor (e.g. say a calculator) to the window with the terminal and had it stuck ontop of the xfce4-terminal.
Now with this change the calculator is being placed behind the xfce4-terminal rather than on-top as I would expect it (and how it used to be).
What happens is the following:
What happens now is this:
If this change is intended to be correct, then I'd suggest adding an event trigger that triggers a window move from another area into the fullscreenarea to become "top window" (if that explaination makes sense). Otherwise it makes no sense moving the window from outside (a different monitor) to an area where you have fullscreen. You want to have the window moving in to become top layer because you would want to have it there and use it there.
The panel for example automaticly registers that something moves in from a different monitor and therefore raises intself to become "top window" putting the xfce4-terminal (still in full screen mode) behind.
Nailed it. Thanks for reporting back.
@Tamaranch Please commit the patch to git. Thanks everyone!
I can confirm this to work.... What Tony might have been missing was regenerating Makefile.am -> Makefile.in which after configure recreates Makefile and then link the windowing.so to the pulseaudio-plugin.so
I will test with a sane checkout, apply the patch build a dist out of it and build with that...
reporting back!
Exactly. It does not need to be in the panel.pc. I did this only for testing the theory.
Adding the two lines into panel.pc added the libs to the linker and thus made sure the plugins had the library linked in.
So the solutions could be
works!
I am going to test rebuild by adding:
Libs: -L${libdir} -lxfce4panel-2.0 -lxfce4windowing-0 -lxfce4windowingui-0
to libxfce4panel.pc
So the panel gets linked to libxfce4windowing thus providing the windowing function inside panel as well as its plugins...
Therefore the function pointed inside libxfce4windoing can't be found at all. During compile it detects it but after runtime nothing provides it.
What I found out is that doing an ldd on the libxfce4panel.so as well as libpulseaudio-plugin.so does not contain any references to libxfce4windowing as I would expect.
libpulseaudio references to linxfce4panel though but the panel does not have any signs of libwindowing references via ldd....