Closed probonopd closed 3 years ago
probonopd
commented
3 years ago When kwin_x11 is running and we then launch the Menu, it is moved outside of the area it has reserved for itself:
@PreyK do you have an idea what might be causing this or how we could avoid this?
PreyK
commented
3 years ago @probonopd As far as i remember the menubar reserves an area with a “fake” invisible widget from the screen. My best guess is that this was a hack to try to make it that we cant drag stuff under the menu but it didn’t make much sense to me. (Was investigating this for a while)
On the screenshot it looks like Kwin is trying to stack the 2 widgets wich is probably the correct way the layout written in the code should work it just behaved differently under openbox?
Will look into this to confirm.
probonopd
commented
3 years ago This is what happens if you try to install the plasma5-kwin package. It would grow the ISO by over 100 MB. Looking at the dependencies I wonder whether one could make e.g., a kwin-x11-minimal package that would not draw in the non-essential dependencies.
FreeBSD% sudo pkg install plasma5-kwin
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
The following 110 package(s) will be affected (of 0 checked):
New packages to be INSTALLED:
aspell: 0.60.8_1,1
boost-libs: 1.72.0_4
brotli: 1.0.9,1
docbook: 1.5
docbook-sgml: 4.5_1
docbook-xml: 5.0_3
docbook-xsl: 1.79.1_1,1
dotconf: 1.3_1
espeak: 1.48.04_7
fftw3: 3.3.9
flac: 1.3.3
gnupg: 2.2.27
gpgme: 1.15.1
gpgme-cpp: 1.15.1
gpgme-qt5: 1.15.1
gstreamer1-libav: 1.16.2
gstreamer1-plugins-a52dec: 1.16.2
gstreamer1-plugins-core: 1.16
gstreamer1-plugins-dts: 1.16.2
gstreamer1-plugins-dvdread: 1.16.2_1
gstreamer1-plugins-mpg123: 1.16.2
gstreamer1-plugins-pango: 1.16.2
gstreamer1-plugins-png: 1.16.2
gstreamer1-plugins-resindvd: 1.16.2_1
gstreamer1-plugins-theora: 1.16.2
gstreamer1-plugins-ugly: 1.16.2
hyphen: 2.8.8
iso8879: 1986_3
kf5-attica: 5.80.0
kf5-breeze-icons: 5.80.0
kf5-frameworkintegration: 5.80.0
kf5-kactivities: 5.80.0
kf5-karchive: 5.80.0
kf5-kauth: 5.80.0
kf5-kbookmarks: 5.80.0
kf5-kcmutils: 5.80.0
kf5-kcodecs: 5.80.0
kf5-kcompletion: 5.80.0
kf5-kconfigwidgets: 5.80.0
kf5-kcrash: 5.80.0
kf5-kdeclarative: 5.80.0
kf5-kded: 5.80.0
kf5-kdelibs4support: 5.80.0
kf5-kdesignerplugin: 5.80.0
kf5-kdewebkit: 5.80.0
kf5-kdoctools: 5.80.0
kf5-kemoticons: 5.80.0
kf5-kglobalaccel: 5.80.0
kf5-kguiaddons: 5.80.0
kf5-kiconthemes: 5.80.0
kf5-kidletime: 5.80.0
kf5-kinit: 5.80.0
kf5-kio: 5.80.1
kf5-kirigami2: 5.80.0
kf5-kitemmodels: 5.80.0
kf5-kitemviews: 5.80.0
kf5-kjobwidgets: 5.80.0
kf5-knewstuff: 5.80.0
kf5-knotifications: 5.80.0
kf5-kpackage: 5.80.0
kf5-kparts: 5.80.0
kf5-kplotting: 5.80.0
kf5-kservice: 5.80.0
kf5-ktextwidgets: 5.80.0
kf5-kunitconversion: 5.80.0
kf5-kwallet: 5.80.0
kf5-kwayland: 5.80.0
kf5-kwidgetsaddons: 5.80.0
kf5-kxmlgui: 5.80.0
kf5-plasma-framework: 5.80.0
kf5-solid: 5.80.0
kf5-sonnet: 5.80.0
liba52: 0.7.4_3
libassuan: 2.5.4
libcanberra: 0.30_5
libcanberra-gtk3: 0.30_5
libdca: 0.0.7
libksba: 1.5.0
libsndfile: 1.0.31
mpg123: 1.26.5
npth: 1.6
phonon-qt5: 4.11.1
pinentry: 1.1.1
pinentry-curses: 1.1.1
pinentry-qt5: 1.1.1
plasma-wayland-protocols: 1.2.1
plasma5-breeze: 5.20.5
plasma5-kdecoration: 5.20.5
plasma5-kscreenlocker: 5.20.5
plasma5-kwayland-server: 5.20.5
plasma5-kwin: 5.20.5_1
portaudio: 19.6.0_5,1
qt5-assistant: 5.15.2
qt5-designer: 5.15.2_1
qt5-help: 5.15.2_1
qt5-qdbus: 5.15.2
qt5-sensors: 5.15.2_1
qt5-speech: 5.15.2
qt5-uiplugin: 5.15.2
qt5-uitools: 5.15.2_1
qt5-virtualkeyboard: 5.15.2_1
qt5-wayland: 5.15.2_1
qt5-webkit: 5.212.0.a4_4
sdocbook-xml: 1.1_2,2
speech-dispatcher: 0.8.8_1
woff2: 1.0.2_4
xcb-util-cursor: 0.1.3
xmlcatmgr: 2.2_2
xmlcharent: 0.3_2
xwayland-devel: 1.20.0.907
Number of packages to be installed: 110
The process will require 552 MiB more space.
108 MiB to be downloaded.cc'ing @jbeich @adriaandegroot. tl;dr: helloSystem is a Qt based FreeBSD-based system that does not use the KDE Plasma desktop but its own Qt-based helloDesktop, and we would like to use KWin without having to install "half of KDE Plasma". We are also not interested in Wayland in any way, form or shape, especially given its current state on FreeBSD.
adriaandegroot
commented
3 years ago "half of KDE-Plasma" is a terrible way to characterize this. Wayland works remarkably well on FreeBSD -- just not KDE Plasma. You'll note that all the things jbeich@ works on (or maintains in ports), work well.
A fair chunk of what you're seeing here is like what you had in Falkon, previously, and which I explained there: packaging is a "batteries included" exercise most of the time, so you get all the bits.
Some more effort from the helloSystem side on making packages more lightweight through flavors (like falkon@qtonly) even if it's just small patches ("here's a patch to make a @lite flavor of KWin; it's not very lite yet, but drops Wayland support" or "kwin depends on webkit through ... is that really necessary?") would go a long way here.
BTW, FreeBSD PR 241490 may also be relevant for you. I suppose with "real" graphics you do need a real mesa-DRI, but keep in mind what elephant (I think it was jbeich@ who said it) gets dragged in by that.
jbeich
commented
3 years ago kf5-wayland and plasma5-kwayland-server are REQUIREDkf5-breeze (pulls 76Mb large kf5-breeze-icons) is OPTIONAL but plasma5-kwin also has indirect dependency on itX11-only or Wayland-only flavors cannot be implemented globally for all packages due to lack of provides/requires support to avoid exploding the number of packages. For example, in A -> B -> C -> D dependency chain A has @nowayland flavor but supporting it currently requires propagating the flavor into B/C/D, none of which care whether A was built with or without Wayland support.
jbeich
commented
3 years ago All Wayland dependencies combined likely take less than plasma5-kwin alone.
adriaandegroot
commented
3 years ago Thanks @jbeich , confirms what I was thinking that Wayland is not the problem here. I've got a patch lined up for ports that turns KDE_USE=doctools into KDE_USE=doctools_build for most everything. That drops the docbook and related deps from kwin, at least. The doctools are really not needed, not even in the "batteries included" style of most FreeBSD ports.
From that table of "extra space" getting rid of boost would be a real win. The point of intersection between pkg info -d plasma5-kwin and pkg info -r boost-libs is kf5-kactivities. That has a stated LIB_DEPENDS on boost, but ldd doesn't mention it. Looking at the source, it seems it's only algorithms from boost being used, so that could go to a BUILD_DEPENDS instead and then we're pretty good (except to the extent that boost might be needed for the installed headers, so we're skirting along the edge of "when do dev-tools get installed").
probonopd
commented
3 years ago Thank you very much for looking into this topic.
here's a patch to make a @lite flavor of KWin
Yes, that's what I was thinking of. Was thinkinging that it wouldn't hurt to informally discuss with you the experts first.
Do you think it would be a good idea to have kwin-x11-lite and possibly kwin-wayland-lite packages?
adriaandegroot
commented
3 years ago As Jan points out:
Effective changes I have already implemented, but not pushed to the ports tree (they'll land together with Plasma 5.21):
Things on @probonopd 's plate then are:
probonopd
commented
3 years ago This took some time but finally I have solved this:
It's easy when you know the solution - https://stackoverflow.com/a/27964691 led me to using KWindowSystem::setType(winId(), NET::Dock); and as a result this issue is no more. Strange that KWindowSystem::setType(winId(), NET::TopMenu); does not seem to be doing the trick. cc @PreyK
probonopd
commented
3 years ago KWin seems to use kglobalaccel5 for keyboard shortcuts, e.g., to switch from window to window with Alt-Tab. To change those, one apparently needs to use skel as those cannot be changed system-wide?!
adriaandegroot
commented
3 years ago KWin seems to use
kglobalaccel5for keyboard shortcuts, e.g., to switch from window to window with Alt-Tab. To change those, one apparently needs to useskelas those cannot be changed system-wide?!
You are linking to a discussion from 2013 that is discussing kde4-era kwin. You'd have a better time asking current Kwin folk on one of their support channels. There is a #kwin IRC channel on Freenode.
adriaandegroot
commented
3 years ago Effective changes I have already implemented, but not pushed to the ports tree (they'll land together with Plasma 5.21):
This has landed, and it'd be good to hear if that helps out your dependency size any.
probonopd
commented
3 years ago Thank you very much @adriaandegroot for you help, this is tremendous.
kettle-7
commented
3 years ago I tried installing the plasma5-kwin package, and it only threw 7 dependencies at me:
The following 7 package(s) will be affected (of 0 checked):
New packages to be INSTALLED:
kf5-kidletime: 5.80.0
plasma-wayland-protocols: 1.2.1
plasma5-kscreenlocker: 5.20.5
plasma5-kwayland-server: 5.20.5
plasma5-kwin: 5.20.5_1
xcb-util-cursor: 0.1.3
xwayland-devel: 1.20.0.917
Number of packages to be installed: 7
The process will require 28 MiB more space.
7 MiB to be downloaded.Everything else is just pulled in by kf5-breeze-icons, which I installed because of another project I'm making. None of these packages are that big, so it's clearly the breeze icon theme with all of its SVG icons for every button or mimetype you can imagine.
kettle-7
commented
3 years ago So far, so good. kwin_x11 --replace absolutely nuked the desktop, so I had to log out and back in again. I edited start-hello to start KWin instead of openbox and picom and it works, so something tells me that KWin and Picom don't agree with each other. Also, there's a chunk missing out of the bottom-right corner of every window, is this normal?
2 things I noticed:
probonopd
commented
3 years ago A future release will come with kwin_x11 out of the box. I am running it locally since a month now and am happy with it. It does require quite a bit of configuration, so I suggest to just wait until it appears fully pre-configured in helloSystem.
KWin and Picom don't agree with each other
kwin_x11 has picom-like functionality built in, so you don't need picom anymore.
The window borders
All of this needs to be heavily configured so that it looks and works like we want in helloSystem. I have such a configuation locally and it looks like this:
kettle-7
commented
3 years ago I like the window control layout that you're using with openbox, close on the left and max on the right.
jhjacobs81
commented
3 years ago how did elementaryos did it? they wrote their own desktop environment i believe, would that not be possible for helloSystem too? (jus thinking out loud here) Then it would be possible to slim down on all the extra requirements?
probonopd
commented
3 years ago elementary OS is using Gtk, which we do not want to use. kwin_x11 does the job nicely, been using it for a while now.
kettle-7
commented
3 years ago You can get some good traffic light kwin themes on the KDE store (another of those annoying pling ones!)
probonopd
commented
3 years ago Let's move away from traffic lights to look less like "a Mac theme". Remember, the goal is to be "welcoming to switchers" but not to be a "Mac theme". The colors can be disturbing anyway.
kettle-7
commented
3 years ago There is a Qml module specifically for writing compositing window managers, I'll try find it.
kettle-7
commented
3 years ago Are you using Breeze Enhanced?
probonopd
commented
3 years ago Yes, for the upcoming kwin_x11 we are using a custom patched version of it: https://github.com/helloSystem/BreezeEnhanced
The reason why we need a custom patched version is explained here: https://github.com/tsujan/BreezeEnhanced/issues/32
probonopd
commented
3 years ago I tried installing the plasma5-kwin package, and it only threw 7 dependencies at me
Strange, I now built an ISO with latest rather than quarterly packages (so that we benefit from all recent changes in packaging) and plasma5-kwin, and the resulting Live ISO (compressed) is 1.61 GB, up from 1.27 GB. 340 MB (compressed) just for adding a window manager is still something that I cannot understand. Need to look into this more deeply.
kettle-7
commented
3 years ago Check how much is icons: that is quite far up the size list.
It might be possible to use kwin with elementary-xfce icons, that would shrink the ISO a bit. Installing breeze just for the window manager seems a bit overkill.
probonopd
commented
3 years ago Installing breeze just for the window manager seems a bit overkill.
Totally.
probonopd
commented
3 years ago Hello @jbeich thanks for your analysis. I am just trying to understand this for now. Why is it that kwin_x11 (not kwin_wayland!) also depends on many Wayland components?
FreeBSD% ldd $(which kwin_x11) | grep ayl
libKF5WaylandClient.so.5 => /usr/local/lib/libKF5WaylandClient.so.5 (0x801602000)
libKWaylandServer.so.5 => /usr/local/lib/libKWaylandServer.so.5 (0x80245a000)
libwayland-server.so.0 => /usr/local/lib/libwayland-server.so.0 (0x802c88000)
libwayland-client.so.0 => /usr/local/lib/libwayland-client.so.0 (0x804217000)
libKF5WaylandServer.so.5 => /usr/local/lib/libKF5WaylandServer.so.5 (0x804237000)
libQt5WaylandClient.so.5 => /usr/local/lib/qt5/libQt5WaylandClient.so.5 (0x80552b000)
libwayland-cursor.so.0 => /usr/local/lib/libwayland-cursor.so.0 (0x805ef7000)Can these dependencies be removed, or can those libraries be replaced by stubs that do nothing? I guess I am just having a hard time understanding why there is an x11 specific version of kwin when in the end it, too, depends on Wayland stuff.
probonopd
commented
3 years ago I have identified many dependencies without with kwin_x11 can still run. This list is not exhaustive.
plasma5-kwin package depend on kf5-krunner?sh -c 'for FILE in $(pkg list kf5-krunner) ; do rm $FILE ; done' --> kwin_x11 still works.
This dependency may be a candidate for removal because it appears not to be strictly required.
FreeBSD% sudo pkg remove kf5-krunner
Checking integrity... done (0 conflicting)
Deinstallation has been requested for the following 2 packages (of 0 packages in the universe):
Installed packages to be REMOVED:
kf5-krunner: 5.82.0
plasma5-kwin: 5.21.5
Number of packages to be removed: 2
The operation will free 24 MiB.plasma5-kwin package depend on kf5-knewstuff?sh -c 'for FILE in $(pkg list kf5-knewstuff) ; do rm $FILE ; done' --> kwin_x11 still works.
This dependency may be a candidate for removal because it appears not to be strictly required.
plasma5-kwin package depend on kf5-frameworkintegration?sh -c 'for FILE in $(pkg list kf5-frameworkintegration) ; do rm $FILE ; done' --> kwin_x11 still works.
This dependency may be a candidate for removal because it appears not to be strictly required.
plasma5-kwin package depend on kf5-breeze-icons?sh -c 'for FILE in $(pkg list kf5-breeze-icons) ; do rm $FILE ; done' --> kwin_x11 still works.
This dependency may be a candidate for removal because we are using another theme.
plasma5-kwin package depend on plasma5-breeze?sh -c 'for FILE in $(pkg list plasma5-breeze) ; do rm $FILE ; done' --> kwin_x11 still works.
This dependency may be a candidate for removal because we are using another theme.
plasma5-kwin package depend on kf5-kauth?sh -c 'for FILE in $(pkg list kf5-kauth) ; do rm $FILE ; done' --> kwin_x11 still works.
This dependency may be a candidate for removal because it appears not to be strictly required.
plasma5-kwin package depend on kf5-kwallet?sh -c 'for FILE in $(pkg list kf5-kwallet) ; do rm $FILE ; done' --> kwin_x11 still works.
This dependency may be a candidate for removal because it appears not to be strictly required.
plasma5-kwin package depend on kf5-kparts?sh -c 'for FILE in $(pkg list kf5-kparts) ; do rm $FILE ; done' --> kwin_x11 still works.
This dependency may be a candidate for removal because it appears not to be strictly required.
plasma5-kwin package depend on kf5-kparts?sh -c 'for FILE in $(pkg list kf5-kparts) ; do rm $FILE ; done' --> kwin_x11 still works.
This dependency may be a candidate for removal because it appears not to be strictly required.
plasma5-kwin package depend on kf5-kdesignerplugin?sh -c 'for FILE in $(pkg list kf5-kdesignerplugin) ; do rm $FILE ; done' --> kwin_x11 still works.
This dependency may be a candidate for removal because it appears not to be strictly required.
plasma5-kwin package depend on kf5-kdelibs4support?sh -c 'for FILE in $(pkg list kf5-kdelibs4support) ; do rm $FILE ; done' --> kwin_x11 still works.
This dependency may be a candidate for removal because it appears not to be strictly required.
plasma5-kwin package depend on kf5-kded?sh -c 'for FILE in $(pkg list kf5-kded) ; do rm $FILE ; done' --> kwin_x11 still works.
This dependency may be a candidate for removal because it appears not to be strictly required.
plasma5-kwin package depend on kf5-kinit?sh -c 'for FILE in $(pkg list kf5-kinit) ; do rm $FILE ; done' --> kwin_x11 still works.
This dependency may be a candidate for removal because it appears not to be strictly required.
plasma5-kwin package depend on kf5-kinit?sh -c 'for FILE in $(pkg list kf5-kinit) ; do rm $FILE ; done' --> kwin_x11 still works.
This dependency may be a candidate for removal because it appears not to be strictly required.
plasma5-kwin package depend on kf5-kcmutils?sh -c 'for FILE in $(pkg list kf5-kcmutils) ; do rm $FILE ; done' --> kwin_x11 still works.
This dependency may be a candidate for removal because it appears not to be strictly required.
plasma5-kwin package depend on kf5-kitemodels?sh -c 'for FILE in $(pkg list kf5-kitemodels) ; do rm $FILE ; done' --> kwin_x11 still works.
This dependency may be a candidate for removal because it appears not to be strictly required.
probonopd
commented
3 years ago Furthermore, I have identified candidates for being made optional in source code.
These cannot just be left away in packaging (otherwise kwin_x11 will not run anymore as-is) but they could possibly be made optional in the source code, e.g., by using dlopen() rather than compiling in a hard dependency on them.
If making them "weak dependencies" is not desitable for the plasma5-kwin package, then maybe a kwin-lite package could be made with dependencies like these removed from the source code.
kf5-kactivities be made optional?FreeBSD% kwin_x11
ld-elf.so.1: Shared object "libKF5Activities.so.5" not found, required by "kwin_x11"kf5-attica be made optional?FreeBSD% kwin_x11
ld-elf.so.1: Shared object "libKF5Attica.so.5" not found, required by "libKF5XmlGui.so.5"kf5-kauth be made optional?FreeBSD% kwin_x11
ld-elf.so.1: Shared object "libKF5Auth.so.5" not found, required by "kwin_x11"plasma5-kscreenlocker be made optional?FreeBSD% ldd $(which kwin_x11) | grep ock
libKScreenLocker.so.5 => /usr/local/lib/libKScreenLocker.so.5 (0x800ba2000)kf5-kio be made optional?FreeBSD% kwin_x11
ld-elf.so.1: Shared object "libKF5KIOWidgets.so.5" not found, required by "libKF5Plasma.so.5"kf5-plasma-framework be made optional?FreeBSD% kwin_x11
ld-elf.so.1: Shared object "libKF5Plasma.so.5" not found, required by "kwin_x11"kf5-karchive be made optional?FreeBSD% kwin_x11
ld-elf.so.1: Shared object "libKF5Archive.so.5" not found, required by "libKF5Plasma.so.5"This is what I meant by "half of KDE Plasma". Why would we need an archiving tool just for a window manager?
FreeBSD% sudo pkg remove kf5-karchive
Checking integrity... done (0 conflicting)
Deinstallation has been requested for the following 30 packages (of 0 packages in the universe):
Installed packages to be REMOVED:
kf5-frameworkintegration: 5.82.0
kf5-kactivities: 5.82.0
kf5-karchive: 5.82.0
kf5-kbookmarks: 5.82.0
kf5-kcmutils: 5.82.0
kf5-kconfigwidgets: 5.82.0
kf5-kdeclarative: 5.82.0
kf5-kded: 5.82.0
kf5-kdelibs4support: 5.82.0
kf5-kdesignerplugin: 5.82.0
kf5-kdewebkit: 5.82.0
kf5-kdoctools: 5.82.0
kf5-kemoticons: 5.82.0
kf5-kglobalaccel: 5.82.0
kf5-kiconthemes: 5.82.0
kf5-kinit: 5.82.0
kf5-kio: 5.82.0_1
kf5-kirigami2: 5.82.0
kf5-knewstuff: 5.82.0
kf5-kpackage: 5.82.0
kf5-kparts: 5.82.0
kf5-krunner: 5.82.0
kf5-kservice: 5.82.0
kf5-ktextwidgets: 5.82.0
kf5-kwallet: 5.82.0
kf5-kxmlgui: 5.82.0
kf5-plasma-framework: 5.82.0
plasma5-breeze: 5.21.5_1
plasma5-kscreenlocker: 5.21.5
plasma5-kwin: 5.21.5
Number of packages to be removed: 30
The operation will free 129 MiB.Looks like the "candidates for being made optional in source code" described above can be replaced by stubs, libraries that just implement the required symbols to satisfy the dependencies without actually doing anything.
I have started to verify that this actually works.
Using https://github.com/jackyf/so-stub, edit the .c file so that it does not abort, but only prints the message "real library not available". Then run (e.g., on a Live system - do not do this on your production machine!)
perl ./so-stub /usr/local/bin/kwin_x11 libKF5Plasma c
sudo mv /usr/local/lib/libKF5Plasma.so* ~/Desktop
sudo mv libKF5Plasma.so.5 /usr/local/lib/
perl ./so-stub /usr/local/bin/kwin_x11 libKF5Crash.so.5 c
sudo mv /usr/local/lib/libKF5Crash.so* ~/Desktop
sudo mv libKF5Crash.so.5 /usr/local/lib/
perl ./so-stub /usr/local/bin/kwin_x11 libKF5Service c
sudo mv /usr/local/lib/libKF5Service.so* ~/Desktop
sudo mv libKF5Service.so.5 /usr/local/lib/
perl ./so-stub /usr/local/bin/kwin_x11 libKF5Notifications c
sudo mv /usr/local/lib/libKF5Notifications* ~/Desktop
sudo mv libKF5Notifications.so.5 /usr/local/lib/
perl ./so-stub /usr/local/bin/kwin_x11 libKF5Package c
sudo mv /usr/local/lib/libKF5Package.so* ~/Desktop
sudo mv libKF5Package.so.5 /usr/local/lib/
perl ./so-stub /usr/local/bin/kwin_x11 libKScreenLocker c
sudo mv /usr/local/lib/libKScreenLocker.so* ~/Desktop
sudo mv libKScreenLocker.so.5 /usr/local/lib/This works: Removes a ton of dependencies including libcanberra, libvorbisfile, libogg,..
However, in my tests this did not work for all libraries, e.g.,:
FreeBSD% perl ./so-stub /usr/local/bin/kwin_x11 libKF5WaylandServer cpp
FreeBSD% sudo mv libKF5WaylandServer.so.5 /usr/local/lib/libKF5WaylandClient.so.5
FreeBSD% kwin_x11
ld-elf.so.1: /usr/local/lib/libkwin.so.5: Undefined symbol "_ZN8KWayland6Client16ConnectionThread16staticMetaObjectEThis does not work, why? Possibly an issue of the so-stub tooling?
probonopd
commented
3 years ago The above seems to stub only the symbols that are used by the program specified to so-stub, rather than all stubs in that library. Hence other applications (which the user might install later on) trying to use the same library might run into unresolved symbols.
Hence the idea: Can we make a libstub-kwin_x11.so that contains all the stub symbols and change the kwin_X11 ELF using patchelf to depend on that library instead of the unwanted libraries?
This way, we would not need to put stub libraries into our system at their usual paths, interfering with other binaries that happen to need the same libraries.
Unfortunately I have only a basic understanding of Perl, but having a version of so-stub that is easier to work with (e.g., to implement the idea described here) would be a big plus. I have hence started to port the so-stub to Python but we'd need someone who actually understands Perl to fill in the missing FIXMEs and bring it to life. (Under 120 lines of code!)
Edit: After some experimentation, I have to conclude that this idea is not workable. If one uses this approach e.g., to remove libKF5Plasma.so.5, then kwin_x11_lite no longer draws in libKF5Plasma.so.5 but it still draws in libkwin.so.5 which again draws in libKF5Plasma.so.5 even though this would not be needed because we have stubbed the symbols needed by that one, too. So the idea of creating a libstubkwin_x11_lite.so.0 and not using the original library names may have been a good one but seems not to be feasible. Instead, we probably need to create a bundle KWinLite.app that contains the stubbed libraries under their original names.
probonopd
commented
3 years ago Of course, all the so-stub stuff is only needed if the dependencies in question cannot be patched away and/or made optional in KWin source code.
At the very least, it shows that there is potential for removing stuff while still keeping the desired minimal kwin_x11 functionality as a window manager.
probonopd
commented
3 years ago figure out where your webkit dependency comes from
We don't worry about this, because we need WebKit anyway for the Falkon browser which is default in helloSystem; but yes, for other uses WebKit would definitely be of concern.
see if you can get rid of breeze and breeze icons
We can, with no ill side effect. But having to download them first, only to manually delete the files, is kinda ugly. Hence imho these should not be hard dependencies in the first place, as KWin can clearly run without them.
probonopd
commented
3 years ago CutefishOS has also expressed interest in a Lite version of KWin for use on a Qt-based desktop without most of KDE Plasma.
jbeich
commented
3 years ago Why is it that
kwin_x11(notkwin_wayland!) also depends on many Wayland components?
Either due to overlinking or because upstream code isn't split enough. See also https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256654
probonopd
commented
3 years ago Update on using https://github.com/jackyf/so-stub:
One has be very careful what dependencies to remove in this way, because KWin tries to be "smart" and makes things worse in the process. Most likely the KWin source code needs to be changed to get to a kwin_x11 with minimal dependencies.
Example:
so-stub to replace libKF5Plasma.so.5 with a stubkwin_x11 still worksstub: real library not available, using stub
Application::crashHandler() called with signal 11; recent crashes: 1
(...)So it seems that the functionality that is responsible for showing all windows in an overview requires libKF5Plasma.so.5 and if that is not implemented, it doesn't just do nothing (no-op) as I would have hoped for, but in fact crashes.
What is worse is that kwin_x11 restarts itself but automatically disables compositing and changes the kwinrc config file, so after the crash kwin_x11 runs again but compositing is disabled forever.
As a conclusion, I fear that to get anywhere with KWin source-code level changes need to be made that make many dependencies weak (i.e., only offer certain features if certain dependencies are met and just remove the functionality otherwise).
probonopd
commented
3 years ago We should also keep an eye on KWinFT which seems to explicitly consider the use case of using KWin without Plasma.
I asked the maintainer, and this was the response:
in the long-term yes. One stated goal of KWinFT is to be more open to other users than KDE Plasma. This will be facilitated by a library split-out as described in kwinft/kwinft#21. You will then be able to pick a subset of libraries that suit your needs and which don't depend on any KDE Plasma software components for building a fully functional window manager. That will be possible for Wayland and X11. At the moment we're not there yet but rapidly moving towards it.
I also asked in KWin IRC and got the answer:
patches to make some dependencies optional are welcome
Good :-)
kettle-7
commented
3 years ago You can remove the overview hot corner that crashes it in KDE System Settings, but I do not know how do manually do it.
probonopd
commented
3 years ago True. In this case, we porbably will want to keep the feature (and the dependency it brings), but it illustrates the point that the method can lead to crashes rather than just doing nothing.
bmentink
commented
3 years ago My 2c. I had a look at the experimental-12.2-0.6.0...... image, here are my thoughts on the KWin windows. (I could not get the 13.0 image to boot)
1.I prefer the original openbox look, with it's two colored close/maximize buttons, I never use minimize, and you can still do that by clicking the icon in the the dock. I also like the fact that you can double click the title bar, so have a stack of "bars" if you want ..
All in all, I still prefer the openbox windows .... very pleasent to use ..
probonopd
commented
3 years ago Besides the different icons (an intentional choice to make things visually more distinctive) the look should not be that different at all.
Do you think the advantages listed at https://github.com/helloSystem/hello/issues/164#issue-861838543 make it still worthwhile to pursue?
bmentink
commented
3 years ago Do you think the advantages listed at #164 (comment) make it still worthwhile to pursue?
Personally I would say no. If those extra features introduce complexity, bloat and a performance hit, then I would stay with the openbox windows as they are, they actually look very good as they are and are functional "enough", especially if you could fix the dragable corners issue .. again just my 2c.
PreyK
commented
3 years ago I think in this case getting everything under kwin would actually decrease the complexity. As far as I looked into it Menu and Dock already using kwin libraries for some of the functionality, kwin_x11 with kwin libraries would mean that there's no undefined behaviour. Also the whole system uses Qt pretty heavily and kwin/the kde project was made with explicitly Qt in mind. On top of this with the additional nice to haves outlined in https://github.com/helloSystem/hello/issues/164#issue-861838543 I think it's definetly worth it. But that's just how I see it On the snappiness, that might be compositing, kwin has a few different modes, might worth a look
probonopd
commented
3 years ago @bmentink reported:
Used to be able to click on "Search" top bar and start typing a name to get to a program fast, no longer works, typing does nothing.
I noticed the same today.
Stangely it is depending on which application is frontmost when you press Command+Space. When you click on the Desktop background and then type Command+Space, then it works.
bmentink
commented
3 years ago on 0.5.0 release yes that is true. You have to click on the desktop before you can hit Command+Space and search, you should be able to do it any time no matter what is frontmost ..
On your experimental-12.2 build you linked, you can't even do that! Click on the desktop then try to use Command+Space and nothing happens, you can not try typing to search ..
probonopd
commented
3 years ago Needs to be investigated further. On my local build system, I can click on the desktop then try to use Command+Space and it works. But here I am not using the KWin.app with the stubs yet. So I need to check whether that breaks it even more than it is broken already without it...
probonopd
commented
3 years ago Regarding menu transparency:
*.kwinrule files can be used to adjust certain classes of windows, e.g., to give them translucency (= less than opacity 100).
Apparently they are loaded from /usr/local/etc/xdg/kwinrulesrc and ~/.config/kwinrulesrc but I could not get it to work yet. Did anyone?
probonopd
commented
3 years ago Do we want rounded corners also at the bottom? Seems doable with KWin using https://github.com/srevinsaju/KDE-Rounded-Corners
Using
kwin_x11instead of Openbox would give usCascade= staircase-by-titleAs a result, the whole desktop feels much more modern (in a positive way).
But
/usr/local/bin/kglobalaccel5for global keyboard shortcuts such as Alt-Tab; this might mean that we should retire/usr/local/bin/lxqt-globalkeysd; configuration lives in~/.config/kglobalshortcutsrcNotes
/usr/local/etc/xdg/kwinrccan be used to set another window decoration and to set the order of the buttons in the window decoration; removing the need forkcmshell5/usr/local/etc/xdg/breezerccan be used to configure BreezeEnhanced, the possible values are explained in https://github.com/tsujan/BreezeEnhanced/blob/master/breezesettingsdata.kcfgStarting with today's experimental ISO builds, the configuration for KWin is included on the ISO, but not KWin nor the BreezeEnhanced theme yet. For those who would try KWin on helloSystem,
sudo pkg install -y plasma5-kwin, replaceopenboxwithkwin_x11in/usr/local/bin/start-hello, and build and install the BreezeEnhanced theme.