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

222 lines
5.9 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 _widget_edge($c:$borders_edge) {
// outer highlight "used" on most widgets
@return 0 1px $c;
}
// provide font size in rem, with px fallback
@mixin fontsize($size: 24, $base: 16) {
font-size: round($size) + pt;
//font-size: ($size / $base) * 1rem;
}
@mixin _shadows($shadow1, $shadow2:none, $shadow3:none, $shadow4:none) {
//
// 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; }
}
// entries
@mixin entry($t, $fc:$selected_bg_color, $edge: $borders_edge) {
//
// Entries drawing function
//
// $t: entry type
// $fc: focus color
// $edge: set to none to not draw the bottom edge or specify a color to not
// use the default one
//
// possible $t values:
// normal, focus, insensitive
//
@if $t==normal {
background-color: $base_color;
border-color: $osd_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
}
@if $t==focus {
border-color: if($fc==$selected_bg_color,
$selected_borders_color,
darken($fc,35%));
}
@if $t==hover { }
@if $t==insensitive {
color: $insensitive_fg_color;
border-color: $insensitive_bg_color;
box-shadow: none;
}
}
// buttons
@function _border_color ($c) { @return darken($c,25%); } // colored buttons want
// the border form the
// base color
@function _text_shadow_color ($tc:$fg_color, $bg:$bg_color) {
//
// calculate the color of text shadows
//
// $tc is the text color
// $bg is the background color
//
$_lbg: lightness($bg)/100%;
@if lightness($tc)<50% { @return transparentize(white,1-$_lbg/($_lbg*1.3)); }
@else { @return transparentize(black,$_lbg*0.8); }
}
@function _button_hilight_color($c) {
//
// calculate the right top hilight color for buttons
//
// $c: base color;
//
@if lightness($c)>90% { @return white; }
@else if lightness($c)>80% { @return transparentize(white, 0.3); }
@else if lightness($c)>50% { @return transparentize(white, 0.5); }
@else if lightness($c)>40% { @return transparentize(white, 0.7); }
@else { @return transparentize(white, 0.9); }
}
@mixin _button_text_shadow ($tc:$fg_color, $bg:$bg_color) {
//
// helper function for the text emboss effect
//
// $tc is the optional text color, not the shadow color
//
// TODO: this functions needs a way to deal with special cases
//
$_shadow: _text_shadow_color($tc, $bg);
@if lightness($tc)<50% {
text-shadow: 0 1px $_shadow;
icon-shadow: 0 1px $_shadow;
}
@else {
text-shadow: 0 -1px $_shadow;
icon-shadow: 0 -1px $_shadow;
}
}
@mixin button($t, $c:$osd_bg_color, $tc:$fg_color, $edge: $borders_edge) {
//
// Button drawing function
//
// $t: button type,
// $c: base button color for colored* types
// $tc: optional text color for colored* types
// $edge: set to none to not draw the bottom edge or specify a color to not
// use the default one
//
// 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
//
$_hilight_color: _button_hilight_color($c);
$_button_edge: if($edge == none, none, _widget_edge($edge));
$_blank_edge: if($edge == none, none, _widget_edge(transparentize($edge,1)));
@if $t==normal {
//
// normal button
//
color: if($bubble_bg_color, $tc, $osd_fg_color);
background-color: if($osd_bg_color or $bubble_bg_color, $c, 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
border-color: $osd_borders_color;
box-shadow: none;
theme: Replace gnome-shell-sass submodule with subtree As the style has grown bigger and more complex, generating the different variants from a common source has been a good decision. However given how intertwined the theme is with gnome-shell itself, relying on a submodule has proven to be quite painful. And as things stand right now, it is going to get worse: - using either pre-generated CSS or generating it at build time is odd, and violates meson's strict separation between source- and build directories; we are therefore considering dropping the CSS and depending on sassc to always generate it at build time - with the migration to gitlab, our workflow shifts decisively towards branches; however there is no support in either git or gitlab for handling two brances of separate repositories consecutively, which gets particularly awkward for branches in a private namespace With those pain points in mind, we will adjust our setup as follows: - remove the submodule from gnome-shell and instead import the sass as subtree - after that, the sass sources can be changed like any other files in the repository, and regular contributors can forget that there was ever anything special about them - whenever we want to update the classic style, we can push the subtree changes and bump gnome-shell-extension's sass submodule In other words: Updating the classic styling will become slightly more painful, but not much and only for me; in return, everyone else can stop fiddling with submodules (and buy me a beer).
2018-02-09 18:22:55 +00:00
text-shadow: 0 1px black;
icon-shadow: 0 1px black;
}
@if $t==focus {
//
// focused button
//
color: if($bubble_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
text-shadow: 0 1px black;
icon-shadow: 0 1px black;
box-shadow: inset 0px 0px 0px 1px $selected_bg_color;
}
@else if $t==hover {
//
// active osd button
//
$_bg: $c;
$_fg: white;
$_bc: $osd_borders_color;
@if $c==$osd_bg_color {
$_bg: lighten($osd_bg_color,3%);
}
@else if $c==$bubble_bg_color {
$_bg: $bubble_hover_bg_color;
$_fg: $bubble_fg_color;
$_bc: $bubble_borders_color;
}
@else {
$_bg: transparentize($c, 0.3);
}
color: $_fg;
border-color: $_bc;
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
background-color: $_bg;
box-shadow: none;
theme: Replace gnome-shell-sass submodule with subtree As the style has grown bigger and more complex, generating the different variants from a common source has been a good decision. However given how intertwined the theme is with gnome-shell itself, relying on a submodule has proven to be quite painful. And as things stand right now, it is going to get worse: - using either pre-generated CSS or generating it at build time is odd, and violates meson's strict separation between source- and build directories; we are therefore considering dropping the CSS and depending on sassc to always generate it at build time - with the migration to gitlab, our workflow shifts decisively towards branches; however there is no support in either git or gitlab for handling two brances of separate repositories consecutively, which gets particularly awkward for branches in a private namespace With those pain points in mind, we will adjust our setup as follows: - remove the submodule from gnome-shell and instead import the sass as subtree - after that, the sass sources can be changed like any other files in the repository, and regular contributors can forget that there was ever anything special about them - whenever we want to update the classic style, we can push the subtree changes and bump gnome-shell-extension's sass submodule In other words: Updating the classic styling will become slightly more painful, but not much and only for me; in return, everyone else can stop fiddling with submodules (and buy me a beer).
2018-02-09 18:22:55 +00:00
text-shadow: 0 1px black;
icon-shadow: 0 1px black;
}
@else if $t==active {
//
// active osd button
//
color: if($c==$bubble_bg_color, $bubble_active_fg_color, white);
border-color: if($c==$bubble_bg_color, $bubble_borders_color, $osd_borders_color);
background-color: if($c==$bubble_bg_color, $bubble_active_bg_color, $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
// This should be none, but it's creating some issues with borders, so to
// workaround it for now, use inset wich goes through a different code path.
// see https://bugzilla.gnome.org/show_bug.cgi?id=752934
text-shadow: none;
icon-shadow: none;
}
@else if $t==insensitive {
//
// insensitive osd button
//
$_bg: transparentize(mix($insensitive_fg_color,if($c==$bubble_bg_color, $bubble_bg_color, $osd_bg_color), 20%),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
color: $insensitive_fg_color;
border-color: if($c==$bubble_bg_color, $bubble_borders_color, $osd_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
background-color: $_bg;
box-shadow: none;
text-shadow: none;
icon-shadow: none;
}
@else if $t==undecorated {
//
// reset
//
border-color: transparent;
background-color: transparent;
background-image: none;
@include _shadows(inset 0 1px transparentize(white,1),
$_blank_edge);
text-shadow: none;
icon-shadow: none;
}
}