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 19:22:55 +01: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
|
|
|
|
|
//
|
|
|
|
|
$_inner_shadows: inset 0 2px 4px transparentize(black, 0.6);
|
|
|
|
|
|
|
|
|
|
@if $t==normal {
|
|
|
|
|
background-color: $base_color;
|
|
|
|
|
border-color: $borders_color;
|
|
|
|
|
@include _shadows($_inner_shadows);
|
|
|
|
|
|
|
|
|
|
}
|
|
|
|
|
@if $t==focus {
|
|
|
|
|
@include _shadows($_inner_shadows);
|
|
|
|
|
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-05-27 16:03:40 +02:00
|
|
|
@function _border_color($c, $darker: false) {
|
|
|
|
|
@if $darker == true { @return darken($c, 20%); }
|
|
|
|
|
@else { @return darken($c, 10%); }
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@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)>95% { @return white; }
|
|
|
|
|
@else if lightness($c)>90% { @return transparentize(white, 0.2); }
|
|
|
|
|
@else if lightness($c)>80% { @return transparentize(white, 0.5); }
|
|
|
|
|
@else if lightness($c)>50% { @return transparentize(white, 0.8); }
|
|
|
|
|
@else if lightness($c)>40% { @return transparentize(white, 0.9); }
|
|
|
|
|
@else { @return transparentize(white, 0.98); }
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@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;
|
|
|
|
|
-gtk-icon-shadow: 0 1px $_shadow;
|
|
|
|
|
}
|
|
|
|
|
@else {
|
|
|
|
|
text-shadow: 0 -1px $_shadow;
|
|
|
|
|
-gtk-icon-shadow: 0 -1px $_shadow;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@mixin button($t, $c:$bg_color, $tc:$fg_color, $edge: 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 19:22:55 +01: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-05-27 16:03:40 +02:00
|
|
|
// This mixin sets the $button_fill global variable which containts the button background-image
|
|
|
|
|
//
|
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 19:22:55 +01:00
|
|
|
$_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-05-27 16:03:40 +02: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 19:22:55 +01:00
|
|
|
|
|
|
|
|
@if $t==normal {
|
|
|
|
|
//
|
|
|
|
|
// normal button
|
|
|
|
|
//
|
2019-05-27 16:03:40 +02:00
|
|
|
color: $tc;
|
|
|
|
|
outline-color: transparentize($tc, 0.7);
|
|
|
|
|
border-color: if($c != $bg_color, _border_color($c), $borders_color);
|
|
|
|
|
border-bottom-color: if($c != $bg_color, _border_color($c, true), $alt_borders_color);
|
|
|
|
|
$button_fill: if($variant == 'light', linear-gradient(to top, darken($c, 4%) 2px, $c),
|
|
|
|
|
linear-gradient(to top, darken($c,1%) 2px, $c)) !global;
|
|
|
|
|
background-image: $button_fill;
|
|
|
|
|
@include _button_text_shadow($tc, $c);
|
|
|
|
|
@include _shadows(inset 0 1px $_hilight_color, $_button_edge, $_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 19:22:55 +01:00
|
|
|
|
2019-05-27 16:03:40 +02:00
|
|
|
@else if $t==hover {
|
|
|
|
|
//
|
|
|
|
|
// hovered button
|
|
|
|
|
//
|
|
|
|
|
color: $tc;
|
|
|
|
|
outline-color: transparentize($tc, 0.7);
|
|
|
|
|
border-color: if($c != $bg_color, _border_color($c), $borders_color);
|
|
|
|
|
border-bottom-color: if($c != $bg_color, _border_color($c, true), $alt_borders_color);
|
|
|
|
|
@if $variant == 'light' {
|
|
|
|
|
$button_fill: linear-gradient(to top, $c, lighten($c, 1%) 1px) !global;
|
|
|
|
|
@include _button_text_shadow($tc, lighten($c, 6%));
|
|
|
|
|
@include _shadows(inset 0 1px _button_hilight_color(lighten($c, 6%)), $_button_edge, $_button_shadow);
|
|
|
|
|
}
|
|
|
|
|
@else {
|
|
|
|
|
$button_fill: linear-gradient(to top, darken($c,1%), lighten($c, 1%) 1px) !global;
|
|
|
|
|
@include _button_text_shadow($tc,lighten($c, 6%));
|
|
|
|
|
@include _shadows(inset 0 1px _button_hilight_color(darken($c, 2%)), $_button_edge, $_button_shadow);
|
|
|
|
|
}
|
|
|
|
|
background-image: $button_fill;
|
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 19:22:55 +01:00
|
|
|
}
|
2019-05-27 16:03:40 +02:00
|
|
|
|
|
|
|
|
@if $t==normal-alt {
|
|
|
|
|
//
|
|
|
|
|
// normal button alternative look
|
|
|
|
|
//
|
|
|
|
|
color: $tc;
|
|
|
|
|
outline-color: transparentize($tc, 0.7);
|
|
|
|
|
border-color: if($c != $bg_color, _border_color($c, true), $alt_borders_color);
|
|
|
|
|
@include _button_text_shadow($tc, $c);
|
|
|
|
|
@if $variant == 'light' {
|
|
|
|
|
background-image: linear-gradient(to bottom, lighten($c, 5%) 20%, $c 90%);
|
|
|
|
|
@include _shadows(inset 0 1px _button_hilight_color(lighten($c, 6%)),
|
|
|
|
|
$_button_edge, $_button_shadow);
|
|
|
|
|
}
|
|
|
|
|
@else {
|
|
|
|
|
background-image: linear-gradient(to bottom, darken($c, 3%) 20%, darken($c, 6%) 90%);
|
|
|
|
|
@include _shadows(inset 0 1px $_hilight_color,
|
|
|
|
|
$_button_edge, $_button_shadow);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@else if $t==hover-alt {
|
|
|
|
|
//
|
|
|
|
|
// hovered button alternative look
|
|
|
|
|
//
|
|
|
|
|
color: $tc;
|
|
|
|
|
outline-color: transparentize($tc, 0.7);
|
|
|
|
|
border-color: if($c != $bg_color, _border_color($c, true), $alt_borders_color);
|
|
|
|
|
@if $variant == 'light' {
|
|
|
|
|
$button_fill: linear-gradient(to bottom, lighten($c, 9%) 10%, lighten($c, 4%) 90%) !global;
|
|
|
|
|
@include _shadows(inset 0 1px _button_hilight_color(lighten($c, 6%)),
|
|
|
|
|
$_button_edge, $_button_shadow);
|
|
|
|
|
}
|
|
|
|
|
@else {
|
|
|
|
|
$button_fill: linear-gradient(to bottom, $c 20%, darken($c, 4%) 90%) !global;
|
|
|
|
|
@include _shadows(inset 0 1px $_hilight_color,
|
|
|
|
|
$_button_edge, $_button_shadow);
|
|
|
|
|
}
|
|
|
|
|
background-image: $button_fill;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@else if $t==active {
|
|
|
|
|
//
|
|
|
|
|
// pushed button
|
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 19:22:55 +01:00
|
|
|
//
|
2019-05-27 16:03:40 +02:00
|
|
|
color: $tc;
|
|
|
|
|
outline-color: transparentize($tc, 0.7);
|
|
|
|
|
border-color: if($c != $bg_color, _border_color($c), $borders_color);
|
|
|
|
|
$button_fill: if($variant == 'light', image(darken($c, 14%)), image(darken($c, 9%))) !global;
|
|
|
|
|
background-image: $button_fill;
|
|
|
|
|
@include _shadows(inset 0 1px transparentize($_hilight_color, 1), $_button_edge);
|
|
|
|
|
|
|
|
|
|
text-shadow: none;
|
|
|
|
|
-gtk-icon-shadow: none;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@else if $t==insensitive {
|
|
|
|
|
//
|
|
|
|
|
// insensitive button
|
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 19:22:55 +01:00
|
|
|
//
|
2019-05-27 16:03:40 +02:00
|
|
|
$_bg: if($c != $bg_color, mix($c, $base_color, 85%), $insensitive_bg_color);
|
|
|
|
|
|
|
|
|
|
label, & { color: if($tc != $fg_color, mix($tc, $_bg, 50%), $insensitive_fg_color); }
|
|
|
|
|
|
|
|
|
|
border-color: if($c != $bg_color, _border_color($c), $insensitive_borders_color);
|
|
|
|
|
$button_fill: image($_bg) !global;
|
|
|
|
|
background-image: $button_fill;
|
|
|
|
|
text-shadow: none;
|
|
|
|
|
-gtk-icon-shadow: none;
|
|
|
|
|
// white with 0 alpha to avoid an ugly transition, since no color means
|
|
|
|
|
// black with 0 alpha
|
|
|
|
|
@include _shadows(inset 0 1px transparentize(white, 1), $_button_edge);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@else if $t==insensitive-active {
|
|
|
|
|
//
|
|
|
|
|
// insensitive pushed button
|
|
|
|
|
//
|
|
|
|
|
$_bg: if($variant == 'light', darken(mix($c, $base_color, 85%), 8%), darken(mix($c, $base_color, 85%), 6%));
|
|
|
|
|
$_bc: if($c != $bg_color, _border_color($c), $insensitive_borders_color);
|
|
|
|
|
|
|
|
|
|
label, & { color: if($c != $bg_color, mix($tc, $_bg, 60%), $insensitive_fg_color); }
|
|
|
|
|
|
|
|
|
|
border-color: $_bc;
|
|
|
|
|
$button_fill: image($_bg) !global;
|
|
|
|
|
background-image: $button_fill;
|
|
|
|
|
// white with 0 alpha to avoid an ugly transition, since no color means
|
|
|
|
|
// black with 0 alpha
|
|
|
|
|
@include _shadows(inset 0 1px transparentize(white, 1), $_button_edge);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
@else if $t==osd {
|
|
|
|
|
//
|
|
|
|
|
// normal osd button
|
|
|
|
|
//
|
|
|
|
|
$_bg: if($c != $bg_color, transparentize($c, 0.5), $osd_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 19:22:55 +01:00
|
|
|
|
|
|
|
|
color: $osd_fg_color;
|
2019-05-27 16:03:40 +02:00
|
|
|
border-color: $osd_borders_color;
|
|
|
|
|
background-color: transparent;
|
|
|
|
|
$button_fill: image($_bg) !global;
|
|
|
|
|
background-image: $button_fill;
|
|
|
|
|
background-clip: padding-box;
|
|
|
|
|
box-shadow: inset 0 1px transparentize(white, 0.9);
|
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 19:22:55 +01:00
|
|
|
text-shadow: 0 1px black;
|
2019-05-27 16:03:40 +02:00
|
|
|
-gtk-icon-shadow: 0 1px black;
|
|
|
|
|
outline-color: transparentize($osd_fg_color, 0.7);
|
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 19:22:55 +01:00
|
|
|
}
|
|
|
|
|
|
2019-05-27 16:03:40 +02:00
|
|
|
@else if $t==osd-hover {
|
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 19:22:55 +01:00
|
|
|
//
|
|
|
|
|
// active osd button
|
|
|
|
|
//
|
2019-05-27 16:03:40 +02:00
|
|
|
$_bg: if($c != $bg_color, transparentize($c, 0.3), lighten($osd_bg_color, 12%));
|
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 19:22:55 +01:00
|
|
|
|
|
|
|
|
color: white;
|
|
|
|
|
border-color: $osd_borders_color;
|
2019-05-27 16:03:40 +02:00
|
|
|
background-color: transparent;
|
|
|
|
|
$button_fill: image($_bg) !global;
|
|
|
|
|
background-image: $button_fill;
|
|
|
|
|
background-clip: padding-box;
|
|
|
|
|
box-shadow: inset 0 1px transparentize(white, 0.9);
|
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 19:22:55 +01:00
|
|
|
text-shadow: 0 1px black;
|
2019-05-27 16:03:40 +02:00
|
|
|
-gtk-icon-shadow: 0 1px black;
|
|
|
|
|
outline-color: transparentize($osd_fg_color, 0.7);
|
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 19:22:55 +01:00
|
|
|
}
|
2019-05-27 16:03:40 +02:00
|
|
|
|
|
|
|
|
@else if $t==osd-active {
|
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 19:22:55 +01:00
|
|
|
//
|
|
|
|
|
// active osd button
|
|
|
|
|
//
|
2019-05-27 16:03:40 +02:00
|
|
|
$_bg: if($c != $bg_color, $c, $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 19:22:55 +01:00
|
|
|
|
|
|
|
|
color: white;
|
|
|
|
|
border-color: $osd_borders_color;
|
2019-05-27 16:03:40 +02:00
|
|
|
background-color: transparent;
|
|
|
|
|
$button_fill: image($_bg) !global;
|
|
|
|
|
background-image: $button_fill;
|
|
|
|
|
background-clip: padding-box;
|
|
|
|
|
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 19:22:55 +01:00
|
|
|
text-shadow: none;
|
2019-05-27 16:03:40 +02:00
|
|
|
-gtk-icon-shadow: none;
|
|
|
|
|
outline-color: transparentize($osd_fg_color, 0.7);
|
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 19:22:55 +01:00
|
|
|
}
|
2019-05-27 16:03:40 +02:00
|
|
|
|
|
|
|
|
@else if $t==osd-insensitive {
|
theme: Replace gnome-shell-sass submodule with subtree
As the style has grown bigger and more complex, generating the different
variants from a common source has been a good decision. However given how
intertwined the theme is with gnome-shell itself, relying on a submodule
has proven to be quite painful. And as things stand right now, it is going
to get worse:
- using either pre-generated CSS or generating it at build time is
odd, and violates meson's strict separation between source- and
build directories; we are therefore considering dropping the CSS
and depending on sassc to always generate it at build time
- with the migration to gitlab, our workflow shifts decisively towards
branches; however there is no support in either git or gitlab for
handling two brances of separate repositories consecutively, which
gets particularly awkward for branches in a private namespace
With those pain points in mind, we will adjust our setup as follows:
- remove the submodule from gnome-shell and instead import the
sass as subtree
- after that, the sass sources can be changed like any other files
in the repository, and regular contributors can forget that there
was ever anything special about them
- whenever we want to update the classic style, we can push the subtree
changes and bump gnome-shell-extension's sass submodule
In other words: Updating the classic styling will become slightly more
painful, but not much and only for me; in return, everyone else can
stop fiddling with submodules (and buy me a beer).
2018-02-09 19:22:55 +01:00
|
|
|
//
|
|
|
|
|
// insensitive osd button
|
|
|
|
|
//
|
2019-05-27 16:03:40 +02:00
|
|
|
color: $osd_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 19:22:55 +01:00
|
|
|
border-color: $osd_borders_color;
|
2019-05-27 16:03:40 +02:00
|
|
|
background-color: transparent;
|
|
|
|
|
$button_fill: image($osd_insensitive_bg_color) !global;
|
|
|
|
|
background-image: $button_fill;
|
|
|
|
|
background-clip: padding-box;
|
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 19:22:55 +01:00
|
|
|
box-shadow: none;
|
|
|
|
|
text-shadow: none;
|
2019-05-27 16:03:40 +02:00
|
|
|
-gtk-icon-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 19:22:55 +01:00
|
|
|
}
|
2019-05-27 16:03:40 +02:00
|
|
|
|
|
|
|
|
|
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 19:22:55 +01:00
|
|
|
@else if $t==undecorated {
|
|
|
|
|
//
|
|
|
|
|
// reset
|
|
|
|
|
//
|
|
|
|
|
border-color: transparent;
|
|
|
|
|
background-color: transparent;
|
2019-05-27 16:03:40 +02:00
|
|
|
$button_fill: none !global;
|
|
|
|
|
background-image: $button_fill;
|
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 19:22:55 +01:00
|
|
|
|
2019-05-27 16:03:40 +02:00
|
|
|
@include _shadows(inset 0 1px transparentize(white, 1), $_blank_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 19:22:55 +01:00
|
|
|
|
|
|
|
|
text-shadow: none;
|
2019-05-27 16:03:40 +02:00
|
|
|
-gtk-icon-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 19:22:55 +01:00
|
|
|
}
|
|
|
|
|
}
|