Discussion:
liquidshell in kdereview
Martin Koller
2017-11-03 20:30:19 UTC
Permalink
Hi all,

I'd like to announce an application I've implemented over the last few weeks - liquidshell

liquidshell is a replacement for plasmashell

It does not use QtQuick but instead relies on QtWidgets,
therefore no hardware graphics acceleration is needed.

Main Features:
- Wallpaper per virtual desktop
- No animations, no CPU hogging, low Memory footprint
- Instant startup
- No use of activities (I never used nor needed them)
- QtWidgets based, therefore follows widget style from systemsettings
- Icons are used from your globally defined icon theme from systemsettings
- Colors are used from your globally defined color theme from systemsettings
- Can additionally be styled with css by passing the commandline option -stylesheet filename.css
(see included example stylesheet.css)
- uses existing KDE dialogs for most configurations, e.g. StartMenu, Virtual Desktops, Bluetooth, Network
- Just one bottom DesktopPanel, containing:
StartMenu (allowing drag of entries into konqueror/dolphin to configure QuickLaunch or AppMenu entries)
QuickLaunch (showing icons for .desktop files from a configurable folder)
AppMenu (showing .desktop files in a menu from a configurable folder, defaults to users desktop folder)
Pager (for switching virtual desktops)
WindowList (Popup showing all open windows on all desktops)
TaskBar (showing windows on the current desktop, allowing drag of an entry onto the Pager to move to a different desktop)
LockLogout
SysLoad widget including CPU, Memory, Swap and Network bars, live updated tooltip
SysTray with integrated Network-, Notifications-, Device Notifier-, Bluetooth-, Battery- display.
Display of StatusNotifier items from other applications (no legacy embedded icons yet).
Notifications kept in a history list for some minutes, including timestamp and text selectable per mouse
(very handy for copy/paste of TAC numbers from online banking received via SMS and transferred to KDE
via kdeconnect)
Clock widget (with calendar popup, tooltip for selected cities)
- Desktop can contain applets (there's currently only a weather applet)

The main motivation was to have a reliable desktop shell which does not hog the CPU or RAM.
(CPU usage and stability were the things driving me mad with plasmashell)
It should be slick and have just the features I need in my daily
work. No need having all the bells and whistles anyone can think of.
Just have a plain, solid, fast workhorse.

I think the final place should be extragear.

Today I put it into openSuse's OBS and 2 packages for tumbleweed and factory are already in place
and ready to be installed.

Screenshots:
light color theme: Loading Image...
dark color theme: Loading Image...
--
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

() ascii ribbon campaign - against html e-mail
/\ - against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
Alexander Potashev
2017-11-04 01:35:27 UTC
Permalink
Hi, thanks for the good stuff.

Tried to build it here against relatively old Qt version, failed at
first attempt and had to do some tweaks (see attachment).

OS: gentoo
gcc 5.4.0
Qt 5.7.1
KF 5.37.0
Post by Martin Koller
Hi all,
I'd like to announce an application I've implemented over the last few weeks - liquidshell
liquidshell is a replacement for plasmashell
It does not use QtQuick but instead relies on QtWidgets,
therefore no hardware graphics acceleration is needed.
- Wallpaper per virtual desktop
- No animations, no CPU hogging, low Memory footprint
- Instant startup
- No use of activities (I never used nor needed them)
- QtWidgets based, therefore follows widget style from systemsettings
- Icons are used from your globally defined icon theme from systemsettings
- Colors are used from your globally defined color theme from systemsettings
- Can additionally be styled with css by passing the commandline option -stylesheet filename.css
(see included example stylesheet.css)
- uses existing KDE dialogs for most configurations, e.g. StartMenu, Virtual Desktops, Bluetooth, Network
StartMenu (allowing drag of entries into konqueror/dolphin to configure QuickLaunch or AppMenu entries)
QuickLaunch (showing icons for .desktop files from a configurable folder)
AppMenu (showing .desktop files in a menu from a configurable folder, defaults to users desktop folder)
Pager (for switching virtual desktops)
WindowList (Popup showing all open windows on all desktops)
TaskBar (showing windows on the current desktop, allowing drag of an entry onto the Pager to move to a different desktop)
LockLogout
SysLoad widget including CPU, Memory, Swap and Network bars, live updated tooltip
SysTray with integrated Network-, Notifications-, Device Notifier-, Bluetooth-, Battery- display.
Display of StatusNotifier items from other applications (no legacy embedded icons yet).
Notifications kept in a history list for some minutes, including timestamp and text selectable per mouse
(very handy for copy/paste of TAC numbers from online banking received via SMS and transferred to KDE
via kdeconnect)
Clock widget (with calendar popup, tooltip for selected cities)
- Desktop can contain applets (there's currently only a weather applet)
The main motivation was to have a reliable desktop shell which does not hog the CPU or RAM.
(CPU usage and stability were the things driving me mad with plasmashell)
It should be slick and have just the features I need in my daily
work. No need having all the bells and whistles anyone can think of.
Just have a plain, solid, fast workhorse.
I think the final place should be extragear.
Today I put it into openSuse's OBS and 2 packages for tumbleweed and factory are already in place
and ready to be installed.
light color theme: http://members.aon.at/m.koller/liquidshell_20171103_174650.png
dark color theme: http://members.aon.at/m.koller/liquidshell_20171103_174944.png
--
Best regards/Schöne GrÌße
Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?
() ascii ribbon campaign - against html e-mail
/\ - against proprietary attachments
Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
--
Alexander Potashev
Martin Koller
2017-11-04 08:48:15 UTC
Permalink
Post by Alexander Potashev
Hi, thanks for the good stuff.
Tried to build it here against relatively old Qt version, failed at
first attempt and had to do some tweaks (see attachment).
OS: gentoo
gcc 5.4.0
Qt 5.7.1
KF 5.37.0
thanks.
I've fixed things now to compile with older Qt (5.6) and older compiler (g++ 4.8.5)
--
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

() ascii ribbon campaign - against html e-mail
/\ - against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
Kai Uwe Broulik
2017-11-04 18:41:27 UTC
Permalink
Hi,

AppMenu.cxx:
* You can use NoDotAndDotDot flag in entryInfoList() to already skip those
* You seem to be using KFileItem and the url you generate just for isDesktopFile(), you could use KDesktopFile::isDesktopFile(), also the isDir() check could come before, a folder cannot be a desktop file

Battery.cxx:
* It's using Solid/Power API that has never been released (and probably never will be..)
* you assume remainingTime() == -1 to be "when on AC", I'm not sure this assumption holds
* secsToHM looks not ideal form an i18n perspective

CMakeLists.txt:
* No project name set

ConfigureDesktopDialog.cxx:
* instead of QOverload or old syntax you can static_cast<void(KUrlRequester::*)(const QString &)>(&KUrlRequester::returnPressed)

ConfigureDesktopDialog.hxx:
* Reason for *returning* const &?

desktop.cxx:
* Missing AA_UseHighDpiPixmaps attribute

DesktopWidget.cxx:
* window type NET::Desktop should imply NET::KeepBelow
* The list of applets is completely hardcoded and makes assumptions in the class (for "Weather" create WeatherApplet) instead of using some plugin/introspection mechanism

LockLogout.cxx:
* Use QDBus instead of calling dbus-send command-line tool or xdg-screensaver

QuickLaunch.cxx:
* Similar issues as AppMenu.cxx
* Internet browser assumes kde.org is start page

StartMenu.cxx:
* Similar issues as LockLogout.cxx

SysTray.cxx:
* The fill function is also awfully hardcoded

General (UI) observations:
* Qt scales it quite well for high-dpi, however the application doesn't announce high dpi support leading to blurry icons, especially tray icons
* The CPU indicator in the panel cannot be disabled and is distracting
* There's lots of I18N substitution errors all over the place (I18N_ARGUMENT_MISSING)
* The "device notifier" lists *all* devices (not just removables) and isn't scrollable if there are lots of devices, network also doesn't seem scrollable
* No battery applet, icon just opens KCM
* "Bluetooth is not operational", why show the icon then
* Notifications doesnt handle multiple incoming ones well (just stacks dialogs ontop of each other)
* Start button breaks Fitt's law (I cannot open it by janking the cursor into the lower-left corner)
* No multi-screen support whatsoever
* I like the background color selector combination of ComboBox and "custom"
* Often uses QString instead of enums
* Task Bar does not announce "iconified geometries" to KWin thus minimize animations go to the wrong place (centre of screen usually)
* The coding style and naming practises do not follow "modern" KDE Frameworks guidelines
Martin Koller
2017-11-05 18:24:55 UTC
Permalink
Hi,

thanks for you review!
Post by Kai Uwe Broulik
Hi,
* You can use NoDotAndDotDot flag in entryInfoList() to already skip those
I just want to skip ".." - but yes, I can use QDir::AllEntries | QDir::NoDotDot
Post by Kai Uwe Broulik
* You seem to be using KFileItem and the url you generate just for isDesktopFile(), you could use KDesktopFile::isDesktopFile(), also the isDir() check could come before, a folder cannot be a desktop file
That does not work. KDesktopFile::isDesktopFile() does not open the file but just checks the file extension.
I do have desktop files without extension.
The url is used for starting the desktop file (see the lambda function at the bottom of AppMenu::fill())
Post by Kai Uwe Broulik
* It's using Solid/Power API that has never been released (and probably never will be..)
Interesting.
On openSuse 42.2 it is included (released) in the solid-devel package.
On what is "it was never released" based ?
But I have no problem to use something else, if there is a way to know if the AC Power is plugged or not
(and get a signal when it changes).
What can I use instead ?
Post by Kai Uwe Broulik
* you assume remainingTime() == -1 to be "when on AC", I'm not sure this assumption holds
I don't know either. I think this was based on try/error.
Maybe with an alternative to Solid/Power I can change that.
Post by Kai Uwe Broulik
* secsToHM looks not ideal form an i18n perspective
Suggestion ?
Post by Kai Uwe Broulik
* No project name set
fixed
Post by Kai Uwe Broulik
* instead of QOverload or old syntax you can static_cast<void(KUrlRequester::*)(const QString &)>(&KUrlRequester::returnPressed)
Thanks for the hint, but this is really ugly to write.
I see no advantage in doing so.
Post by Kai Uwe Broulik
* Reason for *returning* const &?
You mean this ?
const DesktopWidget::Wallpaper &getWallpaper() const { return wallpaper; }

Of course. What else ?
Post by Kai Uwe Broulik
* Missing AA_UseHighDpiPixmaps attribute
fixed
Post by Kai Uwe Broulik
* window type NET::Desktop should imply NET::KeepBelow
ok, removed
Post by Kai Uwe Broulik
* The list of applets is completely hardcoded and makes assumptions in the class (for "Weather" create WeatherApplet)
instead of using some plugin/introspection mechanism
Yes, by intention.
I have currently no plans to have a plugin mechanism
Post by Kai Uwe Broulik
* Use QDBus instead of calling dbus-send command-line tool or xdg-screensaver
Because ?
Post by Kai Uwe Broulik
* Similar issues as AppMenu.cxx
filter now on QDir::Files
Post by Kai Uwe Broulik
* Internet browser assumes kde.org is start page
yes. And ?
This is a default entry if the user did not configure anything.
And I don't know how to run the "default web browser" than using KRun() with an http url ...
Post by Kai Uwe Broulik
* Similar issues as LockLogout.cxx
you mean system() instead QDBus ?
Do you think there might be distributions not shipping the dbus-send command ?
If so, I should change that, else - who cares.
Post by Kai Uwe Broulik
* The fill function is also awfully hardcoded
hardcoded is the part for the features I supply.
Why do you think this is awful ?
Post by Kai Uwe Broulik
* Qt scales it quite well for high-dpi, however the application doesn't announce high dpi support leading to blurry icons, especially tray icons
since I have no hardware to test that, I did not care.
However I have now added the AA_UseHighDpiPixmaps attribute
Post by Kai Uwe Broulik
* The CPU indicator in the panel cannot be disabled and is distracting
What I want is a system which is usually idle - which is one reason why I implemented liquidshell in the first place.
On my system, I normally don't see any CPU bar at all. And if I see one, I go and check who's the culprit.
Post by Kai Uwe Broulik
* There's lots of I18N substitution errors all over the place (I18N_ARGUMENT_MISSING)
how do you see this ? I don't know what to look for or change.
Post by Kai Uwe Broulik
* The "device notifier" lists *all* devices (not just removables)
That should not happen, since the code filters only on removable devices.
See DeviceList::addDevice():

// show only removable devices
if ( device.is<Solid::StorageDrive>() &&
!device.as<Solid::StorageDrive>()->isRemovable() )
{
//qDebug() << device.udi() << "not Removable";
return;
}

// show only removable devices
if ( device.parent().is<Solid::StorageDrive>() &&
!device.parent().as<Solid::StorageDrive>()->isRemovable() )
{
//qDebug() << device.parent().udi() << "parent() not Removable";
return;
}

so which devices do you get which should not appear ?
Or do you know a better way to check for removables only ?
Post by Kai Uwe Broulik
and isn't scrollable if there are lots of devices,
I can easily add a QScrollArea like in the NotificationList, but I think you usually should not have
that many removable devices which would justify this.
Maybe it's the problem that there are devices shown which should not.
Let's find out which ones.
Post by Kai Uwe Broulik
network also doesn't seem scrollable
yes, it isn't. But I also think you will not have that many entries shown.
Am I wrong ?
Post by Kai Uwe Broulik
* No battery applet,
I don't understand.
You'd like to have a battery desktop applet ?
That's of course doable if needed (I just had no need for that).
Post by Kai Uwe Broulik
icon just opens KCM
More importantly: It shows the current battery status and has a tooltip.
What do you mean by "just" ?
Post by Kai Uwe Broulik
* "Bluetooth is not operational", why show the icon then
Because otherwise you would not be able to turn it on (a click opens the kcm)
Post by Kai Uwe Broulik
* Notifications doesnt handle multiple incoming ones well (just stacks dialogs ontop of each other)
interesting use case. never had problems with that, but that can be changed, of course.
Post by Kai Uwe Broulik
* Start button breaks Fitt's law (I cannot open it by janking the cursor into the lower-left corner)
I can live with that (BTW: in plasmashell you can't either)
Post by Kai Uwe Broulik
* No multi-screen support whatsoever
commit a03d66c69d78c6eec9f0728c38a597ea874e3787
Author: Martin Koller <***@aon.at>
Date: Sat Nov 4 13:50:46 2017 +0100

handle multi-screen setup

Desktop Panel always only on primary screen,
Wallpaper drawn per screen in corresponding scaled version
Post by Kai Uwe Broulik
* I like the background color selector combination of ComboBox and "custom"
thanks, but kudos go to KDE's KColorCombo
Post by Kai Uwe Broulik
* Often uses QString instead of enums
You probably mean the Weather Applet (units) where this is done since the selected units is used as string
in the URL to be queried.
Post by Kai Uwe Broulik
* Task Bar does not announce "iconified geometries" to KWin thus minimize animations go to the wrong place (centre of screen usually)
Interesting point. How would I do this ?
(Since openGL does not work on my machine (crappy Intel driver) - therefore also the need to have a widgets based solution -
I don't use animations ...)
Post by Kai Uwe Broulik
* The coding style and naming practises do not follow "modern" KDE Frameworks guidelines
It's the coding style and naming practises I use for the last 25 years, and liquidshell is no framework lib.
--
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

() ascii ribbon campaign - against html e-mail
/\ - against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
Luca Beltrame
2017-11-05 23:04:48 UTC
Permalink
Il giorno Sun, 05 Nov 2017 19:24:55 +0100
Post by Martin Koller
Post by Kai Uwe Broulik
* Use QDBus instead of calling dbus-send command-line tool or xdg-screensaver
Because ?
Personally, because I don't think that calling random executables from
your program is a good idea.
--
Luca Beltrame - KDE Forums team
GPG key ID: A29D259B
Alexander Neundorf
2017-11-04 19:58:49 UTC
Permalink
Post by Martin Koller
Hi all,
...
I always put my panel to the right or left edge (intead at the bottom)...

...
Post by Martin Koller
The main motivation was to have a reliable desktop shell which does not hog
the CPU or RAM. (CPU usage and stability were the things driving me mad
with plasmashell) It should be slick and have just the features I need in
my daily
work. No need having all the bells and whistles anyone can think of.
Just have a plain, solid, fast workhorse.
Not sure whether "liquid" is a good choice then, I don't really associate
"solid" with it ;-)

Alex
Martin Koller
2017-11-05 18:27:27 UTC
Permalink
Post by Alexander Neundorf
Post by Martin Koller
Hi all,
...
I always put my panel to the right or left edge (intead at the bottom)...
Then I fear liquidshell is simply not for you.
Post by Alexander Neundorf
...
Post by Martin Koller
The main motivation was to have a reliable desktop shell which does not hog
the CPU or RAM. (CPU usage and stability were the things driving me mad
with plasmashell) It should be slick and have just the features I need in
my daily
work. No need having all the bells and whistles anyone can think of.
Just have a plain, solid, fast workhorse.
Not sure whether "liquid" is a good choice then, I don't really associate
"solid" with it ;-)
I was thinking about "solidshell" but "Solid" has already a different meaning inside KDE ...
--
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

() ascii ribbon campaign - against html e-mail
/\ - against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
Alexander Neundorf
2017-11-05 22:01:52 UTC
Permalink
Post by Martin Koller
Post by Alexander Neundorf
Post by Martin Koller
Hi all,
...
I always put my panel to the right or left edge (intead at the bottom)...
Then I fear liquidshell is simply not for you.
... I guess in doubt you wouldn't mind some patches ?

Alex
Martin Koller
2017-11-06 07:27:54 UTC
Permalink
Post by Alexander Neundorf
Post by Martin Koller
Post by Alexander Neundorf
Post by Martin Koller
Hi all,
...
I always put my panel to the right or left edge (intead at the bottom)...
Then I fear liquidshell is simply not for you.
... I guess in doubt you wouldn't mind some patches ?
of course patches are welcome, at least until they do not introduce a whole lot
of troubles (e.g. I fear that the taskbar as it is right now is rather useless
when running the panel vertically, except you make it ridiculously wide).
I just can remember that I tried to fix panel widgets in KDE3 times(!)
where there were troubles with the widgets trying to be useful even in vertical
orientation. But let's see with what you come up ;-)
--
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

() ascii ribbon campaign - against html e-mail
/\ - against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
Aleix Pol
2017-11-06 00:57:32 UTC
Permalink
Post by Martin Koller
Hi all,
I'd like to announce an application I've implemented over the last few weeks - liquidshell
liquidshell is a replacement for plasmashell
It does not use QtQuick but instead relies on QtWidgets,
therefore no hardware graphics acceleration is needed.
- Wallpaper per virtual desktop
- No animations, no CPU hogging, low Memory footprint
- Instant startup
- No use of activities (I never used nor needed them)
- QtWidgets based, therefore follows widget style from systemsettings
- Icons are used from your globally defined icon theme from systemsettings
- Colors are used from your globally defined color theme from systemsettings
- Can additionally be styled with css by passing the commandline option -stylesheet filename.css
(see included example stylesheet.css)
- uses existing KDE dialogs for most configurations, e.g. StartMenu, Virtual Desktops, Bluetooth, Network
StartMenu (allowing drag of entries into konqueror/dolphin to configure QuickLaunch or AppMenu entries)
QuickLaunch (showing icons for .desktop files from a configurable folder)
AppMenu (showing .desktop files in a menu from a configurable folder, defaults to users desktop folder)
Pager (for switching virtual desktops)
WindowList (Popup showing all open windows on all desktops)
TaskBar (showing windows on the current desktop, allowing drag of an entry onto the Pager to move to a different desktop)
LockLogout
SysLoad widget including CPU, Memory, Swap and Network bars, live updated tooltip
SysTray with integrated Network-, Notifications-, Device Notifier-, Bluetooth-, Battery- display.
Display of StatusNotifier items from other applications (no legacy embedded icons yet).
Notifications kept in a history list for some minutes, including timestamp and text selectable per mouse
(very handy for copy/paste of TAC numbers from online banking received via SMS and transferred to KDE
via kdeconnect)
Clock widget (with calendar popup, tooltip for selected cities)
- Desktop can contain applets (there's currently only a weather applet)
The main motivation was to have a reliable desktop shell which does not hog the CPU or RAM.
(CPU usage and stability were the things driving me mad with plasmashell)
It should be slick and have just the features I need in my daily
work. No need having all the bells and whistles anyone can think of.
Just have a plain, solid, fast workhorse.
I think the final place should be extragear.
Today I put it into openSuse's OBS and 2 packages for tumbleweed and factory are already in place
and ready to be installed.
light color theme: http://members.aon.at/m.koller/liquidshell_20171103_174650.png
dark color theme: http://members.aon.at/m.koller/liquidshell_20171103_174944.png
--
Best regards/Schöne Grüße
Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?
() ascii ribbon campaign - against html e-mail
/\ - against proprietary attachments
Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
Hi Martin,
I'm a bit confused, who is liquidshell for?

Aleix
Martin Koller
2017-11-06 07:31:08 UTC
Permalink
Post by Aleix Pol
Post by Martin Koller
Hi all,
I'd like to announce an application I've implemented over the last few weeks - liquidshell
liquidshell is a replacement for plasmashell
Hi Martin,
I'm a bit confused, who is liquidshell for?
Whoever does not like plasmashell, for whatever reason.
My reasons are mentioned in the README or the announcement mail.
Free software is about choice, no ?
--
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

() ascii ribbon campaign - against html e-mail
/\ - against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
Tomaz Canabrava
2017-11-06 09:03:05 UTC
Permalink
Post by Martin Koller
Post by Aleix Pol
Post by Martin Koller
Hi all,
I'd like to announce an application I've implemented over the last few
weeks - liquidshell
Post by Aleix Pol
Post by Martin Koller
liquidshell is a replacement for plasmashell
Hi Martin,
I'm a bit confused, who is liquidshell for?
Whoever does not like plasmashell, for whatever reason.
My reasons are mentioned in the README or the announcement mail.
Free software is about choice, no ?
It is, of course. Then, it's also about non-fragmentation, and you know,
human resources are spare.
I know it's your time and your project and I will never tell you what to
do,
but considering that there's lxqt which exists basically for the same
'whatever reasons', why not help them instead of creating yet another
desktop shell?
Post by Martin Koller
--
Best regards/Schöne GrÌße
Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?
() ascii ribbon campaign - against html e-mail
/\ - against proprietary attachments
Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
Kevin Funk
2017-11-06 11:16:06 UTC
Permalink
Post by Tomaz Canabrava
Post by Martin Koller
Post by Aleix Pol
Post by Martin Koller
Hi all,
I'd like to announce an application I've implemented over the last few
weeks - liquidshell
Post by Aleix Pol
Post by Martin Koller
liquidshell is a replacement for plasmashell
Hi Martin,
I'm a bit confused, who is liquidshell for?
Whoever does not like plasmashell, for whatever reason.
My reasons are mentioned in the README or the announcement mail.
Free software is about choice, no ?
It is, of course. Then, it's also about non-fragmentation, and you know,
human resources are spare.
I know it's your time and your project and I will never tell you what to
do,
but considering that there's lxqt which exists basically for the same
'whatever reasons', why not help them instead of creating yet another
desktop shell?
So much +1.

I'm really sad to see more fragmentation in the DE space instead of finding
people investing their time helping existing projects, even more so if there's
one aiming for the same goal under the KDE umbrella.

You're free to work on whatever you like to of course, but to me this sounds
like wasted effort. Your good incentives would be better spent with joining up
with others aiming for the same (LxQt for instance).

Hate to be the party pooper here, but I'm just not sure this kind of
fragmentation helps KDE in the long-term, where we really have a hard time
finding contributors for the majority of our *existing* projects.

Regards,
Kevin
Post by Tomaz Canabrava
Post by Martin Koller
Best regards/Schöne Grüße
Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?
() ascii ribbon campaign - against html e-mail
/\ - against proprietary attachments
Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
--
Kevin Funk | ***@kde.org | http://kfunk.org
Alexander Potashev
2017-11-06 12:30:23 UTC
Permalink
Post by Kevin Funk
You're free to work on whatever you like to of course, but to me this sounds
like wasted effort. Your good incentives would be better spent with joining up
with others aiming for the same (LxQt for instance).
Hi,

I had a bad impression of LxQt because:
1. it didn't work for me out of the box,
2. it consists of many components, it's hard to figure out which of
them are optional,
3. it has poor infrastructure compared to KDE, e.g. their i18n server
hadn't been working for about a year.

Thus liquidshell looks better to me than lxqt; joining an inferior
project is not a good idea.
--
Alexander Potashev
Tomaz Canabrava
2017-11-06 14:31:07 UTC
Permalink
Post by Kevin Funk
Post by Kevin Funk
You're free to work on whatever you like to of course, but to me this
sounds
Post by Kevin Funk
like wasted effort. Your good incentives would be better spent with
joining up
Post by Kevin Funk
with others aiming for the same (LxQt for instance).
Hi,
1. it didn't work for me out of the box,
For many people kde applications don't work out of the box too.

2. it consists of many components, it's hard to figure out which of
Post by Kevin Funk
them are optional,
Also true for kde applications.

3. it has poor infrastructure compared to KDE, e.g. their i18n server
Post by Kevin Funk
hadn't been working for about a year.
I cant comment on that - but the project seems to be alive as there was a
new release just last month with a lot of changes, also they use kf5
libraries where needed.
Post by Kevin Funk
Thus liquidshell looks better to me than lxqt; joining an inferior
project is not a good idea.
please refrain from using words like 'inferior' for a project as it's not
helpful.
Currently the whole code for liquidshell is done for one person, and we (as
in the KDE Sc) suffer for a lot of good projects and ideas that as soon as
the original developers get tired the project stalls,
like Macaw Movie, Spectacle, Baloo and quite a few others - so I'm really
afraid of a one-man-project that's basically what other many projects
already do.

About liquidshell, I tried but it didn't even compile on my machine (some
issue with Solid)
Post by Kevin Funk
--
Alexander Potashev
Albert Astals Cid
2017-11-06 20:59:01 UTC
Permalink
Sorry for top postiing, stupid webmail.

Almost all projects start as a one man project, if you reject those you're basically making impossible for them to grow.

Cheers,
  Albert
Post by Kevin Funk
You're free to work on whatever you like to of course, but to me this sounds
like wasted effort. Your good incentives would be better spent with joining up
with others aiming for the same (LxQt for instance).
Hi,
 1. it didn't work for me out of the box,
For many people kde applications don't work out of the box too.
   2. it consists of many components, it's hard to figure out which of
them are optional,
Also true for kde applications.
   3. it has poor infrastructure compared to KDE, e.g. their i18n server
hadn't been working for about a year.
I cant comment on that - but the project seems to be alive as there was a new release just last month with a lot of changes, also they use kf5 libraries where needed.
 
  Thus liquidshell looks better to me than lxqt; joining an inferior
project is not a good idea.
please refrain from using words like 'inferior' for a project as it's not helpful.
Currently the whole code for liquidshell is done for one person, and we (as in the KDE Sc) suffer for a lot of good projects and ideas that as soon as the original developers get tired the project stalls,
like Macaw Movie, Spectacle, Baloo and quite a few others - so I'm really afraid of a one-man-project that's basically what other many projects already do.


About liquidshell, I tried but it didn't even compile on my machine (some issue with Solid)


 
  --Alexander Potashev
Martin Koller
2017-11-06 18:13:36 UTC
Permalink
Post by Tomaz Canabrava
Post by Martin Koller
Post by Aleix Pol
Post by Martin Koller
Hi all,
I'd like to announce an application I've implemented over the last few
weeks - liquidshell
Post by Aleix Pol
Post by Martin Koller
liquidshell is a replacement for plasmashell
Hi Martin,
I'm a bit confused, who is liquidshell for?
Whoever does not like plasmashell, for whatever reason.
My reasons are mentioned in the README or the announcement mail.
Free software is about choice, no ?
It is, of course. Then, it's also about non-fragmentation, and you know,
human resources are spare.
I know it's your time and your project and I will never tell you what to
do,
but considering that there's lxqt which exists basically for the same
'whatever reasons', why not help them instead of creating yet another
desktop shell?
lxqt say on their web page "The Lightweight Qt Desktop Environment"

I don't want to create yet another Desktop Environment.
I was just unhappy with plasmashell, which liquidshell replaces
--
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

() ascii ribbon campaign - against html e-mail
/\ - against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
Alexander Neundorf
2017-11-06 20:57:09 UTC
Permalink
Post by Martin Koller
Post by Tomaz Canabrava
Post by Martin Koller
Post by Aleix Pol
Post by Martin Koller
Hi all,
I'd like to announce an application I've implemented over the last few
weeks - liquidshell
Post by Aleix Pol
Post by Martin Koller
liquidshell is a replacement for plasmashell
Hi Martin,
I'm a bit confused, who is liquidshell for?
Whoever does not like plasmashell, for whatever reason.
My reasons are mentioned in the README or the announcement mail.
Free software is about choice, no ?
It is, of course. Then, it's also about non-fragmentation, and you know,
human resources are spare.
I know it's your time and your project and I will never tell you what to
do,
but considering that there's lxqt which exists basically for the same
'whatever reasons', why not help them instead of creating yet another
desktop shell?
lxqt say on their web page "The Lightweight Qt Desktop Environment"
I don't want to create yet another Desktop Environment.
I was just unhappy with plasmashell, which liquidshell replaces
I tried lxqt too once, and while nice, I found quite some things lacking, IIRC
if because it replaces really a lot of things and not only plasmashell.
So while joining forces with lxqt sounds very obvious, lxqt AFAIK has a much
wider focus, so I can understand starting a project which is "just" a
replacement for plasmashell.

Alex
Alexander Neundorf
2017-11-06 20:59:34 UTC
Permalink
...
Post by Tomaz Canabrava
Post by Martin Koller
Whoever does not like plasmashell, for whatever reason.
My reasons are mentioned in the README or the announcement mail.
Free software is about choice, no ?
It is, of course. Then, it's also about non-fragmentation, and you know,
human resources are spare.
just speaking for myself: I don't feel qualified to contribute to plasma (QML,
very flexible architecture, fancy design concepts, etc.), but I would feel
qualified to send a patch for a simple QWidget-based desktop shell.

Alex
Friedrich W. H. Kossebau
2017-11-06 16:12:31 UTC
Permalink
Hi Martin,
Post by Martin Koller
I'd like to announce an application I've implemented over the last few weeks - liquidshell
Congrats to the achievement. It surely feels good to run a workspace one has
created one themselves :)

While myself I will choose Plasma over liquidshell due to my needs and
expectations of certain features, I can see that liquidshell would satisfy
those persons who need or want just a simple hard-coded shell following a
well-known UI design & concept, yet stay with the usual tools and apps from
the KDE software world, ideally perfectly integrated with the workspace (think
filemanager, terminal, text editor, etc). People like obviously yourself :) So
those persons might be surely happy about you sharing your work with them.

My hopes for liquidshell as another project under the KDE community umbrella:
* improvements for shared middleware, perhaps even introducing some more
where it makes sense to share between Plasma, liquidshell & others
(pushing for more clear UI-core separation, which in theory is for good)
libtm might be one such thing, the weather data provider system also calls
for being shared code with Plasma (and e.g. the Marble weather plugin)
* another testing ground for protocols & standards in development
* make more obvious that "KDE" is about a community, not a certain software
* give perhaps remaining trinity desktop developers and other
Plasma-no-Qt-jay-fans a new center for their goals and as result also new
contributors for the shared middleware, tools and apps (at least for their
current QtWidgets UI variant ;) )

Re: gosh, yet another workspace
In a perfect world everybody would join work on the one true golden workspace
solution, reality is that there is no such one-workspace-which-fits-all. Not
to forget the mythical person-month issue.

And if people rather go and write their own software instead of joining
existing projects, it should be the projects asking themselves why they have
not been attractive enough in the first place.
Telling people instead "you should not do X, but Y" is rather the opposite of
what Free Software is about. Even when first saying "Your are free, but".

I applaud you, Martin, for managing to solve your needs yourself and for
sharing the results with the rest of the world, instead of keeping them for
yourself.
And as KDE community we can feel honored you trust us to be the best place for
further development of your software, instead of going github or elsewhere.

Re: liquidshell as name
When I read liquidshell I first thought about something very dynamic, highly
animated. So not sure "liquid" is the best term to use in the name. But then
we all know naming is hard, good luck with it :)

Cheers
Friedrich
Martin Koller
2017-11-06 18:30:08 UTC
Permalink
Post by Aleix Pol
Hi Martin,
Post by Martin Koller
I'd like to announce an application I've implemented over the last few weeks
- liquidshell
Congrats to the achievement. It surely feels good to run a workspace one has
created one themselves :)
While myself I will choose Plasma over liquidshell due to my needs and
expectations of certain features, I can see that liquidshell would satisfy
those persons who need or want just a simple hard-coded shell following a
well-known UI design & concept, yet stay with the usual tools and apps from
the KDE software world, ideally perfectly integrated with the workspace (think
filemanager, terminal, text editor, etc). People like obviously yourself :) So
those persons might be surely happy about you sharing your work with them.
* improvements for shared middleware, perhaps even introducing some more
where it makes sense to share between Plasma, liquidshell & others
(pushing for more clear UI-core separation, which in theory is for good)
libtm might be one such thing, the weather data provider system also calls
for being shared code with Plasma (and e.g. the Marble weather plugin)
* another testing ground for protocols & standards in development
* make more obvious that "KDE" is about a community, not a certain software
* give perhaps remaining trinity desktop developers and other
Plasma-no-Qt-jay-fans a new center for their goals and as result also new
contributors for the shared middleware, tools and apps (at least for their
current QtWidgets UI variant ;) )
Re: gosh, yet another workspace
In a perfect world everybody would join work on the one true golden workspace
solution, reality is that there is no such one-workspace-which-fits-all. Not
to forget the mythical person-month issue.
And if people rather go and write their own software instead of joining
existing projects, it should be the projects asking themselves why they have
not been attractive enough in the first place.
Telling people instead "you should not do X, but Y" is rather the opposite of
what Free Software is about. Even when first saying "Your are free, but".
I applaud you, Martin, for managing to solve your needs yourself and for
sharing the results with the rest of the world, instead of keeping them for
yourself.
And as KDE community we can feel honored you trust us to be the best place for
further development of your software, instead of going github or elsewhere.
thanks for the appreciation
Post by Aleix Pol
Re: liquidshell as name
When I read liquidshell I first thought about something very dynamic, highly
animated. So not sure "liquid" is the best term to use in the name. But then
we all know naming is hard, good luck with it :)
This was a tough one. really not easy to select a sensible name.
I was considering "solidshell" but Solid has already a meaning in the KDE world.
--
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

() ascii ribbon campaign - against html e-mail
/\ - against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
Albert Astals Cid
2017-11-06 21:00:05 UTC
Permalink
+1000 to what Friedrich said :)

Cheers,
   Albert

En lunes, 6 de noviembre de 2017 17:13:04 CET, Friedrich W. H. Kossebau <***@kde.org> escribió:

Hi Martin,
Post by Martin Koller
I'd like to announce an application I've implemented over the last few weeks - liquidshell
Congrats to the achievement. It surely feels good to run a workspace one has
created one themselves :)

While myself I will choose Plasma over liquidshell due to my needs and
expectations of certain features, I can see that liquidshell would satisfy
those persons who need or want just a simple hard-coded shell following a
well-known UI design & concept, yet stay with the usual tools and apps from
the KDE software world, ideally perfectly integrated with the workspace (think
filemanager, terminal, text editor, etc). People like obviously yourself :) So
those persons might be surely happy about you sharing your work with them.

My hopes for liquidshell as another project under the KDE community umbrella:
* improvements for shared middleware, perhaps even introducing some more
  where it makes sense to share between Plasma, liquidshell & others
  (pushing for more clear UI-core separation, which in theory is for good)
  libtm might be one such thing, the weather data provider system also calls
  for being shared code with Plasma (and e.g. the Marble weather plugin)
* another testing ground for protocols & standards in development
* make more obvious that "KDE" is about a community, not a certain software
* give perhaps remaining trinity desktop developers and other
  Plasma-no-Qt-jay-fans a new center for their goals and as result also new
  contributors for the shared middleware, tools and apps (at least for their
  current QtWidgets UI variant ;) )

Re: gosh, yet another workspace
In a perfect world everybody would join work on the one true golden workspace
solution, reality is that there is no such one-workspace-which-fits-all. Not
to forget the mythical person-month issue.

And if people rather go and write their own software instead of joining
existing projects, it should be the projects asking themselves why they have
not been attractive enough in the first place.
Telling people instead "you should not do X, but Y" is rather the opposite of
what Free Software is about. Even when first saying "Your are free, but".

I applaud you, Martin, for managing to solve your needs yourself and for
sharing the results with the rest of the world, instead of keeping them for
yourself.
And as KDE community we can feel honored you trust us to be the best place for
further development of your software, instead of going github or elsewhere.

Re: liquidshell as name
When I read liquidshell I first thought about something very dynamic, highly
animated. So not sure "liquid" is the best term to use in the name. But then
we all know naming is hard, good luck with it :)

Cheers
Friedrich
Friedrich W. H. Kossebau
2017-11-06 16:37:15 UTC
Permalink
Post by Martin Koller
- uses existing KDE dialogs for most configurations, e.g. StartMenu, Virtual
Desktops, Bluetooth, Network
Please consider saying rather "KDE Frameworks dialogs", due to "KDE dialogs"
being a concept which no longer exists at age of KDE Frameworks and Plasma.
Post by Martin Koller
http://members.aon.at/m.koller/liquidshell_20171103_174650.png dark color
theme: http://members.aon.at/m.koller/liquidshell_20171103_174944.png
Please consider using a non-KDE logo on the start menu on representative/
advertising screenshots (ideally some new liquidshell logo one, also to help
promoting it and building an identity).
Given the history meaning of the KDE logo as the logo of a desktop, using the
KDE logo will spoil the concerted effort of the rebranding done (whether it
was a good idea or not is too late to discuss) and only continue the
confusion, for no good.

So with the Plasma workspaces having moved to the Plasma logo, leaving the KDE
logo for the community, liquidshell should have and use its own dedicated logo
as well. (and yes, the start-here-kde icons would need renaming finally)

Cheers
Friedrich
Martin Koller
2017-11-06 18:24:51 UTC
Permalink
Post by Friedrich W. H. Kossebau
Post by Martin Koller
- uses existing KDE dialogs for most configurations, e.g. StartMenu, Virtual
Desktops, Bluetooth, Network
Please consider saying rather "KDE Frameworks dialogs", due to "KDE dialogs"
being a concept which no longer exists at age of KDE Frameworks and Plasma.
changed
Post by Friedrich W. H. Kossebau
Post by Martin Koller
http://members.aon.at/m.koller/liquidshell_20171103_174650.png dark color
theme: http://members.aon.at/m.koller/liquidshell_20171103_174944.png
Please consider using a non-KDE logo on the start menu on representative/
advertising screenshots (ideally some new liquidshell logo one, also to help
promoting it and building an identity).
Given the history meaning of the KDE logo as the logo of a desktop, using the
KDE logo will spoil the concerted effort of the rebranding done (whether it
was a good idea or not is too late to discuss) and only continue the
confusion, for no good.
So with the Plasma workspaces having moved to the Plasma logo, leaving the KDE
logo for the community, liquidshell should have and use its own dedicated logo
as well. (and yes, the start-here-kde icons would need renaming finally)
I'm very bad at creating appealing graphics, therefore I used exiting icons where
possible.
Is there some KDE artist who is willing to create a new logo for me ?

Regarding the rebranding: does that mean KDE (the people behind the project)
does not like to promote KDE ?
Very confusing in my view.
I really meant to show "that is a KDE (based) application" by using its logo -
was not clear that this is not welcomed.
--
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

() ascii ribbon campaign - against html e-mail
/\ - against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
Friedrich W. H. Kossebau
2017-11-07 14:32:23 UTC
Permalink
Post by Martin Koller
Post by Friedrich W. H. Kossebau
Post by Martin Koller
http://members.aon.at/m.koller/liquidshell_20171103_174650.png dark
color
theme: http://members.aon.at/m.koller/liquidshell_20171103_174944.png
Please consider using a non-KDE logo on the start menu on representative/
advertising screenshots (ideally some new liquidshell logo one, also to
help promoting it and building an identity).
Given the history meaning of the KDE logo as the logo of a desktop, using
the KDE logo will spoil the concerted effort of the rebranding done
(whether it was a good idea or not is too late to discuss) and only
continue the confusion, for no good.
So with the Plasma workspaces having moved to the Plasma logo, leaving the
KDE logo for the community, liquidshell should have and use its own
dedicated logo as well. (and yes, the start-here-kde icons would need
renaming finally)
I'm very bad at creating appealing graphics, therefore I used exiting icons
where possible.
Is there some KDE artist who is willing to create a new logo for me ?
I recommend to follow https://vdesign.kde.org/how.html and poke the VDG people
directly with your requirement.
Post by Martin Koller
Regarding the rebranding: does that mean KDE (the people behind the project)
does not like to promote KDE ?
Very confusing in my view.
I really meant to show "that is a KDE (based) application" by using its logo
- was not clear that this is not welcomed.
Surely we want to promote KDE, the community :) Just, like e.g. apps like
Okular, Dolphin, Okteta, KDevelop etc. also want to promote KDE, the
community, they do it via the entry in the Help menu or in the About data.
Still they have their own logo/icon for showing off e.g. "he, it's me, okular"
and have their logo/icon displayed as identifier.

The start menu icon here serves a similar purpose usually, it shows "he, its
me, workspace product X/operating system Y". But not saying "I am done by A",
especially when A creates different variants of the product type.

And with the history of "KDE" being once the name of a workspace product,
using its logo on the start menu like in the formerly named "KDE" product
could trigger the uninformed people to consider liquidshell being the new
"KDE". Adding to confusion and wasted resources in fighting those
misconception.
So better prevent from the start, so our time could be spent in bug fixing
instead.


BTW, would you like assistance to have liquidshell covered on build.kde.org?
Seems it is not there yet.

Cheers
Friedrich
Martin Koller
2017-11-07 18:27:31 UTC
Permalink
Post by Friedrich W. H. Kossebau
Post by Martin Koller
Post by Friedrich W. H. Kossebau
Post by Martin Koller
http://members.aon.at/m.koller/liquidshell_20171103_174650.png dark
color
theme: http://members.aon.at/m.koller/liquidshell_20171103_174944.png
Please consider using a non-KDE logo on the start menu on representative/
advertising screenshots (ideally some new liquidshell logo one, also to
help promoting it and building an identity).
Given the history meaning of the KDE logo as the logo of a desktop, using
the KDE logo will spoil the concerted effort of the rebranding done
(whether it was a good idea or not is too late to discuss) and only
continue the confusion, for no good.
So with the Plasma workspaces having moved to the Plasma logo, leaving the
KDE logo for the community, liquidshell should have and use its own
dedicated logo as well. (and yes, the start-here-kde icons would need
renaming finally)
I'm very bad at creating appealing graphics, therefore I used exiting icons
where possible.
Is there some KDE artist who is willing to create a new logo for me ?
I recommend to follow https://vdesign.kde.org/how.html and poke the VDG people
directly with your requirement.
thanks, will do
Post by Friedrich W. H. Kossebau
Post by Martin Koller
Regarding the rebranding: does that mean KDE (the people behind the project)
does not like to promote KDE ?
Very confusing in my view.
I really meant to show "that is a KDE (based) application" by using its logo
- was not clear that this is not welcomed.
Surely we want to promote KDE, the community :) Just, like e.g. apps like
Okular, Dolphin, Okteta, KDevelop etc. also want to promote KDE, the
community, they do it via the entry in the Help menu or in the About data.
Still they have their own logo/icon for showing off e.g. "he, it's me, okular"
and have their logo/icon displayed as identifier.
The start menu icon here serves a similar purpose usually, it shows "he, its
me, workspace product X/operating system Y". But not saying "I am done by A",
especially when A creates different variants of the product type.
And with the history of "KDE" being once the name of a workspace product,
using its logo on the start menu like in the formerly named "KDE" product
could trigger the uninformed people to consider liquidshell being the new
"KDE". Adding to confusion and wasted resources in fighting those
misconception.
So better prevent from the start, so our time could be spent in bug fixing
instead.
ok, understand.
Post by Friedrich W. H. Kossebau
BTW, would you like assistance to have liquidshell covered on build.kde.org?
Seems it is not there yet.
Wow - didn't know that this exists.
Is this just for testing if it compiles or are packages released from there ?

I've currently uploaded a version to build.opensuse.org which compiles currently
some openSuse versions.
--
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

() ascii ribbon campaign - against html e-mail
/\ - against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
Friedrich W. H. Kossebau
2017-11-09 14:27:32 UTC
Permalink
Post by Martin Koller
Post by Friedrich W. H. Kossebau
BTW, would you like assistance to have liquidshell covered on
build.kde.org? Seems it is not there yet.
Wow - didn't know that this exists.
Is this just for testing if it compiles or are packages released from there ?
It is for checking building with current state of other KDE software that is
in the same dependency tree. As well as tracking unit tests results and other
code quality measurements.

No packages generated there, only automated testing done.

Cheers
Friedrich
Martin Flöser
2017-11-07 15:42:40 UTC
Permalink
Post by Martin Koller
Hi all,
I'd like to announce an application I've implemented over the last few weeks - liquidshell
liquidshell is a replacement for plasmashell
It does not use QtQuick but instead relies on QtWidgets,
therefore no hardware graphics acceleration is needed.
[snip]
Post by Martin Koller
The main motivation was to have a reliable desktop shell which does not hog the CPU or RAM.
(CPU usage and stability were the things driving me mad with
plasmashell)
It should be slick and have just the features I need in my daily
work. No need having all the bells and whistles anyone can think of.
Just have a plain, solid, fast workhorse.
I'm now playing devils advocate: which window manager are you using? If
I understand correctly this is supposed to be a replacement for
plasmashell in Plasma, which would mean that you use KWin.

Are you aware that KWin uses QtQuick for all its UI elements, such as
Alt+TAB? Isn't that also a memory and resource hog? Shouldn't you come
up with a replacement for KWin as well?

Also concerning no hardware graphics acceleration needed: who is going
to render your UI? Do you really think the QPainter API is the best and
most efficent to render a UI? Especially considering that in the end the
whole thing needs to be transferred to the GPU. Are you aware that the
compositor uses hardware acceleration to render the UI? If you don't use
a compositor: are you aware that XServer itself uses hardware
acceleration to render its UI (check glamor). Are you aware that if you
don't have hardware acceleration everything is going to be rendered
through llvmpipe? Do you really think QPainter is better than llvmpipe?
Because I - having worked with that stuff for years in a low level area
- doubt so.

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. I know, I know more than 90 % and all the
"lightweight" people get this wrong. But you know what I observed more
and more over the last years: people praise Plasma for the fast speed,
responsiveness and low memory consumption. Why is that so, why do people
no longer consider our software as bloated? Because we use QML and we
use it well!

So if that gets added I want to have it made clear that this is not a
"lightweight" product and I don't want it to be advertised as not using
hardware acceleration. I don't want to see what you list in the main
motivation. Because that will just result in people going all "KDE dev
develops new desktop shell, because Plasma is unreliable". If that
happens it pisses me off! And that's what's going to happen the way you
phrased it. And what would piss me even more of is if that is due to you
misunderstanding hardware acceleration.

Cheers
Martin
KWin maintainer
Martin Koller
2017-11-07 19:08:59 UTC
Permalink
Post by Martin Flöser
Post by Martin Koller
Hi all,
I'd like to announce an application I've implemented over the last few
weeks - liquidshell
liquidshell is a replacement for plasmashell
It does not use QtQuick but instead relies on QtWidgets,
therefore no hardware graphics acceleration is needed.
[snip]
Post by Martin Koller
The main motivation was to have a reliable desktop shell which does
not hog the CPU or RAM.
(CPU usage and stability were the things driving me mad with
plasmashell)
It should be slick and have just the features I need in my daily
work. No need having all the bells and whistles anyone can think of.
Just have a plain, solid, fast workhorse.
I'm now playing devils advocate: which window manager are you using?
personally I'm using kwin, since I only replaced plasmashell,
but I assume this is irrelevant to what "shell" one is using.
Post by Martin Flöser
If I understand correctly this is supposed to be a replacement for
plasmashell in Plasma, which would mean that you use KWin.
yes
Post by Martin Flöser
Are you aware that KWin uses QtQuick for all its UI elements, such as
Alt+TAB?
I have deactivated the compositor since sadly it simply does not work
on my laptop (the intel graphics driver just freezes the whole machine).
Post by Martin Flöser
Isn't that also a memory and resource hog?
not here. It's not in the top 10 processes of CPU or memory usage
Post by Martin Flöser
Shouldn't you come up with a replacement for KWin as well?
no (as long as it works good enough for me)
Post by Martin Flöser
Also concerning no hardware graphics acceleration needed: who is going
to render your UI? Do you really think the QPainter API is the best and
most efficent to render a UI? Especially considering that in the end the
whole thing needs to be transferred to the GPU. Are you aware that the
compositor uses hardware acceleration to render the UI? If you don't use
a compositor: are you aware that XServer itself uses hardware
acceleration to render its UI (check glamor). Are you aware that if you
don't have hardware acceleration everything is going to be rendered
through llvmpipe? Do you really think QPainter is better than llvmpipe?
Because I - having worked with that stuff for years in a low level area
- doubt so.
You're barking at the wrong tree.
I don't care how it's done deep down in the stack.
I can tell you that now with liquidshell my CPU uses 0% CPU most of the time,
and starting plasmashell it's more - sometimes much, much more without changing
anything in the workspace setup. That is simply not acceptable for me.
If plasmashell would work better, I would not have created liquidshell
in the first place.
Just wanting to WORK with my system, which I simply could not with plasmashell.
Post by Martin Flöser
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.
Post by Martin Flöser
I know, I know more than 90 % and all the
"lightweight" people get this wrong. But you know what I observed more
and more over the last years: people praise Plasma for the fast speed,
responsiveness and low memory consumption. Why is that so, why do people
no longer consider our software as bloated? Because we use QML and we
use it well!
For me it - sadly - got worse over time.
Post by Martin Flöser
So if that gets added I want to have it made clear that this is not a
"lightweight" product
Did you read "lightweight" anywhere in my README ?
Post by Martin Flöser
and I don't want it to be advertised as not using
hardware acceleration.
I don't want to see what you list in the main
motivation.
I did not know that I need permission from you for what motivates me
Post by Martin Flöser
Because that will just result in people going all "KDE dev
develops new desktop shell, because Plasma is unreliable".
which it is for me, sorry
Post by Martin Flöser
If that happens it pisses me off! And that's what's going to happen the way you
phrased it. And what would piss me even more of is if that is due to you
misunderstanding hardware acceleration.
I removed now the "no hardware acceleration" sentence from my README, since I'm
obviously too dumb to know what I write, sorry.

To be clear:
It was not the "no hardware acceleration" need which led me starting liquidshell,
it was the troubles I had with plasmashell (and obviously with the hardware I'm using).
And since I'm using QtWidgets since ages and have no QML experience, this was clearly
the way to go for me.
Trying to debug plasmashell to find the reason for the troubles is a route I tried
for a short period, but simply gave up. I have no idea how I would debug a scene graph
and I know close to nothing about openGL - and I don't need to.
I'm pretty sure this would have taken much longer and was much less fun
than starting from scratch with a technology I know.
--
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

() ascii ribbon campaign - against html e-mail
/\ - against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
Martin Flöser
2017-11-07 19:55:57 UTC
Permalink
Post by Martin Koller
Post by Martin Flöser
Are you aware that KWin uses QtQuick for all its UI elements, such as
Alt+TAB?
I have deactivated the compositor since sadly it simply does not work
on my laptop (the intel graphics driver just freezes the whole
machine).
I did not talk about compositor, I talked about QtQuick! Yes, KWin uses
QtQuick for rendering it's UI, that is unrelated to compositing.

Now you mention that your intel graphics driver freezes the whole
system. I'm using Intel on all my systems and it's the most used driver
out there. We get many, many, many bug reports in KWin about issues.
Freezing systems has not been in the list for now something like two
years.

Given that I am very certain that you have a hardware issue where people
can help you with. Intel GPUs are good enough to run the Plasma session
without any negative impact.

So let us help you fix your issues that you can enjoy our work without
having to spend time on writing your own shell.

First thing: are you using the xorg-modesettings driver? If not: install
it, problems solved. Do not (I repeat) do not use the xorg-intel driver.

For kernel I recommend at least version 4.13 as this comes with the
atomic modesettings driver stack enabled by default. If you do not have
such a kernel version yet I highly recommend to give it a try.

As another possible solution I provide something very radical: use
Wayland. My experience is that the system works way more reliable and
nicer on Intel. I had several issues with Xorg and Intel, I have none on
Wayland.

Cheers
Martin
Jaime
2017-11-09 08:04:40 UTC
Permalink
Hello,

Just by curiosity, I've tried your shell.

It is quite similar to my plasmashell configuration. It works for me
except that I get tons of messages like:

"0 instead of 3 arguments to message {Memory Used: %1 MB (...} supplied
before conversion."
"0 instead of 2 arguments to message {Memory Free: %1 MB (...} supplied
before conversion."
"0 instead of 2 arguments to message {Swap Total: %1 MB (%...} supplied
before conversion."
"0 instead of 3 arguments to message {Swap Used: %1 MB (%2...} supplied
before conversion."
"0 instead of 2 arguments to message {Swap Free: %1 MB (%2...} supplied
before conversion."
"0 instead of 2 arguments to message {Net send/receive: %1...} supplied
before conversion."
"0 instead of 1 arguments to message {Net max used: %1 KB/...} supplied
before conversion."
"0 instead of 2 arguments to message {Memory Total: %1 MB ...} supplied
before conversion."
"0 instead of 3 arguments to message {Memory Used: %1 MB (...} supplied
before conversion."
"0 instead of 2 arguments to message {Memory Free: %1 MB (...} supplied
before conversion."
"0 instead of 2 arguments to message {Swap Total: %1 MB (%...} supplied
before conversion."
"0 instead of 3 arguments to message {Swap Used: %1 MB (%2...} supplied
before conversion."
"0 instead of 2 arguments to message {Swap Free: %1 MB (%2...} supplied
before conversion."
"0 instead of 2 arguments to message {Net send/receive: %1...} supplied
before conversion."
"0 instead of 1 arguments to message {Net max used: %1 KB/...} supplied
before conversion."

from the cpu load widget.

[image: Imágenes integradas 1]

Best regards.
Post by Martin Flöser
Post by Martin Flöser
Are you aware that KWin uses QtQuick for all its UI elements, such as
Post by Martin Flöser
Alt+TAB?
I have deactivated the compositor since sadly it simply does not work
on my laptop (the intel graphics driver just freezes the whole machine).
I did not talk about compositor, I talked about QtQuick! Yes, KWin uses
QtQuick for rendering it's UI, that is unrelated to compositing.
Now you mention that your intel graphics driver freezes the whole system.
I'm using Intel on all my systems and it's the most used driver out there.
We get many, many, many bug reports in KWin about issues. Freezing systems
has not been in the list for now something like two years.
Given that I am very certain that you have a hardware issue where people
can help you with. Intel GPUs are good enough to run the Plasma session
without any negative impact.
So let us help you fix your issues that you can enjoy our work without
having to spend time on writing your own shell.
First thing: are you using the xorg-modesettings driver? If not: install
it, problems solved. Do not (I repeat) do not use the xorg-intel driver.
For kernel I recommend at least version 4.13 as this comes with the atomic
modesettings driver stack enabled by default. If you do not have such a
kernel version yet I highly recommend to give it a try.
As another possible solution I provide something very radical: use
Wayland. My experience is that the system works way more reliable and nicer
on Intel. I had several issues with Xorg and Intel, I have none on Wayland.
Cheers
Martin
Ingo Klöcker
2017-11-16 22:24:52 UTC
Permalink
Post by Martin Flöser
Post by Martin Koller
Post by Martin Flöser
Are you aware that KWin uses QtQuick for all its UI elements, such as
Alt+TAB?
I have deactivated the compositor since sadly it simply does not work
on my laptop (the intel graphics driver just freezes the whole machine).
I did not talk about compositor, I talked about QtQuick! Yes, KWin uses
QtQuick for rendering it's UI, that is unrelated to compositing.
Now you mention that your intel graphics driver freezes the whole
system. I'm using Intel on all my systems and it's the most used driver
out there. We get many, many, many bug reports in KWin about issues.
Freezing systems has not been in the list for now something like two
years.
Given that I am very certain that you have a hardware issue where people
can help you with. Intel GPUs are good enough to run the Plasma session
without any negative impact.
So let us help you fix your issues that you can enjoy our work without
having to spend time on writing your own shell.
First thing: are you using the xorg-modesettings driver? If not: install
it, problems solved. Do not (I repeat) do not use the xorg-intel driver.
For kernel I recommend at least version 4.13 as this comes with the
atomic modesettings driver stack enabled by default. If you do not have
such a kernel version yet I highly recommend to give it a try.
Martin, thanks a lot for your advice!

I've suffered from freezes since I updated my openSUSE 13.2 to Tumbleweed some
time ago (and much longer on my laptop where I've switched to Leap and later
Tumbleweed much earlier). The switch to the modesetting driver seems to have
fixed those issues. It took me some time to find out how to enable the
modesetting driver. To save others the time here's how to do it: Write
#=====
Section "Device"
Identifier "Intel Graphics"
Driver "modesetting"
EndSection
#=====
to a file in /etc/X11/xorg.conf.d/, e.g. 50-device.conf. Make sure that this
is the only (or at least the first) "Device" section in any of the files in
/etc/X11/xorg.conf.d/.

Regards,
Ingo
Friedrich W. H. Kossebau
2017-11-18 14:34:16 UTC
Permalink
Post by Ingo Klöcker
Post by Martin Flöser
Post by Martin Koller
Post by Martin Flöser
Are you aware that KWin uses QtQuick for all its UI elements, such as
Alt+TAB?
I have deactivated the compositor since sadly it simply does not work
on my laptop (the intel graphics driver just freezes the whole machine).
I did not talk about compositor, I talked about QtQuick! Yes, KWin uses
QtQuick for rendering it's UI, that is unrelated to compositing.
Now you mention that your intel graphics driver freezes the whole
system. I'm using Intel on all my systems and it's the most used driver
out there. We get many, many, many bug reports in KWin about issues.
Freezing systems has not been in the list for now something like two
years.
Given that I am very certain that you have a hardware issue where people
can help you with. Intel GPUs are good enough to run the Plasma session
without any negative impact.
So let us help you fix your issues that you can enjoy our work without
having to spend time on writing your own shell.
First thing: are you using the xorg-modesettings driver? If not: install
it, problems solved. Do not (I repeat) do not use the xorg-intel driver.
For kernel I recommend at least version 4.13 as this comes with the
atomic modesettings driver stack enabled by default. If you do not have
such a kernel version yet I highly recommend to give it a try.
Martin, thanks a lot for your advice!
I've suffered from freezes since I updated my openSUSE 13.2 to Tumbleweed
some time ago (and much longer on my laptop where I've switched to Leap and
later Tumbleweed much earlier).
Same here, happy to finally see someone with correlated experience. I never
got any useful hints in the log files, so was close to consider my hardware
broken. Strange enough all freezes seemed to happen while moving the mouse
though, which kept the hope alive it was something software-related.

Curious to see if my daily freeze will now be a thing of the past now that I
changed the driver. Though I am on a 2nd gen 915 device, while all the
modesettings driver talk I came across on a quick search seemed to be only
about gen4 and later? No issues seen for one hour so far, hope grows :)
Post by Ingo Klöcker
The switch to the modesetting driver seems
to have fixed those issues. It took me some time to find out how to enable
the modesetting driver. To save others the time here's how to do it: Write
#=====
Section "Device"
Identifier "Intel Graphics"
Driver "modesetting"
EndSection
#=====
to a file in /etc/X11/xorg.conf.d/, e.g. 50-device.conf. Make sure that this
is the only (or at least the first) "Device" section in any of the files in
/etc/X11/xorg.conf.d/.
Another approach seems to be to uninstall xf86-video-intel, that way the
seemingly hardcoded driver-auto-match logic will skip forward to the
modesetting driver:

[ 12.125] (==) Matched intel as autoconfigured driver 0
[ 12.125] (==) Matched intel as autoconfigured driver 1
[ 12.125] (==) Matched modesetting as autoconfigured driver 2
[ 12.125] (==) Matched fbdev as autoconfigured driver 3
[ 12.125] (==) Matched vesa as autoconfigured driver 4
[ 12.125] (==) Assigned the driver to the xf86ConfigLayout
[ 12.125] (II) LoadModule: "intel"
[ 12.127] (WW) Warning, couldn't open module intel
[ 12.127] (II) UnloadModule: "intel"
[ 12.127] (II) Unloading intel
[ 12.127] (EE) Failed to load module "intel" (module does not exist, 0)
[ 12.127] (II) LoadModule: "modesetting"
[ 12.127] (II) Loading /usr/lib64/xorg/modules/drivers/modesetting_drv.so

Cheers
Friedrich
Milian Wolff
2017-11-20 10:59:54 UTC
Permalink
Post by Friedrich W. H. Kossebau
Post by Ingo Klöcker
Post by Martin Flöser
Post by Martin Koller
Post by Martin Flöser
Are you aware that KWin uses QtQuick for all its UI elements, such as
Alt+TAB?
I have deactivated the compositor since sadly it simply does not work
on my laptop (the intel graphics driver just freezes the whole machine).
I did not talk about compositor, I talked about QtQuick! Yes, KWin uses
QtQuick for rendering it's UI, that is unrelated to compositing.
Now you mention that your intel graphics driver freezes the whole
system. I'm using Intel on all my systems and it's the most used driver
out there. We get many, many, many bug reports in KWin about issues.
Freezing systems has not been in the list for now something like two
years.
Given that I am very certain that you have a hardware issue where people
can help you with. Intel GPUs are good enough to run the Plasma session
without any negative impact.
So let us help you fix your issues that you can enjoy our work without
having to spend time on writing your own shell.
First thing: are you using the xorg-modesettings driver? If not: install
it, problems solved. Do not (I repeat) do not use the xorg-intel driver.
For kernel I recommend at least version 4.13 as this comes with the
atomic modesettings driver stack enabled by default. If you do not have
such a kernel version yet I highly recommend to give it a try.
Martin, thanks a lot for your advice!
I've suffered from freezes since I updated my openSUSE 13.2 to Tumbleweed
some time ago (and much longer on my laptop where I've switched to Leap and
later Tumbleweed much earlier).
Same here, happy to finally see someone with correlated experience. I never
got any useful hints in the log files, so was close to consider my hardware
broken. Strange enough all freezes seemed to happen while moving the mouse
though, which kept the hope alive it was something software-related.
Curious to see if my daily freeze will now be a thing of the past now that I
changed the driver. Though I am on a 2nd gen 915 device, while all the
modesettings driver talk I came across on a quick search seemed to be only
about gen4 and later? No issues seen for one hour so far, hope grows :)
Post by Ingo Klöcker
The switch to the modesetting driver seems
to have fixed those issues. It took me some time to find out how to enable
the modesetting driver. To save others the time here's how to do it: Write
#=====
Section "Device"
Identifier "Intel Graphics"
Driver "modesetting"
EndSection
#=====
to a file in /etc/X11/xorg.conf.d/, e.g. 50-device.conf. Make sure that
this is the only (or at least the first) "Device" section in any of the
files in /etc/X11/xorg.conf.d/.
Another approach seems to be to uninstall xf86-video-intel, that way the
seemingly hardcoded driver-auto-match logic will skip forward to the
[ 12.125] (==) Matched intel as autoconfigured driver 0
[ 12.125] (==) Matched intel as autoconfigured driver 1
[ 12.125] (==) Matched modesetting as autoconfigured driver 2
[ 12.125] (==) Matched fbdev as autoconfigured driver 3
[ 12.125] (==) Matched vesa as autoconfigured driver 4
[ 12.125] (==) Assigned the driver to the xf86ConfigLayout
[ 12.125] (II) LoadModule: "intel"
[ 12.127] (WW) Warning, couldn't open module intel
[ 12.127] (II) UnloadModule: "intel"
[ 12.127] (II) Unloading intel
[ 12.127] (EE) Failed to load module "intel" (module does not exist, 0)
[ 12.127] (II) LoadModule: "modesetting"
[ 12.127] (II) Loading /usr/lib64/xorg/modules/drivers/modesetting_drv.so
I've also recently come across this. According to [1] the performance is
supposedly much worse. Is this still true for more recent mesa/kernel
versions?

[1]: https://www.phoronix.com/scan.php?page=news_item&px=Intel-DDX-May-Tests

Thanks, I'll have to try this out
--
Milian Wolff
***@milianw.de
http://milianw.de
Martin Flöser
2017-11-20 16:28:06 UTC
Permalink
Post by Milian Wolff
Post by Friedrich W. H. Kossebau
Post by Ingo Klöcker
Post by Martin Flöser
Post by Martin Koller
Post by Martin Flöser
Are you aware that KWin uses QtQuick for all its UI elements, such as
Alt+TAB?
I have deactivated the compositor since sadly it simply does not work
on my laptop (the intel graphics driver just freezes the whole machine).
I did not talk about compositor, I talked about QtQuick! Yes, KWin uses
QtQuick for rendering it's UI, that is unrelated to compositing.
Now you mention that your intel graphics driver freezes the whole
system. I'm using Intel on all my systems and it's the most used driver
out there. We get many, many, many bug reports in KWin about issues.
Freezing systems has not been in the list for now something like two
years.
Given that I am very certain that you have a hardware issue where people
can help you with. Intel GPUs are good enough to run the Plasma session
without any negative impact.
So let us help you fix your issues that you can enjoy our work without
having to spend time on writing your own shell.
First thing: are you using the xorg-modesettings driver? If not: install
it, problems solved. Do not (I repeat) do not use the xorg-intel driver.
For kernel I recommend at least version 4.13 as this comes with the
atomic modesettings driver stack enabled by default. If you do not have
such a kernel version yet I highly recommend to give it a try.
Martin, thanks a lot for your advice!
I've suffered from freezes since I updated my openSUSE 13.2 to Tumbleweed
some time ago (and much longer on my laptop where I've switched to Leap and
later Tumbleweed much earlier).
Same here, happy to finally see someone with correlated experience. I never
got any useful hints in the log files, so was close to consider my hardware
broken. Strange enough all freezes seemed to happen while moving the mouse
though, which kept the hope alive it was something software-related.
Curious to see if my daily freeze will now be a thing of the past now that I
changed the driver. Though I am on a 2nd gen 915 device, while all the
modesettings driver talk I came across on a quick search seemed to be only
about gen4 and later? No issues seen for one hour so far, hope grows :)
Post by Ingo Klöcker
The switch to the modesetting driver seems
to have fixed those issues. It took me some time to find out how to enable
the modesetting driver. To save others the time here's how to do it: Write
#=====
Section "Device"
Identifier "Intel Graphics"
Driver "modesetting"
EndSection
#=====
to a file in /etc/X11/xorg.conf.d/, e.g. 50-device.conf. Make sure that
this is the only (or at least the first) "Device" section in any of the
files in /etc/X11/xorg.conf.d/.
Another approach seems to be to uninstall xf86-video-intel, that way the
seemingly hardcoded driver-auto-match logic will skip forward to the
[ 12.125] (==) Matched intel as autoconfigured driver 0
[ 12.125] (==) Matched intel as autoconfigured driver 1
[ 12.125] (==) Matched modesetting as autoconfigured driver 2
[ 12.125] (==) Matched fbdev as autoconfigured driver 3
[ 12.125] (==) Matched vesa as autoconfigured driver 4
[ 12.125] (==) Assigned the driver to the xf86ConfigLayout
[ 12.125] (II) LoadModule: "intel"
[ 12.127] (WW) Warning, couldn't open module intel
[ 12.127] (II) UnloadModule: "intel"
[ 12.127] (II) Unloading intel
[ 12.127] (EE) Failed to load module "intel" (module does not exist, 0)
[ 12.127] (II) LoadModule: "modesetting"
[ 12.127] (II) Loading
/usr/lib64/xorg/modules/drivers/modesetting_drv.so
I've also recently come across this. According to [1] the performance is
supposedly much worse. Is this still true for more recent mesa/kernel
versions?
You quoted Phoronix. I hope you don't expect Phoronix to be able to get
proper measurements. That's something Phoronix still hasn't succeeded
after all those years. Just for fun I clicked that link and the first
graph shows a benchmark showing a game one running at 22.15, the other
at 22.13 fps. This difference is kernel sneezing. So much to that. But
the real issue is that a game running at 22 fps is unplayable. It has
nothing to do in the benchmark, the setup is broken. This has been the
issue as long as I followed Phoronix benchmarking. From an academic
point of view - which you understand as much as I do - it's just all
extremely horrible.

Don't take any numbers serious. Michael doesn't understand how to do
benchmarking. He just runs his tools. He doesn't think about what a
benchmark should show, what he wants to show. And he doesn't interpret
the numbers. He just gives numbers. Do they matter? Who knows. You
derived from his numbers that the "performance is much worse". Is that
the case? I don't know because I don't see this in the benchmark. I just
see numbers. We would have to ask someone understanding the system
whether it makes sense. I assume there are not many people who might be
able to answer the question. Maybe the authors of GtkPerf, maybe Keith
Packard as the author of glamor, but certainly not Michael from
Phoronix.

Hadn't done a Phoronix benchmarking rant for years ;-) Sad that it still
is needed.

For reference I point to a blog post from 2012 where I discuss Phoronix
benchmarking in detail:
http://blog.martin-graesslin.com/blog/2012/09/why-i-dont-like-game-rendering-performance-benchmarks/

Everything written there still fully applies to the benchmark in
question

Cheers
Martin
Milian Wolff
2017-11-20 22:40:38 UTC
Permalink
Post by Martin Flöser
On Samstag, 18. November 2017 15:34:16 CET Friedrich W. H. Kossebau
Post by Friedrich W. H. Kossebau
Post by Ingo Klöcker
Post by Martin Flöser
Post by Martin Koller
Post by Martin Flöser
Are you aware that KWin uses QtQuick for all its UI elements, such as
Alt+TAB?
I have deactivated the compositor since sadly it simply does not work
on my laptop (the intel graphics driver just freezes the whole machine).
I did not talk about compositor, I talked about QtQuick! Yes, KWin uses
QtQuick for rendering it's UI, that is unrelated to compositing.
Now you mention that your intel graphics driver freezes the whole
system. I'm using Intel on all my systems and it's the most used driver
out there. We get many, many, many bug reports in KWin about issues.
Freezing systems has not been in the list for now something like two
years.
Given that I am very certain that you have a hardware issue where people
can help you with. Intel GPUs are good enough to run the Plasma session
without any negative impact.
So let us help you fix your issues that you can enjoy our work without
having to spend time on writing your own shell.
First thing: are you using the xorg-modesettings driver? If not: install
it, problems solved. Do not (I repeat) do not use the xorg-intel driver.
For kernel I recommend at least version 4.13 as this comes with the
atomic modesettings driver stack enabled by default. If you do not have
such a kernel version yet I highly recommend to give it a try.
Martin, thanks a lot for your advice!
I've suffered from freezes since I updated my openSUSE 13.2 to Tumbleweed
some time ago (and much longer on my laptop where I've switched to Leap and
later Tumbleweed much earlier).
Same here, happy to finally see someone with correlated experience. I never
got any useful hints in the log files, so was close to consider my hardware
broken. Strange enough all freezes seemed to happen while moving the mouse
though, which kept the hope alive it was something software-related.
Curious to see if my daily freeze will now be a thing of the past now that I
changed the driver. Though I am on a 2nd gen 915 device, while all the
modesettings driver talk I came across on a quick search seemed to be only
about gen4 and later? No issues seen for one hour so far, hope grows
:)
Post by Ingo Klöcker
The switch to the modesetting driver seems
to have fixed those issues. It took me some time to find out how to enable
the modesetting driver. To save others the time here's how to do it: Write
#=====
Section "Device"
Identifier "Intel Graphics"
Driver "modesetting"
EndSection
#=====
to a file in /etc/X11/xorg.conf.d/, e.g. 50-device.conf. Make sure that
this is the only (or at least the first) "Device" section in any of the
files in /etc/X11/xorg.conf.d/.
Another approach seems to be to uninstall xf86-video-intel, that way the
seemingly hardcoded driver-auto-match logic will skip forward to the
[ 12.125] (==) Matched intel as autoconfigured driver 0
[ 12.125] (==) Matched intel as autoconfigured driver 1
[ 12.125] (==) Matched modesetting as autoconfigured driver 2
[ 12.125] (==) Matched fbdev as autoconfigured driver 3
[ 12.125] (==) Matched vesa as autoconfigured driver 4
[ 12.125] (==) Assigned the driver to the xf86ConfigLayout
[ 12.125] (II) LoadModule: "intel"
[ 12.127] (WW) Warning, couldn't open module intel
[ 12.127] (II) UnloadModule: "intel"
[ 12.127] (II) Unloading intel
[ 12.127] (EE) Failed to load module "intel" (module does not exist, 0)
[ 12.127] (II) LoadModule: "modesetting"
[ 12.127] (II) Loading
/usr/lib64/xorg/modules/drivers/modesetting_drv.so
I've also recently come across this. According to [1] the performance is
supposedly much worse. Is this still true for more recent mesa/kernel
versions?
You quoted Phoronix. I hope you don't expect Phoronix to be able to get
proper measurements. That's something Phoronix still hasn't succeeded
after all those years. Just for fun I clicked that link and the first
graph shows a benchmark showing a game one running at 22.15, the other
at 22.13 fps. This difference is kernel sneezing. So much to that. But
the real issue is that a game running at 22 fps is unplayable. It has
nothing to do in the benchmark, the setup is broken. This has been the
issue as long as I followed Phoronix benchmarking. From an academic
point of view - which you understand as much as I do - it's just all
extremely horrible.
Don't take any numbers serious. Michael doesn't understand how to do
benchmarking. He just runs his tools. He doesn't think about what a
benchmark should show, what he wants to show. And he doesn't interpret
the numbers. He just gives numbers. Do they matter? Who knows. You
derived from his numbers that the "performance is much worse". Is that
the case? I don't know because I don't see this in the benchmark. I just
see numbers. We would have to ask someone understanding the system
whether it makes sense. I assume there are not many people who might be
able to answer the question. Maybe the authors of GtkPerf, maybe Keith
Packard as the author of glamor, but certainly not Michael from
Phoronix.
Hadn't done a Phoronix benchmarking rant for years ;-) Sad that it still
is needed.
For reference I point to a blog post from 2012 where I discuss Phoronix
http://blog.martin-graesslin.com/blog/2012/09/why-i-dont-like-game-rendering
-performance-benchmarks/
Everything written there still fully applies to the benchmark in
question
Thanks for the rant :) I rarely look at graphic related Phoronix stuff since I
don't know the tools and what they measure. For some I/O and CPU stuff, the
tools are useful and thus the numbers reported are, too.

So since the tools used here are apparently useless, could you or someone else
please answer the actual question: Is there any perceived performance
difference between modesetting driver and intel driver? I assume it isn't from
the way you respond. Just wanted to make sure.

Thanks
--
Milian Wolff
***@milianw.de
http://milianw.de
Milian Wolff
2017-11-20 23:27:06 UTC
Permalink
Post by Milian Wolff
Post by Martin Flöser
On Samstag, 18. November 2017 15:34:16 CET Friedrich W. H. Kossebau
Post by Friedrich W. H. Kossebau
Post by Ingo Klöcker
Post by Martin Flöser
Post by Martin Koller
Post by Martin Flöser
Are you aware that KWin uses QtQuick for all its UI elements,
such
as
Alt+TAB?
I have deactivated the compositor since sadly it simply does not work
on my laptop (the intel graphics driver just freezes the whole
machine).
I did not talk about compositor, I talked about QtQuick! Yes, KWin uses
QtQuick for rendering it's UI, that is unrelated to compositing.
Now you mention that your intel graphics driver freezes the whole
system. I'm using Intel on all my systems and it's the most used driver
out there. We get many, many, many bug reports in KWin about issues.
Freezing systems has not been in the list for now something like two
years.
Given that I am very certain that you have a hardware issue where people
can help you with. Intel GPUs are good enough to run the Plasma session
without any negative impact.
So let us help you fix your issues that you can enjoy our work without
having to spend time on writing your own shell.
First thing: are you using the xorg-modesettings driver? If not: install
it, problems solved. Do not (I repeat) do not use the xorg-intel driver.
For kernel I recommend at least version 4.13 as this comes with the
atomic modesettings driver stack enabled by default. If you do not have
such a kernel version yet I highly recommend to give it a try.
Martin, thanks a lot for your advice!
I've suffered from freezes since I updated my openSUSE 13.2 to Tumbleweed
some time ago (and much longer on my laptop where I've switched to
Leap
and
later Tumbleweed much earlier).
Same here, happy to finally see someone with correlated experience. I never
got any useful hints in the log files, so was close to consider my hardware
broken. Strange enough all freezes seemed to happen while moving the mouse
though, which kept the hope alive it was something software-related.
Curious to see if my daily freeze will now be a thing of the past now that I
changed the driver. Though I am on a 2nd gen 915 device, while all the
modesettings driver talk I came across on a quick search seemed to be only
about gen4 and later? No issues seen for one hour so far, hope grows
:)
Post by Ingo Klöcker
The switch to the modesetting driver seems
to have fixed those issues. It took me some time to find out how to enable
the modesetting driver. To save others the time here's how to do it: Write
#=====
Section "Device"
Identifier "Intel Graphics"
Driver "modesetting"
EndSection
#=====
to a file in /etc/X11/xorg.conf.d/, e.g. 50-device.conf. Make sure that
this is the only (or at least the first) "Device" section in any of the
files in /etc/X11/xorg.conf.d/.
Another approach seems to be to uninstall xf86-video-intel, that way the
seemingly hardcoded driver-auto-match logic will skip forward to the
[ 12.125] (==) Matched intel as autoconfigured driver 0
[ 12.125] (==) Matched intel as autoconfigured driver 1
[ 12.125] (==) Matched modesetting as autoconfigured driver 2
[ 12.125] (==) Matched fbdev as autoconfigured driver 3
[ 12.125] (==) Matched vesa as autoconfigured driver 4
[ 12.125] (==) Assigned the driver to the xf86ConfigLayout
[ 12.125] (II) LoadModule: "intel"
[ 12.127] (WW) Warning, couldn't open module intel
[ 12.127] (II) UnloadModule: "intel"
[ 12.127] (II) Unloading intel
[ 12.127] (EE) Failed to load module "intel" (module does not exist, 0)
[ 12.127] (II) LoadModule: "modesetting"
[ 12.127] (II) Loading
/usr/lib64/xorg/modules/drivers/modesetting_drv.so
I've also recently come across this. According to [1] the performance is
supposedly much worse. Is this still true for more recent mesa/kernel
versions?
You quoted Phoronix. I hope you don't expect Phoronix to be able to get
proper measurements. That's something Phoronix still hasn't succeeded
after all those years. Just for fun I clicked that link and the first
graph shows a benchmark showing a game one running at 22.15, the other
at 22.13 fps. This difference is kernel sneezing. So much to that. But
the real issue is that a game running at 22 fps is unplayable. It has
nothing to do in the benchmark, the setup is broken. This has been the
issue as long as I followed Phoronix benchmarking. From an academic
point of view - which you understand as much as I do - it's just all
extremely horrible.
Don't take any numbers serious. Michael doesn't understand how to do
benchmarking. He just runs his tools. He doesn't think about what a
benchmark should show, what he wants to show. And he doesn't interpret
the numbers. He just gives numbers. Do they matter? Who knows. You
derived from his numbers that the "performance is much worse". Is that
the case? I don't know because I don't see this in the benchmark. I just
see numbers. We would have to ask someone understanding the system
whether it makes sense. I assume there are not many people who might be
able to answer the question. Maybe the authors of GtkPerf, maybe Keith
Packard as the author of glamor, but certainly not Michael from
Phoronix.
Hadn't done a Phoronix benchmarking rant for years ;-) Sad that it still
is needed.
For reference I point to a blog post from 2012 where I discuss Phoronix
http://blog.martin-graesslin.com/blog/2012/09/why-i-dont-like-game-renderi
ng -performance-benchmarks/
Everything written there still fully applies to the benchmark in
question
Thanks for the rant :) I rarely look at graphic related Phoronix stuff since
I don't know the tools and what they measure. For some I/O and CPU stuff,
the tools are useful and thus the numbers reported are, too.
So since the tools used here are apparently useless, could you or someone
else please answer the actual question: Is there any perceived performance
difference between modesetting driver and intel driver? I assume it isn't
from the way you respond. Just wanted to make sure.
Well, I tried it out myself now that tosky said it works for him. Indeed, it
does for me too - and some glaring bugs are resolved on top! Most notably I'm
finally able to launch secondary X sessions, nice :)

Thanks everyone for recommending this. I bet more people have this old driver
installed out of habit (like I did), without a clear understanding of what
they are doing.

Cheers
--
Milian Wolff
***@milianw.de
http://milianw.de
Boudhayan Gupta
2017-11-21 00:50:39 UTC
Permalink
I've been using the modesetting driver for over a year and a half now
- on Sandy Bridge, Ivy Bridge, Broadwell and now Kaby Lake hardware.
I've *never* come across a bug all this while (in fact, I was forced
to switch due to GPU lockups on Sandy Bridge with xf86-video-intel).

I haven't had a perceptible difference in performance, everything is
tear-free by default (I had to tinker with xorg.conf to enable
sync-to-vblank with SNA on the Intel DDX) - overall a much smoother
out of the box experience with the modesetting driver than the intel
one.

My 2c, experience on Arch Linux.
Thanks,
Boudhayan Gupta
KDE e.V. - Community Working Group
+49 151 71032970
Post by Milian Wolff
Post by Milian Wolff
Post by Martin Flöser
On Samstag, 18. November 2017 15:34:16 CET Friedrich W. H. Kossebau
Post by Friedrich W. H. Kossebau
Post by Ingo Klöcker
Post by Martin Flöser
Post by Martin Koller
Post by Martin Flöser
Are you aware that KWin uses QtQuick for all its UI elements,
such
as
Alt+TAB?
I have deactivated the compositor since sadly it simply does not
work
on my laptop (the intel graphics driver just freezes the whole
machine).
I did not talk about compositor, I talked about QtQuick! Yes, KWin uses
QtQuick for rendering it's UI, that is unrelated to compositing.
Now you mention that your intel graphics driver freezes the whole
system. I'm using Intel on all my systems and it's the most used driver
out there. We get many, many, many bug reports in KWin about issues.
Freezing systems has not been in the list for now something like two
years.
Given that I am very certain that you have a hardware issue where
people
can help you with. Intel GPUs are good enough to run the Plasma session
without any negative impact.
So let us help you fix your issues that you can enjoy our work without
having to spend time on writing your own shell.
install
it, problems solved. Do not (I repeat) do not use the xorg-intel
driver.
For kernel I recommend at least version 4.13 as this comes with the
atomic modesettings driver stack enabled by default. If you do not have
such a kernel version yet I highly recommend to give it a try.
Martin, thanks a lot for your advice!
I've suffered from freezes since I updated my openSUSE 13.2 to Tumbleweed
some time ago (and much longer on my laptop where I've switched to
Leap
and
later Tumbleweed much earlier).
Same here, happy to finally see someone with correlated experience. I never
got any useful hints in the log files, so was close to consider my hardware
broken. Strange enough all freezes seemed to happen while moving the mouse
though, which kept the hope alive it was something software-related.
Curious to see if my daily freeze will now be a thing of the past now that I
changed the driver. Though I am on a 2nd gen 915 device, while all the
modesettings driver talk I came across on a quick search seemed to be only
about gen4 and later? No issues seen for one hour so far, hope grows
:)
Post by Ingo Klöcker
The switch to the modesetting driver seems
to have fixed those issues. It took me some time to find out how to enable
the modesetting driver. To save others the time here's how to do it: Write
#=====
Section "Device"
Identifier "Intel Graphics"
Driver "modesetting"
EndSection
#=====
to a file in /etc/X11/xorg.conf.d/, e.g. 50-device.conf. Make sure that
this is the only (or at least the first) "Device" section in any of the
files in /etc/X11/xorg.conf.d/.
Another approach seems to be to uninstall xf86-video-intel, that way the
seemingly hardcoded driver-auto-match logic will skip forward to the
[ 12.125] (==) Matched intel as autoconfigured driver 0
[ 12.125] (==) Matched intel as autoconfigured driver 1
[ 12.125] (==) Matched modesetting as autoconfigured driver 2
[ 12.125] (==) Matched fbdev as autoconfigured driver 3
[ 12.125] (==) Matched vesa as autoconfigured driver 4
[ 12.125] (==) Assigned the driver to the xf86ConfigLayout
[ 12.125] (II) LoadModule: "intel"
[ 12.127] (WW) Warning, couldn't open module intel
[ 12.127] (II) UnloadModule: "intel"
[ 12.127] (II) Unloading intel
[ 12.127] (EE) Failed to load module "intel" (module does not exist, 0)
[ 12.127] (II) LoadModule: "modesetting"
[ 12.127] (II) Loading
/usr/lib64/xorg/modules/drivers/modesetting_drv.so
I've also recently come across this. According to [1] the performance is
supposedly much worse. Is this still true for more recent mesa/kernel
versions?
You quoted Phoronix. I hope you don't expect Phoronix to be able to get
proper measurements. That's something Phoronix still hasn't succeeded
after all those years. Just for fun I clicked that link and the first
graph shows a benchmark showing a game one running at 22.15, the other
at 22.13 fps. This difference is kernel sneezing. So much to that. But
the real issue is that a game running at 22 fps is unplayable. It has
nothing to do in the benchmark, the setup is broken. This has been the
issue as long as I followed Phoronix benchmarking. From an academic
point of view - which you understand as much as I do - it's just all
extremely horrible.
Don't take any numbers serious. Michael doesn't understand how to do
benchmarking. He just runs his tools. He doesn't think about what a
benchmark should show, what he wants to show. And he doesn't interpret
the numbers. He just gives numbers. Do they matter? Who knows. You
derived from his numbers that the "performance is much worse". Is that
the case? I don't know because I don't see this in the benchmark. I just
see numbers. We would have to ask someone understanding the system
whether it makes sense. I assume there are not many people who might be
able to answer the question. Maybe the authors of GtkPerf, maybe Keith
Packard as the author of glamor, but certainly not Michael from
Phoronix.
Hadn't done a Phoronix benchmarking rant for years ;-) Sad that it still
is needed.
For reference I point to a blog post from 2012 where I discuss Phoronix
http://blog.martin-graesslin.com/blog/2012/09/why-i-dont-like-game-renderi
ng -performance-benchmarks/
Everything written there still fully applies to the benchmark in
question
Thanks for the rant :) I rarely look at graphic related Phoronix stuff since
I don't know the tools and what they measure. For some I/O and CPU stuff,
the tools are useful and thus the numbers reported are, too.
So since the tools used here are apparently useless, could you or someone
else please answer the actual question: Is there any perceived performance
difference between modesetting driver and intel driver? I assume it isn't
from the way you respond. Just wanted to make sure.
Well, I tried it out myself now that tosky said it works for him. Indeed, it
does for me too - and some glaring bugs are resolved on top! Most notably I'm
finally able to launch secondary X sessions, nice :)
Thanks everyone for recommending this. I bet more people have this old driver
installed out of habit (like I did), without a clear understanding of what
they are doing.
Cheers
--
Milian Wolff
http://milianw.de
Friedrich W. H. Kossebau
2017-11-09 14:32:46 UTC
Permalink
Post by Martin Koller
Post by Martin Flöser
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
Martin Koller
2017-11-09 18:18:26 UTC
Permalink
Post by Friedrich W. H. Kossebau
Post by Martin Koller
Post by Martin Flöser
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
I did not make false or unresearched claims.
QPainter, wich is the base for drawing in QWidgets, is - AFAIK - not using
hardware acceleration.
At least inside Qt. Martin F. just explained that deep down in the graphics
stack there is still acceleration used, but that was not my point.
Post by Friedrich W. H. Kossebau
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
* "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.
will change
Post by Friedrich W. H. Kossebau
* "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.
the major difference between plasmashell and liquidshell IS the non-usage of QtQuick, therefore
it definitely needs to be mentioned.
That does not imply judgement. It's just an explanation of what technology
it uses and which it does not - given that these are the two major
possibilities from Qt.
I have adjusted the README

<snip>
Post by Friedrich W. H. Kossebau
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?
not planned
--
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

() ascii ribbon campaign - against html e-mail
/\ - against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
Martin Koller
2017-11-29 20:23:15 UTC
Permalink
Post by Martin Koller
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 ?

A note regarding the comment to not use the start-here-kde logo:
I got in contact with the visual design group and got the information to stay with this logo.
--
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

() ascii ribbon campaign - against html e-mail
/\ - against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
Sebastian Kügler
2017-11-30 09:04:51 UTC
Permalink
Post by Martin Koller
Post by Martin Koller
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 ?
I got in contact with the visual design group and got the information to
stay with this logo.
I strongly disagree. Could you point me to the discussion?
--
sebas

http://www.kde.org | http://vizZzion.org
Martin Koller
2017-11-30 17:41:28 UTC
Permalink
Post by Sebastian Kügler
Post by Martin Koller
Post by Martin Koller
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 ?
I got in contact with the visual design group and got the information to
stay with this logo.
I strongly disagree. Could you point me to the discussion?
it was mail exchange in private (german) mails with the breeze/oxygen-icons maintainer
"kainz.a" <***@gmail.com>
--
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

() ascii ribbon campaign - against html e-mail
/\ - against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
Sebastian Kügler
2017-12-01 13:05:19 UTC
Permalink
On Thu, 30 Nov 2017 18:41:28 +0100
Post by Martin Koller
Post by Sebastian Kügler
Post by Martin Koller
Post by Martin Koller
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 ?
I got in contact with the visual design group and got the
information to stay with this logo.
I strongly disagree. Could you point me to the discussion?
it was mail exchange in private (german) mails with the
In any case, this is not just a visual design question, it's a branding
and marketing question just as much, and a general communication and
positioning question as well.

I'm vetoing any move to released software at the very least until the
logo has changed. I also don't think that a technical review of the
code is enough to warrant us to ship liquidshell as a finished product,
for the reasons that Martin Flöser pointed out. It would harm KDE as a
whole and Plasma specifically (ironically, the product that you use
most parts from).

Cheers,

-- sebas
Albert Astals Cid
2017-12-02 09:27:16 UTC
Permalink
El divendres, 1 de desembre de 2017, a les 14:05:19 CET, Sebastian Kügler va
Post by Sebastian Kügler
On Thu, 30 Nov 2017 18:41:28 +0100
Post by Martin Koller
Post by Sebastian Kügler
Post by Martin Koller
Post by Martin Koller
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 ?
I got in contact with the visual design group and got the
information to stay with this logo.
I strongly disagree. Could you point me to the discussion?
it was mail exchange in private (german) mails with the
In any case, this is not just a visual design question, it's a branding
and marketing question just as much, and a general communication and
positioning question as well.
Yes, the logo has to be changed.
Post by Sebastian Kügler
I'm vetoing any move to released software at the very least until the
logo has changed. I also don't think that a technical review of the
code is enough to warrant us to ship liquidshell as a finished product,
for the reasons that Martin Flöser pointed out. It would harm KDE as a
whole and Plasma specifically (ironically, the product that you use
most parts from).
This is an interesting position, are we supposed to subordinate technical
decisions to marketing now?

Also are you even sure we get better marketing by not allowing liquidshell to
be a KDE thing?

I can very well see headlines like "Plasma developers force other KDE
developers outside of KDE".

I would like to empathize that we are at our core Innovation.

And yes, I agree that doing a desktop shell in QWidgets doesn't seem like
Innovation to me, but Innovation is the process of having new ideas and
products.

Maybe this one has great "external" success and against your and my prediction
gives KDE 1000 new developers that besides contributing to it also end up
contributing to other parts of our software range.

Let's try to think positive :)

Cheers,
Albert
Post by Sebastian Kügler
Cheers,
-- sebas
Sebastian Kügler
2017-12-02 10:52:53 UTC
Permalink
On Sat, 02 Dec 2017 10:27:16 +0100
Post by Albert Astals Cid
El divendres, 1 de desembre de 2017, a les 14:05:19 CET, Sebastian
Post by Sebastian Kügler
On Thu, 30 Nov 2017 18:41:28 +0100
Post by Martin Koller
Post by Sebastian Kügler
Post by Martin Koller
Post by Martin Koller
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 ?
A note regarding the comment to not use the start-here-kde
logo: I got in contact with the visual design group and got
the information to stay with this logo.
I strongly disagree. Could you point me to the discussion?
it was mail exchange in private (german) mails with the
In any case, this is not just a visual design question, it's a
branding and marketing question just as much, and a general
communication and positioning question as well.
Yes, the logo has to be changed.
Post by Sebastian Kügler
I'm vetoing any move to released software at the very least until
the logo has changed. I also don't think that a technical review of
the code is enough to warrant us to ship liquidshell as a finished
product, for the reasons that Martin Flöser pointed out. It would
harm KDE as a whole and Plasma specifically (ironically, the
product that you use most parts from).
This is an interesting position, are we supposed to subordinate
technical decisions to marketing now?
We are doing a review not just based on the code, but based on "is this
suitable and a good idea for KDE to release in this way". It's not
purely marketing, but general communication.

If I wrote a very simple application that just poppped up a Window that
said "Krita is crap", the code could technically be totally fine, but
it may still not be a good idea to do it. If Martin wants to release
this under the KDE umbrella, we should make sure we're not actively
harming other people working inside KDE.
Post by Albert Astals Cid
Also are you even sure we get better marketing by not allowing
liquidshell to be a KDE thing?
I can very well see headlines like "Plasma developers force other KDE
developers outside of KDE".
I would like to empathize that we are at our core Innovation.
And yes, I agree that doing a desktop shell in QWidgets doesn't seem
like Innovation to me, but Innovation is the process of having new
ideas and products.
Absolutely, but it should also be advertised in a healthy way, and
liquidshell in its current form isn't.
Post by Albert Astals Cid
Maybe this one has great "external" success and against your and my
prediction gives KDE 1000 new developers that besides contributing to
it also end up contributing to other parts of our software range.
Let's try to think positive :)
That's the point Martin Flöser already made: liquidshell should be
advertised based on its merits, not based on "plasmashell is shit,
here's something better (I think)"

Cheers,

-- sebas
Albert Astals Cid
2017-12-02 11:42:17 UTC
Permalink
El dissabte, 2 de desembre de 2017, a les 11:52:53 CET, Sebastian Kügler va
Post by Sebastian Kügler
On Sat, 02 Dec 2017 10:27:16 +0100
Post by Albert Astals Cid
El divendres, 1 de desembre de 2017, a les 14:05:19 CET, Sebastian
Post by Sebastian Kügler
On Thu, 30 Nov 2017 18:41:28 +0100
On Donnerstag, 30. November 2017 10:04:51 CET Sebastian Kügler
Post by Sebastian Kügler
Post by Martin Koller
Post by Martin Koller
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 ?
A note regarding the comment to not use the start-here-kde
logo: I got in contact with the visual design group and got
the information to stay with this logo.
I strongly disagree. Could you point me to the discussion?
it was mail exchange in private (german) mails with the
In any case, this is not just a visual design question, it's a
branding and marketing question just as much, and a general
communication and positioning question as well.
Yes, the logo has to be changed.
Post by Sebastian Kügler
I'm vetoing any move to released software at the very least until
the logo has changed. I also don't think that a technical review of
the code is enough to warrant us to ship liquidshell as a finished
product, for the reasons that Martin Flöser pointed out. It would
harm KDE as a whole and Plasma specifically (ironically, the
product that you use most parts from).
This is an interesting position, are we supposed to subordinate
technical decisions to marketing now?
We are doing a review not just based on the code, but based on "is this
suitable and a good idea for KDE to release in this way". It's not
purely marketing, but general communication.
If I wrote a very simple application that just poppped up a Window that
said "Krita is crap", the code could technically be totally fine, but
it may still not be a good idea to do it. If Martin wants to release
this under the KDE umbrella, we should make sure we're not actively
harming other people working inside KDE.
Post by Albert Astals Cid
Also are you even sure we get better marketing by not allowing
liquidshell to be a KDE thing?
I can very well see headlines like "Plasma developers force other KDE
developers outside of KDE".
I would like to empathize that we are at our core Innovation.
And yes, I agree that doing a desktop shell in QWidgets doesn't seem
like Innovation to me, but Innovation is the process of having new
ideas and products.
Absolutely, but it should also be advertised in a healthy way, and
liquidshell in its current form isn't.
Ok, so we're on the same page :)

Cheers,
Albert
Martin Flöser
2017-11-30 18:50:09 UTC
Permalink
Post by Martin Koller
Post by Martin Koller
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 ?
I got in contact with the visual design group and got the information
to stay with this logo.
Like sebas I also strongly disagree. This would be highly confusing. If
Plasma doesn't use the KDE icon another desktop shell shouldn't use KDE
icon as well. I strongly suggest to use a different icon, just to make
it clear that this is not the official KDE desktop shell.

Cheers
Martin
Martin Flöser
2017-11-30 18:57:45 UTC
Permalink
Post by Martin Koller
Post by Martin Koller
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.

Cheers
Martin
Albert Astals Cid
2017-12-02 09:17:56 UTC
Permalink
El dijous, 30 de novembre de 2017, a les 19:57:45 CET, Martin Flöser va
Post by Martin Flöser
Post by Martin Koller
Post by Martin Koller
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 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 :)

Cheers,
Albert
Post by Martin Flöser
Cheers
Martin
Martin Flöser
2017-12-02 12:26:18 UTC
Permalink
Post by Albert Astals Cid
El dijous, 30 de novembre de 2017, a les 19:57:45 CET, Martin Flöser va
Post by Martin Flöser
Post by Martin Koller
Post by Martin Koller
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.
Post by Albert Astals Cid
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. 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?

Cheers
Martin Flöser
Albert Astals Cid
2017-12-03 11:28:02 UTC
Permalink
El dissabte, 2 de desembre de 2017, a les 13:26:18 CET, Martin Flöser va
Post by Martin Flöser
Post by Albert Astals Cid
El dijous, 30 de novembre de 2017, a les 19:57:45 CET, Martin Flöser va
Post by Martin Flöser
Post by Martin Koller
Post by Martin Koller
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?
Post by Martin Flöser
Post by Albert Astals Cid
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.
* Plasma (QtQuick)
* LxQt (QtWidgets)
* Lumina (QtWidgets)
* Hawaii (QtQuick AFAIK)
* 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
* 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.
Post by Martin Flöser
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.

Cheers,
Albert
Post by Martin Flöser
Cheers
Martin Flöser
Martin Flöser
2017-12-03 12:51:49 UTC
Permalink
Post by Albert Astals Cid
El dissabte, 2 de desembre de 2017, a les 13:26:18 CET, Martin Flöser va
Post by Martin Flöser
Post by Albert Astals Cid
El dijous, 30 de novembre de 2017, a les 19:57:45 CET, Martin Flöser va
Post by Martin Flöser
Post by Martin Koller
Post by Martin Koller
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.
Post by Albert Astals Cid
Post by Martin Flöser
Post by Albert Astals Cid
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.
* Plasma (QtQuick)
* LxQt (QtWidgets)
* Lumina (QtWidgets)
* Hawaii (QtQuick AFAIK)
* 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
* 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.
Post by Albert Astals Cid
Post by Martin Flöser
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
Albert Astals Cid
2017-12-03 21:38:00 UTC
Permalink
El diumenge, 3 de desembre de 2017, a les 13:51:49 CET, Martin Flöser va
Post by Martin Flöser
Post by Albert Astals Cid
El dissabte, 2 de desembre de 2017, a les 13:26:18 CET, Martin Flöser va
Post by Martin Flöser
Post by Albert Astals Cid
El dijous, 30 de novembre de 2017, a les 19:57:45 CET, Martin Flöser va
Post by Martin Flöser
Post by Martin Koller
Post by Martin Koller
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.
There's no such thing as extregear anymore (well there is in the l10n module
sense but we should be trying to get rid of it)

Conceptually, there is:
* stuff hosted in KDE and released as a "group", i.e.
- Plasma
- KDE Frameworks
- "KDE Applications" [1]
* stuff hosted in KDE and released individually [2]
- Krita
- rsibreak
- kaffeine
- konversation
- etc

So I don't understand your reasoning.

Are you suggesting that we can host something in kde repos and it gets
released by a kde person but still not be a kde project?

Cheers,
Albert

[1] yes we all agree it's a bad name but noone has come up with a better one
[2] formerly known as extragear

Loading...