Re: KDE at the next Qt Contributors' Summit
Heya folks :) I just wanted to let you know that we might be able to sponsor a very limited number of people to go to the Q Contributors' Summit in Berlin. If you should be there and need sponsoring please email the board asap. Also a quick reminder: Akademy accommodation/travel sponsorship deadline for round one is April 1st. Please do not wait until the last minute. We'd like to check most requests before the deadline so that we can make final decisions quickly in the next board call on April 2nd and get back to everyone. Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher KDE Community Working Group / KDE e.V. board member http://kde.org - http://open-advice.org
Re: Review Request: Make KAuth ready for frameworks + API Changes
> On March 18, 2012, 11:04 p.m., Stephen Kelly wrote:
> > Nice, thanks and sorry for the noise, and thanks for making the branch.
>
> Dario Freddi wrote:
> Np, hope you'll be able to have a quick look at it as well, it would be
> great :)
>
> Stephen Kelly wrote:
> Mostly it looks fine.
>
> The enums are not named consistently though. Sometimes you make it name> (eg StatusDenied) and sometimes you use name> (eg HelperBusyError).
> The Qt way would be .
>
> Also, you replied that removed APIs are used nowhere. Are the enums used
> nowhere too? Is it worth keeping the backward compatibility enum names?
> Assuming your branch builds (I didn't try it) nothing else inside of kdelibs
> seems to need those enum values at least, so maybe it's not a big deal.
>
> I'm also generally impressed with how the commits are written to do one
> thing at a time, so thanks for that. I wonder if the fixes to ExecuteJob
> should be squashed though as well as porting it to KJob? It's not clear to me
> if those commits are separate because of something in an intermediate commit?
> Not very important either way. I don't mind if you change them or not.
>
> Some of the files in the unit tests appear to be old. Are they copied
> from somewhere? Could they be moved instead?
Regarding what you asked about:
* 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
vs. and which one should be preferred in case.
I guess I prefer the Qt style.
* Whether to deprecate static accessors such as static const ActionReply
SuccessReply(). I strongly favor this.
If you know that they are not much used or easily portable, I'd say go for it.
* Whether the new dependency of kcoreaddons for the sake of using KJob is
reasonable or I should go for a different alternative.
I think it's an ok dependency. I still hope that class will move to a different
framework at some point if we can find other classes that it would belong with
('base-asyncronous APIs'?). 'addons' is a forbidden name if the result of Randa
is followed.
* CMake sanity for the new dependency of kcoreaddons.
That's fine, yes.
- Stephen
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104337/#review11596
---
On March 18, 2012, 10:25 p.m., Dario Freddi wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104337/
> ---
>
> (Updated March 18, 2012, 10:25 p.m.)
>
>
> Review request for kdelibs, Kevin Ottens, David Faure, and Alexander Neundorf.
>
>
> 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. StatusInvali
Re: Review Request: Make KAuth ready for frameworks + API Changes
> On March 18, 2012, 11:04 p.m., Stephen Kelly wrote: > > Nice, thanks and sorry for the noise, and thanks for making the branch. > > Dario Freddi wrote: > Np, hope you'll be able to have a quick look at it as well, it would be > great :) Mostly it looks fine. The enums are not named consistently though. Sometimes you make it (eg StatusDenied) and sometimes you use (eg HelperBusyError). The Qt way would be . Also, you replied that removed APIs are used nowhere. Are the enums used nowhere too? Is it worth keeping the backward compatibility enum names? Assuming your branch builds (I didn't try it) nothing else inside of kdelibs seems to need those enum values at least, so maybe it's not a big deal. I'm also generally impressed with how the commits are written to do one thing at a time, so thanks for that. I wonder if the fixes to ExecuteJob should be squashed though as well as porting it to KJob? It's not clear to me if those commits are separate because of something in an intermediate commit? Not very important either way. I don't mind if you change them or not. Some of the files in the unit tests appear to be old. Are they copied from somewhere? Could they be moved instead? - Stephen --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104337/#review11596 --- On March 18, 2012, 10:25 p.m., Dario Freddi wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/104337/ > --- > > (Updated March 18, 2012, 10:25 p.m.) > > > Review request for kdelibs, Kevin Ottens, David Faure, and Alexander Neundorf. > > > 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 > vs. 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 > optimiza
Re: kdegames looking for a QML-experienced mentor
On Friday 16 March 2012 00:01:26 Stefan Majewsky wrote: > Hi, > > on kde-games-devel, we got a lot of interest in a GSoC 2012 idea > that's about porting a game to QML/Quick1. We want this on one hand as > a template for further QML-based games, but on the other hand, it > shall most importantly reveal where we have to adjust libkdegames > towards more QML-friendliness. (The ABI breakage of Qt 5.0 is the > perfect opportunity for this.) > > Unfortunately, I will not be able to mentor a project based on this > idea. I will be available for co-mentoring to handle > libkdegames-specific questions, but we need a mentor who is especially > experienced in QML/Quick1, e.g. someone from the Plasma team. Please > write to me or kde-games-devel@ if you're interested, and feel free to > forward this mail as required. > > Greetings > Stefan Hi, I've been working with QML recently, maybe I can help. I don't know much about kdegames, though... :) Aleix
Re: Re: Review Request: include KolorManager in kdegraphics
Am 16.03.12, 17:05 +0100 schrieb Alex Fiestas: On Friday, March 16, 2012 03:09:39 PM John Layt wrote: Here's my pragmatic take on it, without judging the merits of either project or their champions, and not knowing what the implications for application developers are. At the moment I believe we are only talking about KCM Modules to configure sub-systems external to KDE. There is no code I'm aware of in kdelibs, kde- runtime, or kde-workspace that actually implements anything colour management related. As such any KCM module to configure such a system belongs in extragear for now. When a distro chooses one or other of the competing systems for their distro then they can package the appropriate KCM for that system. Agreed If the time comes when one or other system is integrated directly into one of our core modules or applications and requires to be configured, then that is the time for that KCM to move into the appropriate main module. If they both stay alive and healthy then we may want to abstract the abstracted alrady asbtracted so our applications only have to care about that abstraction instead of caring about colord/oryanos/windows/mac Abstraction++ (if possible :p) In Oyranos users need few care about cross platform support. If extra bits are needed, these would certainly be welcome inside upstream Oyranos CMS. kind regards Kai-Uwe -- www.oyranos.org
Re: [GSoC] KWin colour management
Thanks for posting here. Am 18.03.12, 20:01 +0200 schrieb Casian Andrei: Hello, I am a final year undergraduate student at the Polytechnic University of Bucharest, Automation and Computers Faculty. I am interested in the "Compositor Colour Management" idea from OpenSUSE. It looks like something I would enjoy doing. Given that colour management inside open source toolkits is a very very long outstanding issue, and we are still at the beginning with that, it is unlikely that Qt5 will allow to colour manage _all_ it's widgets by default. That means, we will see only few graphics applications to do ICC colour correction themself. Consequently most other desktop applications and areas will look different on each monitor. In my opinion, the most easy path towards working end to end colour management inside KDE is to assume sRGB for all non colour aware applications and do colour correction unquestioned. That concept is worked out on OpenICC and used and checked on a daily base with CompICC. So it is no longer a experimental feature. In comparision, the concept to colour manage unaware colour content is as well common practise inside Linux and other OS printing paths. Ghostscript and likely Poppler will or do already colour convert the mass of todays /DeviceRGB colour unquestioned. They will implicitely assume that these colours to be meant as sRGB. I suggest we should follow that route for displaying inside KWin and improve colour useability on the KDE desktop. I have acceptable C / C ++ skills and lots of experience with OpenGL. I am also familiar with Qt. Regarding shaders, I wrote a couple about 2 years ago for an old project, and I still know how they work, so it would be easy for me to remember. Last GSoC I worked on an OpenGL interface for VLC, and 2 years ago I worked on capture support in Phonon. I need your guidance in order to create a decent proposal. I understand the project will involve implementing the colour management features in KWin. As the idea suggests, this would imply making KWin handle the _ICC_COLOR_OUTPUTS and _ICC_COLOR_PROFILES atoms. The idea behind these two atoms is to enable per window colour correction, which is relatively easy implemented. In a first step a window manager can be enabled with that feature. It is completely backward compatible. Graphic applications can be updated step by step to take advantage of the new ICC support by implementing the X Color Management protocol. They will profit by getting multi monitor aware very fast and power efficient colour correction with the smallest effort. Some few applications exist already, which deploy this scheme. Qt or KDE widgets can be created to share common code among such apps. Today I documented myself about colour management in general, and how it's done in Linux. I also read about ICC, Oyranos, X color management and related things. Now I'm not completely in the dark as before. I looked around in the KWin code and I found the area of interest - the compositor part, more specifically KWin::SceneOpenGL. Since shaders will be needed, it looks like some custom shaders of type KWin::ShaderManager::ColorShader would be able to do the job. Please correct me if this is wrong. But I am still unsure and I don't have an exact image in mind about what needs to be done. Clearly, more exploration is needed. I don't know what to concentrate on - looking around in KWin / Compiz code, concentrating on libXcm and the X Color Management spec, reading more about Oyranos and colour management in general? I tried the Oyranos colour management LiveCD and I saw it doing the correction magic, but unfortunately I was unable to get compiz working - with the open source drivers it didn't start because of missing glx_ext_texture_from_pixmap extension, and there were problems with the ati drivers - after installing them, the root visual was not a GL visual (or something like that), and if I tried to do some configuration with Catalyst, then X froze together with the system (nothing new for me, that's why I am sticking to the open source drivers). At least I know ICC profiles for both my monitors were found, by monitoring with QcmsEvents. Best regards, Casian kind regards Kai-Uwe -- www.oyranos.org
Re: Review Request: Make KAuth ready for frameworks + API Changes
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104337/#review11598 --- In kauth/autotests/HelperTest.cpp The comment on line 57-68 should be reworded. In general when someone is told not to touch some lines they won't. You should be clear on why the code is that way. However saying "you don't want to touch this code" is a bad thing. It gives someone permission to not look close, even when in the future their change would break things. Yes what you are doing is subtle, but that is no excuse for someone to not understand it. - Henry Miller On March 18, 2012, 10:25 p.m., Dario Freddi wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/104337/ > --- > > (Updated March 18, 2012, 10:25 p.m.) > > > Review request for kdelibs, Kevin Ottens, David Faure, and Alexander Neundorf. > > > 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 > vs. 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. > > > 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 >
[GSoC] KWin colour management
Hello, I am a final year undergraduate student at the Polytechnic University of Bucharest, Automation and Computers Faculty. I am interested in the "Compositor Colour Management" idea from OpenSUSE. It looks like something I would enjoy doing. I have acceptable C / C ++ skills and lots of experience with OpenGL. I am also familiar with Qt. Regarding shaders, I wrote a couple about 2 years ago for an old project, and I still know how they work, so it would be easy for me to remember. Last GSoC I worked on an OpenGL interface for VLC, and 2 years ago I worked on capture support in Phonon. I need your guidance in order to create a decent proposal. I understand the project will involve implementing the colour management features in KWin. As the idea suggests, this would imply making KWin handle the _ICC_COLOR_OUTPUTS and _ICC_COLOR_PROFILES atoms. Today I documented myself about colour management in general, and how it's done in Linux. I also read about ICC, Oyranos, X color management and related things. Now I'm not completely in the dark as before. I looked around in the KWin code and I found the area of interest - the compositor part, more specifically KWin::SceneOpenGL. Since shaders will be needed, it looks like some custom shaders of type KWin::ShaderManager::ColorShader would be able to do the job. Please correct me if this is wrong. But I am still unsure and I don't have an exact image in mind about what needs to be done. Clearly, more exploration is needed. I don't know what to concentrate on - looking around in KWin / Compiz code, concentrating on libXcm and the X Color Management spec, reading more about Oyranos and colour management in general? I tried the Oyranos colour management LiveCD and I saw it doing the correction magic, but unfortunately I was unable to get compiz working - with the open source drivers it didn't start because of missing glx_ext_texture_from_pixmap extension, and there were problems with the ati drivers - after installing them, the root visual was not a GL visual (or something like that), and if I tried to do some configuration with Catalyst, then X froze together with the system (nothing new for me, that's why I am sticking to the open source drivers). At least I know ICC profiles for both my monitors were found, by monitoring with QcmsEvents. Best regards, Casian
