CommuniTheme Progress

Hello everyone,

I feel like the phase of heavy design turnovers and big changes is about to end and we are entering a phase of refinement and bug fixing. (Correct me if that’s a wrong impression :smile: @c-lobrano)

For our general motivation and a transparent project insight I would like to gather where we stand:

  • The GNOME shell theme is almost finished and thanks to @godlyranchdressing we can toggle between dark and white components in one line of code if we feel this way
  • The GTK3 theme has come down to a beautiful yet usable state where we found a way to keep several branding elements and yet “reducing the orange” :wink: to a good medium amount - thanks to @nusi and @jaggers
  • The GTK2 theme was paused in a phase where many changes hit the road and has been postponed until we are sure that we reached a mature state in GTK3 theming
  • I just found out that a QT-Theme is provided by tsujan on github but I don’t know weither @didrocks is already informed and connected about his progress and how Qt-themes can be included into the snap?

Maybe we can leave the Design threads for now and continue to report our road to 18.10 and becoming the default theme in here.

It would be nice if our designers @madsrh and @luxamman could leave some report(s) in here on where the design stands and @c-lobrano and @godlyranchdressing what is on their todo list at the moment.

I am currently working on the dark GTK3 version which some GNOME apps (some are even core apps in Ubuntu) use by default.

Best regards,
Frederik

11 Likes

Nice recap @frederik-f, I like the idea to come here and list past and future activites. I’ll try to do it more often from now on.

I agree this might be the time to update GTK2 and start testing other implementation/engines (I’m not sure how to call them), like QT.

Personally, I spent some time on:

  • animations, but I’ve never done something similar, so no result so far.
  • color adjustment (I am not very sure about current view-to-sidebar relationship, but first try has been rejected)
  • top panel transparency (see issue 173)
  • checkbox widget in GNOME Music
  • some other minor bug fixing
7 Likes

I think there’s still some small issues in the Shell that we have to work on, I just haven’t found the time to form my thoughts on them (I’d feel bad about opening issues without having the time to work on them :persevere: ). Off the top of my head:

  • The alt-tab selection should have some kind of orange because this is one of those things that really does need the highlight color. Every other popular theme uses a major color here.

  • The window selection preview in the overview is too transparent. This is a similar problem to the alt-tab switcher. If we want to avoid the orange in the alt-tab switcher then we can apply the same white border there as well.

  • The transparency for the notification popups should be the same value as $popover-alpha-value but, popovers are also so barely transparent that I think we should decide whether or not we should leave them transparent at all.

  • We still have to make a decision on the app-grid icon.

  • :warning: Controversy ahead :warning: I know that there was a poll, but I don’t agree with the final result on the Shell’s use of light and dark colors. I think that this is a similar situation to the usage of blue for text selection. The distinction that we see between popups, OSDs and dialog windows won’t be as obvious to everyone. I took some time to even understand what I was choosing to vote for on the poll itself. It’s why I proposed the dark panel, dark popovers (the popovers “come out” of the dark top-panel so it fits) and light everything else. If it isn’t all or nothing, then things start to get confusing. I really think that we should avoid polls in the future: having to commit to any final decision chosen by the general public on something as subjective as design and what “looks good” is never a good thing - I know that goes against the basis of the communitheme, but it is what it is. Polls don’t give people time to warm up to something they otherwise wouldn’t have agreed with (jaggers eventually came around to the blue! :smile:) and if we do ultimately decide to go against the final decision for whatever reason, then we’re automatically against the popular vote and said poll is used as the basis for why we shouldn’t make the change in the first place.

Also a small but something we can ignore on the GTK3 theme: the margin between the path-bar and stackswitcher and the headerbar is a little too small but I guess nothing can be done about that without upsetting the too-big-headerbars crowd:

margin

2 Likes

Do you mean the clone border or the workspace tile background? I have to admit that the same transparency for entry/workspace thumbnails/dock and top panel make perfect sense to me :slight_smile:

Easy change, though I would like to keep both, the popup and the notification transparency as it looks quiet refreshing in my opinion to not have everything painted solid.

2 Likes

The workspace tile background is the workspace switcher, right? That looks fine. .window-clone-border is the classname for what I’m talking about.

I think we can up the transparency of the popovers. They were more transparent earlier on. I think a very minor 0.025, up from 0.015 actually makes a huge difference:

trans

And I did like the notification’s transparency at first! But after seeing it in action, I’ve found that favicons bleed out through the transparency a little too much. If only we could blur the background. :wink:

This is before and after using the the proposed 0.025 alpha value:

trans2
trans3

But best we take this discussion to Mockups/new design discussions so we don’t have duplicate threads.

4 Likes

I’d feel bad about opening issues without having the time to work on them

Please open them, with all the info you think might be useful. If you don’t have time, someone else might, and BTW the issue is tracked :wink:

The alt-tab selection should have some kind of orange because this is one of those things that really does need the highlight color. Every other popular theme uses a major color here.

Orange underline?

The window selection preview in the overview is too transparent. This is a similar problem to the alt-tab switcher. If we want to avoid the orange in the alt-tab switcher then we can apply the same white border there as well.

+1

We still have to make a decision on the app-grid icon.

My understanding was that to remove the ubuntu logo in the grid, we should add another extention to add the logo in the top panel. Is that right?

:warning: Controversy ahead :warning:

To me, the biggest drawback of light shell is the tab-switcher. This is the widget that most of the times goes over other windows, which are mostly bright, so white on white is not easy for the eyes.
However, for a similar reason, I like bright popups, which appear most of the times over dark headerbars. Also I usually don’t see GNOME vanilla notifications since they are too dark and not very visible.
All the rest… if popovers are dark, it makes sense to have shell windows dark as well to me, I don’t see such a big improvement in style in making them white.

Also -1 about making public polls. Users interaction with us with feedbacks is fundamental, we might (and did) change direction according to our community, but to make choices in advance we are the only ones that see the code and the UI all the time and might have a (decent) grasp of the pros and cons of every choice.

5 Likes

Hi everyone,

now that all the repos are merged into one we could slowly look to 18.10.

Some questions come to my mind:

  • when will 3.30 land on the cosmic daily repos so we can test them?
  • what applications will see a drastic UI overhaul in 3.30 (beside nautilus, we know this)?
  • will 18.10 still use nautilus 3.26, use 3.28 or switch straight to 3.30?
  • with which default applications will it ship?
  • if thunderbird is still going to be shipped, will that thunderbird use the new firefox UI (there is thunderbird dev version which already uses that UI)?
  • how will we handle the different versioning for 3.28 (18.04) and 3.30 (18.10) in the SASS files?

Maybe @didrocks can answer some of these questions :angel:

3 Likes

I’m only answering to some of the questions which could be google away (like what’s new on 3.30 isn’t set in stone until we reach GNOME feature freeze)

We don’t land WIP version before 3.28.90 generally, which is still some months ahead. This is when we evaluate the changes and if we want to get them or not. Basically assessing risks/benefits.

Still an opened question. I’m working with Carlos on the icon on the desktop. So we either keep 3.26 or will switch to 3.30, depending on the timeline of that feature being ready.

No big changes on that one AFAIK. We will have some tweaks and improvments.

Depends on when they have a release for it, mind looking?

That’s a good question. I suggest that we keep some kind of backward compatibility if the changes are small. If not, we can separate the branches or have separate directories, once shipped in the package, the other in the snap. But it’s basically doubling the work.

At this point in time, we have 16 bugs over 40 opened on Suru icons or icons in general (I believe some are the default ones from gnome).
I’m sorry, but no one of the core Yaru team has the skills to entirely develop new icons. I am very glad that ubuntujaggers (@jaggers, is that you?) is doing such a great job, but we’re understaffed in this regard and short on time if we want to do anything for 18.10.

We know that there will always be limitations on the icons we can create/modify (e.g. Third party app), so is using default gnome icons so bad?

3 Likes

I think we should draw a line. We are mostly done for 18.10, UIF is now in order. So, basically, small enhancements, that doesn’t break UIF can be done, but I will be reluctant to encourage any other work done until we release 18.10. Good news, there are still some releases (and so time, and so, incremental improvements) until the next LTS, which is where most of users will discover our wonderful new theme :slight_smile:

5 Likes

Yes - that would be a bad idea.
If we were talking about apple OSX icons or similar inspired themes in the linux world like La Capitaine I would say yes, is this really necessary?
But we are talking about adwaita icons. Which are a) currently hyper realistic, very detailed and glossy and b) moving to a hyper flat version in the next releases (very extreme, aren’t they?). So unity8 had/has the original Suru, so we need this GNOME suru for the gnome theme Yaru.
I’d say shipping with suru for ALL default apps (except firefox/thunderbird/LO) is a very reachable target for 19.4 and our 18.4 snap.
But I strongly agree that if we wouldn’t found out that @jaggers is a SVG artist, we would have a real problem, since SNWH activity is low and can’t keep pace with Yaru’s.
But @jaggers could need more people to help him. As far as I know @luxamman is also capable of creating inkscape vectors :slight_smile:

I message spammed @didrocks about this in panic and almost :wink: angry. As far as I understood him correctly, @mpt will open the bugs that are about already created suru icons by SNWH on the upstream repo.
But shouldn’t we close the corresponding reports in our repo then? It’s kind of distracting.

4 Likes