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
|
|
|
|
|
|
2019-12-18 16:25:03 -05:00
|
|
|
@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
|
2019-12-18 16:25:03 -05:00
|
|
|
@return 0 1px $c;
|
theme: Replace gnome-shell-sass submodule with subtree
As the style has grown bigger and more complex, generating the different
variants from a common source has been a good decision. However given how
intertwined the theme is with gnome-shell itself, relying on a submodule
has proven to be quite painful. And as things stand right now, it is going
to get worse:
- using either pre-generated CSS or generating it at build time is
odd, and violates meson's strict separation between source- and
build directories; we are therefore considering dropping the CSS
and depending on sassc to always generate it at build time
- with the migration to gitlab, our workflow shifts decisively towards
branches; however there is no support in either git or gitlab for
handling two brances of separate repositories consecutively, which
gets particularly awkward for branches in a private namespace
With those pain points in mind, we will adjust our setup as follows:
- remove the submodule from gnome-shell and instead import the
sass as subtree
- after that, the sass sources can be changed like any other files
in the repository, and regular contributors can forget that there
was ever anything special about them
- whenever we want to update the classic style, we can push the subtree
changes and bump gnome-shell-extension's sass submodule
In other words: Updating the classic styling will become slightly more
painful, but not much and only for me; in return, everyone else can
stop fiddling with submodules (and buy me a beer).
2018-02-09 13:22:55 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// provide font size in rem, with px fallback
|
|
|
|
|
@mixin fontsize($size: 24, $base: 16) {
|
2019-12-18 16:25:03 -05:00
|
|
|
font-size: round($size) + pt;
|
|
|
|
|
//font-size: ($size / $base) * 1rem;
|
theme: Replace gnome-shell-sass submodule with subtree
As the style has grown bigger and more complex, generating the different
variants from a common source has been a good decision. However given how
intertwined the theme is with gnome-shell itself, relying on a submodule
has proven to be quite painful. And as things stand right now, it is going
to get worse:
- using either pre-generated CSS or generating it at build time is
odd, and violates meson's strict separation between source- and
build directories; we are therefore considering dropping the CSS
and depending on sassc to always generate it at build time
- with the migration to gitlab, our workflow shifts decisively towards
branches; however there is no support in either git or gitlab for
handling two brances of separate repositories consecutively, which
gets particularly awkward for branches in a private namespace
With those pain points in mind, we will adjust our setup as follows:
- remove the submodule from gnome-shell and instead import the
sass as subtree
- after that, the sass sources can be changed like any other files
in the repository, and regular contributors can forget that there
was ever anything special about them
- whenever we want to update the classic style, we can push the subtree
changes and bump gnome-shell-extension's sass submodule
In other words: Updating the classic styling will become slightly more
painful, but not much and only for me; in return, everyone else can
stop fiddling with submodules (and buy me a beer).
2018-02-09 13:22:55 -05:00
|
|
|
}
|
|
|
|
|
|
2019-12-18 16:25:03 -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;
|
|
|
|
|
//
|
2019-12-18 16:25:03 -05:00
|
|
|
@if $shadow4!=none { box-shadow: $shadow1, $shadow2, $shadow3, $shadow4; }
|
|
|
|
|
@else if $shadow3!=none { box-shadow: $shadow1, $shadow2, $shadow3; }
|
|
|
|
|
@else if $shadow2!=none { box-shadow: $shadow1, $shadow2; }
|
|
|
|
|
@else { box-shadow: $shadow1; }
|
theme: Replace gnome-shell-sass submodule with subtree
As the style has grown bigger and more complex, generating the different
variants from a common source has been a good decision. However given how
intertwined the theme is with gnome-shell itself, relying on a submodule
has proven to be quite painful. And as things stand right now, it is going
to get worse:
- using either pre-generated CSS or generating it at build time is
odd, and violates meson's strict separation between source- and
build directories; we are therefore considering dropping the CSS
and depending on sassc to always generate it at build time
- with the migration to gitlab, our workflow shifts decisively towards
branches; however there is no support in either git or gitlab for
handling two brances of separate repositories consecutively, which
gets particularly awkward for branches in a private namespace
With those pain points in mind, we will adjust our setup as follows:
- remove the submodule from gnome-shell and instead import the
sass as subtree
- after that, the sass sources can be changed like any other files
in the repository, and regular contributors can forget that there
was ever anything special about them
- whenever we want to update the classic style, we can push the subtree
changes and bump gnome-shell-extension's sass submodule
In other words: Updating the classic styling will become slightly more
painful, but not much and only for me; in return, everyone else can
stop fiddling with submodules (and buy me a beer).
2018-02-09 13:22:55 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// entries
|
|
|
|
|
|
|
|
|
|
@mixin entry($t, $fc:$selected_bg_color, $edge: $borders_edge) {
|
|
|
|
|
//
|
|
|
|
|
// Entries drawing function
|
|
|
|
|
//
|
|
|
|
|
// $t: entry type
|
|
|
|
|
// $fc: focus color
|
2019-12-18 16:25:03 -05:00
|
|
|
// $edge: set to none to not draw the bottom edge or specify a color to not use the default one
|
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, focus, insensitive
|
|
|
|
|
//
|
|
|
|
|
|
2019-12-18 16:25:03 -05:00
|
|
|
@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;
|
|
|
|
|
}
|
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
|
|
|
|
|
|
2019-12-18 16:25:03 -05:00
|
|
|
@function draw_border_color ($c) {
|
|
|
|
|
//
|
|
|
|
|
// colored buttons want the border form the base color
|
|
|
|
|
//
|
|
|
|
|
@return if($variant == 'light', darken($c, 18%), darken($c, 4%));
|
|
|
|
|
}
|
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
|
|
|
|
2019-12-18 16:25:03 -05:00
|
|
|
@function draw_text_shadow_color ($tc:$fg_color, $bg:$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
|
|
|
//
|
|
|
|
|
// calculate the color of text shadows
|
|
|
|
|
//
|
|
|
|
|
// $tc is the text color
|
|
|
|
|
// $bg is the background color
|
|
|
|
|
//
|
2019-12-18 16:25:03 -05:00
|
|
|
$lbg: lightness($bg)/100%;
|
|
|
|
|
@if lightness($tc)<50% { @return rgba(255,255,255,$lbg/($lbg*1.3)); }
|
|
|
|
|
@else { @return rgba(0,0,0,1-$lbg*0.8); }
|
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
|
|
|
}
|
|
|
|
|
|
2019-12-18 16:25:03 -05:00
|
|
|
@function draw_button_hilight_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
|
|
|
//
|
|
|
|
|
// calculate the right top hilight color for buttons
|
|
|
|
|
//
|
|
|
|
|
// $c: base color;
|
|
|
|
|
//
|
2019-12-18 16:25:03 -05:00
|
|
|
@if lightness($c)>90% { @return white; }
|
|
|
|
|
@else if lightness($c)>80% { @return rgba(255,255,255, 0.7); }
|
|
|
|
|
@else if lightness($c)>50% { @return rgba(255,255,255, 0.5); }
|
|
|
|
|
@else if lightness($c)>40% { @return rgba(255,255,255, 0.3); }
|
|
|
|
|
@else { @return rgba(255,255,255, 0.1); }
|
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
|
|
|
}
|
|
|
|
|
|
2019-12-18 16:25:03 -05:00
|
|
|
@mixin draw_button_text_shadow ($tc:$fg_color, $bg:$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
|
|
|
//
|
|
|
|
|
// 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
|
|
|
|
|
//
|
|
|
|
|
|
2019-12-18 16:25:03 -05:00
|
|
|
$shadow: draw_text_shadow_color($tc, $bg);
|
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
|
|
|
|
2019-12-18 16:25:03 -05:00
|
|
|
@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;
|
|
|
|
|
}
|
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
|
|
|
}
|
|
|
|
|
|
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
|
|
|
|
|
//
|
|
|
|
|
|
2019-12-18 16:25:03 -05:00
|
|
|
$hilight_color: draw_button_hilight_color($c);
|
|
|
|
|
$button_edge: if($edge == none, none, draw_widget_edge($edge));
|
|
|
|
|
$blank_edge: if($edge == none, none, draw_widget_edge(transparentize($edge,1)));
|
|
|
|
|
|
|
|
|
|
// normal button
|
|
|
|
|
@if $t==normal {
|
|
|
|
|
color: $tc;
|
|
|
|
|
background-color: lighten($c, 3%) !important;
|
|
|
|
|
border-width: 1px;
|
|
|
|
|
border-style: solid;
|
|
|
|
|
border-color: draw_border_color($c);
|
|
|
|
|
@include draw_shadows(0 1px 1px 0 $shadow_color);
|
|
|
|
|
// box-shadow: 0 1px 1px 0 rgba(0,0,0,0.1);
|
|
|
|
|
text-shadow: 0 1px $text_shadow_color;
|
|
|
|
|
icon-shadow: 0 1px $text_shadow_color;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// focused button
|
|
|
|
|
@if $t==focus {
|
|
|
|
|
color: $tc;
|
|
|
|
|
text-shadow: 0 1px $text_shadow_color;
|
|
|
|
|
icon-shadow: 0 1px $text_shadow_color;
|
|
|
|
|
box-shadow: inset 0 0 0 2px transparentize($selected_bg_color, 0.7);
|
|
|
|
|
//border-color: $selected_bg_color;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// hover osd button
|
|
|
|
|
@else if $t==hover {
|
|
|
|
|
color: $tc;
|
|
|
|
|
background-color: lighten($c, if($variant == 'light', 8%, 5%)) !important;
|
|
|
|
|
border-width: 1px;
|
|
|
|
|
border-style: solid;
|
|
|
|
|
border-color: if($variant == 'light', draw_border_color(lighten($c, 7%)), draw_border_color($c));
|
|
|
|
|
@include draw_shadows(0 1px 1px 0 $shadow_color);
|
|
|
|
|
text-shadow: 0 1px $text_shadow_color;
|
|
|
|
|
icon-shadow: 0 1px $text_shadow_color;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// active osd button
|
|
|
|
|
@else if $t==active {
|
|
|
|
|
color: $tc;
|
|
|
|
|
background-color: darken($c,3%) !important;
|
|
|
|
|
border-width: 1px;
|
|
|
|
|
border-style: solid;
|
|
|
|
|
border-color: draw_border_color(if($variant == 'light', $c, darken($c,7%)));
|
|
|
|
|
text-shadow: none;
|
|
|
|
|
icon-shadow: none;
|
|
|
|
|
box-shadow: none;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// insensitive button
|
|
|
|
|
@else if $t==insensitive {
|
|
|
|
|
color: $insensitive_fg_color;
|
|
|
|
|
border-width: 1px;
|
|
|
|
|
border-style: solid;
|
|
|
|
|
border-color: $insensitive_borders_color;
|
|
|
|
|
background-color: $insensitive_bg_color !important;
|
|
|
|
|
box-shadow: none;
|
|
|
|
|
text-shadow: none;
|
|
|
|
|
icon-shadow: none;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// reset
|
|
|
|
|
@else if $t==undecorated {
|
|
|
|
|
border-color: transparent;
|
|
|
|
|
background-color: transparent;
|
|
|
|
|
background-image: none;
|
|
|
|
|
@include draw_shadows(inset 0 1px rgba(255,255,255,0),$blank_edge);
|
|
|
|
|
text-shadow: none;
|
|
|
|
|
icon-shadow: none;
|
|
|
|
|
}
|
|
|
|
|
}
|