Re: Re: [GSoC] KWin colour management
Am 21.03.12, 20:34 +0100 schrieb Martin Gräßlin: I think you do not know how KWin's rendering works. In a simplistic way: a window is rendered to the screen through a shader. At runtime KWin decides which shader to be used. As by that there is always only one active shader, so to have color correction it has to be added to all shaders which render windows/textures/colors. Thanks for the description. This is different to any experience you might have from Compiz 0.8. There the screen was not rendered with shaders but plugins could use shaders. Do you have any references showing that it is impossible to add color correction to Qt during the lifecycle of Qt 5? I'm sorry, but I don't base technical decisions on my feeling says. That would mean colour management appears earliest inside Qt 6. But it is at the moment not clear if that happens at all. Any proof for these bold statements? Anything from Qt where I can see that this is the case (also for Wayland)? Remember nobody wants to develop for X anymore ;-) As we discuss a equivalent of colour management in KWin, we talk about default colour management of all displayed Qt widgets. That is a high goal and likely coming with some API changes. Such changes need quite some preparation. What signs are visible that with the first release of Qt 5 will have full CM? Even if people would put CM now high on the Qt develpers or similar agendas, CM will likely not get included soon to be ready for the first Qt 5 release. Then logically the next feature window is Qt 6. On the other hand, Xorg architect Jim Getty told me, that compositors are the right places for colour correction. that might be quite true, but not if apps want to opt-out. The X Color Management spec allows for opt-out inside compositors. I think to demonstrated you that on osC. and I think I explained to you why I don't think that's a good idea for KWin :-) kind regards Kai-Uwe
Re: [GSoC] KWin colour management
Am 21.03.12, 22:25 +0100 schrieb Thomas Zander: Color management in Qt is a bit of a weird statement; first of all, support is already possible as Krita proves. Second, I doubt that 94% of the widgets Krita does colour management inside Krita. IMO that does not belong to a discussion about Qt itself. actually need color correction of the type that kwin could provide. Who cares that their text edits and their buttons are color correct? Many people care about that and even more are positively affected. Its only for canvas-like widgets that this is relevant, and apps have that option already by linking to LCMS. It is relevant to the whole desktop experience. What people like to see are consistent colours on displays and then on prints. And they want to show the same colours to their friends remotely. At the moment KDE looks on each monitor different. No one can predict on what colours come over the internet, being it web sites, email clients or application toolbars. That's not so good. So, KWin support would just be a shortcut. A one-stop solution to make all apps suddenly get sunglasses on. It certainly is not a 'proper' solution, its a shortcut. So please keep treating it as such. Yes. There needs work on many layers. All have to play their role. And I see default colour management in KWin as a big step in a good direction. When people talk about the toolkit adding support its more about convenience APIs. Think a QPainter method to set a color transform to do correction on following draws. Such a API is specialy tailored to a certain audience. Photographers come to mind. And I am all for it, but they are only part of the KDE user base. When people want support in the toolkit, they want the color selector widget, the print preview widget etc, that come with Qt to natively use the monitor profile. Last, they want the printing to take color management into account. Good example. The print of a screenshot should look like on screen. So the first thing is to make screens look consistent. Then printing has a chance to match that. All of those are possible and likely even welcomed in Qt. The only thing is that someone has to actually do it. So saying that it won't happen in Qt6 is a self-fulfilling wish, and I feel its not very fair to plant that doubt in peoples minds. Agreed with you. And luckily no one says it can not happen for Qt 6. What would KWin people suggest how and where to place this feature near KWin? Well the question is whether such a feature is needed at all. I would say: * either correct the whole screen * or let the windows handle it Now it becomes quite simple: there's an app doing color correction itself. In that case we can safely assume that the user wants the app to take care - compositor does no longer color correct the screen. There is no application taking care of it: compositor renders the whole screen. That could be a start. kind regards Kai-Uwe Behrmann -- www.oyranos.org
Re: Re: Re: [GSoC] KWin colour management
Am 22.03.12, 07:34 +0100 schrieb Martin Gräßlin: On Thursday 22 March 2012 07:02:27 Kai-Uwe Behrmann wrote: Am 21.03.12, 20:34 +0100 schrieb Martin Gräßlin: Do you have any references showing that it is impossible to add color correction to Qt during the lifecycle of Qt 5? I'm sorry, but I don't base technical decisions on my feeling says. That would mean colour management appears earliest inside Qt 6. But it is at the moment not clear if that happens at all. Any proof for these bold statements? Anything from Qt where I can see that this is the case (also for Wayland)? Remember nobody wants to develop for X anymore ;-) As we discuss a equivalent of colour management in KWin, we talk about default colour management of all displayed Qt widgets. That is a high goal and likely coming with some API changes. Such changes need quite some preparation. What signs are visible that with the first release of Qt 5 will have full CM? Even if people would put CM now high on the Qt develpers or similar agendas, CM will likely not get included soon to be ready for the first Qt 5 release. Then logically the next feature window is Qt 6. Sorry but I don't follow that logic. Just because it won't make it into 5.0 (which is impossible) does not mean that it won't enter any 5.x release. And that's what I asked for: is there any reference stating that it won't be possible to add CM to Qt in the lifetime of Qt 5? Here my thoughts, why I think CM in Qt is not easily introduced during a minor Qt 5 release. [Preparation of CM for Qt 6 is a different story.] Lets hypothetical assume some effort is initiated to bring CM to Qt and that happens during Qt 5 life time. The new design says by default all content is considered sRGB, which is by itself reasonable. However existing applications will initially not know about that changed convention. There is currently no API to know that. They will play freestyle as before and colour correct to monitor space without knowing how to tell anything to Qt. These old style apps will colour correct to monitor and Qt will colour correct from sRGB to monitor as Qt does not better know. That is called double colour correction and would be a real design bug. The conflict is solveable by making the new drawing API incompatible with the old one, e.g. requiring a colour space argument. An other way is verbally declaring sRGB as the default colour space in Qt, which would be a major API change as well and only reasonable possible during major version change. Both is not easy before Qt 5. After the fist Qt 5 release a new drawing API could theoretically be introduced in parallel to the old one. But old Qt apps would then look inconsistent compared to ones using the new API. Not sure if that transition path would be a good option regarding code complexity. IMO best would be to wait for Qt 6 and then switch completely. kind regards Kai-Uwe Behrmann -- www.oyranos.org
Re: Need suggestion on how to fix the common crash in plasma-desktop (kdelibs related)
Em Wednesday 21 March 2012, Lamarque V. Souza escreveu:
Em Wednesday 21 March 2012, Aaron J. Seigo escreveu:
On Tuesday, March 20, 2012 22:31:57 Lamarque V. Souza wrote:
There is a crash in WeatherEngine (kde-workspace) triggered by the
fact
that Plasma::DataEngineManager::self() (kdelib) is invalid when
plasma-{desktop,device} are exiting. WeatherEngine::~WeatherEngine()
calls WeatherEngine::unloadIons(), which tries to use the invalid
Plasma::DataEngineManager::self(). The crash only happens if there is
this happens only when the application uncleanly exits. if you notice in
the bug reports you linked to there was a problem elsewhere (e.g. an
xioerror, an uncaught exception, etc.) and that caused an abort of the
process with an unclean exit which then triggers this problem. the cause
of the crash was never the WeatherEngine itself, but rather a crash in
WeatherEngine was triggered while the application was otherwise closing
down due to an error elsewhere that was itself bringing down the
application.
a simple killall plasma-device suffices to make WeatherEngine hit the
invalid Plasma::DataEngineManager::self(). I know that there is kquitapp,
which I have just checked and it avoids the crash, but not everybody uses
it.
DataEngines created by DataEngineManager *must* be released prior to
application exit. and normally this happens except in such cases where
the application is brought down by an abnormal situation.
I do not consider a TERM signal an abnormal situation. Could we add a
signal handler to plasma-{desktop,device} to re-route the TERM signal to
the code kquitapp triggers in plasma-{desktop,device}?
Just to make it clear. Signal TERM (kill -15, 15 is the default signal
for the kill command) means please, save your data and close yourself. It
does not mean abruptly killing the process, that is signal KILL. What I am
asking for here is to support the Unix way of gently terminating a process and
only that (support only signal TERM, not all other signals). The name kill
for the command to send signals to process is misleading, not all signals mean
something wrong happened. Signal SIGUSR1 for instance is commonly used to tell
the process to re-read its configuration. Today we have dbus to send messages
to processes, which I guess is what kquitapp uses, but not all programs
support dbus, so I do not see why not support this Unix way of sending
messages to a process.
so while you can make the changes David suggests, it will only change the
backtraces in those bug reports but not actually solve anything in the
real world. the aborts will still happen as a result of the underlying
error.
The crash does not happen if WeatherEngine's dtor is changed to do not
use Plasma::DataEngineManager::self().
--
Lamarque V. Souza
KDE's Network Management maintainer
http://planetkde.org/pt-br
Re: Re: Re: [GSoC] KWin colour management
2012/3/22 Kai-Uwe Behrmann k...@gmx.de: Here my thoughts, why I think CM in Qt is not easily introduced during a minor Qt 5 release. [Preparation of CM for Qt 6 is a different story.] Lets hypothetical assume some effort is initiated to bring CM to Qt and that happens during Qt 5 life time. The new design says by default all content is considered sRGB, which is by itself reasonable. However existing applications will initially not know about that changed convention. There is currently no API to know that. They will play freestyle as before and colour correct to monitor space without knowing how to tell anything to Qt. These old style apps will colour correct to monitor and Qt will colour correct from sRGB to monitor as Qt does not better know. That is called double colour correction and would be a real design bug. The conflict is solveable by making the new drawing API incompatible with the old one, e.g. requiring a colour space argument. An other way is verbally declaring sRGB as the default colour space in Qt, which would be a major API change as well and only reasonable possible during major version change. Both is not easy before Qt 5. After the fist Qt 5 release a new drawing API could theoretically be introduced in parallel to the old one. But old Qt apps would then look inconsistent compared to ones using the new API. Not sure if that transition path would be a good option regarding code complexity. IMO best would be to wait for Qt 6 and then switch completely. I'm sorry but you point is wrong here. Even if the real problem was just API changing and old applications getting unaware of that this is the easiest thing to fix. When people draw API they have this in mind and we don't need a whole new Qt just to introduce a new feature, easy solution: QApplication::setColorCorrected(true); Done! All old apps won't be color corrected since they don't set that and all new ones will be able to have this. And I had only to think about it in 2 minutes, surely Qt devs will have a better solution. I'm not saying it's easy to add Color Correction to Qt, but API additions is no excuse.
Re: [GSoC] KWin colour management
On 2012-03-22, Daniel Nicoletti dantt...@gmail.com wrote: people draw API they have this in mind and we don't need a whole new Qt just to introduce a new feature, easy solution: QApplication::setColorCorrected(true); That's crap API thoug.h QApplication::setBehaveSane(true); QApplication::setPleaseDontCrash(true); QApplication::pleaseFixMyBrokenApplication(true); /Sune
Re: [GSoC] KWin colour management
2012/3/22 Sune Vuorela nos...@vuorela.dk: On 2012-03-22, Daniel Nicoletti dantt...@gmail.com wrote: people draw API they have this in mind and we don't need a whole new Qt just to introduce a new feature, easy solution: QApplication::setColorCorrected(true); That's crap API thoug.h QApplication::setBehaveSane(true); QApplication::setPleaseDontCrash(true); QApplication::pleaseFixMyBrokenApplication(true); Sure it is, I was just illustrating that it is possible to add that (even through crap API). I'm not an expert in Qt internals but surely they will think on something much clever.
Re: Review Request: KJS: Extend strictEqual check for numbers by NaN and signbit check
This looks wrong to me; strictEqual is used for ===, which is defined in 11.9.6, and doesn't do any freaky deviations from IEEE FP. You'll likely need a separate version for SameValue proper. On 3/21/12, Bernd Buschinski b.buschin...@googlemail.com wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104358/ --- (Updated March 22, 2012, 12:41 a.m.) Review request for kdelibs. Changes --- Whoops sorry, wrong/old version uploaded - now really check for NaN using isNan Description --- In c++ NAN == NAN return false, true in javascript 9.12 Step 4.a also +0 == -0 is true in c++, false in javascript 9.12 Step 4.b (same for -0 == +0 , Step 4c) Diffs (updated) - kjs/operations.cpp d4c0066 Diff: http://git.reviewboard.kde.org/r/104358/diff/ Testing --- Tesed via ecmascript, fixes some tests that rely on +0 not beeing the same as -0 Thanks, Bernd Buschinski
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 enum
nameenum value (eg StatusDenied) and sometimes you use enum valueenum
name (eg HelperBusyError).
The Qt way would be enum valueenum name.
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 Kelly wrote:
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
typevalue vs. valuetype 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.
Kevin Ottens wrote:
Result pretty much aligns with what I was expecting as outcome from our
previous private discussion. And so, apart from the points Stephen already
raised I see nothing outstanding now.
Dario Freddi wrote:
Enums: will change all of them to be valuename (InvalidStatus,
ExecuteMode, AuthorizationDeniedError).
Static accessors: they are easily portable (one should use SuccessReply()
compared to previous SuccessReply) and quite used widely. I'd like people to
use ActionReply(ActionReply::SuccessType) instead, although they are indeed
widely used in helpers. Quite torn on this one - now they're safe to use
though, so I guess that besides adding lots of symbols for the sake of
nothing, they won't hurt. What's your take?
Squashing ExecuteJob's commits might be a good idea now that it's clear
we're going to use KJob as a base class. Will also take care of amending
other commits for the sake of clarity.
The enums are not used exactly because the static accessors are used
instead. The only enums that might be used around are the error ones, but
again it's not something as big to justify the need for having to keep SC
with those.
Old files in unit tests - Disclaimer I should have put: I forgot to
update copyrights and documentation, so those will come later. Files in the
autotests directory are slight modifications of existent files which
basically hijack KAuth's backend loading making it possible to use a
different testing backend. Will probably write a more detailed documentation
on how autotesting is achieved in the future, not anything strictly urgent
unless somebody plans to hack on the core testing suite soon (very unlikely).
Will fix enums in my branch (I won't update the review since it's too
much of a hassle) and will wait for further feedback from you about the other
points before amending merging.
Regarding the static accessors I think you're right, they won't hurt. If that
really bothers you though you could at least mark them deprecated, that'll
motivate people to port away from them, and you'll be in a good position to
remove them at the next great ABI breakage. :-)
- Kevin
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104337/#review11596
---
On March 18, 2012, 10:25
Re: RFC: i18n: drop KUIT tags in KDE Frameworks 5.0?
On Thu, March 22, 2012 10:25 am, Chusslove Illich wrote: Starting with KDE 4.0, i18n() functions act as XML processors under the hood, expecting the strings to be well-formed XML and resolving some tags (KUIT tags) to a target format (HTML or pure text). These KUIT tags include filename, para, emphasis, etc. I would like to drop this support in KDE Frameworks 5.0. There would be a fully automatic conversion script for sources to resolve KUIT tags in existing i18n() calls into appropriate target formats. The reasoning is as follows. Firstly, in the past 4 years, KUIT tags didn't get to be used very much. Only 0.56% of all messages (1144 out of 200,000) contain any. Only 5 out of 24 KUIT tags were used more than 100 times (filename being the most used with 333 appearances). This means that both original strategic goals were not accomplished: text elements still have different formatting across most of KDE applications (such as whether filenames are singly or doubly quoted, bold, etc.), and translators still have little additional semantic indication of what text placeholders are substituted with. Secondly, XML processing in strings was made somewhat lax, as a compromise between ease of use, mixing with existing markup (Qt rich text), and not changing programming habits. Most conspicuously, string arguments substituted for placeholders are not automatically escaped, e.g. into lt;, which causes silent non-well formedness behind the scene. In the other direction, people also complained about lt; inexpectedly becoming , etc. (i.e. the programmer didn't know about the XML nature of i18n() and doesn't want this at all). Based on these two observations, I myself would drop KUIT and that's it. But there are a few heavy users, and I'd like to know if they would strongly object to this. Among them: KAlarm, Partition Manager, DrKonqi, libkcdraw... One automatic question could be: can we have KUIT as option, default off? In KDE 4 this was not even technically possible, due to one ugly design problem of i18n(), but I plan to deal with this problem in KDE 5; so it should be technically possible. But, given the usage statistics above, I'm not sure if it makes sense spending time on this. (There would also have to be some redesign, making everything stricter, e.g. automatic escaping on substitution and no mixing with Qt rich text. This means that current KUIT users who would like to continue to use it, would have to do some manual checking and modification in existing code.) I understand from your email that you are only proposing to remove KUIT semantic tags, not KUIT context markers. Can you confirm this? -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
Re: Re: Re: [GSoC] KWin colour management
Am 22.03.2012, 08:55 Uhr, schrieb Kai-Uwe Behrmann k...@gmx.de: Lets hypothetical assume some effort is initiated to bring CM to Qt and that happens during Qt 5 life time. The new design says by default all content is considered sRGB, which is by itself reasonable. However existing applications will initially not know about that changed convention. Errrmmm... how is that please different from opting out of the compositor? Except that latter does not only hit Qt applications but also *every* legacy stuff around? The conflict is solveable by making the new drawing API incompatible with the old one, e.g. requiring a colour space argument. Or by making user code color correction calls (QApplication::setColorSpec(int spec)?) invalidate/override library settings? Cheers, Thomas
Re: RFC: i18n: drop KUIT tags in KDE Frameworks 5.0?
[: David Jarvie :] I understand from your email that you are only proposing to remove KUIT semantic tags, not KUIT context markers. Can you confirm this? I confirm. They are used much more than tags, and have no problems on their own; they are simply useful whenever present. They would only have no functional effect any more (this means dropping /format modifier too). -- Chusslove Illich (Часлав Илић) signature.asc Description: This is a digitally signed message part.
Re: [GSoC] KWin colour management
Sorry I missed to answere you somehow. Am 21.03.12, 10:25 +0100 schrieb todd rme: On Wed, Mar 21, 2012 at 8:39 AM, Kai-Uwe Behrmann k...@gmx.de wrote: Am 20.03.12, 21:17 +0100 schrieb Thomas Lübking: Am 20.03.2012, 20:12 Uhr, schrieb Martin Graesslin mgraess...@kde.org: A fully color corrected compositor seems feasible to me I'm atm. not even sure about that. I might be utterly wrong, but my impression is that the xvidmode extension can correct screens (eg. xcalib loads icc profiles), so a screen wide color xvidmode gamma ramps are per channel curves. These are very limited compared to ICC based colour correction. Those gamma curves provide better gray balance and potentialy white point adjustment. But they do not describe colour primaries shifts or other more complex distortions. Gamma curves must be taken into account for ICC profiles. But detailed characterisation of device colorimetry happens usualy in ICC profiles. This may be an ignorant question, but can xvidmode be extended to offer more complex correction? That would end in a all desktop content is sRGB dituation. That would be fine as long as we know that wide gamut monitors are excluded, like on fixed hardware. Tablets could do that for their internal displays. But I am afraid a desktop, which cribbles all wide gamut monitors by default to sRGB, is suboptimal marketing. kind regards Kai-Uwe Behrmann -- www.oyranos.org
Re: Re: Re: Re: [GSoC] KWin colour management
On Thursday 22 March 2012 19:20:11 Kai-Uwe Behrmann wrote: Something like that is technical possible. But let me repeat, you get then a mixture of colour managed and non colour managed apps with the same toolkit, which is completely non understandable for users. First of all: users don't know anything about toolkits. If they use KDE Plasma Workspaces (and that's what this whole thread is about), they get three different toolkits looking exactly the same thanks to the effort of the Oxygen team. So how should users understand that their Firefox (GTK 2) is not color corrected, while the Qt app is? The issue - if there is any at all - will be quite simply resolved by the apps adjusting to it. It's a three line patch (ifdef, call, endif) for each app. If users really care about it, they will report bugs to the application (looks strange when running with Qt 5.x) or the more advanced will provide the patch directly (e.g. a distro could very easily do that). To me it is important to do it right. And if right means legacy is not supported, than it is like that. To me it looks like you are trying extreme workarounds just to make everybody happy and especially support legacy. Do yourself a favor: go for the easy part and forget about legacy :-) Cheers Martin signature.asc Description: This is a digitally signed message part.
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 enum
nameenum value (eg StatusDenied) and sometimes you use enum valueenum
name (eg HelperBusyError).
The Qt way would be enum valueenum name.
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 Kelly wrote:
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
typevalue vs. valuetype 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.
Kevin Ottens wrote:
Result pretty much aligns with what I was expecting as outcome from our
previous private discussion. And so, apart from the points Stephen already
raised I see nothing outstanding now.
Dario Freddi wrote:
Enums: will change all of them to be valuename (InvalidStatus,
ExecuteMode, AuthorizationDeniedError).
Static accessors: they are easily portable (one should use SuccessReply()
compared to previous SuccessReply) and quite used widely. I'd like people to
use ActionReply(ActionReply::SuccessType) instead, although they are indeed
widely used in helpers. Quite torn on this one - now they're safe to use
though, so I guess that besides adding lots of symbols for the sake of
nothing, they won't hurt. What's your take?
Squashing ExecuteJob's commits might be a good idea now that it's clear
we're going to use KJob as a base class. Will also take care of amending
other commits for the sake of clarity.
The enums are not used exactly because the static accessors are used
instead. The only enums that might be used around are the error ones, but
again it's not something as big to justify the need for having to keep SC
with those.
Old files in unit tests - Disclaimer I should have put: I forgot to
update copyrights and documentation, so those will come later. Files in the
autotests directory are slight modifications of existent files which
basically hijack KAuth's backend loading making it possible to use a
different testing backend. Will probably write a more detailed documentation
on how autotesting is achieved in the future, not anything strictly urgent
unless somebody plans to hack on the core testing suite soon (very unlikely).
Will fix enums in my branch (I won't update the review since it's too
much of a hassle) and will wait for further feedback from you about the other
points before amending merging.
Kevin Ottens wrote:
Regarding the static accessors I think you're right, they won't hurt. If
that really bothers you though you could at least mark them deprecated,
that'll motivate people to port away from them, and you'll be in a good
position to remove them at the next great ABI breakage. :-)
Kevin: exactly what I intended to do :) Will do this in my branch then
- Dario
---
This is an automatically generated e-mail. To reply, visit:
Re: Re: Re: [GSoC] KWin colour management
Am 22.03.12, 22:49 +0100 schrieb Thomas Lübking: Am 22.03.2012, 19:20 Uhr, schrieb Kai-Uwe Behrmann k...@gmx.de: I was tould by the graphics community to keep the X Color Management spec backward compatible with the ICC Profile in X spec, so we did. Thus old style applications see a sRGB profile through the ICC Profile in X spec, and they continue to work by converting to sRGB. Sorry again, but does that actually mean that if I have a WG screen and an application which does not support the opt-out protocol or bought into a competing* system, it will be reduced to sRGB while the application and the Where would be a competing system on Linux? screen actually could do WG ... but the delete icon in dolphin looks correct? That is correctly described and expected behaviour as developers said. Next question: do you have approached the Wayland project on this? In case, what do they say? We discussed that with Wayland people and the last spec revision was adapted to meet their concerns. So the transition from X Color Management to W(ayland) Color Management should be relativele smooth. http://lists.freedesktop.org/archives/openicc/2012q1/004595.html http://www.oyranos.org/2012/02/x-color-management-0-4-draft1 *semi OT sidenote: This is btw. sth. I do not like at all. Xorg and fdo do not have the market share -esp. in that market- to afford two competing color management systems. I have no idea about the technical, conceptual and maybe religious differences, but would suggest to iron that out by all means if you ever want usable CM on this Architecture. What other substantial proposals or discussions do you have in mind? As far as I can see there was no publically discussed *competing* concept of substance ever brought to the attention of the graphics community. We only have read some nebulous and non technical statements on the typical level of marketing. OpenICC [1] is the fd.o place to discuss such CM stuff or at least the Xorg email list. In both I am active. I will surely continue to present and discuss the idea with users and developers in various events. kind regards Kai-Uwe Behrmann -- www.oyranos.org [1] http://www.freedesktop.org/wiki/OpenIcc/Events/Fosdem/2012
