Personally I think I prefer no circle when the window is out-of-focus, but I’d defer to the preference of the design team 
It might be worth trying one and then trying the other in “edge” or something, because I think you don’t always know what your preference is until you’ve tried it both ways for a bit (case in point: the original removal of the orange circle).
I agree, also because if the backdropped window is too bright, the bright top border will disappear into it 
+1 (I have to write 20 characters)
I need some help to rap around my head about those too complicated technicalities (only for me ofc 
) .
I red the instructions many times and I feel I understand in teory how it all work but when it comes to practice I’m
a bit unsure.
For example : The command communithem.reset that is doing the gsetting.override
What keys should I override and what are the exact commands I should use?
@didrocks, @c-lobrano , @frederik-f or any of you that can help, will be much appreciated
@c-lobrano possibly a middle ground like:
It had never occurred to me to highlight the upper edge of the window title, but, seeing it, I like it
The command was communitheme.reset and is now removed for turning communitheme in an arch:all package (more on that later). I don’t find any place mentioning this? If you have found some references to it still, please feel free to edit them.
You normally don’t have to run it, apart if you changed the defaults (via Tweaks or any other tools). The up-to-date instructions are on https://github.com/ubuntu/communitheme-snap-helpers/blob/master/README.md. Note that the snap communitheme-set-defaut isn’t published yet and is pending votes on Classic confinement request: communitheme-set-default - snap - snapcraft.io. If you are eager to see it, do not hesitate to comment there
I agree with ads2000. While I’m not too bothered about white dialogs for the Shell, there is some inferred coherence in ensuring everything coming from the Shell (which is mostly dark) like managing windows/workspaces, passwords prompt, shutdown dialog have similar coloring pattern (like the dropdown menu in date, menus…). Note that I didn’t say “consistent” @madsrh 
Indeed, it’s an issue we had in the past as well. Some parts can be styled, but not everything. @3v1n0, you are the one knowing more than me here ^
Whatever the finale decision is, I think we’ll write some “design guidelines” on what and why certain decisions were made, so that we can refer people to it (perhaps as part of the FAQ). For instance, stuff like that would be perfect in it:
Once we are ready and most decisions are set in stone, having someone (not necessarilly technical), gathering all those, putting them in a readable shape (maybe with screenshots) would be an awesome contribution to help the core communitheme team!
I like it very much! (in general, I already love the “backdrop state” visual rendering, which was another topic with a lot of back and forth
The login failure isn’t related to communitheme, indeed. It’s probably Bug #1766137 “[regression] Password accepted but login fails (bl...” : Bugs : gdm3 package : Ubuntu (upstream is https://gitlab.gnome.org/GNOME/gnome-shell/issues/227).
+1 in stone for this
We were thinking to use github wiki to gather all of this, but then it can be moved everywhere
Yeah, a wiki page for some collaboration and iteration over it before moving it is perfect!
Now I’ve seen the bright top border live - I love it! I think this is a really nice detail that makes the gui look slicker, as well as helping with the distinction between foreground/background window titles.
I leave it to the design team to decide whether it would also benefit from some additional lightening of the background titles.
Current
Slightly lightened background titles
The second screenshot is from my personal folder of mockups, so includes other tweaks I’ve been playing with (namely: restoration of the app grid button; a Circle of Friends next to “Activities”; and removal of the separating line between Gnome header and launcher).
EDIT: forgot to say - I also love only the orange circle for the focussed window only, and the look of no circle (rather than a greyed-out one) for other windows
You bring up some very good ideas and the quality of your mock-ups is very good! Thank you very much @jaggers
Thank you @frederik-f, I enjoy making the mock ups and posting in this thread, so it’s kind of you to say so!
The need for it came to allow me reset before I report issues that might have come from NOT default setting.
I voted there although, you gave me some reading to do which I grateful for. I might have more questions to you
after reading it, if you don’t mind.
Thank you!
There is one big plus with white dialogs, they are very positive:
Dark dialogs are sometimes a bit “darkly” and creepy =)
We could also try more iterations on what is white and what is dark.
Atm we have
I believe a good iteration to try would be to go everywhere back to dark except light notifications + light dialogs. It should not be “negative” or “darkly” to authenticate for installation or logout:
I actually like most of the dialog, when they have the backdrop behind them. However, remember that the rest of the Shell UI is rather dark, entering activities, menus and others…
The one I find really weird is alt-tab, especially if you have a white UI behind it, the lack of contrast merge it a little bit too much with the application (like the browser page) to me.
+1 the dark version was SO good looking.
I really like the light dialogs (authentication+login/out) we currently have.
We should strive for a coherent experience and that might not necessarily be exclusive light or dark.
So this is what I would like to try:
Dark alt+tab switcher
Dark workspace switcher
Dark popups
White dialog when you plugin your headphones:
White notifications:
And the logout and auth dialogs from my last post (see above)!
Everyone +1 to try this? =) I’d make a PR for this then.
White login and close window white look a bit out of place to me if most of the rest is dark
I like white dialogues - I agree with @frederik-f, dark ones can look creepy.
I am less sure about the style difference between the app dialogues and shell dialogues:
For shell dialogues, differences are: no dark stripe at the top; borderless buttons; rounded bottom corners; dimming of the desktop. I think both dialogue styles look very good but probably have a preference for the app ones, because they look more “Communitheme” to me (the shell dialogues are nice but look alien).
It may actually be desirable to have a clear visual distinction between shell dialogues and app dialogues. But I don’t IMHO think the points of distinction should be arbitrary design choices (e.g. one has square corners at the bottom and one has rounded ones… one has button style “x” and one has button style “y”, etc.).
Of the differences listed, I think the one that makes most logical sense is dimming the desktop for shell dialogues, because it emphasises a shift of focus away from apps, open documents, etc., so you can talk to the shell itself.
Are there limitations in terms of what can and can’t be themed here? I think I would like to see the shell dialogues styled in a similar way to the rest of Communitheme, if possible. A dark bar at the top would give a nice balance between light and dark (so the dialogues are light but not too “bright-seeming”) and the desktop could still be dimmed for shell dialogues only, to distinguish them from app dialogues:
@jaggers The shell dialogues can’t have a headerbar.
But we have a PR somewhere (?) to revert the gtk dialogues back to upstream/shell-lookalike
@c-lobrano dialogs are somehow similar to notifications with buttons like this one:
So it would make perfect sense to me to have a dark shell yet light dialogues/notifications
The gtk theme is both dark (headerbar) and light (window), too after all.
But a dark shell would be more “upstream”.
And to finish my above post, volume/keyboardbacklight/screenbrightness OSDs would be also dark
