![]() KDE Developer ![]()
|
> not sure if the gradient gives it a style slightly different from the rest tough?
It does a bit. I vote for changing the rest, and not this, because it is f-star-star gorgeous! |
![]() KDE Developer ![]()
|
Completely unrelated from the taskbar: i have a little comment about the window shadow: perhaps it looks too much a "circle"? That is the same problem current oxygen windows decorations have as well, that can be syntetyzed in two points: * the blur of the shadow looking too much like a flat gradient * the radius of the blur being the same as the radius of the rounded corner the last version of air has shadows that while yes, they really looks kinda over the top since are huge, they have a radius way bigger than the corner, that makes them look more natural. i am now trying to do some experiments to see if a gradient can be kept for shadows (i hope, but doesn't seem much possible to make it look just right) or if embedded pixmaps are really needed. I pushed in panel-background.svgz some experiments, the one on the right i think it looks more realistic (even tough perhaps is a bit too contrasted, but opacity can always be tweaked) ![]() |
![]() KDE Developer ![]()
|
but goes a bit away from the style was pretty much agreed upon, is just "taking a decision and stick with it" capacity that i'm a bit concerned upon. A kindof "freeze". that will have to be done some point or another, in which regardless on how much better a new idea may be, will be a "too late, decision taken" ![]() |
![]() Registered Member ![]()
|
For clarity, while the direction is definitely toward a much flatter design, it was never intended to be completely flat. The intent from the outset was to use depth, sparingly, to communicate substance and meaning. In this case, depth is intentionally used to communicate substance - tasks with visible windows on the screen. Indicators for normal and focused windows have a perceptible substance to them. Whereas indicators for minimized windows and mouseovers have a purposefully flatter, more ephemeral quality. Similarly linedits, while flat when unfocused, have some depth and substance when focused. Buttons are flat (in the latest update), but have some depth and substance when pushed. Active windows (in the mockups) have a deeper shadow than inactive windows. My first attempt at the tasks theming was flat, just like the mockups. In actual use, however, it felt... lifeless... just some splotches of color painted on to the strip of paper representing the panel. The most consistently visible part of the Plasma desktop deserved more than that I think. So I experimented with several variations and kept coming back to this one, every time. (I took a few days to evaluate it in use to be sure). In use, it simply felt the most natural and honest to the mood goals. I won't argue for much, but I'm arguing to preserve the tasks design as you see it here. ![]() I'll do everything I can to maintain some consistency in the sparing use of depth through the design. It will occasionally mean revisiting a few things here and there, as long as we remain consistent with the overall mood goals. |
![]() Registered Member ![]()
|
Great catch Marco, those experiments help a lot. I'll be sure to take a look at it tonight. ![]() |
![]() KDE Developer ![]()
|
|
![]() Registered Member ![]()
|
Thanks so much IVan! That helps. It's a little difficult separating the layout issues from the theme issues but here goes: a. The panel padding/margins in your screenshot are almost non-existent unlike my screenshots from my plasma1 install. Is it a function of panel height? Or are panel margins handled differently in plasma2? b. Glad to see the vertical scrollbars rendered that way on plasma2. My plasma1 install had some inconsistencies (different widths). Also, I'll assume the lack of a top margin on that vertical scrollbar is just an applet layout issue. Let me know it's something I need to do in the theme. c. Also glad to see the arrows rendered at a reasonable size. It'll be nice once we get the remaining visuals of the theme sorted out so we can start tackling some of the low-hanging fruit in the in-applet layout designs (spacing, alignment, typpography, etc.). Slowly but surely we're getting there! |
![]() KDE Developer ![]()
|
looks like for some resons it sets dpi really, really low, most layout issues seems to come from that |
![]() KDE Developer ![]()
|
|
![]() KDE Developer ![]()
|
|
![]() KDE Developer ![]()
|
|
![]() KDE Developer ![]()
|
Some other screenshots.
This is still a quick experiment i did in the code, is not pushed yet, basically is to implement the mockup part where open popups and active systray icons are painted like active tasks. if it makes "design sense" I'll push it so work can go on: ![]() Kickoff open, the k button has the same element of the taskbar visible to show it's open (kickoff tabbar itself should receive the same treatment probably) ![]() Calendar open, same effect for the clock size ![]() Systray open, no systray applet chosen, so completely highlighted ![]() Systray open, device notifier highlighted (yes, it thinks i have a floppy, and no, i don't have one... don't ask ![]() ![]() Systray open, battery (whose icon is in the popup) highlighted, the highlight of course should be rotated and face the plasmoid area (therefore i would remove the vertical line) |
![]() KDE Developer ![]()
|
> and active systray icons are painted like active tasks.
> if it makes "design sense" I'll push it so work can go on I do like the idea to (finally) be able to show the indicator of where the pop-up came from, but I don't think the tasks graphics should be used*. If it was a custom theming element, I'd give it +1 without a hesitation. (hell with it, not +1, but +10^100 ![]() If we go for it, we need to resolve the alignment problems - the bars go over the icons in the system tray, but not in the tasks applet. * I don't mind it for this theme, but there sure will be themes where it just wont fit. I was already bitten a few times that some element's graphics start to be used in a totally unrelated place, so I'd like for us to ease on the 'no new theme elements' policy. |
![]() Administrator ![]()
|
Don't know if it makes "design sense" or not, but I love it! I personally liked the flatter "indicators" more because I think they fit the overall design better. However, I also like alake's reasoning about not making everything completely flat; it just so happens that I prefer the flat version in this case, and don't think the gradients add any important visual clues. Keep up the great work!
Problem solved? Please click on "Accept this answer" below the post with the best answer to mark your topic as solved.
10 things you might want to do in KDE | Open menu with Super key | Mouse shortcuts |
![]() KDE Developer ![]()
|
I'm seeing that actually looks so-so when used with an old theme with a classical button-like taskbar entry, so may make sense to have a new element. Another that will probably need to be a new element is the tabbar (would really like to give to it the same look) depends tough also how much we want to stay retrocompatible, I'll still put a fallback to use button+frame as now? |
Registered users: Bing [Bot], Google [Bot], Sogou [Bot]