gnome-shell/data/theme/gnome-shell-sass/_drawing.scss

441 lines
12 KiB
SCSS
Raw Normal View History

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
@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
@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) {
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
}
@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;
//
@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
}
// Text entries
@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
// $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
//
// 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
//
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
@if $t==normal {
background-color: transparentize($c, 0.85);
color: transparentize($c,0.3);
@if $is_highcontrast {
box-shadow: inset 0 0 0 1px $hc_inset_color;
}
}
@if $t==focus {
background-color: mix(transparentize($c, 0.75), $fc, 95%);
box-shadow: inset 0 0 0 2px transparentize($fc, 0.3);
color: $c;
&:hover {}
}
@if $t==hover {
background-color: transparentize($c, 0.75);
}
@if $t==insensitive {
background-color:transparentize($c, 0.75);
color: transparentize($c, 0.5);
}
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
}
// 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
//
// 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
//
// $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
//
// 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
//
// 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
// 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);
}
&:active {
background-color: mix(lighten($c, 10%), $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 18:22:55 +00:00
// hover key
@else if $t==hover {
color: $tc;
background-color: lighten($c, 7%);
}
// active key
@else if $t==active {
color: $tc;
background-color: lighten($c, 10%);
}
// checked key
@else if $t==checked {
color: $tc;
background-color: lighten($c, 15%);
}
// 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;
}
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,
// $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
//
// since buttons are all flat an borderless now the mixin is simpler
@mixin button($t, $tc:$fg_color, $c:$bg_color, $flat: false) {
$button_bg_color: mix($tc, $c, $button_mix_factor);
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
// normal button
@if $t==normal {
color: $tc;
background-color: $button_bg_color;
@if $flat {
background-color: transparent;
}
@if $is_highcontrast {
box-shadow: inset 0 0 0 1px $hc_inset_color;
}
}
// 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;
}
}
// hover button
@else if $t==hover {
color: $tc;
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%);
}
}
// active button
@else if $t==active {
color: $tc;
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%);
}
}
// checked button
@else if $t==checked {
color: $tc;
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%);
}
&:hover { background-color: lighten($button_bg_color, 12%);}
&:active { background-color: lighten($button_bg_color, 15%);}
}
// insensitive button
@else if $t==insensitive {
background-color: if($variant == 'light', transparentize($tc, .9), transparentize($tc, .95));
color: if($variant == 'light', transparentize($tc, .6), transparentize($tc, .5));
}
// 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_fg_color, .4) !important;
}
&: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);
}
}
// reset
@else if $t==undecorated {
background-color: transparent;
background-color: none;
box-shadow: none;
&:insensitive {
@include button(insensitive);
background-color: transparent;
}
}
}
// tile
@mixin tile_button($color, $flat: true) {
@extend %tile;
@if $flat {
background-color: transparent;
} @else {
background-color: transparentize($color, .84);
@if $is_highcontrast {
box-shadow: inset 999px 0 0 0 transparentize($color, .2); // bit of a hack
}
}
&: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);}
}
&: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);}
}
&:drop {
border: 2px solid transparentize($selected_bg_color, .2); //already 2px transparent so no jumping
background-color: transparentize($selected_bg_color, .8);
}
}
// overview icon, dash, app grid
@mixin overview_icon($color, $flat: true) {
transition-duration: 400ms;
.overview-icon {
@extend %tile;
}
@if $flat {
.overview-icon { background-color: transparent;}
} @else {
.overview-icon { background-color: transparentize($color, .93); }
}
&:hover .overview-icon { background-color: transparentize($color, .87);}
&: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);}
}
&: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);}
}
&:drop .overview-icon {
border: 2px solid transparentize($selected_bg_color, .2); //already 2px transparent so no jumping
background-color: transparentize($selected_bg_color, .8);
}
}
// styling for elements within popovers that look like notifications
@mixin card($flat: false) {
border-radius: $base_border_radius*1.5;
margin: $base_margin;
@if $flat {
@include button(undecorated);
box-shadow: none !important;
} @else {
@include button(normal);
}
&:hover {@include button(hover);}
&:active {@include button(active);}
&:focus {@include button(focus);}
&:insensitive {
@include button(insensitive);
@if $flat {
background-color: transparent;
}
}
}
// styling for all menuitems in popovers
@mixin menuitem($bg, $flat: true) {
// 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;
@if $flat {
@include button(undecorated);
box-shadow: none !important;
} @else {
@include button(normal, $c:$bg);
}
&:focus,
&:hover {
@include button(hover, $c:$bg);
}
&:active {@include button(active, $c:$bg);}
&:checked {@include button(checked, $c:$bg);}
}
//
// 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
// $child_class: class name of the child element
//
@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;
&:active, &:focus, &:checked {
box-shadow: inset 0 0 0 100px transparentize($fg, 0.75);
&:hover {
box-shadow: inset 0 0 0 100px transparentize($fg, 0.65);
}
}
&:hover {
box-shadow: inset 0 0 0 100px transparentize($fg, 0.8);
}
} @else {
box-shadow: inset 0 0 0 100px transparentize($bg, 0.2);
&:active, &:focus, &:checked {
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;
}
&:active, &:focus, &:checked {
box-shadow: none !important;
#{$child_class} {
box-shadow: inset 0 0 0 100px transparentize($fg, 0.75);
&:hover {
box-shadow: inset 0 0 0 100px transparentize($fg, 0.65) !important;
}
}
}
&:hover {
box-shadow: none !important;
#{$child_class} {
box-shadow: inset 0 0 0 100px transparentize($fg, 0.8);
}
}
}
}