liquidshell in kdereview
Friedrich W. H. Kossebau
kossebau at kde.org
Thu Nov 9 14:32:46 GMT 2017
Am Dienstag, 7. November 2017, 20:08:59 CET schrieb Martin Koller:
> On Dienstag, 7. November 2017 16:42:40 CET Martin Flöser wrote:
> > Am 2017-11-03 21:30, schrieb Martin Koller:
> > I don't mind what you develop in your spare time. Not at all. What I
> > mind is if a product is added to KDE as a competitor/replacement to a
> > product I work on because of misunderstood things. What I see here is
> > that you completely misunderstood what hardware acceleration means and
> > gives to the system.
> See above. I did not start liquidshell because I was bored. Believe me, I
> have other hobbies. I started it just because I got fed up with the
> problems I had with plasmashell and I need to use some DE for my daily
> work. Restarting plasmashell multiple times a day is just not funny.
I think what Martin F. is also asking here, and what surely one expects as
standard in KDE, is that the description of the liquidshell product/project is
not making false or unresearched claims or speaking badly about alternative
solutions, especially from the same community. In short: being respectful :)
So e.g. if this was about some new liquidhexeditor, I as author of Okteta
would be not happy about phrases like:
* "liquidhexeditor is a replacement for okteta"
"replacement" (to me) comes with meaning of successor, being better. Which is
The more neutral word "alternative" might be better here.
* "It does not use QtQuick but instead relies on QtWidgets."
"not use X but relies on Y" also tells me that "X" sucks and better is
Where one could rather say "Uses X for everything because property 1, property
2 and property 3", without losing a word about "Y". Just listing the factors
one made their choice on for using "X" leaves everyone with their idea about
the qualities of "Y".
E.g. it could be said that QWidgets are a stable mature UI technology and
(like already is sayed) provide a consistent UI across shell and apps (at
least the QWidget-based apps).
No need to speak here about alternatives like QQ, Gtk, or EFL, there are
people for any who think that to be a better base to build a UI on.
So Martik K., IMHO the current README carries still some of the frustration
you had experienced with the Plasma shell. While this has been part of your
motivation for your work on a new solution, it could be now time to step back
and to turn completely into positive thinking like most of the README already
is, for a peaceful, cooperative co-existence :)
I propose to start the README with the product requirements you had in mind
when working on liquidshell, perhaps by listing the features already
implemented (and then listing some which you still consider to add).
With those, potential users might be able to see whether the requirements
match those they are looking for themselves, and developers might be able to
follow your decisions on why creating a separate project and on the
technologies used for the implementation.
BTW, you are surely aware that other UI components of the Plasma workspace,
like the System Settings, are ported to QtQuick currently. So given your
implementation choices, do you plan to create a liquidsystemsettings variant
More information about the kde-core-devel