situation with window decorations
Hugo Pereira Da Costa
hugo.pereira at free.fr
Mon Aug 31 03:28:49 BST 2009
(ok. Original email was sent to the wrong list. Re-sending to
I'm trying jump in the thread on
oxygen/ozone/nitrogen, since I originally forked oxygen into nitrogen on
Few comments to some of the other discussions in the thread
- A not very constructive one: I love oxygen (the style and the wideco),
this is the primary reason why I switched from kde3 to kde4.
- on nitrogen configuration dialog being messy: this is historical.
Originally, nitrogen was just for me and had only flags to turn off the
window separator and the scratches. Then since it was working well, I
put it on kde-look. There it had more success than I originally
expected, and since then I've been basically putting (almost) all
requests in there from the comments I got. Hence the mess. I have no
experience on how 'regular' users actually use kde, and kde-look users
are already advanced, I believe, with respect to regular users. Now I do
think that oxygen decoration has too few options.
- I agree that having nitrogen into kde (as opposed to kde-look) put
more requirement in terms of clarity of the options, simplicity of the
configuration, and matching with the rest of the work. Open for
- on coordination: indeed I was first contacted by the oxygen people
(Nino, Boemann, others) to code directly into oxygen windeco. What has
stopped me to get heavily involved in this so far is just 'coding
details'. At that time nitrogen was already quite advanced, and the
implementation of the "exception" handling (window-specific decoration
options) required quite serious code changes. All other options came on
top of that. So that: adding the "exception handling" in oxygen would
change the oxygen code a lot, at once (which I was reluctant to do so
far, by respect for other developpers), and porting the other options
from nitrogen to oxygen without the "exception handling" was equivalent
to rewritting them from scratch. Hence my lack of motivation (it's
basically doing the same job twice). On the other hand, I got much more
enthousiastic about Lucas suggestion (because it represents less work).
Might not be optimal (Oxygen/ozone/nitrogen), but I think
oxygen/nitrogen only (as Lucas just committed) is a reasonable
compromise, for the time being.
I acknowledge the oxygen people concern about keeping the 'basic' oxygen
configuration simple, and consistent with the oxygen style.
In fact I have another suggestion, to minimize the amount of duplicated
work: basically the only difference (today) between oxygen and nitrogen
is the amount of options _made_ available to the user in the
configuration window. What would be nice, I think, would be to have all
nitrogen options implemented in oxygen directly (and have only one
kwin3_oxygen library), and have two configuration libraries
(kwin_oxygen_config and say kwin_oxygen_advanced_config ), one with
'basic' configuration that would only implement a subset of all
available options and would be similar to the current oxygen
configuration, and an 'advanced' configuration, similar to a
'cleaned-up' nitrogen configuration, with all options. (and available
with a different name, say "oxygen (advanced)" in the windecoration
combo-box). That would minimize the amount of code, and make it much
easier to keep the two decorations in sync. Does that make sense ? Does
one think it is feasible ?
On nitrogen available options:
- size grip and no-border: I don't like the use of 'ugly'. This is a
subjective statement, and I don't find it very constructive I think. I
like "I don't like the size grip" rather than "the size grip is ugly".
In fact: bespin has a size grip too; some user on kde-look commented
that they _really_ liked the "no-border + size grip" option; and
finally, I got the idea from another famous (and quite polished) OS
which implements just the same (and I really like their version of xterm
with no border and a size-grip). I'd really like to keep it, (now that
it is working well, as far as I can tell). I agree that the appearance
of the size grip could be made better though, and that it conflicts with
the status bar of some applications (amarok, kopete, konqueror, to name
a few). This can be overcome by leaving some extra space free on the
right side of the title bar (I did that for some private applications),
and could even be implemented in the oxygen style directly.
- button style: this is historical. Nitrogen started with kde4.2 flat
oxygen buttons, then followed oxygen style when moving to kde4.3, and
since people wanted both on kde-look, I kept both. But this is a pain:
button drawing is all QPainter stuff, so that each style is a totally
separate method call. Hard to maintain. I'm unclear on how themable the
"default" decoration should be: why two button styles ? why not three
(like adding the kde4.1 raised buttons, as suggested), or four ... Maybe
it is better to keep only one, and leave the themability stuff to
decorations like deKorator, and aurora. I've no objection against
- button size: I would like to keep it, I actually think it _is_ a
useful feature for disabled people (or when using very large screens).
- scratch line: no preference whether one should keep the option or not,
but if we don't, I'd rather have the default be 'no scratch line'
(notably because scratch lines and large buttons don't fit well together).
- blue glow for active window. I don't like it (personally), although I
understand the purpose. I'd be inclined to keep the option.
- separator: I like the decoration without it, but I think it is
necessary to keep it for non kde applications with incorrect window blend.
- background style (radial blend or solid): same as above. The issue is
with non kde applications.
- title bar color: I have no opinion. I always used the 'window content'
colors, so that I would have no objections against removing the option,
but as far as I understand, a large number of people ask for it ...
Also: I agree that "flags" is not a good name for a group box. (and that
"layout" does not exactly match the content of the left group box of the
configuration). So far I could not come with a better naming, though.
Suggestions welcome. (as well as any other suggestion to make the
configuration window look nicer. I'm not good at these things.)
More information about the kde-core-devel