kwin integration

[agaida]

create a lxqt-kwin file for kcmshell5

[agaida]

@tsujan - you might be interested in

[tsujan]

It's a long time that I use KWin because its bugs are fixed. However, I always have a complete KDE installation to test Qt apps that I work on (pcmanfm-qt included) with it and also to know the progress in Wayland.

The desktop files you want to add are quite handy but I think we should add "KWin" to their names, for example, "KWin Actions" instead of "Actions", because otherwise, they will be seen as ours, which will be confusing to the user:

[tsujan]

BTW, I should add the desktop file of BreezeEnhanced to this dialog because it supports changing KWin's title-bar font outside KDE and I did it especially for LXQt.

[tsujan]

And completely unrelated to this: at some point, we should add a filter-bar to the Configuration Center. I'll wait until someone wants it because it might not be easy ;)

[agaida]

- i played a bit

[agaida]

a bit more tinkering

[tsujan]

How did you do that?

Your desktop files are OK. It's fun to run this from Configuration Center:

If the names are to be changed by adding "KWin" or other words, the translations should be removed and be added by LXQt.

[agaida]

basicly

Exec=kcmshell5 --desktopfile=/usr/share/kservices5/kwindecoration.desktop --caption="LXQt KWin Settings" kwinactions kwindecoration kwinfocus kwinmoving kwinadvanced kwinrules kwincompositing kwineffects kwintabbox kwinscreenedges kwinscripts

if we reduce the caption to "LXQt KWin" there should be no problem - or just drop the caption - it will likely be sufficient to have all needed controls for kwin at hand. With the new desktop entry kwin can be a real alternative to openbox or xfwm4. Until now the need for too much additional packages was as big point not to use kwin.

[agaida]

Some useful extensions coud be a TryExec=kwin or so - so the icon is not shown if kwin is not installed

[tsujan]

basicly Exec=kcmshell5 -...

Very interesting!

[tsujan]

Until now the need for too much additional packages was as big point not to use kwin.

My current LXQt session was started 2 days ago -- after a kernel update -- and kwin_x11 memory usage is only 30 MiB. I remember that Compiz's was ~45 MiB.

[agaida]

memory usage was not the big point for me - but i don't want to install half of KDE for a window manager - I'm fine with kwin + kcmshell and a very limited set of other packages.

[tsujan]

I understand that but I also think kwin -- in its current state -- is so good that those who like it are ready to install anything needed. I won't be surprised if many LXQt users have come from KDE, as I have.

[agaida]

There was much improvements over time - and as you see in our forum or in the bug tracker - some user just don't get it that we are modular :P - after some tests, especially on weaker machines i guess that installing kwin by default will be an option if it works fine.

[tsujan]

Use kwin 5.14 in your tests if possible.

[agaida]

no problem in Arch i guess - in debianland we are still on 4:5.13.5-1+b1

[tsujan]

V5.13 was OK too.

[tsujan]

@agaida Only one thing is missing from your kcmshell5 command and that's colors; it's needed for changing kwin's title-bar color and is also good for those who use the Breeze widget style.

[agaida]

noticed that too - to be honest, right now i don't know which kcm it is

Edit: Erm, now i know and it make me not happy: kcmshell5 desktop style fontinst colors as in: plasma-desktop-data: /usr/share/kservices5/colors.desktop libkf5newstuff-data: /usr/share/kf5/kmoretools/presets-kmoretools/fontinst.desktop plasma-desktop-data: /usr/share/kservices5/fontinst.desktop plasma-desktop-data: /usr/share/kservices5/style.desktop

of course - the binaries are in plasma-desktop

[agaida]

Of course - we could just borrow the needed parts

[agaida]

ok, now i know it - and it makes me not happy - the needed desktop files are in plasms-shell-data and the program files in plasma-desktop - and that would pull in a full plasma desktop - so not the best option.

[tsujan]

the needed desktop files are in plasms-shell-data

You're right. Strange!

[agaida]

Played a bit with plasma-desktop packaging i was able to extract both needed kcm-plugins. The very hard part will be to convince the d-qt-kde Team that we really serious about that - maybe @tsimonq2 want to help with. Not the best situation - but - KDE shows with KF5 that package splitting is possible - why shouldn't it be possible with some applications. Anyways - until this is solved i really can't recommend kwin as default WM and i wouldn't call deploying LXQt with a complete plasma installation a solution.

[tsujan]

Fair enough.

[tsujan]

The Breeze title-bar color (and gradient) can be set separately from the KDE color scheme in one of its forks by a simple change in the code but I think that's an overkill.

On the one hand, I think the KDE color scheme will never be separated from Plasma. So, LXQt with kwin will be only an option for those who don't mind installing more packages. On the other hand, kwin will be the best option when wayland becomes really usable. So, we might have a problem in future.

[agaida]

if anything else fails we can / could just fork plasma-desktop and extract the needed files - i know that it sounds nuts, but it isn't - both needed kcm's are small. I would like the solution with splitting out the needed things into a separated package more. If it don't work @distribution stage maybe talking with KDE upstream will help. the sddm kcm is also a separated packge - it should be possible to do this for color and style to - last resort is forking.

[tsujan]

maybe talking with KDE upstream will help.

It won't. We requested a separate font setting for kwin but they didn't agree. Only a month ago, I realized how easy it was and implemented it.

the sddm kcm is also a separated packge - it should be possible to do this for color and style to

I also think so.

[agaida]

ok - so plan B first - strip it hard out and make it work - after that it might be that talking is much easier.

[agaida]

@tsujan - first working model, debian foo needs a bit love, some files should be removed too - but it kind of works: https://github.com/agaida/lxqt-kcm-colors-style

[tsujan]

You already did it? Fantastic! I'll test it tomorrow.

[agaida]

Wasn't that hard, very clean code and structure - the translations was boring. ok, CMakeLists.txt is still a mess, but ok. But it is a base to speak with some guys - and if we really are forced to fork - nevermind.

[agaida]

Hmm - the big question is if both kcm's should really be part of plasma or should belong to kwin - both would have pros and cons - from the view point of the plasma maintainers colors and styles might be seen as a part of the desktop environment. I see it different, because without kwin is nearly unusable in other environments. And to be honest - forking this would make not much sense at all.

[tsujan]

It's confusing to me too.

[tsujan]

Compilation was successful but the package can't be installed because:

kcm_style: /etc/xdg/colorschemes.knsrc exists in filesystem (owned by plasma-desktop)
kcm_style: /etc/xdg/plasma-desktop.categories exists in filesystem (owned by plasma-desktop)
kcm_style: /usr/bin/kcolorschemeeditor exists in filesystem (owned by plasma-desktop)
kcm_style: /usr/lib/qt/plugins/kcm_colors.so exists in filesystem (owned by plasma-desktop)
kcm_style: /usr/lib/qt/plugins/kcm_style.so exists in filesystem (owned by plasma-desktop)
kcm_style: /usr/share/applications/org.kde.kcolorschemeeditor.desktop exists in filesystem (owned by plasma-desktop)
kcm_style: /usr/share/color-schemes/Honeycomb.colors exists in filesystem (owned by plasma-desktop)
kcm_style: /usr/share/color-schemes/Norway.colors exists in filesystem (owned by plasma-desktop)
kcm_style: /usr/share/color-schemes/ObsidianCoast.colors exists in filesystem (owned by plasma-desktop)
kcm_style: /usr/share/color-schemes/Oxygen.colors exists in filesystem (owned by plasma-desktop)
kcm_style: /usr/share/color-schemes/OxygenCold.colors exists in filesystem (owned by plasma-desktop)
kcm_style: /usr/share/color-schemes/Steel.colors exists in filesystem (owned by plasma-desktop)
kcm_style: /usr/share/color-schemes/WontonSoup.colors exists in filesystem (owned by plasma-desktop)
kcm_style: /usr/share/color-schemes/Zion.colors exists in filesystem (owned by plasma-desktop)
kcm_style: /usr/share/color-schemes/ZionReversed.colors exists in filesystem (owned by plasma-desktop)
kcm_style: /usr/share/doc/HTML/ca/kcontrol/colors/index.cache.bz2 exists in filesystem (owned by plasma-desktop)
kcm_style: /usr/share/doc/HTML/ca/kcontrol/colors/index.docbook exists in filesystem (owned by plasma-desktop)
kcm_style: /usr/share/doc/HTML/ca/kcontrol/kcmstyle/index.cache.bz2 exists in filesystem (owned by plasma-desktop)
...

and many other files.

I should sleep now. Until tomorrow!

[tsujan]

Before I sleep; this is a very good sign:

[agaida]

what do you expect - of course there are file conflicts - so the dependency would be:

lxqt-kcm-colors-style | plasma-desktop right now

and

lxqt-kcm-colors-style conflicts/replaces plasma-desktop

Thats why i would really prefer an upstream change of these bits

[tsujan]

You've delved into it and I may be totally wrong but I think it may be possible in parallel.

[agaida]

it is possible, but it need some modifications - we can't change the locations of the installed files so we are forced to change filenames - and the matching lines in code if needed.

Aka - that would be a full fork

[tsujan]

Sorry if this question is stupid -- when I haven't started to look into something, it's like a big question mark to me:

Can the program use the existing files and if they don't exist, do nothing? I mean, can it be another config program for those parts of KDE but integrated into LXQt? We know kwin can work outside KDE; so we need a config app for it outside KDE too.

[agaida]

The question isn't stupit - with a big but - if we don't get this upstream there will be collisions as in:

kcm_style: /usr/share/color-schemes/Honeycomb.colors exists in filesystem (owned by plasma-desktop)
kcm_style: /usr/share/color-schemes/Norway.colors exists in filesystem (owned by plasma-desktop)

sure we can rename this files, but then they will be visible in plasma too under the new name

We can rename the libs too i think - but they will be visible in plasma too under the new name

kcm_style: /usr/lib/qt/plugins/kcm_colors.so exists in filesystem (owned by plasma-desktop)
kcm_style: /usr/lib/qt/plugins/kcm_style.so exists in filesystem (owned by plasma-desktop)

and so on

[tsujan]

if we don't get this upstream...

If I were you, I wouldn't think about upstream at all ;)

I mean a more radical approach: something only depending on those KDE parts that we need, independent from the others and consistent with KDE too (although KDE won't need it). KDE may be more modular than it looks but I can't be sure until I look into it. Time is the problem: KDE has so many interdependent parts.

[tsujan]

Something like sddm-config-editor (but, of course, not in QML).

[agaida]

erm - bad idea it's mostly a distribution thing - kde and even plasma-desktop isn't that bad at all. But there is a big but: But distributions take a fing big source tarball and build a fing big package from it. The resulting packages could be far mor fine grained - but that will be a lot more work for the distribution maintainers. So please guess what they prefer :sunglasses:

[agaida]

maybe an example: i could take our lxqt repo, checkout all and build from there - and i'm a clever guy, i make a single package of it, only one build, all things done, wouldn't it be nice? :smile: - only one package to maintain. And one resulting package. And after a while, if people complain to loud, i could at least split out lxqt-about :grinning:

[tsujan]

erm - bad idea

Unfortunately, I can't prove it isn't a bad idea right now; It may not be possible either.

The resulting packages could be far mor fine grained

I agree. However, they may have a reason. I'm not familiar with KDE codes -- just Dolphin (in old times) and the Breeze title-bar (now).

[tsujan]

Something that's in the direction of you last comments:

kactivitymanagerd starts for no good reason when I start some KDE apps just to test their styles. I have to stop it manually.

[agaida]

so my initial idea was to help the package maintainers to split this out - that will be some lines of code. If this way would be chosen it would be a clean solution. That would mean that plasma-desktop would likely depend on this package, kwin recommend that package and thats all.

If that not works: write an integration package that depend on lxqt-kcm or plasma-desktop. That would mean:

• if plasma desktop is installed - nothing to to, just use the plasma package.
• if plasma isn't installed - just install the default alternative - that would mean our package.

Downside: If one is doing so, plasma desktop should conflict and replace our package. Thats all, modern package managers should suppot this usecase.

[palinek]

@agaida crossing fingers ...

[maverick74]

How's this going? Any good news from the KDE guys?

[tsujan]

Now that we think about KWin integration, I'd like to tell about something that I found recently and may be useful to others:

KDE mouse gestures for launching Qt apps will work fine under LXQt provided that the commands are like:

bash -c "export QT_QPA_PLATFORMTHEME=lxqt && APP"

Of course, the KWin dbus commands work out of box.

A reason to use KDE mouse gestures under LXQt may be that you're addicted to mouse gestures but you know that easystroke is dead and causes X11 crashes.