liquidshell in kdereview

[Friedrich W. H. Kossebau]

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 
attributing things.
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 
avoided.
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 
as well?

Cheers
Friedrich