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
