liquidshell in kdereview
Martin Flöser
mgraesslin at kde.org
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 cgit.kde.org 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.
Cheers
Martin Flöser
More information about the kde-core-devel
mailing list