Re: Review Request: include KolorManager in kdegraphics
On Wednesday, March 14, 2012 14:22:54 Sune Vuorela wrote: There's a few major points which I think if can be answered would help clarify what that would look like: Indeed, this discussion is going places, but does not really come up with answers. As someone who has no understanding of colour managemant whatsoever and without any bias, I, indeed, see some questions to be answered, in the hope this will provide us with some structure. * First of all, how expensive would it be to provide a small abstraction allowing drop-in replacement of Oyranos by colord and the other way around, e.g. have one interface and two backends? * If the platforms supported by the backend are different from the platforms targetted by KDE, how do we cope on these other targets? Should we answer question one with: indeed one interface, however, four backends -- given whatever Windows, MacOSX, or whatever platform you like and KDE targets uses. * What of those extra features are a big deal for a desktop environment (i.e. would specifically would we *not* be providing our users by supporting colord and not supporting Oyranos). * Maybe reformulated to: What are the target audiences of the applications? If one is more aimed at the default user and another at certain professionals this calls for a different view at the situation. As some people tend to say: one size does not always fits all. Furthermore, I expect that there should be some communication between the goals of KDE and those of the solution we prefer. * What feature(s) does Oyranos support over and above colord? I think we're all in agreement that Oyranos does /more/, but what specifically does that mean? * A feature-wise comparison, although that quite easily gives a false impression. For example, a product may have way more features, but because of some fundamental design decisions we do not like, or the other way around, something may be over simplified. Thus, such a comparison requires real expertise and no bias. It would probably be best if the developers explained what makes there software great and not so much what makes other software less worthy. * Finally, assuming no direct support for Oyranos in a KCM, what would be needed to allow a user to use Oyranos in a KDE Desktop? E.g. let's assume that colord is always available on Ubuntu and so KDE can interact with it, but the user wants to use Oyranos... what does KDE have to do to allow the user to manually control their color profiles without a KDE daemon interfering? * Maybe this should be asked for all possible solutions? Also, given the fact that there are people working or willing to work on KDE integration of both, this hould not be too much of a problem, I would guess. As a final remark, please note that the diversity in the open source world in general and the Linux world specific is, most of the time, considered a good thing. Competing projects are generally responsible for more innovation than monopolies. If we can embrace this, it would be wonderful.
Re: Review Request: include KolorManager in kdegraphics
Am 14.03.12, 17:04 +0100 schrieb Matthias Klumpp: 2012/3/14 Kai-Uwe Behrmann k...@gmx.de: Am 14.03.12, 15:54 +0100 schrieb Matthias Klumpp: [...] I also want to point you to this comparison colord against Oryanos: = http://www.freedesktop.org/software/colord/faq.html#oyranos Matthias, you help spreading false assertions here. Please do a similar table for Oryanos vs. colord than the colord maintainer did, so we can compare them. I guess that might be helpful even for people who don't understand color management very well. The table you link to is biased and, in my opinion, unfair. It would probably just as unfair if I started a similar comparison table. That is really a job for a third party reviewer. But instead I will list here the features Oyranos has right now, which I think will be directly useful to end users. I think it is worth noting that Oyranos and colord aren not the only players. There is also the very powerful and very valuable ArgyllCMS. Anyway, here about what Oyranos provides: Oyranos properties General Concept * cross platform API (Linux, BSD, osX, started win32) * abstraction from platform specific conventions * interfacing native OS specific CMS'es * cross desktop * toolkit independent library * standalone front end Synnefo in Qt (similiar to KolorManager) * selfcontained and modular design * most dependencies reside in runtime switchable modules * lightwight core * modules can be easily maintained, exchanged, fixed or extented * installations can be customised (e.g. skipping X11 module for pure print servers) * adhering to existing standards and work on new ones inside OpenICC / ICC * OpenICC is a fd.o project * we help creating and maintaining proposals and specs * Oyranos just works * KolorManager enables even nonexpert users to configure their devices * new BSD License Settings * complete CM settings like in advanced graphics applications * CinePaint * ICC Examin * optional, apps decide what they want to support * hybrid approach possible like explicitely syncing internal settgings with Oyranos * users can share CM options across supporting applications e.g. enabling proofing and selection of a proof profile That can reduce repeating settings in each application. * clear concept of user owned and system owned settings * user versus system rights are much more naturaly handled * administrators can provide useful machine specific defaults * portable * policy / grouping for easy switching, export, import of default settings * country specific defaults * company specific defaults or * task specific defaults Profile Handling * profile lookup * including support of platform specifics * profile parsing * minor corrections like profile ID assignment * caching * profile writing (but no own profiling like ArgyllCMS) Processing * colour conversion API * optional * apps can offload CM decission to Oyranos on demand * still fine controled settings possible * supports proofing, effect profiles * arbitrary channel count and bit depths like CMM (lcms) * profile and transform caching for fast access * backend API for plugable CMMs (lcms, lcms2, GPU based are possible) * stand alone modules, without external requirements * these CMM's are selectable through the colour conversion API * DAC based imaging for extension to HDR imaging and spectral imaging * state of the art, like in Gegl, Blender or other node based engines * 2D capable API * useful for adding tonemapping * CPU based multi monitor colour correction * needs the above imaging DAC, the monitor module and a CMM * works independent of window managers * used in some widgets in ICC Examin * traceable colour correction for easy debugging through users * unexpected results happen allways, this is a way to track processing * convenient for end users * speeds up error search by using simle tools * no gdb needed * named colour support * used in ICC Examin * would be useful in KDE colour selectors * high precission colorimetry with native channels easily possible Device Profile Assignment * automatic device profile based on parsed hardware and ICC meta data * automatic profile selection according to a given device * Taxi support for remote distributed ICC profiles * online DB for ICC device profiles * dispcalGUI can upload to Taxi DB * selection and download of profiles from remote DB by Oyranos * spec is shared through OpenICC for more users * backend API for device property modules * for device identification and * most complete tracking of colour related settings in drivers * abstracted from apps, which do not need to care about specifics * multi monitor support includes * XRandR like intel * nvidia drivers * ati drivers need more testing * on-the-fly fallback from EDID profile generation * supports cameraRAW/LibRaw combo * allows to
Re: Review Request: include KolorManager in kdegraphics
Am 14.03.12, 14:29 -0700 schrieb Daniel Nicoletti: 2012/3/14 Kai-Uwe Behrmann k...@gmx.de: It is indeed relevant because now we have a central place to configure it. And users need to manage and error check everything themself. I would not use that in a professional environment, where time counts. But colord depends on CUPS to support it's concept of placing colord's session centric configuration into each job on server side. Which makes total technical sense. No color management system will work 100% I still do not see merit in the user session in CUPS server hook concept. I would really like to understand why it is a good design, but no one gave so far a satisfying answere on OpenICC. Maybe it can be found here? Look at the details. colord is called inside CUPS server. CUPS servers can be remote without any DBus connection, which colord relies upon. The CUPS server is, well, a server, not client software. It takes print jobs through a well defined communication path after lots of security checks. Now colord breaks these security check on a local host and says to CUPS to use a There is no security break, sorry, I know CUPS, CUPS is the one calling an extra thing not the other way. That is wrong. CUPS is patched to call colord. CUPS itself does not use or need a extra thing. I'm not sure if this is what happens currently so I'm going to say what I would do: First regular users don't touch /etc/cups/client.conf - The file that makes your cups calls go away. They don't need that to talk to remote printers CUPS is smart enough to talk to another CUPS over the network. So a process that uses less than 1MB can just be installed on each Linux machine (as is the case today). If CUPS is locally installed this means it can just send the job color corrected! You checked that? The first respond from the colord author, which I have read, was that the remote machine shall be configured through colord. Hence my above discussion of such a situation. Now you suggest that the local client does colour correct a spooling PDF? Are you sure? That would be a great feature and much more work than a small hook inside CUPS. Nothing indicated, that the colord author wants to support that approach. So far colour conversion happens on the end machine. That is the one, which is connected to the device. That fits to what Michael Sweet says about early versus late colour binding, suggesting that early colour binding can cause gigabytes of traffic, while late colour bind will have no such issue. Plain simple... The colord printing configuration architecture fits maybe to a one person system like Android, provided that it uses a direct connection to the actual printing device. Ironically Android does not allow for DBus. I see no irony we do not target Android instead our users which lack CM. Public news stated, that Qt apps are already on Android. kind regards Kai-Uwe
Re: Review Request: include KolorManager in kdegraphics
Am 14.03.12, 20:43 -0700 schrieb Daniel Nicoletti: On the other hand if there are things that a mere 'power user' might find useful (that colord will not be supporting due to scope) then it might make sense to have extra U/I if Oyranos is available. Perhaps multi-monitor CMS would fit the bill (assuming colord will not support). I'm sure you were just giving an example but as someone earlier mentioned something about NVIDIA here's the explanation: Multi monitor color correction works as long as your video driver supports XRandR 1.3, which means NVIDIA proprietary driver is the only one not supporting this. If we support XRR 1.2 both monitors get the same correction. Personally I develop mainly on a nvidia machine with two very different monitors in part over DP. Colour correction works to each with the Oyranos setup. Even though I would prefere nvidia added support for XRandR properly. kind regards Kai-Uwe
Re: Review Request: include KolorManager in kdegraphics
Am 14.03.12, 20:39 -0700 schrieb Daniel Nicoletti: Like I also help with Wicd support in KDE, Kopete, and other areas of interests for KDE users. I do not use Wicd, but I help KDE users of Wicd even before I was the Network Management maintainer. By the way, I am not driven by FDO interests. We are using upower/udisks because there is no other choice in Linux, hal is unmaintained as you probably know. That is why I think we should have a community to maintain the software we depend upon. Right so which community you are talking about, because Kai likes KDE, it seems that you are putting FDO/Gnome as things we should get away, instead of actually looking at how maintainable these two things are and yet share code which is really important. First you need to build the software or use the packaged version, see how things work, now I started a replacement for system-config-printer because it has authentication problems and is written in python. when I go to Oyranos I found a bunch of tech I don't like, not just I don't like but many developers don't, so who will maintain those technologies if few people like/use it? Few developers like to code CMMs. On the other hand many people want ICC support. Yeah colour management is non trivial in the basics. That is not new. The more useful is a API like lcms provides and a maintainer, who cares about the core stuff and it's necessary complexities. And to get it right, device configuration is also non trivial. There needs not only the device identification as requireed for profile selection but as well the driver and the colour settings for that driver. Oyranos is one of the few libraries, which supports that in a generic way, without the need of special setups or closed loop systems. That's too personal oppinion and you sound like nobody likes oyranos. It's a personal opinion indeed but this doesn't mean nobody likes Oyranos, it simply means that looking at the code there won't be much devs willing to maintain that. The deps speak for themselves. You need to maintain the same dependencies of the Oyranos device modules inside your KDE code. Oyranos just abstracts that out into run time modules. Otherwise access to monitor or printer informations is not easy. I have never used PackageKit and said nothing about it. Are you talking about PakcageKit or colord here? Users can help with patches from time to time, that is important, and I was only a Knetworkmanager user before I started to contribute. Your statement is completely wrong in an opensource world. You don't get it, I'm giving an example of how good projects dies because from a technical point of view they become unmaintainable. Some special guys have a tradition in declaring other projects dieing. kind regards Kai-Uwe
Re: Review Request: include KolorManager in kdegraphics
Em Thursday 15 March 2012, Daniel Nicoletti escreveu: Like I also help with Wicd support in KDE, Kopete, and other areas of interests for KDE users. I do not use Wicd, but I help KDE users of Wicd even before I was the Network Management maintainer. By the way, I am not driven by FDO interests. We are using upower/udisks because there is no other choice in Linux, hal is unmaintained as you probably know. That is why I think we should have a community to maintain the software we depend upon. Right so which community you are talking about, because Kai likes KDE, it seems that you are putting FDO/Gnome as things we should get away, instead of actually looking at how maintainable these two things are and yet share code which is really important. The community that develops and maintains the software in question. In the sentence above it was hal's community, in this thread are the oyranos and colord's communities. First you need to build the software or use the packaged version, see how things work, now I started a replacement for system-config-printer because it has authentication problems and is written in python. when I go to Oyranos I found a bunch of tech I don't like, not just I don't like but many developers don't, so who will maintain those technologies if few people like/use it? That's too personal oppinion and you sound like nobody likes oyranos. It's a personal opinion indeed but this doesn't mean nobody likes Oyranos, it simply means that looking at the code there won't be much devs willing to maintain that. The deps speak for themselves. Maybe, that is something that needs to be discussed with oyranos' community. By what I read in this thread elektra is still maintained and is optional, not sure about fltk. I don't want to kill Oyranos but I do think the choices based on wrong use cases might lead to an end, a good project done with a wrong design won't succeed. Take smart for example, PackageKit in a few years was able to do what they tried for many years, and stop saying that Gnome or Red Hat is pushing it, you can have Gnome without it, FDO also plays by it's own rules, let's focus on what really matters which is the code. No user will help you maintain a line of code, they will use what we best choose to them. If it is about Gnome without colord I am not sure if that is possible, anyway, why would they patch cups to add support to colord if it is not going to be used in the desktops? Gnome works pretty much the same way as KDE we have modules, so the do, you can just remove/disable and Gnome will run without it, but why remove a cool feature? It's non sense, it's obvious that every distro would push because they want the missing feature, if Oyranos was there first maybe colord didn't had to exist. Maybe, maybe not. I have never used PackageKit and said nothing about it. Are you talking about PakcageKit or colord here? Users can help with patches from time to time, that is important, and I was only a Knetworkmanager user before I started to contribute. Your statement is completely wrong in an opensource world. You don't get it, I'm giving an example of how good projects dies because from a technical point of view they become unmaintainable. Sure, pretty much everyone is first an user then a developer but this doesn't mean you can expect from users of a software to maintain that, otherwise most of these projects wouldn't go into an end. You mean the oppositte in the last sentense, right? I still disagree, users can do a lot to help maintaining a software, that's called community. For extremelly technical parts there will be less users able to help, but still if you are not a user of the software why would you bother to help maintaining it? Sure the most experient users take the technical decisions, that is what we are do here in k-c-d for KDE for example. -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br
Re: Review Request: include KolorManager in kdegraphics
So far colour conversion happens on the end machine. That is the one, which is connected to the device. That fits to what Michael Sweet says about early versus late colour binding, suggesting that early colour binding can cause gigabytes of traffic, while late colour bind will have no such issue. Kai you keep saying that Michael Sweet don't want colord upstream, how do I find just the opposite? http://lists.freedesktop.org/archives/openicc/2012q1/004489.html He even mentions that to add Oyranos that means loads of code...
Re: Review Request: include KolorManager in kdegraphics
Am 15.03.12, 08:06 -0300 schrieb Lamarque V. Souza: Maybe, that is something that needs to be discussed with oyranos' community. By what I read in this thread elektra is still maintained and is optional, not sure about fltk. FLTK is optional. The core library is toolkit independent and builds fine without GUI code. However there is some example code using FLTK, Qt and Cairo. kind regards Kai-Uwe
Re: Review Request: include KolorManager in kdegraphics
Am 15.03.12, 07:34 +0100 schrieb Stas Verberkt: On Wednesday, March 14, 2012 14:22:54 Sune Vuorela wrote: There's a few major points which I think if can be answered would help clarify what that would look like: Indeed, this discussion is going places, but does not really come up with answers. As someone who has no understanding of colour managemant whatsoever and without any bias, I, indeed, see some questions to be answered, in the hope this will provide us with some structure. * First of all, how expensive would it be to provide a small abstraction allowing drop-in replacement of Oyranos by colord and the other way around, e.g. have one interface and two backends? For device configuration a decission would have to be made to eiher simplify and thus cripple Oyranos or to extent colord for a common API wrapper. Profile lookup would be pretty simple. Many settings could be shared, but do not completely overlap. I do not know about caching in colord. A colour conversion CMM wrapper API is only in Oyranos available. So you would have to recode that completely of you want complete independence from. All modern platforms, except Linux, support now multi monitor colour correction in their basic image viewers. You might loose partitially the ability to support that. For cross platform support, KDE would need code rewritten for each platform. This includes nearly all non pure ICC components, like profile paths, settings, device backends and so on. * If the platforms supported by the backend are different from the platforms targetted by KDE, how do we cope on these other targets? Should we answer question one with: indeed one interface, however, four backends -- given whatever Windows, MacOSX, or whatever platform you like and KDE targets uses. * What of those extra features are a big deal for a desktop environment (i.e. would specifically would we *not* be providing our users by supporting colord and not supporting Oyranos). * Maybe reformulated to: What are the target audiences of the applications? If one is more aimed at the default user and another at certain professionals this calls for a different view at the situation. As It is not that a strong division. Oyranos at least supports both mentioned user groups. some people tend to say: one size does not always fits all. Furthermore, I expect that there should be some communication between the goals of KDE and those of the solution we prefer. I be here around. * What feature(s) does Oyranos support over and above colord? I think we're all in agreement that Oyranos does /more/, but what specifically does that mean? * A feature-wise comparison, although that quite easily gives a false impression. For example, a product may have way more features, but because of some fundamental design decisions we do not like, or the other way around, something may be over simplified. Thus, such a comparison requires real expertise and no bias. It would probably be best if the developers explained what makes there software great and not so much what makes other software less worthy. agreed. Again my link inside this thread to do so. http://lists.kde.org/?l=kde-core-develm=133180205024971w=2 * Finally, assuming no direct support for Oyranos in a KCM, what would be needed to allow a user to use Oyranos in a KDE Desktop? E.g. let's assume that colord is always available on Ubuntu and so KDE can interact with it, but the user wants to use Oyranos... what does KDE have to do to allow the user to manually control their color profiles without a KDE daemon interfering? * Maybe this should be asked for all possible solutions? Also, given the fact that there are people working or willing to work on KDE integration of both, this hould not be too much of a problem, I would guess. As a final remark, please note that the diversity in the open source world in general and the Linux world specific is, most of the time, considered a good thing. Competing projects are generally responsible for more innovation than monopolies. If we can embrace this, it would be wonderful. kind regards Kai-Uwe -- Kai-Uwe Behrmann www.oyranos.org
Re: Review Request: include KolorManager in kdegraphics
Am 14.03.12, 14:29 -0700 schrieb Daniel Nicoletti: If CUPS is locally installed this means it can just send the job color corrected! Am 15.03.12, 04:11 -0700 schrieb Daniel Nicoletti: So far colour conversion happens on the end machine. That is the one, which is connected to the device. That fits to what Michael Sweet says about early versus late colour binding, suggesting that early colour binding can cause gigabytes of traffic, while late colour bind will have no such issue. Kai you keep saying that Michael Sweet don't want colord upstream, Do you mean me? If so I did not write such a statement. I refered to your abouve first sentence, which is now recovered. how do I find just the opposite? No idea how you get these two different things together. Maybe you think early colour binding is related to linking of code? Then no it is not related. Early colour binding means simply to do colour conversion early in the data flow, and that means on the local host, inside the application. http://lists.freedesktop.org/archives/openicc/2012q1/004489.html He even mentions that to add Oyranos that means loads of code... Regardless of oversimplified or non-trivial amounts of code, I still do not think that this would be a good route to follow. I fear a big maintainance effort for that scheme. kind regards Kai-Uwe
Re: Review Request: include KolorManager in kdegraphics
On Wednesday 14 March 2012 20.31.30 Lamarque V. Souza wrote: I said I wanted the most versatile, which means one that satisfies my needs and somebody else's needs. The requirement for 'most versatile' doesn't follow in that sentence. You are making a logic error, or at least taking the biggest car and hoping it will get you there fastest. If you want to satisfy your needs, try it for a while and see if it works. You are completey ignoring the fact that there are people using oyranos too, it has been developed for years, do you think it's fair to drop all that work now? Hmm, you pose lots of questions that are completely off-topic here. And jumping to weird conclusions about dropping work is just unhelpful. I am in favor of adding support to both colord and oyranos in kdegraphics. I strongly disagree with that. KDE is not a support group where lonely software goes to get more recognition. This community works based on choosing solutions that work best. Your suggestion to not choose is therefore not helpful. And no, I have not tested either of them Then I'm sorry to say, your opinion is just that, one uninformed opinion. At minimum read this; http://www.freedesktop.org/software/colord/intro.html And tell us if there is any reason to say that this product does *not* satisfy your needs (when the KDE stuff is finished) nobody is an expert in color managament to judge the merits of either project There are not a lot of experts on the topic, no. I've been doing my first physical monitor and scanner calibration back in 1999, on the Mac. (with a Barco monitor). I've been reading many (beautifyl) books and I'm nowhere near an expert at all. From a software engineer point of view there is a good solution; as I *do* have the basic information needed, and thats easy to get to for everyone else as well. Read the above linked page, for instance. Basic design of system color management is that each input (scanner etc) and each output (monitor, printer) has to have assigned a personal color profile. Applications that are capable of doing color management have to have access to those profiles so they can use them in combination with a library like lcms to do the right thing. Colord embraces that concept and provides all we need. Oyranos makes things ... complicated. See; http://www.oyranos.org/doc_alpha/index.html -- Thomas Zander
Re: Review Request: include KolorManager in kdegraphics
Am 15.03.12, 13:09 +0100 schrieb Thomas Zander: Basic design of system color management is that each input (scanner etc) and each output (monitor, printer) has to have assigned a personal color profile. That is not as simple as that. You must include the driver, the colour related driver settings and maybe more identification informations from the device itself like the EDID. E.g. Modern monitors can emulate colour spaces, that would be written in the EDID. A simple one device to one profile is over simplified and ambiguous at best. Applications that are capable of doing color management have to have access to those profiles so they can use them in combination with a library like lcms to do the right thing. ... and do caching, lookup, perhaps wrapping of CMMs and so one. Would it not be nice to share that? Colord embraces that concept and provides all we need. Oyranos makes things ... complicated. See; http://www.oyranos.org/doc_alpha/index.html That is a apple against orange page comparision. But hey, here is a better link: http://www.oyranos.org/features/ -- Thomas Zander glad to help, Kai-Uwe -- Kai-Uwe Behrmann www.oyranos.org
Re: Review Request: include KolorManager in kdegraphics
Em Thursday 15 March 2012, Thomas Zander escreveu: On Wednesday 14 March 2012 20.31.30 Lamarque V. Souza wrote: I said I wanted the most versatile, which means one that satisfies my needs and somebody else's needs. The requirement for 'most versatile' doesn't follow in that sentence. You are making a logic error, or at least taking the biggest car and hoping it will get you there fastest. No, I choose a car that carries my and my family's luggage in a reasonable speed. Most of the time I can drive alone, but it is still usefull to have a reasonable sized trunk to carry something for me or someone of my family. Or do you think I should always buy a moto and never a car just because I prefer driving fast? If you want to satisfy your needs, try it for a while and see if it works. You are completey ignoring the fact that there are people using oyranos too, it has been developed for years, do you think it's fair to drop all that work now? Hmm, you pose lots of questions that are completely off-topic here. And jumping to weird conclusions about dropping work is just unhelpful. I think dropping work must be carefully decided, if nobody uses the code so drop it. I am ready to drop Kopete once telepathy-kde fullfills my needs and I have already dropped features from Plasma NM that nobody used. If there are people using oyranos I think that must be taking into account. I am in favor of adding support to both colord and oyranos in kdegraphics. I strongly disagree with that. KDE is not a support group where lonely software goes to get more recognition. This community works based on choosing solutions that work best. Your suggestion to not choose is therefore not helpful. That was not my suggestion, somebody else suggested that in #kde-devel and I agree because I think that fullfills the needs of most KDE users. And no, I have not tested either of them Then I'm sorry to say, your opinion is just that, one uninformed opinion. Like everybody else's opinion in this thread. At minimum read this; http://www.freedesktop.org/software/colord/intro.html And tell us if there is any reason to say that this product does *not* satisfy your needs (when the KDE stuff is finished) I do not have a need for color management nowadays, which does not mean I cannot help fullfill somebody else's needs. I do not always do things for myself only. Basic design of system color management is that each input (scanner etc) and each output (monitor, printer) has to have assigned a personal color profile. Applications that are capable of doing color management have to have access to those profiles so they can use them in combination with a library like lcms to do the right thing. How that is different from oyranos? Colord embraces that concept and provides all we need. Oyranos makes things ... complicated. See; http://www.oyranos.org/doc_alpha/index.html By reading the front page of both web pages I cannot judge which one is more complicated. I do not have time to read all pages in both projects now too. -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br
Re: Bugzilla upgrade.
On Wed, March 14, 2012 9:41 pm, Burkhard Lück wrote: And to have the Additional Comments field above the BR and all comments is like tofu (http://en.wikipedia.org/wiki/Top-posting#Top-posting) There is now a preference setting which lets you choose whether to display the Additional Comments field at the top or the bottom. On Wed, March 14, 2012 7:32 pm, Daniel Nicoletti wrote: I don't think so, I think it has some huge icons but I thought it was my browsers problem, the huge header and footer it's real hard to see the content on my small screen, the new version fews snappier but the theme needs polishing imo. I also renders the footer strange using Chrome, but I hope someone is still working on this... :D Yes, the header fields waste a _lot_ of space. The old theme was far better in that respect. -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
Re: Bugzilla upgrade.
On Thursday 15 March 2012 Mar, David Jarvie wrote: On Wed, March 14, 2012 9:41 pm, Burkhard Lück wrote: And to have the Additional Comments field above the BR and all comments is like tofu (http://en.wikipedia.org/wiki/Top-posting#Top-posting) There is now a preference setting which lets you choose whether to display the Additional Comments field at the top or the bottom. On Wed, March 14, 2012 7:32 pm, Daniel Nicoletti wrote: I don't think so, I think it has some huge icons but I thought it was my browsers problem, the huge header and footer it's real hard to see the content on my small screen, the new version fews snappier but the theme needs polishing imo. I also renders the footer strange using Chrome, but I hope someone is still working on this... :D Yes, the header fields waste a _lot_ of space. The old theme was far better in that respect. And the footer field tends to obscure the line I was searching for, at least in firefox. -- Boudewijn Rempt http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
Re: Re: Review Request: include KolorManager in kdegraphics
Don't know the best place to reply, so I guess that this is as good as any. We don't need to choose right now, colord-kde just started and Oyranos is just starting to make noise thanks to KColorManager, where is the hurry to choose a side? it seems to me that some people are using this fight to win a battle in the Middleware war which some people think that is going on. Please stop that or open a new thread to discuss that. In my humble opinion we should just wait and see what of them last longer and healthier. Also, I'm not an expert but if we could share interface I would love that, is it possible? Finally, is there any possibility of making an abstraction that allows our applications to use color management in all platforms? Thanks and sorry if I say soemthign already replied, long threads are long :p
Re: Review Request: Remember current desktop when changing activity
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104261/ --- (Updated March 15, 2012, 6:13 p.m.) Review request for KDE Runtime. Description --- Patches kactivitymanagerd to store (and restore back) the working current directory when switching activities. The activity-changing-behavior is as follows: 1. Say you have two (or more activities) A and B. 2. You are working on activity A on Desktop 4. 3. You switch to activity B (and by default to Desktop 4). 4. Change to Desktop 1. 5. Go back to activity A and (by default) to Desktop 1, while it should move you to Desktop 4 (this is where my patch kicks in). I hope it makes sense :-) This addresses bugs 241864 and 265015. http://bugs.kde.org/show_bug.cgi?id=241864 http://bugs.kde.org/show_bug.cgi?id=265015 Diffs - service/ActivityManager.cpp 7af2049 service/ActivityManager_p.h d054eb7 Diff: http://git.reviewboard.kde.org/r/104261/diff/ Testing --- Thanks, makis marimpis
Re: Review Request: include KolorManager in kdegraphics
On Thursday 15 March 2012, Alex Fiestas wrote: ... In my humble opinion we should just wait and see what of them last longer and healthier. +1 Alex
Re: Review Request: include KolorManager in kdegraphics
2012/3/15 Alexander Neundorf neund...@kde.org: On Thursday 15 March 2012, Alex Fiestas wrote: ... In my humble opinion we should just wait and see what of them last longer and healthier. +1 I agree with that too :) Maybe wait a few months and then check the new situation. (or rediscuss the old one if nothing has changed, but I don't believe that nothing changes ^^) Cheers, Matthias
Re: Review Request: include KolorManager in kdegraphics
Am 15.03.12, 09:39 -0300 schrieb Daniel Nicoletti: 2012/3/15 Kai-Uwe Behrmann k...@gmx.de: ... and do caching, lookup, perhaps wrapping of CMMs and so one. Would it not be nice to share that? Really caching of so small files? If you cache small files you have an unneeded overhead at best and a complex solution at worst. Transforms are expensive, so caching makes sense. Parsing of ICC profiles in larger numbers is expensive too. That is a apple against orange page comparision. But hey, here is a better link: http://www.oyranos.org/features/ You're just trying to create yet another CMS, we already have excelent ones lcms, AngryCMS why a third? Oyranos is a wrapper for CMM's. That way it wrappes the lcms ICC colour conversion engine. It could wrap ArgyllCMS's ICC colour conversion engine as a CMM too. Oyranos does not do colour colorimetric stuff. It links to a CMM to do that. kind regards Kai-Uwe
Re: Review Request: include KolorManager in kdegraphics
On Wednesday, March 14, 2012 20:43:59 Daniel Nicoletti wrote: On the other hand if there are things that a mere 'power user' might find useful (that colord will not be supporting due to scope) then it might make sense to have extra U/I if Oyranos is available. Perhaps multi-monitor CMS would fit the bill (assuming colord will not support). I'm sure you were just giving an example but as someone earlier mentioned something about NVIDIA here's the explanation: Multi monitor color correction works as long as your video driver supports XRandR 1.3, which means NVIDIA proprietary driver is the only one not supporting this. If we support XRR 1.2 both monitors get the same correction. OK, thanks for the clarification. I didn't mean to further spread a possible misconception (although I can't go back and edit it now anyways). Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part.
kdegames looking for a QML-experienced mentor
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
Re: Review Request: include KolorManager in kdegraphics
On Thursday, March 15, 2012 12:11:34 Kai-Uwe Behrmann wrote: Am 14.03.12, 22:15 -0400 schrieb Michael Pyne: The problem is that the software is /like/ KDE but doesn't use any KDE technologies. To best utilize a given subsystem we would typically use at least a light abstraction layer, using Oyranos (at this stage) entails a KDE abstraction layer on top of a KDE-like abstraction layer (unless KDE apps code to Oyranos directly, which I don't see as likely in general). This API impedance mismatch is undesirable for much the same reasons that we don't typically code to glib or gobject APIs. Do you suggest a KDE wrapper for Oyranos objects and functions? Well, I suggest that if KDE is to support color management at essentially any level deeper than just providing a UI to e.g. select a color profile for a display and printer, that it would be done with a KDE-style API, that could wrap Oyranos, or could wrap any other feasible implementation. Something like Phonon or Solid. I hope to have adressed that already from my side. http://lists.kde.org/?l=kde-core-develm=133180205024971w=2 Thanks for the link straight to the relevant email. :) Oyranos makes sense to user, who have no idea that colour management exists. So they have no idea that it would be good for them. Well your link says that Oyranos just works, and your statement here seems to suggest that Oyranos does this without much (if any) user intervention. Given all the other features supported by Oyranos I have to assume that this requires at least some support from the application and/or toolkit level, no? Keeping that in mind it would seem that to get the full benefit of Oyranos that there would need to be deeper integration work than just adding KolorManager (which I understand is separate from this thread's topic). Returning to the topic at-hand, I will say (and this is just my opinion) that I think this application would be best suited for extragear/graphics when it moves out of playground, based on the low level of integration (both with KDE's desktop and the other toolkit/infra work needed). If/when color management becomes more supported in Qt and KDE then it would make more sense to have CMS configuration in kdegraphics for the available CMS system(s). But until then having this in kdegraphics without support from skanlite, Qt, our printing layer, etc. really seems to promise more than a KDE desktop can deliver right now. Even if it were to be in kdegraphics it should be an optional build item (dependent on whether oyranos is available or not). Like I said, that's just my opinion... I'm neither involved in kdegraphics development nor the kdegraphics module maintainer. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part.
Re: Review Request: include KolorManager in kdegraphics
Michael Pyne mp...@kde.org schrieb: On Wednesday, March 14, 2012 20:43:59 Daniel Nicoletti wrote: On the other hand if there are things that a mere 'power user' might find useful (that colord will not be supporting due to scope) then it might make sense to have extra U/I if Oyranos is available. Perhaps multi-monitor CMS would fit the bill (assuming colord will not support). I'm sure you were just giving an example but as someone earlier mentioned something about NVIDIA here's the explanation: Multi monitor color correction works as long as your video driver supports XRandR 1.3, which means NVIDIA proprietary driver is the only one not supporting this. If we support XRR 1.2 both monitors get the same correction. OK, thanks for the clarification. I didn't mean to further spread a possible misconception (although I can't go back and edit it now anyways). Oyranos has a tool to do multi monitor ICC setup with nvidia propriarity drivers. It works as well without XRandR. Some projects do multi monitor colour correction using Oyranos this way. kind regards Kai-Uwe
