situation with window decorations

[Nuno Pinheiro]

A Segunda, 31 de Agosto de 2009 03:28:49 Hugo Pereira Da Costa você escreveu:
> (ok. Original email was sent to the wrong list. Re-sending to
> kde-core-devel)
>
> Hi,
>
> I'm trying jump in the thread on
> oxygen/ozone/nitrogen, since I originally forked oxygen into nitrogen on
> kde look.
> 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
> suggestions.
>
> - 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.

does not need to be too simple just not a overly complex UI. 
there is 2 ways to negate information, first way is not to give any, the 
second is to give a 5000 page report on it.... I think the first one is at 
least more honest :)



> 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.

several things we can try in that department

> - 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
> dumping it.

agree


> - 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).

also agree


> - 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.

the idea is to be any color you so which based on KCM .... actually 2 colors 
for contrast, so it would look like plasma glows or any way user would see 
fit.


> - separator: I like the decoration without it, but I think it is
> necessary to keep it for non kde applications with incorrect window blend.


+1 in advance mode

> - background style (radial blend or solid): same as above. The issue is
> with non kde applications.

+1 in advance mode

> - 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.)
>
> Hugo

-- 
Oxygen coordinator