Re: KIdleTime : to poll not or provide a settable resolution for the polling backends?

[René J . V . Bertin]

René J. V. Bertin wrote:

> As to MacPoller: I'll see whether I subclass WidgetBasedPoller or whether it's
> just as efficient to copy/paste the relevant code (if I'd be overriding too
> many methods, which might be the case here).

Seems I'll be doing copy/paste, because when I subclass following the example 
from the xscreensaver plugin


class MacPoller: public WidgetBasedPoller
{
Q_OBJECT
Q_PLUGIN_METADATA(IID "org.kde.kidletime.AbstractSystemPoller" FILE 
"osx.json")
Q_INTERFACES(AbstractSystemPoller)

I get an error:

kf5-kidletime/work/kidletime-5.16.0/src/plugins/osx/macpoller.cpp:34:7: error: 
type 'AbstractSystemPoller' is not a direct or virtual base of 'MacPoller'
: AbstractSystemPoller(parent)
  ^~~~


___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126087: Move the i18n context from KDeclarative

[Aleix Pol Gonzalez]

> On Nov. 17, 2015, 10:58 a.m., Marco Martin wrote:
> > Here's the reason I don't like it:
> > In origin KDeclarative was intended to be a library that only depended from 
> > Qt stuff, to be at most tier 2 (and imports there were supposed to be 
> > qt-only as well) and frameworks applications using QML were supposed to do 
> > it trough KDeclarative..
> > This just highlights a problem happened afterwards, when no frameworks 
> > maintainer wanted any qml binding it the framework's repository, the 
> > kdeclarative repo ended up being pretty much a dumpster where all the 
> > binding of all the frameworks went, making it depend from pretty much 
> > everything.
> > This also means that whoever will need the binding of $framework, it will 
> > probably rather rewrite them, since using kdeclarative means pretty much 
> > depending from all of them.
> > So, fine for making the i18n context independent, but iff the whole 
> > situation gets resolved and each single import that depends from more than 
> > Qt stuff goes either in its framework repository or gets its own.
> 
> Martin Gräßlin wrote:
> I agree with Marco: we should try to split this up again. Somehow the 
> framework starts to remind me of kdelibs4 and in applications I maintain it 
> takes a lot of strength to buy into using it. (Why would I want KIO in KWin?)
> 
> Aleix Pol Gonzalez wrote:
> Isn't it what this patch is about?
> 
> To me it's clear that KIconProvider could go to KIconThemes and 
> KIOAccessManagerFactory could go to KIO.
> 
> Marco Martin wrote:
> we could push that right at the start of the 5.18 cycle so that's done 
> well in advance
> 
> Marco Martin wrote:
> yes, and most of the linking luckily is private. the only thing that is 
> public and a bit out of tune unfortunately is configpropertymap
> 
> Marco Martin wrote:
> in general i'm in favor, i would like to try to make it an import instead 
> tough (the qobject inserted as context object if a custom one wasn't set 
> already and made a QML singleton as well, so that can get accessed by 
> KI18n.i18n("") and such).
> it should work if it can be injected somehow from KDeclarative c++

If we do it in a different way (e.g. a singleton), we'll have to get the code 
ported. That's not backwards-compatible.


- Aleix


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126087/#review88463
---


On Nov. 16, 2015, 3:55 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126087/
> ---
> 
> (Updated Nov. 16, 2015, 3:55 p.m.)
> 
> 
> Review request for KDE Frameworks, Chusslove Illich and Marco Martin.
> 
> 
> Repository: ki18n
> 
> 
> Description
> ---
> 
> The only way to use `i18n*()` so far in QML is by depending on all 
> KDeclarative. This patch moves the necessary bits there so it can be adopted 
> by an application or framework just by offering the needed bits within KI18n.
> This is done by offering an object with methods that map to the `i18n*()` C++ 
> counter-parts.
> 
> 
> Diffs
> -
> 
>   src/klocalizedcontext.cpp PRE-CREATION 
>   src/CMakeLists.txt 818595e 
>   src/klocalizedcontext.h PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/126087/diff/
> 
> 
> Testing
> ---
> 
> Ported KDeclarative, everything still seems to work.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126087: Move the i18n context from KDeclarative

[Aleix Pol Gonzalez]

> On Nov. 17, 2015, 10:58 a.m., Marco Martin wrote:
> > Here's the reason I don't like it:
> > In origin KDeclarative was intended to be a library that only depended from 
> > Qt stuff, to be at most tier 2 (and imports there were supposed to be 
> > qt-only as well) and frameworks applications using QML were supposed to do 
> > it trough KDeclarative..
> > This just highlights a problem happened afterwards, when no frameworks 
> > maintainer wanted any qml binding it the framework's repository, the 
> > kdeclarative repo ended up being pretty much a dumpster where all the 
> > binding of all the frameworks went, making it depend from pretty much 
> > everything.
> > This also means that whoever will need the binding of $framework, it will 
> > probably rather rewrite them, since using kdeclarative means pretty much 
> > depending from all of them.
> > So, fine for making the i18n context independent, but iff the whole 
> > situation gets resolved and each single import that depends from more than 
> > Qt stuff goes either in its framework repository or gets its own.
> 
> Martin Gräßlin wrote:
> I agree with Marco: we should try to split this up again. Somehow the 
> framework starts to remind me of kdelibs4 and in applications I maintain it 
> takes a lot of strength to buy into using it. (Why would I want KIO in KWin?)

Isn't it what this patch is about?

To me it's clear that KIconProvider could go to KIconThemes and 
KIOAccessManagerFactory could go to KIO.


- Aleix


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126087/#review88463
---


On Nov. 16, 2015, 3:55 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126087/
> ---
> 
> (Updated Nov. 16, 2015, 3:55 p.m.)
> 
> 
> Review request for KDE Frameworks, Chusslove Illich and Marco Martin.
> 
> 
> Repository: ki18n
> 
> 
> Description
> ---
> 
> The only way to use `i18n*()` so far in QML is by depending on all 
> KDeclarative. This patch moves the necessary bits there so it can be adopted 
> by an application or framework just by offering the needed bits within KI18n.
> This is done by offering an object with methods that map to the `i18n*()` C++ 
> counter-parts.
> 
> 
> Diffs
> -
> 
>   src/klocalizedcontext.cpp PRE-CREATION 
>   src/CMakeLists.txt 818595e 
>   src/klocalizedcontext.h PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/126087/diff/
> 
> 
> Testing
> ---
> 
> Ported KDeclarative, everything still seems to work.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126087: Move the i18n context from KDeclarative

[Marco Martin]

> On Nov. 17, 2015, 9:58 a.m., Marco Martin wrote:
> > Here's the reason I don't like it:
> > In origin KDeclarative was intended to be a library that only depended from 
> > Qt stuff, to be at most tier 2 (and imports there were supposed to be 
> > qt-only as well) and frameworks applications using QML were supposed to do 
> > it trough KDeclarative..
> > This just highlights a problem happened afterwards, when no frameworks 
> > maintainer wanted any qml binding it the framework's repository, the 
> > kdeclarative repo ended up being pretty much a dumpster where all the 
> > binding of all the frameworks went, making it depend from pretty much 
> > everything.
> > This also means that whoever will need the binding of $framework, it will 
> > probably rather rewrite them, since using kdeclarative means pretty much 
> > depending from all of them.
> > So, fine for making the i18n context independent, but iff the whole 
> > situation gets resolved and each single import that depends from more than 
> > Qt stuff goes either in its framework repository or gets its own.
> 
> Martin Gräßlin wrote:
> I agree with Marco: we should try to split this up again. Somehow the 
> framework starts to remind me of kdelibs4 and in applications I maintain it 
> takes a lot of strength to buy into using it. (Why would I want KIO in KWin?)
> 
> Aleix Pol Gonzalez wrote:
> Isn't it what this patch is about?
> 
> To me it's clear that KIconProvider could go to KIconThemes and 
> KIOAccessManagerFactory could go to KIO.

we could push that right at the start of the 5.18 cycle so that's done well in 
advance


- Marco


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126087/#review88463
---


On Nov. 16, 2015, 2:55 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126087/
> ---
> 
> (Updated Nov. 16, 2015, 2:55 p.m.)
> 
> 
> Review request for KDE Frameworks, Chusslove Illich and Marco Martin.
> 
> 
> Repository: ki18n
> 
> 
> Description
> ---
> 
> The only way to use `i18n*()` so far in QML is by depending on all 
> KDeclarative. This patch moves the necessary bits there so it can be adopted 
> by an application or framework just by offering the needed bits within KI18n.
> This is done by offering an object with methods that map to the `i18n*()` C++ 
> counter-parts.
> 
> 
> Diffs
> -
> 
>   src/klocalizedcontext.cpp PRE-CREATION 
>   src/CMakeLists.txt 818595e 
>   src/klocalizedcontext.h PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/126087/diff/
> 
> 
> Testing
> ---
> 
> Ported KDeclarative, everything still seems to work.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126087: Move the i18n context from KDeclarative

[Aleix Pol Gonzalez]

> On Nov. 16, 2015, 3:08 p.m., Milian Wolff wrote:
> > src/klocalizedcontext.cpp, line 53
> > 
> >
> > isNull or isEmpty? Don't we usually want to check against isEmpty and 
> > never against isNull? Isn't the latter even quasi-deprecated as it's 
> > internal state is somewhat undocumented and one must not depend on it? I 
> > think I remember something like that from the qt devel mailing list... 
> > Should ask Thiago again maybe?

QString::isNull is correct. Qml will give us a null string if the argument 
isn't there, AFAIK.


- Aleix


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126087/#review88431
---


On Nov. 16, 2015, 3:55 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126087/
> ---
> 
> (Updated Nov. 16, 2015, 3:55 p.m.)
> 
> 
> Review request for KDE Frameworks, Chusslove Illich and Marco Martin.
> 
> 
> Repository: ki18n
> 
> 
> Description
> ---
> 
> The only way to use `i18n*()` so far in QML is by depending on all 
> KDeclarative. This patch moves the necessary bits there so it can be adopted 
> by an application or framework just by offering the needed bits within KI18n.
> This is done by offering an object with methods that map to the `i18n*()` C++ 
> counter-parts.
> 
> 
> Diffs
> -
> 
>   src/klocalizedcontext.cpp PRE-CREATION 
>   src/CMakeLists.txt 818595e 
>   src/klocalizedcontext.h PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/126087/diff/
> 
> 
> Testing
> ---
> 
> Ported KDeclarative, everything still seems to work.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126087: Move the i18n context from KDeclarative

[Marco Martin]

> On Nov. 17, 2015, 9:58 a.m., Marco Martin wrote:
> > Here's the reason I don't like it:
> > In origin KDeclarative was intended to be a library that only depended from 
> > Qt stuff, to be at most tier 2 (and imports there were supposed to be 
> > qt-only as well) and frameworks applications using QML were supposed to do 
> > it trough KDeclarative..
> > This just highlights a problem happened afterwards, when no frameworks 
> > maintainer wanted any qml binding it the framework's repository, the 
> > kdeclarative repo ended up being pretty much a dumpster where all the 
> > binding of all the frameworks went, making it depend from pretty much 
> > everything.
> > This also means that whoever will need the binding of $framework, it will 
> > probably rather rewrite them, since using kdeclarative means pretty much 
> > depending from all of them.
> > So, fine for making the i18n context independent, but iff the whole 
> > situation gets resolved and each single import that depends from more than 
> > Qt stuff goes either in its framework repository or gets its own.
> 
> Martin Gräßlin wrote:
> I agree with Marco: we should try to split this up again. Somehow the 
> framework starts to remind me of kdelibs4 and in applications I maintain it 
> takes a lot of strength to buy into using it. (Why would I want KIO in KWin?)
> 
> Aleix Pol Gonzalez wrote:
> Isn't it what this patch is about?
> 
> To me it's clear that KIconProvider could go to KIconThemes and 
> KIOAccessManagerFactory could go to KIO.
> 
> Marco Martin wrote:
> we could push that right at the start of the 5.18 cycle so that's done 
> well in advance
> 
> Marco Martin wrote:
> yes, and most of the linking luckily is private. the only thing that is 
> public and a bit out of tune unfortunately is configpropertymap

in general i'm in favor, i would like to try to make it an import instead tough 
(the qobject inserted as context object if a custom one wasn't set already and 
made a QML singleton as well, so that can get accessed by KI18n.i18n("") and 
such).
it should work if it can be injected somehow from KDeclarative c++


- Marco


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126087/#review88463
---


On Nov. 16, 2015, 2:55 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126087/
> ---
> 
> (Updated Nov. 16, 2015, 2:55 p.m.)
> 
> 
> Review request for KDE Frameworks, Chusslove Illich and Marco Martin.
> 
> 
> Repository: ki18n
> 
> 
> Description
> ---
> 
> The only way to use `i18n*()` so far in QML is by depending on all 
> KDeclarative. This patch moves the necessary bits there so it can be adopted 
> by an application or framework just by offering the needed bits within KI18n.
> This is done by offering an object with methods that map to the `i18n*()` C++ 
> counter-parts.
> 
> 
> Diffs
> -
> 
>   src/klocalizedcontext.cpp PRE-CREATION 
>   src/CMakeLists.txt 818595e 
>   src/klocalizedcontext.h PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/126087/diff/
> 
> 
> Testing
> ---
> 
> Ported KDeclarative, everything still seems to work.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KIdleTime : to poll not or provide a settable resolution for the polling backends?

[René J . V . Bertin]

Martin Graesslin wrote:

Sorry, long reply, too many arguments.

> Don't poll. Never ever, don't poll. That's the opposite of what an 
application wants to do. 

As I said elsewhere, while I agree on the principle I don't think that should 
be 
dogma. It depends on the requirements of the application in question, and the 
facilities provided by the operation system on which it's running. There are 
perfectly justifiable use cases in which detection precision and reaction time 
prime over being nice to others (and risk being moved to the end of the event 
processing queue).
The KIdleTime documentation does not make any statements as to whether it is 
NOT 
to be used for anything with real-time-like requirements. It's the possibility 
to serve that specific kind of use-case that I had in mind (which is for 
application developers to decide on, not KF5 developers...). If there's an 
existing sensible default then that should of course be incorporated in a new 
mechanism to provide a settable polling resolution.

> I think it's better to not provide the feature than to perform polling.

I don't agree in this case. Not with my background in which a reliable and 
precise detection of idle periods and/or user input could have come in very 
handy.
It's simple, really. The KIdleTime documentation should provide information on 
the underlying implementation, and point out that polling might be used. Anyone 
looking into using the feature can then decide for themselves whether or not 
that is an issue -- and control the polling overhead via the new mechanism I'm 
proposing.

> Ah found it. It's in the parent WidgetBasedPoller. I think that implementation
> already answers how you should do the polling, because it has an
> implementation for it. But nevertheless: please try to not poll.

That implementation still polls. It only uses a widget to refrain from polling 
as long as there is user activity, but according to the documentation this is 
true for a QTimer with interval 0 too (in that case the timer fires only when 
there is no activity).

From what I understand of the code, WidgedBasedPoller still polls at a 
calculated interval when there is no activity, and uses a fixed margin of error 
for determining whether a timeout was reached.
*** That margin is smaller than the one originally used in macpoller.cpp, but 
we're still speaking of an undocumented ±300ms error on the timeout detection.

I don't understand why the `mintime` calculation is repeated at each poll (I 
rolled my own unknowingly, in the methods that add or remove a timeout to the 
list, and I think Qt has a datatype that orders that list so the minimum is 
always the 1st element).

*** What is the idea behind setting the poll timer to `mintime - idle`? Am I 
right that the grabber widget allows to stop the polling as soon as activity 
resumes (removing the need for QTimer::interval==0)?
If so, it still seems suboptimal to use the exact "error" (remaining time to 
wait) as the poll interval. I'm not the best expert on control theory of the 
class, but I do remember it's generally a bad idea to drive a feedback loop 
with 
the unmodified error. Something like (mintime-idle)/2 should lead to more 
stable 
behaviour (and the best possible precision during the last <2ms).

BTW: shouldn't the code use QTimer::setInterval in case the timer is already 
running? According to the documentation, QTimer::start(msec) will first stop 
and 
then restart the timer. If QTimer::setInterval doesn't (not documented...) that 
ought to be preferable, no?

Anyway, I'd adapt my proposition to include the existing implementation as the 
default, which could also be (re)selected by something like 
KIdleTimer::setResolution(KIdleTimer::DefaultResolution) (== -1).

As to MacPoller: I'll see whether I subclass WidgetBasedPoller or whether it's 
just as efficient to copy/paste the relevant code (if I'd be overriding too 
many 
methods, which might be the case here).

R.

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126087: Move the i18n context from KDeclarative

[Marco Martin]

> On Nov. 17, 2015, 9:58 a.m., Marco Martin wrote:
> > Here's the reason I don't like it:
> > In origin KDeclarative was intended to be a library that only depended from 
> > Qt stuff, to be at most tier 2 (and imports there were supposed to be 
> > qt-only as well) and frameworks applications using QML were supposed to do 
> > it trough KDeclarative..
> > This just highlights a problem happened afterwards, when no frameworks 
> > maintainer wanted any qml binding it the framework's repository, the 
> > kdeclarative repo ended up being pretty much a dumpster where all the 
> > binding of all the frameworks went, making it depend from pretty much 
> > everything.
> > This also means that whoever will need the binding of $framework, it will 
> > probably rather rewrite them, since using kdeclarative means pretty much 
> > depending from all of them.
> > So, fine for making the i18n context independent, but iff the whole 
> > situation gets resolved and each single import that depends from more than 
> > Qt stuff goes either in its framework repository or gets its own.
> 
> Martin Gräßlin wrote:
> I agree with Marco: we should try to split this up again. Somehow the 
> framework starts to remind me of kdelibs4 and in applications I maintain it 
> takes a lot of strength to buy into using it. (Why would I want KIO in KWin?)
> 
> Aleix Pol Gonzalez wrote:
> Isn't it what this patch is about?
> 
> To me it's clear that KIconProvider could go to KIconThemes and 
> KIOAccessManagerFactory could go to KIO.
> 
> Marco Martin wrote:
> we could push that right at the start of the 5.18 cycle so that's done 
> well in advance

yes, and most of the linking luckily is private. the only thing that is public 
and a bit out of tune unfortunately is configpropertymap


- Marco


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126087/#review88463
---


On Nov. 16, 2015, 2:55 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126087/
> ---
> 
> (Updated Nov. 16, 2015, 2:55 p.m.)
> 
> 
> Review request for KDE Frameworks, Chusslove Illich and Marco Martin.
> 
> 
> Repository: ki18n
> 
> 
> Description
> ---
> 
> The only way to use `i18n*()` so far in QML is by depending on all 
> KDeclarative. This patch moves the necessary bits there so it can be adopted 
> by an application or framework just by offering the needed bits within KI18n.
> This is done by offering an object with methods that map to the `i18n*()` C++ 
> counter-parts.
> 
> 
> Diffs
> -
> 
>   src/klocalizedcontext.cpp PRE-CREATION 
>   src/CMakeLists.txt 818595e 
>   src/klocalizedcontext.h PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/126087/diff/
> 
> 
> Testing
> ---
> 
> Ported KDeclarative, everything still seems to work.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126056: Use KDE_INSTALL_ICONDIR to install the icons

[Heiko Becker]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126056/
---

(Updated Nov. 17, 2015, 12:42 nachm.)


Review request for KDE Frameworks and Uri Herrera.


Changes
---

Removed the unnecessary code and win32 handling, s/FULL_//


Summary (updated)
-

Use KDE_INSTALL_ICONDIR to install the icons


Repository: breeze-icons


Description (updated)
---

It was previously hard-coded to prefix/share which is not helpful on a
multiarch layout, where the prefix might be something like /usr/${arch}
but arch independent files should still go into /usr/share.

Also clean up unecessary cmake code. "cmake_minimum_required(VERSION 2.8)"
was already set to a higher value in the root CMakeLists.txt, same for
"set (CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmake")".
Furthermore I couldn't find any '*.sh' files in the repo.

REVIEW: 126056


Diffs (updated)
-

  icons-dark/CMakeLists.txt f039db19e1df89f62a33dc323cf0b8344d9b33fd 
  icons/CMakeLists.txt 6c6e3b7efb6ca1490ed52356beaf06c4e181fee0 

Diff: https://git.reviewboard.kde.org/r/126056/diff/


Testing
---

Icons get installed into the desired location.


Thanks,

Heiko Becker

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126057: Use KDE_INSTALL_ICONDIR to install the icons

[Heiko Becker]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126057/
---

(Updated Nov. 17, 2015, 12:45 nachm.)


Review request for KDE Frameworks and andreas kainz.


Changes
---

Removed win32 handling, s/FULL_//


Summary (updated)
-

Use KDE_INSTALL_ICONDIR to install the icons


Repository: oxygen-icons5


Description (updated)
---

It was previously hard-coded to prefix/share which is not helpful on a
multiarch layout, where the prefix might be something like /usr/${arch}
but arch independent files should still go into /usr/share.

REVIEW: 126057


Diffs (updated)
-

  CMakeLists.txt 85962199e481572e05e45dab6848983b8f22c3e1 

Diff: https://git.reviewboard.kde.org/r/126057/diff/


Testing
---

Icons get installed into the desired location.


Thanks,

Heiko Becker

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KIdleTime: early and/or failing/rejected timeout detection?

[René J . V . Bertin]

Martin Graesslin wrote:


> I don't really understand. How can it signal too early?

I was wrong about the MS Windows implementation, but from WidgetBasedPoller:

Q_FOREACH(int timeOut, m_timeouts) {
if ( ( timeOut - idle < 300 && timeOut >= idle ) || ( idle - timeOut < 
300 && idle > timeOut ) ) {
// Bingo!
emit timeoutReached( timeOut );
}
}

that code accepts any idle value that is within ±300ms of timeOut. Since idle 
increases monotonically after onset, and if comparisons are done often enough, 
the code will signal up to 300ms early.

> I can say for Wayland as I wrote that recently:

I'm guessing Wayland will provide a mechanism that's inspired by what Xcb 
provides?

> * it will fire if it's hit - there might be a delay which I think doesn't
> matter in the case of being swapped out.

Do you mean that the delay is independent of whether or not you're swapped out, 
or that the question of how long the delay is is moot if you are (were) swapped 
out? It will "Fire if it's hit", but what "it" doesn't get hit at the 
configured 
time but at a later time?

> The Wayland implementation doesn't give a guarantee that if there is an idle
> time of 5 sec it will be signalled exactly after 5 sec. That's something a
> non-realtime system cannot provide.

Of course not. But that doesn't mean it is pointless to try to minimise the 
delay (for instance by polling ;))
To put this into perspective: the last thing I wrote in this context was an 
extension to Matlab/Simulink that allowed to run a compiled Simulink model 
realtime on a sufficiently fast host, without need for special realtime 
hardware.
Let's be clear about this: true realtime indeed requires a special system, or 
at 
the very least support from the OS, and the appropriate coding approach in your 
own application. I have a hunch that Qt is already used "that way" (it exists 
on 
Qnx after all). There aren't that many applications that need 100%, "hard" 
realtime behaviour (as opposed to only a fraction of their running time). 
Realtime also isn't necessarily about the lowest possible delays (they just 
need 
to be known and more or less constant). OTOH there are many more types of 
applications that want to be perceived to run in real time, with the smallest 
possible delays. IMHO those kind of applications (games, simulators, 
psychophysics or other empirical software, ...) are much more likely to resort 
to convenience frameworks like those provided by KF5.
(I was going to add "apps for controlling little trains" but those probably 
have 
little need for KIdleTime, just for other time-related functions with 
comparable 
"good" behaviour :))

> And honestly I don't think it matters. KIdleTime is about being noticed about
> being idle. We are talking here about timeouts which are in an area where
> realtime doesn't matter [...]
> If you want
> to use KIdleTime for anything below let's say half a minute, I think it's the
> wrong tool for it.

And I really don't see the point in providing a framework for this (and 
basically only this) if it's not going to try to be as versatile as possible. 
It 
can and should aim to avoid hogging any resources in the default configuration. 
But as it happens it is actually more complicated to implement that than to 
implement the basic approach that can also provide the best precision and 
detection delays. I think the framework becomes more versatile if it allows 
users to switch it to a more precise/powerful and (possibly) more intrusive 
mode.
If of course the majority of major platforms on which it is deployed support 
the 
kind of precision I'm thinking of.

BTW, the exact durations are inconsequential (as long as they're above what can 
be timed a reasonable precision). It's not because you're interested to learn 
if 
an application has been idle for 10min that all of a sudden it becomes more 
acceptable to detect that with a much worse precision.

And FWIW: any backend that's based on QTimer and use Qt::PreciseTimer to 
achieve 
better than 5% error (= at least ms accuracy).

R.

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KIdleTime: early and/or failing/rejected timeout detection?

[Martin Graesslin]

On Tuesday, November 17, 2015 5:04:09 PM CET René J. V. Bertin wrote:
> > I can say for Wayland as I wrote that recently:
> I'm guessing Wayland will provide a mechanism that's inspired by what Xcb
> provides?

eh no. As I control both the server (hello KWin) and the client (hello 
KWayland) I just designed a protocol which is ideal for KIdleTime.

> 
> > * it will fire if it's hit - there might be a delay which I think doesn't
> > matter in the case of being swapped out.
> 
> Do you mean that the delay is independent of whether or not you're swapped
> out, or that the question of how long the delay is is moot if you are
> (were) swapped out? It will "Fire if it's hit", but what "it" doesn't get
> hit at the configured time but at a later time?

Sorry, but I just don't get your problem here. This all sounds highly 
theoretical to me and is nothing which I considered at all.

The implementation is basically:
* Wayland client registers an idle timeout
* KWayland::Server creates a QTimer
* on each input event the QTimer is restarted
* if the QTimer times out in the Wayland server the Wayland client is notified

Now this includes a few IPC roundtrips which are completely outside the 
control of my code. Like the last step. What do I know when the client will be 
notified by the kernel about it?

> 
> > The Wayland implementation doesn't give a guarantee that if there is an
> > idle time of 5 sec it will be signalled exactly after 5 sec. That's
> > something a non-realtime system cannot provide.
> 
> Of course not. But that doesn't mean it is pointless to try to minimise the
> delay (for instance by polling ;))

There is absolutely zero polling in the Wayland implementation!

> And I really don't see the point in providing a framework for this (and
> basically only this) if it's not going to try to be as versatile as
> possible. It can and should aim to avoid hogging any resources in the
> default configuration.

Repeat after me: no polling! I mean that: NO POLLING! Don't add code which 
polls. Don't do that.

NO POLLING!

If you cannot do that on OSX, I really think it's better to not provide it. If 
you think it's unfair that there is a backend for X11 which performs polling, 
then I'm going to delete the XScreenSaver based one.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KIdleTime: early and/or failing/rejected timeout detection?

[Martin Graesslin]

On Tuesday, November 17, 2015 2:59:57 PM CET René J.V. Bertin wrote:
> KIdleTime really seems to have captured my attention - it's after all very
> closely related to "problems" I've had to solve more than a few times in a
> previous life.
> 
> Currently, the MS Windows and OS X backends have 2 issues with detecting &
> signalling idle timeouts, aside from the fact they allow a heavy margin of
> error:
> 
> - timeouts can be (and are) signalled early (by up to the detection margin).
> I tend to think that time delays should not never be reported early. -
> timeouts can fail to be reported if detected too late.

I don't really understand. How can it signal too early?

> What does the XCB alarm-based mechanism do in this case? I would expect an
> alarm to fire even if it's late, rather than being missed completely. Also,
> does the XCB implementation allow for early reporting of timeouts?

I can say for Wayland as I wrote that recently:
* it cannot fire too early
* it will fire if it's hit - there might be a delay which I think doesn't 
matter in the case of being swapped out.

The Wayland implementation doesn't give a guarantee that if there is an idle 
time of 5 sec it will be signalled exactly after 5 sec. That's something a 
non-realtime system cannot provide.

And honestly I don't think it matters. KIdleTime is about being noticed about 
being idle. We are talking here about timeouts which are in an area where 
realtime doesn't matter and also being swapped out doesn't matter. If you want 
to use KIdleTime for anything below let's say half a minute, I think it's the 
wrong tool for it.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

KIdleTime: early and/or failing/rejected timeout detection?

[René J . V . Bertin]

KIdleTime really seems to have captured my attention - it's after all very 
closely related to "problems" I've had to solve more than a few times in a 
previous life.

Currently, the MS Windows and OS X backends have 2 issues with detecting & 
signalling idle timeouts, aside from the fact they allow a heavy margin of 
error:

- timeouts can be (and are) signalled early (by up to the detection margin). I 
tend to think that time delays should not never be reported early.
- timeouts can fail to be reported if detected too late.

For that 2nd point, consider an application that has a timeout set for 5s and 
that got swapped out, or that for some other reason detects too late that it 
has been idle for 5s. If this is detected at, say, 6.5s, there still has been 
5s of idletime, but since the current idle time is outside the margin of error 
it is not signalled.

What does the XCB alarm-based mechanism do in this case? I would expect an 
alarm to fire even if it's late, rather than being missed completely.
Also, does the XCB implementation allow for early reporting of timeouts?

I'd test this empirically, but my current Linux systems aren't suitable for 
this kind of work.

R.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KIdleTime: early and/or failing/rejected timeout detection?

[René J . V . Bertin]

Martin Graesslin wrote:


> NO POLLING!
> 
> If you cannot do that on OSX, I really think it's better to not provide it. If
> you think it's unfair that there is a backend for X11 which performs polling,
> then I'm going to delete the XScreenSaver based one.

I'm not adding code that polls, I'm modifying an implementation that polls. I'm 
even making it less dependent on frequent polling in its default configuration, 
inspired by WidgetBasedPoller.

I'm not touching your Wayland implementation, nor the Xcb implementation, but I 
don't see your gripe with changing things in code that is written by someone 
else...

If developing KF5 frameworks isn't a democratic endeavour I don't really see 
what I'm doing here either.

R.

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126087: Move the i18n context from KDeclarative

[Aleix Pol Gonzalez]

> On Nov. 17, 2015, 9:43 a.m., Chusslove Illich wrote:
> > Could you also document the usage in docs/programmers-guide.md (section 
> > #link_cat)? I'm not much into QML, so it would help me understand the 
> > implications of the usage.
> > 
> > It seems to me other three series of calls (xi18n*, ki18n*, kxi18n*) should 
> > be made available as well.

I don't think we want the `k*i18n*` version of the calls, as they return 
KLocalizedString and we probably don't need to deal with it from QML.

Regarding `xi18n*`, I see that we have counter-parts for every of the `i18n*` 
calls. Could you explain a bit what does it do differently? Is it to support 
the xml-like markup?


- Aleix


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126087/#review88459
---


On Nov. 16, 2015, 3:55 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126087/
> ---
> 
> (Updated Nov. 16, 2015, 3:55 p.m.)
> 
> 
> Review request for KDE Frameworks, Chusslove Illich and Marco Martin.
> 
> 
> Repository: ki18n
> 
> 
> Description
> ---
> 
> The only way to use `i18n*()` so far in QML is by depending on all 
> KDeclarative. This patch moves the necessary bits there so it can be adopted 
> by an application or framework just by offering the needed bits within KI18n.
> This is done by offering an object with methods that map to the `i18n*()` C++ 
> counter-parts.
> 
> 
> Diffs
> -
> 
>   src/klocalizedcontext.cpp PRE-CREATION 
>   src/CMakeLists.txt 818595e 
>   src/klocalizedcontext.h PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/126087/diff/
> 
> 
> Testing
> ---
> 
> Ported KDeclarative, everything still seems to work.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KIdleTime : to poll not or provide a settable resolution for the polling backends?

[René J . V . Bertin]

Another thing I should have realised:

It is not currently feasible with Qt to detect "global" events that are not 
destined to "ourselves" (see 
http://stackoverflow.com/questions/19229777/how-to-detect-global-mouse-button-events
 and 
http://stackoverflow.com/questions/4752427/osx-detect-system-wide-keydown-events).
 In addition to that, creating the grabber widget when no other GUI 
exists causes a basic, empty window to appear on the screen (-1000,-1000 
happens 
to be on my left monitor, apparently).

I'll have a look at adding an ObjC(++) snippet, but only since I love the 
language :)

R.

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126056: Use KDE_INSTALL_ICONDIR to install the icons

[Alex Merry]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126056/#review88499
---



icons/CMakeLists.txt (line 9)


I suspect this call *does* actually need the absolute path.


- Alex Merry


On Nov. 17, 2015, 12:42 p.m., Heiko Becker wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126056/
> ---
> 
> (Updated Nov. 17, 2015, 12:42 p.m.)
> 
> 
> Review request for KDE Frameworks and Uri Herrera.
> 
> 
> Repository: breeze-icons
> 
> 
> Description
> ---
> 
> It was previously hard-coded to prefix/share which is not helpful on a
> multiarch layout, where the prefix might be something like /usr/${arch}
> but arch independent files should still go into /usr/share.
> 
> Also clean up unecessary cmake code. "cmake_minimum_required(VERSION 2.8)"
> was already set to a higher value in the root CMakeLists.txt, same for
> "set (CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmake")".
> Furthermore I couldn't find any '*.sh' files in the repo.
> 
> REVIEW: 126056
> 
> 
> Diffs
> -
> 
>   icons-dark/CMakeLists.txt f039db19e1df89f62a33dc323cf0b8344d9b33fd 
>   icons/CMakeLists.txt 6c6e3b7efb6ca1490ed52356beaf06c4e181fee0 
> 
> Diff: https://git.reviewboard.kde.org/r/126056/diff/
> 
> 
> Testing
> ---
> 
> Icons get installed into the desired location.
> 
> 
> Thanks,
> 
> Heiko Becker
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126057: Use KDE_INSTALL_ICONDIR to install the icons

[Alex Merry]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126057/#review88500
---

Ship it!


Ship It!

- Alex Merry


On Nov. 17, 2015, 12:45 p.m., Heiko Becker wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126057/
> ---
> 
> (Updated Nov. 17, 2015, 12:45 p.m.)
> 
> 
> Review request for KDE Frameworks and andreas kainz.
> 
> 
> Repository: oxygen-icons5
> 
> 
> Description
> ---
> 
> It was previously hard-coded to prefix/share which is not helpful on a
> multiarch layout, where the prefix might be something like /usr/${arch}
> but arch independent files should still go into /usr/share.
> 
> REVIEW: 126057
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 85962199e481572e05e45dab6848983b8f22c3e1 
> 
> Diff: https://git.reviewboard.kde.org/r/126057/diff/
> 
> 
> Testing
> ---
> 
> Icons get installed into the desired location.
> 
> 
> Thanks,
> 
> Heiko Becker
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126078: [OS X] modernising the KIdleTime plugin (WIP!)

[Lamarque Souza]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126078/#review88505
---



src/plugins/osx/macpoller.h (line 24)


Nitpick: this should go after #include 



src/plugins/osx/macpoller.h (line 75)


One line per variable.



src/plugins/osx/macpoller.h (line 76)


Here too.



src/plugins/osx/macpoller.cpp (line 2)


This should be appended to the list, not prepended. I know, the next line 
is wrong too.



src/plugins/osx/macpoller.cpp (line 29)


Remove trailing space character.



src/plugins/osx/macpoller.cpp (line 49)


Initialize m_nativeGrabber here too.



src/plugins/osx/macpoller.cpp (line 100)


Use qCWarning instead.



src/plugins/osx/macpoller.cpp (line 135)


Shouldn't you check the return value of this method?



src/plugins/osx/macpoller.cpp (line 137)


This should be changed to "return true", right?



src/plugins/osx/macpoller.cpp (line 212)


We usually join the last } with the next "else {", like this:

} else {



src/plugins/osx/macpoller.cpp (line 221)


Remove commented code.



src/plugins/osx/macpoller.cpp (line 242)


We usually do not use extra space after ( and before )



src/plugins/osx/macpoller.cpp (line 274)


Remove commented code.



src/plugins/osx/macpoller.cpp (line 325)


I do not get the "Unsetting m_catch is enough" comment. What is it supposed 
to mean since unsetting m_catch is the original code.



src/plugins/osx/macpoller.cpp (line 343)


Remove trailing space and shouldn't the commented code in this method be 
removed?



src/plugins/osx/macpoller_helper.mm (line 2)


Append new entries in copyright section, do not prepend.



src/plugins/osx/macpoller_helper.mm (line 43)


Use qCDebug instead.



src/plugins/osx/macpoller_helper.mm (line 54)


Usually when a new operation returns 0 it is because system is on short on 
RAM memory (or memory is too fragmented). I would add assert here instead of 
silently ignoring the failure to allocate memory.



src/plugins/osx/macpoller_helper.mm (line 78)


There is no point in doing this if the next line will delete nativeGrabber.



src/plugins/osx/macpoller_helper.mm (line 82)


This line can go to inside the if clause above.


- Lamarque Souza


On Nov. 17, 2015, 9:13 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126078/
> ---
> 
> (Updated Nov. 17, 2015, 9:13 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Frameworks and Dario Freddi.
> 
> 
> Repository: kidletime
> 
> 
> Description
> ---
> 
> I noticed that the KIdleTime example doesn't work properly on OS X, and that 
> the plugin for OS X still uses the deprecated Carbon-based algorithm that I 
> already patched for KDE4.
> 
> This patch is a work-in-progress (hence the qDebugs) update to use IOKit, 
> IORegistry and CoreServices to do idle-time calculation as it should be done, 
> and allow simulated user activity through a "less deprecated" function.
> 
> 
> Diffs
> -
> 
>   src/plugins/osx/CMakeLists.txt e1b50b8 
>   src/plugins/osx/macpoller.h ef51ea5 
>   src/plugins/osx/macpoller.cpp ad9c10f 
>   src/plugins/osx/macpoller_helper.mm PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/126078/diff/
> 
> 
> Testing
> ---
> 
> On OS X 10.9 with Qt 5.5.1 and frameworks 5.16.0 .
> 
> The example now works: when I set a QTimer with interval==0, the expected 
> wait for user input (`resumingFromIdle` signal) works. However, I am getting 
> a `stopCatchingIdleEvents` signal which means 

Re: Review Request 125705: Use LANG for month names in calendar applet

[Martin Klapetek]

> On Oct. 28, 2015, 9:44 p.m., Martin Klapetek wrote:
> > So...any word on this?
> 
> Albert Astals Cid wrote:
> Re-reading your comment, if i understand it correctly, you claim it is a 
> bug in Qt that it does obey LC_DATE for month names when according to you 
> LC_DATE is only for the formatting and should be using LANG, right? 
> Why not fix it upstream then?
> 
> Martin Klapetek wrote:
> I don't claim it's a bug as I simply don't know if it's correct behavior 
> or not, just that the way it works does not suit our intended use case, 
> because we encourage our users to mess with LC_* variables through the 
> Formats KCM, which makes it prone to mixed configurations like LC_DATE=cs_CZ 
> and LANG=en_US.
> 
> But nevertheless a) David Edmundson has a patch in the works so let's see 
> if they think it's a bug and b) we'd need something for the meantime anyway.
> 
> David Edmundson wrote:
> Just uploaded: https://codereview.qt-project.org/139295

Given the Qt patch was rejected, I'll ship this if noone objects.


- Martin


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125705/#review87617
---


On Oct. 20, 2015, 9:04 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125705/
> ---
> 
> (Updated Oct. 20, 2015, 9:04 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Bugs: 353715
> http://bugs.kde.org/show_bug.cgi?id=353715
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> Simple QDate::longMonthName won't do the job as it
> will return the month name using LC_DATE locale which is used
> for date formatting etc. So for example, in en_US locale
> and cs_CZ LC_DATE, it would return Czech month names while
> it should return English ones. So here we force the LANG
> locale and take the month name from that.
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/calendar/calendar.cpp 67a08e5 
> 
> Diff: https://git.reviewboard.kde.org/r/125705/diff/
> 
> 
> Testing
> ---
> 
> LC_DATE=cs_CZ
> LANG=en_US
> 
> Month names in calendar applet are now english.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: plasma-framework master stable-kf5-qt5 » Linux,NoX11,gcc - Build # 152 - Failure!

[no-reply]

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/plasma-framework%20master%20stable-kf5-qt5/PLATFORM=Linux,Variation=NoX11,compiler=gcc/152/
Project: PLATFORM=Linux,Variation=NoX11,compiler=gcc
Date of build: Tue, 17 Nov 2015 23:11:23 +
Build duration: 13 sec

CHANGE SET
Revision e757ebb4839690e20c1ce009c6f87fb92cc0bb37 by Martin Klapetek: 
([calendar] Add missing item id)
  change: edit src/declarativeimports/calendar/qml/MonthView.qml
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: plasma-framework master stable-kf5-qt5 » Linux,NoX11,gcc - Build # 153 - Fixed!

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/plasma-framework%20master%20stable-kf5-qt5/PLATFORM=Linux,Variation=NoX11,compiler=gcc/153/
Project: PLATFORM=Linux,Variation=NoX11,compiler=gcc
Date of build: Wed, 18 Nov 2015 00:04:41 +
Build duration: 2 min 53 sec

CHANGE SET
Revision c84e591b968eeb70dd89c86bc0899f3a00c494dc by Martin Klapetek: 
([calendar] Use correct plugin IID for filtering)
  change: edit src/declarativeimports/calendar/eventpluginsmanager.cpp


JUNIT RESULTS

Name: (root) Failed: 0 test(s), Passed: 10 test(s), Skipped: 0 test(s), Total: 
10 test(s)

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 5/7 (71%)FILES 60/100 (60%)CLASSES 60/100 (60%)LINE 3488/9601 
(36%)CONDITIONAL 1637/2642 (62%)

By packages
  
autotests
FILES 18/18 (100%)CLASSES 18/18 (100%)LINE 503/518 
(97%)CONDITIONAL 328/586 (56%)
src.declarativeimports.core
FILES 7/20 (35%)CLASSES 7/20 (35%)LINE 268/1793 
(15%)CONDITIONAL 66/112 (59%)
src.plasma
FILES 14/21 (67%)CLASSES 14/21 (67%)LINE 1584/3645 
(43%)CONDITIONAL 769/1186 (65%)
src.plasma.private
FILES 17/24 (71%)CLASSES 17/24 (71%)LINE 898/1675 
(54%)CONDITIONAL 374/570 (66%)
src.plasma.scripting
FILES 0/3 (0%)CLASSES 0/3 (0%)LINE 0/194 (0%)CONDITIONAL 0/0 
(100%)
src.plasmaquick
FILES 4/11 (36%)CLASSES 4/11 (36%)LINE 235/1663 
(14%)CONDITIONAL 100/188 (53%)
src.plasmaquick.private
FILES 0/3 (0%)CLASSES 0/3 (0%)LINE 0/113 (0%)CONDITIONAL 0/0 
(100%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: plasma-framework master stable-kf5-qt5 » Linux,NoX11,gcc - Build # 153 - Fixed!

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/plasma-framework%20master%20stable-kf5-qt5/PLATFORM=Linux,Variation=NoX11,compiler=gcc/153/
Project: PLATFORM=Linux,Variation=NoX11,compiler=gcc
Date of build: Wed, 18 Nov 2015 00:04:41 +
Build duration: 2 min 53 sec

CHANGE SET
Revision c84e591b968eeb70dd89c86bc0899f3a00c494dc by Martin Klapetek: 
([calendar] Use correct plugin IID for filtering)
  change: edit src/declarativeimports/calendar/eventpluginsmanager.cpp


JUNIT RESULTS

Name: (root) Failed: 0 test(s), Passed: 10 test(s), Skipped: 0 test(s), Total: 
10 test(s)

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 5/7 (71%)FILES 60/100 (60%)CLASSES 60/100 (60%)LINE 3488/9601 
(36%)CONDITIONAL 1637/2642 (62%)

By packages
  
autotests
FILES 18/18 (100%)CLASSES 18/18 (100%)LINE 503/518 
(97%)CONDITIONAL 328/586 (56%)
src.declarativeimports.core
FILES 7/20 (35%)CLASSES 7/20 (35%)LINE 268/1793 
(15%)CONDITIONAL 66/112 (59%)
src.plasma
FILES 14/21 (67%)CLASSES 14/21 (67%)LINE 1584/3645 
(43%)CONDITIONAL 769/1186 (65%)
src.plasma.private
FILES 17/24 (71%)CLASSES 17/24 (71%)LINE 898/1675 
(54%)CONDITIONAL 374/570 (66%)
src.plasma.scripting
FILES 0/3 (0%)CLASSES 0/3 (0%)LINE 0/194 (0%)CONDITIONAL 0/0 
(100%)
src.plasmaquick
FILES 4/11 (36%)CLASSES 4/11 (36%)LINE 235/1663 
(14%)CONDITIONAL 100/188 (53%)
src.plasmaquick.private
FILES 0/3 (0%)CLASSES 0/3 (0%)LINE 0/113 (0%)CONDITIONAL 0/0 
(100%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126087: Move the i18n context from KDeclarative

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126087/#review88463
---


Here's the reason I don't like it:
In origin KDeclarative was intended to be a library that only depended from Qt 
stuff, to be at most tier 2 (and imports there were supposed to be qt-only as 
well) and frameworks applications using QML were supposed to do it trough 
KDeclarative..
This just highlights a problem happened afterwards, when no frameworks 
maintainer wanted any qml binding it the framework's repository, the 
kdeclarative repo ended up being pretty much a dumpster where all the binding 
of all the frameworks went, making it depend from pretty much everything.
This also means that whoever will need the binding of $framework, it will 
probably rather rewrite them, since using kdeclarative means pretty much 
depending from all of them.
So, fine for making the i18n context independent, but iff the whole situation 
gets resolved and each single import that depends from more than Qt stuff goes 
either in its framework repository or gets its own.

- Marco Martin


On Nov. 16, 2015, 2:55 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126087/
> ---
> 
> (Updated Nov. 16, 2015, 2:55 p.m.)
> 
> 
> Review request for KDE Frameworks, Chusslove Illich and Marco Martin.
> 
> 
> Repository: ki18n
> 
> 
> Description
> ---
> 
> The only way to use `i18n*()` so far in QML is by depending on all 
> KDeclarative. This patch moves the necessary bits there so it can be adopted 
> by an application or framework just by offering the needed bits within KI18n.
> This is done by offering an object with methods that map to the `i18n*()` C++ 
> counter-parts.
> 
> 
> Diffs
> -
> 
>   src/klocalizedcontext.cpp PRE-CREATION 
>   src/CMakeLists.txt 818595e 
>   src/klocalizedcontext.h PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/126087/diff/
> 
> 
> Testing
> ---
> 
> Ported KDeclarative, everything still seems to work.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126091: Remove printscreen.khotkeys from KHotkeys package

[Boudhayan Gupta]

> On Nov. 17, 2015, 12:51 p.m., Martin Gräßlin wrote:
> > should the file be added to ksnapshot?

Already done, installs to both {CMAKE_INSTALL_PREFIX}/share/khotkeys and 
{CMAKE_INSTALL_PREFIX}/share/apps/khotkeys (for kde4 compatibility)


- Boudhayan


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126091/#review88456
---


On Nov. 16, 2015, 10:36 p.m., Boudhayan Gupta wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126091/
> ---
> 
> (Updated Nov. 16, 2015, 10:36 p.m.)
> 
> 
> Review request for KDE Frameworks, Plasma and David Edmundson.
> 
> 
> Repository: khotkeys
> 
> 
> Description
> ---
> 
> After moving KSnapshot to Extragear I've modified it to install its own 
> khotkeys file (which it does correctly). Spectacle already installs its own 
> KHotkeys file, so there's no reason anymore for KHotkeys to include its own 
> PrintScreen hotkey file.
> 
> I'll push out a special release of KSnapshot for distributions to use once 
> the Plasma 5.5 version of KHotkeys is pushed out, so printscreen 
> functionality won't be broken on the desktop (assuming, that is, distros push 
> out the updates together).
> 
> 
> Diffs
> -
> 
>   data/CMakeLists.txt f3bcb57 
>   data/printscreen.khotkeys e583311 
> 
> Diff: https://git.reviewboard.kde.org/r/126091/diff/
> 
> 
> Testing
> ---
> 
> Doesn't install the printscreen.khotkeys file anymore
> 
> 
> Thanks,
> 
> Boudhayan Gupta
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126087: Move the i18n context from KDeclarative

[Martin Gräßlin]

> On Nov. 17, 2015, 10:58 a.m., Marco Martin wrote:
> > Here's the reason I don't like it:
> > In origin KDeclarative was intended to be a library that only depended from 
> > Qt stuff, to be at most tier 2 (and imports there were supposed to be 
> > qt-only as well) and frameworks applications using QML were supposed to do 
> > it trough KDeclarative..
> > This just highlights a problem happened afterwards, when no frameworks 
> > maintainer wanted any qml binding it the framework's repository, the 
> > kdeclarative repo ended up being pretty much a dumpster where all the 
> > binding of all the frameworks went, making it depend from pretty much 
> > everything.
> > This also means that whoever will need the binding of $framework, it will 
> > probably rather rewrite them, since using kdeclarative means pretty much 
> > depending from all of them.
> > So, fine for making the i18n context independent, but iff the whole 
> > situation gets resolved and each single import that depends from more than 
> > Qt stuff goes either in its framework repository or gets its own.

I agree with Marco: we should try to split this up again. Somehow the framework 
starts to remind me of kdelibs4 and in applications I maintain it takes a lot 
of strength to buy into using it. (Why would I want KIO in KWin?)


- Martin


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126087/#review88463
---


On Nov. 16, 2015, 3:55 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126087/
> ---
> 
> (Updated Nov. 16, 2015, 3:55 p.m.)
> 
> 
> Review request for KDE Frameworks, Chusslove Illich and Marco Martin.
> 
> 
> Repository: ki18n
> 
> 
> Description
> ---
> 
> The only way to use `i18n*()` so far in QML is by depending on all 
> KDeclarative. This patch moves the necessary bits there so it can be adopted 
> by an application or framework just by offering the needed bits within KI18n.
> This is done by offering an object with methods that map to the `i18n*()` C++ 
> counter-parts.
> 
> 
> Diffs
> -
> 
>   src/klocalizedcontext.cpp PRE-CREATION 
>   src/CMakeLists.txt 818595e 
>   src/klocalizedcontext.h PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/126087/diff/
> 
> 
> Testing
> ---
> 
> Ported KDeclarative, everything still seems to work.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126087: Move the i18n context from KDeclarative

[Chusslove Illich]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126087/#review88459
---


Could you also document the usage in docs/programmers-guide.md (section 
#link_cat)? I'm not much into QML, so it would help me understand the 
implications of the usage.

It seems to me other three series of calls (xi18n*, ki18n*, kxi18n*) should be 
made available as well.

- Chusslove Illich


On Нов. 16, 2015, 3:55 по п., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126087/
> ---
> 
> (Updated Нов. 16, 2015, 3:55 по п.)
> 
> 
> Review request for KDE Frameworks, Chusslove Illich and Marco Martin.
> 
> 
> Repository: ki18n
> 
> 
> Description
> ---
> 
> The only way to use `i18n*()` so far in QML is by depending on all 
> KDeclarative. This patch moves the necessary bits there so it can be adopted 
> by an application or framework just by offering the needed bits within KI18n.
> This is done by offering an object with methods that map to the `i18n*()` C++ 
> counter-parts.
> 
> 
> Diffs
> -
> 
>   src/klocalizedcontext.cpp PRE-CREATION 
>   src/CMakeLists.txt 818595e 
>   src/klocalizedcontext.h PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/126087/diff/
> 
> 
> Testing
> ---
> 
> Ported KDeclarative, everything still seems to work.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126078: [OS X] modernising the KIdleTime plugin (WIP!)

[Martin Gräßlin]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126078/#review88509
---



src/plugins/osx/macpoller.cpp (lines 144 - 149)


seriously? You care about idle timeouts below 5 msec? This is a framework 
to tell the application whether the user doesn't use input devices. I don't 
know how fast you type, but I'm relatively certain that it takes more than 5 
msec to move my finger from one key to another. What exactly is that you want 
to detect here? An event after each key press, maybe even between a key press 
and a key release? Because that's probably already more about 5 msec.


- Martin Gräßlin


On Nov. 17, 2015, 10:13 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126078/
> ---
> 
> (Updated Nov. 17, 2015, 10:13 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Frameworks and Dario Freddi.
> 
> 
> Repository: kidletime
> 
> 
> Description
> ---
> 
> I noticed that the KIdleTime example doesn't work properly on OS X, and that 
> the plugin for OS X still uses the deprecated Carbon-based algorithm that I 
> already patched for KDE4.
> 
> This patch is a work-in-progress (hence the qDebugs) update to use IOKit, 
> IORegistry and CoreServices to do idle-time calculation as it should be done, 
> and allow simulated user activity through a "less deprecated" function.
> 
> 
> Diffs
> -
> 
>   src/plugins/osx/CMakeLists.txt e1b50b8 
>   src/plugins/osx/macpoller.h ef51ea5 
>   src/plugins/osx/macpoller.cpp ad9c10f 
>   src/plugins/osx/macpoller_helper.mm PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/126078/diff/
> 
> 
> Testing
> ---
> 
> On OS X 10.9 with Qt 5.5.1 and frameworks 5.16.0 .
> 
> The example now works: when I set a QTimer with interval==0, the expected 
> wait for user input (`resumingFromIdle` signal) works. However, I am getting 
> a `stopCatchingIdleEvents` signal which means the application waits forever, 
> without ever getting to compare idle time to the list of timeouts.
> I haven't been able to figure out where that signal comes from, nor why this 
> doesn't happen on Linux.
> 
> Surely I'm missing something, but what?
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126078: [OS X] modernising the KIdleTime plugin (WIP!)

[René J . V . Bertin]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126078/
---

(Updated Nov. 17, 2015, 10:12 p.m.)


Review request for KDE Software on Mac OS X and KDE Frameworks.


Changes
---

This revision takes comments from the mailing list into account. Pure 
end-of-idle detection is done in a way similar to how `WidgetBasedPoller` does 
it, by detecting global UI events. That part explains the newly introduced 
ObjC++ file.
Like `WidgetBasedPoller`, the new implementation has to resort to a polling 
approach, and like that example class, the the polling frequency is adaptive. 
However, the adaptive algorithm:
- uses the difference between the current idle time and the next timeout from 
the timeouts list as the source of the "error" value used to calculate the 
timer interval
- uses <1 gain (difference/2) 
- relies on a sorted timeouts list, which ensures that the initial "next 
timeout" is equal to the minimal timeout

In addition, using a sorted timeout list means that determination of a timeout 
hit becomes much simpler, basically `idle >= timeout[i]`. That removes the 
possibility to signal early, or to reject signalling because a timeout was 
detected after the acceptance window.

I have left the `kidletime_example` run idling for over 3 minutes; as far as I 
can tell it behaves as expected, and yields a better-than-1ms accuracy (on 
average timeouts are signalled less than 1ms late). It only shows near the top 
in a running `top` listing on rare occasions, and then only at a few percents 
CPU.

I have left in the hooks to configure a fixed, higher polling frequency, for 
now, until I'm convinced that they're indeed not justified given the 1ms 
resolution imposed by the API.


Repository: kidletime


Description
---

I noticed that the KIdleTime example doesn't work properly on OS X, and that 
the plugin for OS X still uses the deprecated Carbon-based algorithm that I 
already patched for KDE4.

This patch is a work-in-progress (hence the qDebugs) update to use IOKit, 
IORegistry and CoreServices to do idle-time calculation as it should be done, 
and allow simulated user activity through a "less deprecated" function.


Diffs (updated)
-

  src/plugins/osx/CMakeLists.txt e1b50b8 
  src/plugins/osx/macpoller.h ef51ea5 
  src/plugins/osx/macpoller.cpp ad9c10f 
  src/plugins/osx/macpoller_helper.mm PRE-CREATION 

Diff: https://git.reviewboard.kde.org/r/126078/diff/


Testing
---

On OS X 10.9 with Qt 5.5.1 and frameworks 5.16.0 .

The example now works: when I set a QTimer with interval==0, the expected wait 
for user input (`resumingFromIdle` signal) works. However, I am getting a 
`stopCatchingIdleEvents` signal which means the application waits forever, 
without ever getting to compare idle time to the list of timeouts.
I haven't been able to figure out where that signal comes from, nor why this 
doesn't happen on Linux.

Surely I'm missing something, but what?


Thanks,

René J.V. Bertin

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KIdleTime: early and/or failing/rejected timeout detection?

[Martin Graesslin]

On Tuesday, November 17, 2015 6:33:17 PM CET René J. V. Bertin wrote:
> Martin Graesslin wrote:
> > NO POLLING!
> > 
> > If you cannot do that on OSX, I really think it's better to not provide
> > it. If you think it's unfair that there is a backend for X11 which
> > performs polling, then I'm going to delete the XScreenSaver based one.
> 
> I'm not adding code that polls, I'm modifying an implementation that polls.
> I'm even making it less dependent on frequent polling in its default
> configuration, inspired by WidgetBasedPoller.
> 
> I'm not touching your Wayland implementation, nor the Xcb implementation,
> but I don't see your gripe with changing things in code that is written by
> someone else...
> 
> If developing KF5 frameworks isn't a democratic endeavour I don't really see
> what I'm doing here either.

erm, I don't see how you can come to that conclusion. I'm providing my 
feedback here based on the fact that I recently:

* changed KIdleTime to use plugins
* implemented a Wayland backend

The feedback I'm giving you is "no polling". You so far ignored this feedback 
and came up with very confusing mails about things which absolutely do not 
matter in the framework and stuff like optimal polling intervals and what not. 
All things that are completely irrelevant if you don't use polling. This makes 
the interaction very difficult, because I have a feeling of being ignored and 
having to explain things again and again.

Now of course I care about the implementation of KIdleTime on OSX. KIdleTime 
is a useful framework, but if it polls it's in my opinion a useless framework 
and hardly useable for applications. The idea of the framework is to be 
smarter than what applications would come up with. If the implementation polls 
it triggers wakeups in each application which uses it. This is bad, I hope I 
don't have to explain how bad it is. And this is completely independent on 
whether the code already polled or not. We have a common code ownership and 
this includes that I do care about the implementation on other platforms. 
Especially as I have written one of the supported platforms. At the moment 
there is nobody in KDE who could provide you better feedback on the framework, 
please don't ignore it.

It is relatively easy to change the architecture in ways that it doesn't poll 
in each application. If it's really impossible to do this without polling: 
create a dedicated process which does the polling for all other users. It's 
easy to come up with such solutions: all it needs is taking a step back when 
getting feedback which is "no polling".

Other solutions could involve looking at what OSX provides and not 
implementing everything. E.g. on Wayland I decided to not implement 
forcePollRequest because I considered this as exposing information a Wayland 
client is not proposed to get. Platform abstracted code also means to look at 
a platform and decide what's doable and what not.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel