Mockups/new design discussions

I can hardly see any difference (at least on this screen, maybe later on my notebook :smiley:) in x+1 or x-1.
#2B2929 looks actually better for me too.

Looking good! My personal choice would be between (x+2, x[quote=“c-lobrano, post:198, topic:1898”]
The bar at the top is no longer transparent but totally black, I find it less beautiful (except if the wallpaper is dark and in this case it does not change much)

This is true, but I lost track of why we did that
[/quote]

On that one, I think we should really follow upstream with the transparent / dark switch when an app is next to it. It’s a GNOME feature and behavior that we shouldn’t deviate from IMHO.

(will comment on the other points later on, but want to wait on other’s feedback first ;))

3 Likes

I really like the solid orange color too! If @luxamman feels that this steals too much focus, we could make use of the orange line here: like this old mockup

Side note: Window$ and O$X both use gray.

+1 for green

A lighter headerbar would make the contrast better, but I really like the dark hearderbar. Looks like the click-color is #c1c1c1, could we try to make it darker?
Also in the screenshot above, the deactivated buttons look kind of loose. Perhaps a darker border or a very lightgray bg?

buttons_again

+1 for no shadow. They still look too big to me. Compared to other themes, the same applies to radio and checkboxes. Could we try making them a bit smaller? @godlyranchdressing

I also like 2B2927, I’m not much into the too-black version :slight_smile:

Speaking of the buttons, I’ve not following all the discussion, but they’re the only thing that doesn’t convince me much so far. Or better, i’m not much in love with the bottom border. They look like they’re too much out of context.

I really like the buttons and the bottom border! Very Suru… :slight_smile:

1 Like

I’m in complete agreement with the suggestions that @madsrh has :wink:

1 Like

Thanks,

I also created issues for:

  • Checkboxes and radio buttons design change
  • Click button color darker
  • Switches smaller without inner shadow

+1 for lighter grey


About the dock - maybe we can solve some problems by changing the dock itself since it is a fork. @didrocks will know and maybe he can help us with it.

  • The overall inner-shadow is not working for example with the square elements - so I would like to see the inner-shadow on the top only. Just for the separation of the top bar. Sometimes -10px works, maybe we can add a fixed element to the dock? This way it would look more like a glass-element but I still don’t want to lose the shadow on the top…
  • The dark square is not very nice looking, the hiding mechanism is also working very strict:
    VirtualBox_Ubuntu1804_24_01_2018_12_24_23
    Is there a possibility to soften this hiding mechanism a little? This is tricky, but maybe there is a solution to make something like a shadow but instead of a color, it add’s transparency to hide the icons. Ideas?

And again the points like months ago for @didrocks - I still would love to change the dock a little:

  • Making icons smaller, less clumsy and more elegant. Also giving more space for the indicator points. The position would not be centered, but a little to the right.
  • Indicator points are centered between the icon and the screen border, also a little bigger. In the actual system, they are never centered and sometimes overlapping the border.
  • Giving the icon on the top a little more space to the top - the actual dock has more space between icons than between the top icon and the top bar.
    dock

Since the dock is a fork, this changes could bring an additional design bonus to fit the system and just look better. The icons are just tooo big IMHO…


Thanks to all!

3 Likes

On the dock. I read here that you discussed it a little bit about not being able to theme it while I was on holidays. Do you mind describing a little bit more the issue?
There is an option which we keep to false “org.gnome.shell.extensions.dash-to-dock apply-custom-theme”. I looked at the code, this only adds “dashtodock” class to the dock itself to differientate from the dash one, which could be used in the general Shell theme.

So, I would be in favor to do most of the changes in the themes (in term of maintainability), and if someone should be done in the theme and couldn’t, we talk to upstream about adding the correct class to support it. :slight_smile:
Am I missing anything?

That’s maybe the issue you were seeing: dashtodock has its own css file shipped in the theme (this is how “shrink” and others properties are different: they just change the class name and apply the new style thus). This css files is applied last for the theme, and it seems it overrides the general theme thus.
I would propose to remove this css file in our fork and just implement that in the general theme, wdyt? (/!\ it means I need to upload this modified dash to dock in the ppa and keep it up to date or find a clever way to change this on the per session stuff…).
It means that we will port all properties from stylesheet.css to the general theme, which is a better place for this particular use case IMHO (and let also other theme creators style it).

I’m not sure to get what you mean here. I don’t see any inner shadow between elements?

The dark square (I guess when you select an element) can surely be styled once the restriction above is lifted.
hiding mechanism: that’s indeed a little bit more tricky. However, it looks better on my ubuntu session than apparently for you, note the transparency + shadow. See the bottom and top icons:
dash-overflow

The default is shrinked (from your screenshot, it’s not enabled apparently), so giving less space to icons. We can change default icon size (I always set them to 32px personnally). However, IIRC, the 48px default was selected based on user testing.
Indicator position, size and spacing should be able to be changed via css.

Same, should be doable with a :first-child css class.

So, it seems that overall, all requests can be changed without any code modifications, just ensuring the css file doesn’t override the shell theme, am I right?

As a first approach, we can directly patch the css file /usr/share/gnome-shell/extensions/ubuntu-dock@ubuntu.com/stylesheet.css if you want to ensure this is doable :wink:

1 Like

that’s the way! Open all the issues! The more the tickets the best we can organize our work and time :slight_smile:

2 Likes

Ok, after some tests, it seems that the general css isn’t applied to extensions, or that at least, removing the stylesheet.css and implementing the same property in the general theme isn’t picked up (I tried first with !important before deciding to remove the stylesheet.css directly for this).

EDIT: I found a trick actually looking at the code.
It’s supposed to apply (in order of loading, first one can be overriden by later ones):

  • general mode css (in /usr/share, the theme you are hacking on)
  • extensions stylesheet.css
  • extensions mode_name.css (ubuntu-communitheme).
    There is no way for !important to take precedence.

In the case mode_name.css == stylesheet name (case for the ubuntu theme, not for the ubuntu-community-theme, so I need to test it), the trick is that an empty extension mode_name.css file will make the general mode css file taking precedence over the general extensions stylesheet.css! This is another option as well. But I think the cleanest way is to ship a mode_name.css file next to stylesheet.css in the extension.

2 Likes

I really like #2B2929.

  • Change the pure orange for selections to a softer orange like in actual Ubuntu (16.04) to make the orange less dominating and the contrast flatter?

I do get that the current orange throws off the soft look we’re going for, but I prefer the current orange over a softer orange. How about using Silk (#CCC)?

  • Checkboxes and radioboxes - we have two designs now - the one in “Files” an the one for example in “Tweaks”

This was taken from Suru. Adwaita uses a simplified check and radio in its menus as well. I’m not exactly sure why but I did come up with:

  1. Deal with the selection color “overwriting” the color of the checkboxes and radio buttons - we use gray instead of orange for selected menuitems now so we don’t have to consider this anymore

menu check

  1. Not have too much complication in menus with a lot of checkboxes and radio buttons (LibreOffice) - this is something we could consider since there’ll be a lot of solid green in menus if we do scrap the hollow variant in menus, something that will throw off the soft look we’re going for.
  • Seems the green switches have an inner-shadow now - do we want that?

Checks, radios and buttons use shadows as well. Looking at it now the shadow is a bit too much though. Maybe 1px instead of the current 2px?

slider

  • Connected Buttons? Where are we heading? Have you tested possible designs?

I’ve been using the “hollow” concept - linked buttons have a border with no background. Unfortunately, an optical illusion comes into play and it makes everything look the same shade, especially thinner icons like the back-forward buttons. It looks much worse in this screenshot but it’s not much better in action. It’s cool and frustrating.

linked buttons

Still proposing the following on my end. :wink:

pathbar

I’ve been updating the insensitive/backdrop states based on Ubuntu’s disabled state styling and path bar buttons opacity and it looks this now:

buttons

I was leaning towards A since B’s border colors are a little too faint.

Sure, it’s just that the tick is so thin for the checkboxes that making it smaller makes it look weird. I’ll try to find a nice balance.

The edges having a shadow is due to the blur effect. Too low of a blur effect and it doesn’t look like a shadow on top, but too much and the other edges of the dock start to take on the blur effect. That was before the lighter dock color though (current is #292929 or something close to that). I’ll experiment and see what works while also taking into account a more transparent panel.

2 Likes

It looks like #2B2929 got most of the love :smiley: (3 or 4 preferences against 1 for the others). I’m going to open a ticket and then push the change

+1

May be this also the reason of this?

1 Like

IF there must be a border around the entire bar, I would prefer your earlier version with a solid gray background:
https://ubuntucommunity.s3-us-east-2.amazonaws.com/original/2X/5/5fc8edfd5af7716c637e1aa4e0898b7ce237f3cb.png

5 Likes

That could work too, I guess. For that mockup path-bar I was going for a fake entry field look.

What about for the linked buttons?

  1. They need to be linked to avoid potential issues
  2. They need to look disabled when they’re disabled - why I think we should use a background color again

Are headerbars going to be the same color? And what are opinions on a separator between the top panel and application title/headerbar? I got the idea from one of the Canonical mockups. Inkstone is being used here for the separator.

separator

1 Like

+1 for darker border. It fits well with the “physical” appearance of a button: It’s just a label, not a button so you can’t press it. Grey makes it look as if it’s a button that is pressed halfway in…

1 Like

I like the shadow as it is now, I like the non-flat aspects of the theme; it distinguishes us…

I think the issue with B is that the borders of the enabled buttons need to be a bit darker. I think that’s how it should be given the light source from the top: the edges of a button that are risen should be more pronounced than the edges of a button that is level (or a label).

For the linked buttons, I also like the approach of this pathbar the most:

(the shared lighter background)

I think depth doesn’t really work in the headerbar because the other elements in the headerbar are flat… Although the “rail” for the orange underline worked well imho.

1 Like

example
I like as well this grouping very much, it feels like a single thing, and we can see that arrows next to them will really impact this group alone. (still need to ensure the disabled state is clearly recognizable for them).

However, I wonder if the constrast is high enough between the background and text?

1 Like

Do we need one?
Anyway, inkstone is ok for me (if we need a separator)

1 Like

Do you think this is still an issue with the new headerbar color? The click-color is #1C1C1C, I can’t take a screenshoot with a darker color (:open_mouth: ), but I can hardly see the difference on my screen

It was @luxamman who pointed this out - I’m such a disaster with button, so I’ll just leave it to him :stuck_out_tongue_winking_eye:

Yes, they are still quite hard to spot. To me the current UI is kind of inconsistent:

  • In the Nautilus sidebar we use the orange rectangle for selected
  • In the pathbar it’s an orange line underneath
  • For buttons (search, grid,…) it’s a dark square
  • When I click ‘Activities’ in the topbar it’s highlighted to gray

:thinking:

In the quick mockup below (excuse lack of thouroughness), I’m actually leaning towards the orange line underneath or even the orange square solely because of consistency. The problem is that these options steal much focus, and so this might just be a really long way of saying, just make them a bit darker :upside_down_face:

buttons

4 Likes