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

313 lines
8.3 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 13:22:55 -05:00
// Drawing mixins
// generic drawing of more complex things
@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
@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) {
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
}
@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;
//
@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) {
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 drawing function
//
// $t: entry type
// $fc: focus color
//
// possible $t values:
// normal, focus, insensitive
//
@if $t==normal {
background-color: lighten($bg_color, 5%);
color: transparentize($fg_color,0.3);
border: 2px solid lighten($bg_color, 5%);
}
@if $t==focus {
background-color: mix(lighten($bg_color, 5%), $selected_bg_color, 95%);
border-color: $fc;
color: $fg_color;
&:hover {}
}
@if $t==hover {
background-color:lighten($hover_bg_color, 5%);
border-color:lighten($hover_bg_color, 5%);
color: transparentize($fg_color,0.3);
}
@if $t==insensitive {
background-color:lighten($insensitive_bg_color, 5%);
border-color: lighten($insensitive_bg_color, 5%);
color: $insensitive_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
}
// 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
//
// 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
//
// $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
//
// 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
//
// 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
// 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 13:22:55 -05: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 13:22:55 -05:00
}
// buttons
// since buttons are all flat an borderless now the mixin is simpler
@mixin button($t, $tc:$fg_color, $c:$bg_color) {
$button_bg_color: mix($tc, $c, 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 13:22:55 -05: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 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
//
// normal button
@if $t==normal {
color: $tc;
background-color: $button_bg_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);
&: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);
}
&: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);
}
}
// hover button
@else if $t==hover {
color: $tc;
background-color: lighten($button_bg_color, 3%);
}
// active button
@else if $t==active {
color: $tc;
background-color: lighten($button_bg_color, 6%);
}
// checked button
@else if $t==checked {
color: $tc;
background-color: lighten($button_bg_color, 9%);
&:hover { background-color: lighten($button_bg_color, 12%);}
&:active { background-color: lighten($button_bg_color, 15%);}
}
// insensitive button
@else if $t==insensitive {
color: transparentize($tc, 0.5);
background-color: transparentize($tc, .95);
}
// 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);
}
}
// reset
@else if $t==undecorated {
background-color: transparent;
background-color: none;
&:insensitive {
@include button(insensitive);
background-color: transparent;
color: transparentize($selected_fg_color, .5);
}
}
}
// tile
@mixin tile_button($color, $flat: true) {
@extend %tile;
@if $flat {
background-color: transparent;
} @else {
background-color: transparentize($color, .84);
}
&: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) {
.overview-icon { @extend %tile; }
@if $flat {
.overview-icon { background-color: transparent;}
} @else {
.overview-icon { background-color: transparentize($color, .81);}
}
&:hover .overview-icon { background-color: transparentize($color, .9);}
&: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;
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);
}
}