9

[img ] http://owncloud.xapient.net/tp-users/us ... hadow1.png [/img]

all three items on this screenshot should have the same "z-index" (panel, window, window)

therefore none of them should drop a shadow on the other one. (it's okay most of the time but not in maximized/tiled mode)

i find it somehow disturbing - it looks weird to my eyes and it doesn't make sense either
the dropshadow of the panel looks most disturbing when the panel is on top of the screen and the shadow drops on the window decoration of a maximized window.


please martin g. (or anybody who can ^^) - would you fix that?

But it tells you wich window is the active one

By default Windows don't have a "Drop Shadow" but active windows have a blue glow. This is to help identify the active window as markus2107 already wrote.

Given that this is a very useful feature it will of course not be removed.

Concerning inactive windows and panels: yes there is a shadow and yes it is there to also indicate the position in the stacking order. E.g. a panel is on top of other windows in the stacking order and by that casts a shadow on the windows underneath.

We have support to disable shadows in the window decoration but KWin will never get support to disable shadows overall. Shadows are a service provided by the Compositor to interested parties (e.g. Window decorations, Desktop Shell) and completely controlled by the interested parties.

does a maximized window also drop a shadow or glow?

(name it however you want.. it's just a color and still looks like the one is hovering over the other which just isn't the case)

i didn't ask to disable the shadows or glows entirely.. just for tiled/maximized windows (if the desktop is completely covered)

on the right window i don't see the glow on the side,top or bottom of the window - why must i see it on the left side where it glows into my other equally important app..

it's okay for the panel to drop a shadow on the desktop but my window is the most important thing on the screen - so the panel has to be quiet and stop dropping shadows on it. (again.. just when maximized and tiled)

have you ever tried a top panel ? it really looks awkward when the top panel drops it's shadow on the window decoration.

i just read about rewriting the window tiling functions in javascript and thought it should be possible to fix this "papercut".. i know you are not a graphic designer but a dedicated programmer - so it probably isn't something to "fix" at all (at least from your point of view)

that's why i posted it on brainstorm to find out if others agree..


@marcus: so does the windowtitle and the taskbar but i had to take a close look to be sure (thats how important this feature is to me ^^) the only thing that matters IMHO is the blinking text-cursor and everyone else who does not work with the keyboard that much does not need this at all

fortunately on kde the mousewheel is functional on non-focused windows too (not like in win7 - god i hate this )

No one is talking to disable all shadows, only from the edge what is snapped to edge of other window or screen/panel.

The shadow (what the glow is as well, it is just with different color) does have great visual information when windows overlaps each other, but when window is snapped to other window, it should be cut off from that edge.

With the default Oxygen color shadow the snapping effect does not look so bad, but when user wants just black/dark/stronger shadow, it comes a problem.

These are the reasons why we developers should not participate in brainstorm discussions...

Fri13 wrote:No one is talking to disable all shadows, only from the edge what is snapped to edge of other window or screen/panel.

The shadow (what the glow is as well, it is just with different color) does have great visual information when windows overlaps each other, but when window is snapped to other window, it should be cut off from that edge.

I'm sorry to say that this would require information we don't have. While rendering e.g. the Shadow of the Panel we have no idea whether windows border to the panel. Neither has the panel these information.

Concerning the window shadow the situation is the same: the shadow is provided by the decoration, but the decoration does not get the information that the window is quick tiled. And overall we don't know whether two windows border to each other. The relations between the windows is unknown. Changing that is non trivial

Fri13 wrote:With the default Oxygen color shadow the snapping effect does not look so bad, but when user wants just black/dark/stronger shadow, it comes a problem.

We developers try to get the system perfectly configured and tailored for the defaults. If the user changes defaults it may feel no longer that good. That might sound bad, but consider that we allow to change the defaults at all! It is for us developers impossible to develop software which suits all needs. This is a case where I would say that the user's need for shadows for quick tiled windows looking good after changing the good looking default shadow is less important than our need to keep the source code complexity low and having good performance.

And that's why I think we developers should not participate in brainstorm. We can block all suggestions just with saying "technical reasons"

mgraesslin wrote:And that's why I think we developers should not participate in brainstorm. We can block all suggestions just with saying "technical reasons"

Yes,of cause. But on the other side, ideas with more user interests will discussed three years. There will be mockups created, research done, useabillity questions rised, or comparisons to other DE/OS. This also takes time. Im not at brainstorming because I want to have seen my own feature wishes integrated (sure I couldn't avoid this in every scope). I want to give some kind of input to get kde to a better product (same as reporting bugs). As non coder I see it as my way to contribute according to my skills.
If a wish is not feasible, bad in relation of work and effect or just politcally not wanted. It's OK. But if it's articulated then the community don't need to discuss furthermore. The time could be used for other things in live.

If it's sound harsh. Sorry for that. It shouldn't. Just want to give my point of view.

no developr shout ever say.. "not possible, technical reasons" ^^ (an honest answer would be.. not worth the work in my opinion)


AFAIU the window decoration would need to be able to turn of shadows only for specific windows and it would have to listen for a "turn of shadow now" signal... also the new tiling effect should send this signal...

well.. i've researched a little bit.. the gnome3 panel doesn't seem to drop a shadow at all (therefore no shadow on maximized windows) BUT they have JUST implemented what this idea is about.. no shadows on tiled windows

i think i'll switch to gnome april april .. just kidding

A very interesting discussion and on a subject I'm particularly passionate about.

These are the reasons why we developers should not participate in brainstorm discussions...

While I cannot tell you what you should or should not do, I think comments from developers are welcome from the viewpoint of ordinary users. I actually think I agree with you that developers should not get too caught up with the process of kicking around ideas, but as knowlegeable decision makers your honest perspective of the bigger picture is valuable, save individuals from wasting time on mockups and design feature requests that, for other reasons will never see the light of day. It goes without saying of course that an honest and truthful reason or reply against a user-request needs no defending. Period.

However, if I could throw my 2c worth in...
I appreciate that the default themes or the standard look of KDE is of major importance, based on the principle of 'first impressions'. No arguement there. And for some this look will be perfect, for others satisfactory, and dare I say perhaps a minority might find it just downright ghastly lol! And this is both understandable and unfortunately (at least for some) a situation that will always be.

But it should be the goal, and I say this sincerely, of every developer of KDE apps or desktop elements to create in such a way that ensures a consistant look compliant with the visual guidelines. If this was the case, users could switch to a dark theme, plasma or otherwise and not find aspects of the desktop environment retaining hardcoded colors or images from the default theme for instance. And I say this so adamantly for one reason alone; the goal of KDE was never to be just another d/e. It was intended to be the BEST d/e. Desktop theming and athestetics generally are considered a poor cousin to feature rich, functionality and stability everywhere on the interweb. However, everywhere on the web has an excuse for such visual inconsistency... that is they are NOT the best and NEVER aspired to be.

In saying what I just said, two things automatically come to mind. Is it possible to ALWAYS create in such a manner? I don't know. But I'm guessing Mr Developer does... And if Mr Developer's app or widget or whatever fails this 'scrutiny', then I'd like to trust that he/she had made every effort in this regard. The second thing might be a little abstract in a sense, but if the above was indeed the case then ordinary users, contributors of themes and budding designers might have a more level and consistant canvas on which to ply their talent. And then questions like the OP's and other similar changes might be able to be considered.

To be clear I'm not trying to undermine anybodys work. I just feel not enough consideration is given to consistency is all. I think it is equally important.