Version: (using Devel) Installed from: Compiled sources The most recently added "alternative" default theme "Ozone" has some serious problems which involve technical issues and unfortunately even goes beyond those: The first issue is that technically Oxygen was never meant to visually distinguish between an abstract thing called "window decoration" and the mainwindow/dialog background (1). This was obviously made for good reasons as thereby the Oxygen Window Decoration looks easier on the eyes more elegant and provides less visual clutter. The current solution in Oxygen still bears the need to come up with a better way for differentiating between active and inactive windows but this bug has been filed elsewhere and is not subject to this bugzilla entry. By renaming the style and by encouraging/allowing users to change the color of the window decoration to something that will evidently look bad Lubos Lunak has shown utter disrespect for the work of the Oxygen artist team (probably due to lack of awareness). Basically this action is comparable to the situation where an exhibitor orders his artist to paint a great picture (into which the artist puts his heart and his soul -- in his spare time). Once the picture is done during the exhibition the exhibitor starts to put color spray cans in front of the picture so people might "adjust" something that was not supposed to be "adjusted" to their needs. ("Hey, it's free software, so we are legally allow to mess around with it!" -- "Only within limits if we value and respect expertise and ethics"). I could completely understand if the artists involved would be clearly pissed by this kind of action and wouldn't feel much like contributing anymore. I want to assume that Lubos Lunak is just not aware of the harm this action might have done. Don't get me wrong: I do not oppose the ability to customize the color of all kinds of details of a theme -- as long as the visual integrity is maintained! However as the KDE project we have the responsibility to make sure that custom visual settings provided will still look good and would be visually consistent with the rest of the interface. I'm also fully aware that distributors who think they "know better" might apply comparable patches. But there's a difference if we as a KDE team encourage this (by putting the spray can right into the user's hands) or if others decide to change their copy of our software. The former wouldn't shed good light onto the professionalism and team work inside the KDE project. My opinion on how this would need to get fixed professionally (in terms of quality work as well as quality behavior) is this: A.) Give the artists a public deadline for the KDE 4.1 release to come up with a proposal that will line out a viable alternative to addressing the "inactive / active" issue. B.) If the suggested solution still sticks to the concept of "no visual distinction between the mainwidget background and the windeco frameborders" (which is pretty likely) then the SystemSettings software needs to get adjusted as follows: - an internal property for window decorations needs to get added (probably a boolean/enum). If set "true" it will make sure that the window decoration color will always be synchronized with the mainwidget background. - The SystemSettings module will query the value of the above-mentioned property and -- if set "true" -- will not offer separate means to adjust the color for window manager and mainwidget separately. Instead both values would get provided through a single entry in the user interface for this particular theme. I think this kind of solution would provide a viable fix for this Ozone bug. Best Regards, Torsten Rahn (1) Actually the difference between the window decoration color and the mainwindow background color is something that seems pretty unnatural/artificial to most new users. As a user it would never come to my mind that a concept such as a window manager would be necessary at all (while I do perfectly understand the internal need from the point of a technician). I remember that coming from MS Windows almost 15 years ago the concept of a WindowManager was completely new to me as it was well hidden by Non-Unix Operating systems. And rightfully so as the awareness of the window manager concept has little merit for most end users who simply want to get their work done. Personally I guess that the popularity of visually distinctive window managers on Unix is an accident which stems back from the prototype-quality solutions such as the Athena "toolkit".
Oh and of course I agree that it must be possible to change the color of mainwidget+windeco (in sync). To make sure that the Oxygen theme doesn't get misrepresented I'd suggest that the color picker would prominently offer good and acceptable color alternatives (as defined by pinheiro). As you might realize from the mail above I'm truely disappointed that this fork has been created so quickly. It would show poorly on us if we wouldn't come up with a single solution before 4.1 that would be at least halfway satisfying to everyone involved.
I suggest you read all of bug #152030 (have fun) to figure out the background behind this (say, things like the idea of forking coming from the Oxygen people actually, or that this "quickly" took months). I'm not very happy about this either, I find this ridiculous in fact, so if you know a better solution, please share it.
Is this the place for flaming remark? Isn't a mailing list such as kwin@kde.org a better place to find a compromise? Anyway, here are my remarks. The artist could have spared us all of this by listening and reacting to the complains of the users. The current solution may not be ideal, but at least it provides a working solution for the meantime. I have a few issues with regards with such a tight integration as with the oxygen theme and the decoration. The fact that decoration and widget style are handled by different programs may be an implementation detail, but it is an important detail, and pretending it isn't there poses problems I have not seen addressed by the Oxygen artists. For example, not all applications are KDE applications, and visual clues suggested by the Oxygen team do not work with, say GNOME applications. I think playing working acceptably with other applications than KDE should be an important design consideration for the default decoration. And working with non-composited displays. And working with non-state-of-the-art hardware. And non-state-of-the-art eyes, for that matter. So all things considered, I prefer a theme that may allow the user to make the window uglier -- in the eye of the designer -- but functional.
Lubos Lunak wrote: > I suggest you read all of bug #152030 (have fun) to figure out Did that. I have even read through it a second time and from reading Nuno Pinheiro's and Ricardo Iaconelli's position the whole issue seems to mostly focus on the issue that window manager and mainwidget color need to be kept in sync. > the background behind this (say, things like the idea of forking > coming from the Oxygen people actually, or that this "quickly" I think I can read between the lines that this suggestion wasn't meant verbatim - at least not from the artists. Luciano Montanaro wrote: > The artist could have spared us all of this by listening and reacting > to the complains of the users. Oh come on. Have you ever done artwork? It's not like one could solve problems of artwork in a deterministic way (much math is pretty easy to do in comparison - for artwork you need to wait for an inspiration to come - you often can't force it). Besides: Most people who have replied in the Bugzilla thread are developers and not users. > and pretending it isn't there poses problems > I have not seen addressed by the Oxygen artists. Which ones? > playing working acceptably with other applications > than KDE should be an important design consideration Sure. > And working with non-composited displays. I also see the point of this one although I fail to see why this shouldn't be possible for Oxygen with appropriate fallback solutions. I'll talk to Nuno about this ... and sorry, but I don't consider this issue "fixed", "closed" or "resolved".
On Wednesday 09 April 2008 22:43:11 tackat@kde.org wrote: > Lubos Lunak wrote: > > I suggest you read all of bug #152030 (have fun) to figure out > > Did that. I have even read through it a second time and from reading Nuno > Pinheiro's and Ricardo Iaconelli's position the whole issue seems to mostly > focus on the issue that window manager and mainwidget color need to be kept > in sync. > Well, I think there are planty of ways to respect color roles while making the decoration look similar enough to the original idea. As long as you are flexible enough. For example you could blend the border color over the window background color. Or draw a thin outline using the border color. Similarly for the title background colors. I'd like to try out some idea if I manage to find the time. Well, it's not you that I must convince, and I tried a few times already with Nuno and Riccardo, at least. Well, I had the impression Nuno is the one that really opposes practically any change in this regard, but... > > the background behind this (say, things like the idea of forking > > coming from the Oxygen people actually, or that this "quickly" > > I think I can read between the lines that this suggestion wasn't meant > verbatim - at least not from the artists. > Actually I'm not sure how to read that. Maybe you are right. It seemed a bit... odd, anyway, and not in the spirit of collaboration that should be the norm in free or open source software. Actually, it looks to me as Nuno is not really comfortable with the open source idea yet. Well, artwork poses different issues from code, and I can understand the problem, up to a certain point -- but "Oxygen" looks to me as the umbrella name of "whatever KDE4 ships as its default theme". > Luciano Montanaro wrote: > > The artist could have spared us all of this by listening and reacting > > to the complains of the users. > > Oh come on. Have you ever done artwork? A little, I guess. Nothing too fancy, for the games. It can be a lot of work, and tweaking, and experimenting... Feels like programming. :) > It's not like one could solve > problems of artwork in a deterministic way (much math is pretty easy to do > in comparison - for artwork you need to wait for an inspiration to come - > you often can't force it). I find software is not much different. Free software in particular. But nothing prevents other people to help with software -- and people should not be prevented to help, discuss or improve artwork too. Or to change the design if it does not fit. A decoration should not be "art" it should be "design", and it should be ergonomic. A bit of art can be sacrificed to function. Otherwise, you end up with something like those chairs that are kept in museums, because they cannot be used to sit on them. > Besides: Most people who have replied in the > Bugzilla thread are developers and not users. > At this stage in KDE 4, what's the difference? ;) Jokes apart, developers are users too. We may be picky users, and argumentative, but I can't see why developer needs should be dismissed so easily. > > and pretending it isn't there poses problems > > I have not seen addressed by the Oxygen artists. > > Which ones? I'm missing the context here... Oh, the duality decoration-widget style. Well, the one with non-KDE applications down there, to start. You can't rely on a GTK+ application to change window background color to show it has focus. Or Java. Or... So I'd rather have a decoration that looks decent (and gives me the strong hint I need at which window has the focus) in as many conditions as possible, and maybe does not fully implement the original ideal. > > > playing working acceptably with other applications > > than KDE should be an important design consideration > > Sure. > > > And working with non-composited displays. > > I also see the point of this one although I fail to see why this shouldn't > be possible for Oxygen with appropriate fallback solutions. > I think it would be perfectly possible to have that, yes. > I'll talk to Nuno about this ... and sorry, but I don't consider this issue > "fixed", "closed" or "resolved". Good luck, then. Let me know on any news. > _______________________________________________ > Kwin mailing list > Kwin@kde.org > https://mail.kde.org/mailman/listinfo/kwin
So I have no idea on open source??? Interesting, nice to know. This is really really bad, and makes me wonder what am I doing here? The fact is that you are saying to me.... anything as long as its collorable... and cause i say that is ok but that is not oxygen, I must be a freaking asshole.
I've talked to Nuno Pinheiro in the meantime and indeed my assumption has been correct: 1. The only issue that he insists on is the treatment of window decoration and mainwidget as a single visual entity. All other issues mentioned in the "other" bugzilla entry are not things where he has strong feelings. 2. Nuno Pinheiro is neither happy with a fork nor did he seriously encourage it. One doesn't need to be socially sensible to get that by reading the thread. > Well, I think there are planty of ways to respect color roles while > making the decoration look similar enough to the original idea. As Well, draw a mockup and show it to Nuno Pinheiro for his opinion. > manage to find the time. Well, it's not you that I must convince, > and I tried a few times already with Nuno and Riccardo, at least. It's funny but except for me and Nuno Celeste Paul shares our opinion on this issue. So it's quite likely that you'd basically need to show a viable solution that convinces one of us and everyone else would be convinced as well. Why? Because suitable artwork is not something random. > bit... odd, anyway, and not in the spirit of collaboration that > should be the norm in free or open source software. Actually, it > looks to me as Nuno is not really comfortable with the open source Well, it's pretty obvious to me that it's quite a challenge to get artwork and free software under one umbrella. And it's perfectly understandable for me that Nuno Pinheiro isn't exactly keen on having his artwork misrepresented by the software created by his own team. That has nothing to do with "lack of understanding of open source". > point -- but "Oxygen" looks to me as the umbrella name of "whatever KDE4 > ships as its default theme". I disagree with this. I've followed Oxygen right from the start back at the Appeal meeting and vision and style have been continously improved but generally have always taken the same direction. > and tweaking, and experimenting... Feels like programming. :) Maybe drawing by numbers does. Or technical design. But in general artwork is a pretty different beast. > Jokes apart, developers are users too. We may be picky users, and > argumentative, but I can't see why developer needs should be dismissed so Because KDE is not the "KDE Developers Environment" but is targeted at endusers. Developers only make up a small amount compared to those and yet again developers who'd care about this particular issue are even fewer (I'd expect in the sub-percent area). I also wonder how many e-mails Apple and Microsoft receive from developers on their plattforms who can't live without custom wm colors ... > on a GTK+ application to change window background color to show it has > focus. Or Java. Or... So I'd rather have a decoration that looks decent Do I understand it correctly that it's not possible to immediately change the background color of the mainwidget of a Gtk/Java application at any moment? Torsten
> 1. The only issue that he insists on is the treatment of window decoration > and mainwidget as a single visual entity. All other issues mentioned > in the "other" bugzilla entry are not things where he has strong feelings. And the only issue I insist on in bug #152030 is that the default KWin decoration is at least optionally able to follow the configurable colors. And, indeed, the fact that it's the only solution I've seen so far that comes reasonably close to solving bug #160117 is a very nice bonus, I admit. > 2. Nuno Pinheiro is neither happy with a fork nor did he seriously > encourage it. One doesn't need to be socially sensible to get that by > reading the thread. But he did suggest that, and while I have a similar position on this, what other option am I left with? (Also changing the bug summary, since neither half of the original one is true.)
> Besides: Most people who have replied in the Bugzilla thread are developers and not users. As Luciano so aptly pointed out, we're users too. Seriously... I liked oxygen as it was up to the point that I actually tried to, er, use it. At which point I quickly hated it. I don't mind artistic integrity... as long as poor usability is not forced on users as the default settings. When you're talking defaults, art must give way to usability (or "ergonomics", to use Luciano's word). > I also wonder how many e-mails Apple and Microsoft receive from developers on their plattforms who can't live without custom wm colors ... ...and this, IMO, completely misses the point. Side note: There is already work in progress about hiding the inappropriate color settings, but that's completely orthogonal to the usability issues.
> Well, draw a mockup and show it to Nuno Pinheiro for his opinion. I can't speak for Lubos but I was hoping the artists would come up with the artistic element of the solution. I really think your complaint is unreasonable Torsten. This problem with the design was reported a long time ago, getting on for 6 months in fact. 6 months later it remains unfixed. The feature freeze for KDE 4.1 is 8 days away. We'd love the artists to come up with a solution which fits in nicely with their original concept but at the same time we also want to use KDE 4 comfortably for day to day work. > But in general artwork is a pretty different beast. We are not preparing artwork to hang on a wall in a museum somewhere though. This is an engineering project. Engineering is about finding the optimum trade-off between various constraints. I don't know if you followed the discussion around the dock changes in the latest Leopard but Apple clearly went through a similar conflict between what looks good and what is functional. In the end even they, a company whoose image is all about design made a few compromises before the box hit the shelves.
"Optimum trade-off" until this point seams to be, anything as long as its colorable, witch goes in oposite direction, I'm wiling to chage it aslong as it dosent the one slab efect. So in the trade-off area I realy dont know wich of us are willing to trade in an honnest way.
Wrong, it's anything as long as it is usable. The coloring trade-off is only the first and only one we know of right now. Please come up with suggestions of how to make it usable again, but if there is only one choice, we are tempted to take it. Still the coloring is a very cheap trade-off which hurts nobody except you as the designer, but certainly none of the users.
> "Optimum trade-off" until this point seams to be, > anything as long as its colorable pinheiro, please re-read the second sentence in Bug #152030 : "I can not distinguish which window is active, which is inactive, neither is it simple possible to see where a window ends when I have 2 or more windows overlapping." This is the heart of the problem and I think the issue that will bother people much more than whether or not they can define customized colours for the titlebar. There is some talk of alternatives in bug #152030 but no screenshots or mockups of alternatives attached to the report. Please, let's see some ideas!
i have some ideas on my blog http://www.nuno-icons.com/images/estilo/nocoloringmoreoptions.png http://pinheiro-kde.blogspot.com/2008/03/active-vs-inactive-part-ii.html but most pople here seem to be mostly wanting to have it colorable.. Show-me a mock that dosent look bad and dosent ruins the one slab look wille being coloreble and you have one happy guy here. As for making the distinction more proeminent Im all for it. Ideas wellcome are more than wellcome, coments one the mock ideas 2.
Unfortunately those mockups rely on compositing to work properly. Do you have the source SVGs for those images by the way? It would be easier to experiment with those rather than hacking the style code.
Man, people is destroying the whole Oxygen "feel". That thing that I only had with Apple software, and I was happy to have on linux as a KDE user. When I saw a screenshot of the new OpenSuse with the titlebar blue I couln`t believe it was Oxygen, because it destroys the whole integrity of the theme.. As a user I think we doesn`t need to change the colors to distinguish between active and inactive. here a screenshot of mac osx in case you didn`t know it: http://www.crunchgear.com/wp-content/uploads/mac_os_x_leopard_800x502.jpg They didn`t needed to destroy the artwork for making a better distiguish between active and inactive windows. Why users love osx when they use it? Because they really priorize design on their products. Oh, and when talking about usability, please, cite tests with real users or well known usability euristics. Something without that is just specullation. One more thing, it`s well known that developers aren`t very good at design, so, for me, it`s a good thing if they respect some design decisions. The are so few good designers on open source world, like Pinheiro, and I don`t think it`s a good thing for the open source world to piss off them.
A Wednesday 23 April 2008 15:01:58, Robert Knight escreveu: [bugs.kde.org quoted mail] of f course :) that's how i do it :) do you want them?
the dev have the power (by code) to limit areas (design, artwork) that they don't really have knowledge... How kwin developers would feel if the code decisions were made by Nuno...
> Oh, and when talking about usability, please, cite tests with real users or well known usability heuristics. What's with this notion that devs are not "real users"? If you read the original bug, you'll see that I'm one of the ones complaining, *based on real use*. I'll point out again; I didn't have a problem with the design until I tried to actually use it... > the dev have the power (by code) to limit areas (design, artwork) that they don't really have knowledge... The devs (and, ahem, the artists) also have a responsibility to listen to complaints from users.
Matthew I realy get ofenden every time you say that, you know me well enough to know that I listen.
@pinheiro: my apologies for upsetting you, but please understand, you still come across as putting your artistic vision ahead of user feedback. To an extent, that can be a good thing, but at some point a compromise must be made. (That, or of course we need a solution that makes all parties happy :-). To which end, would you mind posting a link in this report to an svg we can play around with? Or add it as an attachment if you don't want your server getting beat up.)
> What's with this notion that devs are not "real users"? Well they are real users no doubt about that. The point in case is that in terms of target user base people like you and me are not in the main focus obviously. When Matthias Ettrich called for developers in his initial Usenet Posting he was _not_ calling for developers to create the "KDE Developer Desktop Environment" made by developers and mostly for developers. No, he called for developers to create a desktop environment that is targeted at _end_ users. KDE developers make a very small amount of the whole user base. Assuming an amount of users at the magnitude of several millions they are way below the one-tenth of a percent range. Even if you elevate our importance as KDE developers due to the fact that we are authors we are still less "worth" than a percent. Things that you dub as usability are in reality usually nothing but "comfort" for a specific niche of users (KDE developers) at the expense of our main target user base.
Our target user base doesn't have a desire to differentiate between active and inactive windows? Our target user base is all running on modern hardware with high quality video drivers? I wish we had known this earlier, all sorts of code could have been removed!
Dan, yes our target user base wants all of that 2 i supose, but does it meens that in order to differentiate they need to be painted in diferent colors. Do we still have to be somthing less wen we should try to be somthing more? Maybe we want oxygen to be somthing we in the OSS cant be (i dont think so), but I think we should at least give our best honest try to do somthing that looks good and professional, somthing that gives honour to the great quality of our codebase in oss.
> The devs (and, ahem, the artists) also have a responsibility to listen to > complaints from users. dev have the power to fork... Not saying that people in kwin don't listen to user, or even that artists don't listen to users, but devs must behave as a end user (when treating stuff as usability) and not as a power user with superforkingpower...
I see the discussion heats up again, so here is my evidence: I want the decoration to change color exactly for the users, not for developers. This usability problem really is the first they encountered and that could make them go away. Guess what, from my coleagues no one has good acceleration on Linux, and this decoration was the first problem. This really isn't a problem for the advanced user. I tryed to change the color, I saw it wouldn't listen and I simply chose another decoration. So the idea is to have as few things as posible that would make people go away on the first try.
Can't the problem be solve by a way that doesn't "damages" the design? With a aleatory color on the top? my 2 cents: - Behave like plasma. Active the frame is there, inactive isn't visible - Add a color (yes, that color) line in the middle, above or even below the decease "windeco" (isn't the window a deco herself?) - color the inactive window a slightly 10% sepia tone (like an old paper) - do all the Nuno's voodoo with buttons and gradients and some of above - make a big red cross on top of the inactive window (yes yes the last is a little joke...)
alecs: osx's titlebar it's "blended" with the window, like Oxygen, and I never saw anybody complaining about it.. And it's very unlikely that someone abandoned it because it's not possible to change the titlebar color... I agree with Jorge, it's perfectly possible to solve the inactive problem without changing the color of the titlebar. Anybody saw this: http://files.opensuse.org/opensuse/en/f/f4/OS11.0beta1-kde4-2.png ? This is not Oxygen for me. Well, sorry if i'm being inconvenient, but Oxygen is one of the greatest themes ever made for Linux, if not THE greatest, and I was really excited about it, so it would be very sad for me if someone brake it..
Paulo, to point out the obvious, Mac OS X can rely on the availability of compositing support and high quality LCD screens with good contrast. KDE 4, on Linux at least, cannot. It may be the case that, like Windows, the composited and non-composited cases might need to be handled differently.
Mac OSX runs very well whithout 3d cards at all. I know because I tested it on a old system I have, without opengl support and with an old crt monitor.. One thing I don't understand about X11 is why do we need composite to to argb things.. But that's not my point, if you look at a leopard screenshot, you can see that shadows are not the only hints of inactivity. I'll try to draw a mockup and demonstrate what I'm talking..
I just want to give my humble opinion to this issue. First of all: I like Oxygen. It's probably the most beautiful theme I have ever seen on FLOSS. Especially the icons are really great :-D So coming to the time when I was (only) a user (Dec 2007). I tried KDE 4 in virtual machines. That is: no compositing. Additionally I had bad hardware: a monitor with very bad contrast. White and grey could not be distinguished. Gradients were not visible at all. Not only that I could not distinguish which window is active or inactive (actual state with new monitor), I could not even distinguish where a window ends and the next begins:-( What do you think I thought about the theme? So personally I think that the mentioned concerns are true and I know from myself that many users stay with the default. I did not change the colouring and did not change the windeco. Of course I can't know what the average user wants and thinks. I don't know if art is more important than functionality. I think they want both: a beautiful desktop (which Oxygen provides) and good functionality like easy distinguish of active/inactive windows.
Yes Martin, but if we do the difrence betwin active and inactive without using the "I want to color my windeco" wouldn't you be ok with it? I'm not saying there is no bug in oxygen, im just saying that the bug is, "low contrast betwin active and inactive". And not, "I cant color my windeco".
Of course - I am happy with any solution :-) For me it was not a problem that I cannot colour the windeco (as I said I did not try to change anything). I have seen your mockups and some I think are good possible solutions.
Hi Paulo, > Mac OSX runs very well whithout 3d cards at all. > I know because I tested it on a old system I have, without opengl > support and with an old crt monitor.. I did not say anything about 3D cards. My point was that MacOS X has always been able to rely on compositing - that is the ability to draw windows offscreen and combine the result together into a final image on screen along with effects such as shadows and other adjustments. MacOS could rely on this because Apple was able to pick the hardware and optimize the graphics stack from top-to-bottom to get it to work fast enough with only 2D acceleration. On the X11 platform there isn't the same level of control over the environment so the software has to adapt. > But that's not my point, if you look at a leopard screenshot, > you can see that shadows are not the only hints of inactivity. Indeed. In addition to a nice sharp border there is also quite a marked change in the background colour of the window: http://www.hongkiat.com/blog/wp-content/uploads/leopardpc.png Matthew Woehlke tried changing the colour palette for inactive and active windows. Unfortunately for technical reasons it didn't work well on many systems leading to lots of flickering. I think with Qt 4.4 some of those problems may have gone away. In any case, I think it is important to have a solution which doesn't just involve a cheap copy of <whatever competitor does>.
please, don't get me wrong, I really dislike the idea of copying the competidors either, I just used mac as an example that marking active windows without coloring it can be done in a nice way Well, but I think that now all our problems are solved: http://pinheiro-kde.blogspot.com/2008/04/im-active.html thanks for the insight on the composited thing Robert, but I still didn't get it why X11 can't do composite without things like texture_from_pixmap, but that's offtopic :)
I think this bug should be closed. The bug report is invalid, IMHO, because the Ozone theme clearly isn't superfluous. It solves a real need that real users (like me) have, namely the need to color the windows differently based on which one is active. No one committing to an open source project has the right to expect that they will retain proprietary, dictatorial rights to control what people do with their work, and that includes the artwork. I find the suggestion that the Oxygen theme should not have been branched out of respect for the artist an anti-open-source position. You can dance around the issue all you like, but if you release something under GPL or similar licenses, as Pinheiro has Oxygen, you are actively endorsing people adapting your work to suit their needs, and to release it for others to use. We now have a solution to the glaring usability problem with Oxygen, and it is the fork entitled Ozone. Pinheiro is free to develop Oxygen and address the issues as he sees fit, or not address them at all. I hope it turns out to be everything he wants it to be. Giving users who complain about missing functionality a viable solution is a completely reasonable thing to do, and this bug report seems to deny that simple fact. If you want to talk about what is superfluous, I think we should be looking at Oxygen. Right now, the only reason that Oxygen exists independently of Ozone is to remove the ability to configure one color. So, people who want their window decorations to be the same color as their window contents can either change the now-default Ozone window decoration color setting...or they can install and select the Oxygen theme. Using Ozone seems like less work for exactly the same result. Nonetheless, I fully support Pinheiro's efforts to continue to try to make Oxygen everything he wants from a window decoration. And who knows, maybe if he comes up with something brilliant, we'll want to use it again. But for the time being, by his stubbornness, he has made his branch completely superfluous, IMHO.
"It solves a real need that real users (like me) have, namely the need to color the windows differently based on which one is active." with a solution that makes kde look like kde3 (and all the winfamily...). Its a poor looking solution. There are a lot of styles and do the coulor stuff... Why to fork oxygen if has a so bad usability? Lets make oxygen better. Lets help in the active/inactive problem. Has we have done in the contrast problem. Lets bury the oxygen designers with new ideas (not ideas from the 90's...) for every mock up a critic, a new idea, not cry every time they don't do things the way we would like to be done... "If you want to talk about what is superfluous, I think we should be looking at Oxygen. Right now, the only reason that Oxygen exists independently of Ozone is to remove the ability to configure one color." reversing reality!!!! Every visual idea on ozone is oxygen... who will continue the artwork coherently? Oxygen designers will have to fix Ozone artwork in six months? remember that oxygen exists only to have the same coherent look all over kde4. To avoid to have 30 different styles (keramic didn-t add coherency with crystal icons... for instance? "But for the time being, by his stubbornness,..." I think you are mislead by the way he writes english. And IMHO anchored in a few phrases, 90 per cent of his words are: Yes we have a problem with active inactive Iam working hard trying to solve it = see his blog We need a stab look = like Apple and a coulor windeco ruins it = MSwinlook Lets solve oxygen problems without ruin the looks...
Ok this does it for me :(. Mr. Eric Stith you have no right at all to judge me and oxygen, I have been working in oxygen for far to long to have to put up with this sort of coments. You cant be freking reading the intire thing are you? I'm geting completly tired of this. As mater of fact im relly thinking you Sr. are totaly right Oxygen is becoming completely superfluous, or if not Oxygen at least me. this is completly wrong.
The thing that realy pisses me off is the, "you dont get oss" that makes me wonder what I have benn doing that last 3 years with so much efort, and specialy time stolen from my personal and work life. Never knew OSS ment pissing on top of other people work. And have the right to change it as will. As mater of fact now that you put things like that I think most of the people I know and admire in OSS, dont know anything about OSS 2 couse they stik to their belifs, heven wen lots of people tell them they are wrong. BTW in the past ween I was alone in a belife about some path to take I changed my mind. This was not the case BTW. Think I need some time off.
Just to make one thing clear, none of this would be relevent if not for the fact that for the most part, the work done on Oxygen has been good. It's just that from the perspective of many users there's this one little problem with Oxygen as it stands, one which is easily changed, but which the maintaners would not make. That's the reason the fork makes sense. If the win deco weren't any good, we'd just use something else.
Eric, your rhetoric is pretty short-sighted. The larger issue here is that we have an art team, and that art team needs to have a certain amount of leeway to implement a coherent and recognizable art style, and needs to be protected from whining about short-term difficulties to be able affect long-term progress. Enabling that is a critical issue for the project and an important experiment in the context of free software. Art in free software used to and frequently still sucks; that is a competitive disadvantage in the market, because design does matter. It took us a very long time, as a community and a movement, to attract talent outside of programming, and now that we finally have, for the time being, that aspect needs extra respect and protection, given how young and fragile as it still is. That doesn't mean you shouldn't provide feedback on issues that impact your use of the software, but that you should be patient as the solutions are worked out in a way that recognizes the design team's authority and contribution in the matter. Let's be a little bit more strategic than eat-or-be-eaten. Don't despair, pinheiro: some do get it.
Eike, I think I made a clear point to say that I support Pinheiro's efforts to improve his win deco. But if he wants it to be the default win deco with KDE4, which is supposed to be moving toward a usable product, he is going to have to address the niggling usability issues, or it will start to effect the general impression of KDE. With Oxygen as a non-default win deco, he will have more latitude to express himself without the expectation that he will necessarily solve all the problems that users have. So, going back to the point of my original comment, I think that is yet another reason that Ozone is not superfluous, and that therefore the bug report is invalid. It will give Pinheiro additional shelter from the criticism he doesn't want for his art.
> I think I made a clear point to say that I support Pinheiro's efforts to improve his win deco. It's not "his window deco", it's the window decoration designed and implemented by the KDE 4 art team and part of an effort to execute a system-wide design to go beyond the piecemeal crap we used to have in the past. "He can play in non-default land all he wants, as long as I get my funky colored borders" is a terrible regression on that progress, and I'm saddened that your post continues to show a lack of appreciation for that strategic component. pinheiro not wanting to have criticsm for his work doesn't strike me to be true either, after reading the copious amounts of debate on this issue. Quite the contrary, he has acknowledged the underlying issue and went on to try and come up with a variety of solutions that work in the context of the design. (FWIW, I continue to think that the real fix for this issue doesn't involve the window decoration very much at all, but aim for finally enabling the separation of color palettes for active and inactive windows by default. Colored window borders are quite 90s.)
"he is going to have to address the niggling usability issues" Really, explain me why the only way to resolve this is by looking a Frankenstein 80's/2008's look? Apart from the active/inactive (being addressed by Oxygen team) there's any other "niggling usability issue" cause by not coloring the windeco? because it seams to me that with plasmoids and interactive background, color windeco only helps me to have more elements, more confusion... Is what I think is been done by the Oxygen theme (This is not a Pinheiro's problem I believe, as he's just standing for a team work, it not that "personal", BTW that team happens to be the KDE artwork team). I've criticized the fork because, is not that the style is perfect or there aren't things I would personally change, but I just can't fork because I can... without a future direction. Does the forker want's to take over the oxygen work? There's a team of designer's backing him up? Shouldn't be the designer's/usability experts deciding designs/usability questions and not developers? Isn't that one of the biggest problems in Free Software? And You have to face that there is also a lot of people that don't agree with your point of view. "he will have more latitude to express himself" The Oxygen style is a Oxygen team work, no? "he has acknowledged the underlying issue and went on to try and come up with a variety of solutions that work in the context of the design" AGREE!!! "there's this one little problem with Oxygen as it stands but which the maintaners would not make" The Maintaner does want to solve inactive/active problem... the color windeco is a matter of taste... The underlying issue is active/inactive not "we want 80's windeco on top of a 2008 style" which by the way is what is Ozone... "If the win deco weren't any good, we'd just use something else" IMWO the Ozone is not good (dated looks, not coherent, no future), lets just use someoxygen else :-D
>And You have to face that there is also a lot of people that don't agree with your point of view. This is just hypocritical. This bug report claims that a windeco is superfluous based upon the consensus of an art team. I am saying that this windeco provides a solution to a problem for real users. You are arguing for less user choice, I am saying that more user choice would be good. >Is what I think is been done by the Oxygen theme (This is not a Pinheiro's problem I believe, as he's just standing for a team work, it not that "personal", BTW that team happens to be the KDE artwork team). I don't know how many people are involved, but Pinheiro's comments have seemed to take a very personal tone on this matter. If this isn't correct, consider my comments to apply to whoever is appropriate. Could we please drop the ridiculous line about colored window borders being so '80s, or so '90s, or whatever decade we consider most out-of-style? I happen to like colored window borders, I don't think they look dated, and I don't see that changing soon. This is partially an aesthetic preference and partially a functional preference, and, not surprisingly, there are a variety of valid opinions on what is right. There's been a lot of whining about having respect for the artists, but what about having some respect for the taste of others in general? I really do respect the choice of those who prefer to have a single color for both the window background and the title bar. KDE's greatest advantage, for me, has always been the amount of choice it offers. All I am asking is for the option to change the color if I don't like the dictates of your art team. Ozone provides that, and therefore it is useful, and therefore it is not superfluous, and therefore this bug is invalid, which was my main point in the first place. No one has offered anything to address this seemingly simple logic, preferring instead to complain about receiving the user feedback that they were asking for when they thought that only the developers cared enough to be pedantic about colors, and preferring to patronize me about how "saddenned" you are that I don't agree with your aesthetic decisions. Whether Ozone has a future, or frankly whether Oxygen has a future, has yet to be seen. If Oxygen can address these issues adequately at some point, maybe Ozone will become unnecessary, but in the mean time it might be nice to have something that has the options that current KDE users need to make the switch to KDE4. Now I've said my piece, take it or leave it, and I don't intend to say any more unless someone else finds another new way to misconstrue my comments.
sorry to misconstruct your comment again: "ridiculous line about colored window borders being so '80s, or so '90s," is not that ridiculous when we are speaking of artwork. My comment expresses my hope that Oxygen with be a default, and not Ozone (I personally, as a matter of subjective taste). There are millions of styles with color windeco, so one may use one of them, as one may use Ozone. Its only a matter of freedom of choice My personal view is for default style Oxygen is better. Ozone is as in nature not healthy :-D. My previous comment focus on getting usability in a better way that the past. Maybe Oxygen maintainers could work out a way of having the stab effect and a color line or a shadow or something so everybody is happy. This may be tricky because sometimes less is better that try to satisfy every opinion. I do respect your taste don't get me wrong, Is just my opinion is that is not a good artwork decision for kde 4. I hope that Oxygen cames with a solution that doesn't needs a strap of color on the top. Seams to me a easy workaround. For that to work well the concept of Oxygen style should be made around another thing. The important part of my post was "Dated looks, not coherent." future is too difficult to forecast ;-) and "Is there's a team of designer's backing Ozone"'s future and "there's any other "niggling usability issue" cause by not coloring the windeco?" and "shouldn't be the designer's/usability experts deciding designs/usability questions and not developers?"
Eric Stith I heven might agrea with you on the closing this bug issue. But next time try to have some respect for the people that work in OSS. It hurts like hell after several years of puting all my efort into making this real, being acused of not knowing what oss is. Maybe one day you will create somthing wich you trully belive in, and then you will undrestand us beter. As for ozone I wish it best luck. Honest, I would love to be proven wrong and see ozone perfectly integrated into oxygen. Maybe that would be the day we would remerge. If you think about it, thats how OSS usualy works. If I have ofended any one im, sorry, it was not my intention. If I seeam arrogant and anal, sorry its just that I truly bellived that ozone was not oxygen.
2008/4/28 pinheiro <nuno@oxygen-icons.org>: [bugs.kde.org quoted mail] ANNNNAAALLL?????? <br><br><div class="gmail_quote">2008/4/28 pinheiro <<a href="mailto:nuno@oxygen-icons.org">nuno@oxygen-icons.org</a>>:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div class="Ih2E3d">------- You are receiving this mail because: -------<br> You are a voter for the bug, or are watching someone who is.<br> <br> <a href="http://bugs.kde.org/show_bug.cgi?id=160627" target="_blank">http://bugs.kde.org/show_bug.cgi?id=160627</a><br> <br> <br> <br> <br> </div>------- Additional Comments From nuno oxygen-icons org 2008-04-28 23:55 -------<br> Eric Stith I heven might agrea with you on the closing this bug issue.<br> But next time try to have some respect for the people that work in OSS.<br> It hurts like hell after several years of puting all my efort into making this real, being acused of not knowing what oss is.<br> Maybe one day you will create somthing wich you trully belive in, and then you will undrestand us beter.<br> As for ozone I wish it best luck. Honest, I would love to be proven wrong and see ozone perfectly integrated into oxygen. Maybe that would be the day we would remerge. If you think about it, thats how OSS usualy works.<br> <br> If I have ofended any one im, sorry, it was not my intention.<br> If I seeam arrogant and anal, sorry its just that I truly bellived that ozone was not oxygen.<br> </blockquote></div><br>ANNNNAAALLL??????<br><br clear="all"><br>-- <br><br>Um abra
A Monday 28 April 2008 22:59:04, você escreveu: [bugs.kde.org quoted mail] dude responder ao autor :)
>Eric Stith I heven might agrea with you on the closing this bug issue. >But next time try to have some respect for the people that work in OSS. I don't mean you any disrespect. In fact, most of my initial comment here was intended to address the reasoning of the bug report itself, not the person offering the reasoning, and certainly not you. I didn't mean it as a personal attack on anyone. The bug report complains that forking Oxygen to make Ozone was disrespectful to the artist(s), and I maintain that that attitude is not appropriate for any open source project. I did not say that you or anyone else doesn't understand open source. I only argued against the reasoning of the bug report. >It hurts like hell after several years of puting all my efort into making this real, being acused of not knowing what oss is. >Maybe one day you will create somthing wich you trully belive in, and then you will undrestand us beter. I don't mean to diminish your contribution at all. I just think you should be a little more flexible about it, and understand that people changing it to suit their needs was always part of the bargain. After all, Ozone is still mostly the same piece of work, at least in terms of number of bits if not concept. >As for ozone I wish it best luck. Honest, I would love to be proven wrong and see ozone perfectly integrated into oxygen. Maybe that would be the day we would remerge. If you think about it, thats how OSS usualy works. I'm glad to see you say that. And I honestly hope Oxygen works out for you. >If I have ofended any one im, sorry, it was not my intention. >If I seeam arrogant and anal, sorry its just that I truly bellived that ozone was not oxygen. I wasn't offended, but I was frustrated at what felt like a dismissal of what I felt were legitimate issues. I am sorry that the way I presented my comment upset you. That was not my intent.
Created attachment 24550 [details] mockup of smoother WM-colors integration Since I never got modern svg's, I had to do this based on an older svg (I thought about simply coding it, but the frame-drawing code is actually fairly scary - and no, I didn't write any of it, I only did style code). But anyway, here's my idea for adding color without being so obnoxious about it. The border still seems a bit "strong", but I'm too lazy to fiddle with it a whole lot in inkscape; just pretend it's a bit more subtle even than it is now and hopefully you get the idea. Oh, and I'd probably be OK dropping the extra color on top and having just the subtle edge tint (well, maybe keep it as an option but not the default option), though I'd want to try both ways in actual practice.
My help into ozone... Well I think that trying to blend in a colorable windeco into the oxygen, will never work. So IMO you should not try to blend it, and assume its difrent nature, another atitude could be to try to have no visible border around the window, and just having a bar under and on top, (bit like mac) that way you can brake the wolle unified slab look without framing it, still looks nice. As a side note ( I have thought a great deal about this options and tried several variations, and every single one of them that worked, were very disruptive, the kind of disruptive that opens alot of new bugs). Some times I get the feeling that there is this general idea that presenting a final concept to a designer/artist he can make it look good couse he is a artist and thats his joob, well the truth is that its a bit like how artist tend to think about coders, ( If i can design this how come you cant make it?) In my real life work This situation is extremly comon but has been already delth with, Im a civil engenier and there I'm like the coders saying to an architect that a 70 meters span cant be done without making a really big beam, and he should cumply with that couse its my area. Same goes wen I put a a 3 m wide pilar in the center of the living room wthout trying other solutions with him, he will probaly be prety pissed off and im prety sure I would lose that joob. Any way if i was a architect/designer being told to make that work (ozone), I would start by making a clear distintion betwin windeco and window. Assume that a windeco is a windeco, and make that work.
> mockup of smoother WM-colors integration I think that looks quite attractive myself and would work from a UI perspective, although Nuno is right that it still doesn't really 'fit' with the concept. For non-composited desktops I think it would be an acceptible sacrifice. What does that look like with a dark grey or black tint at the edges of the window instead of blue? Can you also attach the SVG to the bug report, if the size is not too large so that others can experiment?
Created attachment 24581 [details] svg of previous mockup Indeed; how hypocritical of me to forget the .svg ;-). ...I guess I'll have to disagree with the "fit" thing, I've *done* ceramics where the glaze is different for the very bottom. In fact I can turn my head and look at an example of just that (made myself). If the idea is to emulate a slab of clay/rock/whatever, I fail to see why this is incompatible with the edges (i.e. parts that would have a lower Z-value if you were assigning heights to the pixels) being a different color. (I'm still fiddling with alternate colors; in general, dark gray edges seem far more subtle.)
My 2 cents in that direction. From my experiments, white monocrome variations work very well. PLus white is precived has a more distant color so it would be beter for inactive. (but this is just talking about the color being used and that is another conversation.) Side note any one that wants the svg's please poke me, I send some to Robert, but I will not post them here couse 1 they are a mess 2 they are to big.
Er, ouch. That OpenSuse screenshot portraits Ozone in the ugliest possible way... I do hope that it's not going to become default like that. What about we keep Oxygen as default, and users like the ones in here (and in the other thread) can use Ozone as alternative until Oxygen works for all people involved? In my opinion, forking in order to address personal/public/usability/whatever needs is totally fine. What I disagree with is that the KWin default is being changed at the same time - Ozone didn't become the default because it's more popular or better in technical aspects or because it has been agreed on by either k-c-d or kde-artist, but simply because of the KWin maintainer's personal preference. It might be your right to do that, but in the context of a "we are a united KDE community" I still find it an abuse of maintainership powers. It might be necessary to have a "dictator" deciding on this issue (think of another Apple comparison) but I don't see why it should be Lubos' sole decision - artists and usability experts (experts!) have just as many stakes in here, and the fact that the switch belongs to the KWin codebase should not be the all-important empowerment.
I kindly ask people who want to take part in this discussion to check at least basic facts before making comments that are completely off the mark. And, if somebody feels a maintainer of any KDE component is doing their job inappropriately in any regard, feel free to bring it up on the appropriate higher place.
Well, mmkay. Seems that's the classical backfire, and reminds me not to voice my opinion on heated topics. Still, the blue-colored Ozone is really ugly, perhaps it would be worth a thought to change the default back to Plastik instead of doing *that* to new users. And with that unnecessary remark, I'm outta here. See you in a place where I'm hopefully more productive.
I've read the dot.kde digest followed the bug report Bug #152030 comments and this one, and I can't see were is jakob Petsovits wrong... I agreed totally with him. Usability decisions should be adressed by the usability expert that exist in kde. It would be great if Lubos clarify his position. But I do think that Ozone isn't a default (at least in suse's kde 4 live cd), am I wrong?
- "KWin maintainer's personal preference" - KWin maintainer is quite happy with using the KDE2 decoration and as such personally couldn't care less - "Ozone didn't become the default because it's ... better in technical aspects" - that's actually the reason, since Ozone additionally has only code for bug #152030 which also solves bug #160117, I think better technical aspects are quite clear. Of course, having a default decoration where it doesn't take half a year not to reach any reasonable conclusion anyway helps too. - "What about we keep Oxygen as default, and users ... can use Ozone as alternative until Oxygen works for all people involved? " - unacceptable for the default - "abuse of maintainership powers" - it is the responsibility of the maintainer to handle things where no consensus can be reached, which apparently was this case; I don't see this as I did it because I could, but because I had to - "Lubos' sole decision" - it was in fact a suggestion from Oxygen people and it also turned out to be the only solution, no matter how ridiculous Maybe I could continue, but I have yet to find at least a single thing in comment #56 that is not just personal opinion or plain wrong, so I guess this is enough. And yes, Ozone is now the default, so much for your careful reading, it is even mentioned in the very first sentence of this bugreport. And now, if you excuse me, I'll go again doing something actually useful, which cannot be quite said about this issue, until the practical ignorance of bug #160117 from the Oxygen side, just like with bug #152030, will end up with me having to do something about it again, and I'll get all this rubbish again. Just in case I sound upset, that's because I am.
Absolutely correct Lubos. Jakob you should really do your homework better, what any distro out there shows you as KDE4 desktop is what they want it to look like, not what the KDE devs/artists/whoever decided to be the default. Install KDE4 from source and you won't see a single difference between Ozone and Oxygen, unless you start playing with your window decoration colors.
Lubus its your call, that was quite obvius, but in respect to the "practical ignorance of bug #160117 from the Oxygen side" its not true, ask any of the oxygen coders.
> you won't see a single difference between Ozone and Oxygen, > unless you start playing with your window decoration colors. true. You need to disable blend title bar colors also. This is the default on Debian. Jakob seems to say Ozone is ugly, but I prefer something "ugly" and usable than "beautiful" and not usable at all. I would like to hear usability expert here and not artists. Lubos decision +1
Comment #62: Then it would be nice to see a reply in bug #160117. I myself haven't noticed any real progress on the issue (no comment in the bugreport from anybody from Oxygen and no changes in SVN, and that's what I meant with practically ignoring it) and 4.1 is getting close.
Fathi Boudra if you have the patience to read this overly huge thread and the other one, you will read the usability expert's opinion on the subject, that I fully agrea with btw.
"- "abuse of maintainership powers" - it is the responsibility of the maintainer to handle things where no consensus can be reached, which apparently was this case; I don't see this as I did it because I could, but because I had to " Is your decision supported by the usability expert, that is in fact the most capable person to make such decision or to say "unacceptable for the default"? If that is the case your're in the right track, if not, your option and decision such always be under the umbrella of the usability expert, and a consensus with the art team. If not there will be no real possibility to have a coherent visual experience in kde 4, and we will end up to be another Frankenstein looking/feeling/experience desktop. Because every decision will depend on a random developer, without the necessary coordination with a usability expert team. Without a common view on how it should feel/look the desktop. We should be like OS X but open. Or do you think that every OS X dev agrees with the looks/feeling of OS X? But OS X works because coherent decisions are made. Acts like yours, makes me think that a good looking and coherent experience will never be possible in a free software desktop. "until the practical ignorance of bug #160117 from the Oxygen side" Do you read any oxygen blogs?
> Is your decision supported by the usability expert I haven't seen "usability experts" commenting either way. What I've seen a LOT of is users calling for configurable color, more obvious title bars, etc., all of which support ozone. Incidentally, ozone looks no more or less "ugly" than oxygen with non-KDE4 windows on the same box.
As far as I can tell, there is virtually no difference between Ozone and Oxygen. Except that as of the recent shadow changes, each decoration now has its own shadow bugs. As far as colouring the active window goes, Ozone and Oxygen are now identical.
It feels like there should be an "I told you so" in here somewhere. I switched to Oxygen just now. Strangely enough, it looks a lot like the deco I've been using for the past month or so. In fact I can hardly tell the difference between the two (for active windows, anyway). I'd like to see one teensy option added to Oxygen, for the border; always use window colors, always use titlebar colors, use titlebar colors for active windows (the third being "the current behavior"). After that... yeah, I'll join a petition to remove ozone, assuming seli is satisfied with the new Oxygen.
Can sone one help us in making kcm beter, I would like to do the active shadow beter and heven try to use 2 colors there so its "more active" and has better contrast. so as color my windeco goes one would be able to color his active and inactive windeco by chaging the shadows, ofcourse hving the inpact it now has on non composite capable sistems.... think this would be a nice way to kill this bug once an for all....
SVN commit 1023636 by hpereiradacosta: Moved Nitrogen to Oxygen deco, and removed Nitrogen. It is believed that Nitrogen is versatile enough to satisfy most users, and that it is good-looking enough to make Nuno happy. CCMAIL: kwin@kde.org BUG: 160627 M +1 -1 clients/CMakeLists.txt D clients/nitrogen (directory) A clients/oxygen (directory) clients/nitrogen#1023631 M +5 -5 clients/oxygen/CMakeLists.txt M +4 -4 clients/oxygen/config/CMakeLists.txt M +2 -21 clients/oxygen/config/config.cpp M +1 -1 clients/oxygen/nitrogen.cpp M +2 -2 clients/oxygen/nitrogenclient.cpp D clients/oxygen/nitrogenclient.desktop A clients/oxygen/oxygenclient.desktop M +4 -4 kcmkwin/kwindecoration/kwindecoration.cpp M +1 -1 plugins.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1023636