liquidshell in kdereview

Martin Flöser mgraesslin at
Sun Dec 3 12:51:49 GMT 2017

Am 2017-12-03 12:28, schrieb Albert Astals Cid:
> El dissabte, 2 de desembre de 2017, a les 13:26:18 CET, Martin Flöser 
> va
> escriure:
>> Am 2017-12-02 10:17, schrieb Albert Astals Cid:
>> > El dijous, 30 de novembre de 2017, a les 19:57:45 CET, Martin Flöser va
>> >
>> > escriure:
>> >> Am 2017-11-29 21:23, schrieb Martin Koller:
>> >> > On Freitag, 3. November 2017 21:30:19 CET Martin Koller wrote:
>> >> >> Hi all,
>> >> >>
>> >> >> I'd like to announce an application I've implemented over the last few
>> >> >> weeks - liquidshell
>> >> >
>> >> > since more than 3 weeks have passed, I hopefully have addressed all
>> >> > issues and I got no further comments,
>> >> > are there any blocking points you see or can I proceed requesting the
>> >> > move to extragear ?
>> >>
>> >> Yes I still see several blocking items. E.g.
>> >> "liquidshell is an alternative to plasmashell"
>> >>
>> >> I think that should be removed. I do not want any competing or
>> >> alternative to plasmashell provided by KDE. This would be very bad for
>> >> our community. Please formulate the readme without mentioning Plasma.
>> >> I'm sure you are able to find unique selling points without going into
>> >> any part of competition with Plasma or in any part which could be
>> >> misunderstood.
>> >>
>> >> What I do not want is Phoronix: "KDE starts new desktop shell because
>> >> Plasma sucks". Please formulate everything so that it cannot be
>> >> misunderstood.
>> >>
>> >> Also remove all the parts about the main motivation without "hog cpu
>> >> or
>> >> ram". We already discussed that this was a problem with your local and
>> >> personal setup. Don't piss on Plasma because your setup has problems.
>> >> You have all the rights to scratch your own itch, but don't piss on
>> >> us.
>> >>
>> >> Personally I'm against liquidshell getting added to extragear. I think
>> >> this would be harming the KDE community to have a shared desktop
>> >> shell.
>> >> We have already too much fragmentation on the desktop area and I don't
>> >> think KDE should support this by creating yet another desktop shell.
>> >> We
>> >> should think here in the big picture.
>> >
>> > So you'd rather prefer he did this in github?
>> I did't write that and I'm surprised you come to that conclusion.
> You said we should not take this in. Martin wants this to be published 
> it
> somehwere, so it has to end up somewhere in github or similar. That was 
> my
> conclusion, i really don't see how is it surprising?

Yes, I think we should not take it into extra-gear. That does not mean 
that I have anything against it being hosted on KDE's git 
infrastructure. Whether it gets released and promoted by the KDE 
community is rather orthogonal to where it is hosted.

So I don't understand your reasoning.

>> > I mean yes, ideally everyone would work on whathever i want them to
>> > work on,
>> > but since this won't happen, can we try to make KDE a nice and
>> > welcoming place
>> > to challenge eachother ideas and implementations?
>> >
>> > I'm sure a little friendly (and yes this goes both ways in the
>> > meanthing that
>> > liquidshell should not piss on plasmashell) competition never hurt
>> > anyone :)
>> Such competition exists - especially on the desktop shell area,
>> especially on the QtQuick vs. QtWidgets area.
>> There currently are the following Qt based desktop shells:
>>   * Plasma (QtQuick)
>>   * LxQt (QtWidgets)
>>   * Lumina (QtWidgets)
>>   * Hawaii (QtQuick AFAIK)
>> In addition there is competition in the GTK world:
>>   * GNOME Shell
>>   * Pantheon
>>   * Xfce
>>   * Budgie
>>   * Cinnamon
>> And there are even further desktop environments on even other toolkits
>> such as E.
>> If there are things we need, it's yet another desktop environment. 
>> There
>> is already sufficient external competition, so that we don't need
>> internal competition.
>> As I already said: Martin is free to do in his spare time whatever he
>> wants. If he thinks we need another desktop shell, fine. He can do so.
>> Whether we as KDE should endorse and support this is another question.
>> I think for the overall Linux world yet another desktop shell is
>> harming. You can have another opinion and that and that's also fine. I
>> only shared my opinion stating that I consider this as harming and 
>> that
>> we as KDE should IMHO not support this.
>> Btw. I would see this completely different if for example LxQt would
>> approach KDE and ask for joining. I would support this and would be
>> happy to see them becoming a part of KDE.
>> Also I think the project should not be added as the whole thing is
>> hypocrite. According to the readme Martin has a problem with QtQuick.
>> Fair enough, but why is he fine with the following areas being in
>> QtQuick:
>>   * KWin (e.g. Alt+Tab)
>>   * Lockscreen
>>   * logout screen
>>   * Systemsettings
>>   * many more components
>> If QtQuick would be a problem, Martin would have to replace everything
>> and not just Plasmashell.
> *If* (big if) QtQuick had performance problems I would understand using
> QtQuick in the alt+tab/lockscreen/etc to be less problematic since i'm 
> not
> using them all the time compared to Plasma itself.

If QtQuick is a problem and causes high CPU usage that would especially 
be a problem when using the lock screen. Especially then you don't want 
CPU time to be wasted.

>> I cannot help it, but I personally have a
>> feeling that Martin did not properly understand where his problems 
>> with
>> his system are. This means the motivation and argumentation is just
>> wrong. I don't think we as KDE should support an ill taken path. We 
>> are
>> a community which is proud about our technical abilities, always 
>> trying
>> to be in the first front for new technologies. Do we really want to 
>> take
>> in products which are motivated on technical misunderstandings?
> I half agree with you, we should participate in projects based on
> misunderstandings, but once the misunderstanding has been cleared (i.e. 
> the
> readmes are cleared of "qtquick and plasma are bad" references) we end 
> up with
> a shell written in QWidgets, that it in itself has nothing to do with 
> its
> initial "political motivations", and if Martin is commited to develop 
> it (now
> that potentially his Plasma works better/he knows where the problems 
> are) I
> don't see why we should not take it in.

Let's continue this discussion once the issues are fixed. I just looked 
into and find:
  * Description: "Alternative desktop replacement for Plasma, using 
QtWidgets instead of QtQuick to ensure hardware acceleration is not 
required "
  * README: "liquidshell is an alternative to plasmashell"
  * README: "It does not use QtQuick but instead uses QtWidgets."
  * README: "No animations, no CPU hogging, low Memory footprint"
  * README: "No use of activities (I never used nor needed them)"
  * README: "The main motivation was to have a reliable desktop shell 
which does not hog the CPU or RAM."
  * many more...

This was all pointed out quite some time already. Not just by me, but 
also from non-Plasma devs. Martin has not fixed this. In the current 
state we don't need to discuss whether it gets accepted.

Once Martin fixed this we can think about the further steps. What I want 
to see then is a KDE community wide discussion about whether it gets 
added or not. Especially I want to see a discussion whether we want to 
add a competing product to LxQt. If we assume Martin fixes the 
description the product is no longer in competition with Plasma, but 
then it gets in competition with LxQt. Do we want that? We praised them 
for working against fragmentation with RazorQt. We supported their 
efforts in using Frameworks. We have a good relationship based on the 
fact that we don't compete. Do we want to risk that? That's an important 
community wide question which cannot be solved in a technical review. If 
we introduce another desktop shell we need to look at the big picture 
and what it means for the Linux ecosystem. It's not a question just 
about Plasma, it really is at global scale.

Martin Flöser

More information about the kde-core-devel mailing list