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 18:22:55 +00:00
|
|
|
// Drawing mixins
|
|
|
|
|
|
|
|
// generic drawing of more complex things
|
|
|
|
|
2022-11-03 15:28:24 +00:00
|
|
|
@function draw_widget_edge($c:$outer_borders_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 18:22:55 +00:00
|
|
|
// outer highlight "used" on most widgets
|
2019-12-19 15:38:27 +00: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 18:22:55 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// provide font size in rem, with px fallback
|
|
|
|
@mixin fontsize($size: 24, $base: 16) {
|
2019-12-19 15:38:27 +00: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 18:22:55 +00:00
|
|
|
}
|
|
|
|
|
2019-12-18 21:25:03 +00: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 18:22:55 +00:00
|
|
|
//
|
|
|
|
// Helper function to stack up to 4 box-shadows;
|
|
|
|
//
|
2019-12-19 15:38:27 +00: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 18:22:55 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2022-10-13 16:51:17 +00:00
|
|
|
// Text entries
|
2023-07-05 16:47:57 +00:00
|
|
|
@mixin entry($t, $c, $fc:$selected_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 18:22:55 +00:00
|
|
|
//
|
|
|
|
// Entries drawing function
|
|
|
|
//
|
|
|
|
// $t: entry type
|
2022-10-13 16:51:17 +00:00
|
|
|
// $c: text color, used to derive background color of entries
|
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 18:22:55 +00:00
|
|
|
//
|
2022-10-13 16:51:17 +00:00
|
|
|
// possible $t values: normal, focus, insensitive
|
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 18:22:55 +00:00
|
|
|
//
|
2022-11-03 15:28:24 +00:00
|
|
|
transition-duration: 100ms;
|
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 18:22:55 +00:00
|
|
|
|
2019-12-19 15:38:27 +00:00
|
|
|
@if $t==normal {
|
2022-10-13 16:51:17 +00:00
|
|
|
background-color: transparentize($c, 0.85);
|
|
|
|
color: transparentize($c,0.3);
|
2022-11-03 15:28:24 +00:00
|
|
|
|
|
|
|
@if $is_highcontrast {
|
|
|
|
box-shadow: inset 0 0 0 1px $hc_inset_color;
|
|
|
|
}
|
2019-12-19 15:38:27 +00:00
|
|
|
}
|
2022-02-07 18:22:40 +00:00
|
|
|
|
2019-12-19 15:38:27 +00:00
|
|
|
@if $t==focus {
|
2023-07-05 16:47:57 +00:00
|
|
|
background-color: mix(transparentize($c, 0.75), $fc, 95%);
|
|
|
|
box-shadow: inset 0 0 0 2px transparentize($fc, 0.3);
|
2022-10-13 16:51:17 +00:00
|
|
|
color: $c;
|
2022-02-07 18:22:40 +00:00
|
|
|
&:hover {}
|
|
|
|
}
|
|
|
|
|
|
|
|
@if $t==hover {
|
2022-10-13 16:51:17 +00:00
|
|
|
background-color: transparentize($c, 0.75);
|
2019-12-19 15:38:27 +00:00
|
|
|
}
|
2022-02-07 18:22:40 +00:00
|
|
|
|
2019-12-19 15:38:27 +00:00
|
|
|
@if $t==insensitive {
|
2022-10-13 16:51:17 +00:00
|
|
|
background-color:transparentize($c, 0.75);
|
|
|
|
color: transparentize($c, 0.5);
|
2019-12-19 15:38:27 +00: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 18:22:55 +00:00
|
|
|
}
|
|
|
|
|
2022-02-02 18:17:42 +00: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 18:22:55 +00:00
|
|
|
//
|
2022-02-02 18:17:42 +00: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 18:22:55 +00:00
|
|
|
//
|
2022-02-02 18:17:42 +00: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 18:22:55 +00:00
|
|
|
//
|
2022-02-02 18:17:42 +00: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 18:22:55 +00:00
|
|
|
//
|
|
|
|
|
2022-02-02 18:17:42 +00: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 18:22:55 +00:00
|
|
|
|
2022-02-02 18:17:42 +00: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);
|
|
|
|
}
|
2022-02-07 18:22:40 +00:00
|
|
|
&:active {
|
|
|
|
background-color: mix(lighten($c, 10%), $selected_bg_color, 90%);
|
|
|
|
box-shadow: inset 0 0 0 2px transparentize($selected_bg_color, 0.3);
|
|
|
|
}
|
2022-02-02 18:17:42 +00: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 18:22:55 +00:00
|
|
|
|
2022-02-02 18:17:42 +00:00
|
|
|
// hover key
|
|
|
|
@else if $t==hover {
|
|
|
|
color: $tc;
|
2022-02-07 18:22:40 +00:00
|
|
|
background-color: lighten($c, 7%);
|
2019-12-19 15:38:27 +00:00
|
|
|
}
|
2022-02-02 18:17:42 +00:00
|
|
|
|
|
|
|
// active key
|
|
|
|
@else if $t==active {
|
|
|
|
color: $tc;
|
2022-02-07 18:22:40 +00:00
|
|
|
background-color: lighten($c, 10%);
|
|
|
|
}
|
|
|
|
|
|
|
|
// checked key
|
|
|
|
@else if $t==checked {
|
|
|
|
color: $tc;
|
|
|
|
background-color: lighten($c, 15%);
|
2022-02-02 18:17:42 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// 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 15:38:27 +00: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 18:22:55 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//
|
|
|
|
// Button drawing function
|
|
|
|
//
|
|
|
|
// $t: button type,
|
2022-02-02 18:17:42 +00: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 18:22:55 +00: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
|
|
|
|
//
|
2022-05-27 18:09:45 +00:00
|
|
|
// since buttons are all flat an borderless now the mixin is simpler
|
|
|
|
|
2023-07-18 13:00:50 +00:00
|
|
|
@mixin button($t, $tc:$fg_color, $c:$bg_color, $flat: false, $osd: false) {
|
2022-05-27 18:09:45 +00:00
|
|
|
|
2022-08-22 16:11:27 +00:00
|
|
|
$button_bg_color: mix($tc, $c, $button_mix_factor);
|
2022-05-27 18:09:45 +00:00
|
|
|
transition-duration: 100ms;
|
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 18:22:55 +00:00
|
|
|
|
2023-07-18 13:00:50 +00:00
|
|
|
@if $osd {
|
|
|
|
$button_bg_color: transparentize($tc, 0.9);
|
|
|
|
}
|
|
|
|
|
2019-12-19 15:38:27 +00:00
|
|
|
// normal button
|
|
|
|
@if $t==normal {
|
|
|
|
color: $tc;
|
2022-02-07 18:22:40 +00:00
|
|
|
background-color: $button_bg_color;
|
2022-10-13 16:51:17 +00:00
|
|
|
@if $flat {
|
|
|
|
background-color: transparent;
|
|
|
|
}
|
2022-11-03 15:28:24 +00:00
|
|
|
@if $is_highcontrast {
|
|
|
|
box-shadow: inset 0 0 0 1px $hc_inset_color;
|
2022-02-02 18:17:42 +00:00
|
|
|
}
|
2019-12-19 15:38:27 +00:00
|
|
|
}
|
|
|
|
|
2022-10-13 16:51:17 +00:00
|
|
|
// focused button
|
|
|
|
@if $t==focus {
|
|
|
|
color: $tc;
|
|
|
|
background-color: mix($button_bg_color, $selected_bg_color, 90%);
|
|
|
|
box-shadow: inset 0 0 0 2px transparentize($selected_bg_color, 0.4) !important;
|
|
|
|
&:hover {
|
|
|
|
background-color: mix(lighten($button_bg_color, 3%), $selected_bg_color, 90%);
|
|
|
|
box-shadow: inset 0 0 0 2px transparentize($selected_bg_color, 0.3) !important;
|
|
|
|
}
|
|
|
|
&:active {
|
|
|
|
background-color: mix(lighten($button_bg_color, 6%), $selected_bg_color, 90%);
|
|
|
|
box-shadow: inset 0 0 0 2px transparentize($selected_bg_color, 0.3) !important;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-01-17 10:57:42 +00:00
|
|
|
// hover button
|
2019-12-19 15:38:27 +00:00
|
|
|
@else if $t==hover {
|
|
|
|
color: $tc;
|
2022-10-13 16:51:17 +00:00
|
|
|
background-color: if($variant == 'light', darken($button_bg_color, 3%), lighten($button_bg_color, 3%));
|
|
|
|
|
|
|
|
@if $is_highcontrast == "true" {
|
|
|
|
box-shadow: inset 0 0 0 1px lighten($button_inset_color, 3%);
|
|
|
|
background-color: mix(lighten($button_bg_color, 3%), $button_inset_color, 10%);
|
2022-08-22 16:11:27 +00:00
|
|
|
}
|
2019-12-19 15:38:27 +00:00
|
|
|
}
|
|
|
|
|
2020-01-17 10:57:42 +00:00
|
|
|
// active button
|
2019-12-19 15:38:27 +00:00
|
|
|
@else if $t==active {
|
|
|
|
color: $tc;
|
2022-10-13 16:51:17 +00:00
|
|
|
background-color: if($variant == 'light', darken($button_bg_color, 6%), lighten($button_bg_color, 6%));
|
|
|
|
@if $is_highcontrast == "true" {
|
|
|
|
box-shadow: inset 0 0 0 1px lighten($button_inset_color, 6%);
|
|
|
|
background-color: mix(lighten($button_bg_color, 6%), $button_inset_color, 10%);
|
|
|
|
}
|
2022-02-07 18:22:40 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// checked button
|
|
|
|
@else if $t==checked {
|
|
|
|
color: $tc;
|
2022-10-13 16:51:17 +00:00
|
|
|
background-color: if($variant == 'light', darken($button_bg_color, 9%), lighten($button_bg_color, 9%));
|
|
|
|
@if $is_highcontrast == "true" {
|
|
|
|
box-shadow: inset 0 0 0 1px lighten($button_inset_color, 9%);
|
|
|
|
background-color: mix(lighten($button_bg_color, 9%), $button_inset_color, 10%);
|
|
|
|
}
|
2022-02-07 18:22:40 +00:00
|
|
|
&:hover { background-color: lighten($button_bg_color, 12%);}
|
|
|
|
&:active { background-color: lighten($button_bg_color, 15%);}
|
2019-12-19 15:38:27 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// insensitive button
|
|
|
|
@else if $t==insensitive {
|
2023-07-19 13:01:09 +00:00
|
|
|
color: if($variant == 'light', transparentize($tc, .6), transparentize($tc, .5));
|
2023-07-05 16:43:39 +00:00
|
|
|
background-color: if($variant == 'light', transparentize($tc, .9), transparentize($tc, .95));
|
2019-12-19 15:38:27 +00:00
|
|
|
}
|
|
|
|
|
2022-02-02 18:17:42 +00:00
|
|
|
// default/suggested button
|
|
|
|
@else if $t==default {
|
|
|
|
background-color: $selected_bg_color;
|
|
|
|
color: $selected_fg_color;
|
2022-11-03 15:28:24 +00:00
|
|
|
|
2022-02-02 18:17:42 +00:00
|
|
|
&:focus {
|
2022-11-03 15:28:24 +00:00
|
|
|
box-shadow: inset 0 0 0 2px transparentize($selected_fg_color, .4) !important;
|
2022-02-02 18:17:42 +00:00
|
|
|
}
|
2022-11-03 15:28:24 +00:00
|
|
|
&:hover, &:focus {
|
2022-02-02 18:17:42 +00:00
|
|
|
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);
|
|
|
|
}
|
|
|
|
}
|
2022-02-07 18:22:40 +00:00
|
|
|
|
2019-12-19 15:38:27 +00:00
|
|
|
// reset
|
|
|
|
@else if $t==undecorated {
|
|
|
|
background-color: transparent;
|
2022-02-02 18:17:42 +00:00
|
|
|
background-color: none;
|
2022-08-22 16:11:27 +00:00
|
|
|
box-shadow: none;
|
2022-02-07 18:22:40 +00:00
|
|
|
&:insensitive {
|
2023-08-28 18:46:24 +00:00
|
|
|
@include button(insensitive);
|
2022-02-07 18:22:40 +00:00
|
|
|
background-color: transparent;
|
|
|
|
}
|
2022-02-02 18:17:42 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// tile
|
2022-02-07 18:22:40 +00:00
|
|
|
@mixin tile_button($color, $flat: true) {
|
2022-02-02 18:17:42 +00:00
|
|
|
@extend %tile;
|
2022-02-07 18:22:40 +00:00
|
|
|
@if $flat {
|
|
|
|
background-color: transparent;
|
|
|
|
} @else {
|
|
|
|
background-color: transparentize($color, .84);
|
2022-11-03 15:28:24 +00:00
|
|
|
@if $is_highcontrast {
|
|
|
|
box-shadow: inset 999px 0 0 0 transparentize($color, .2); // bit of a hack
|
|
|
|
}
|
2022-02-02 18:17:42 +00:00
|
|
|
}
|
2022-02-07 18:22:40 +00:00
|
|
|
&:hover { background-color: transparentize($color, .9);}
|
|
|
|
&:selected, &:focus {
|
|
|
|
background-color: transparentize($color, .87);
|
|
|
|
&:hover { background-color: transparentize($color, .84);}
|
|
|
|
&:active { background-color: transparentize($color, .87);}
|
2022-02-02 18:17:42 +00:00
|
|
|
}
|
2022-02-07 18:22:40 +00:00
|
|
|
&:active { background-color: transparentize($color, .84);}
|
|
|
|
&:outlined, &:checked {
|
|
|
|
background-color: transparentize($color, .81);
|
|
|
|
&:active { background-color: transparentize($color, .78);}
|
|
|
|
&:hover { background-color: transparentize($color, .75);}
|
2022-02-02 18:17:42 +00:00
|
|
|
}
|
2022-02-07 18:22:40 +00:00
|
|
|
&:drop {
|
|
|
|
border: 2px solid transparentize($selected_bg_color, .2); //already 2px transparent so no jumping
|
|
|
|
background-color: transparentize($selected_bg_color, .8);
|
2019-12-19 15:38:27 +00:00
|
|
|
}
|
|
|
|
}
|
2020-01-25 08:53:17 +00:00
|
|
|
|
2022-02-07 18:22:40 +00:00
|
|
|
// overview icon, dash, app grid
|
|
|
|
@mixin overview_icon($color, $flat: true) {
|
2022-05-27 18:09:45 +00:00
|
|
|
transition-duration: 400ms;
|
2022-10-13 16:51:17 +00:00
|
|
|
.overview-icon {
|
2022-11-03 15:28:24 +00:00
|
|
|
@extend %tile;
|
|
|
|
}
|
2022-02-07 18:22:40 +00:00
|
|
|
@if $flat {
|
|
|
|
.overview-icon { background-color: transparent;}
|
|
|
|
} @else {
|
2022-10-13 16:51:17 +00:00
|
|
|
.overview-icon { background-color: transparentize($color, .93); }
|
2020-01-25 08:53:17 +00:00
|
|
|
}
|
2022-10-13 16:51:17 +00:00
|
|
|
&:hover .overview-icon { background-color: transparentize($color, .87);}
|
2020-01-25 08:53:17 +00:00
|
|
|
|
2022-02-07 18:22:40 +00:00
|
|
|
&:selected .overview-icon,
|
|
|
|
&:focus .overview-icon {
|
|
|
|
background-color: transparentize($color, .87);
|
|
|
|
&:hover .overview-icon { background-color: transparentize($color, .84);}
|
|
|
|
&:active .overview-icon { background-color: transparentize($color, .87);}
|
2020-01-25 08:53:17 +00:00
|
|
|
}
|
2022-02-07 18:22:40 +00:00
|
|
|
&:active .overview-icon { background-color: transparentize($color, .84);}
|
|
|
|
&:outlined .overview-icon,
|
|
|
|
&:checked .overview-icon {
|
|
|
|
background-color: transparentize($color, .81);
|
|
|
|
&:active .overview-icon { background-color: transparentize($color, .78);}
|
|
|
|
&:hover .overview-icon { background-color: transparentize($color, .75);}
|
2020-01-25 08:53:17 +00:00
|
|
|
}
|
2022-02-07 18:22:40 +00:00
|
|
|
&:drop .overview-icon {
|
|
|
|
border: 2px solid transparentize($selected_bg_color, .2); //already 2px transparent so no jumping
|
|
|
|
background-color: transparentize($selected_bg_color, .8);
|
2020-01-25 08:53:17 +00:00
|
|
|
}
|
|
|
|
}
|
2022-02-02 18:17:42 +00:00
|
|
|
|
|
|
|
// styling for elements within popovers that look like notifications
|
|
|
|
@mixin card($flat: false) {
|
2022-11-03 15:28:24 +00:00
|
|
|
border-radius: $base_border_radius*1.5;
|
2022-02-02 18:17:42 +00:00
|
|
|
margin: $base_margin;
|
|
|
|
|
|
|
|
@if $flat {
|
|
|
|
@include button(undecorated);
|
|
|
|
box-shadow: none !important;
|
|
|
|
} @else {
|
2022-11-03 15:28:24 +00:00
|
|
|
@include button(normal);
|
2022-02-02 18:17:42 +00:00
|
|
|
}
|
2022-11-03 15:28:24 +00:00
|
|
|
&:hover {@include button(hover);}
|
|
|
|
&:active {@include button(active);}
|
|
|
|
&:focus {@include button(focus);}
|
2022-10-13 16:51:17 +00:00
|
|
|
&:insensitive {
|
|
|
|
@include button(insensitive);
|
|
|
|
@if $flat {
|
|
|
|
background-color: transparent;
|
|
|
|
}
|
|
|
|
}
|
2022-11-03 15:28:24 +00:00
|
|
|
}
|
2022-02-02 18:17:42 +00:00
|
|
|
|
2022-12-01 18:14:04 +00:00
|
|
|
// styling for all menuitems in popovers
|
2022-11-03 15:28:24 +00:00
|
|
|
@mixin menuitem($bg, $flat: true) {
|
2022-02-02 18:17:42 +00:00
|
|
|
|
2022-11-03 15:28:24 +00:00
|
|
|
// lighten the background color always
|
|
|
|
$bg: lighten($bg,5%);
|
|
|
|
|
|
|
|
font-weight: normal;
|
|
|
|
spacing: $base_padding;
|
|
|
|
transition-duration: 100ms;
|
|
|
|
padding: $base_padding*1.5 $base_padding*2;
|
2022-02-02 18:17:42 +00:00
|
|
|
|
2022-11-03 15:28:24 +00:00
|
|
|
@if $flat {
|
|
|
|
@include button(undecorated);
|
|
|
|
box-shadow: none !important;
|
|
|
|
} @else {
|
|
|
|
@include button(normal, $c:$bg);
|
|
|
|
}
|
|
|
|
&:focus,
|
|
|
|
&:hover {
|
|
|
|
@include button(hover, $c:$bg);
|
2022-02-02 18:17:42 +00:00
|
|
|
}
|
2022-11-03 15:28:24 +00:00
|
|
|
&:active {@include button(active, $c:$bg);}
|
|
|
|
&:checked {@include button(checked, $c:$bg);}
|
2022-02-02 18:17:42 +00:00
|
|
|
}
|
2023-06-19 19:52:29 +00:00
|
|
|
|
|
|
|
//
|
|
|
|
// Panel menu/button drawing function
|
|
|
|
//
|
|
|
|
// $bg: background color, derived from $panel_fg_color
|
|
|
|
// $fg: foreground color, also derived from $panel_fg_color
|
|
|
|
//
|
|
|
|
// $flat: if true, the button is filled instead of transparent
|
|
|
|
// $highlighted_child: if true, applies some special overrides for to a
|
|
|
|
// child element, see _panel.scss for details
|
2023-07-05 15:00:14 +00:00
|
|
|
// $child_class: class name of the child element
|
2023-06-19 19:52:29 +00:00
|
|
|
//
|
|
|
|
|
|
|
|
@mixin panel_button($bg:$panel_fg_color, $fg:$panel_fg_color, $flat: true, $highlighted_child: false, $child_class:"") {
|
|
|
|
|
|
|
|
transition-duration: 150ms;
|
|
|
|
border: 3px solid transparent;
|
|
|
|
border-radius: 99px;
|
|
|
|
|
|
|
|
font-weight: bold;
|
|
|
|
background-color: transparent;
|
|
|
|
color: $fg;
|
|
|
|
|
|
|
|
@if $flat {
|
|
|
|
box-shadow: none;
|
|
|
|
|
2023-07-05 15:00:14 +00:00
|
|
|
&:active, &:focus, &:checked {
|
|
|
|
box-shadow: inset 0 0 0 100px transparentize($fg, 0.75);
|
2023-06-19 19:52:29 +00:00
|
|
|
&:hover {
|
2023-07-05 15:00:14 +00:00
|
|
|
box-shadow: inset 0 0 0 100px transparentize($fg, 0.65);
|
2023-06-19 19:52:29 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
&:hover {
|
2023-07-05 15:00:14 +00:00
|
|
|
box-shadow: inset 0 0 0 100px transparentize($fg, 0.8);
|
2023-06-19 19:52:29 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
} @else {
|
|
|
|
box-shadow: inset 0 0 0 100px transparentize($bg, 0.2);
|
|
|
|
|
2023-07-05 15:00:14 +00:00
|
|
|
&:active, &:focus, &:checked {
|
2023-06-19 19:52:29 +00:00
|
|
|
box-shadow: inset 0 0 0 100px $bg;
|
|
|
|
&:hover {
|
|
|
|
box-shadow: inset 0 0 0 100px transparentize($bg, 0.05);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
&:hover {
|
|
|
|
box-shadow: inset 0 0 0 100px transparentize($bg, 0.1);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// some overrides to style a child element
|
|
|
|
@if $highlighted_child {
|
|
|
|
box-shadow: none !important;
|
|
|
|
|
|
|
|
#{$child_class} {
|
|
|
|
transition-duration: 150ms;
|
|
|
|
border: 3px solid transparent;
|
|
|
|
border-radius: 99px;
|
|
|
|
}
|
|
|
|
|
2023-07-05 15:00:14 +00:00
|
|
|
&:active, &:focus, &:checked {
|
2023-06-19 19:52:29 +00:00
|
|
|
box-shadow: none !important;
|
|
|
|
|
|
|
|
#{$child_class} {
|
2023-07-05 15:00:14 +00:00
|
|
|
box-shadow: inset 0 0 0 100px transparentize($fg, 0.75);
|
2023-06-19 19:52:29 +00:00
|
|
|
|
2023-07-05 15:00:14 +00:00
|
|
|
&:hover {
|
|
|
|
box-shadow: inset 0 0 0 100px transparentize($fg, 0.65) !important;
|
2023-06-19 19:52:29 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
&:hover {
|
|
|
|
box-shadow: none !important;
|
|
|
|
#{$child_class} {
|
2023-07-05 15:00:14 +00:00
|
|
|
box-shadow: inset 0 0 0 100px transparentize($fg, 0.8);
|
2023-06-19 19:52:29 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|