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 _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: $borders_color;
|
|
|
|
|
|
|
|
}
|
|
|
|
@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;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-06-18 09:29:00 -04:00
|
|
|
@mixin button($t, $c:$bg_color, $tc:$fg_color, $edge: $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
|
|
|
//
|
|
|
|
// 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)));
|
2019-06-18 09:29:00 -04:00
|
|
|
$_button_shadow: 0 1px 2px transparentize($shadow_color, 0.03);
|
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
|
|
|
|
|
|
|
@if $t==normal {
|
|
|
|
//
|
|
|
|
// normal button
|
|
|
|
//
|
|
|
|
|
2019-06-18 09:29:00 -04:00
|
|
|
color: $tc;
|
|
|
|
background-color: $c;
|
|
|
|
border-color: $borders_color;
|
|
|
|
box-shadow: $_button_shadow;
|
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
|
|
|
text-shadow: 0 1px black;
|
|
|
|
icon-shadow: 0 1px black;
|
|
|
|
}
|
|
|
|
@if $t==focus {
|
|
|
|
//
|
|
|
|
// focused button
|
2019-06-18 09:29:00 -04:00
|
|
|
//
|
|
|
|
color: $tc;
|
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
|
|
|
text-shadow: 0 1px black;
|
|
|
|
icon-shadow: 0 1px black;
|
2019-06-18 09:29:00 -04:00
|
|
|
box-shadow: inset 0px 0px 0px 2px $selected_bg_color;
|
|
|
|
//border-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 13:22:55 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
@else if $t==hover {
|
|
|
|
//
|
|
|
|
// active osd button
|
|
|
|
//
|
2019-06-18 09:29:00 -04:00
|
|
|
color: $tc;
|
|
|
|
border-color: $borders_color;
|
|
|
|
background-color: $c;
|
|
|
|
box-shadow: $_button_shadow;
|
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
|
|
|
text-shadow: 0 1px black;
|
|
|
|
icon-shadow: 0 1px black;
|
|
|
|
|
|
|
|
}
|
|
|
|
@else if $t==active {
|
|
|
|
//
|
|
|
|
// active osd button
|
|
|
|
//
|
2019-06-18 09:29:00 -04:00
|
|
|
color: $tc;
|
|
|
|
border-color: $borders_color;
|
|
|
|
background-color: $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
|
|
|
text-shadow: none;
|
|
|
|
icon-shadow: none;
|
2019-06-18 09:29:00 -04:00
|
|
|
box-shadow: none;
|
theme: Replace gnome-shell-sass submodule with subtree
As the style has grown bigger and more complex, generating the different
variants from a common source has been a good decision. However given how
intertwined the theme is with gnome-shell itself, relying on a submodule
has proven to be quite painful. And as things stand right now, it is going
to get worse:
- using either pre-generated CSS or generating it at build time is
odd, and violates meson's strict separation between source- and
build directories; we are therefore considering dropping the CSS
and depending on sassc to always generate it at build time
- with the migration to gitlab, our workflow shifts decisively towards
branches; however there is no support in either git or gitlab for
handling two brances of separate repositories consecutively, which
gets particularly awkward for branches in a private namespace
With those pain points in mind, we will adjust our setup as follows:
- remove the submodule from gnome-shell and instead import the
sass as subtree
- after that, the sass sources can be changed like any other files
in the repository, and regular contributors can forget that there
was ever anything special about them
- whenever we want to update the classic style, we can push the subtree
changes and bump gnome-shell-extension's sass submodule
In other words: Updating the classic styling will become slightly more
painful, but not much and only for me; in return, everyone else can
stop fiddling with submodules (and buy me a beer).
2018-02-09 13:22:55 -05:00
|
|
|
}
|
|
|
|
@else if $t==insensitive {
|
|
|
|
|
|
|
|
color: $insensitive_fg_color;
|
2019-06-18 09:29:00 -04:00
|
|
|
border-color: $insensitive_borders_color;
|
|
|
|
background-color: $insensitive_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
|
|
|
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;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|