DevHeads.net

liquidshell in kdereview

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: <a href="http://members.aon.at/m.koller/liquidshell_20171103_174650.png" title="http://members.aon.at/m.koller/liquidshell_20171103_174650.png">http://members.aon.at/m.koller/liquidshell_20171103_174650.png</a>
dark color theme: <a href="http://members.aon.at/m.koller/liquidshell_20171103_174944.png" title="http://members.aon.at/m.koller/liquidshell_20171103_174944.png">http://members.aon.at/m.koller/liquidshell_20171103_174944.png</a>

Comments

Re: liquidshell in kdereview

By Martin Koller at 11/29/2017 - 16:23

On Freitag, 3. November 2017 21:30:19 CET Martin Koller wrote:
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.

Re: liquidshell in kdereview

By Martin =?ISO-88... at 11/30/2017 - 14:57

Am 2017-11-29 21:23, schrieb Martin Koller:
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

By Albert Astals Cid at 12/02/2017 - 05:17

El dijous, 30 de novembre de 2017, a les 19:57:45 CET, Martin Flöser va
escriure:
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

Re: liquidshell in kdereview

By Martin =?ISO-88... at 12/02/2017 - 08:26

Am 2017-12-02 10:17, schrieb Albert Astals Cid:
I did't write that and I'm surprised you come to that conclusion.

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

By Albert Astals Cid at 12/03/2017 - 07:28

El dissabte, 2 de desembre de 2017, a les 13:26:18 CET, Martin Flöser va
escriure:
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?

*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 half agree with you, we should participate in projects based on
misunderstandings, but once the misunderstanding has been cleared (i.e. the
readmes are cleared of "qtquick and plasma are bad" references) we end up with
a shell written in QWidgets, that it in itself has nothing to do with its
initial "political motivations", and if Martin is commited to develop it (now
that potentially his Plasma works better/he knows where the problems are) I
don't see why we should not take it in.

Cheers,
Albert

Re: liquidshell in kdereview

By Martin =?ISO-88... at 12/03/2017 - 08:51

Am 2017-12-03 12:28, schrieb Albert Astals Cid:
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.

If QtQuick is a problem and causes high CPU usage that would especially
be a problem when using the lock screen. Especially then you don't want
CPU time to be wasted.

Let's continue this discussion once the issues are fixed. I just looked
into cgit.kde.org and find:
* Description: "Alternative desktop replacement for Plasma, using
QtWidgets instead of QtQuick to ensure hardware acceleration is not
required "
* README: "liquidshell is an alternative to plasmashell"
* README: "It does not use QtQuick but instead uses QtWidgets."
* README: "No animations, no CPU hogging, low Memory footprint"
* README: "No use of activities (I never used nor needed them)"
* README: "The main motivation was to have a reliable desktop shell
which does not hog the CPU or RAM."
* many more...

This was all pointed out quite some time already. Not just by me, but
also from non-Plasma devs. Martin has not fixed this. In the current
state we don't need to discuss whether it gets accepted.

Once Martin fixed this we can think about the further steps. What I want
to see then is a KDE community wide discussion about whether it gets
added or not. Especially I want to see a discussion whether we want to
add a competing product to LxQt. If we assume Martin fixes the
description the product is no longer in competition with Plasma, but
then it gets in competition with LxQt. Do we want that? We praised them
for working against fragmentation with RazorQt. We supported their
efforts in using Frameworks. We have a good relationship based on the
fact that we don't compete. Do we want to risk that? That's an important
community wide question which cannot be solved in a technical review. If
we introduce another desktop shell we need to look at the big picture
and what it means for the Linux ecosystem. It's not a question just
about Plasma, it really is at global scale.

Cheers
Martin Flöser

Re: liquidshell in kdereview

By Albert Astals Cid at 12/03/2017 - 17:38

El diumenge, 3 de desembre de 2017, a les 13:51:49 CET, Martin Flöser va
escriure:
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

By Martin =?ISO-88... at 11/30/2017 - 14:50

Am 2017-11-29 21:23, schrieb Martin Koller:
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

By Sebastian =?utf... at 11/30/2017 - 05:04

On woensdag 29 november 2017 21:23:15 CET Martin Koller wrote:
I strongly disagree. Could you point me to the discussion?

Re: liquidshell in kdereview

By Martin Koller at 11/30/2017 - 13:41

On Donnerstag, 30. November 2017 10:04:51 CET Sebastian Kügler wrote:
it was mail exchange in private (german) mails with the breeze/oxygen-icons maintainer
"kainz.a" <kainz. ... at gmail dot com>

Re: liquidshell in kdereview

By Sebastian =?utf... at 12/01/2017 - 09:05

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

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

By Albert Astals Cid at 12/02/2017 - 05:27

El divendres, 1 de desembre de 2017, a les 14:05:19 CET, Sebastian Kügler va
escriure:
Yes, the logo has to be changed.

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

Re: liquidshell in kdereview

By Sebastian =?utf... at 12/02/2017 - 06:52

On Sat, 02 Dec 2017 10:27:16 +0100

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.

Absolutely, but it should also be advertised in a healthy way, and
liquidshell in its current form isn't.

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

By Albert Astals Cid at 12/02/2017 - 07:42

El dissabte, 2 de desembre de 2017, a les 11:52:53 CET, Sebastian Kügler va
escriure:
Ok, so we're on the same page :)

Cheers,
Albert

Re: liquidshell in kdereview

By Martin =?ISO-88... at 11/07/2017 - 11:42

Am 2017-11-03 21:30, schrieb Martin Koller:
[snip]

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

By Martin Koller at 11/07/2017 - 15:08

On Dienstag, 7. November 2017 16:42:40 CET Martin Flöser wrote:
personally I'm using kwin, since I only replaced plasmashell,
but I assume this is irrelevant to what "shell" one is using.

yes

I have deactivated the compositor since sadly it simply does not work
on my laptop (the intel graphics driver just freezes the whole machine).

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

no (as long as it works good enough for me)

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.

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.

For me it - sadly - got worse over time.

Did you read "lightweight" anywhere in my README ?

I did not know that I need permission from you for what motivates me

which it is for me, sorry

I removed now the "no hardware acceleration" sentence from my README, since I'm
obviously too dumb to know what I write, sorry.

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

Re: liquidshell in kdereview

By Friedrich W. H.... at 11/09/2017 - 10:32

Am Dienstag, 7. November 2017, 20:08:59 CET schrieb Martin Koller:
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

By Martin Koller at 11/09/2017 - 14:18

On Donnerstag, 9. November 2017 15:32:46 CET Friedrich W. H. Kossebau wrote:
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.

will change

the major difference between plasmashell and liquidshell IS the non-usage of QtQuick, therefore
it definitely needs to be mentioned.
That does not imply judgement. It's just an explanation of what technology
it uses and which it does not - given that these are the two major
possibilities from Qt.
I have adjusted the README

<snip>

not planned

Re: liquidshell in kdereview

By Martin =?ISO-88... at 11/07/2017 - 15:55

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

By Ingo =?iso-8859... at 11/16/2017 - 18:24

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

Recommended modesetting driver for Intel graphic cards (was: Re:

By Friedrich W. H.... at 11/18/2017 - 10:34

Am Donnerstag, 16. November 2017, 23:24:52 CET schrieb Ingo Klöcker:
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 :)

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:

By Milian Wolff at 11/20/2017 - 06:59

On Samstag, 18. November 2017 15:34:16 CET Friedrich W. H. Kossebau wrote:
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]: <a href="https://www.phoronix.com/scan.php?page=news_item&amp;px=Intel-DDX-May-Tests" title="https://www.phoronix.com/scan.php?page=news_item&amp;px=Intel-DDX-May-Tests">https://www.phoronix.com/scan.php?page=news_item&amp;px=Intel-DDX-May-Tests</a>

Thanks, I'll have to try this out

Re: Recommended modesetting driver for Intel graphic cards

By Martin =?ISO-88... at 11/20/2017 - 12:28

Am 2017-11-20 11:59, schrieb Milian Wolff:
You quoted Phoronix. I hope you don't expect Phoronix to be able to get
proper measurements. That's something Phoronix still hasn't succeeded
after all those years. Just for fun I clicked that link and the first
graph shows a benchmark showing a game one running at 22.15, the other
at 22.13 fps. This difference is kernel sneezing. So much to that. But
the real issue is that a game running at 22 fps is unplayable. It has
nothing to do in the benchmark, the setup is broken. This has been the
issue as long as I followed Phoronix benchmarking. From an academic
point of view - which you understand as much as I do - it's just all
extremely horrible.

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

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

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

Everything written there still fully applies to the benchmark in
question

Cheers
Martin

Re: Recommended modesetting driver for Intel graphic cards

By Milian Wolff at 11/20/2017 - 18:40

On Montag, 20. November 2017 17:28:06 CET Martin Flöser wrote:
Thanks for the rant :) I rarely look at graphic related Phoronix stuff since I
don't know the tools and what they measure. For some I/O and CPU stuff, the
tools are useful and thus the numbers reported are, too.

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

Thanks

Re: Recommended modesetting driver for Intel graphic cards

By Milian Wolff at 11/20/2017 - 19:27

On Montag, 20. November 2017 23:40:38 CET Milian Wolff wrote:
Well, I tried it out myself now that tosky said it works for him. Indeed, it
does for me too - and some glaring bugs are resolved on top! Most notably I'm
finally able to launch secondary X sessions, nice :)

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

Cheers

Re: Recommended modesetting driver for Intel graphic cards

By Boudhayan Gupta at 11/20/2017 - 20:50

I've been using the modesetting driver for over a year and a half now
- on Sandy Bridge, Ivy Bridge, Broadwell and now Kaby Lake hardware.
I've *never* come across a bug all this while (in fact, I was forced
to switch due to GPU lockups on Sandy Bridge with xf86-video-intel).

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

My 2c, experience on Arch Linux.
Thanks,
Boudhayan Gupta
KDE e.V. - Community Working Group
+49 151 71032970

On 21 November 2017 at 00:27, Milian Wolff < ... at milianw dot de> wrote:

Re: liquidshell in kdereview

By Jaime Torres Amate at 11/09/2017 - 04:04

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 < ... at kde dot org>:

Re: liquidshell in kdereview

By Friedrich W. H.... at 11/06/2017 - 12:37

Some more branding oriented nitpicks:

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

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

By Martin Koller at 11/06/2017 - 14:24

On Montag, 6. November 2017 17:37:15 CET Friedrich W. H. Kossebau wrote:
changed

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.

Re: liquidshell in kdereview

By Friedrich W. H.... at 11/07/2017 - 10:32

Am Montag, 6. November 2017, 19:24:51 CET schrieb Martin Koller:
I recommend to follow <a href="https://vdesign.kde.org/how.html" title="https://vdesign.kde.org/how.html">https://vdesign.kde.org/how.html</a> and poke the VDG people
directly with your requirement.

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

By Martin Koller at 11/07/2017 - 14:27

On Dienstag, 7. November 2017 15:32:23 CET Friedrich W. H. Kossebau wrote:
thanks, will do

ok, understand.

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.

Re: liquidshell in kdereview

By Friedrich W. H.... at 11/09/2017 - 10:27

Am Dienstag, 7. November 2017, 19:27:31 CET schrieb Martin Koller:
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

By Friedrich W. H.... at 11/06/2017 - 12:12

Hi Martin,

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

By Albert Astals Cid at 11/06/2017 - 17:00

+1000 to what Friedrich said :)

Cheers,
   Albert

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

Hi Martin,

Am Freitag, 3. November 2017, 21:30:19 CET schrieb Martin Koller:

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

By Martin Koller at 11/06/2017 - 14:30

On Montag, 6. November 2017 17:12:31 CET Friedrich W. H. Kossebau wrote:
thanks for the appreciation

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.

Re: liquidshell in kdereview

By Aleix Pol at 11/05/2017 - 20:57

On Fri, Nov 3, 2017 at 9:30 PM, Martin Koller < ... at aon dot at> wrote:
Hi Martin,
I'm a bit confused, who is liquidshell for?

Aleix

Re: liquidshell in kdereview

By Martin Koller at 11/06/2017 - 03:31

On Montag, 6. November 2017 01:57:32 CET Aleix Pol 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 ?

Re: liquidshell in kdereview

By Tomaz Canabrava at 11/06/2017 - 05:03

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?

Re: liquidshell in kdereview

By Alexander Neundorf at 11/06/2017 - 16:59

On 2017 M11 6, Mon 10:03:05 CET Tomaz Canabrava wrote:
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

By Martin Koller at 11/06/2017 - 14:13

On Montag, 6. November 2017 10:03:05 CET Tomaz Canabrava wrote:
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

Re: liquidshell in kdereview

By Alexander Neundorf at 11/06/2017 - 16:57

On 2017 M11 6, Mon 19:13:36 CET Martin Koller wrote:
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

By Kevin Funk at 11/06/2017 - 07:16

On Monday, 6 November 2017 10:03:05 CET Tomaz Canabrava wrote:
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

Re: liquidshell in kdereview

By Alexander Potashev at 11/06/2017 - 08:30

2017-11-06 14:16 GMT+03:00 Kevin Funk < ... at kde dot org>:
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.

Re: liquidshell in kdereview

By Tomaz Canabrava at 11/06/2017 - 10:31

On Mon, Nov 6, 2017 at 1:30 PM, Alexander Potashev < ... at gmail dot com>
wrote:

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
Also true for kde applications.

3. it has poor infrastructure compared to KDE, e.g. their i18n server
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.

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)

Re: liquidshell in kdereview

By Albert Astals Cid at 11/06/2017 - 16:59

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 < ... at kde dot org> escribió:

On Mon, Nov 6, 2017 at 1:30 PM, Alexander Potashev < ... at gmail dot com> wrote:
For many people kde applications don't work out of the box too.

Also true for kde applications.

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

 

Re: liquidshell in kdereview

By Alexander Neundorf at 11/04/2017 - 15:58

On 2017 M11 3, Fri 21:30:19 CET Martin Koller wrote:
I always put my panel to the right or left edge (intead at the bottom)...

...
Not sure whether "liquid" is a good choice then, I don't really associate
"solid" with it ;-)

Alex

Re: liquidshell in kdereview

By Martin Koller at 11/05/2017 - 14:27

On Samstag, 4. November 2017 20:58:49 CET Alexander Neundorf wrote:
Then I fear liquidshell is simply not for you.

I was thinking about "solidshell" but "Solid" has already a different meaning inside KDE ...

Re: liquidshell in kdereview

By Alexander Neundorf at 11/05/2017 - 18:01

On 2017 M11 5, Sun 19:27:27 CET Martin Koller wrote:
... I guess in doubt you wouldn't mind some patches ?

Alex

Re: liquidshell in kdereview

By Martin Koller at 11/06/2017 - 03:27

On Sonntag, 5. November 2017 23:01:52 CET Alexander Neundorf wrote:
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 ;-)

Re: liquidshell in kdereview

By Kai Uwe Broulik at 11/04/2017 - 14:41

Hi,

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

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

CMakeLists.txt:
* No project name set

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

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

desktop.cxx:
* Missing AA_UseHighDpiPixmaps attribute

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

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

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

StartMenu.cxx:
* Similar issues as LockLogout.cxx

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

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

Cheers
Kai Uwe