- Improve legibility by using the OSD style for the results
- Would be nice to include the search entry in the container
and have a nice transition.
Addresses https://gitlab.gnome.org/GNOME/gnome-shell/issues/288
- darker, less transparent OSD
- brighter OSD border
- no border for over view panels and entry
- fix border color of popups
- remove trough variable as osd trough and popup trough cant have the same color if dependant on fg_color, fixed hex could also work
- thinner workspace border
- originally related to tweaking the osd style for use in dialogs,
it no longer serves the purpose as dialogs are eithe rlight or dark
and thus can use the colors directly.
- the original style was built on OSD colors and the conditionals no longer made any sense. In Adwaita:gtk the color conditionals special case the color buttons (warning and suggested tinting). This does not exist in the shell
- light colored, bubble-like popovers, dialogues and notifications
- unified OSD colors for OSD elements
- small shadow for OSD elements to improve visibility above dark backgrounds
- small screenshield shadow improvements
- slightly bigger GDM buttons
- rounder buttons, rounder entries
- flatter entries
As the style has grown bigger and more complex, generating the different
variants from a common source has been a good decision. However given how
intertwined the theme is with gnome-shell itself, relying on a submodule
has proven to be quite painful. And as things stand right now, it is going
to get worse:
- using either pre-generated CSS or generating it at build time is
odd, and violates meson's strict separation between source- and
build directories; we are therefore considering dropping the CSS
and depending on sassc to always generate it at build time
- with the migration to gitlab, our workflow shifts decisively towards
branches; however there is no support in either git or gitlab for
handling two brances of separate repositories consecutively, which
gets particularly awkward for branches in a private namespace
With those pain points in mind, we will adjust our setup as follows:
- remove the submodule from gnome-shell and instead import the
sass as subtree
- after that, the sass sources can be changed like any other files
in the repository, and regular contributors can forget that there
was ever anything special about them
- whenever we want to update the classic style, we can push the subtree
changes and bump gnome-shell-extension's sass submodule
In other words: Updating the classic styling will become slightly more
painful, but not much and only for me; in return, everyone else can
stop fiddling with submodules (and buy me a beer).
