Re: Review Request 126724: Expose callingUser in HelperSupport if available

[Dario Freddi]

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

Ship it!


As long as the additional dependency does not cause any issue (I strongly doubt 
it), it definitely makes sense to me.

- Dario Freddi


On Jan. 12, 2016, 9:36 a.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126724/
> ---
> 
> (Updated Jan. 12, 2016, 9:36 a.m.)
> 
> 
> Review request for KDE Frameworks, Dario Freddi and David Edmundson.
> 
> 
> Repository: kauth
> 
> 
> Description
> ---
> 
> The Polkit backend is able to retrieve the calling user. As this is
> a useful information for a helper the information can be exposed in
> the AuthBackend and be retrieved through the HelperSupport.
> 
> 
> Diffs
> -
> 
>   src/kauthhelpersupport.h 2828ec21aa00b7fb35dcf19db7f3869158e85b1d 
>   src/kauthhelpersupport.cpp c2a88d7cc574eb6ab092f0981b828fd4c68ba025 
>   src/AuthBackend.h c67a706dda107c9815e3c3f74c628fed6d2e4dcc 
>   src/AuthBackend.cpp ff91dd580919af9046b3f3d26f340885d54d370e 
>   src/CMakeLists.txt 1b6930d1db89f6ecc1223772b6632c57762f829f 
>   src/backends/polkit-1/Polkit1Backend.cpp 
> 78ee5bb6d97d9d83beec21e197a947dfc994b2a9 
> 
> Diff: https://git.reviewboard.kde.org/r/126724/diff/
> 
> 
> Testing
> ---
> 
> a helper with:
> ActionReply KScreenLockerAuthHelper::save(const QVariantMap )
> {
> auto user = KAuth::HelperSupport::callingUser();
> 
> QFile file(QStringLiteral("/tmp/authtest"));
> file.open(QIODevice::WriteOnly);
> file.write(user->homeDir().toUtf8());
> file.write("\n");
> file.write(user->loginName().toUtf8());
> file.write("\n");
> file.write(QByteArray::number(user->userId().nativeId()));
> file.write("\n");
> 
> return ActionReply::SuccessReply();
> }
> 
> created the file /tmp/authtest with the following content:
> 
> /home/martin
> martin
> 1000
> 
> Which matches my user.
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
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!)

[Dario Freddi]

Hi René,

just thought I'd clarify some things as the creator/former maintainer of
all this - which might also justify some of Martin's positions.

The idea behind KIdleTime is that the framework shall be a lightweight,
non-critical framework for those applications which want to know about the
idle time of the system. The only critical application relying on KIdleTime
is (as expected) the power manager (which was also where the framework came
from, if you remember). As such, we work under the following assumption:

 * We don't want/need to report the idle time precisely. We care about
timeouts and an error in the order of seconds is acceptable (here comes
Martin's argument). The reason why the API returns the idle time in msec is
just a matter of consistency with Qt's API, which always return msec as the
base unit for time.
 * If an application is relying on having a msec-accurate idle time, I have
very bad news for its developer :) It's just impossible to provide
warranties that we can be that accurate on all platforms.
 * KIdleTime strives to be as lightweight as possible. This is something
which came from the old approach used in KDE3/4 powermanagement which was
basically stressing the system just to find out how long it has been idle
(the irony)


I agree with you about the lack of documentation, and it'd be great if
something put that in a better shape. We're fine to assume that KIdleTime
will be initialised with no functional backend, because we assume that if
we can't determine if the system is idle, we assume it is always active. It
is indeed not documented, and I agree with you on that, but the approach
definitely makes sense given the assumption above. It is, on the other
hand, responsibility of applications which use the idle time as a critical
resource (aka: the power manager) to take care of this, but it was deemed
crazy to bring in such complexity for those applications which might care
only about doing stuff in a more conservative way when the system is not
idle.

Also, this applies to strange setups (remote login): it is tied to a series
of limitations and, especially in the case you mentioned, the concept of an
"idle system" is definitely ambiguous, as you are dealing with... two
different systems. And if we can't give warranties about computing, we
simply don't.

That said, I really appreciate you improving the OSX backend. Thanks!


I hope to have shed some light on this.

Best



2015-11-19 14:38 GMT+01:00 René J.V. :

> There's something else that's been bothering me since I realised it:
> KIdleTime has been written with the assumption that'll always work, and
> that whatever initialisation is required never fails. That must be why the
> return value from setupPoller() is discarded.
>
> Maybe this all holds true on Linux, where initialisation probably only
> fails if there's no valid connection to an X server or a severe
> out-of-memory condition. The former will lead to sufficient explicative
> feedback to the user, the latter, well, it'd still be nice to simply print
> a message and then exit without triggering crash reporting stuff that's
> only going to increase the system load.
>
> On OS X, there is a very valid situation in which initialisation could (or
> should) fail and that cannot be predicted from something like the absence
> of an env. variable like DISPLAY : remote login. That's a more generic
> problem that affects Qt applications in general, though.
>
> Anyway, I don't see anything in the documentation that suggests that
> applications can verify whether any of the KIdleTime features are going to
> work (= are implemented). Idle time is reported as 0 when there is no
> platform plugin (which is a valid time, not an error value), or whatever
> the platform plugin returns if it cannot determine a sensible value. The
> other, signalling features probably just fail to deliver signals if they
> are not supported. I haven't seen a warning for that in the documentation,
> so that could lead to 2 things:
>
> - either dependent software just never gets to do the (possibly important)
> things it is designed to do when an idle period ends or reaches a given
> duration.
> - or developers deduce that they have to write additional checks, possibly
> through polling to detect and handle situation in which KIdleTime fails to
> do its job ... but then why would they even use KIdleTime at all?
>
> R.
>
___
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!)

[Dario Freddi]

Given I already stepped in...

2015-11-19 10:36 GMT+01:00 René J.V. :
>
> Now it's just bad code, eh?
>
> Just for the record: no one but Apple really knows what IOKit considers being 
> idle but it clearly involves absence of user input events. That's "user 
> idle", not "system idle" (term from the KIdleTime docs!), and how long of the 
> former you need to attain the latter (or something you consider "system 
> idle") is completely up to the software to decide. Because it involves event 
> timing, this can be determined with as much precision as native events can be 
> timed (and if I'm not mistaken those are accurate enough to support a 1ms 
> resolution on OS X).
>
> I'm not going to repeat my position on polling or on how it's up to the user 
> to decide whether or not idle timeout detection is too expensive.
> As long as people here remain dead-set against anything the uses it without 
> even testing the actual implementation, then I am not going to reconsider 
> contributing to this code. Writing great software doesn't necessarily mean 
> applying all applicable principles without wiggle room (and I'd hope that's 
> about the only thing I'm dogmatic about myself :)).
>
> Apparently I might want to reconsider using QTimer, though, there might be 
> more accurate and/or less intrusive mechanisms available natively - and now 
> that I incorporated some ObjC it ought to be a lot less work to experiment 
> with those.

René, Martin was just questioning your choice of Qt::PreciseTimer. From Qt docs:

For Qt::CoarseTimer, the interval will be adjusted up to 5% to align
the timer with other timers that are expected to fire at or around the
same time. The objective is to make most timers wake up at the same
time, thereby reducing CPU wakeups and power consumption.

Which is *exactly* the purpose of KIdleTime - notifying with a relaxed
precision (because let's face it, as Martin already explained the
added precision value is completely pointless if we're talking about
**user** activity) with the minimum consumption of system resources.
And this is exactly what :CoarseTimer does. So I stand behind Martin's
comment and agree with it. It does not relate to IOKit or anything
else, but just with the purpose for which you're using QTimer in that
context. And note that people here are not dead-set without concrete
and actual reason: the new Qt5 API of QTimer was designed with these
kind of use cases in mind. The fact that (of course) you don't notice
any concrete difference might change when you scale back to a more
constrained system - and it's the purpose of frameworks to be as
efficient as possible everywhere. And most of all, there's no gain in
using PreciseTimer at all here - actually KIdleTime might even use
VeryCoarse. That's all.

In the bigger scheme: would you be happy to know that your laptop is
consuming more energy just to know more accurately when it's a good
time to suspend to save energy? :)

P.S.: On you reconsidering QTimer: the fact you might be using a
different API won't change the base problem, which you will face
anyway: having a precise timer implies consuming more resources and
having more wakeups.
___
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!)

[Dario Freddi]

2015-11-19 17:17 GMT+01:00 René J.V. <rjvber...@gmail.com>:
> On Thursday November 19 2015 15:21:10 Dario Freddi wrote:
>
>> * KIdleTime strives to be as lightweight as possible. This is something
>>which came from the old approach used in KDE3/4 powermanagement which was
> ...
>>resource (aka: the power manager) to take care of this, but it was deemed
>>crazy to bring in such complexity for those applications which might care
>
> That kind of application simply doesn't make sense on operating systems that 
> already have their own, built-in power management...
>
> OTOH, I wouldn't be amazed if it is non-trivial to guarantee good and 
> reliable timing accuracy on an OS like Linux: that would fit in with the 
> experience I have with its use in time-critical applications (where it always 
> required realtime extensions to the kernel).
> But I continue the think that a simple framework like this can very well 
> attempt to provide the best accuracy/cost compromise that the host allows, 
> esp. if that doesn't mean adding crazy complexity. As it happens, OS X 
> returns the "idle time" in *nano* seconds; do not think for a second (pun 
> intended) that it would do that if the underlying measurement didn't have 
> that kind of accuracy. I think that makes it safe to say that my current 
> implementation indeed provides just short of a 1ms accuracy, with a 
> CoarseTimer and an adaptive polling interval that spends most of the timeout 
> duration waiting for the timer to fire.
>
> It's quite possible that's enough, and that there will never be any reason 
> (demand) to export the interval control I drafted. But consider this: KF5 
> frameworks are young (despite the almost crazy progression of the release 
> number, which for me is a telltale sign of immaturity). They are also hardly 
> (nor have they been) used beyond Linux, and in practice not at all on OS X. 
> Who knows what uses any framework might be considered for that wasn't really 
> part of its original mission statement? If that's always going to elicit a 
> rejecting attitude, I'll be better off going back to making the minimum 
> modifications required to make things work for MacPorts, and only request 
> inclusion if it turns out maintaining those changes requires too much 
> continuous effort.

Again - this is not against IOKit or what Apple does, but your usage
of QTimer in your code. RRs are meant for constructive feedback, and
everyone here is striving to keep a positive attitude and explain the
reasons why such a comment has been made (speaking of which, thanks
Boudhayan for the insightful message). I really hope you will
reconsider this and accept the feedback, it would be really sad to see
MacPorts differ from upstream. As Martin said before, we're here to
help and keep code consistent, there's no interest in giving you this
kind of feedback just for the sake of it. KIdleTime is a framework
with a purpose and some requirements, if you want to build something
which can cover time-critical applications, it definitely does not
belong there.

>
> As to use over a remote, non-X11 connection: applications should not attempt 
> to determine idle time in that case. They shouldn't receive return values 
> that suggest 0 idle time, they should receive an error that tells them 
> they're out of bounds. If Qt provided a way to raise an error to the user 
> (and force the app to exit) without provoking a crash (abort), I'd use that, 
> but I'm not aware of any such facility. As it is, the OS X implementation 
> will probably signal the actual idle time of whomever is logged in locally ...
>
> R.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 113851: Unbreak kauth-policy-gen

[Dario Freddi]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113851/#review43705
---

Ship it!


Ship It!

- Dario Freddi


On Nov. 15, 2013, 8:38 a.m., Aurélien Gâteau wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/113851/
 ---
 
 (Updated Nov. 15, 2013, 8:38 a.m.)
 
 
 Review request for KDE Frameworks and Dario Freddi.
 
 
 Repository: kdelibs
 
 
 Description
 ---
 
 This is a two-commit patch, it fixes a build failure in 
 kde-workspace/kcontrol/dateandtime.
 
 
 1. make policy-gen accept a second argument pointing to the output file
 
 2. Unbreak call to kauth-policy-gen
 
 Uses the new kauth-policy-gen syntax for extra safety (no empty output file
 gets created in case of failure)
 
 Note: I haven't tested the Mac part of the code. Would be awesome if someone 
 could give it a try.
 
 
 Diffs
 -
 
   tier2/kauth/KAuthConfig.cmake.in 67eb7de 
   tier2/kauth/cmake/KAuthMacros.cmake 1ebc889 
   tier2/kauth/src/CMakeLists.txt 68c7c37 
   tier2/kauth/src/policy-gen/policy-gen.cpp b00e09f 
 
 Diff: http://git.reviewboard.kde.org/r/113851/diff/
 
 
 Testing
 ---
 
 Still builds, kcmclock_actions.policy is correctly generated in 
 kde-workspace/kcontrol/dateandtime
 
 
 Thanks,
 
 Aurélien Gâteau
 


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

Re: Review Request 113851: Unbreak kauth-policy-gen

[Dario Freddi]

 On Nov. 15, 2013, 8:38 a.m., Commit Hook wrote:
  This review has been submitted with commit 
  00e39e1d2a8372c991e24383d7c45ea393522ca8 by Aurélien Gâteau to branch 
  frameworks.
 
 Aurélien Gâteau wrote:
 Decided to push it without a ship it: it fixes the build of 
 kde-workspace on build.kde.org and a few people looked at it without being 
 horrified.

Not a big deal, the patch wasn't really intrusive. OTOH, 24hrs is still a 
decent reaction time :)


- Dario


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113851/#review43702
---


On Nov. 15, 2013, 8:38 a.m., Aurélien Gâteau wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/113851/
 ---
 
 (Updated Nov. 15, 2013, 8:38 a.m.)
 
 
 Review request for KDE Frameworks and Dario Freddi.
 
 
 Repository: kdelibs
 
 
 Description
 ---
 
 This is a two-commit patch, it fixes a build failure in 
 kde-workspace/kcontrol/dateandtime.
 
 
 1. make policy-gen accept a second argument pointing to the output file
 
 2. Unbreak call to kauth-policy-gen
 
 Uses the new kauth-policy-gen syntax for extra safety (no empty output file
 gets created in case of failure)
 
 Note: I haven't tested the Mac part of the code. Would be awesome if someone 
 could give it a try.
 
 
 Diffs
 -
 
   tier2/kauth/KAuthConfig.cmake.in 67eb7de 
   tier2/kauth/cmake/KAuthMacros.cmake 1ebc889 
   tier2/kauth/src/CMakeLists.txt 68c7c37 
   tier2/kauth/src/policy-gen/policy-gen.cpp b00e09f 
 
 Diff: http://git.reviewboard.kde.org/r/113851/diff/
 
 
 Testing
 ---
 
 Still builds, kcmclock_actions.policy is correctly generated in 
 kde-workspace/kcontrol/dateandtime
 
 
 Thanks,
 
 Aurélien Gâteau
 


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

Re: Notifications-future, a recap

[Dario Freddi]

2012/9/21 Aaron J. Seigo ase...@kde.org:
 if the new can be achieved by extending or building on galago, that would
 seem to me to be a much better thing.

 and no, galago is not perfect. it's not even great, but it is passable and
 widely used and that gives it a lot of value.

 if it turns out that we can not indeed achieve truly useful things without
 creating something completely new, we'll still need to support galago
 notifications in Plasma Workspaces, and we'll still want a bridge to galago so
 we don't lose integration with other workspaces (otherwise our app devs and
 users will, rightfully, complain)

Exactly - and just to complete the story, I have been there before
with inhibition - although KDE now uses its own standard, it still
remains 100% back and forth compatible with fd.o's one. So I don't
know where it came up that I planned to drop the existing standard,
but (especially knowing where I come from) I never thought about it
for a second.

Aaron got it perfectly right, so I guess we can cut this particular
part of the discussion here since we're debating over nothing, and
everyone is saying the same thing.

 so ... what are the things that can not be achieved by building on top of
 galago?

 GNOME3 notifications are quite good, implementing at least one concept long
 pursued by Notmart's vision (being able to specify which notifications
 should be kept and which notifications are irrelevant). To do this they had
 least expand galago spec.

 key word: expand.

this ^. And (at least try to) upstream.


 --
 Aaron Seigo

 ___
 Plasma-devel mailing list
 plasma-de...@kde.org
 https://mail.kde.org/mailman/listinfo/plasma-devel

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

Re: Notifications-future, a recap

[Dario Freddi]

2012/9/21 Mark mark...@gmail.com:
 On Tue, Sep 18, 2012 at 12:17 AM, Dario Freddi drf54...@gmail.com wrote:
 (putting back plasma-devel on CC, since the discussion is quite relevant)

 2012/9/17 Sune Vuorela nos...@vuorela.dk:
 I know Sune already had some plans for the notification stack and I
 think that's one of the best times for discussing what's going to

 yep. the plan is
 1) write a small library wrapping the org.freedesktop.notification api
wrap growl on mac

 OT: you don't want to wrap growl but probably the new native
 notification system.

wrap QSystemTrayIcon on windows
 2) do something similar for audio notifications
 3) retrofit knotification on top of those

 and the more I have investigated, 1) should actually be put into Qt and
 QPA.
 That should also make it possible for e.g. webkit to use it to show web
 notifications.
 Unfortunately, I'm currently a bit busy with stuff :/

 My personal idea is to have a new (tier1) framework consisting of a
 way for building handlers, a client API and a server API (so that the

 Really? I_think we should get rid of a daemon and just let the workspace
 shell handle it.

 It really depends on what you want to achieve. If your goal is just
 cleaning up the API and implementing the existing standard it might
 work out, but for sure it won't just cut it for what I proposed, where
 we need a centralized logic for dispatching, grouping and more. As
 Marco also said (framework wasn't CC'ed tho), the applet is already
 gearing towards being a dull observer.

 I have a hard time figuring out why the above quite simple steps don't
 solve the problems you're specifying (and even ensures that you keep all
 existing applications working with their notifications)

 Well :D. There is no way you can group notification, no way you can
 tie them to activities, no way you can dispatch notifications to
 different handlers than the workspace, and more. So I guess it's
 rather safe to assume that the current design just won't cut it, and
 as I already said applications will still be able to work with the
 existing API, they just won't be able to expose the full experience -
 and in some cases where they just shoot out a transient bubble, they
 won't even notice the change.

 snip

 I'm not quite sure if i agree with you there. The following is all
 based on assumptions!

You missed the point - the discussion was not on the API as I said,
and I'll repeat for the 1 billionth time that the current API will
still work for the majority of cases. The discussion was on the
structure of the internal system, which at the moment doesn't allow
any of the features listed above to be exposed, via any possible kind
of API.

When I referred to they just won't be able to expose the full
experience I was referring to that small percentage of applications
which, for example, belong to an activity but need to stream an event
which belongs to a different one, such as the contact list example I
put in my blogpost. But the API is there for staying.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Notifications-future, a recap

[Dario Freddi]

2012/9/20 Sune Vuorela nos...@vuorela.dk:
 On 2012-09-17, Dario Freddi drf54...@gmail.com wrote:
 It really depends on what you want to achieve. If your goal is just
 cleaning up the API and implementing the existing standard it might
 work out, but for sure it won't just cut it for what I proposed, where

 Why won't the existing (as in the fdo/galago spec) api cut it to ensure
 we also play well with others (in both directions) ?

Wait. Noone ever said we wouldn't be compatible with the existing spec
back and forth, quite the opposite. I just said I'd try to push our
changes upstream, this doesn't mean we wouldn't be compatible with
fdo, it would be a suicide. The current API simply WON'T ALLOW
applications with specific requirements to take advantage of a more
fine-grained system. More below.

 Really. All I read is complexity for teh sake of complexity, trying
 to build walled gardens for the sake of building walled gardens and
 complicating deployment for the sake of complicating deployment.
 And I don't think that's neither modern, slick nor futureproof.

I am sorry, but no. If you read my second post it is blatant clear
we're lagging behind every possible modern concept of notifications.
Example: has Akonadi or any other data-intensive application ever
failed on you? It does to me quite often, and I get 30 error spam
bubbles my system simply can't handle and drive me mad every time. And
what about losing track of incoming mails/messages? Thank god Kubuntu
kind of implements support for persistent notifications, otherwise I'd
lose every single time people ping me on IRC.

If we want to pretend what we have is already enough, we can live in
our own small world. But looking outside of our bubble should tell us
something, and making us realize we have to try to walk a step
forward. Complexity in the server code leads to simplicity to the user
and to developers - most of the features I have disclosed won't be
exposed through the API - as I explained, most of the grouping can be
done with the current means we have. On the client (applet) side,
everything would be much easier since the applet would just receive a
model. It really can't get simpler than that.

A more complex API will be provided to those application which have
specific needs, such as contact list. Your average (80%) application
will just benefit from SC and won't even notice. You don't want to
make your application a handler? Fine, still works. You don't need to
associate a specific event to an activity? Fine, still works, and
moreover the API will figure this out for you. I really cannot see how
this would get more complex to users and developers. Of course it is
more complicated than what we have now INTERNALLY, but again you
should look at the benefits.

If the majority doesn't want this, I won't be the one pushing it, but
stating that such a change isn't a step towards being more modern is
willingfully ignoring everything outside KDE - I didn't write 3 blog
posts for anything, and my first two ones were exactly aimed at
answering concerns like yours. Seriously, the only new thing in that
concept, in complete honesty, is the activity integration - everything
else can be found in any modern interface, be it phone, desktop or
web.


 /Sune

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

Re: Notifications-future, a recap

[Dario Freddi]

(readded frameworks, the topic ping-pongs)

2012/9/18 Aaron J. Seigo ase...@kde.org:
 On Monday, September 17, 2012 20:40:33 Dario Freddi wrote:
 it's pretty much on the board :) just that 90% of this will happen in
 the background (server), whereas handlers will just take care of
 showing a model and a set of events. The aim is to make the client API
 as simple as possible and have a fatter server.

 is the goal of getting rid of the notifications server as discussed at the
 Frameworks meetings in Randa off the table then?

Personally, I don't care about who is gonna be the server - and this
is also why I started the discussion. The ideas are:

1. A separate daemon, close to what we have now
2. An existing component behaving as a server.

Consider that when I am talking about a server it actually means a
component implementing a DBus interface. I admit that my POV has
changed after 1 year and a lot of research, since I strongly believe
the client/visualization and server/dispatcher must be de-paired,
otherwise we wouldn't be able to make applications act as handlers.
But at the end of the day, we just need something implementing a DBus
interface. So I don't know - I kind of like the idea of having a
separate component, but even if it was a NotificationServer::init()
inside plasma-* it would still be more than enough.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Notifications-future, a recap

[Dario Freddi]

Hello everyone,

you might or might not know by now of my intention of revamping the
way we deal with notifications in KDE as I explained in my last blog
post 
http://drfav.wordpress.com/2012/09/17/the-notifications-issue-part-3-the-possible-solution/
. I have been talking about this with many of you already but I think
it's time to see what's the overall reception to the idea and what's
coming up for the actual job.

I know Sune already had some plans for the notification stack and I
think that's one of the best times for discussing what's going to
happen. I seriously doubt we can rely on the old KNotification code,
and probably we'll have to change some things during the way, but I am
rather confident we can keep a sort of source compatibility with the
old API (although I think it's not desirable since the way
applications interact with notifications is a major point in this
potential change).

My personal idea is to have a new (tier1) framework consisting of a
way for building handlers, a client API and a server API (so that the
server can be put into runtime rather easily). Marco is already doing
some work on the applet to make it ready to adapt to this new
concept. Ideally, the applet will just receive a model of the existing
backlog + additional messages for transient notifications and newly
spawned persistent ones.

What do you think?
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Notifications-future, a recap

[Dario Freddi]

2012/9/17 David Faure fa...@kde.org:
 On Monday 17 September 2012 17:49:23 Dario Freddi wrote:
 a server API (so that the
 server can be put into runtime rather easily)

 Just a note on that: the plan with KDE Frameworks, is that there will be no
 more libs/runtime separation. A framework will come with any runtime stuff it
 might need, to make things more modular.

 Of course if you mean 'there could be multiple servers which handle
 visualization' then that's different, we don't want a framework to ship all
 GUIs and therefore end up with too many dependencies. E.g. the kjob framework
 doesn't ship the plasma visualization stuff :-)

 But mandatory runtime requirements such as daemons and stuff, should be part 
 of
 the framework, in the future.

Definitely, sorry for the confusion - the server (handling the
grouping/dispatching logic) WILL be shipped with the framework,
whereas an API for building handlers (applications, applet) will be
provided.

TBH I don't see many benefits in allowing multiple servers at this
stage - maybe in a bright future, where this could become a standard,
it would make sense to have just a way for creating a server. For now
I'd stick to the plan of shipping the entire solution :)


 --
 David Faure, fa...@kde.org, http://www.davidfaure.fr
 Working on KDE, in particular KDE Frameworks 5

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

Re: dependency issue (KService* - KPluginLoader - KLocale)

[Dario Freddi]

2012/8/31 Kevin Ottens er...@kde.org:
 Hello,

 On Wednesday 29 August 2012 23:53:32 David Faure wrote:
 KService, KServiceTypeTrader and KMimeTypeTrader (all of which I moved to a
 new kservice framework), all have a template method (createInstance*)
 which uses KPluginLoader to load the plugin described by the given service,
 or trader query.

 Which gives two, well, three solutions:

 1) Moving KPluginLoader to the kservice framework as well.

 2) Moving these template methods out, e.g. into KPluginLoader itself, making
 kpluginloader one tier above kservice. the app code change looks like this:
 -  Client *client = service-createInstanceClient(this, ...)
 + Client *client = KPluginLoader::createInstanceClient(service, this, ...)

 3) Making kservice *and* kpluginloader tier1 libs, and having the template
 methods to integrate the two somewhere else, above.

 I definitely vote for 1. I don't see much use for KPluginLoader outside of a
 I use kservice context. With that in mind, 2 and 3 are far less tempting.

Add my vote in as well.

 Hmm another idea:
 Solution 1b: move KPluginLoader to kservice, but solve the i18n dependency
 by having some singleton inside KPluginLoader emit a signal when loading a
 plugin, and some singleton in KLocale picks that up and loads the catalog.
 Too hacky? (ugly singletons, and exposing some internal object publically
 for the benefit of one other framework)... It would work, though, I
 guess...

 If we can make it work that's worth a try despite the Qt translation system
 being inferior. I can easily imagine cases of plugins with no strings of
 their own. In such a case forcibly bringing klocale as a dependency is a bit
 unfortunate if it can be avoided.

To be honest I don't really agree here - I don't see a real benefit in
avoiding the KLocale dependency and I think it makes sense to have the
plugin system depend on it - even though I reckon that might be
undesirable in case a plugin bears no strings. Also, I think tier2
fits quite well for kservice. I think the original solution by David
is already good enough to go. (my 2c)


 Regards.
 --
 Kévin Ottens, http://ervin.ipsquad.net

 KDAB - proud patron of KDE, http://www.kdab.com
 ___
 Kde-frameworks-devel mailing list
 Kde-frameworks-devel@kde.org
 https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

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

Re: KF5 Volunteer day 2 next week?

[Dario Freddi]

Il 20 marzo 2012 17:53, Kevin Ottens er...@kde.org ha scritto:
 On Sunday 18 March 2012 20:11:20 Kevin Ottens wrote:
 So, doable? Any volunteers (aha) to drive the volunteer day? :-)

 Dario indicated to me he could be available part of the afternoon, that's nice
 but likely not enough.

Screw this GMail, it was meant to be a public answer... Quoting myself:

If in the reasonably late afternoon I might be there. Though, I might
be quite jetlagged as well so I'd appreciate a backup in case I
collapse without realizing it.

However, my plane lands at something like 4pm CET, so I could probably
be available 30 mins after that time, hoping jetlag won't kill me. So
in the best case I'd still need a backup before that.


 Anyone else?

 Regards.
 --
 Kévin Ottens, http://ervin.ipsquad.net

 KDAB - proud patron of KDE, http://www.kdab.com

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

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

Fwd: Review Request: Make KAuth ready for frameworks + API Changes

[Dario Freddi]

For interested people (hopefully many)

-- Messaggio inoltrato --
Da: Dario Freddi d...@kde.org
Date: 18 marzo 2012 23:25
Oggetto: Review Request: Make KAuth ready for frameworks + API Changes
A: Kevin Ottens er...@kde.org, David Faure fa...@kde.org, Alexander
Neundorf neund...@kde.org
Cc: Dario Freddi d...@kde.org, kdelibs kde-core-de...@kde.org, Dario
Freddi d...@kde.org, kdelibs kde-core-de...@kde.org


   This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104337/
  Review request for kdelibs, Kevin Ottens, David Faure, and Alexander
Neundorf.
By Dario Freddi.
Description

Preamble - sorry for having to name-call people but apparently we
still don't have a frameworks way for reviewing code (which sucks).
And sorry for the long summary, but it's worth reading. However.

This huge patchsets brings KAuth in the marvelous world of Frameworks.
If you dislike ReviewBoard's way of displaying diffs or simply want to
see a commit list, please refer to the URL in Branch.

First of all, I pulled in a dependency on KJob after a chat with
Kevin. This makes KAuth tier2, but shouldn't be a big issue.

Then there's the hard part: source compatibility is reasonably broken
here. The changes I had to do were mostly for the sake of revamping
the internal workflow of the library. The main problem KAuth had was
the fact it was completely synchronous, leading to a multitude of
problems. After these changes it's fully asynchronous instead (reason
for pulling in KJob), the API was simplified, and some unused features
like multiple action execution have been removed.

The main changes at a glance:

 * Some renaming to the enums
 * Moving Action  ActionReply to be implicitly shared
 * Removing ActionWatcher (now useless due to the new semantics of execute
 * Removing some useless APIs from Action, namely executeActions,
execute(helper)
 * execute() now returns a KJob
 * helperID() - helperId()
 * Static action replies are now static accessors returning a new
instance. This was a complete mistake in the first place, but it's
still there with a different semantic to ease porting. The main use
case for changing this is a failure to handle implicitly shared
classes in multithreaded environments with that approach.

Of course, while it would be awesome to have all the code reviewed, I
understand it's a very big change so I'd like at least some feedback
on the following points:

 * General sanity of the new API
 * Consistency of the enums. StatusInvalid vs. ExecuteMode vs.
AuthorizationDeniedError. While the semantic seems correct to me, I'd
like to have some feedback on whether consistency is valuable in the
ordering of typevalue vs. valuetype and which one should be
preferred in case.
 * Whether to deprecate static accessors such as static const
ActionReply SuccessReply(). I strongly favor this.
 * Whether the new dependency of kcoreaddons for the sake of using
KJob is reasonable or I should go for a different alternative.
 * CMake sanity for the new dependency of kcoreaddons.

The code is pretty much unit-tested and it should have a decent
coverage, even if I had no way to check this. For unit tests, I had to
create a fake authorization backend for testing purposes, whereas I
managed to reuse the dbus backend for helper communication, so that I
could even test that. For running the helper and the client in the
same process, in the unit test I am resorting to making the dbus
service of the helper live in a separate thread, to prevent
asynchronous DBus calls from failing due to QDBus' local-loop
optimization. The test is also run on the session bus.

  Testing

New unit tests pass 100%

  Diffs

   - staging/kauth/CMakeLists.txt (PRE-CREATION)
   - staging/kauth/autotests/BackendsManager.h (PRE-CREATION)
   - staging/kauth/autotests/BackendsManager.cpp (PRE-CREATION)
   - staging/kauth/autotests/CMakeLists.txt (PRE-CREATION)
   - staging/kauth/autotests/HelperTest.cpp (PRE-CREATION)
   - staging/kauth/autotests/SetupActionTest.cpp (PRE-CREATION)
   - staging/kauth/autotests/TestBackend.h (PRE-CREATION)
   - staging/kauth/autotests/TestBackend.cpp (PRE-CREATION)
   - staging/kauth/autotests/TestHelper.h (PRE-CREATION)
   - staging/kauth/autotests/TestHelper.cpp (PRE-CREATION)
   - staging/kauth/src/AuthBackend.h (PRE-CREATION)
   - staging/kauth/src/CMakeLists.txt (PRE-CREATION)
   - staging/kauth/src/HelperProxy.h (PRE-CREATION)
   - staging/kauth/src/backends/dbus/DBusHelperProxy.h (PRE-CREATION)
   - staging/kauth/src/backends/dbus/DBusHelperProxy.cpp (PRE-CREATION)
   - staging/kauth/src/backends/dbus/org.kde.auth.xml (PRE-CREATION)
   - staging/kauth/src/backends/fake/FakeBackend.cpp (PRE-CREATION)
   - staging/kauth/src/backends/fakehelper/FakeHelperProxy.h (PRE-CREATION)
   - staging/kauth/src/backends/fakehelper/FakeHelperProxy.cpp
   (PRE-CREATION)
   - staging/kauth/src/backends/mac/AuthServicesBackend.cpp (PRE-CREATION)
   - staging/kauth/src/backends/policykit

Re: Monitoring autotest coverage in frameworks

[Dario Freddi]

Hi,

2012/3/1 Frank Reininghaus frank7...@googlemail.com:
 Hi,

 Am 1. März 2012 00:44 schrieb Dario Freddi:
 I was wondering if we already had a way to generate reports on
 autotests coverage using lcov/gcov in frameworks. Looking at our cmake
 infrastructure, I spotted a build mode Profile which should
 apparently set the correct compiler flags (but actually, at least for
 me, it didn't work), I didn't go as far as seeing if it also forces
 every library to build static. Instead, there seems to be no mention
 of a lcov target.

 Question time: is anybody already working on this? I think it's quite
 important for us to have such a thing, and I'd be happy to provide
 patches for this to happen (would be cool if Alex or any other
 buildsystem gatekeeper gave a word about how this should be done/where
 should it go).

 it seems that measuring test coverage does work in kdelibs 4.x, at
 least there are results submitted daily to CDash:

 http://my.cdash.org/index.php?project=kdelibsdate=2012-03-01

 AFAIK, the results which CTest gathers during the tests using gcov are
 written to an XML file (which is then submitted to CDash if you ran
 the tests using, e.g., 'make Experimental').

This is *awesome* news indeed, I didn't know CDash did that. Do you
also know if CDash is capable of generating a report which takes into
account coverage of directories as well a-la-lcov? Something like

solid/   23%
solid/test.cpp   34%
etc...

If we had that, problem solved 100%. With the current interface is
just a little confusing to find out the global coverage of a specific
project/subdirectory (this could be quite important for frameworks)


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

Monitoring autotest coverage in frameworks

[Dario Freddi]

Hey guys,

I was wondering if we already had a way to generate reports on
autotests coverage using lcov/gcov in frameworks. Looking at our cmake
infrastructure, I spotted a build mode Profile which should
apparently set the correct compiler flags (but actually, at least for
me, it didn't work), I didn't go as far as seeing if it also forces
every library to build static. Instead, there seems to be no mention
of a lcov target.

Question time: is anybody already working on this? I think it's quite
important for us to have such a thing, and I'd be happy to provide
patches for this to happen (would be cool if Alex or any other
buildsystem gatekeeper gave a word about how this should be done/where
should it go).
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Please avoid noisy merge commits in frameworks

[Dario Freddi]

2012/2/19 Stephen Kelly steve...@gmail.com:
 Stephen Kelly wrote:


 Hi there,

 I was reviewing the changes in the frameworks branch from yesterday.
 Something I noticed was that there are a lot of merge commits that don't
 need to exist.

 Ugh. Yet more of this just appeared... Recent history in the frameworks
 branch looks far more complex than it is and is harder to follow.

 There are too many people unaware that they're doing it maybe...

What about having a small volunteer day in which we draft some
policies for git commits and eventually implement some hooks to avoid
these (and other) things happening?


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

Re: Please avoid noisy merge commits in frameworks

[Dario Freddi]

2012/2/19 Ben Cooksley bcooks...@kde.org:

 First, our hooks are in python - so any changes would need to be in Python
 as well.

I can speak a bit of python, would be a nice way for learning more :)


 Second, there is a legitimate use for pushing merge commits - namely
 integrating a seperate remote branch. I have no idea if it would be possible
 to determine if this is a local only branch merge or not.

Indeed merge commits are useful in that case - although there's a
different pattern in the ones Stephen was complaining about, since you
always merge master onto (remote) master in such commits which never
makes sense. And besides that, as many on this list already know, I
advocated multiple times for crystal clear git policies across at
least all KDE core repositories - this is just one of the issues to
tackle.


 Third, please ensure that you disable the previously mentioned auto-rebase
 on git pull if you are merging a reemote branch, otherwise you will
 duplicate many commits, in addition to triggering the hooks for all those
 commits (which will not happen if you just merge). The hooks could even
 decide to reject your push, as it will contain too many new commits.

Also interactive rebasing can help here, but at this point a
fetch+rebase -i is actually a better option.



 Thanks,

 Steve.



 Regards,
 Ben Cooksley
 KDE Sysadmin.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: i18n in Frameworks, the lightweight version

[Dario Freddi]

2011/12/6 George Kiagiadakis kiagiadakis.geo...@gmail.com:
 On Tue, Dec 6, 2011 at 10:54 AM, Aaron J. Seigo ase...@kde.org wrote:
 On Monday, December 5, 2011 12:23:30 Chusslove Illich wrote:
 Regarding yesterday's chat, to shortly (really!) sum up my stance on i18n.

 1) I see no point at striving for single translation system for apps based
 on Qt and Qt plus KDE Frameworks. Qt should keep the tr()/Linguist system,
 and Frameworks should continue to offer the i18n()/PO system.

 2) The application developer would choose which translation system to use
 based on whatever criteria, like choosing between any other two libraries
 covering the same need. We could put up an article describing the relative
 advantages of the two systems.

 that is precisely the problem. nobody wants to choose between two translation
 systems. nobody wants to have to figure out what libraryFoo uses for
 translation (that one uses tr, this one use i18n, this other one also uses
 i18n, that one uses tr ..) and try to align their app with that.

 on the device side, i certainly do not want the overhead of two translation
 systems.

 there is simply no way to justify the current state of affairs, other than
 it's how it's always been done, it's already implemented.


 I agree with Aaron here. I probably have missed previous discussions
 on this topic, but seeing this email now I'm full of questions. Why
 should we keep both systems? Considering that we go for your plan, who
 is going to use i18n()? It will probably just die... From my point of
 view they do the same job, so why should I depend on an extra library
 when I can just use tr()?

There is more: some of the tier1 libraries might even become Qt Addons
at some stages and move to qt-project. In that case we would probably
have to switch the translation system (buildsystem seems not to be a
concern from last Contributors day). In general, one of the efforts of
frameworks is getting closer to Qt, and I think i18n is still a major
issue in this regard.

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