jensreuterberg wrote:Thats lovelly Marco! Although I would prefer the non-pressed button to be flatter and just light and the header to be lead by a graphical element as well as being on the same line and with an explanatory subheader.

ah, yeah, i didn't pay attention at the layout at all, i just done something that kindof reminds the systray just to illustrate the control elements themselves

I know we talked shortly about this but you mentioned the problems with not having transparent backgrounds ... You know where I'm going with this? What do you think about saying "screw it" and just do them opaque?

Is mostly due that following an old decision on still maintaining a bit of transparency, so then I spent around two months rewriting the blur effect in kwin (i'll give some screenshot eh ) that could have be spent.. on other things so is already a bit invested on that

About pixmaps in SVG's can you be more specific with the issue? What are you referring to? The "in application shadow" or what exactly?

Ah, right, this misses a lot of context
in inkscape, extensions->images->embed
the svg support of Qt is very basic so things in inkscape as blur and masks are not supported, so those effects if used need to be rendered as png and re-imported (yeah, i know quite crude (tough i kindof like this limit since pretty much forces to have simple things)
so yeah things like blurred shadows would have to be imported pngs, this works well, but i like to keep it used more rarely

Finally about the June release - remember that the plan is to release slowly and bit by bit. Meaning that the changes for June will be small but more will be added with further editions - that means we have to be able to have a goal to aim for even though the goal isn't realized June.

+100. what i would like to do, is to have a first release with very few visual changes and then ramping up release by release to the final vision

Ok about the transparency:
Thats a bummer - a thing thats become apparent is that transparency isn't popular in the mockups - and tbh it doesn't work with in-app shadows. Should there be a secondary theme planned with opaque objects and dropshadows and use a plain flat transparent one? Sadly that means a theme that is essentially the same thing.

As for blurred shadows:
since the current theme supports window shadows - it can't be that much of an issue or are you referring to in-app shadows? Can't that be solved with solid color imports without having to reimport the blur/transparency of shadows? Although that might look weird in the end. Again perhaps this could be solved through two themes - one transparent "Oxygen" theme and one Opaque where perhaps the removal of transparencies can weigh up for the use of in app shadows.

As for bit-by-bit release:
Then thats what we're doing. Seriously I think thats a clever thing in general. Do some change for June and then just roll out. The question is can we do it or will it end up being dropped midwork?

We really need to get the two first issues sorted before ANY more work can be done. I don't want people working in vain on a huge project and dumping hours after hours of work and then half way in finding out none of them will be done or can be done.

So what do the rest of you prefer:
1= Scrap transparency and go with solid?
2= Do two themes one Oxygen Next and one Paper one?
3= Go with Oxygen instead?

I started fiddling with a light weight version of the flat theme - without any compositing - just to see if it was possible to get a a nice shadow effect without it (stole your slider handle btw Marco)

Just as test

Ok everyone, this is the icon sketches Acidrum is doing for Plasma NEXT. Now we all know what a huge job that is and I want all to be supportive to Acidrum and help him out if he needs it. I will post them on the blog for tomorrows "Monday Report".

And yes they are squared - even though the debate was raging concerning whether to have shapes set or with different shapes. This was a choice made by me after listening to the needs of the Plasma Devs about having perfect pixel alignment which is close to impossible to achieve logicly with "different shaped" icons because you have to count in things like weight and make certain its placed evenly so as to not appear to be misaligned. It is also aesthetically what we need.

I am backing this 100% and I hope you can all do that too.

notmart wrote:Weekend scratch-an-itch project:
This is the idea i was toying with:

Love this general idea Marco!

notmart wrote:Weekend scratch-an-itch project:
This is the idea i was toying with: [...]

Something like this is what i wanna do.
* is the (Tilain)iconsize ok for everyone? (16x22;HxW, on a 24x24background, of course), so maybe we could re-use the most of them (some needs changes)
* i would prefer no border. in composited mode there is no need for because of the shadow. only without compositing a border would be good
* for the shadowing system, the current one (maybe a little smaller) is good, because otherwise we will have a shadow problem in some cases, when a panel/widget is on the other side of the screen. Maybe we could talk to the kwin guys, to make the shadow dynamic and have a real light spot on the desktop, so that the shadow works dynamic to the light spot?dont know if this would cost much performance
* no shadows inside a widget, no highlight "shadow" or something like this. we could give the border a highlight color, but no shadow
* only a really minimal transparency, so that we dont need background blurring (pro performance).

plusfabi wrote:

notmart wrote:Weekend scratch-an-itch project:
This is the idea i was toying with: [...]

Something like this is what i wanna do.
* is the (Tilain)iconsize ok for everyone? (16x22;HxW, on a 24x24background, of course), so maybe we could re-use the most of them (some needs changes)

I still have to talk with the others, right now we have the systray icons with a 24x24 size constraint, all the other icons are 22x22, i would like to get sizes uniformed, i'll have a talk with the other developers to see if the square will in the end be 24x24 or 22x22.

Tilain icons.. I quite like them. probably not all of them are completely suited but is a good style since is very simple.

plusfabi wrote:* i would prefer no border. in composited mode there is no need for because of the shadow. only without compositing a border would be good

often a "pixel contrast" is used anyways to make things look sharper, but if is decided this way, for windows like the popups and the panel the backgrounds are different images for composite and non composite, so is possible

plusfabi wrote:* for the shadowing system, the current one (maybe a little smaller) is good, because otherwise we will have a shadow problem in some cases, when a panel/widget is on the other side of the screen. Maybe we could talk to the kwin guys, to make the shadow dynamic and have a real light spot on the desktop, so that the shadow works dynamic to the light spot?dont know if this would cost much performance

Martin Graesslin should have the last word on that, but i think that it's quite unlikely, since the act of passing the shadow pixmap to the window manager is quite costly, couldn't be really be updated many times per second

plusfabi wrote:* no shadows inside a widget, no highlight "shadow" or something like this. we could give the border a highlight color, but no shadow

on that i trust you guys

plusfabi wrote:* only a really minimal transparency, so that we dont need background blurring (pro performance).

ah, no, the point of the transparent theme is pretty much to have the blur since it has to stress test the api to control it from the theme

the mockup looks nice btw (the slider thing looks like it does have a shadow tough?)

btw if the video card doesn't support the blur shader, another background gets used, so it can be much less transparent (window elements can have 3 copies: without compositing, with compositing and with compositing and blur)

Another thing, i was asked exactly how much transparency is needed.

So, for the plasmoids (widgets/background.svgz) pretty much the amount you said like ~80% opaque should be good (but we can experiment later)

for the windows (widgets/tooltip.svgz, widgets/panel-background.svgz, dialogs/background.svgz) the resulting apparent opacity is very differnt from the opacity of the window itself, so a ~30% opacity, will result in the end in around ~80% final result, the sv is just to give a slight tint, all the rest is done by the shader.
(aditionally there would be the shaderless version that would be 80% as the plasmoids background and the opaque version completely opaque and with the edges pixelated)

anyways, most of the controls should be pretty much independent from how much transparent the backgrounds are in the end.

as a base, air should be used, from
http://quickgit.kde.org/?p=plasma-frame ... heme%2Fair

(using git would be great btw)

With some inspiration from you lot, I started on mocking up possible apps...



Full-size here: http://wstaw.org/m/2014/02/18/mockup_b1.png

I'll take a stab at a few other apps soon...

notmart wrote:Another thing, i was asked exactly how much transparency is needed.

So, for the plasmoids (widgets/background.svgz) pretty much the amount you said like ~80% opaque should be good (but we can experiment later)

i think we should not go below 95% for any of them. There is some bad thing in air. you see it on screenshots, you really like it with all the blur. now you install it and because of your limited hardware, there is no blur, more white, and you start to feel bad for your computer in some way. I dont want this. i wanna give everyone the same fresh feeling on the desktop side. for modern hardware and for the older (or much to modern ) stuff.

Next is that we dont know the background image or whats behind a plasma widget, even with blur there are much cases when you cant read the text. now we could use some kind of halo effect around text but i feel ugly with it.


first 2 -> 80% +blur
secound 2 -> 95% +blur
third -> 95% without any blur

notmart wrote:(using git would be great btw)

sure is there a little howto how to get access and how to controll git?

Next is that we dont know the background image or whats behind a plasma widget, even with blur there are much cases when you cant read the text. now we could use some kind of halo effect around text but i feel ugly with it.

That's the point, in plasma1 it only did blur.
what i'm trying to say since several posts is that in plasma next it doesn't only blur. the theme can control 3 parameters:
the contrast of the pixels of the background between each other, their intensity (changing their tonality), their saturation (changing them from black and white to flashy colors)

this is an example with contrast=0.1 intensity=1.9 saturation=1.7


the actual svg has just 30% opacity (really , but since the contrast of the pixels is slashed by a factor of then, readability even over a very dark and contrasted background is perfectly safe.
the optical difference compared to just a more opaque window, is that color data is preserved more, so you just have a slight tinting of the windows. phisically, is what happen on a frosted glass when you add a component of incident light, that overpowers the light that arrives from behind the glass.

notmart wrote:(using git would be great btw)

sure is there a little howto how to get access and how to controll git?

well, you can start with
git clone git://anongit.kde.org/plasma-framework.git

an howto is there
http://techbase.kde.org/Contribute/Get_ ... or_Account
then asking for push access for your account on identity.kde.org

I started doing this yesterday and then finished it today as a sketch sort of riffing of the ideas so far.

Fabian:
I think I can say with some confidence that a halo effect around text is a massive no-go area.

Marco:
So 80% opacity is the norm we're going for? (plus blur and desaturation etc etc etc)

jensreuterberg wrote:Fabian:
I think I can say with some confidence that a halo effect around text is a massive no-go area.

Marco:
So 80% opacity is the norm we're going for? (plus blur and desaturation etc etc etc)

yes, i would say so.

maybe you can add Sebas (or i can ask an admin as well if you can't, that is, if you are fine with it too in this forum to have one final opinion?

Go for it!