theme: Replace gnome-shell-sass submodule with subtree
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).
2018-02-09 13:22:55 -05:00
|
|
|
// Drawing mixins
|
|
|
|
|
|
|
|
// generic drawing of more complex things
|
|
|
|
|
2019-12-18 16:25:03 -05:00
|
|
|
@function draw_widget_edge($c:$borders_edge) {
|
theme: Replace gnome-shell-sass submodule with subtree
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).
2018-02-09 13:22:55 -05:00
|
|
|
// outer highlight "used" on most widgets
|
2019-12-19 10:38:27 -05:00
|
|
|
@return 0 1px $c;
|
theme: Replace gnome-shell-sass submodule with subtree
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).
2018-02-09 13:22:55 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
// provide font size in rem, with px fallback
|
|
|
|
@mixin fontsize($size: 24, $base: 16) {
|
2019-12-19 10:38:27 -05:00
|
|
|
font-size: round($size) + pt;
|
|
|
|
//font-size: ($size / $base) * 1rem;
|
theme: Replace gnome-shell-sass submodule with subtree
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).
2018-02-09 13:22:55 -05:00
|
|
|
}
|
|
|
|
|
2019-12-18 16:25:03 -05:00
|
|
|
@mixin draw_shadows($shadow1, $shadow2:none, $shadow3:none, $shadow4:none) {
|
theme: Replace gnome-shell-sass submodule with subtree
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).
2018-02-09 13:22:55 -05:00
|
|
|
//
|
|
|
|
// Helper function to stack up to 4 box-shadows;
|
|
|
|
//
|
2019-12-19 10:38:27 -05:00
|
|
|
@if $shadow4!=none { box-shadow: $shadow1, $shadow2, $shadow3, $shadow4; }
|
|
|
|
@else if $shadow3!=none { box-shadow: $shadow1, $shadow2, $shadow3; }
|
|
|
|
@else if $shadow2!=none { box-shadow: $shadow1, $shadow2; }
|
|
|
|
@else { box-shadow: $shadow1; }
|
theme: Replace gnome-shell-sass submodule with subtree
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).
2018-02-09 13:22:55 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
// entries
|
|
|
|
|
|
|
|
@mixin entry($t, $fc:$selected_bg_color, $edge: $borders_edge) {
|
|
|
|
//
|
|
|
|
// Entries drawing function
|
|
|
|
//
|
|
|
|
// $t: entry type
|
|
|
|
// $fc: focus color
|
2019-12-18 16:25:03 -05:00
|
|
|
// $edge: set to none to not draw the bottom edge or specify a color to not use the default one
|
theme: Replace gnome-shell-sass submodule with subtree
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).
2018-02-09 13:22:55 -05:00
|
|
|
//
|
|
|
|
// possible $t values:
|
|
|
|
// normal, focus, insensitive
|
|
|
|
//
|
|
|
|
|
2019-12-19 10:38:27 -05:00
|
|
|
@if $t==normal {
|
|
|
|
background-color: $base_color;
|
|
|
|
border-color: $borders_color;
|
|
|
|
}
|
|
|
|
@if $t==focus {
|
|
|
|
border-color: if($fc==$selected_bg_color,
|
|
|
|
$selected_borders_color,
|
|
|
|
darken($fc,35%));
|
2021-08-05 08:23:41 -04:00
|
|
|
box-shadow: inset 0 0 0 2px $fc;
|
2019-12-19 10:38:27 -05:00
|
|
|
}
|
|
|
|
@if $t==hover { }
|
|
|
|
@if $t==insensitive {
|
|
|
|
color: $insensitive_fg_color;
|
|
|
|
border-color: $insensitive_bg_color;
|
|
|
|
box-shadow: none;
|
|
|
|
}
|
theme: Replace gnome-shell-sass submodule with subtree
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).
2018-02-09 13:22:55 -05:00
|
|
|
}
|
|
|
|
|
2022-02-02 13:17:42 -05:00
|
|
|
// On-screen Keyboard
|
|
|
|
@mixin keyboard_key($t, $c:$osd_bg_color, $tc:$osd_fg_color) {
|
theme: Replace gnome-shell-sass submodule with subtree
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).
2018-02-09 13:22:55 -05:00
|
|
|
//
|
2022-02-02 13:17:42 -05:00
|
|
|
// Keyboard key drawing function
|
theme: Replace gnome-shell-sass submodule with subtree
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).
2018-02-09 13:22:55 -05:00
|
|
|
//
|
2022-02-02 13:17:42 -05:00
|
|
|
// $t: key type,
|
|
|
|
// $c: base key color for colored* types
|
|
|
|
// $tc: optional text color for colored* types
|
theme: Replace gnome-shell-sass submodule with subtree
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).
2018-02-09 13:22:55 -05:00
|
|
|
//
|
2022-02-02 13:17:42 -05:00
|
|
|
// possible $t values:
|
|
|
|
// normal, hover, active, insensitive, insensitive-active,
|
|
|
|
// backdrop, backdrop-active, backdrop-insensitive, backdrop-insensitive-active,
|
|
|
|
// osd, osd-hover, osd-active, osd-insensitive, osd-backdrop, undecorated
|
theme: Replace gnome-shell-sass submodule with subtree
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).
2018-02-09 13:22:55 -05:00
|
|
|
//
|
|
|
|
|
2022-02-02 13:17:42 -05:00
|
|
|
// normal key
|
|
|
|
@if $t==normal {
|
|
|
|
color: $tc;
|
|
|
|
background-color: lighten($c, 3%);
|
|
|
|
}
|
theme: Replace gnome-shell-sass submodule with subtree
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).
2018-02-09 13:22:55 -05:00
|
|
|
|
2022-02-02 13:17:42 -05:00
|
|
|
// focused key
|
|
|
|
@if $t==focus {
|
|
|
|
color: $tc;
|
|
|
|
background-color: mix(lighten($c, 3%), $selected_bg_color, 90%);
|
|
|
|
box-shadow: inset 0 0 0 2px transparentize($selected_bg_color, 0.4);
|
|
|
|
&:hover {
|
|
|
|
background-color: mix(lighten($c, 8%), $selected_bg_color, 90%);
|
|
|
|
box-shadow: inset 0 0 0 2px transparentize($selected_bg_color, 0.3);
|
|
|
|
}
|
|
|
|
}
|
theme: Replace gnome-shell-sass submodule with subtree
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).
2018-02-09 13:22:55 -05:00
|
|
|
|
2022-02-02 13:17:42 -05:00
|
|
|
// hover key
|
|
|
|
@else if $t==hover {
|
|
|
|
color: $tc;
|
|
|
|
background-color: lighten($c, if($variant == 'light', 8%, 5%));
|
2019-12-19 10:38:27 -05:00
|
|
|
}
|
2022-02-02 13:17:42 -05:00
|
|
|
|
|
|
|
// active key
|
|
|
|
@else if $t==active {
|
|
|
|
color: $tc;
|
|
|
|
background-color: darken($c,3%);
|
|
|
|
}
|
|
|
|
|
|
|
|
// insensitive key
|
|
|
|
@else if $t==insensitive {
|
|
|
|
color: $insensitive_fg_color;
|
|
|
|
background-color: $insensitive_bg_color;
|
|
|
|
}
|
|
|
|
|
|
|
|
// reset
|
|
|
|
@else if $t==undecorated {
|
|
|
|
background-color: transparent;
|
|
|
|
background-image: none;
|
2019-12-19 10:38:27 -05:00
|
|
|
}
|
theme: Replace gnome-shell-sass submodule with subtree
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).
2018-02-09 13:22:55 -05:00
|
|
|
}
|
|
|
|
|
2022-02-02 13:17:42 -05:00
|
|
|
|
|
|
|
// buttons
|
|
|
|
// since buttons are all flat an borderless now the mixin is simpler
|
|
|
|
|
|
|
|
@mixin button($t, $tc:$fg_color, $c:$bg_color) {
|
theme: Replace gnome-shell-sass submodule with subtree
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).
2018-02-09 13:22:55 -05:00
|
|
|
//
|
|
|
|
// Button drawing function
|
|
|
|
//
|
|
|
|
// $t: button type,
|
2022-02-02 13:17:42 -05:00
|
|
|
// $c: base button colors, derived from fg_color
|
|
|
|
// $tc: base button colors, derived from fg_color
|
theme: Replace gnome-shell-sass submodule with subtree
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).
2018-02-09 13:22:55 -05:00
|
|
|
//
|
|
|
|
// possible $t values:
|
|
|
|
// normal, hover, active, insensitive, insensitive-active,
|
|
|
|
// backdrop, backdrop-active, backdrop-insensitive, backdrop-insensitive-active,
|
|
|
|
// osd, osd-hover, osd-active, osd-insensitive, osd-backdrop, undecorated
|
|
|
|
//
|
|
|
|
|
2019-12-19 10:38:27 -05:00
|
|
|
// normal button
|
|
|
|
@if $t==normal {
|
|
|
|
color: $tc;
|
2022-02-02 13:17:42 -05:00
|
|
|
background-color: mix($tc, $c, 5%);
|
2019-12-19 10:38:27 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
// focused button
|
|
|
|
@if $t==focus {
|
|
|
|
color: $tc;
|
2022-02-02 13:17:42 -05:00
|
|
|
background-color: mix(mix($tc, $c, 5%), $selected_bg_color, 90%);
|
|
|
|
// border-color: lighten($tc, 3%);
|
2020-02-19 03:49:36 -05:00
|
|
|
box-shadow: inset 0 0 0 2px transparentize($selected_bg_color, 0.4);
|
2022-02-02 13:17:42 -05:00
|
|
|
&:hover {
|
|
|
|
background-color: mix(mix($tc, $c, 7%), $selected_bg_color, 90%);
|
|
|
|
box-shadow: inset 0 0 0 2px transparentize($selected_bg_color, 0.3);
|
|
|
|
}
|
2019-12-19 10:38:27 -05:00
|
|
|
}
|
|
|
|
|
2020-01-17 05:57:42 -05:00
|
|
|
// hover button
|
2019-12-19 10:38:27 -05:00
|
|
|
@else if $t==hover {
|
|
|
|
color: $tc;
|
2022-02-02 13:17:42 -05:00
|
|
|
background-color: mix($tc, $c, 7%);
|
2019-12-19 10:38:27 -05:00
|
|
|
}
|
|
|
|
|
2020-01-17 05:57:42 -05:00
|
|
|
// active button
|
2019-12-19 10:38:27 -05:00
|
|
|
@else if $t==active {
|
|
|
|
color: $tc;
|
2022-02-02 13:17:42 -05:00
|
|
|
background-color: mix($tc, $c, 2%);
|
2019-12-19 10:38:27 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
// insensitive button
|
|
|
|
@else if $t==insensitive {
|
2022-02-02 13:17:42 -05:00
|
|
|
color: transparentize($tc, 0.5);
|
|
|
|
background-color: transparentize($tc, .95);
|
2019-12-19 10:38:27 -05:00
|
|
|
}
|
|
|
|
|
2022-02-02 13:17:42 -05:00
|
|
|
// default/suggested button
|
|
|
|
@else if $t==default {
|
|
|
|
background-color: $selected_bg_color;
|
|
|
|
color: $selected_fg_color;
|
|
|
|
&:focus {
|
|
|
|
box-shadow: inset 0 0 0 2px transparentize($selected_bg_color, 0.4);
|
|
|
|
}
|
|
|
|
&:hover, &:focus {
|
|
|
|
background-color: lighten($selected_bg_color, 5%);
|
|
|
|
color: lighten($selected_fg_color, 5%);
|
|
|
|
}
|
|
|
|
&:active {
|
|
|
|
background-color: darken($selected_bg_color, 7%);
|
|
|
|
color: darken($selected_fg_color, 7%);
|
|
|
|
}
|
|
|
|
&:insensitive {
|
|
|
|
@include button(insensitive);
|
|
|
|
background-color: transparentize($selected_bg_color, .5);
|
|
|
|
color: transparentize($selected_fg_color, .5);
|
|
|
|
}
|
|
|
|
}
|
2019-12-19 10:38:27 -05:00
|
|
|
// reset
|
|
|
|
@else if $t==undecorated {
|
|
|
|
background-color: transparent;
|
2022-02-02 13:17:42 -05:00
|
|
|
background-color: none;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// tile
|
|
|
|
@mixin tile($color) {
|
|
|
|
@extend %tile;
|
|
|
|
background-color: transparent;
|
|
|
|
|
|
|
|
&:hover,
|
|
|
|
&:selected:hover {
|
|
|
|
background-color: transparentize($color, .85);
|
|
|
|
}
|
|
|
|
|
|
|
|
&:focus:hover {
|
|
|
|
background-color: transparentize($color, .8);
|
|
|
|
}
|
|
|
|
|
|
|
|
&:selected,
|
|
|
|
&:focus {
|
|
|
|
background-color: transparentize($color, .9);
|
|
|
|
}
|
|
|
|
|
|
|
|
&:outlined,
|
|
|
|
&:checked,
|
|
|
|
&:active {
|
|
|
|
background-color: transparentize(darken($osd_bg_color, 10%), .5);
|
2019-12-19 10:38:27 -05:00
|
|
|
}
|
|
|
|
}
|
2020-01-25 03:53:17 -05:00
|
|
|
|
2022-02-02 13:17:42 -05:00
|
|
|
|
2020-01-25 03:53:17 -05:00
|
|
|
// overview icons
|
2022-02-02 13:17:42 -05:00
|
|
|
// mixin fo tiles in the overview
|
2021-12-28 08:46:54 -05:00
|
|
|
@mixin overview_icon($color) {
|
2020-01-25 03:53:17 -05:00
|
|
|
.overview-icon {
|
2022-02-02 13:17:42 -05:00
|
|
|
@extend %tile;
|
2020-01-25 03:53:17 -05:00
|
|
|
color: $color;
|
|
|
|
}
|
|
|
|
|
|
|
|
&:hover,
|
2022-02-02 13:17:42 -05:00
|
|
|
&:focus:hover,
|
2020-01-25 03:53:17 -05:00
|
|
|
&:selected {
|
|
|
|
.overview-icon {
|
|
|
|
background-color: transparentize($color, .9);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
&:focus {
|
|
|
|
.overview-icon {
|
2022-02-02 13:17:42 -05:00
|
|
|
background-color: transparentize($color, .95);
|
2020-01-25 03:53:17 -05:00
|
|
|
// border-color: $selected_bg_color;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
&:drop {
|
|
|
|
.overview-icon {
|
2022-02-02 13:17:42 -05:00
|
|
|
border: 2px solid transparentize($selected_bg_color, .2); //already 2px transparent so no jumping
|
2021-02-22 08:58:58 -05:00
|
|
|
background-color: transparentize($selected_bg_color, .8);
|
2020-01-25 03:53:17 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
&:active,
|
2022-02-02 13:17:42 -05:00
|
|
|
&:focus:active,
|
2020-01-25 03:53:17 -05:00
|
|
|
&:checked {
|
|
|
|
.overview-icon {
|
|
|
|
background-color: transparentize(darken($osd_bg_color, 10%), .5);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2022-02-02 13:17:42 -05:00
|
|
|
|
|
|
|
|
|
|
|
// styling for elements within popovers that look like notifications
|
|
|
|
@mixin card($flat: false) {
|
|
|
|
border-radius: $base_border_radius;
|
|
|
|
margin: $base_margin;
|
|
|
|
box-shadow: 0 1px 1px 0 rgba(0,0,0,.1);
|
|
|
|
|
|
|
|
@if $flat {
|
|
|
|
@include button(undecorated);
|
|
|
|
box-shadow: none !important;
|
|
|
|
} @else {
|
|
|
|
@include button(normal);
|
|
|
|
}
|
|
|
|
|
|
|
|
&:focus {
|
|
|
|
@include button(focus);
|
|
|
|
}
|
|
|
|
|
|
|
|
&:hover {
|
|
|
|
@include button(hover);
|
|
|
|
}
|
|
|
|
|
|
|
|
&:active {
|
|
|
|
@include button(active);
|
|
|
|
}
|
|
|
|
}
|