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

[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

[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: Latte : make_unique for gcc <=4.8

[Luigi Toscano]

Michail Vourlakos ha scritto:
> 
> 
> BTW: for every e-mail I send I need moderator approval is that a standard
> procedure or I can register somewhere to avoid this?

kde-core-devel is moderated even for registered users, but usually after few
posts the moderators put people in the whitelist.

Ciao
-- 
Luigi

Re: Latte : make_unique for gcc <=4.8

[Adriaan de Groot]

On Thursday, 9 November 2017 09:58:26 CET Tomaz Canabrava wrote:
> On Sun, Nov 5, 2017 at 4:12 PM, Michail Vourlakos 
> 
> > during the review phase in Latte we removed the following code in case it
> > would conflict in some cases:
> > 
> > #if __GLIBCXX__ <= 20150623
> > namespace std {
> > template
> > unique_ptr make_unique(Args &&... args)
..
> > #endif
> > 
> > 
> > this was needed for gcc versions that even though they are C++14
> > compatible they dont offer make_unique function. By removing that code we
> > broke compatibility with openSUSE Leap that uses gcc 4.8.5 ... so in order
> > to build latte packages a made a patch to readd that code.

The problem was at least partly (IIRC) that the check doesn't detect Clang, 
and then defines a duplicate (language-lawyering says it's undefined behavior). 
The problem isn't so much with gcc itself, as with the C++ STL version it 
ships with.

I wanted to point you to https://cmake.org/cmake/help/v3.8/prop_gbl/
CMAKE_CXX_KNOWN_FEATURES.html , but has-make-unique is not one other features 
CMake knows about.

As Sven points out, using symbol_exists() might work, or easier might be a 
try_compile() which will definitely tell you if std::make_unique compiles on 
the local system.

[ade]

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

Re: Latte : make_unique for gcc <=4.8

[Sven Brauch]

On 05/11/17 16:12, Michail Vourlakos wrote:
> Do you know any better way to handle this?

You can let cmake do the check:

https://cmake.org/cmake/help/v3.0/module/CheckSymbolExists.html

Not sure if this is the best option, though.

Greetings,
Sven



signature.asc
Description: OpenPGP digital signature

Re: Latte : make_unique for gcc <=4.8

[Tomaz Canabrava]

On Sun, Nov 5, 2017 at 4:12 PM, Michail Vourlakos 
wrote:

> Hello everyone,
>
> during the review phase in Latte we removed the following code in case it
> would conflict in some cases:
>
> #if __GLIBCXX__ <= 20150623
> namespace std {
> template
> unique_ptr make_unique(Args &&... args)
> {
> return std::unique_ptr(new T(std::forward(args)...));
> }
> }
> #endif
>
>
> this was needed for gcc versions that even though they are C++14
> compatible they dont offer make_unique function. By removing that code we
> broke compatibility with openSUSE Leap that uses gcc 4.8.5 ... so in order
> to build latte packages a made a patch to readd that code.
>
> Do you know any better way to handle this?
>

I would say "just drop it altogether" because 4.8.5 is too old and broken
(it's a 2013 release, after all. four years have passed and for programming
this is an eternity) - require a newer compiler.


> regards,
> [michail]
>
>
> BTW: for every e-mail I send I need moderator approval is that a standard
> procedure or I can register somewhere to avoid this?
>

yes, you can: https://mail.kde.org/mailman/listinfo/kde-core-devel

Re: Latte Dock into extragear...

[Tomaz Canabrava]

Awesome,

On Thu, Nov 2, 2017 at 8:39 PM, Michail Vourlakos 
wrote:

> Just to update...
>
> Latte from now on can be found at extragear after succeeding at its review
> phase...
> as mentioned also at: https://phabricator.kde.org/T7115
>

Downloading and installing to test.
<3


> regards,
> [michail]
>

Latte : make_unique for gcc <=4.8

[Michail Vourlakos]

Hello everyone,

during the review phase in Latte we removed the following code in case it
would conflict in some cases:

#if __GLIBCXX__ <= 20150623
namespace std {
template
unique_ptr make_unique(Args &&... args)
{
return std::unique_ptr(new T(std::forward(args)...));
}
}
#endif


this was needed for gcc versions that even though they are C++14 compatible
they dont offer make_unique function. By removing that code we broke
compatibility with openSUSE Leap that uses gcc 4.8.5 ... so in order to
build latte packages a made a patch to readd that code.

Do you know any better way to handle this?

regards,
[michail]


BTW: for every e-mail I send I need moderator approval is that a standard
procedure or I can register somewhere to avoid this?

Re: Python bindings using cppyy (was: An update on Python bindings)

[Philipp A.]

Hi Shaheed, Chris,

Shaheed Haque  schrieb am Sa., 4. Nov. 2017 um
18:35 Uhr:

> FWIW, I already tried that (types.ModuleType is itself a perfectly
> subclassable class!) […]
>
> Now, none of that may be a limiting factor in the plan you seem to be
> discussing, but it was part of what made me think "here be dragons"...


For me that sounds like a perfectly acceptable clearly-defined instruction:

   - If you can, don’t use a __init__.py for namespace packages (because
   it’s simple).
   - If you need an __init__.py, only use one or use identical ones.

Reasons for needing a __init__.py include the need for toplevel
constants/classes/functions, or supporting Python 2. The docs also say that
you can mix __init__.py omission and (identical) __init__.pys.

I created an example here: https://github.com/flying-sheep/namespace-test

You can see that by using a __init__.py in exactly one of the merged
packages, you can define toplevel constants/classes/functions like BASE in
the example.

If we need, we can also define toplevel constants and so on in multiple
distributions, like this (this specific version requires all distributions
to know about all others, but that’s automatable):

*namespace-test-1/namespace_test/namespace_test_1_init.py*:
FOO = 1
*namespace-test-2/namespace_test/**namespace_test_2_init.py*:
BAR= 1
*namespace-test-{1,2}/namespace_test/**__init__.py*:
from pkgutil import extend_path
__path__ = extend_path(__path__, __name__)
try:
from .namespace_test_1_init import *
except ImportError:
pass
try:
from .namespace_test_2_init import *
except ImportError:
pass

Chris Burel  schrieb am So., 5. Nov. 2017 um
02:49 Uhr:

> I think this is a remarkably short sighted statement. It assumes that
> people that would use these bindings have no existing Python codebase at
> all, and can afford to start a brand new project. The reality is much
> different. […]


No, because you’re missing something here: There’s no KF5 bindings. So
every project that’ll use Shaheed’s new cool KF5 bindings will be a new
project.

Therefore the only thing Python 2 KF5 bindings would accomplish is to make
people think that starting a *new* Python 2 project in 2018 was still a
good idea. Which it isn’t.

Re: Python bindings using cppyy (was: An update on Python bindings)

[wlavrijsen]

Hi,

On Friday 2017-11-03 12:52, Philipp A. wrote:

Am I missing something? Namespaces should be Python modules, not classes.
If we can do represent them this way, the problem is solveable:
https://packaging.python.org/guides/packaging-namespace-packages/


there are two different things that should not be mixed up together as I
believe they are in this discussion: what cppyy does for purely internal
reasons, and how some package that uses it does its organization. In fact,
the idea of cppyy has always been to provide very "C++-like" python, and
then fix that up in Python to be more pythonistic (as opposed to fixing it
up in C++ or any 3rd language).

To be concrete, in cppyy, I can (and want to be able to) do this:

  >>> import cppyy
  >>> cppyy.cppdef("namespace A { int i = 42; }")
  >>> cppyy.gbl.A.i
  42
  >>> cppyy.gbl.A.i = 17
  >>> cppyy.cppdef("void print_i() { std::cout << A::i << std::endl; }")
  >>> cppyy.gbl.print_i()
  17
  >>>

So now I have a (C++) namespace 'A' that bears no relationship to anything
to do with the file system or any type of Python packaging: it exists only
in memory for the duration of the python session.

For the above to work, I needed to make certain design decisions and the
conclusion was to make 'A' an instance of a subclass of type type, which,
yes, means that it is a class-like type.

None of this, however, should limit the choices of a pythonization layer
on top of cppyy. Yes, there is the risk of "leakage" and some of that may
be inevitable (think e.g. automatically generated __doc__ strings), but by
and large, it should be contained. There should be no clashes, however, as
the C++ namespaces are installed in sys.modules with the 'cppyy.gbl'
prefix, so a Python module called 'A' can live right next to it.

Also, the reason that I'm confident it can be done, is because it has been
done:

  http://www.rootpy.org/

albeit that the structure there is simpler than in this discussion. OTOH,
rootpy goes way farther in renaming things.

On Friday 2017-11-03 13:15, Shaheed Haque wrote:

That's likey to be a bad idea because of the potential impact on
arbitrary round trips between C++ and Python (remember that everything
is based on named-based lookups).


The renaming does not actually scare me that much from a performance point
of view: already, C++ has typedefs for classes and aliases for namespaces.
There is always the problem of "leakage" as mentioned above, where the
end-user sees both at some point, but internally, aliasing will work fine:
it's just another reference to the same object.

On Friday 2017-11-03 14:09, Philipp A. wrote:

I'd be interested in why. Usually using classes as namespaces is only done
for reasons of cuteness (callable namespaces, namespaces usable as context
managers, ...) or so.


It is to attach a meta class for a __getattr__, the use of properties, and
to allow pickling. The module type does not support meta classes.

On Friday 2017-11-03 14:09, Philipp A. wrote:

Even in this case, it's possible to replace the module's class with a
module subclass that has the necessary capabilities (modules are objects
that have a class, too)


Certainly. A module is functionally a subset of a class, so duck typing
ensures that a class can be placed anywhere a module can, so it's either
enhance module or restrict class. However, the use of a meta class is so
much easier to just reuse from type type as opposed to reinventing that
wholesale for module type.

Just to put a historic note here: Python has a lot of "meta" features to
make anything behave like anything else. Using them, however, has two
distinct disadvantages. 1) A lot of tooling relies on very specific
behavior and goes belly-up if anything is slightly different (I'm looking
at you, inspect!) 2) Way too many packages use these features and they never
work well together. (I'm looking at you, ipython!)

Thus, although in the past I've made bountiful use of all the dunderscore
features that Python offers, I've learned my lesson the hard way and these
days I much rather avoid them and use the "builtin" behavior if at all
feasible.

The meta class is one of them: although reworking its behavior is not hard,
but making sure it works _exactly_ as the builtin version across all python
versions and implementations, _is_ hard. (Same goes for reworking the use
of properties, etc.)

That doesn't mean I'm totally innocent here: I'm going through quite some
steps to satisfy inspect, including the on-the-fly generation of code
objects (p2 only for now), to make help() do things like this:

 |  SavePrimitive(self, basic_ostream& out, const 
char* option='')
 |  void TObject::SavePrimitive(basic_ostream& out, const 
char* option = "")

Note above the type info in the python (!) representation of that method
(the second line is just the doc string of course, but the first one is
build up by fooling inspect). Yes, that's clearly just "cuteness". OTOH,
this plays nicely 

Re: Python bindings using cppyy (was: An update on Python bindings)

[Philipp A.]

Hi Shaheed,

Thank you so much for all your work!

a framework-by-framework integration of the binding generation logic (as
> previously pioneered by Steve) probably cannot work in general because
> there are cases where multiple frameworks contribute to to the same C++
> namespace […]
>
> The problem is that the Python implementation of these namespaces is a
> class, and so treating these frameworks […] as separate would result in
> multiple colliding Python class definitions.


Am I missing something? Namespaces should be Python modules, not classes.
If we can do represent them this way, the problem is solveable:
https://packaging.python.org/guides/packaging-namespace-packages/

The original TODOs and bugs have been resolved, and there is the beginnings
> of support for packaging frameworks under a Python namespace as in
> "KF5.KDCRAW".


Once they’re modules, we should probably respect that Python modules are by
convention lowercase. It would be best if we named them kf5.kdcraw and so
on.

Thank you again,
Best, Philipp

Re: Python bindings using cppyy (was: An update on Python bindings)

[Philipp A.]

Hi Shaheed,

Shaheed Haque  schrieb am Fr., 3. Nov. 2017 um
14:16 Uhr:

> Philipp,
>
> - my overall understanding of this technique is that it may end up
> being fragile, especially given the difference between P2 and P3.
>

Python 2? I’m sure we shouldn’t include into our decision making an
obsolete language that has a final (yes, really this time!) expiration date
2 years in the future. 2020 is the end of the line, I certainly don’t
bother anymore to write a single line accomodating to it, and would suggest
you do the same for a new project.

- using it further down might not work as expected especially if there
> are "accidental" collisions in the directory/namespace names.
> - it is also not clear if the technique can be used multiple times.
>

We should check if this is the case. Who’s a Python guru who knows the ins
and outs of the module system?

- cppyy gives us classes. (Actually, in conversation with Wim, CC'd
> here, it turns out that the choice of using classes is not arbitrary,
> but we were pondering simple modules at that point, for other
> reasons).
>

I’d be interested in why. Usually using classes as namespaces is only done
for reasons of cuteness (callable namespaces, namespaces usable as context
managers, …) or so.

Even in this case, it’s possible to replace the module’s class with a
module subclass that has the necessary capabilities (modules are objects
that have a class, too)


> Bottom line: I'm not keen on using Python namespace modules here for
> the reasons listed.
>

I’m not entirely convinced. We should only do a final decision once we know
if either your suspicions of multiple levels not working turn out to be
true, or the reason for using classes is important.


> That's likey to be a bad idea because of the potential impact on arbitrary
> round trips between C++ and Python (remember that everything is based on
> named-based lookups). In addition, we already have problems like "gpgme++",
> and the use of capitalisation to separate legacy and forwarding headers in
> KDE: further case-based confusion is the last thing that is needed!
>

I see, makes sense. I guess the allcaps example here is not very common
anyway, and most namespaces will be UpperCamelCase like Qt’s, right?

Thanks for the review/remarks, Shaheed
>

NP!
Best, Philipp

Re: Python bindings using cppyy (was: An update on Python bindings)

[Chris Burel]

> On Nov 4, 2017, at 4:46 AM, Philipp A.  wrote:
> 
> Entirely new bindings lead to new applications being written using those 
> bindings. Writing applications in Python 2 is an immediate maintenance burden 
> and people only do it because of stubborn ideology or a complete lack of 
> awareness that Python 2 is being killed off for good.
I think this is a remarkably short sighted statement. It assumes that people 
that would use these bindings have no existing Python codebase at all, and can 
afford to start a brand new project. The reality is much different.

Let's take a specific example. I have 6 years experience writing Python for the 
visual effects industry. We have a 10 year old Python 2 codebase. We also use 
an application from Autodesk called Maya. It has been a Qt 4 application with 
Python 2 embedded since 2012. In 2016 they jumped to qt 5 and pyside2. Now 
Autodesk knows that companies have built large codebase around their product 
that requires Python 2. What would've happened if pyside2 did not support 
Python 2.7? They'd be stuck either forcing all their customers to move to 
Python 3 and risk people not wanting the new version of the software, or they'd 
be prevented from moving to Qt 5.

So no, Python 2 is not dead. Not by a long shot.

-Chris

Re: Python bindings using cppyy (was: An update on Python bindings)

[Philipp A.]

Hi Shaheed,

Thank you for the clarifications!

My observation is that *nobody* is likely to help with that problem: the
> framework owners did
> nothing obvious to either keep PyKDE4 going (out of tree) or to help
> Steve with my earlier SIP based efforts (in tree).
>

It's a bit sad, but not too surprising that the framework maintainers
didn't help. I assume it's a matter of priorities for them as well.

I do however prefer to maintain compatibility (to Python 2) until the
> burden of doing so presents an insurmountable issue.
>

At this point I'd say you do humanity a bigger favor if you ditch Python 2
even without maintenance burden.

Entirely new bindings lead to new applications being written using those
bindings. Writing applications in Python 2 is an immediate maintenance
burden and people only do it because of stubborn ideology or a complete
lack of awareness that Python 2 is being killed off for good.

There is no need for a "final decision" from me. I would suggest that
> the first question for anybody that cares is to assess the scope of
> the issue. Unfortunately, i have other more fundamental issues to fry.
>

OK, cool! So if this is possible and not over my head, I might be able to
try my hands at it.

Best regards, Shaheed
>

The same to you!

>

Re: Python bindings using cppyy (was: An update on Python bindings)

[Philipp A.]

Hi Wim!

So now I have a (C++) namespace 'A' that bears no relationship to anything
> to do with the file system or any type of Python packaging: it exists only
> in memory for the duration of the python session.
>

Yeah, cool, so we just use a path hook and are ready to go right?

https://www.python.org/dev/peps/pep-0302/#specification-part-2-registering-hooks

Every framework gets its own path hook that handles imports from that
framework.

Frameworks with shared namespaces will just handle their own specific
paths, right?

The renaming does not actually scare me that much from a performance point
> of view: already, C++ has typedefs for classes and aliases for namespaces.
> There is always the problem of "leakage" as mentioned above, where the
> end-user sees both at some point, but internally, aliasing will work fine:
> it's just another reference to the same object.
>

Cool, so this might be possible after all! Certainly not as a top priority
before getting things to work, but still!

It is to attach a meta class for a __getattr__, the use of properties, and
> to allow pickling. The module type does not support meta classes.
>

Can't we replace the framework modules’ type with a subclass of both
“module” and “type”?

Thank you for explaining,
Best regards, Philipp

Latte Dock into extragear...

[Michail Vourlakos]

Just to update...

Latte from now on can be found at extragear after succeeding at its review
phase...
as mentioned also at: https://phabricator.kde.org/T7115

regards,
[michail]

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
>