liquidshell in kdereview

[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.

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: 
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

liquidshell in kdereview

[Martin Koller]

Hi,

since some time has already passed and there was no conclusion, I'll try once 
again
to announce liquidshell.

I have made adjustments to the README which now says:

liquidshell is a basic Desktop Shell implemented using QtWidgets.

Main Features:
- Wallpaper per virtual desktop
- No animations, low memory and CPU footprint
- Instant startup
- No use of activities
- 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 Frameworks 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.
  It also features PackageKit software updates integration.
  The DeviceList also shows devices connected and paired with KDEConnect.
  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)

I think the final place should be extragear.

openSuse's OBS has already packages for some distributions

Screenshots:
http://members.aon.at/m.koller/liquidshell_20190310_light.png
http://members.aon.at/m.koller/liquidshell_20190310_dark.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

Re: liquidshell in kdereview

[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

2017-11-03 23:30 GMT+03:00 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.
>
> 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: 
> 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
diff --git a/Battery.cxx b/Battery.cxx
index cc9b6fc..01dda67 100644
--- a/Battery.cxx
+++ b/Battery.cxx
@@ -22,7 +22,7 @@
 #include 
 #include 
 
-#include 
+//#include 
 #include 
 
 #include 
@@ -49,7 +49,7 @@ Battery::Battery(QWidget *parent)
 hide();
   else
   {
-connect(Solid::Power::self(), &Solid::Power::acPluggedChanged, this, 
&Battery::changed);
+///connect(Solid::Power::self(), &Solid::Power::acPluggedChanged, this, 
&Battery::changed);
 connect(device.as(), 
&Solid::Battery::chargePercentChanged, this, &Battery::changed);
 connect(device.as(), &Solid::Battery::chargeStateChanged, 
this, &Battery::changed);
 connect(device.as(), &Solid::Battery::timeToFullChanged, 
this, &Battery::changed);
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 7077710..1cabcfa 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -16,7 +16,7 @@ find_package(Qt5 5.7 CONFIG REQUIRED COMPONENTS
 
 find_package(KF5 REQUIRED COMPONENTS
  WindowSystem WidgetsAddons ConfigWidgets Config KIO IconThemes 
ItemViews Archive
- Notifications I18n NetworkManagerQt Service Solid BluezQt 
KCMUtils Crash DBusAddons
+ Notifications I18n NetworkManagerQt Service Solid BluezQt 
KCMUtils Crash DBusAddons KDELibs4Support
 )
 
 set(SOURCES
@@ -95,6 +95,7 @@ target_link_libraries(${TARGET}
   KF5::DBusAddons
   KF5::ItemViews
   KF5::Archi

Re: liquidshell in kdereview

[Martin Koller]

On Samstag, 4. November 2017 02:35:27 CET Alexander Potashev wrote:
> 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

Re: liquidshell in kdereview

[Kai Uwe Broulik]

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(&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

Cheers
Kai Uwe

Re: liquidshell in kdereview

[Alexander Neundorf]

On 2017 M11 3, Fri 21:30:19 CET Martin Koller wrote:
> Hi all,
...
> - Just one bottom DesktopPanel, containing:

I always put my panel to the right or left edge (intead at the bottom)...

...
> 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

Re: liquidshell in kdereview

[Martin Koller]

Hi,

thanks for you review!

On Samstag, 4. November 2017 19:41:27 CET Kai Uwe Broulik wrote:
> Hi,
> 
> AppMenu.cxx:
> * 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

> * 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())

> Battery.cxx:
> * 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 ?

> * 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.

> * secsToHM looks not ideal form an i18n perspective

Suggestion ?
 
> CMakeLists.txt:
> * No project name set

fixed

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

Thanks for the hint, but this is really ugly to write.
I see no advantage in doing so. 

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

You mean this ?
const DesktopWidget::Wallpaper &getWallpaper() const { return wallpaper; }

Of course. What else ?

> desktop.cxx:
> * Missing AA_UseHighDpiPixmaps attribute

fixed

> DesktopWidget.cxx:
> * window type NET::Desktop should imply NET::KeepBelow

ok, removed

> * 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

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

Because ?

> QuickLaunch.cxx:
> * Similar issues as AppMenu.cxx

filter now on QDir::Files

> * 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 ...

> StartMenu.cxx:
> * 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.

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

hardcoded is the part for the features I supply.
Why do you think this is awful ?
 
> 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

since I have no hardware to test that, I did not care.
However I have now added the AA_UseHighDpiPixmaps attribute

> * 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.

> * 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.

> * 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() &&
   !device.as()->isRemovable() )
  {
//qDebug() << device.udi() << "not Removable";
return;
  }

  // show only removable devices
  if ( device.parent().is() &&
   !device.parent().as()->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 ?

> 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.

> 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 ?

> * No battery applet,

I don't understand.
You'd like to have a battery de

Re: liquidshell in kdereview

[Martin Koller]

On Samstag, 4. November 2017 20:58:49 CET Alexander Neundorf wrote:
> On 2017 M11 3, Fri 21:30:19 CET Martin Koller wrote:
> > Hi all,
> ...
> > - Just one bottom DesktopPanel, containing:
> 
> I always put my panel to the right or left edge (intead at the bottom)...

Then I fear liquidshell is simply not for you.

> ...
> > 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

Re: liquidshell in kdereview

[Alexander Neundorf]

On 2017 M11 5, Sun 19:27:27 CET Martin Koller wrote:
> On Samstag, 4. November 2017 20:58:49 CET Alexander Neundorf wrote:
> > On 2017 M11 3, Fri 21:30:19 CET Martin Koller wrote:
> > > Hi all,
> > 
> > ...
> > 
> > > - Just one bottom DesktopPanel, containing:
> > 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

Re: liquidshell in kdereview

[Luca Beltrame]

Il giorno Sun, 05 Nov 2017 19:24:55 +0100
Martin Koller  ha scritto:


> > * 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


pgpjoVC8Ja7cB.pgp
Description: Firma digitale OpenPGP

Re: liquidshell in kdereview

[Aleix Pol]

On Fri, Nov 3, 2017 at 9:30 PM, Martin Koller  wrote:
> 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: 
> 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

Re: liquidshell in kdereview

[Martin Koller]

On Sonntag, 5. November 2017 23:01:52 CET Alexander Neundorf wrote:
> On 2017 M11 5, Sun 19:27:27 CET Martin Koller wrote:
> > On Samstag, 4. November 2017 20:58:49 CET Alexander Neundorf wrote:
> > > On 2017 M11 3, Fri 21:30:19 CET Martin Koller wrote:
> > > > Hi all,
> > > 
> > > ...
> > > 
> > > > - Just one bottom DesktopPanel, containing:
> > > 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

Re: liquidshell in kdereview

[Martin Koller]

On Montag, 6. November 2017 01:57:32 CET Aleix Pol wrote:
> On Fri, Nov 3, 2017 at 9:30 PM, Martin Koller  wrote:
> > 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

Re: liquidshell in kdereview

[Tomaz Canabrava]

On Mon, Nov 6, 2017 at 8:31 AM, Martin Koller  wrote:

> On Montag, 6. November 2017 01:57:32 CET Aleix Pol wrote:
> > On Fri, Nov 3, 2017 at 9:30 PM, Martin Koller  wrote:
> > > 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 ?
>

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?


> --
> 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
>
>
>

Re: liquidshell in kdereview

[Kevin Funk]

On Monday, 6 November 2017 10:03:05 CET Tomaz Canabrava wrote:
> On Mon, Nov 6, 2017 at 8:31 AM, Martin Koller  wrote:
> > On Montag, 6. November 2017 01:57:32 CET Aleix Pol wrote:
> > > On Fri, Nov 3, 2017 at 9:30 PM, Martin Koller  wrote:
> > > > 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 ?
> 
> 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

> > 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 | kf...@kde.org | http://kfunk.org

signature.asc
Description: This is a digitally signed message part.

Re: liquidshell in kdereview

[Alexander Potashev]

2017-11-06 14:16 GMT+03:00 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

Re: liquidshell in kdereview

[Tomaz Canabrava]

On Mon, Nov 6, 2017 at 1:30 PM, Alexander Potashev 
wrote:

> 2017-11-06 14:16 GMT+03:00 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,
>

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
>

Re: liquidshell in kdereview

[Friedrich W. H. Kossebau]

Hi Martin,

Am Freitag, 3. November 2017, 21:30:19 CET schrieb 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

Re: liquidshell in kdereview

[Friedrich W. H. Kossebau]

Some more branding oriented nitpicks:

Am Freitag, 3. November 2017, 21:30:19 CET schrieb 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.

> 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

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

Re: liquidshell in kdereview

[Martin Koller]

On Montag, 6. November 2017 10:03:05 CET Tomaz Canabrava wrote:
> On Mon, Nov 6, 2017 at 8:31 AM, Martin Koller  wrote:
> 
> > On Montag, 6. November 2017 01:57:32 CET Aleix Pol wrote:
> > > On Fri, Nov 3, 2017 at 9:30 PM, Martin Koller  wrote:
> > > > 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 ?
> >
> 
> 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

Re: liquidshell in kdereview

[Martin Koller]

On Montag, 6. November 2017 17:37:15 CET Friedrich W. H. Kossebau wrote:
> Some more branding oriented nitpicks:
> 
> Am Freitag, 3. November 2017, 21:30:19 CET schrieb 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
 
> > 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
> 
> 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

Re: liquidshell in kdereview

[Martin Koller]

On Montag, 6. November 2017 17:12:31 CET Friedrich W. H. Kossebau wrote:
> Hi Martin,
> 
> Am Freitag, 3. November 2017, 21:30:19 CET schrieb 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.

thanks for the appreciation
 
> 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

Re: liquidshell in kdereview

[Alexander Neundorf]

On 2017 M11 6, Mon 19:13:36 CET Martin Koller wrote:
> On Montag, 6. November 2017 10:03:05 CET Tomaz Canabrava wrote:
> > On Mon, Nov 6, 2017 at 8:31 AM, Martin Koller  wrote:
> > > On Montag, 6. November 2017 01:57:32 CET Aleix Pol wrote:
> > > > On Fri, Nov 3, 2017 at 9:30 PM, Martin Koller  wrote:
> > > > > 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 ?
> > 
> > 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

Re: liquidshell in kdereview

[Alexander Neundorf]

On 2017 M11 6, Mon 10:03:05 CET Tomaz Canabrava wrote:
> On Mon, Nov 6, 2017 at 8:31 AM, Martin Koller  wrote:
...
> > 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

Re: liquidshell in kdereview

[Albert Astals Cid]

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

En lunes, 6 de noviembre de 2017 15:31:34 CET, Tomaz Canabrava 
 escribió: 

On Mon, Nov 6, 2017 at 1:30 PM, Alexander Potashev  wrote:
> 2017-11-06 14:16 GMT+03:00 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,

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

Re: liquidshell in kdereview

[Albert Astals Cid]

+1000 to what Friedrich said :)

Cheers,
   Albert

En lunes, 6 de noviembre de 2017 17:13:04 CET, Friedrich W. H. Kossebau 
 escribió: 

Hi Martin,

Am Freitag, 3. November 2017, 21:30:19 CET schrieb 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

Re: liquidshell in kdereview

[Friedrich W. H. Kossebau]

Am Montag, 6. November 2017, 19:24:51 CET schrieb Martin Koller:
> On Montag, 6. November 2017 17:37:15 CET Friedrich W. H. Kossebau wrote:
> > > 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
> > 
> > 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.

> 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

Re: liquidshell in kdereview

[Martin Flöser]

Am 2017-11-03 21:30, schrieb 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]


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

Re: liquidshell in kdereview

[Martin Koller]

On Dienstag, 7. November 2017 15:32:23 CET Friedrich W. H. Kossebau wrote:
> Am Montag, 6. November 2017, 19:24:51 CET schrieb Martin Koller:
> > On Montag, 6. November 2017 17:37:15 CET Friedrich W. H. Kossebau wrote:
> > > > 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
> > > 
> > > 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

> 
> > 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.

> 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

Re: liquidshell in kdereview

[Martin Koller]

On Dienstag, 7. November 2017 16:42:40 CET Martin Flöser wrote:
> Am 2017-11-03 21:30, schrieb 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]
> 
> > 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.

> If I understand correctly this is supposed to be a replacement for 
> plasmashell in Plasma, which would mean that you use KWin.

yes
 
> 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).

> Isn't that also a memory and resource hog?

not here. It's not in the top 10 processes of CPU or memory usage

> Shouldn't you come up with a replacement for KWin as well?

no (as long as it works good enough for me)
 
> 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.

> 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 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.

> 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 ?

> 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

> 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

> 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 

Re: liquidshell in kdereview

[Martin Flöser]

Am 2017-11-07 20:08, schrieb Martin Koller:

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

Re: liquidshell in kdereview

[Jaime]

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.

2017-11-07 20:55 GMT+01:00 Martin Flöser :

> Am 2017-11-07 20:08, schrieb Martin Koller:
>
>> 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
>

Re: liquidshell in kdereview

[Friedrich W. H. Kossebau]

Am Dienstag, 7. November 2017, 19:27:31 CET schrieb Martin Koller:
> On Dienstag, 7. November 2017 15:32:23 CET Friedrich W. H. Kossebau wrote:
> > 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

Re: liquidshell in kdereview

[Friedrich W. H. Kossebau]

Am Dienstag, 7. November 2017, 20:08:59 CET schrieb Martin Koller:
> On Dienstag, 7. November 2017 16:42:40 CET Martin Flöser wrote:
> > Am 2017-11-03 21:30, schrieb Martin Koller:
> > I don't mind what you develop in your spare time. Not at all. What I
> > mind is if a product is added to KDE as a competitor/replacement to a
> > product I work on because of misunderstood things. What I see here is
> > that you completely misunderstood what hardware acceleration means and
> > gives to the system.
> 
> See above. I did not start liquidshell because I was bored. Believe me, I
> have other hobbies. I started it just because I got fed up with the
> problems I had with plasmashell and I need to use some DE for my daily
> work. Restarting plasmashell multiple times a day is just not funny.

I think what Martin F. is also asking here, and what surely one expects as 
standard in KDE, is that the description of the liquidshell product/project is 
not making false or unresearched claims or speaking badly about alternative 
solutions, especially from the same community. In short: being respectful :)

So e.g. if this was about some new liquidhexeditor, I as author of Okteta 
would be not happy about phrases like:

* "liquidhexeditor is a replacement for okteta"
"replacement" (to me) comes with meaning of successor, being better. Which is 
attributing things.
The more neutral word "alternative" might be better here.

* "It does not use QtQuick but instead relies on QtWidgets."
"not use X but relies on Y" also tells me that "X" sucks and better is 
avoided.
Where one could rather say "Uses X for everything because property 1, property 
2 and property 3", without losing a word about "Y".  Just listing the factors 
one made their choice on for using "X" leaves everyone with their idea about 
the qualities of "Y".
E.g. it could be said that QWidgets are a stable mature UI technology and 
(like already is sayed) provide a consistent UI across shell and apps (at 
least the QWidget-based apps).
No need to speak here about alternatives like QQ, Gtk, or EFL, there are 
people for any who think that to be a better base to build a UI on.

So Martik K., IMHO the current README carries still some of the frustration 
you had experienced with the Plasma shell. While this has been part of your 
motivation for your work on a new solution, it could be now time to step back 
and to turn completely into positive thinking like most of the README already 
is, for a peaceful, cooperative co-existence :) 

I propose to start the README with the product requirements you had in mind 
when working on liquidshell, perhaps by listing the features already 
implemented (and then listing some which you still consider to add).
With those, potential users might be able to see whether the requirements 
match those they are looking for themselves, and developers might be able to 
follow your decisions on why creating a separate project and on the 
technologies used for the implementation.

BTW, you are surely aware that other UI components of the Plasma workspace, 
like the System Settings, are ported to QtQuick currently. So given your 
implementation choices, do you plan to create a liquidsystemsettings variant 
as well?

Cheers
Friedrich

Re: liquidshell in kdereview

[Martin Koller]

On Donnerstag, 9. November 2017 15:32:46 CET Friedrich W. H. Kossebau wrote:
> Am Dienstag, 7. November 2017, 20:08:59 CET schrieb Martin Koller:
> > On Dienstag, 7. November 2017 16:42:40 CET Martin Flöser wrote:
> > > Am 2017-11-03 21:30, schrieb Martin Koller:
> > > I don't mind what you develop in your spare time. Not at all. What I
> > > mind is if a product is added to KDE as a competitor/replacement to a
> > > product I work on because of misunderstood things. What I see here is
> > > that you completely misunderstood what hardware acceleration means and
> > > gives to the system.
> > 
> > See above. I did not start liquidshell because I was bored. Believe me, I
> > have other hobbies. I started it just because I got fed up with the
> > problems I had with plasmashell and I need to use some DE for my daily
> > work. Restarting plasmashell multiple times a day is just not funny.
> 
> I think what Martin F. is also asking here, and what surely one expects as 
> standard in KDE, is that the description of the liquidshell product/project 
> is 
> not making false or unresearched claims

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.

> 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.

will change

> * "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
 


> 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

Re: liquidshell in kdereview

[Ingo Klöcker]

On Dienstag, 7. November 2017 20:55:57 CET Martin Flöser wrote:
> Am 2017-11-07 20:08, schrieb Martin Koller:
> >> 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


signature.asc
Description: This is a digitally signed message part.

Re: liquidshell in kdereview

[Martin Koller]

On Freitag, 3. November 2017 21:30:19 CET Martin Koller wrote:
> Hi all,
> 
> I'd like to announce an application I've implemented over the last few weeks 
> - liquidshell

since more than 3 weeks have passed, I hopefully have addressed all issues and 
I got no further comments,
are there any blocking points you see or can I proceed requesting the move to 
extragear ?

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

Re: liquidshell in kdereview

[Sebastian Kügler]

On woensdag 29 november 2017 21:23:15 CET Martin Koller wrote:
> On Freitag, 3. November 2017 21:30:19 CET Martin Koller wrote:
> 
> 
> > Hi all,
> > 
> > I'd like to announce an application I've implemented over the last few
> > weeks - liquidshell
> since more than 3 weeks have passed, I hopefully have addressed all issues
> and I got no further comments, are there any blocking points you see or can
> I proceed requesting the move to extragear ?
> 
> 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?
-- 
sebas

http://www.kde.org | http://vizZzion.org

Re: liquidshell in kdereview

[Martin Koller]

On Donnerstag, 30. November 2017 10:04:51 CET Sebastian Kügler wrote:
> On woensdag 29 november 2017 21:23:15 CET Martin Koller wrote:
> > On Freitag, 3. November 2017 21:30:19 CET Martin Koller wrote:
> > 
> > 
> > > Hi all,
> > > 
> > > I'd like to announce an application I've implemented over the last few
> > > weeks - liquidshell
> > since more than 3 weeks have passed, I hopefully have addressed all issues
> > and I got no further comments, are there any blocking points you see or can
> > I proceed requesting the move to extragear ?
> > 
> > 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 breeze/oxygen-icons 
maintainer
"kainz.a" 

-- 
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

Re: liquidshell in kdereview

[Martin Flöser]

Am 2017-11-29 21:23, schrieb Martin Koller:

On Freitag, 3. November 2017 21:30:19 CET Martin Koller wrote:

Hi all,

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


since more than 3 weeks have passed, I hopefully have addressed all
issues and I got no further comments,
are there any blocking points you see or can I proceed requesting the
move to extragear ?

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.


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

Re: liquidshell in kdereview

[Martin Flöser]

Am 2017-11-29 21:23, schrieb Martin Koller:

On Freitag, 3. November 2017 21:30:19 CET Martin Koller wrote:

Hi all,

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


since more than 3 weeks have passed, I hopefully have addressed all
issues and I got no further comments,
are there any blocking points you see or can I proceed requesting the
move to extragear ?


Yes I still see several blocking items. E.g.
"liquidshell is an alternative to plasmashell"

I think that should be removed. I do not want any competing or 
alternative to plasmashell provided by KDE. This would be very bad for 
our community. Please formulate the readme without mentioning Plasma. 
I'm sure you are able to find unique selling points without going into 
any part of competition with Plasma or in any part which could be 
misunderstood.


What I do not want is Phoronix: "KDE starts new desktop shell because 
Plasma sucks". Please formulate everything so that it cannot be 
misunderstood.


Also remove all the parts about the main motivation without "hog cpu or 
ram". We already discussed that this was a problem with your local and 
personal setup. Don't piss on Plasma because your setup has problems. 
You have all the rights to scratch your own itch, but don't piss on us.


Personally I'm against liquidshell getting added to extragear. I think 
this would be harming the KDE community to have a shared desktop shell. 
We have already too much fragmentation on the desktop area and I don't 
think KDE should support this by creating yet another desktop shell. We 
should think here in the big picture.


Cheers
Martin

Re: liquidshell in kdereview

[Sebastian Kügler]

On Thu, 30 Nov 2017 18:41:28 +0100
Martin Koller  wrote:

> On Donnerstag, 30. November 2017 10:04:51 CET Sebastian Kügler wrote:
> > On woensdag 29 november 2017 21:23:15 CET Martin Koller wrote:  
> > > On Freitag, 3. November 2017 21:30:19 CET Martin Koller wrote:
> > > 
> > >   
> > > > Hi all,
> > > > 
> > > > I'd like to announce an application I've implemented over the
> > > > last few weeks - liquidshell  
> > > since more than 3 weeks have passed, I hopefully have addressed
> > > all issues and I got no further comments, are there any blocking
> > > points you see or can I proceed requesting the move to extragear ?
> > > 
> > > 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
> breeze/oxygen-icons maintainer "kainz.a" 

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

Re: liquidshell in kdereview

[Albert Astals Cid]

El dijous, 30 de novembre de 2017, a les 19:57:45 CET, Martin Flöser va 
escriure:
> Am 2017-11-29 21:23, schrieb Martin Koller:
> > On Freitag, 3. November 2017 21:30:19 CET Martin Koller wrote:
> >> Hi all,
> >> 
> >> I'd like to announce an application I've implemented over the last few
> >> weeks - liquidshell
> > 
> > since more than 3 weeks have passed, I hopefully have addressed all
> > issues and I got no further comments,
> > are there any blocking points you see or can I proceed requesting the
> > move to extragear ?
> 
> Yes I still see several blocking items. E.g.
> "liquidshell is an alternative to plasmashell"
> 
> I think that should be removed. I do not want any competing or
> alternative to plasmashell provided by KDE. This would be very bad for
> our community. Please formulate the readme without mentioning Plasma.
> I'm sure you are able to find unique selling points without going into
> any part of competition with Plasma or in any part which could be
> misunderstood.
> 
> What I do not want is Phoronix: "KDE starts new desktop shell because
> Plasma sucks". Please formulate everything so that it cannot be
> misunderstood.
> 
> Also remove all the parts about the main motivation without "hog cpu or
> ram". We already discussed that this was a problem with your local and
> personal setup. Don't piss on Plasma because your setup has problems.
> You have all the rights to scratch your own itch, but don't piss on us.
> 
> Personally I'm against liquidshell getting added to extragear. I think
> this would be harming the KDE community to have a shared desktop shell.
> We have already too much fragmentation on the desktop area and I don't
> think KDE should support this by creating yet another desktop shell. We
> should think here in the big picture.

So you'd rather prefer he did this in github?

I 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

> 
> Cheers
> Martin

Re: liquidshell in kdereview

[Albert Astals Cid]

El divendres, 1 de desembre de 2017, a les 14:05:19 CET, Sebastian Kügler va 
escriure:
> On Thu, 30 Nov 2017 18:41:28 +0100
> 
> Martin Koller  wrote:
> > On Donnerstag, 30. November 2017 10:04:51 CET Sebastian Kügler wrote:
> > > On woensdag 29 november 2017 21:23:15 CET Martin Koller wrote:
> > > > On Freitag, 3. November 2017 21:30:19 CET Martin Koller wrote:
> > > > > Hi all,
> > > > > 
> > > > > I'd like to announce an application I've implemented over the
> > > > > last few weeks - liquidshell
> > > > 
> > > > since more than 3 weeks have passed, I hopefully have addressed
> > > > all issues and I got no further comments, are there any blocking
> > > > points you see or can I proceed requesting the move to extragear ?
> > > > 
> > > > 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
> > breeze/oxygen-icons maintainer "kainz.a" 
> 
> 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.

> 
> 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



> 
> Cheers,
> 
> -- sebas

Re: liquidshell in kdereview

[Sebastian Kügler]

On Sat, 02 Dec 2017 10:27:16 +0100
Albert Astals Cid  wrote:

> El divendres, 1 de desembre de 2017, a les 14:05:19 CET, Sebastian
> Kügler va escriure:
> > On Thu, 30 Nov 2017 18:41:28 +0100
> > 
> > Martin Koller  wrote:
> > > On Donnerstag, 30. November 2017 10:04:51 CET Sebastian Kügler
> > > wrote:
> > > > On woensdag 29 november 2017 21:23:15 CET Martin Koller wrote:
> > > > > On Freitag, 3. November 2017 21:30:19 CET Martin Koller wrote:
> > > > > > Hi all,
> > > > > > 
> > > > > > I'd like to announce an application I've implemented over
> > > > > > the last few weeks - liquidshell
> > > > > 
> > > > > since more than 3 weeks have passed, I hopefully have
> > > > > addressed all issues and I got no further comments, are there
> > > > > any blocking points you see or can I proceed requesting the
> > > > > move to extragear ?
> > > > > 
> > > > > 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
> > > breeze/oxygen-icons maintainer "kainz.a" 
> > 
> > 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.
> 
> > 
> > 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.

> 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.

> 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

Re: liquidshell in kdereview

[Albert Astals Cid]

El dissabte, 2 de desembre de 2017, a les 11:52:53 CET, Sebastian Kügler va 
escriure:
> On Sat, 02 Dec 2017 10:27:16 +0100
> 
> Albert Astals Cid  wrote:
> > El divendres, 1 de desembre de 2017, a les 14:05:19 CET, Sebastian
> > 
> > Kügler va escriure:
> > > On Thu, 30 Nov 2017 18:41:28 +0100
> > > 
> > > Martin Koller  wrote:
> > > > On Donnerstag, 30. November 2017 10:04:51 CET Sebastian Kügler
> > > > 
> > > > wrote:
> > > > > On woensdag 29 november 2017 21:23:15 CET Martin Koller wrote:
> > > > > > On Freitag, 3. November 2017 21:30:19 CET Martin Koller wrote:
> > > > > > > Hi all,
> > > > > > > 
> > > > > > > I'd like to announce an application I've implemented over
> > > > > > > the last few weeks - liquidshell
> > > > > > 
> > > > > > since more than 3 weeks have passed, I hopefully have
> > > > > > addressed all issues and I got no further comments, are there
> > > > > > any blocking points you see or can I proceed requesting the
> > > > > > move to extragear ?
> > > > > > 
> > > > > > 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
> > > > breeze/oxygen-icons maintainer "kainz.a" 
> > > 
> > > 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.
> > 
> > > 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.
> 
> > 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

Re: liquidshell in kdereview

[Martin Flöser]

Am 2017-12-02 10:17, schrieb Albert Astals Cid:

El dijous, 30 de novembre de 2017, a les 19:57:45 CET, Martin Flöser va
escriure:

Am 2017-11-29 21:23, schrieb Martin Koller:
> On Freitag, 3. November 2017 21:30:19 CET Martin Koller wrote:
>> Hi all,
>>
>> I'd like to announce an application I've implemented over the last few
>> weeks - liquidshell
>
> since more than 3 weeks have passed, I hopefully have addressed all
> issues and I got no further comments,
> are there any blocking points you see or can I proceed requesting the
> move to extragear ?

Yes I still see several blocking items. E.g.
"liquidshell is an alternative to plasmashell"

I think that should be removed. I do not want any competing or
alternative to plasmashell provided by KDE. This would be very bad for
our community. Please formulate the readme without mentioning Plasma.
I'm sure you are able to find unique selling points without going into
any part of competition with Plasma or in any part which could be
misunderstood.

What I do not want is Phoronix: "KDE starts new desktop shell because
Plasma sucks". Please formulate everything so that it cannot be
misunderstood.

Also remove all the parts about the main motivation without "hog cpu 
or

ram". We already discussed that this was a problem with your local and
personal setup. Don't piss on Plasma because your setup has problems.
You have all the rights to scratch your own itch, but don't piss on 
us.


Personally I'm against liquidshell getting added to extragear. I think
this would be harming the KDE community to have a shared desktop 
shell.

We have already too much fragmentation on the desktop area and I don't
think KDE should support this by creating yet another desktop shell. 
We

should think here in the big picture.


So you'd rather prefer he did this in github?


I did't write that and I'm surprised you come to that conclusion.



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

Re: liquidshell in kdereview

[Albert Astals Cid]

El dissabte, 2 de desembre de 2017, a les 13:26:18 CET, Martin Flöser va 
escriure:
> Am 2017-12-02 10:17, schrieb Albert Astals Cid:
> > El dijous, 30 de novembre de 2017, a les 19:57:45 CET, Martin Flöser va
> > 
> > escriure:
> >> Am 2017-11-29 21:23, schrieb Martin Koller:
> >> > On Freitag, 3. November 2017 21:30:19 CET Martin Koller wrote:
> >> >> Hi all,
> >> >> 
> >> >> I'd like to announce an application I've implemented over the last few
> >> >> weeks - liquidshell
> >> > 
> >> > since more than 3 weeks have passed, I hopefully have addressed all
> >> > issues and I got no further comments,
> >> > are there any blocking points you see or can I proceed requesting the
> >> > move to extragear ?
> >> 
> >> Yes I still see several blocking items. E.g.
> >> "liquidshell is an alternative to plasmashell"
> >> 
> >> I think that should be removed. I do not want any competing or
> >> alternative to plasmashell provided by KDE. This would be very bad for
> >> our community. Please formulate the readme without mentioning Plasma.
> >> I'm sure you are able to find unique selling points without going into
> >> any part of competition with Plasma or in any part which could be
> >> misunderstood.
> >> 
> >> What I do not want is Phoronix: "KDE starts new desktop shell because
> >> Plasma sucks". Please formulate everything so that it cannot be
> >> misunderstood.
> >> 
> >> Also remove all the parts about the main motivation without "hog cpu
> >> or
> >> ram". We already discussed that this was a problem with your local and
> >> personal setup. Don't piss on Plasma because your setup has problems.
> >> You have all the rights to scratch your own itch, but don't piss on
> >> us.
> >> 
> >> Personally I'm against liquidshell getting added to extragear. I think
> >> this would be harming the KDE community to have a shared desktop
> >> shell.
> >> We have already too much fragmentation on the desktop area and I don't
> >> think KDE should support this by creating yet another desktop shell.
> >> We
> >> should think here in the big picture.
> > 
> > So you'd rather prefer he did this in github?
> 
> I did't write that and I'm surprised you come to that conclusion.

You said we should not take this in. Martin wants this to be published it 
somehwere, so it has to end up somewhere in github or similar. That was my 
conclusion, i really don't see how is it surprising?

> 
> > I mean yes, ideally everyone would work on whathever i want them to
> > work on,
> > but since this won't happen, can we try to make KDE a nice and
> > welcoming place
> > to challenge eachother ideas and implementations?
> > 
> > I'm sure a little friendly (and yes this goes both ways in the
> > meanthing that
> > liquidshell should not piss on plasmashell) competition never hurt
> > anyone :)
> 
> Such competition exists - especially on the desktop shell area,
> especially on the QtQuick vs. QtWidgets area.
> 
> There currently are the following Qt based desktop shells:
>   * Plasma (QtQuick)
>   * LxQt (QtWidgets)
>   * Lumina (QtWidgets)
>   * Hawaii (QtQuick AFAIK)
> 
> In addition there is competition in the GTK world:
>   * GNOME Shell
>   * Pantheon
>   * Xfce
>   * Budgie
>   * Cinnamon
> 
> And there are even further desktop environments on even other toolkits
> such as E.
> 
> If there are things we need, it's yet another desktop environment. There
> is already sufficient external competition, so that we don't need
> internal competition.
> 
> As I already said: Martin is free to do in his spare time whatever he
> wants. If he thinks we need another desktop shell, fine. He can do so.
> Whether we as KDE should endorse and support this is another question.
> 
> I think for the overall Linux world yet another desktop shell is
> harming. You can have another opinion and that and that's also fine. I
> only shared my opinion stating that I consider this as harming and that
> we as KDE should IMHO not support this.
> 
> Btw. I would see this completely different if for example LxQt would
> approach KDE and ask for joining. I would support this and would be
> happy to see them becoming a part of KDE.
> 
> Also I think the project should not be added as the whole thing is
> hypocrite. According to the readme Martin has a problem with QtQuick.
> Fair enough, but why is he fine with the following areas being in
> QtQuick:
>   * KWin (e.g. Alt+Tab)
>   * Lockscreen
>   * logout screen
>   * Systemsettings
>   * many more components
> 
> If QtQuick would be a problem, Martin would have to replace everything
> and not just Plasmashell. 

*If* (big if) QtQuick had performance problems I would understand using 
QtQuick in the alt+tab/lockscreen/etc to be less problematic since i'm not 
using them all the time compared to Plasma itself.

> 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 

Re: liquidshell in kdereview

[Martin Flöser]

Am 2017-12-03 12:28, schrieb Albert Astals Cid:
El dissabte, 2 de desembre de 2017, a les 13:26:18 CET, Martin Flöser 
va

escriure:

Am 2017-12-02 10:17, schrieb Albert Astals Cid:
> El dijous, 30 de novembre de 2017, a les 19:57:45 CET, Martin Flöser va
>
> escriure:
>> Am 2017-11-29 21:23, schrieb Martin Koller:
>> > On Freitag, 3. November 2017 21:30:19 CET Martin Koller wrote:
>> >> Hi all,
>> >>
>> >> I'd like to announce an application I've implemented over the last few
>> >> weeks - liquidshell
>> >
>> > since more than 3 weeks have passed, I hopefully have addressed all
>> > issues and I got no further comments,
>> > are there any blocking points you see or can I proceed requesting the
>> > move to extragear ?
>>
>> Yes I still see several blocking items. E.g.
>> "liquidshell is an alternative to plasmashell"
>>
>> I think that should be removed. I do not want any competing or
>> alternative to plasmashell provided by KDE. This would be very bad for
>> our community. Please formulate the readme without mentioning Plasma.
>> I'm sure you are able to find unique selling points without going into
>> any part of competition with Plasma or in any part which could be
>> misunderstood.
>>
>> What I do not want is Phoronix: "KDE starts new desktop shell because
>> Plasma sucks". Please formulate everything so that it cannot be
>> misunderstood.
>>
>> Also remove all the parts about the main motivation without "hog cpu
>> or
>> ram". We already discussed that this was a problem with your local and
>> personal setup. Don't piss on Plasma because your setup has problems.
>> You have all the rights to scratch your own itch, but don't piss on
>> us.
>>
>> Personally I'm against liquidshell getting added to extragear. I think
>> this would be harming the KDE community to have a shared desktop
>> shell.
>> We have already too much fragmentation on the desktop area and I don't
>> think KDE should support this by creating yet another desktop shell.
>> We
>> should think here in the big picture.
>
> So you'd rather prefer he did this in github?

I did't write that and I'm surprised you come to that conclusion.


You said we should not take this in. Martin wants this to be published 
it
somehwere, so it has to end up somewhere in github or similar. That was 
my

conclusion, i really don't see how is it surprising?


Yes, I think we should not take it into extra-gear. That does not mean 
that I have anything against it being hosted on KDE's git 
infrastructure. Whether it gets released and promoted by the KDE 
community is rather orthogonal to where it is hosted.


So I don't understand your reasoning.





> I mean yes, ideally everyone would work on whathever i want them to
> work on,
> but since this won't happen, can we try to make KDE a nice and
> welcoming place
> to challenge eachother ideas and implementations?
>
> I'm sure a little friendly (and yes this goes both ways in the
> meanthing that
> liquidshell should not piss on plasmashell) competition never hurt
> anyone :)

Such competition exists - especially on the desktop shell area,
especially on the QtQuick vs. QtWidgets area.

There currently are the following Qt based desktop shells:
  * Plasma (QtQuick)
  * LxQt (QtWidgets)
  * Lumina (QtWidgets)
  * Hawaii (QtQuick AFAIK)

In addition there is competition in the GTK world:
  * GNOME Shell
  * Pantheon
  * Xfce
  * Budgie
  * Cinnamon

And there are even further desktop environments on even other toolkits
such as E.

If there are things we need, it's yet another desktop environment. 
There

is already sufficient external competition, so that we don't need
internal competition.

As I already said: Martin is free to do in his spare time whatever he
wants. If he thinks we need another desktop shell, fine. He can do so.
Whether we as KDE should endorse and support this is another question.

I think for the overall Linux world yet another desktop shell is
harming. You can have another opinion and that and that's also fine. I
only shared my opinion stating that I consider this as harming and 
that

we as KDE should IMHO not support this.

Btw. I would see this completely different if for example LxQt would
approach KDE and ask for joining. I would support this and would be
happy to see them becoming a part of KDE.

Also I think the project should not be added as the whole thing is
hypocrite. According to the readme Martin has a problem with QtQuick.
Fair enough, but why is he fine with the following areas being in
QtQuick:
  * KWin (e.g. Alt+Tab)
  * Lockscreen
  * logout screen
  * Systemsettings
  * many more components

If QtQuick would be a problem, Martin would have to replace everything
and not just Plasmashell.


*If* (big if) QtQuick had performance problems I would understand using
QtQuick in the alt+tab/lockscreen/etc to be less problematic since i'm 
not

using them all the time compared to Plasma itself.


If QtQuick is a problem and causes high CPU usage that would especially 
be a problem whe

Re: liquidshell in kdereview

[Albert Astals Cid]

El diumenge, 3 de desembre de 2017, a les 13:51:49 CET, Martin Flöser va 
escriure:
> Am 2017-12-03 12:28, schrieb Albert Astals Cid:
> > El dissabte, 2 de desembre de 2017, a les 13:26:18 CET, Martin Flöser
> > va
> > 
> > escriure:
> >> Am 2017-12-02 10:17, schrieb Albert Astals Cid:
> >> > El dijous, 30 de novembre de 2017, a les 19:57:45 CET, Martin Flöser va
> >> > 
> >> > escriure:
> >> >> Am 2017-11-29 21:23, schrieb Martin Koller:
> >> >> > On Freitag, 3. November 2017 21:30:19 CET Martin Koller wrote:
> >> >> >> Hi all,
> >> >> >> 
> >> >> >> I'd like to announce an application I've implemented over the last
> >> >> >> few
> >> >> >> weeks - liquidshell
> >> >> > 
> >> >> > since more than 3 weeks have passed, I hopefully have addressed all
> >> >> > issues and I got no further comments,
> >> >> > are there any blocking points you see or can I proceed requesting
> >> >> > the
> >> >> > move to extragear ?
> >> >> 
> >> >> Yes I still see several blocking items. E.g.
> >> >> "liquidshell is an alternative to plasmashell"
> >> >> 
> >> >> I think that should be removed. I do not want any competing or
> >> >> alternative to plasmashell provided by KDE. This would be very bad for
> >> >> our community. Please formulate the readme without mentioning Plasma.
> >> >> I'm sure you are able to find unique selling points without going into
> >> >> any part of competition with Plasma or in any part which could be
> >> >> misunderstood.
> >> >> 
> >> >> What I do not want is Phoronix: "KDE starts new desktop shell because
> >> >> Plasma sucks". Please formulate everything so that it cannot be
> >> >> misunderstood.
> >> >> 
> >> >> Also remove all the parts about the main motivation without "hog cpu
> >> >> or
> >> >> ram". We already discussed that this was a problem with your local and
> >> >> personal setup. Don't piss on Plasma because your setup has problems.
> >> >> You have all the rights to scratch your own itch, but don't piss on
> >> >> us.
> >> >> 
> >> >> Personally I'm against liquidshell getting added to extragear. I think
> >> >> this would be harming the KDE community to have a shared desktop
> >> >> shell.
> >> >> We have already too much fragmentation on the desktop area and I don't
> >> >> think KDE should support this by creating yet another desktop shell.
> >> >> We
> >> >> should think here in the big picture.
> >> > 
> >> > So you'd rather prefer he did this in github?
> >> 
> >> I did't write that and I'm surprised you come to that conclusion.
> > 
> > You said we should not take this in. Martin wants this to be published
> > it
> > somehwere, so it has to end up somewhere in github or similar. That was
> > my
> > conclusion, i really don't see how is it surprising?
> 
> Yes, I think we should not take it into extra-gear. That does not mean
> that I have anything against it being hosted on KDE's git
> infrastructure. Whether it gets released and promoted by the KDE
> community is rather orthogonal to where it is hosted.
> 
> So I don't understand your reasoning.

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

Re: liquidshell in kdereview

[Tomaz Canabrava]

On Sun, Mar 10, 2019 at 1:25 PM Martin Koller  wrote:
>
> Hi,
>
> since some time has already passed and there was no conclusion, I'll try once 
> again
> to announce liquidshell.
>
> I have made adjustments to the README which now says:
>
> liquidshell is a basic Desktop Shell implemented using QtWidgets.
>
> Main Features:
> - Wallpaper per virtual desktop
> - No animations, low memory and CPU footprint
> - Instant startup
> - No use of activities

How apps that deal with activities will work on? they will just
silently ignore activities?

> - 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 Frameworks 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.
>   It also features PackageKit software updates integration.
>   The DeviceList also shows devices connected and paired with KDEConnect.
>   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)
>
> I think the final place should be extragear.
>
> openSuse's OBS has already packages for some distributions
>
> Screenshots:
> http://members.aon.at/m.koller/liquidshell_20190310_light.png
> http://members.aon.at/m.koller/liquidshell_20190310_dark.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
>
>

Re: liquidshell in kdereview

[Albert Astals Cid]

El diumenge, 10 de març de 2019, a les 13:25:14 CET, Martin Koller va escriure:
> Hi,
> 
> since some time has already passed and there was no conclusion, I'll try once 
> again
> to announce liquidshell.
> 
> I have made adjustments to the README which now says:
> 
> liquidshell is a basic Desktop Shell implemented using QtWidgets.
> 
> Main Features:
> - Wallpaper per virtual desktop
> - No animations, low memory and CPU footprint
> - Instant startup
> - No use of activities

I feel like this is still Plasma feature bad mouthing. To you it is somehow a 
feature because you think activities are bad, so that's why you list it as a 
feature, but honestly it is also a feature of GNOME Shell and almost every 
other single desktop environment out there, and they don't announce it, why 
should you?

Cheers,
  Albert

Re: liquidshell in kdereview

[Martin Koller]

On Montag, 11. März 2019 10:34:35 CET Tomaz Canabrava wrote:
> On Sun, Mar 10, 2019 at 1:25 PM Martin Koller  wrote:
> >
> > Hi,
> >
> > since some time has already passed and there was no conclusion, I'll try 
> > once again
> > to announce liquidshell.
> >
> > I have made adjustments to the README which now says:
> >
> > liquidshell is a basic Desktop Shell implemented using QtWidgets.
> >
> > Main Features:
> > - Wallpaper per virtual desktop
> > - No animations, low memory and CPU footprint
> > - Instant startup
> > - No use of activities
> 
> How apps that deal with activities will work on? they will just
> silently ignore activities?

Since I do not use activities, I have no idea.
But since liquidshell does not even offer anything related to activities,
why would an application face an issue with that in the first place ?

-- 
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

Re: liquidshell in kdereview

[Tomaz Canabrava]

On Tue, Mar 12, 2019 at 9:34 AM Martin Koller  wrote:
>
> On Montag, 11. März 2019 10:34:35 CET Tomaz Canabrava wrote:
> > On Sun, Mar 10, 2019 at 1:25 PM Martin Koller  wrote:
> > >
> > > Hi,
> > >
> > > since some time has already passed and there was no conclusion, I'll try 
> > > once again
> > > to announce liquidshell.
> > >
> > > I have made adjustments to the README which now says:
> > >
> > > liquidshell is a basic Desktop Shell implemented using QtWidgets.
> > >
> > > Main Features:
> > > - Wallpaper per virtual desktop
> > > - No animations, low memory and CPU footprint
> > > - Instant startup
> > > - No use of activities
> >
> > How apps that deal with activities will work on? they will just
> > silently ignore activities?
>
> Since I do not use activities, I have no idea.
> But since liquidshell does not even offer anything related to activities,
> why would an application face an issue with that in the first place ?

Because I could use plasma and activities and then install liquidshell
to test, to discover that I'm unable to launch the application in the
state that I left.
I, as user, being unable to reach an already configured application
state, would consider that Liquidshell has a bug related to the
loading of applications.

> --
> 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
>
>

Re: liquidshell in kdereview

[Albert Astals Cid]

El dimarts, 12 de març de 2019, a les 9:46:19 CET, Tomaz Canabrava va escriure:
> On Tue, Mar 12, 2019 at 9:34 AM Martin Koller  wrote:
> >
> > On Montag, 11. März 2019 10:34:35 CET Tomaz Canabrava wrote:
> > > On Sun, Mar 10, 2019 at 1:25 PM Martin Koller  wrote:
> > > >
> > > > Hi,
> > > >
> > > > since some time has already passed and there was no conclusion, I'll 
> > > > try once again
> > > > to announce liquidshell.
> > > >
> > > > I have made adjustments to the README which now says:
> > > >
> > > > liquidshell is a basic Desktop Shell implemented using QtWidgets.
> > > >
> > > > Main Features:
> > > > - Wallpaper per virtual desktop
> > > > - No animations, low memory and CPU footprint
> > > > - Instant startup
> > > > - No use of activities
> > >
> > > How apps that deal with activities will work on? they will just
> > > silently ignore activities?
> >
> > Since I do not use activities, I have no idea.
> > But since liquidshell does not even offer anything related to activities,
> > why would an application face an issue with that in the first place ?
> 
> Because I could use plasma and activities and then install liquidshell
> to test, to discover that I'm unable to launch the application in the
> state that I left.
> I, as user, being unable to reach an already configured application
> state, would consider that Liquidshell has a bug related to the
> loading of applications.

Same as if you use Gnome Shell instead of liquidshell, no? 

If the application locks itself in a bad state depending the Desktop in use, 
that's a bug of the application not of the desktop.

Cheers,
  Albert

> 
> > --
> > 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
> >
> >
> 

Re: liquidshell in kdereview

[Ivan Čukić]

> Same as if you use Gnome Shell instead of liquidshell, no?
> 
> If the application locks itself in a bad state depending the Desktop in use,
> that's a bug of the application not of the desktop.

Yes and no. KWin can force applications to be on specific activities.

The fact that liquidshell makes no use of activities does not mean that 
activities are disabled. Namely, KWin uses activities, KWin will start the 
activity manager daemon and KWin will handle windows as it does on Plasma.

Dolphin, Gwenview, etc. will still use activities as they do now. Nothing will 
change in that regard.

So, liquidshell doesn't use activities means:
- it does not react to activity changes
- it does not offer a way to switch activities, even if they still exist

Anyhow, while I do find it strange to market a non-feature in the features 
list, I don't have anything against it. If people want to use liquidshell 
instead of plasma or lxqt, why would we stop them?

I don't think we've had 'political' discussions in the review phase before, 
and I don't think we should now.


Cheers,
Ivan


-- 
dr Ivan Čukić
KDE, ivan.cu...@kde.org, https://cukic.co/
gpg key fingerprint: 8FE4 D32F 7061 EA9C 8232  07AE 01C6 CE2B FF04 1C12

Re: liquidshell in kdereview

[Adriaan de Groot]

On Sunday, March 10, 2019 1:25:14 PM CEST Martin Koller wrote:
> since some time has already passed and there was no conclusion, I'll try
> once again to announce liquidshell.

# Documentation issues

The features list, both in German and English, lists a bunch of features that 
distinguish it from, say, twm, not from Plasma.

The feature list in English doesn't match the one in German. The English one 
includes dubious claims such as "instant startup" and "low memory footprint", 
which I'd still want to see measured and/or demonstrated.

Typo's in (English) README.

# License issues

None, actually. Well done. Consistent use of GPLv3+ everywhere. You might want 
to add SPDX identifiers, but that would be the icing on the cake.

# Source issues

Doesn't report nicely at end of CMake (use FeatureSummary).

Ancient CMake and Qt versions listed as "minimum" (that's ok, I guess).

Unusual source layout and file suffixes (again, I guess it's ok, just weird 
and being difficult).

Poor C++11 hygiene (include guards, conversions, nullptr).

# Compatibility issues

Fails to document that NetworkManager and BlueZ are required. 

Uses bash for things that are POSIX shell scripts.

Those (two items) above are symptoms of "liquidshell is a shell for Martin 
Koller and people with exactly his computer setup and workflow". Since the KDE 
community has traditionally produced general, flexible software, it's weird to 
have a restricted, limited, non-flexible product as well.

[ade]


signature.asc
Description: This is a digitally signed message part.

Re: liquidshell in kdereview

[Marco Martin]

On Fri, Mar 15, 2019 at 7:59 AM Ivan Čukić  wrote:
> Anyhow, while I do find it strange to market a non-feature in the features
> list, I don't have anything against it.

I have a bit of a problem about putting doesn't use activities as a
feature, because it's a bit confrontational towards other KDE products
(and as you point out, often not 100% true as kactivitymanagerd will
be very probably started anyways)
That said, i don't have problems of having a competing shell as a KDE
project, choice is usually good.

Marco Martin

Re: liquidshell in kdereview

[Martin Koller]

On Freitag, 12. April 2019 12:48:17 CEST Adriaan de Groot wrote:
> On Sunday, March 10, 2019 1:25:14 PM CEST Martin Koller wrote:
> > since some time has already passed and there was no conclusion, I'll try
> > once again to announce liquidshell.
> 
> # Documentation issues
> 
> The features list, both in German and English, lists a bunch of features that 
> distinguish it from, say, twm, not from Plasma.

I don't understand your point.
What do you want me to change?

> The feature list in English doesn't match the one in German. The English one 
> includes dubious claims such as "instant startup" and "low memory footprint", 
> which I'd still want to see measured and/or demonstrated.

you can see them when you start liquidshell.
What do you want me to change ?

> Typo's in (English) README.
> 
> # License issues
> 
> None, actually. Well done. Consistent use of GPLv3+ everywhere. You might 
> want 
> to add SPDX identifiers, but that would be the icing on the cake.

Where, which and how would I need to add SPDX identifiers ?
Where is this documented in KDE guidelines ?
Here
https://community.kde.org/Policies/Licensing_Policy
I don't find anything.

> # Source issues
> 
> Doesn't report nicely at end of CMake (use FeatureSummary).

included now
 
> # Compatibility issues
> 
> Fails to document that NetworkManager and BlueZ are required. 

Not sure I understand.
The cmake file includes
find_package(KF5 REQUIRED COMPONENTS 
for NetworkManagerQt and BluezQt

> Uses bash for things that are POSIX shell scripts.

What do you mean ?
There is exactly one shellscript which is not build related:
start_liquidshell
it contains #!/bin/bash
if you're referring to this.
I did this since I remember having read that /bin/sh is not the correct way.

> Those (two items) above are symptoms of "liquidshell is a shell for Martin 
> Koller and people with exactly his computer setup and workflow".

"my workflow" - of course.
"exactly his computer" - not so.
E.g. it seems Arch Linux provides liquidshell: 
https://aur.archlinux.org/packages/liquidshell-git/
Also KaOS have included liquidshell 
https://linuxscoop.com/video/whats-new-kaos-2018-01

I'm using openSuse.

> Since the KDE community has traditionally produced general, flexible 
> software, it's weird to 
> have a restricted, limited, non-flexible product as well.

If you find liquidshell too limited and unflexible for you, don't use it.
liquidshell's intent is exactly being this: simple and not over complex (aka 
general, flexible)

-- 
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

Re: liquidshell in kdereview

[Martin Koller]

On Freitag, 12. April 2019 13:07:41 CEST Marco Martin wrote:
> On Fri, Mar 15, 2019 at 7:59 AM Ivan Čukić  wrote:
> > Anyhow, while I do find it strange to market a non-feature in the features
> > list, I don't have anything against it.
> 
> I have a bit of a problem about putting doesn't use activities as a
> feature, because it's a bit confrontational towards other KDE products
> (and as you point out, often not 100% true as kactivitymanagerd will
> be very probably started anyways)

I have removed the mentioning of activities now

> That said, i don't have problems of having a competing shell as a KDE
> project, choice is usually good.

Thanks for your open mind!

-- 
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

Re: liquidshell in kdereview

[Adriaan de Groot]

On Saturday, 13 April 2019 14:08:18 CEST Martin Koller wrote:
> > # License issues
> > 
> > None, actually. Well done. Consistent use of GPLv3+ everywhere. You might
> > want to add SPDX identifiers, but that would be the icing on the cake.
> 
> Where, which and how would I need to add SPDX identifiers ?

You don't *need* to. Like I said, icing on the cake, which is like .. vanilla 
sauce on the apfelstruedel. Makes it complete and wonderful, but it's 
acceptable without it.

SPDX identifiers are machine-readable, standardised, tags in source files that 
help tooling that works with licensing (meta) data. See spdx.org; something 
like (off the top of my head, not necessarily the right identifier or format, 
etc.)

// SPDX-Identifier: GPLv2+

at the top of C++ source files does the trick.

> Where is this documented in KDE guidelines ?
> Here
> https://community.kde.org/Policies/Licensing_Policy
> I don't find anything.

It's not.

> > # Source issues
> > 
> > Doesn't report nicely at end of CMake (use FeatureSummary).
> 
> included now

Thanks.

> > # Compatibility issues
> > 
> > Fails to document that NetworkManager and BlueZ are required.
> 
> Not sure I understand.

Would have been nice to have that in the README, is what I mean.

> > Uses bash for things that are POSIX shell scripts.
> 
> What do you mean ?

You have a shell script (start_liquidshell). It uses no bash features at all. 
A POSIX system (ok, liquidshell is for Linux only, so this can be argued) has 
a /bin/sh for shell scripts.

> I did this since I remember having read that /bin/sh is not the correct way.

Fine by me.

[ade]

signature.asc
Description: This is a digitally signed message part.

Re: liquidshell in kdereview

[Martin Koller]

On Sonntag, 14. April 2019 12:44:20 CEST Adriaan de Groot wrote:
> On Saturday, 13 April 2019 14:08:18 CEST Martin Koller wrote:
> > > # License issues
> > > 
> > > None, actually. Well done. Consistent use of GPLv3+ everywhere. You might
> > > want to add SPDX identifiers, but that would be the icing on the cake.
> > 
> > Where, which and how would I need to add SPDX identifiers ?
> 
> You don't *need* to. Like I said, icing on the cake, which is like .. vanilla 
> sauce on the apfelstruedel. Makes it complete and wonderful, but it's 
> acceptable without it.
> 
> SPDX identifiers are machine-readable, standardised, tags in source files 
> that 
> help tooling that works with licensing (meta) data. See spdx.org; something 
> like (off the top of my head, not necessarily the right identifier or format, 
> etc.)
> 
> // SPDX-Identifier: GPLv2+
> 
> at the top of C++ source files does the trick.

ok, done.
 
> > Where is this documented in KDE guidelines ?
> > Here
> > https://community.kde.org/Policies/Licensing_Policy
> > I don't find anything.
> 
> It's not.

should it ?

> > > # Compatibility issues
> > > 
> > > Fails to document that NetworkManager and BlueZ are required.
> > 
> > Not sure I understand.
> 
> Would have been nice to have that in the README, is what I mean.

I'm not a fan of doing duplicate things.
The cmake file is the ultimate source for specifying what the application
depends on. Adding this somewhere else will easily get out of sync.

-- 
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

Re: liquidshell in kdereview

[Luca Beltrame]

Il giorno Sun, 14 Apr 2019 16:43:54 +0200
Martin Koller  ha scritto:

> The cmake file is the ultimate source for specifying what the
> application depends on. Adding this somewhere else will easily get

READMEs can be useful for packagers instead of manually watching the
output of CMake or reading CMakelists.txt (fine for simpler projects,
but not for large ones).


-- 
Luca Beltrame
GPG key ID: A29D259B


pgpJP4dfjoxjC.pgp
Description: Firma digitale OpenPGP

Re: liquidshell in kdereview

[Martin Koller]

On Sonntag, 14. April 2019 23:34:43 CEST Luca Beltrame wrote:
> Il giorno Sun, 14 Apr 2019 16:43:54 +0200
> Martin Koller  ha scritto:
> 
> > The cmake file is the ultimate source for specifying what the
> > application depends on. Adding this somewhere else will easily get
> 
> READMEs can be useful for packagers instead of manually watching the
> output of CMake or reading CMakelists.txt (fine for simpler projects,
> but not for large ones).

since in this case we are talking about required software,
the packager will not get the app compiled.
I assume this will hit his attention.
I would understand that optional dependencies are different since the app
would build but not with all options.

-- 
Best regards/Schöne Grüße

Martin

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

Re: liquidshell in kdereview

[Jonathan Riddell]

I've now moved this to extragear/base as there did not seem to be any more
political complaints and technical ones seemed fairly fixable.

Jonathan


On Mon, 15 Apr 2019 at 10:16, Martin Koller  wrote:

> On Sonntag, 14. April 2019 23:34:43 CEST Luca Beltrame wrote:
> > Il giorno Sun, 14 Apr 2019 16:43:54 +0200
> > Martin Koller  ha scritto:
> >
> > > The cmake file is the ultimate source for specifying what the
> > > application depends on. Adding this somewhere else will easily get
> >
> > READMEs can be useful for packagers instead of manually watching the
> > output of CMake or reading CMakelists.txt (fine for simpler projects,
> > but not for large ones).
>
> since in this case we are talking about required software,
> the packager will not get the app compiled.
> I assume this will hit his attention.
> I would understand that optional dependencies are different since the app
> would build but not with all options.
>
> --
> Best regards/Schöne Grüße
>
> Martin
>
> ()  ascii ribbon campaign - against html e-mail
> /\- against proprietary attachments
>
>
>
>
>

Recommended modesetting driver for Intel graphic cards (was: Re: liquidshell in kdereview)

[Friedrich W. H. Kossebau]

Am Donnerstag, 16. November 2017, 23:24:52 CET schrieb Ingo Klöcker:
> On Dienstag, 7. November 2017 20:55:57 CET Martin Flöser wrote:
> > Am 2017-11-07 20:08, schrieb Martin Koller:
> > >> 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 :)

> 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

Re: Recommended modesetting driver for Intel graphic cards (was: Re: liquidshell in kdereview)

[Milian Wolff]

On Samstag, 18. November 2017 15:34:16 CET Friedrich W. H. Kossebau wrote:
> Am Donnerstag, 16. November 2017, 23:24:52 CET schrieb Ingo Klöcker:
> > On Dienstag, 7. November 2017 20:55:57 CET Martin Flöser wrote:
> > > Am 2017-11-07 20:08, schrieb Martin Koller:
> > > >> 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 :)
> > 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

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
m...@milianw.de
http://milianw.de

signature.asc
Description: This is a digitally signed message part.