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
|
|
|
//This is the RIGHT PLACE to edit the stylesheet
|
|
|
|
|
|
|
|
|
|
//let's start by telling people not to edit the generated CSS:
|
|
|
|
|
$cakeisalie: "This stylesheet is generated, DO NOT EDIT";
|
|
|
|
|
/* #{$cakeisalie} */
|
|
|
|
|
|
|
|
|
|
/* Copyright 2009, 2015 Red Hat, Inc.
|
|
|
|
|
*
|
|
|
|
|
* Portions adapted from Mx's data/style/default.css
|
|
|
|
|
* Copyright 2009 Intel Corporation
|
|
|
|
|
*
|
|
|
|
|
* This program is free software; you can redistribute it and/or modify it
|
|
|
|
|
* under the terms and conditions of the GNU Lesser General Public License,
|
|
|
|
|
* version 2.1, as published by the Free Software Foundation.
|
|
|
|
|
*
|
|
|
|
|
* This program is distributed in the hope it will be useful, but WITHOUT ANY
|
|
|
|
|
* WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
|
|
|
|
|
* FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for
|
|
|
|
|
* more details.
|
|
|
|
|
*
|
|
|
|
|
* You should have received a copy of the GNU Lesser General Public License
|
|
|
|
|
* along with this program; if not, write to the Free Software Foundation,
|
|
|
|
|
* Inc., 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/* GLOBALS */
|
2019-06-18 09:29:00 -04:00
|
|
|
|
2019-07-02 14:29:40 -04:00
|
|
|
|
|
|
|
|
$modal_radius: 9px;
|
|
|
|
|
$button_radius: 5px;
|
|
|
|
|
$panel-corner-radius: $button_radius + 1;
|
2019-06-18 09:29:00 -04:00
|
|
|
|
|
|
|
|
$_trough_color: transparentize($fg_color, 0.9);
|
|
|
|
|
$_bubble_borders_color: lighten($borders_color, if($variant=='light', 0%, 5%));
|
|
|
|
|
$_hover_bg_color: lighten($bg_color,if($variant=='light', 5%, 3%));
|
|
|
|
|
$_active_bg_color: if($variant == 'light', darken($bg_color, 14%), darken($bg_color, 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 13:22:55 -05:00
|
|
|
$font-size: 11;
|
|
|
|
|
$font-family: Cantarell, Sans-Serif;
|
|
|
|
|
|
|
|
|
|
stage {
|
|
|
|
|
font-family: $font-family;
|
|
|
|
|
@include fontsize($font-size);
|
|
|
|
|
color: $fg_color;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* WIDGETS */
|
|
|
|
|
|
|
|
|
|
/* Buttons */
|
2019-06-18 09:29:00 -04:00
|
|
|
.button, %button {
|
2019-07-02 14:29:40 -04:00
|
|
|
border-radius: $button_radius;
|
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
|
|
|
border-width: 1px;
|
2019-06-18 09:29:00 -04:00
|
|
|
min-height: 22px;
|
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
|
|
|
padding: 4px 32px;
|
|
|
|
|
@include button(normal);
|
2019-06-18 09:29:00 -04:00
|
|
|
&:focus { @include button(focus, $c:$_hover_bg_color, $tc:$fg_color); }
|
|
|
|
|
&:hover { @include button(hover, $c:$_hover_bg_color, $tc:$fg_color); }
|
theme: Replace gnome-shell-sass submodule with subtree
As the style has grown bigger and more complex, generating the different
variants from a common source has been a good decision. However given how
intertwined the theme is with gnome-shell itself, relying on a submodule
has proven to be quite painful. And as things stand right now, it is going
to get worse:
- using either pre-generated CSS or generating it at build time is
odd, and violates meson's strict separation between source- and
build directories; we are therefore considering dropping the CSS
and depending on sassc to always generate it at build time
- with the migration to gitlab, our workflow shifts decisively towards
branches; however there is no support in either git or gitlab for
handling two brances of separate repositories consecutively, which
gets particularly awkward for branches in a private namespace
With those pain points in mind, we will adjust our setup as follows:
- remove the submodule from gnome-shell and instead import the
sass as subtree
- after that, the sass sources can be changed like any other files
in the repository, and regular contributors can forget that there
was ever anything special about them
- whenever we want to update the classic style, we can push the subtree
changes and bump gnome-shell-extension's sass submodule
In other words: Updating the classic styling will become slightly more
painful, but not much and only for me; in return, everyone else can
stop fiddling with submodules (and buy me a beer).
2018-02-09 13:22:55 -05:00
|
|
|
&:insensitive { @include button(insensitive); }
|
2019-06-18 09:29:00 -04:00
|
|
|
&:active { @include button(active, $c:$_active_bg_color, $tc:$fg_color); }
|
theme: Replace gnome-shell-sass submodule with subtree
As the style has grown bigger and more complex, generating the different
variants from a common source has been a good decision. However given how
intertwined the theme is with gnome-shell itself, relying on a submodule
has proven to be quite painful. And as things stand right now, it is going
to get worse:
- using either pre-generated CSS or generating it at build time is
odd, and violates meson's strict separation between source- and
build directories; we are therefore considering dropping the CSS
and depending on sassc to always generate it at build time
- with the migration to gitlab, our workflow shifts decisively towards
branches; however there is no support in either git or gitlab for
handling two brances of separate repositories consecutively, which
gets particularly awkward for branches in a private namespace
With those pain points in mind, we will adjust our setup as follows:
- remove the submodule from gnome-shell and instead import the
sass as subtree
- after that, the sass sources can be changed like any other files
in the repository, and regular contributors can forget that there
was ever anything special about them
- whenever we want to update the classic style, we can push the subtree
changes and bump gnome-shell-extension's sass submodule
In other words: Updating the classic styling will become slightly more
painful, but not much and only for me; in return, everyone else can
stop fiddling with submodules (and buy me a beer).
2018-02-09 13:22:55 -05:00
|
|
|
}
|
|
|
|
|
|
2019-06-18 09:29:00 -04:00
|
|
|
.modal-dialog-linked-button, %bubble_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 13:22:55 -05:00
|
|
|
border-right-width: 1px;
|
2019-06-18 09:29:00 -04:00
|
|
|
@include button(normal, $c:$bg_color, $tc:$fg_color);
|
|
|
|
|
&:insensitive { @include button(insensitive, $c:$bg_color, $tc:$fg_color); }
|
|
|
|
|
&:hover { @include button(hover, $c:$_hover_bg_color, $tc:$fg_color); }
|
|
|
|
|
&:focus { @include button(focus, $c:$_hover_bg_color, $tc:$fg_color); }
|
|
|
|
|
&:active { @include button(active, $c:$_active_bg_color, $tc:$fg_color); }
|
theme: Replace gnome-shell-sass submodule with subtree
As the style has grown bigger and more complex, generating the different
variants from a common source has been a good decision. However given how
intertwined the theme is with gnome-shell itself, relying on a submodule
has proven to be quite painful. And as things stand right now, it is going
to get worse:
- using either pre-generated CSS or generating it at build time is
odd, and violates meson's strict separation between source- and
build directories; we are therefore considering dropping the CSS
and depending on sassc to always generate it at build time
- with the migration to gitlab, our workflow shifts decisively towards
branches; however there is no support in either git or gitlab for
handling two brances of separate repositories consecutively, which
gets particularly awkward for branches in a private namespace
With those pain points in mind, we will adjust our setup as follows:
- remove the submodule from gnome-shell and instead import the
sass as subtree
- after that, the sass sources can be changed like any other files
in the repository, and regular contributors can forget that there
was ever anything special about them
- whenever we want to update the classic style, we can push the subtree
changes and bump gnome-shell-extension's sass submodule
In other words: Updating the classic styling will become slightly more
painful, but not much and only for me; in return, everyone else can
stop fiddling with submodules (and buy me a beer).
2018-02-09 13:22:55 -05:00
|
|
|
padding: 12px;
|
2019-06-18 09:29:00 -04:00
|
|
|
border-top: 1px solid $_bubble_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 13:22:55 -05:00
|
|
|
|
|
|
|
|
&:first-child {
|
2019-07-02 14:29:40 -04:00
|
|
|
border-radius: 0px 0px 0px $modal_radius;
|
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
|
|
|
}
|
|
|
|
|
&:last-child {
|
|
|
|
|
border-right-width: 0px;
|
2019-07-02 14:29:40 -04:00
|
|
|
border-radius: 0px 0px $modal_radius 0px;
|
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
|
|
|
}
|
|
|
|
|
&:first-child:last-child {
|
|
|
|
|
border-right-width: 0px;
|
2019-07-02 14:29:40 -04:00
|
|
|
border-radius: 0px 0px $modal_radius $modal_radius;
|
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 */
|
|
|
|
|
StEntry {
|
2019-07-02 14:29:40 -04:00
|
|
|
border-radius: $button_radius;
|
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
|
|
|
padding: 4px;
|
|
|
|
|
border-width: 1px;
|
|
|
|
|
color: $fg_color;
|
|
|
|
|
@include entry(normal);
|
|
|
|
|
//&:hover { @include entry(hover);}
|
|
|
|
|
&:focus { @include entry(focus,$fc:transparentize($fg_color,0.5));}
|
|
|
|
|
&:insensitive { @include entry(insensitive);}
|
|
|
|
|
selection-background-color: $selected_bg_color;
|
|
|
|
|
selected-color: $selected_fg_color;
|
|
|
|
|
StIcon.capslock-warning {
|
|
|
|
|
icon-size: 16px;
|
|
|
|
|
warning-color: $warning_color;
|
|
|
|
|
padding: 0 4px;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/* Scrollbars */
|
|
|
|
|
|
|
|
|
|
StScrollView {
|
|
|
|
|
&.vfade { -st-vfade-offset: 68px; }
|
|
|
|
|
&.hfade { -st-hfade-offset: 68px; }
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
StScrollBar {
|
|
|
|
|
padding: 0;
|
|
|
|
|
|
|
|
|
|
StScrollView & {
|
|
|
|
|
min-width: 14px;
|
|
|
|
|
min-height: 14px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
StBin#trough {
|
|
|
|
|
border-radius: 0;
|
|
|
|
|
background-color: transparent;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
StButton#vhandle, StButton#hhandle {
|
|
|
|
|
border-radius: 8px;
|
|
|
|
|
background-color: mix($fg_color, $bg_color, 60%);
|
|
|
|
|
//border: 3px solid transparent; //would be nice to margin or at least to transparent
|
|
|
|
|
margin: 3px;
|
|
|
|
|
&:hover { background-color: mix($fg_color, $bg_color, 80%); }
|
|
|
|
|
&:active { background-color: $selected_bg_color; }
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Slider */
|
|
|
|
|
|
|
|
|
|
.slider {
|
|
|
|
|
height: 1em;
|
2018-02-08 13:04:42 -05:00
|
|
|
-barlevel-height: 0.3em;
|
2019-06-18 09:29:00 -04:00
|
|
|
-barlevel-background-color: transparentize($fg_color, 0.9); //background of the trough
|
2018-02-08 13:04:42 -05:00
|
|
|
-barlevel-border-color: $borders_color; //trough border color
|
|
|
|
|
-barlevel-active-background-color: $selected_bg_color; //active trough fill
|
2019-06-18 09:29:00 -04:00
|
|
|
-barlevel-active-border-color: $selected_borders_color; //active trough border
|
2018-07-31 09:49:06 -04:00
|
|
|
-barlevel-overdrive-color: $destructive_color;
|
|
|
|
|
-barlevel-overdrive-border-color: darken($destructive_color,10%);
|
|
|
|
|
-barlevel-overdrive-separator-width: 0.2em;
|
2018-02-08 13:04:42 -05:00
|
|
|
-barlevel-border-width: 1px;
|
2019-06-18 09:29:00 -04:00
|
|
|
-slider-handle-radius: 8px;
|
|
|
|
|
-slider-handle-border-width: 1px;
|
|
|
|
|
-slider-handle-border-color: $borders_color;
|
2019-06-26 06:34:42 -04:00
|
|
|
color: if($variant == 'light', lighten($bg_color, 10%), darken($bg_color,4%));
|
2019-06-18 09:29:00 -04:00
|
|
|
&:hover { color: $_hover_bg_color; }
|
|
|
|
|
&:active { color: $_active_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
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Check Boxes */
|
|
|
|
|
|
|
|
|
|
.check-box {
|
|
|
|
|
StBoxLayout { spacing: .8em; }
|
|
|
|
|
StBin {
|
|
|
|
|
width: 24px;
|
|
|
|
|
height: 22px;
|
|
|
|
|
background-image: url("resource:///org/gnome/shell/theme/checkbox-off.svg");
|
|
|
|
|
}
|
|
|
|
|
&:focus StBin { background-image: url("resource:///org/gnome/shell/theme/checkbox-off-focused.svg"); }
|
|
|
|
|
&:checked StBin { background-image: url("resource:///org/gnome/shell/theme/checkbox.svg"); }
|
|
|
|
|
&:focus:checked StBin { background-image: url("resource:///org/gnome/shell/theme/checkbox-focused.svg"); }
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Switches */
|
|
|
|
|
.toggle-switch {
|
2019-06-18 09:29:00 -04:00
|
|
|
color: $fg_color;
|
2019-04-16 10:05:10 -04:00
|
|
|
width: 46px;
|
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
|
|
|
height: 22px;
|
|
|
|
|
background-size: contain;
|
2019-06-18 09:29:00 -04:00
|
|
|
background-image: if($variant == 'light', url("resource:///org/gnome/shell/theme/toggle-off.svg"),
|
|
|
|
|
url("resource:///org/gnome/shell/theme/toggle-off-dark.svg"));
|
|
|
|
|
&:checked {
|
|
|
|
|
background-image: if($variant == 'light', url("resource:///org/gnome/shell/theme/toggle-on.svg"),
|
|
|
|
|
url("resource:///org/gnome/shell/theme/toggle-on-dark.svg"));
|
|
|
|
|
}
|
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
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* links */
|
|
|
|
|
.shell-link {
|
|
|
|
|
color: $link_color;
|
|
|
|
|
&:hover { color: lighten($link_color,10%); }
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Modal Dialogs */
|
|
|
|
|
|
|
|
|
|
.headline { font-size: 110%; }
|
|
|
|
|
.lightbox { background-color: black; }
|
|
|
|
|
.flashspot { background-color: white; }
|
|
|
|
|
|
|
|
|
|
.modal-dialog {
|
2019-07-02 14:29:40 -04:00
|
|
|
border-radius: $modal_radius;
|
2019-06-18 09:29:00 -04:00
|
|
|
@extend %bubble-panel;
|
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
|
|
|
.modal-dialog-content-box {
|
|
|
|
|
padding: 24px;
|
|
|
|
|
}
|
|
|
|
|
.run-dialog-entry { width: 20em; margin-bottom: 6px; }
|
|
|
|
|
.run-dialog-error-box {
|
|
|
|
|
padding-top: 16px;
|
|
|
|
|
spacing: 6px;
|
|
|
|
|
}
|
|
|
|
|
.run-dialog-button-box { padding-top: 1em; }
|
|
|
|
|
.run-dialog-label {
|
|
|
|
|
@include fontsize($font-size + 1.1);
|
2019-06-18 09:29:00 -04:00
|
|
|
font-weight: normal;
|
|
|
|
|
color: $fg_color;
|
theme: Replace gnome-shell-sass submodule with subtree
As the style has grown bigger and more complex, generating the different
variants from a common source has been a good decision. However given how
intertwined the theme is with gnome-shell itself, relying on a submodule
has proven to be quite painful. And as things stand right now, it is going
to get worse:
- using either pre-generated CSS or generating it at build time is
odd, and violates meson's strict separation between source- and
build directories; we are therefore considering dropping the CSS
and depending on sassc to always generate it at build time
- with the migration to gitlab, our workflow shifts decisively towards
branches; however there is no support in either git or gitlab for
handling two brances of separate repositories consecutively, which
gets particularly awkward for branches in a private namespace
With those pain points in mind, we will adjust our setup as follows:
- remove the submodule from gnome-shell and instead import the
sass as subtree
- after that, the sass sources can be changed like any other files
in the repository, and regular contributors can forget that there
was ever anything special about them
- whenever we want to update the classic style, we can push the subtree
changes and bump gnome-shell-extension's sass submodule
In other words: Updating the classic styling will become slightly more
painful, but not much and only for me; in return, everyone else can
stop fiddling with submodules (and buy me a beer).
2018-02-09 13:22:55 -05:00
|
|
|
padding-bottom: .4em;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.mount-dialog-subject,
|
|
|
|
|
.end-session-dialog-subject { //this should be a generic header class
|
|
|
|
|
@include fontsize($font-size * 1.3);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Message Dialog */
|
|
|
|
|
.message-dialog-main-layout {
|
|
|
|
|
padding: 12px 20px 0;
|
|
|
|
|
spacing: 12px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.message-dialog-content {
|
|
|
|
|
max-width: 28em;
|
|
|
|
|
spacing: 20px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.message-dialog-icon {
|
|
|
|
|
min-width: 48px;
|
|
|
|
|
icon-size: 48px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.message-dialog-title {
|
|
|
|
|
font-weight: bold;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.message-dialog-subtitle {
|
2019-06-18 09:29:00 -04:00
|
|
|
color: $fg_color;
|
theme: Replace gnome-shell-sass submodule with subtree
As the style has grown bigger and more complex, generating the different
variants from a common source has been a good decision. However given how
intertwined the theme is with gnome-shell itself, relying on a submodule
has proven to be quite painful. And as things stand right now, it is going
to get worse:
- using either pre-generated CSS or generating it at build time is
odd, and violates meson's strict separation between source- and
build directories; we are therefore considering dropping the CSS
and depending on sassc to always generate it at build time
- with the migration to gitlab, our workflow shifts decisively towards
branches; however there is no support in either git or gitlab for
handling two brances of separate repositories consecutively, which
gets particularly awkward for branches in a private namespace
With those pain points in mind, we will adjust our setup as follows:
- remove the submodule from gnome-shell and instead import the
sass as subtree
- after that, the sass sources can be changed like any other files
in the repository, and regular contributors can forget that there
was ever anything special about them
- whenever we want to update the classic style, we can push the subtree
changes and bump gnome-shell-extension's sass submodule
In other words: Updating the classic styling will become slightly more
painful, but not much and only for me; in return, everyone else can
stop fiddling with submodules (and buy me a beer).
2018-02-09 13:22:55 -05:00
|
|
|
font-weight: bold;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* End Session Dialog */
|
|
|
|
|
.end-session-dialog {
|
|
|
|
|
spacing: 42px;
|
|
|
|
|
border: 1px solid $_bubble_borders_color;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.end-session-dialog-list {
|
|
|
|
|
padding-top: 20px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.end-session-dialog-layout {
|
|
|
|
|
padding-left: 17px;
|
|
|
|
|
&:rtl { padding-right: 17px; }
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.end-session-dialog-description {
|
|
|
|
|
width: 28em;
|
|
|
|
|
padding-bottom: 10px;
|
|
|
|
|
&:rtl {
|
|
|
|
|
text-align: right;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.end-session-dialog-warning {
|
|
|
|
|
width: 28em;
|
|
|
|
|
color: $warning_color;
|
|
|
|
|
padding-top: 6px;
|
|
|
|
|
&:rtl {
|
|
|
|
|
text-align: right;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.end-session-dialog-logout-icon {
|
2019-02-05 11:28:41 -05:00
|
|
|
border-radius: 99px;
|
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
|
|
|
width: 48px;
|
|
|
|
|
height: 48px;
|
|
|
|
|
background-size: contain;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.end-session-dialog-shutdown-icon {
|
|
|
|
|
color: $fg_color;
|
|
|
|
|
width: 48px;
|
|
|
|
|
height: 48px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.end-session-dialog-inhibitor-layout {
|
|
|
|
|
spacing: 16px;
|
|
|
|
|
max-height: 200px;
|
|
|
|
|
padding-right: 65px;
|
|
|
|
|
padding-left: 65px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.end-session-dialog-session-list,
|
|
|
|
|
.end-session-dialog-app-list {
|
|
|
|
|
spacing: 1em;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.end-session-dialog-list-header {
|
|
|
|
|
font-weight: bold;
|
|
|
|
|
&:rtl { text-align: right; }
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.end-session-dialog-app-list-item,
|
|
|
|
|
.end-session-dialog-session-list-item {
|
|
|
|
|
spacing: 1em;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.end-session-dialog-app-list-item-name,
|
|
|
|
|
.end-session-dialog-session-list-item-name {
|
|
|
|
|
font-weight: bold;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.end-session-dialog-app-list-item-description {
|
|
|
|
|
color: darken($fg_color,5%);
|
|
|
|
|
font-size: 10pt;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* ShellMountOperation Dialogs */
|
|
|
|
|
.shell-mount-operation-icon { icon-size: 48px; }
|
|
|
|
|
|
|
|
|
|
.mount-dialog {
|
|
|
|
|
spacing: 24px;
|
|
|
|
|
|
|
|
|
|
.message-dialog-title {
|
|
|
|
|
padding-top: 10px;
|
|
|
|
|
padding-left: 17px;
|
|
|
|
|
padding-bottom: 6px;
|
|
|
|
|
max-width: 34em;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.message-dialog-title:rtl {
|
|
|
|
|
padding-left: 0px;
|
|
|
|
|
padding-right: 17px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.message-dialog-body {
|
|
|
|
|
padding-left: 17px;
|
|
|
|
|
width: 28em;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.message-dialog-body:rtl {
|
|
|
|
|
padding-left: 0px;
|
|
|
|
|
padding-right: 17px;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.mount-dialog-app-list {
|
|
|
|
|
max-height: 200px;
|
|
|
|
|
padding-top: 24px;
|
|
|
|
|
padding-left: 49px;
|
|
|
|
|
padding-right: 32px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.mount-dialog-app-list:rtl {
|
|
|
|
|
padding-right: 49px;
|
|
|
|
|
padding-left: 32px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.mount-dialog-app-list-item {
|
2019-06-18 09:29:00 -04:00
|
|
|
color: lighten($fg_color,10%);
|
theme: Replace gnome-shell-sass submodule with subtree
As the style has grown bigger and more complex, generating the different
variants from a common source has been a good decision. However given how
intertwined the theme is with gnome-shell itself, relying on a submodule
has proven to be quite painful. And as things stand right now, it is going
to get worse:
- using either pre-generated CSS or generating it at build time is
odd, and violates meson's strict separation between source- and
build directories; we are therefore considering dropping the CSS
and depending on sassc to always generate it at build time
- with the migration to gitlab, our workflow shifts decisively towards
branches; however there is no support in either git or gitlab for
handling two brances of separate repositories consecutively, which
gets particularly awkward for branches in a private namespace
With those pain points in mind, we will adjust our setup as follows:
- remove the submodule from gnome-shell and instead import the
sass as subtree
- after that, the sass sources can be changed like any other files
in the repository, and regular contributors can forget that there
was ever anything special about them
- whenever we want to update the classic style, we can push the subtree
changes and bump gnome-shell-extension's sass submodule
In other words: Updating the classic styling will become slightly more
painful, but not much and only for me; in return, everyone else can
stop fiddling with submodules (and buy me a beer).
2018-02-09 13:22:55 -05:00
|
|
|
&:hover { color: $fg_color; }
|
|
|
|
|
&:ltr { padding-right: 1em; }
|
|
|
|
|
&:rtl { padding-left: 1em; }
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.mount-dialog-app-list-item-icon {
|
|
|
|
|
&:ltr { padding-right: 17px; }
|
|
|
|
|
&:rtl { padding-left: 17px; }
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.mount-dialog-app-list-item-name {
|
|
|
|
|
font-size: 10pt;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/* Password or Authentication Dialog */
|
|
|
|
|
|
|
|
|
|
.prompt-dialog {
|
2019-06-18 09:29:00 -04:00
|
|
|
@extend %bubble-panel;
|
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
|
|
|
//this is the width of the entire modal popup
|
|
|
|
|
width: 34em;
|
|
|
|
|
|
|
|
|
|
.message-dialog-main-layout { spacing: 24px; padding: 10px; }
|
|
|
|
|
.message-dialog-content { spacing: 16px; }
|
2019-06-18 09:29:00 -04:00
|
|
|
.message-dialog-title { color: lighten($fg_color,15%); }
|
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
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.prompt-dialog-description:rtl {
|
|
|
|
|
text-align: right;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.prompt-dialog-password-box {
|
|
|
|
|
spacing: 1em;
|
2019-06-18 09:29:00 -04:00
|
|
|
padding-bottom: 1em;
|
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
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.prompt-dialog-error-label {
|
|
|
|
|
font-size: 10pt;
|
2019-03-01 09:34:41 -05:00
|
|
|
color: $warning_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
|
|
|
padding-bottom: 8px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.prompt-dialog-info-label {
|
|
|
|
|
font-size: 10pt;
|
|
|
|
|
padding-bottom: 8px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.hidden {
|
|
|
|
|
color: rgba(0,0,0,0);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.prompt-dialog-null-label {
|
|
|
|
|
font-size: 10pt;
|
|
|
|
|
padding-bottom: 8px;
|
|
|
|
|
}
|
|
|
|
|
|
2019-04-07 17:35:07 -04:00
|
|
|
.prompt-dialog-pim-box {
|
|
|
|
|
spacing: 1em;
|
|
|
|
|
}
|
|
|
|
|
|
2019-04-07 17:33:34 -04:00
|
|
|
.prompt-dialog-grid {
|
|
|
|
|
spacing-rows: 15px;
|
|
|
|
|
spacing-columns: 1em;
|
|
|
|
|
}
|
|
|
|
|
|
2019-04-07 17:35:07 -04:00
|
|
|
.prompt-dialog-keyfiles-box {
|
|
|
|
|
spacing: 1em;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.prompt-dialog-button.button {
|
|
|
|
|
padding: 8px;
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
/* Polkit Dialog */
|
|
|
|
|
|
|
|
|
|
.polkit-dialog-user-layout {
|
|
|
|
|
padding-left: 10px;
|
|
|
|
|
spacing: 10px;
|
|
|
|
|
&:rtl {
|
|
|
|
|
padding-left: 0px;
|
|
|
|
|
padding-right: 10px;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.polkit-dialog-user-root-label {
|
|
|
|
|
color: $warning_color;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.polkit-dialog-user-icon {
|
2019-02-05 11:28:41 -05:00
|
|
|
border-radius: 99px;
|
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
|
|
|
background-size: contain;
|
|
|
|
|
width: 48px;
|
|
|
|
|
height: 48px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Audio selection dialog */
|
|
|
|
|
.audio-device-selection-dialog {
|
2019-06-18 09:29:00 -04:00
|
|
|
@extend %bubble-panel;
|
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
|
|
|
spacing: 30px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.audio-selection-content {
|
|
|
|
|
spacing: 20px;
|
|
|
|
|
padding: 24px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.audio-selection-title {
|
|
|
|
|
font-weight: bold;
|
|
|
|
|
text-align: center;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.audio-selection-box {
|
|
|
|
|
spacing: 20px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.audio-selection-device {
|
|
|
|
|
border: 1px solid $_bubble_borders_color;
|
|
|
|
|
border-radius: 12px;
|
2019-06-18 09:29:00 -04:00
|
|
|
&:hover,&:focus { background-color: $_hover_bg_color; }
|
|
|
|
|
&:active {
|
|
|
|
|
background-color: $selected_bg_color;
|
|
|
|
|
color: $selected_fg_color;
|
|
|
|
|
}
|
theme: Replace gnome-shell-sass submodule with subtree
As the style has grown bigger and more complex, generating the different
variants from a common source has been a good decision. However given how
intertwined the theme is with gnome-shell itself, relying on a submodule
has proven to be quite painful. And as things stand right now, it is going
to get worse:
- using either pre-generated CSS or generating it at build time is
odd, and violates meson's strict separation between source- and
build directories; we are therefore considering dropping the CSS
and depending on sassc to always generate it at build time
- with the migration to gitlab, our workflow shifts decisively towards
branches; however there is no support in either git or gitlab for
handling two brances of separate repositories consecutively, which
gets particularly awkward for branches in a private namespace
With those pain points in mind, we will adjust our setup as follows:
- remove the submodule from gnome-shell and instead import the
sass as subtree
- after that, the sass sources can be changed like any other files
in the repository, and regular contributors can forget that there
was ever anything special about them
- whenever we want to update the classic style, we can push the subtree
changes and bump gnome-shell-extension's sass submodule
In other words: Updating the classic styling will become slightly more
painful, but not much and only for me; in return, everyone else can
stop fiddling with submodules (and buy me a beer).
2018-02-09 13:22:55 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.audio-selection-device-box {
|
|
|
|
|
padding: 20px;
|
|
|
|
|
spacing: 20px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.audio-selection-device-icon {
|
|
|
|
|
icon-size: 64px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Access Dialog */
|
|
|
|
|
.access-dialog {
|
2019-06-18 09:29:00 -04:00
|
|
|
@extend %bubble-panel;
|
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
|
|
|
spacing: 30px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Geolocation Dialog */
|
|
|
|
|
.geolocation-dialog {
|
2019-06-18 09:29:00 -04:00
|
|
|
@extend %bubble-panel;
|
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
|
|
|
spacing: 30px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Extension Dialog */
|
|
|
|
|
.extension-dialog {
|
2019-06-18 09:29:00 -04:00
|
|
|
@extend %bubble-panel;
|
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
|
|
|
.message-dialog-main-layout { spacing: 24px; padding: 10px; }
|
2019-06-18 09:29:00 -04:00
|
|
|
.message-dialog-title { font-weight: normal; color: $fg_color; }
|
theme: Replace gnome-shell-sass submodule with subtree
As the style has grown bigger and more complex, generating the different
variants from a common source has been a good decision. However given how
intertwined the theme is with gnome-shell itself, relying on a submodule
has proven to be quite painful. And as things stand right now, it is going
to get worse:
- using either pre-generated CSS or generating it at build time is
odd, and violates meson's strict separation between source- and
build directories; we are therefore considering dropping the CSS
and depending on sassc to always generate it at build time
- with the migration to gitlab, our workflow shifts decisively towards
branches; however there is no support in either git or gitlab for
handling two brances of separate repositories consecutively, which
gets particularly awkward for branches in a private namespace
With those pain points in mind, we will adjust our setup as follows:
- remove the submodule from gnome-shell and instead import the
sass as subtree
- after that, the sass sources can be changed like any other files
in the repository, and regular contributors can forget that there
was ever anything special about them
- whenever we want to update the classic style, we can push the subtree
changes and bump gnome-shell-extension's sass submodule
In other words: Updating the classic styling will become slightly more
painful, but not much and only for me; in return, everyone else can
stop fiddling with submodules (and buy me a beer).
2018-02-09 13:22:55 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Inhibit-Shortcuts Dialog */
|
|
|
|
|
.inhibit-shortcuts-dialog {
|
2019-06-18 09:29:00 -04:00
|
|
|
@extend %bubble-panel;
|
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
|
|
|
spacing: 30px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Network Agent Dialog */
|
|
|
|
|
|
|
|
|
|
.network-dialog-secret-table {
|
|
|
|
|
spacing-rows: 15px;
|
|
|
|
|
spacing-columns: 1em;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.keyring-dialog-control-table {
|
|
|
|
|
spacing-rows: 15px;
|
|
|
|
|
spacing-columns: 1em;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Popovers/Menus */
|
|
|
|
|
|
|
|
|
|
.popup-menu {
|
|
|
|
|
min-width: 15em;
|
2019-06-18 09:29:00 -04:00
|
|
|
color: $fg_color;
|
|
|
|
|
border-color: $_bubble_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 13:22:55 -05:00
|
|
|
|
|
|
|
|
.popup-menu-arrow { } //defined globally in the TOP BAR
|
|
|
|
|
.popup-sub-menu {
|
2019-06-18 09:29:00 -04:00
|
|
|
background-color: darken($bg_color,5%);
|
|
|
|
|
box-shadow: inset 0 -1px 0px $_bubble_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 13:22:55 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.popup-menu-content { padding: 1em 0em; }
|
|
|
|
|
.popup-menu-item {
|
|
|
|
|
spacing: 12px;
|
|
|
|
|
|
|
|
|
|
&:ltr { padding: .4em 1.75em .4em 0em; }
|
|
|
|
|
&:rtl { padding: .4em 0em .4em 1.75em; }
|
|
|
|
|
&:checked {
|
2019-06-18 09:29:00 -04:00
|
|
|
background-color: $bg_color;
|
|
|
|
|
box-shadow: inset 0 -1px 0px $_bubble_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 13:22:55 -05:00
|
|
|
font-weight: bold;
|
|
|
|
|
}
|
2019-06-18 09:29:00 -04:00
|
|
|
&.selected {
|
|
|
|
|
background-color: transparentize(white, if($variant=='light', 0.2, 0.9));
|
|
|
|
|
color: $fg_color;
|
|
|
|
|
}
|
|
|
|
|
&:active {
|
|
|
|
|
background-color: $selected_bg_color;
|
|
|
|
|
color: $selected_fg_color;
|
|
|
|
|
}
|
theme: Replace gnome-shell-sass submodule with subtree
As the style has grown bigger and more complex, generating the different
variants from a common source has been a good decision. However given how
intertwined the theme is with gnome-shell itself, relying on a submodule
has proven to be quite painful. And as things stand right now, it is going
to get worse:
- using either pre-generated CSS or generating it at build time is
odd, and violates meson's strict separation between source- and
build directories; we are therefore considering dropping the CSS
and depending on sassc to always generate it at build time
- with the migration to gitlab, our workflow shifts decisively towards
branches; however there is no support in either git or gitlab for
handling two brances of separate repositories consecutively, which
gets particularly awkward for branches in a private namespace
With those pain points in mind, we will adjust our setup as follows:
- remove the submodule from gnome-shell and instead import the
sass as subtree
- after that, the sass sources can be changed like any other files
in the repository, and regular contributors can forget that there
was ever anything special about them
- whenever we want to update the classic style, we can push the subtree
changes and bump gnome-shell-extension's sass submodule
In other words: Updating the classic styling will become slightly more
painful, but not much and only for me; in return, everyone else can
stop fiddling with submodules (and buy me a beer).
2018-02-09 13:22:55 -05:00
|
|
|
&:insensitive { color: transparentize($fg_color,.5); }
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.popup-inactive-menu-item { //all icons and other graphical elements
|
|
|
|
|
color: $fg_color;
|
|
|
|
|
|
|
|
|
|
&:insensitive { color: transparentize($fg_color,0.5); }
|
|
|
|
|
}
|
|
|
|
|
//.popup-status-menu-item { font-weight: normal; color: pink; } //dunno what that is
|
|
|
|
|
&.panel-menu {
|
|
|
|
|
-boxpointer-gap: 4px;
|
|
|
|
|
margin-bottom: 1.75em;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
.popup-menu-ornament {
|
|
|
|
|
text-align: right;
|
|
|
|
|
width: 1.2em;
|
|
|
|
|
}
|
|
|
|
|
.popup-menu-boxpointer,
|
|
|
|
|
.candidate-popup-boxpointer {
|
2019-07-02 14:29:40 -04:00
|
|
|
-arrow-border-radius: $button_radius+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
|
|
|
-arrow-background-color: $bg_color;
|
|
|
|
|
-arrow-border-width: 1px;
|
2019-06-18 09:29:00 -04:00
|
|
|
-arrow-border-color: if($variant=='light', transparentize(black, 0.6), $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 13:22:55 -05:00
|
|
|
-arrow-base: 24px;
|
|
|
|
|
-arrow-rise: 11px;
|
|
|
|
|
-arrow-box-shadow: 0 1px 3px black; //dreaming. bug #689995
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.popup-separator-menu-item {
|
|
|
|
|
//-margin-horizontal: 24px;
|
|
|
|
|
height: 1px; //not really the whole box
|
|
|
|
|
margin: 6px 64px;
|
|
|
|
|
background-color: transparent;
|
2019-06-18 09:29:00 -04:00
|
|
|
border-color: $_bubble_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 13:22:55 -05:00
|
|
|
border-bottom-width: 1px;
|
|
|
|
|
border-bottom-style: solid;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
// Background menu
|
|
|
|
|
.background-menu { -boxpointer-gap: 4px; -arrow-rise: 0px; }
|
|
|
|
|
|
|
|
|
|
/* fallback menu
|
|
|
|
|
- odd thing for styling App menu when apparently not running under shell. Light Adwaita styled
|
|
|
|
|
app menu inside the main app window itself rather than the top bar
|
|
|
|
|
*/
|
|
|
|
|
|
2019-07-15 18:04:48 -04:00
|
|
|
/*************
|
|
|
|
|
* App Icons *
|
|
|
|
|
*************/
|
|
|
|
|
/* Outline for low res icons */
|
|
|
|
|
.lowres-icon {
|
2019-07-17 23:03:08 -04:00
|
|
|
icon-shadow: 0 1px 2px rgba(0,0,0,0.3);
|
2019-07-15 18:04:48 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Drapshadow for large icons */
|
|
|
|
|
.icon-dropshadow {
|
2019-07-17 23:03:08 -04:00
|
|
|
icon-shadow: 0 1px 2px rgba(0,0,0,0.4);
|
2019-07-15 18:04:48 -04: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 13:22:55 -05:00
|
|
|
|
|
|
|
|
/* OSD */
|
|
|
|
|
.osd-window {
|
|
|
|
|
text-align: center;
|
|
|
|
|
font-weight: bold;
|
|
|
|
|
spacing: 1em;
|
|
|
|
|
margin: 32px;
|
|
|
|
|
min-width: 64px;
|
|
|
|
|
min-height: 64px;
|
|
|
|
|
|
|
|
|
|
.osd-monitor-label { font-size: 3em; }
|
|
|
|
|
.level {
|
|
|
|
|
height: 0.6em;
|
2018-02-08 13:22:29 -05:00
|
|
|
-barlevel-height: 0.6em;
|
2019-06-18 09:29:00 -04:00
|
|
|
-barlevel-background-color: transparentize($fg_color, if($variant=='light', 0.2, 0.9));
|
2018-02-08 13:22:29 -05:00
|
|
|
-barlevel-active-background-color: $osd_fg_color;
|
2018-07-31 09:49:06 -04:00
|
|
|
-barlevel-overdrive-color: $destructive_color;
|
|
|
|
|
-barlevel-overdrive-separator-width: 0.2em;
|
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
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Pad OSD */
|
|
|
|
|
.pad-osd-window {
|
|
|
|
|
padding: 32px;
|
|
|
|
|
background-color: transparentize(black, 0.2);
|
|
|
|
|
|
|
|
|
|
.pad-osd-title-box { spacing: 12px; }
|
|
|
|
|
.pad-osd-title-menu-box { spacing: 6px; }
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.combo-box-label {
|
|
|
|
|
width: 15em;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* App Switcher */
|
|
|
|
|
.switcher-popup {
|
|
|
|
|
padding: 8px;
|
|
|
|
|
spacing: 16px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.osd-window,
|
|
|
|
|
.resize-popup,
|
|
|
|
|
.switcher-list {
|
|
|
|
|
@extend %osd-panel;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.switcher-list-item-container { spacing: 8px; }
|
|
|
|
|
|
|
|
|
|
.switcher-list .item-box {
|
|
|
|
|
padding: 8px;
|
|
|
|
|
border-radius: 4px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.switcher-list .item-box:outlined {
|
|
|
|
|
padding: 6px;
|
|
|
|
|
border: 2px solid darken($borders_color,10%);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.switcher-list .item-box:selected {
|
2019-06-18 09:29:00 -04:00
|
|
|
background-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 13:22:55 -05:00
|
|
|
color: $selected_fg_color;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.switcher-list .thumbnail-box {
|
|
|
|
|
padding: 2px;
|
|
|
|
|
spacing: 4px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.switcher-list .thumbnail {
|
|
|
|
|
width: 256px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.switcher-list .separator {
|
|
|
|
|
width: 1px;
|
|
|
|
|
background: $borders_color;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.switcher-arrow {
|
|
|
|
|
border-color: rgba(0,0,0,0);
|
|
|
|
|
color: transparentize($fg_color,0.2);
|
|
|
|
|
&:highlighted {
|
|
|
|
|
color: $fg_color;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.input-source-switcher-symbol {
|
|
|
|
|
font-size: 34pt;
|
|
|
|
|
width: 96px;
|
|
|
|
|
height: 96px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Window Cycler */
|
|
|
|
|
.cycler-highlight { border: 5px solid $selected_bg_color; }
|
|
|
|
|
|
|
|
|
|
/* Workspace Switcher */
|
|
|
|
|
.workspace-switcher-group { padding: 12px; }
|
|
|
|
|
|
|
|
|
|
.workspace-switcher-container {
|
|
|
|
|
@extend %osd-panel;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.workspace-switcher {
|
|
|
|
|
background: transparent;
|
|
|
|
|
border: 0px;
|
|
|
|
|
border-radius: 0px;
|
|
|
|
|
padding: 0px;
|
|
|
|
|
spacing: 8px;
|
|
|
|
|
}
|
|
|
|
|
|
2019-06-04 15:22:26 -04:00
|
|
|
.ws-switcher-active-up, .ws-switcher-active-down,
|
|
|
|
|
.ws-switcher-active-left, .ws-switcher-active-right {
|
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
|
|
|
height: 50px;
|
|
|
|
|
background-color: $selected_bg_color;
|
|
|
|
|
color: $selected_fg_color;
|
|
|
|
|
background-size: 32px;
|
|
|
|
|
border-radius: 8px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.ws-switcher-box {
|
|
|
|
|
height: 50px;
|
|
|
|
|
border: 1px solid transparentize($osd_fg_color,0.9);
|
|
|
|
|
background: transparent;
|
|
|
|
|
border-radius: 8px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
%osd-panel {
|
2019-06-18 09:29:00 -04:00
|
|
|
color: $osd_fg_color;
|
|
|
|
|
background-color: $osd_bg_color;
|
|
|
|
|
border: 1px solid $osd_outer_borders_color;
|
theme: Replace gnome-shell-sass submodule with subtree
As the style has grown bigger and more complex, generating the different
variants from a common source has been a good decision. However given how
intertwined the theme is with gnome-shell itself, relying on a submodule
has proven to be quite painful. And as things stand right now, it is going
to get worse:
- using either pre-generated CSS or generating it at build time is
odd, and violates meson's strict separation between source- and
build directories; we are therefore considering dropping the CSS
and depending on sassc to always generate it at build time
- with the migration to gitlab, our workflow shifts decisively towards
branches; however there is no support in either git or gitlab for
handling two brances of separate repositories consecutively, which
gets particularly awkward for branches in a private namespace
With those pain points in mind, we will adjust our setup as follows:
- remove the submodule from gnome-shell and instead import the
sass as subtree
- after that, the sass sources can be changed like any other files
in the repository, and regular contributors can forget that there
was ever anything special about them
- whenever we want to update the classic style, we can push the subtree
changes and bump gnome-shell-extension's sass submodule
In other words: Updating the classic styling will become slightly more
painful, but not much and only for me; in return, everyone else can
stop fiddling with submodules (and buy me a beer).
2018-02-09 13:22:55 -05:00
|
|
|
border-radius: 12px;
|
|
|
|
|
padding: 12px;
|
|
|
|
|
}
|
|
|
|
|
|
2019-06-18 09:29:00 -04:00
|
|
|
%bubble-entry {
|
|
|
|
|
color: $fg_color;
|
|
|
|
|
background-color: darken($bg_color, 2%);
|
|
|
|
|
border-color: $_bubble_borders_color;
|
|
|
|
|
box-shadow: none;
|
|
|
|
|
&:focus { border: 2px solid $selected_bg_color; }
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
%bubble-panel {
|
|
|
|
|
color: $fg_color;
|
|
|
|
|
background-color: $bg_color;
|
|
|
|
|
border: 1px solid if($variant=='light', transparentize(black, 0.6), $borders_color);
|
|
|
|
|
|
|
|
|
|
StEntry { @extend %bubble-entry; }
|
|
|
|
|
.button {
|
|
|
|
|
&, &:hover, &:focus, &:active, &:disabled {
|
|
|
|
|
box-shadow: none;
|
|
|
|
|
border-color: $_bubble_borders_color;
|
|
|
|
|
}
|
|
|
|
|
background-color: $bg_color;
|
|
|
|
|
color: $fg_color;
|
|
|
|
|
&:hover { background-color: $_hover_bg_color; }
|
|
|
|
|
&:active {
|
|
|
|
|
background-color: $selected_bg_color;
|
|
|
|
|
color: $selected_fg_color;
|
|
|
|
|
}
|
|
|
|
|
&:disabled { color: $insensitive_fg_color; }
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
theme: Replace gnome-shell-sass submodule with subtree
As the style has grown bigger and more complex, generating the different
variants from a common source has been a good decision. However given how
intertwined the theme is with gnome-shell itself, relying on a submodule
has proven to be quite painful. And as things stand right now, it is going
to get worse:
- using either pre-generated CSS or generating it at build time is
odd, and violates meson's strict separation between source- and
build directories; we are therefore considering dropping the CSS
and depending on sassc to always generate it at build time
- with the migration to gitlab, our workflow shifts decisively towards
branches; however there is no support in either git or gitlab for
handling two brances of separate repositories consecutively, which
gets particularly awkward for branches in a private namespace
With those pain points in mind, we will adjust our setup as follows:
- remove the submodule from gnome-shell and instead import the
sass as subtree
- after that, the sass sources can be changed like any other files
in the repository, and regular contributors can forget that there
was ever anything special about them
- whenever we want to update the classic style, we can push the subtree
changes and bump gnome-shell-extension's sass submodule
In other words: Updating the classic styling will become slightly more
painful, but not much and only for me; in return, everyone else can
stop fiddling with submodules (and buy me a beer).
2018-02-09 13:22:55 -05:00
|
|
|
/* Tiled window previews */
|
|
|
|
|
.tile-preview {
|
|
|
|
|
background-color: transparentize($selected_bg_color,0.5);
|
|
|
|
|
border: 1px solid $selected_bg_color;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.tile-preview-left.on-primary {
|
|
|
|
|
border-radius: $panel-corner-radius 0 0 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.tile-preview-right.on-primary {
|
|
|
|
|
border-radius: 0 $panel-corner-radius 0 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.tile-preview-left.tile-preview-right.on-primary {
|
|
|
|
|
border-radius: $panel-corner-radius $panel-corner-radius 0 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* TOP BAR */
|
|
|
|
|
|
|
|
|
|
#panel {
|
2019-01-30 11:48:28 -05:00
|
|
|
background-color: black;
|
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
|
|
|
font-weight: bold;
|
|
|
|
|
height: 1.86em;
|
2018-05-17 10:45:02 -04:00
|
|
|
font-feature-settings: "tnum";
|
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
|
|
|
|
|
|
|
|
&.unlock-screen,
|
|
|
|
|
&.login-screen,
|
|
|
|
|
&.lock-screen {
|
|
|
|
|
background-color: transparent;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#panelLeft, #panelCenter { // spacing between activities<>app menu and such
|
|
|
|
|
spacing: 4px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.panel-corner {
|
|
|
|
|
-panel-corner-radius: $panel-corner-radius;
|
2019-01-30 11:48:28 -05:00
|
|
|
-panel-corner-background-color: black;
|
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
|
|
|
-panel-corner-border-width: 2px;
|
|
|
|
|
-panel-corner-border-color: transparent;
|
|
|
|
|
|
|
|
|
|
&:active, &:overview, &:focus {
|
|
|
|
|
-panel-corner-border-color: lighten($selected_bg_color,5%);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
&.lock-screen, &.login-screen, &.unlock-screen {
|
|
|
|
|
-panel-corner-radius: 0;
|
|
|
|
|
-panel-corner-background-color: transparent;
|
|
|
|
|
-panel-corner-border-color: transparent;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.panel-button {
|
|
|
|
|
-natural-hpadding: 12px;
|
|
|
|
|
-minimum-hpadding: 6px;
|
|
|
|
|
font-weight: bold;
|
2019-01-30 11:48:28 -05:00
|
|
|
color: #ccc;
|
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
|
|
|
|
|
|
|
|
.app-menu-icon {
|
|
|
|
|
-st-icon-style: symbolic;
|
|
|
|
|
margin-left: 4px;
|
|
|
|
|
margin-right: 4px;
|
|
|
|
|
//dimensions of the icon are hardcoded
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
&:hover {
|
2019-06-18 09:29:00 -04:00
|
|
|
color: $selected_fg_color;
|
theme: Replace gnome-shell-sass submodule with subtree
As the style has grown bigger and more complex, generating the different
variants from a common source has been a good decision. However given how
intertwined the theme is with gnome-shell itself, relying on a submodule
has proven to be quite painful. And as things stand right now, it is going
to get worse:
- using either pre-generated CSS or generating it at build time is
odd, and violates meson's strict separation between source- and
build directories; we are therefore considering dropping the CSS
and depending on sassc to always generate it at build time
- with the migration to gitlab, our workflow shifts decisively towards
branches; however there is no support in either git or gitlab for
handling two brances of separate repositories consecutively, which
gets particularly awkward for branches in a private namespace
With those pain points in mind, we will adjust our setup as follows:
- remove the submodule from gnome-shell and instead import the
sass as subtree
- after that, the sass sources can be changed like any other files
in the repository, and regular contributors can forget that there
was ever anything special about them
- whenever we want to update the classic style, we can push the subtree
changes and bump gnome-shell-extension's sass submodule
In other words: Updating the classic styling will become slightly more
painful, but not much and only for me; in return, everyone else can
stop fiddling with submodules (and buy me a beer).
2018-02-09 13:22:55 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
&:active, &:overview, &:focus, &:checked {
|
|
|
|
|
// Trick due to St limitations. It needs a background to draw
|
|
|
|
|
// a box-shadow
|
|
|
|
|
background-color: rgba(0, 0, 0, 0.01);
|
|
|
|
|
box-shadow: inset 0 -2px 0px lighten($selected_bg_color,5%);
|
2019-06-18 09:29:00 -04:00
|
|
|
color: $selected_fg_color;
|
theme: Replace gnome-shell-sass submodule with subtree
As the style has grown bigger and more complex, generating the different
variants from a common source has been a good decision. However given how
intertwined the theme is with gnome-shell itself, relying on a submodule
has proven to be quite painful. And as things stand right now, it is going
to get worse:
- using either pre-generated CSS or generating it at build time is
odd, and violates meson's strict separation between source- and
build directories; we are therefore considering dropping the CSS
and depending on sassc to always generate it at build time
- with the migration to gitlab, our workflow shifts decisively towards
branches; however there is no support in either git or gitlab for
handling two brances of separate repositories consecutively, which
gets particularly awkward for branches in a private namespace
With those pain points in mind, we will adjust our setup as follows:
- remove the submodule from gnome-shell and instead import the
sass as subtree
- after that, the sass sources can be changed like any other files
in the repository, and regular contributors can forget that there
was ever anything special about them
- whenever we want to update the classic style, we can push the subtree
changes and bump gnome-shell-extension's sass submodule
In other words: Updating the classic styling will become slightly more
painful, but not much and only for me; in return, everyone else can
stop fiddling with submodules (and buy me a beer).
2018-02-09 13:22:55 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.system-status-icon { icon-size: 1.09em; padding: 0 5px; }
|
|
|
|
|
.unlock-screen &,
|
|
|
|
|
.login-screen &,
|
|
|
|
|
.lock-screen & {
|
|
|
|
|
color: lighten($fg_color, 10%);
|
|
|
|
|
&:focus, &:hover, &:active { color: lighten($fg_color, 10%); }
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.panel-status-indicators-box,
|
|
|
|
|
.panel-status-menu-box {
|
|
|
|
|
spacing: 2px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// spacing between power icon and (optional) percentage label
|
|
|
|
|
.power-status.panel-status-indicators-box {
|
|
|
|
|
spacing: 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.screencast-indicator { color: $warning_color; }
|
|
|
|
|
|
2018-07-27 12:07:52 -04:00
|
|
|
.remote-access-indicator { color: $warning_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
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// calendar popover
|
|
|
|
|
#calendarArea {
|
|
|
|
|
padding: 0.75em 1.0em;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.calendar {
|
|
|
|
|
margin-bottom: 1em;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.calendar,
|
|
|
|
|
.datemenu-today-button,
|
|
|
|
|
.datemenu-displays-box,
|
|
|
|
|
.message-list-sections {
|
|
|
|
|
margin: 0 1.5em;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.datemenu-calendar-column { spacing: 0.5em; }
|
|
|
|
|
.datemenu-displays-section { padding-bottom: 3em; }
|
|
|
|
|
.datemenu-displays-box { spacing: 1em; }
|
|
|
|
|
|
|
|
|
|
.datemenu-calendar-column {
|
2019-06-18 09:29:00 -04:00
|
|
|
border: 0 solid $_bubble_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 13:22:55 -05:00
|
|
|
&:ltr { border-left-width: 1px; }
|
|
|
|
|
&:rtl { border-right-width: 1px; }
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.datemenu-today-button,
|
|
|
|
|
.world-clocks-button,
|
|
|
|
|
.weather-button,
|
|
|
|
|
.events-section-title {
|
|
|
|
|
border-radius: 4px;
|
|
|
|
|
padding: .4em;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.message-list-section-list:ltr {
|
|
|
|
|
padding-left: .4em;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.message-list-section-list:rtl {
|
|
|
|
|
padding-right: .4em;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.datemenu-today-button,
|
|
|
|
|
.world-clocks-button,
|
|
|
|
|
.weather-button,
|
|
|
|
|
.events-section-title {
|
2019-06-18 09:29:00 -04:00
|
|
|
&:hover, focus { background-color: $_hover_bg_color }
|
|
|
|
|
&:active { background-color: $_active_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
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.datemenu-today-button .day-label {
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.datemenu-today-button .date-label {
|
|
|
|
|
font-size: 1.5em;
|
2018-02-14 10:42:56 -05:00
|
|
|
font-weight: 300;
|
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
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.world-clocks-header,
|
|
|
|
|
.weather-header,
|
|
|
|
|
.events-section-title {
|
|
|
|
|
color: darken($fg_color,40%);
|
|
|
|
|
font-weight: bold;
|
|
|
|
|
}
|
|
|
|
|
|
2019-01-11 11:42:22 -05:00
|
|
|
.weather-header.location {
|
|
|
|
|
font-weight: normal;
|
|
|
|
|
font-size: 0.9em;
|
|
|
|
|
}
|
|
|
|
|
|
2018-12-13 08:45:22 -05:00
|
|
|
.world-clocks-grid,
|
|
|
|
|
.weather-grid {
|
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
|
|
|
spacing-rows: 0.4em;
|
2018-12-13 11:44:28 -05:00
|
|
|
spacing-columns: 0.8em;
|
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
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.weather-box {
|
|
|
|
|
spacing: 0.4em;
|
|
|
|
|
}
|
|
|
|
|
|
2018-12-13 11:44:28 -05:00
|
|
|
.world-clocks-city {
|
|
|
|
|
font-weight: bold;
|
|
|
|
|
font-size: 0.9em;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.world-clocks-time {
|
|
|
|
|
color: darken($fg_color,20%);
|
|
|
|
|
font-feature-settings: "tnum";
|
|
|
|
|
font-size: 1.2em;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.world-clocks-timezone {
|
2019-06-18 09:29:00 -04:00
|
|
|
color: $fg_color;
|
2018-12-13 11:44:28 -05:00
|
|
|
font-feature-settings: "tnum";
|
|
|
|
|
font-size: 0.9em;
|
2018-12-13 08:45:22 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.weather-forecast-icon {
|
|
|
|
|
icon-size: 2.18em;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.weather-forecast-time {
|
|
|
|
|
color: darken($fg_color,40%);
|
|
|
|
|
font-size: 0.8em;
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
.calendar-month-label {
|
2019-06-18 09:29:00 -04:00
|
|
|
color: lighten($fg_color,5%);
|
theme: Replace gnome-shell-sass submodule with subtree
As the style has grown bigger and more complex, generating the different
variants from a common source has been a good decision. However given how
intertwined the theme is with gnome-shell itself, relying on a submodule
has proven to be quite painful. And as things stand right now, it is going
to get worse:
- using either pre-generated CSS or generating it at build time is
odd, and violates meson's strict separation between source- and
build directories; we are therefore considering dropping the CSS
and depending on sassc to always generate it at build time
- with the migration to gitlab, our workflow shifts decisively towards
branches; however there is no support in either git or gitlab for
handling two brances of separate repositories consecutively, which
gets particularly awkward for branches in a private namespace
With those pain points in mind, we will adjust our setup as follows:
- remove the submodule from gnome-shell and instead import the
sass as subtree
- after that, the sass sources can be changed like any other files
in the repository, and regular contributors can forget that there
was ever anything special about them
- whenever we want to update the classic style, we can push the subtree
changes and bump gnome-shell-extension's sass submodule
In other words: Updating the classic styling will become slightly more
painful, but not much and only for me; in return, everyone else can
stop fiddling with submodules (and buy me a beer).
2018-02-09 13:22:55 -05:00
|
|
|
font-weight: bold;
|
|
|
|
|
padding: 8px 0;
|
|
|
|
|
&:focus {}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.pager-button {
|
|
|
|
|
background-color: transparent;
|
|
|
|
|
width: 32px;
|
|
|
|
|
border-radius: 4px;
|
2019-06-18 09:29:00 -04:00
|
|
|
&:hover, focus { background-color: $_hover_bg_color; }
|
|
|
|
|
&:active { background-color: transparentize($fg_color, 0.84); }
|
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
|
|
|
}
|
|
|
|
|
|
2018-11-20 11:55:31 -05:00
|
|
|
.calendar-change-month-back StIcon, .calendar-change-month-forward StIcon { // arrows
|
|
|
|
|
icon-size: 1.09em;
|
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
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.calendar-day-base {
|
|
|
|
|
font-size: 80%;
|
|
|
|
|
text-align: center;
|
|
|
|
|
width: 2.4em; height: 2.4em;
|
|
|
|
|
padding: 0.1em;
|
|
|
|
|
margin: 2px;
|
|
|
|
|
border-radius: 1.4em;
|
2018-05-17 10:45:02 -04:00
|
|
|
font-feature-settings: "tnum";
|
2019-06-18 09:29:00 -04:00
|
|
|
&:hover, focus { background-color: $_hover_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
|
|
|
&:active,&:selected {
|
|
|
|
|
color: lighten($selected_fg_color,5%);
|
|
|
|
|
background-color: $selected_bg_color;
|
|
|
|
|
border-color: transparent; //avoid jumparound due to today
|
|
|
|
|
}
|
|
|
|
|
&.calendar-day-heading { //day of week heading
|
2019-06-18 09:29:00 -04:00
|
|
|
color: lighten($fg_color,5%);
|
theme: Replace gnome-shell-sass submodule with subtree
As the style has grown bigger and more complex, generating the different
variants from a common source has been a good decision. However given how
intertwined the theme is with gnome-shell itself, relying on a submodule
has proven to be quite painful. And as things stand right now, it is going
to get worse:
- using either pre-generated CSS or generating it at build time is
odd, and violates meson's strict separation between source- and
build directories; we are therefore considering dropping the CSS
and depending on sassc to always generate it at build time
- with the migration to gitlab, our workflow shifts decisively towards
branches; however there is no support in either git or gitlab for
handling two brances of separate repositories consecutively, which
gets particularly awkward for branches in a private namespace
With those pain points in mind, we will adjust our setup as follows:
- remove the submodule from gnome-shell and instead import the
sass as subtree
- after that, the sass sources can be changed like any other files
in the repository, and regular contributors can forget that there
was ever anything special about them
- whenever we want to update the classic style, we can push the subtree
changes and bump gnome-shell-extension's sass submodule
In other words: Updating the classic styling will become slightly more
painful, but not much and only for me; in return, everyone else can
stop fiddling with submodules (and buy me a beer).
2018-02-09 13:22:55 -05:00
|
|
|
margin-top: 1em;
|
|
|
|
|
font-size: 70%;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
.calendar-day { //border collapse hack - see calendar.js
|
|
|
|
|
border-width: 0;
|
|
|
|
|
}
|
|
|
|
|
.calendar-day-top { border-top-width: 1px; }
|
|
|
|
|
.calendar-day-left { border-left-width: 1px; }
|
|
|
|
|
.calendar-work-day {
|
|
|
|
|
|
|
|
|
|
}
|
|
|
|
|
.calendar-nonwork-day {
|
|
|
|
|
color: $insensitive_fg_color;
|
|
|
|
|
}
|
|
|
|
|
.calendar-today {
|
|
|
|
|
font-weight: bold;
|
|
|
|
|
//color: lighten($fg_color,10%);
|
|
|
|
|
//background-color: darken($bg_color,5%);
|
2019-06-18 09:29:00 -04:00
|
|
|
border: 1px solid $_bubble_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 13:22:55 -05:00
|
|
|
}
|
|
|
|
|
.calendar-day-with-events {
|
|
|
|
|
color: lighten($fg_color,10%);
|
|
|
|
|
font-weight: bold;
|
|
|
|
|
background-image: url("resource:///org/gnome/shell/theme/calendar-today.svg");
|
|
|
|
|
}
|
|
|
|
|
.calendar-other-month-day {
|
2019-06-18 09:29:00 -04:00
|
|
|
color: transparentize($fg_color ,0.5);
|
theme: Replace gnome-shell-sass submodule with subtree
As the style has grown bigger and more complex, generating the different
variants from a common source has been a good decision. However given how
intertwined the theme is with gnome-shell itself, relying on a submodule
has proven to be quite painful. And as things stand right now, it is going
to get worse:
- using either pre-generated CSS or generating it at build time is
odd, and violates meson's strict separation between source- and
build directories; we are therefore considering dropping the CSS
and depending on sassc to always generate it at build time
- with the migration to gitlab, our workflow shifts decisively towards
branches; however there is no support in either git or gitlab for
handling two brances of separate repositories consecutively, which
gets particularly awkward for branches in a private namespace
With those pain points in mind, we will adjust our setup as follows:
- remove the submodule from gnome-shell and instead import the
sass as subtree
- after that, the sass sources can be changed like any other files
in the repository, and regular contributors can forget that there
was ever anything special about them
- whenever we want to update the classic style, we can push the subtree
changes and bump gnome-shell-extension's sass submodule
In other words: Updating the classic styling will become slightly more
painful, but not much and only for me; in return, everyone else can
stop fiddling with submodules (and buy me a beer).
2018-02-09 13:22:55 -05:00
|
|
|
opacity: 0.5;
|
|
|
|
|
}
|
|
|
|
|
.calendar-week-number {
|
|
|
|
|
font-size: 70%;
|
|
|
|
|
font-weight: bold;
|
|
|
|
|
width: 2.3em; height: 1.8em;
|
|
|
|
|
border-radius: 2px;
|
|
|
|
|
padding: 0.5em 0 0;
|
|
|
|
|
margin: 6px;
|
2019-06-18 09:29:00 -04:00
|
|
|
background-color: $_bubble_borders_color;
|
|
|
|
|
color: $fg_color;
|
theme: Replace gnome-shell-sass submodule with subtree
As the style has grown bigger and more complex, generating the different
variants from a common source has been a good decision. However given how
intertwined the theme is with gnome-shell itself, relying on a submodule
has proven to be quite painful. And as things stand right now, it is going
to get worse:
- using either pre-generated CSS or generating it at build time is
odd, and violates meson's strict separation between source- and
build directories; we are therefore considering dropping the CSS
and depending on sassc to always generate it at build time
- with the migration to gitlab, our workflow shifts decisively towards
branches; however there is no support in either git or gitlab for
handling two brances of separate repositories consecutively, which
gets particularly awkward for branches in a private namespace
With those pain points in mind, we will adjust our setup as follows:
- remove the submodule from gnome-shell and instead import the
sass as subtree
- after that, the sass sources can be changed like any other files
in the repository, and regular contributors can forget that there
was ever anything special about them
- whenever we want to update the classic style, we can push the subtree
changes and bump gnome-shell-extension's sass submodule
In other words: Updating the classic styling will become slightly more
painful, but not much and only for me; in return, everyone else can
stop fiddling with submodules (and buy me a beer).
2018-02-09 13:22:55 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Message list */
|
|
|
|
|
.message-list {
|
|
|
|
|
width: 31.5em;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.message-list-clear-button.button {
|
2019-06-18 09:29:00 -04:00
|
|
|
@extend %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 13:22:55 -05:00
|
|
|
margin: 1.5em 1.5em 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.message-list-sections {
|
|
|
|
|
spacing: 1em;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.message-list-section,
|
|
|
|
|
.message-list-section-list {
|
|
|
|
|
spacing: 0.4em;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.message {
|
2019-06-18 09:29:00 -04:00
|
|
|
border: 1px solid $_bubble_borders_color;
|
|
|
|
|
background-color: lighten($bg_color, 2%);
|
|
|
|
|
&:hover,&:focus { background-color: $_hover_bg_color; }
|
|
|
|
|
&:active { background-color: transparentize($fg_color, 0.84) }
|
|
|
|
|
border-radius: 5px;
|
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
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.message-icon-bin {
|
|
|
|
|
padding: 0.68em 0.2em 0.68em 0.68em;
|
|
|
|
|
&:rtl { padding: 0.68em 0.68em 0.68em 0.2em; }
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.message-icon-bin > StIcon {
|
2019-06-18 09:29:00 -04:00
|
|
|
color: $fg_color;
|
theme: Replace gnome-shell-sass submodule with subtree
As the style has grown bigger and more complex, generating the different
variants from a common source has been a good decision. However given how
intertwined the theme is with gnome-shell itself, relying on a submodule
has proven to be quite painful. And as things stand right now, it is going
to get worse:
- using either pre-generated CSS or generating it at build time is
odd, and violates meson's strict separation between source- and
build directories; we are therefore considering dropping the CSS
and depending on sassc to always generate it at build time
- with the migration to gitlab, our workflow shifts decisively towards
branches; however there is no support in either git or gitlab for
handling two brances of separate repositories consecutively, which
gets particularly awkward for branches in a private namespace
With those pain points in mind, we will adjust our setup as follows:
- remove the submodule from gnome-shell and instead import the
sass as subtree
- after that, the sass sources can be changed like any other files
in the repository, and regular contributors can forget that there
was ever anything special about them
- whenever we want to update the classic style, we can push the subtree
changes and bump gnome-shell-extension's sass submodule
In other words: Updating the classic styling will become slightly more
painful, but not much and only for me; in return, everyone else can
stop fiddling with submodules (and buy me a beer).
2018-02-09 13:22:55 -05:00
|
|
|
icon-size: 1.09em;
|
|
|
|
|
-st-icon-style: symbolic;
|
|
|
|
|
}
|
|
|
|
|
|
2019-03-08 08:12:12 -05:00
|
|
|
.message-icon-bin > .fallback-window-icon {
|
|
|
|
|
width: 1.09em;
|
|
|
|
|
height: 1.09em;
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
.message-secondary-bin {
|
|
|
|
|
padding: 0 0.82em;;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.message-secondary-bin > .event-time {
|
2019-06-18 09:29:00 -04:00
|
|
|
color: $fg_color;
|
theme: Replace gnome-shell-sass submodule with subtree
As the style has grown bigger and more complex, generating the different
variants from a common source has been a good decision. However given how
intertwined the theme is with gnome-shell itself, relying on a submodule
has proven to be quite painful. And as things stand right now, it is going
to get worse:
- using either pre-generated CSS or generating it at build time is
odd, and violates meson's strict separation between source- and
build directories; we are therefore considering dropping the CSS
and depending on sassc to always generate it at build time
- with the migration to gitlab, our workflow shifts decisively towards
branches; however there is no support in either git or gitlab for
handling two brances of separate repositories consecutively, which
gets particularly awkward for branches in a private namespace
With those pain points in mind, we will adjust our setup as follows:
- remove the submodule from gnome-shell and instead import the
sass as subtree
- after that, the sass sources can be changed like any other files
in the repository, and regular contributors can forget that there
was ever anything special about them
- whenever we want to update the classic style, we can push the subtree
changes and bump gnome-shell-extension's sass submodule
In other words: Updating the classic styling will become slightly more
painful, but not much and only for me; in return, everyone else can
stop fiddling with submodules (and buy me a beer).
2018-02-09 13:22:55 -05:00
|
|
|
font-size: 0.7em;
|
|
|
|
|
/* HACK: the label should be baseline-aligned with a 1em label,
|
|
|
|
|
fake this with some bottom padding */
|
|
|
|
|
padding-bottom: 0.13em;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.message-secondary-bin > StIcon {
|
|
|
|
|
icon-size: 1.09em;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.message-title {
|
2019-06-18 09:29:00 -04:00
|
|
|
color: $fg_color;
|
theme: Replace gnome-shell-sass submodule with subtree
As the style has grown bigger and more complex, generating the different
variants from a common source has been a good decision. However given how
intertwined the theme is with gnome-shell itself, relying on a submodule
has proven to be quite painful. And as things stand right now, it is going
to get worse:
- using either pre-generated CSS or generating it at build time is
odd, and violates meson's strict separation between source- and
build directories; we are therefore considering dropping the CSS
and depending on sassc to always generate it at build time
- with the migration to gitlab, our workflow shifts decisively towards
branches; however there is no support in either git or gitlab for
handling two brances of separate repositories consecutively, which
gets particularly awkward for branches in a private namespace
With those pain points in mind, we will adjust our setup as follows:
- remove the submodule from gnome-shell and instead import the
sass as subtree
- after that, the sass sources can be changed like any other files
in the repository, and regular contributors can forget that there
was ever anything special about them
- whenever we want to update the classic style, we can push the subtree
changes and bump gnome-shell-extension's sass submodule
In other words: Updating the classic styling will become slightly more
painful, but not much and only for me; in return, everyone else can
stop fiddling with submodules (and buy me a beer).
2018-02-09 13:22:55 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.message-content {
|
2019-06-18 09:29:00 -04:00
|
|
|
color: darken($fg_color, 10%);
|
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
|
|
|
padding: 10px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.message-media-control {
|
|
|
|
|
padding: 12px;
|
2019-06-18 09:29:00 -04:00
|
|
|
color: lighten($fg_color, 15%);
|
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
|
|
|
|
|
|
|
|
&:last-child:ltr { padding-right: 18px; }
|
|
|
|
|
&:last-child:rtl { padding-left: 18px; }
|
|
|
|
|
&:hover { color: $fg_color; }
|
|
|
|
|
&:insensitive { color: darken($fg_color,40%); }
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.media-message-cover-icon {
|
|
|
|
|
icon-size: 48px !important;
|
|
|
|
|
&.fallback {
|
2019-06-18 09:29:00 -04:00
|
|
|
color: lighten($fg_color,10%);
|
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
|
|
|
background-color: $bg_color;
|
2019-06-18 09:29:00 -04:00
|
|
|
border: 1px solid $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
|
|
|
border-radius: 2px;
|
2018-09-13 14:14:05 -04:00
|
|
|
icon-size: 32px !important;
|
|
|
|
|
padding: 6px; }
|
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
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
// a little unstructured mess:
|
|
|
|
|
|
|
|
|
|
#appMenu {
|
|
|
|
|
spacing: 4px;
|
|
|
|
|
|
|
|
|
|
.label-shadow { color: transparent; }
|
|
|
|
|
}
|
|
|
|
|
|
2019-02-04 19:11:43 -05:00
|
|
|
.app-menu,
|
|
|
|
|
.app-well-menu {
|
|
|
|
|
max-width: 27.25em;
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
.aggregate-menu {
|
|
|
|
|
min-width: 21em;
|
|
|
|
|
.popup-menu-icon { padding: 0 4px; }
|
2018-04-02 17:54:43 -04:00
|
|
|
.popup-sub-menu .popup-menu-item > :first-child {
|
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
|
|
|
&:ltr { /* 12px spacing + 2*4px padding */
|
|
|
|
|
padding-left: 20px; margin-left: 1.09em; }
|
|
|
|
|
&:rtl { /* 12px spacing + 2*4px padding */
|
|
|
|
|
padding-right: 20px; margin-right: 1.09em; }
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.system-menu-action {
|
2018-07-24 10:29:56 -04:00
|
|
|
-st-icon-style: symbolic;
|
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
|
|
|
color: $fg_color;
|
|
|
|
|
border-radius: 32px; /* wish we could do 50% */
|
|
|
|
|
padding: 13px;
|
2019-06-18 09:29:00 -04:00
|
|
|
border: 1px solid $_bubble_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 13:22:55 -05:00
|
|
|
|
|
|
|
|
&:hover, &:focus {
|
2019-06-18 09:29:00 -04:00
|
|
|
background-color: $_hover_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
|
|
|
color: $fg_color;
|
|
|
|
|
border: none;
|
|
|
|
|
padding: 14px;
|
|
|
|
|
}
|
2019-06-18 09:29:00 -04:00
|
|
|
&:active {
|
|
|
|
|
background-color: $selected_bg_color;
|
|
|
|
|
color: $selected_fg_color;
|
|
|
|
|
}
|
theme: Replace gnome-shell-sass submodule with subtree
As the style has grown bigger and more complex, generating the different
variants from a common source has been a good decision. However given how
intertwined the theme is with gnome-shell itself, relying on a submodule
has proven to be quite painful. And as things stand right now, it is going
to get worse:
- using either pre-generated CSS or generating it at build time is
odd, and violates meson's strict separation between source- and
build directories; we are therefore considering dropping the CSS
and depending on sassc to always generate it at build time
- with the migration to gitlab, our workflow shifts decisively towards
branches; however there is no support in either git or gitlab for
handling two brances of separate repositories consecutively, which
gets particularly awkward for branches in a private namespace
With those pain points in mind, we will adjust our setup as follows:
- remove the submodule from gnome-shell and instead import the
sass as subtree
- after that, the sass sources can be changed like any other files
in the repository, and regular contributors can forget that there
was ever anything special about them
- whenever we want to update the classic style, we can push the subtree
changes and bump gnome-shell-extension's sass submodule
In other words: Updating the classic styling will become slightly more
painful, but not much and only for me; in return, everyone else can
stop fiddling with submodules (and buy me a beer).
2018-02-09 13:22:55 -05:00
|
|
|
|
|
|
|
|
& > StIcon { icon-size: 16px; }
|
|
|
|
|
}
|
|
|
|
|
|
2018-11-16 14:05:05 -05:00
|
|
|
// Activities Ripples
|
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
|
|
|
.ripple-box {
|
|
|
|
|
width: 52px;
|
|
|
|
|
height: 52px;
|
2018-11-16 14:05:05 -05:00
|
|
|
border-radius: 0 0 52px 0; // radius the size of the box give us the curve
|
|
|
|
|
background-color: lighten(transparentize($selected_bg_color, 0.7), 40%);
|
|
|
|
|
box-shadow: 0 0 2px 2px lighten($selected_bg_color, 20%);
|
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
|
|
|
}
|
|
|
|
|
|
2018-11-16 14:05:05 -05:00
|
|
|
.ripple-box:rtl { border-radius: 0 0 0 52px; } // just a simple change to the border radius position
|
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-04-04 10:03:54 -04:00
|
|
|
// Rubberband for select-area screenshots
|
|
|
|
|
.select-area-rubberband {
|
|
|
|
|
background-color: transparentize($selected_bg_color,0.7);
|
|
|
|
|
border: 1px solid $selected_bg_color;
|
|
|
|
|
}
|
|
|
|
|
|
2019-02-20 04:12:36 -05:00
|
|
|
// Pointer location
|
|
|
|
|
.ripple-pointer-location {
|
|
|
|
|
width: 50px;
|
|
|
|
|
height: 50px;
|
|
|
|
|
border-radius: 25px 25px 25px 25px; // radius the size of the box give us the curve
|
|
|
|
|
background-color: lighten(transparentize($selected_bg_color, 0.7), 30%);
|
|
|
|
|
box-shadow: 0 0 2px 2px lighten($selected_bg_color, 20%);
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
// not really top bar only
|
2019-03-10 16:57:54 -04:00
|
|
|
.popup-menu-arrow { icon-size: 1.09em; }
|
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
|
|
|
.popup-menu-icon { icon-size: 1.09em; }
|
|
|
|
|
|
|
|
|
|
//close buttons
|
|
|
|
|
|
|
|
|
|
.window-close {
|
2019-03-15 09:41:55 -04:00
|
|
|
background-color: $selected_bg_color;
|
|
|
|
|
color: white;
|
2018-11-16 11:15:44 -05:00
|
|
|
border-radius: 24px;
|
2019-03-15 09:41:55 -04:00
|
|
|
border: 2px solid $selected_bg_color;
|
2018-11-16 11:15:44 -05:00
|
|
|
height: 24px;
|
|
|
|
|
width: 24px;
|
2019-03-15 09:41:55 -04:00
|
|
|
-shell-close-overlap: 11px;
|
|
|
|
|
box-shadow: -1px 1px 5px 0px transparentize(black, 0.5);
|
2018-11-16 11:15:44 -05:00
|
|
|
|
|
|
|
|
&:hover {
|
2019-03-15 09:41:55 -04:00
|
|
|
background-color: lighten($selected_bg_color, 5%);
|
|
|
|
|
border-color: lighten($selected_bg_color, 5%);
|
2018-11-16 11:15:44 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
&:active {
|
2019-03-15 09:41:55 -04:00
|
|
|
background-color: darken($selected_bg_color, 5%);
|
|
|
|
|
border-color: darken($selected_bg_color, 5%);
|
2018-11-16 11:15:44 -05: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 13:22:55 -05:00
|
|
|
}
|
|
|
|
|
|
2019-03-20 12:46:12 -04:00
|
|
|
// Pointer accessibility notifications
|
|
|
|
|
.pie-timer {
|
|
|
|
|
width: 60px;
|
|
|
|
|
height: 60px;
|
|
|
|
|
-pie-border-width: 3px;
|
|
|
|
|
-pie-border-color: $selected_bg_color;
|
|
|
|
|
-pie-background-color: lighten(transparentize($selected_bg_color, 0.7), 40%);
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
/* NETWORK DIALOGS */
|
|
|
|
|
|
|
|
|
|
.nm-dialog {
|
2019-06-18 09:29:00 -04:00
|
|
|
@extend %bubble-panel;
|
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
|
|
|
max-height: 34em;
|
|
|
|
|
min-height: 31em;
|
|
|
|
|
min-width: 32em;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.nm-dialog-content {
|
|
|
|
|
spacing: 20px;
|
|
|
|
|
padding: 24px;
|
|
|
|
|
}
|
|
|
|
|
.nm-dialog-header-hbox { spacing: 10px; }
|
|
|
|
|
.nm-dialog-airplane-box { spacing: 12px; }
|
|
|
|
|
|
|
|
|
|
.nm-dialog-airplane-headline {
|
|
|
|
|
font-weight: bold;
|
|
|
|
|
text-align: center;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.nm-dialog-airplane-text { color: $fg_color; }
|
|
|
|
|
.nm-dialog-header-icon { icon-size: 32px; }
|
|
|
|
|
.nm-dialog-scroll-view { border: 2px solid $borders_color; }
|
|
|
|
|
.nm-dialog-header { font-weight: bold; }
|
|
|
|
|
|
|
|
|
|
.nm-dialog-item {
|
|
|
|
|
font-size: 110%;
|
|
|
|
|
border-bottom: 1px solid $borders_color;
|
|
|
|
|
padding: 12px;
|
|
|
|
|
spacing: 20px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.nm-dialog-item:selected {
|
|
|
|
|
background-color: $selected_bg_color;
|
|
|
|
|
color: $selected_fg_color;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.nm-dialog-icons { spacing: .5em; }
|
|
|
|
|
.nm-dialog-icon { icon-size: 16px; }
|
|
|
|
|
.no-networks-label { color: #999999; }
|
|
|
|
|
.no-networks-box { spacing: 12px; }
|
|
|
|
|
|
|
|
|
|
/* OVERVIEW */
|
|
|
|
|
|
|
|
|
|
#overview {
|
|
|
|
|
spacing: 24px; //
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.overview-controls {
|
|
|
|
|
padding-bottom: 32px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.window-picker { //container around window thumbnails
|
|
|
|
|
-horizontal-spacing: 16px;
|
|
|
|
|
-vertical-spacing: 16px;
|
|
|
|
|
padding: 0 16px 16px;
|
|
|
|
|
|
|
|
|
|
&.external-monitor { padding: 16px; }
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.window-clone-border {
|
2019-03-15 09:41:55 -04:00
|
|
|
$_bg: transparentize(white, 0.65);
|
2019-07-15 23:27:34 -04:00
|
|
|
border: 7px solid $_bg;
|
|
|
|
|
border-radius: $modal_radius;
|
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
|
|
|
// For window decorations with round corners we can't match
|
|
|
|
|
// the exact shape when the window is scaled. So apply a shadow
|
|
|
|
|
// to fix that case
|
2019-03-15 09:41:55 -04:00
|
|
|
box-shadow: inset 0 0 0 1px $_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
|
|
|
.window-caption {
|
|
|
|
|
spacing: 25px;
|
|
|
|
|
color: $selected_fg_color;
|
|
|
|
|
background-color: $selected_bg_color;
|
|
|
|
|
border-radius: 8px;
|
|
|
|
|
padding: 4px 12px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
//search entry
|
2019-06-18 09:29:00 -04:00
|
|
|
.search-entry, %search_entry {
|
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
|
|
|
width: 320px;
|
|
|
|
|
padding: 7px 9px;
|
2019-06-18 09:29:00 -04:00
|
|
|
border-radius: 18px;
|
|
|
|
|
color: $fg_color;
|
|
|
|
|
background-color: $base_color;
|
|
|
|
|
border-color: $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 13:22:55 -05:00
|
|
|
&:focus {
|
|
|
|
|
padding: 6px 8px;
|
|
|
|
|
border-width: 2px;
|
|
|
|
|
border-color: $selected_bg_color;
|
|
|
|
|
}
|
|
|
|
|
|
2019-06-18 09:29:00 -04:00
|
|
|
.search-entry-icon { icon-size: 1em; padding: 0 4px; color: $fg_color; }
|
theme: Replace gnome-shell-sass submodule with subtree
As the style has grown bigger and more complex, generating the different
variants from a common source has been a good decision. However given how
intertwined the theme is with gnome-shell itself, relying on a submodule
has proven to be quite painful. And as things stand right now, it is going
to get worse:
- using either pre-generated CSS or generating it at build time is
odd, and violates meson's strict separation between source- and
build directories; we are therefore considering dropping the CSS
and depending on sassc to always generate it at build time
- with the migration to gitlab, our workflow shifts decisively towards
branches; however there is no support in either git or gitlab for
handling two brances of separate repositories consecutively, which
gets particularly awkward for branches in a private namespace
With those pain points in mind, we will adjust our setup as follows:
- remove the submodule from gnome-shell and instead import the
sass as subtree
- after that, the sass sources can be changed like any other files
in the repository, and regular contributors can forget that there
was ever anything special about them
- whenever we want to update the classic style, we can push the subtree
changes and bump gnome-shell-extension's sass submodule
In other words: Updating the classic styling will become slightly more
painful, but not much and only for me; in return, everyone else can
stop fiddling with submodules (and buy me a beer).
2018-02-09 13:22:55 -05:00
|
|
|
|
|
|
|
|
&:hover, &:focus {
|
2019-06-18 09:29:00 -04:00
|
|
|
.search-entry-icon { color: transparentize($fg_color,.3); }
|
theme: Replace gnome-shell-sass submodule with subtree
As the style has grown bigger and more complex, generating the different
variants from a common source has been a good decision. However given how
intertwined the theme is with gnome-shell itself, relying on a submodule
has proven to be quite painful. And as things stand right now, it is going
to get worse:
- using either pre-generated CSS or generating it at build time is
odd, and violates meson's strict separation between source- and
build directories; we are therefore considering dropping the CSS
and depending on sassc to always generate it at build time
- with the migration to gitlab, our workflow shifts decisively towards
branches; however there is no support in either git or gitlab for
handling two brances of separate repositories consecutively, which
gets particularly awkward for branches in a private namespace
With those pain points in mind, we will adjust our setup as follows:
- remove the submodule from gnome-shell and instead import the
sass as subtree
- after that, the sass sources can be changed like any other files
in the repository, and regular contributors can forget that there
was ever anything special about them
- whenever we want to update the classic style, we can push the subtree
changes and bump gnome-shell-extension's sass submodule
In other words: Updating the classic styling will become slightly more
painful, but not much and only for me; in return, everyone else can
stop fiddling with submodules (and buy me a beer).
2018-02-09 13:22:55 -05:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
//search results
|
|
|
|
|
|
|
|
|
|
#searchResultsContent {
|
2018-11-24 16:33:05 -05:00
|
|
|
max-width: 1000px;
|
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
|
|
|
padding-left: 20px;
|
|
|
|
|
padding-right: 20px;
|
|
|
|
|
spacing: 16px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.search-section { spacing: 16px; } // This should be equal to #searchResultsContent spacing
|
|
|
|
|
.search-section-content { spacing: 32px; } // This is the space between the provider icon and the results container
|
|
|
|
|
.search-statustext { // "no results"
|
|
|
|
|
@extend %status_text;
|
|
|
|
|
}
|
|
|
|
|
.list-search-results { spacing: 3px; }
|
|
|
|
|
|
|
|
|
|
.search-section-separator { height: 2px; background-color: rgba(255, 255, 255, 0.2); }
|
|
|
|
|
|
2018-11-24 18:45:19 -05:00
|
|
|
.search-section:last-child .search-section-separator { background-color: transparent; }
|
|
|
|
|
|
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
|
|
|
.list-search-result-content { spacing: 30px; }
|
|
|
|
|
.list-search-result-title { color: darken($osd_fg_color,5%); spacing: 12px; }
|
2019-06-18 09:29:00 -04:00
|
|
|
.list-search-result-description { color: darken($osd_fg_color, 30%); }
|
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
|
|
|
.list-search-provider-details { width: 150px; color: darken($osd_fg_color,5%); margin-top: 0.24em; }
|
|
|
|
|
.list-search-provider-content { spacing: 20px; }
|
|
|
|
|
.search-provider-icon { padding: 15px; }
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/* DASHBOARD */
|
|
|
|
|
|
|
|
|
|
#dash {
|
2019-06-18 09:29:00 -04:00
|
|
|
@extend %overview-panel;
|
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
|
|
|
font-size: 9pt;
|
|
|
|
|
padding: 4px 0;
|
|
|
|
|
border-radius: 0px 9px 9px 0px;
|
|
|
|
|
|
|
|
|
|
&:rtl {
|
|
|
|
|
border-radius: 9px 0 0 9px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.placeholder {
|
|
|
|
|
background-image: url("resource:///org/gnome/shell/theme/dash-placeholder.svg");
|
|
|
|
|
background-size: contain;
|
|
|
|
|
height: 24px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.empty-dash-drop-target {
|
|
|
|
|
width: 24px;
|
|
|
|
|
height: 24px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.dash-item-container > StWidget {
|
|
|
|
|
padding: 4px 8px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.dash-label { //osd tooltip
|
|
|
|
|
border-radius: 7px;
|
|
|
|
|
padding: 4px 12px;
|
|
|
|
|
color: $osd_fg_color;
|
2019-06-18 09:29:00 -04:00
|
|
|
background-color: transparentize($osd_bg_color,0.05);
|
|
|
|
|
border: 1px solid $osd_outer_borders_color;
|
theme: Replace gnome-shell-sass submodule with subtree
As the style has grown bigger and more complex, generating the different
variants from a common source has been a good decision. However given how
intertwined the theme is with gnome-shell itself, relying on a submodule
has proven to be quite painful. And as things stand right now, it is going
to get worse:
- using either pre-generated CSS or generating it at build time is
odd, and violates meson's strict separation between source- and
build directories; we are therefore considering dropping the CSS
and depending on sassc to always generate it at build time
- with the migration to gitlab, our workflow shifts decisively towards
branches; however there is no support in either git or gitlab for
handling two brances of separate repositories consecutively, which
gets particularly awkward for branches in a private namespace
With those pain points in mind, we will adjust our setup as follows:
- remove the submodule from gnome-shell and instead import the
sass as subtree
- after that, the sass sources can be changed like any other files
in the repository, and regular contributors can forget that there
was ever anything special about them
- whenever we want to update the classic style, we can push the subtree
changes and bump gnome-shell-extension's sass submodule
In other words: Updating the classic styling will become slightly more
painful, but not much and only for me; in return, everyone else can
stop fiddling with submodules (and buy me a beer).
2018-02-09 13:22:55 -05:00
|
|
|
text-align: center;
|
|
|
|
|
-x-offset: 8px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* App Vault/Grid */
|
|
|
|
|
.icon-grid {
|
|
|
|
|
spacing: 30px;
|
|
|
|
|
-shell-grid-horizontal-item-size: 136px;
|
|
|
|
|
-shell-grid-vertical-item-size: 136px;
|
|
|
|
|
|
|
|
|
|
.overview-icon { icon-size: 96px; }
|
|
|
|
|
}
|
|
|
|
|
//.app-display { spacing: 20px; }
|
|
|
|
|
|
|
|
|
|
.system-action-icon {
|
|
|
|
|
background-color: black;
|
|
|
|
|
color: white;
|
|
|
|
|
border-radius: 99px;
|
|
|
|
|
icon-size: 48px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.app-view-controls { //favorties | all toggle container
|
|
|
|
|
padding-bottom: 32px;
|
|
|
|
|
}
|
|
|
|
|
.app-view-control { //favorties | all toggle button
|
|
|
|
|
padding: 4px 32px;
|
2019-06-18 09:29:00 -04:00
|
|
|
margin: 0 4px;
|
|
|
|
|
&, &:hover, &:checked { @include button(undecorated); }
|
|
|
|
|
|
|
|
|
|
&, &:hover { color: darken($osd_fg_color, 25%); }
|
|
|
|
|
|
|
|
|
|
&:hover { box-shadow: inset 0 -2px darken($osd_fg_color, 25%); }
|
|
|
|
|
|
|
|
|
|
&:active {
|
|
|
|
|
box-shadow: inset 0 -2px $osd_fg_color;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
&:checked {
|
|
|
|
|
color: $osd_fg_color;
|
|
|
|
|
box-shadow: inset 0 -2px $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
|
|
|
&:first-child {
|
|
|
|
|
border-right-width: 0;
|
2019-06-18 09:29:00 -04:00
|
|
|
border-radius: 0;
|
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
|
|
|
|
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
|
|
|
&:last-child {
|
2019-06-18 09:29:00 -04:00
|
|
|
border-radius: 0;
|
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
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
//Icon tile
|
|
|
|
|
.search-provider-icon,
|
|
|
|
|
.list-search-result {
|
|
|
|
|
@extend %icon_tile;
|
|
|
|
|
&:focus, &:selected, &:hover {
|
|
|
|
|
background-color: transparentize($osd_fg_color,.9);
|
|
|
|
|
transition-duration: 200ms;
|
|
|
|
|
}
|
2019-07-15 18:16:32 -04:00
|
|
|
&:active, &:checked { background-color: transparentize(darken($osd_bg_color,10%),.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
|
|
|
}
|
|
|
|
|
.app-well-app,
|
|
|
|
|
.app-well-app.app-folder,
|
|
|
|
|
.show-apps,
|
|
|
|
|
.grid-search-result {
|
|
|
|
|
& .overview-icon {
|
|
|
|
|
@extend %icon_tile;
|
|
|
|
|
}
|
|
|
|
|
&:hover .overview-icon,
|
|
|
|
|
&:focus .overview-icon,
|
|
|
|
|
&:selected .overview-icon {
|
|
|
|
|
background-color: transparentize($osd_fg_color,.9);
|
|
|
|
|
transition-duration: 0ms;
|
|
|
|
|
border-image: none;
|
|
|
|
|
background-image: none;
|
|
|
|
|
}
|
2019-07-15 18:16:32 -04:00
|
|
|
&:active .overview-icon,
|
|
|
|
|
&:checked .overview-icon {
|
|
|
|
|
background-color: transparentize(darken($osd_bg_color,10%), 0.5);
|
|
|
|
|
}
|
theme: Replace gnome-shell-sass submodule with subtree
As the style has grown bigger and more complex, generating the different
variants from a common source has been a good decision. However given how
intertwined the theme is with gnome-shell itself, relying on a submodule
has proven to be quite painful. And as things stand right now, it is going
to get worse:
- using either pre-generated CSS or generating it at build time is
odd, and violates meson's strict separation between source- and
build directories; we are therefore considering dropping the CSS
and depending on sassc to always generate it at build time
- with the migration to gitlab, our workflow shifts decisively towards
branches; however there is no support in either git or gitlab for
handling two brances of separate repositories consecutively, which
gets particularly awkward for branches in a private namespace
With those pain points in mind, we will adjust our setup as follows:
- remove the submodule from gnome-shell and instead import the
sass as subtree
- after that, the sass sources can be changed like any other files
in the repository, and regular contributors can forget that there
was ever anything special about them
- whenever we want to update the classic style, we can push the subtree
changes and bump gnome-shell-extension's sass submodule
In other words: Updating the classic styling will become slightly more
painful, but not much and only for me; in return, everyone else can
stop fiddling with submodules (and buy me a beer).
2018-02-09 13:22:55 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.app-well-app-running-dot { //running apps indicator
|
|
|
|
|
width: 10px; height: 3px;
|
|
|
|
|
background-color: $selected_bg_color;
|
|
|
|
|
margin-bottom: 2px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
%icon_tile {
|
|
|
|
|
color: $osd_fg_color;
|
2019-07-02 14:29:40 -04:00
|
|
|
border-radius: $button_radius+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
|
|
|
padding: 6px;
|
|
|
|
|
border: 1px solid transparent;
|
|
|
|
|
transition-duration: 100ms;
|
|
|
|
|
text-align: center;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.app-well-app.app-folder > .overview-icon {
|
|
|
|
|
background-color: transparentize($osd_bg_color,.6);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.show-apps:checked .show-apps-icon,
|
|
|
|
|
.show-apps:focus .show-apps-icon {
|
|
|
|
|
color: white;
|
|
|
|
|
transition-duration: 100ms;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
// Collections
|
|
|
|
|
.app-folder-popup { //expanded collection
|
|
|
|
|
-arrow-border-radius: 8px;
|
2019-06-18 09:29:00 -04:00
|
|
|
-arrow-background-color: transparentize(darken($osd_bg_color,10%), 0.5);
|
theme: Replace gnome-shell-sass submodule with subtree
As the style has grown bigger and more complex, generating the different
variants from a common source has been a good decision. However given how
intertwined the theme is with gnome-shell itself, relying on a submodule
has proven to be quite painful. And as things stand right now, it is going
to get worse:
- using either pre-generated CSS or generating it at build time is
odd, and violates meson's strict separation between source- and
build directories; we are therefore considering dropping the CSS
and depending on sassc to always generate it at build time
- with the migration to gitlab, our workflow shifts decisively towards
branches; however there is no support in either git or gitlab for
handling two brances of separate repositories consecutively, which
gets particularly awkward for branches in a private namespace
With those pain points in mind, we will adjust our setup as follows:
- remove the submodule from gnome-shell and instead import the
sass as subtree
- after that, the sass sources can be changed like any other files
in the repository, and regular contributors can forget that there
was ever anything special about them
- whenever we want to update the classic style, we can push the subtree
changes and bump gnome-shell-extension's sass submodule
In other words: Updating the classic styling will become slightly more
painful, but not much and only for me; in return, everyone else can
stop fiddling with submodules (and buy me a beer).
2018-02-09 13:22:55 -05:00
|
|
|
-arrow-base: 24px;
|
|
|
|
|
-arrow-rise: 11px;
|
|
|
|
|
}
|
|
|
|
|
.app-folder-popup-bin { padding: 5px; }
|
|
|
|
|
.app-folder-icon {
|
|
|
|
|
padding: 5px;
|
|
|
|
|
spacing-rows: 5px;
|
|
|
|
|
spacing-columns: 5px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.page-indicator {
|
|
|
|
|
padding: 15px 20px;
|
|
|
|
|
|
|
|
|
|
.page-indicator-icon {
|
2018-11-16 13:44:52 -05:00
|
|
|
width: 12px;
|
|
|
|
|
height: 12px;
|
|
|
|
|
background-color: transparent;
|
|
|
|
|
border: 2px solid rgba(255, 255, 255, 0.4);
|
2019-03-10 13:56:34 -04:00
|
|
|
border-radius: 12px;
|
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
|
|
|
}
|
|
|
|
|
|
2018-11-16 13:44:52 -05:00
|
|
|
&:hover .page-indicator-icon { border-color: white; }
|
2019-03-10 13:56:34 -04:00
|
|
|
&:active .page-indicator-icon { border: none; margin: 2px; background-color: white; }
|
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
|
|
|
&:checked .page-indicator-icon,
|
2019-03-10 13:56:34 -04:00
|
|
|
&:checked:active .page-indicator-icon { background-color: white;}
|
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
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.no-frequent-applications-label { @extend %status_text; }
|
|
|
|
|
|
|
|
|
|
.app-well-app > .overview-icon.overview-icon-with-label,
|
|
|
|
|
.grid-search-result .overview-icon.overview-icon-with-label {
|
|
|
|
|
padding: 10px 8px 5px 8px;
|
|
|
|
|
spacing: 4px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Workspace pager
|
|
|
|
|
.workspace-thumbnails { //container ala dash
|
|
|
|
|
@extend %overview-panel;
|
|
|
|
|
visible-width: 32px; //amount visible before hover
|
|
|
|
|
spacing: 11px;
|
|
|
|
|
padding: 8px;
|
|
|
|
|
border-radius: 9px 0 0 9px;
|
|
|
|
|
//border-width: 1px 0 1px 1px; //fixme: can't have non unoform borders :(
|
|
|
|
|
&:rtl { border-radius: 0 9px 9px 0;}
|
|
|
|
|
|
|
|
|
|
.placeholder {
|
|
|
|
|
background-image: url("resource:///org/gnome/shell/theme/dash-placeholder.svg");
|
|
|
|
|
background-size: contain;
|
|
|
|
|
height: 24px;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
.workspace-thumbnail-indicator {
|
2019-06-18 09:29:00 -04:00
|
|
|
border: 2px solid $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
|
|
|
padding: 1px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
//Some hacks I don't even
|
|
|
|
|
.all-apps,
|
|
|
|
|
.frequent-apps > StBoxLayout {
|
|
|
|
|
// horizontal padding to make sure scrollbars or dash don't overlap content
|
|
|
|
|
padding: 0px 88px 10px 88px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
%overview-panel {
|
2019-06-18 09:29:00 -04:00
|
|
|
color: $osd_fg_color;
|
|
|
|
|
background-color: transparentize($osd_bg_color, 0.1);
|
|
|
|
|
border: 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
|
|
|
}
|
|
|
|
|
|
|
|
|
|
%status_text {
|
|
|
|
|
font-size: 2em;
|
|
|
|
|
font-weight: bold;
|
2019-06-18 09:29:00 -04:00
|
|
|
color: $osd_fg_color;
|
theme: Replace gnome-shell-sass submodule with subtree
As the style has grown bigger and more complex, generating the different
variants from a common source has been a good decision. However given how
intertwined the theme is with gnome-shell itself, relying on a submodule
has proven to be quite painful. And as things stand right now, it is going
to get worse:
- using either pre-generated CSS or generating it at build time is
odd, and violates meson's strict separation between source- and
build directories; we are therefore considering dropping the CSS
and depending on sassc to always generate it at build time
- with the migration to gitlab, our workflow shifts decisively towards
branches; however there is no support in either git or gitlab for
handling two brances of separate repositories consecutively, which
gets particularly awkward for branches in a private namespace
With those pain points in mind, we will adjust our setup as follows:
- remove the submodule from gnome-shell and instead import the
sass as subtree
- after that, the sass sources can be changed like any other files
in the repository, and regular contributors can forget that there
was ever anything special about them
- whenever we want to update the classic style, we can push the subtree
changes and bump gnome-shell-extension's sass submodule
In other words: Updating the classic styling will become slightly more
painful, but not much and only for me; in return, everyone else can
stop fiddling with submodules (and buy me a beer).
2018-02-09 13:22:55 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* NOTIFICATIONS & MESSAGE TRAY */
|
|
|
|
|
|
|
|
|
|
.url-highlighter { link-color: lighten($selected_bg_color,10%); }
|
|
|
|
|
|
|
|
|
|
// Banners
|
|
|
|
|
.notification-banner {
|
|
|
|
|
font-size: 11pt;
|
|
|
|
|
width: 34em;
|
|
|
|
|
margin: 5px;
|
2019-07-02 14:29:40 -04:00
|
|
|
border-radius: $modal_radius;
|
2019-06-18 09:29:00 -04:00
|
|
|
border: if($variant == 'light', none, $_bubble_borders_color);
|
|
|
|
|
min-height: 64px;
|
|
|
|
|
box-shadow: 0 1px 2px transparentize(black, 0.7);
|
|
|
|
|
&:hover { background: $bg_color; }
|
|
|
|
|
&, &:focus, &:active {
|
|
|
|
|
background-color: $bg_color;
|
|
|
|
|
.message-title { color: $fg_color }
|
|
|
|
|
.message-content { color: $fg_color; }
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.message-icon-bin > StIcon {
|
|
|
|
|
color: $fg_color;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
StEntry { @extend %bubble-entry; }
|
|
|
|
|
|
|
|
|
|
.notification-icon { padding: 5px; }
|
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
|
|
|
.notification-content { padding: 5px; spacing: 5px; }
|
|
|
|
|
.secondary-icon { icon-size: 1.09em; }
|
|
|
|
|
.notification-actions {
|
2019-06-18 09:29:00 -04:00
|
|
|
padding-top: 0;
|
|
|
|
|
color: $fg_color;
|
|
|
|
|
border-top: 1px solid $_bubble_borders_color;
|
|
|
|
|
spacing: 0px;
|
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
|
|
|
}
|
|
|
|
|
.notification-button {
|
2019-06-18 09:29:00 -04:00
|
|
|
@extend %bubble_button;
|
|
|
|
|
&:focus { box-shadow: none; }
|
|
|
|
|
padding: 0 16px;
|
|
|
|
|
min-height: 35px;
|
|
|
|
|
border: 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
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
.summary-source-counter {
|
|
|
|
|
font-size: 10pt;
|
|
|
|
|
font-weight: bold;
|
|
|
|
|
height: 1.6em; width: 1.6em;
|
|
|
|
|
-shell-counter-overlap-x: 3px;
|
|
|
|
|
-shell-counter-overlap-y: 3px;
|
|
|
|
|
background-color: $selected_bg_color;
|
|
|
|
|
color: $selected_fg_color;
|
2019-06-18 09:29:00 -04:00
|
|
|
border: 2px solid $fg_color;
|
theme: Replace gnome-shell-sass submodule with subtree
As the style has grown bigger and more complex, generating the different
variants from a common source has been a good decision. However given how
intertwined the theme is with gnome-shell itself, relying on a submodule
has proven to be quite painful. And as things stand right now, it is going
to get worse:
- using either pre-generated CSS or generating it at build time is
odd, and violates meson's strict separation between source- and
build directories; we are therefore considering dropping the CSS
and depending on sassc to always generate it at build time
- with the migration to gitlab, our workflow shifts decisively towards
branches; however there is no support in either git or gitlab for
handling two brances of separate repositories consecutively, which
gets particularly awkward for branches in a private namespace
With those pain points in mind, we will adjust our setup as follows:
- remove the submodule from gnome-shell and instead import the
sass as subtree
- after that, the sass sources can be changed like any other files
in the repository, and regular contributors can forget that there
was ever anything special about them
- whenever we want to update the classic style, we can push the subtree
changes and bump gnome-shell-extension's sass submodule
In other words: Updating the classic styling will become slightly more
painful, but not much and only for me; in return, everyone else can
stop fiddling with submodules (and buy me a beer).
2018-02-09 13:22:55 -05:00
|
|
|
box-shadow: 0 2px 2px rgba(0,0,0,0.5);
|
|
|
|
|
border-radius: 0.9em; // should be 0.8 but whatever; wish I could do 50%;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.secondary-icon { icon-size: 1.09em; }
|
|
|
|
|
|
|
|
|
|
//chat bubbles
|
|
|
|
|
.chat-body { spacing: 5px; }
|
|
|
|
|
.chat-response { margin: 5px; }
|
|
|
|
|
.chat-log-message { color: darken($fg_color,10%); }
|
|
|
|
|
.chat-new-group { padding-top: 1em; }
|
|
|
|
|
.chat-received {
|
|
|
|
|
padding-left: 4px;
|
|
|
|
|
&:rtl { padding-left: 0px; padding-right: 4px; }
|
|
|
|
|
}
|
|
|
|
|
.chat-sent {
|
|
|
|
|
padding-left: 18pt;
|
2019-06-18 09:29:00 -04:00
|
|
|
color: lighten($fg_color, 15%);
|
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
|
|
|
&:rtl { padding-left: 0; padding-right: 18pt; }
|
|
|
|
|
}
|
|
|
|
|
.chat-meta-message {
|
|
|
|
|
padding-left: 4px;
|
|
|
|
|
font-size: 9pt;
|
|
|
|
|
font-weight: bold;
|
2019-06-18 09:29:00 -04:00
|
|
|
color: lighten($fg_color,18%);
|
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
|
|
|
&:rtl { padding-left: 0; padding-right: 4px; }
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
//hotplug
|
|
|
|
|
.hotplug-transient-box {
|
|
|
|
|
spacing: 6px;
|
|
|
|
|
padding: 2px 72px 2px 12px;
|
|
|
|
|
}
|
|
|
|
|
.hotplug-notification-item {
|
2019-06-18 09:29:00 -04:00
|
|
|
@extend %bubble_button;
|
|
|
|
|
border: none; 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
|
|
|
padding: 2px 10px;
|
|
|
|
|
&:focus { padding: 1px 71px 1px 11px; }
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.hotplug-notification-item-icon {
|
|
|
|
|
icon-size: 24px;
|
|
|
|
|
padding: 2px 5px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.hotplug-resident-box { spacing: 8px; }
|
|
|
|
|
|
|
|
|
|
.hotplug-resident-mount {
|
|
|
|
|
spacing: 8px;
|
|
|
|
|
border-radius: 4px;
|
2019-06-18 09:29:00 -04:00
|
|
|
&:hover { background-color: $_hover_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
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.hotplug-resident-mount-label {
|
|
|
|
|
color: inherit;
|
|
|
|
|
padding-left: 6px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.hotplug-resident-mount-icon {
|
|
|
|
|
icon-size: 24px;
|
|
|
|
|
padding-left: 6px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.hotplug-resident-eject-icon {
|
|
|
|
|
icon-size: 16px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.hotplug-resident-eject-button {
|
|
|
|
|
padding: 7px;
|
|
|
|
|
border-radius: 5px;
|
|
|
|
|
color: pink;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Eeeky things */
|
|
|
|
|
|
|
|
|
|
//magnifier
|
|
|
|
|
|
|
|
|
|
.magnifier-zoom-region {
|
|
|
|
|
border: 2px solid $selected_bg_color;
|
|
|
|
|
&.full-screen { border-width: 0; }
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
//Keyboard
|
|
|
|
|
/* On-screen Keyboard */
|
|
|
|
|
.word-suggestions {
|
|
|
|
|
font-size: 14pt;
|
|
|
|
|
spacing: 12px;
|
|
|
|
|
min-height: 20pt;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#keyboard {
|
|
|
|
|
background-color: transparentize($osd_bg_color, 0.3);
|
2017-12-22 10:02:51 -05:00
|
|
|
|
|
|
|
|
.page-indicator {
|
|
|
|
|
padding: 4px 4px;
|
|
|
|
|
|
|
|
|
|
.page-indicator-icon {
|
|
|
|
|
width: 6px;
|
|
|
|
|
height: 6px
|
|
|
|
|
}
|
|
|
|
|
}
|
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
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.key-container {
|
|
|
|
|
padding: 4px;
|
|
|
|
|
spacing: 4px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.keyboard-key {
|
2019-07-02 14:29:40 -04:00
|
|
|
$_key_bg: opacify(lighten($osd_bg_color, 9%), 1);
|
|
|
|
|
background-color: $_key_bg;
|
2019-01-21 15:34:27 -05:00
|
|
|
min-height: 1.2em;
|
|
|
|
|
min-width: 1.2em;
|
2018-02-15 12:57:19 -05:00
|
|
|
font-size: 16pt;
|
2019-07-02 14:29:40 -04:00
|
|
|
border-radius: $button_radius;
|
|
|
|
|
border: 1px solid $osd_outer_borders_color;
|
|
|
|
|
color: $osd_fg_color;
|
theme: Replace gnome-shell-sass submodule with subtree
As the style has grown bigger and more complex, generating the different
variants from a common source has been a good decision. However given how
intertwined the theme is with gnome-shell itself, relying on a submodule
has proven to be quite painful. And as things stand right now, it is going
to get worse:
- using either pre-generated CSS or generating it at build time is
odd, and violates meson's strict separation between source- and
build directories; we are therefore considering dropping the CSS
and depending on sassc to always generate it at build time
- with the migration to gitlab, our workflow shifts decisively towards
branches; however there is no support in either git or gitlab for
handling two brances of separate repositories consecutively, which
gets particularly awkward for branches in a private namespace
With those pain points in mind, we will adjust our setup as follows:
- remove the submodule from gnome-shell and instead import the
sass as subtree
- after that, the sass sources can be changed like any other files
in the repository, and regular contributors can forget that there
was ever anything special about them
- whenever we want to update the classic style, we can push the subtree
changes and bump gnome-shell-extension's sass submodule
In other words: Updating the classic styling will become slightly more
painful, but not much and only for me; in return, everyone else can
stop fiddling with submodules (and buy me a beer).
2018-02-09 13:22:55 -05:00
|
|
|
&:focus { @include button(focus); }
|
2019-07-02 14:29:40 -04:00
|
|
|
&:hover, &:checked { background-color: lighten($_key_bg, 3%); }
|
|
|
|
|
&:active { background-color: darken($_key_bg, 2%); }
|
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
|
|
|
&:grayed { //FIXME
|
|
|
|
|
background-color: $osd_bg_color;
|
|
|
|
|
color: $osd_fg_color;
|
|
|
|
|
border-color: $osd_borders_color;
|
|
|
|
|
}
|
|
|
|
|
&.default-key {
|
2019-07-02 14:29:40 -04:00
|
|
|
$_default_key_bg: opacify($osd_bg_color, 1);
|
|
|
|
|
border-color: $osd_outer_borders_color;
|
|
|
|
|
background-color: $_default_key_bg;
|
2018-02-15 12:57:19 -05:00
|
|
|
background-size: 20px;
|
2019-07-02 14:29:40 -04:00
|
|
|
&:hover, &:checked { background-color: lighten($_default_key_bg, 3%); }
|
|
|
|
|
&:active { background-color: darken($_default_key_bg, 2%); }
|
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
|
|
|
}
|
|
|
|
|
&.enter-key {
|
2019-07-02 14:29:40 -04:00
|
|
|
border-color: lighten($selected_bg_color, 5%);
|
|
|
|
|
background-color: $selected_bg_color;
|
2018-02-15 12:57:19 -05:00
|
|
|
background-image: url("resource:///org/gnome/shell/theme/key-enter.svg");
|
2019-07-02 14:29:40 -04:00
|
|
|
&:hover, &:checked { background-color: lighten($selected_bg_color, 3%); }
|
|
|
|
|
&:active { background-color: darken($selected_bg_color, 2%); }
|
2018-02-15 12:57:19 -05:00
|
|
|
}
|
|
|
|
|
&.shift-key-lowercase {
|
|
|
|
|
background-image: url("resource:///org/gnome/shell/theme/key-shift.svg");
|
|
|
|
|
}
|
|
|
|
|
&.shift-key-uppercase {
|
|
|
|
|
background-image: url("resource:///org/gnome/shell/theme/key-shift-uppercase.svg");
|
|
|
|
|
}
|
|
|
|
|
&.shift-key-uppercase:latched {
|
|
|
|
|
background-image: url("resource:///org/gnome/shell/theme/key-shift-latched-uppercase.svg");
|
|
|
|
|
}
|
|
|
|
|
&.hide-key {
|
|
|
|
|
background-image: url("resource:///org/gnome/shell/theme/key-hide.svg");
|
|
|
|
|
}
|
|
|
|
|
&.layout-key {
|
|
|
|
|
background-image: url("resource:///org/gnome/shell/theme/key-layout.svg");
|
theme: Replace gnome-shell-sass submodule with subtree
As the style has grown bigger and more complex, generating the different
variants from a common source has been a good decision. However given how
intertwined the theme is with gnome-shell itself, relying on a submodule
has proven to be quite painful. And as things stand right now, it is going
to get worse:
- using either pre-generated CSS or generating it at build time is
odd, and violates meson's strict separation between source- and
build directories; we are therefore considering dropping the CSS
and depending on sassc to always generate it at build time
- with the migration to gitlab, our workflow shifts decisively towards
branches; however there is no support in either git or gitlab for
handling two brances of separate repositories consecutively, which
gets particularly awkward for branches in a private namespace
With those pain points in mind, we will adjust our setup as follows:
- remove the submodule from gnome-shell and instead import the
sass as subtree
- after that, the sass sources can be changed like any other files
in the repository, and regular contributors can forget that there
was ever anything special about them
- whenever we want to update the classic style, we can push the subtree
changes and bump gnome-shell-extension's sass submodule
In other words: Updating the classic styling will become slightly more
painful, but not much and only for me; in return, everyone else can
stop fiddling with submodules (and buy me a beer).
2018-02-09 13:22:55 -05:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.keyboard-subkeys { //long press on a key popup
|
|
|
|
|
color: white;
|
|
|
|
|
-arrow-border-radius: 10px;
|
|
|
|
|
-arrow-background-color: transparentize($osd_bg_color, 0.3);
|
|
|
|
|
-arrow-border-width: 2px;
|
2019-06-18 09:29:00 -04:00
|
|
|
-arrow-border-color: $osd_outer_borders_color;
|
theme: Replace gnome-shell-sass submodule with subtree
As the style has grown bigger and more complex, generating the different
variants from a common source has been a good decision. However given how
intertwined the theme is with gnome-shell itself, relying on a submodule
has proven to be quite painful. And as things stand right now, it is going
to get worse:
- using either pre-generated CSS or generating it at build time is
odd, and violates meson's strict separation between source- and
build directories; we are therefore considering dropping the CSS
and depending on sassc to always generate it at build time
- with the migration to gitlab, our workflow shifts decisively towards
branches; however there is no support in either git or gitlab for
handling two brances of separate repositories consecutively, which
gets particularly awkward for branches in a private namespace
With those pain points in mind, we will adjust our setup as follows:
- remove the submodule from gnome-shell and instead import the
sass as subtree
- after that, the sass sources can be changed like any other files
in the repository, and regular contributors can forget that there
was ever anything special about them
- whenever we want to update the classic style, we can push the subtree
changes and bump gnome-shell-extension's sass submodule
In other words: Updating the classic styling will become slightly more
painful, but not much and only for me; in return, everyone else can
stop fiddling with submodules (and buy me a beer).
2018-02-09 13:22:55 -05:00
|
|
|
-arrow-base: 20px;
|
|
|
|
|
-arrow-rise: 10px;
|
|
|
|
|
-boxpointer-gap: 5px;
|
|
|
|
|
}
|
|
|
|
|
|
2017-12-22 10:02:51 -05:00
|
|
|
.emoji-page {
|
|
|
|
|
.keyboard-key {
|
|
|
|
|
background-color: transparent;
|
|
|
|
|
border: none;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.emoji-panel {
|
|
|
|
|
.keyboard-key:latched {
|
2019-07-02 14:29:40 -04:00
|
|
|
border-color: lighten($selected_bg_color, 5%);
|
|
|
|
|
background-color: $selected_bg_color;
|
2017-12-22 10:02:51 -05: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 13:22:55 -05:00
|
|
|
// IBus Candidate Popup
|
|
|
|
|
|
|
|
|
|
.candidate-popup-content {
|
|
|
|
|
padding: 0.5em;
|
|
|
|
|
spacing: 0.3em;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.candidate-index {
|
|
|
|
|
padding: 0 0.5em 0 0;
|
|
|
|
|
color: darken($fg_color,10%);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.candidate-box {
|
|
|
|
|
padding: 0.3em 0.5em 0.3em 0.5em;
|
|
|
|
|
border-radius: 4px;
|
|
|
|
|
&:selected,&:hover { background-color: $selected_bg_color; color: $selected_fg_color; }
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.candidate-page-button-box {
|
|
|
|
|
height: 2em;
|
|
|
|
|
.vertical & { padding-top: 0.5em; }
|
|
|
|
|
.horizontal & { padding-left: 0.5em; }
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.candidate-page-button {
|
|
|
|
|
padding: 4px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.candidate-page-button-previous { border-radius: 4px 0px 0px 4px; border-right-width: 0; }
|
|
|
|
|
.candidate-page-button-next { border-radius: 0px 4px 4px 0px; }
|
|
|
|
|
.candidate-page-button-icon { icon-size: 1em; }
|
|
|
|
|
|
|
|
|
|
/* Auth Dialogs & Screen Shield */
|
|
|
|
|
|
2019-02-05 11:28:41 -05:00
|
|
|
.user-icon {
|
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
|
|
|
background-size: contain;
|
|
|
|
|
color: $osd_fg_color;
|
2019-02-05 11:28:41 -05:00
|
|
|
border-radius: 99px;
|
theme: Replace gnome-shell-sass submodule with subtree
As the style has grown bigger and more complex, generating the different
variants from a common source has been a good decision. However given how
intertwined the theme is with gnome-shell itself, relying on a submodule
has proven to be quite painful. And as things stand right now, it is going
to get worse:
- using either pre-generated CSS or generating it at build time is
odd, and violates meson's strict separation between source- and
build directories; we are therefore considering dropping the CSS
and depending on sassc to always generate it at build time
- with the migration to gitlab, our workflow shifts decisively towards
branches; however there is no support in either git or gitlab for
handling two brances of separate repositories consecutively, which
gets particularly awkward for branches in a private namespace
With those pain points in mind, we will adjust our setup as follows:
- remove the submodule from gnome-shell and instead import the
sass as subtree
- after that, the sass sources can be changed like any other files
in the repository, and regular contributors can forget that there
was ever anything special about them
- whenever we want to update the classic style, we can push the subtree
changes and bump gnome-shell-extension's sass submodule
In other words: Updating the classic styling will become slightly more
painful, but not much and only for me; in return, everyone else can
stop fiddling with submodules (and buy me a beer).
2018-02-09 13:22:55 -05:00
|
|
|
&:hover {
|
|
|
|
|
color: lighten($osd_fg_color,30%);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// LOGIN DIALOG
|
|
|
|
|
|
|
|
|
|
.login-dialog-banner-view {
|
|
|
|
|
padding-top: 24px;
|
|
|
|
|
max-width: 23em;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.login-dialog {
|
|
|
|
|
//reset
|
|
|
|
|
border: none;
|
|
|
|
|
background-color: transparent;
|
|
|
|
|
|
2019-06-18 09:29:00 -04:00
|
|
|
$_gdm_fg: #f6f5f4;
|
|
|
|
|
$_gdm_bg: lighten(#2e3436, 19%);
|
|
|
|
|
|
|
|
|
|
StEntry {
|
|
|
|
|
@extend %search_entry;
|
2019-07-02 14:29:40 -04:00
|
|
|
border-radius: $button_radius;
|
2019-06-18 09:29:00 -04:00
|
|
|
@if $variant=='dark' {
|
|
|
|
|
$_gdm_entry_bg: transparentize(lighten(desaturate(#241f31, 20%), 2%), 0.5);
|
|
|
|
|
background-color: $_gdm_entry_bg;
|
|
|
|
|
border-color: $_gdm_entry_bg;
|
|
|
|
|
color: $osd_fg_color;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
theme: Replace gnome-shell-sass submodule with subtree
As the style has grown bigger and more complex, generating the different
variants from a common source has been a good decision. However given how
intertwined the theme is with gnome-shell itself, relying on a submodule
has proven to be quite painful. And as things stand right now, it is going
to get worse:
- using either pre-generated CSS or generating it at build time is
odd, and violates meson's strict separation between source- and
build directories; we are therefore considering dropping the CSS
and depending on sassc to always generate it at build time
- with the migration to gitlab, our workflow shifts decisively towards
branches; however there is no support in either git or gitlab for
handling two brances of separate repositories consecutively, which
gets particularly awkward for branches in a private namespace
With those pain points in mind, we will adjust our setup as follows:
- remove the submodule from gnome-shell and instead import the
sass as subtree
- after that, the sass sources can be changed like any other files
in the repository, and regular contributors can forget that there
was ever anything special about them
- whenever we want to update the classic style, we can push the subtree
changes and bump gnome-shell-extension's sass submodule
In other words: Updating the classic styling will become slightly more
painful, but not much and only for me; in return, everyone else can
stop fiddling with submodules (and buy me a beer).
2018-02-09 13:22:55 -05:00
|
|
|
.modal-dialog-button-box { spacing: 3px; }
|
|
|
|
|
.modal-dialog-button {
|
2019-06-18 09:29:00 -04:00
|
|
|
padding: 4px 18px;
|
|
|
|
|
box-shadow: 0 1px 3px transparentize($shadow_color, 0.02);
|
|
|
|
|
background-color: $_gdm_bg;
|
|
|
|
|
border-color: $_gdm_bg;
|
|
|
|
|
color: $_gdm_fg;
|
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
|
|
|
$_hover_c: lighten($_gdm_bg, 5%);
|
|
|
|
|
&:hover, &:focus {
|
|
|
|
|
background-color: $_hover_c;
|
|
|
|
|
border-color: $_hover_c;
|
|
|
|
|
}
|
|
|
|
|
&:active {
|
|
|
|
|
$_active_c: darken($_gdm_bg, 5%);
|
|
|
|
|
box-shadow: none;
|
|
|
|
|
background-color: $_active_c;
|
|
|
|
|
border-color: $_active_c;
|
|
|
|
|
}
|
|
|
|
|
&:insensitive {
|
|
|
|
|
@include button(insensitive);
|
|
|
|
|
border-color: darken($_gdm_bg, 5%);
|
|
|
|
|
background-color: darken($_gdm_bg, 5%);
|
|
|
|
|
color: transparentize($_gdm_fg, 0.3);
|
|
|
|
|
}
|
|
|
|
|
&:default {
|
|
|
|
|
@include button(normal, $c:$selected_bg_color, $tc:$selected_fg_color);
|
|
|
|
|
border-color: $selected_bg_color;
|
|
|
|
|
&:hover, &:focus {
|
|
|
|
|
@include button(hover,$c:$selected_bg_color, $tc:$selected_fg_color);
|
|
|
|
|
$_def_hover_c: lighten($selected_bg_color, 5%);
|
|
|
|
|
background-color: $_def_hover_c;
|
|
|
|
|
border-color: $_def_hover_c;
|
|
|
|
|
}
|
|
|
|
|
&:active {
|
|
|
|
|
@include button(active,$c:$selected_bg_color, $tc:$selected_fg_color);
|
|
|
|
|
$_def_active_c: darken($selected_bg_color, 5%);
|
|
|
|
|
background-color: $_def_active_c;
|
|
|
|
|
border-color: $_def_active_c;
|
|
|
|
|
}
|
|
|
|
|
&:insensitive {
|
|
|
|
|
@include button(insensitive);
|
|
|
|
|
border-color: darken($selected_bg_color, 10%);
|
|
|
|
|
background-color: darken($selected_bg_color, 10%);
|
|
|
|
|
color: transparentize($selected_fg_color, 0.3);
|
|
|
|
|
}
|
theme: Replace gnome-shell-sass submodule with subtree
As the style has grown bigger and more complex, generating the different
variants from a common source has been a good decision. However given how
intertwined the theme is with gnome-shell itself, relying on a submodule
has proven to be quite painful. And as things stand right now, it is going
to get worse:
- using either pre-generated CSS or generating it at build time is
odd, and violates meson's strict separation between source- and
build directories; we are therefore considering dropping the CSS
and depending on sassc to always generate it at build time
- with the migration to gitlab, our workflow shifts decisively towards
branches; however there is no support in either git or gitlab for
handling two brances of separate repositories consecutively, which
gets particularly awkward for branches in a private namespace
With those pain points in mind, we will adjust our setup as follows:
- remove the submodule from gnome-shell and instead import the
sass as subtree
- after that, the sass sources can be changed like any other files
in the repository, and regular contributors can forget that there
was ever anything special about them
- whenever we want to update the classic style, we can push the subtree
changes and bump gnome-shell-extension's sass submodule
In other words: Updating the classic styling will become slightly more
painful, but not much and only for me; in return, everyone else can
stop fiddling with submodules (and buy me a beer).
2018-02-09 13:22:55 -05:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.login-dialog-logo-bin { padding: 24px 0px; }
|
|
|
|
|
.login-dialog-banner { color: darken($osd_fg_color,10%); }
|
|
|
|
|
.login-dialog-button-box { spacing: 5px; }
|
|
|
|
|
.login-dialog-message-warning { color: $warning_color; }
|
|
|
|
|
.login-dialog-message-hint { padding-top: 0; padding-bottom: 20px; }
|
|
|
|
|
.login-dialog-user-selection-box { padding: 100px 0px; }
|
|
|
|
|
.login-dialog-not-listed-label {
|
|
|
|
|
padding-left: 2px;
|
|
|
|
|
.login-dialog-not-listed-button:focus &,
|
|
|
|
|
.login-dialog-not-listed-button:hover & {
|
|
|
|
|
color: $osd_fg_color;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
.login-dialog-not-listed-label {
|
|
|
|
|
font-size: 90%;
|
|
|
|
|
font-weight: bold;
|
|
|
|
|
color: darken($osd_fg_color,30%);
|
|
|
|
|
padding-top: 1em;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.login-dialog-user-list-view { -st-vfade-offset: 1em; }
|
|
|
|
|
.login-dialog-user-list {
|
|
|
|
|
spacing: 12px;
|
|
|
|
|
width: 23em;
|
|
|
|
|
&:expanded .login-dialog-user-list-item:selected { background-color: $selected_bg_color; color: $selected_fg_color; }
|
|
|
|
|
&:expanded .login-dialog-user-list-item:logged-in { border-right: 2px solid $selected_bg_color; }
|
|
|
|
|
}
|
|
|
|
|
.login-dialog-user-list-item {
|
|
|
|
|
border-radius: 5px;
|
2018-04-07 15:23:22 -04:00
|
|
|
padding: 6px;
|
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
|
|
|
color: darken($osd_fg_color,30%);
|
2018-04-08 06:25:32 -04:00
|
|
|
&:ltr .user-widget { padding-right: 1em; }
|
|
|
|
|
&:rtl .user-widget { padding-left: 1em; }
|
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
|
|
|
.login-dialog-timed-login-indicator {
|
|
|
|
|
height: 2px;
|
2018-04-07 15:23:22 -04:00
|
|
|
margin-top: 6px;
|
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
|
|
|
background-color: $osd_fg_color;
|
|
|
|
|
}
|
|
|
|
|
&:focus .login-dialog-timed-login-indicator { background-color: $selected_fg_color; }
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.login-dialog-username,
|
|
|
|
|
.user-widget-label {
|
|
|
|
|
color: $osd_fg_color;
|
|
|
|
|
font-size: 120%;
|
|
|
|
|
font-weight: bold;
|
|
|
|
|
text-align: left;
|
|
|
|
|
padding-left: 15px;
|
|
|
|
|
}
|
|
|
|
|
.user-widget-label {
|
2018-04-08 06:25:32 -04:00
|
|
|
&:ltr { padding-left: 14px; }
|
|
|
|
|
&:rtl { padding-right: 14px; }
|
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
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.login-dialog-prompt-layout {
|
|
|
|
|
padding-top: 24px;
|
|
|
|
|
padding-bottom: 12px;
|
|
|
|
|
spacing: 8px;
|
|
|
|
|
width: 23em;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.login-dialog-prompt-label {
|
|
|
|
|
color: darken($osd_fg_color, 20%);
|
|
|
|
|
font-size: 110%;
|
|
|
|
|
padding-top: 1em;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.login-dialog-session-list-button StIcon {
|
|
|
|
|
icon-size: 1.25em;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.login-dialog-session-list-button {
|
|
|
|
|
color: darken($osd_fg_color,30%);
|
|
|
|
|
&:hover,&:focus { color: $osd_fg_color; }
|
|
|
|
|
&:active { color: darken($osd_fg_color, 50%); }
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
//SCREEN SHIELD
|
|
|
|
|
|
2019-06-18 09:29:00 -04:00
|
|
|
$_screenshield_shadow: 0px 0px 6px rgba(0, 0, 0, 0.726);
|
|
|
|
|
|
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
|
|
|
.screen-shield-arrows {
|
|
|
|
|
padding-bottom: 3em;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.screen-shield-arrows Gjs_Arrow {
|
|
|
|
|
color: white;
|
|
|
|
|
width: 80px;
|
|
|
|
|
height: 48px;
|
|
|
|
|
-arrow-thickness: 12px;
|
2019-06-18 09:29:00 -04:00
|
|
|
-arrow-shadow: $_screenshield_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
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.screen-shield-clock {
|
|
|
|
|
color: white;
|
2019-06-18 09:29:00 -04:00
|
|
|
text-shadow: $_screenshield_shadow;
|
2018-02-14 10:42:56 -05:00
|
|
|
font-weight: bold;
|
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-align: center;
|
|
|
|
|
padding-bottom: 1.5em;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.screen-shield-clock-time {
|
|
|
|
|
font-size: 72pt;
|
2019-06-18 09:29:00 -04:00
|
|
|
text-shadow: $_screenshield_shadow;
|
2018-05-17 10:45:02 -04:00
|
|
|
font-feature-settings: "tnum";
|
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
|
|
|
}
|
|
|
|
|
|
2018-02-14 10:42:56 -05:00
|
|
|
.screen-shield-clock-date {
|
2018-02-14 10:42:56 -05:00
|
|
|
font-size: 28pt;
|
2018-02-14 10:42:56 -05:00
|
|
|
font-weight: normal;
|
|
|
|
|
}
|
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
|
|
|
|
|
|
|
|
.screen-shield-notifications-container {
|
|
|
|
|
spacing: 6px;
|
|
|
|
|
width: 30em;
|
|
|
|
|
background-color: transparent;
|
|
|
|
|
max-height: 500px;
|
|
|
|
|
.summary-notification-stack-scrollview {
|
|
|
|
|
padding-top: 0;
|
|
|
|
|
padding-bottom: 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.notification,
|
|
|
|
|
.screen-shield-notification-source {
|
|
|
|
|
padding: 12px 6px;
|
2019-06-18 09:29:00 -04:00
|
|
|
border: 1px solid $osd_outer_borders_color;
|
theme: Replace gnome-shell-sass submodule with subtree
As the style has grown bigger and more complex, generating the different
variants from a common source has been a good decision. However given how
intertwined the theme is with gnome-shell itself, relying on a submodule
has proven to be quite painful. And as things stand right now, it is going
to get worse:
- using either pre-generated CSS or generating it at build time is
odd, and violates meson's strict separation between source- and
build directories; we are therefore considering dropping the CSS
and depending on sassc to always generate it at build time
- with the migration to gitlab, our workflow shifts decisively towards
branches; however there is no support in either git or gitlab for
handling two brances of separate repositories consecutively, which
gets particularly awkward for branches in a private namespace
With those pain points in mind, we will adjust our setup as follows:
- remove the submodule from gnome-shell and instead import the
sass as subtree
- after that, the sass sources can be changed like any other files
in the repository, and regular contributors can forget that there
was ever anything special about them
- whenever we want to update the classic style, we can push the subtree
changes and bump gnome-shell-extension's sass submodule
In other words: Updating the classic styling will become slightly more
painful, but not much and only for me; in return, everyone else can
stop fiddling with submodules (and buy me a beer).
2018-02-09 13:22:55 -05:00
|
|
|
background-color: transparentize($osd_bg_color,0.5);
|
2019-06-18 09:29:00 -04:00
|
|
|
color: $osd_fg_color;
|
theme: Replace gnome-shell-sass submodule with subtree
As the style has grown bigger and more complex, generating the different
variants from a common source has been a good decision. However given how
intertwined the theme is with gnome-shell itself, relying on a submodule
has proven to be quite painful. And as things stand right now, it is going
to get worse:
- using either pre-generated CSS or generating it at build time is
odd, and violates meson's strict separation between source- and
build directories; we are therefore considering dropping the CSS
and depending on sassc to always generate it at build time
- with the migration to gitlab, our workflow shifts decisively towards
branches; however there is no support in either git or gitlab for
handling two brances of separate repositories consecutively, which
gets particularly awkward for branches in a private namespace
With those pain points in mind, we will adjust our setup as follows:
- remove the submodule from gnome-shell and instead import the
sass as subtree
- after that, the sass sources can be changed like any other files
in the repository, and regular contributors can forget that there
was ever anything special about them
- whenever we want to update the classic style, we can push the subtree
changes and bump gnome-shell-extension's sass submodule
In other words: Updating the classic styling will become slightly more
painful, but not much and only for me; in return, everyone else can
stop fiddling with submodules (and buy me a beer).
2018-02-09 13:22:55 -05:00
|
|
|
border-radius: 4px;
|
|
|
|
|
}
|
|
|
|
|
.notification { margin-right: 15px; } //compensate for space allocated to the scrollbar
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
.screen-shield-notification-label {
|
|
|
|
|
font-weight: bold;
|
|
|
|
|
padding: 0px 0px 0px 12px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.screen-shield-notification-count-text { padding: 0px 0px 0px 12px; }
|
|
|
|
|
|
2019-06-18 09:29:00 -04:00
|
|
|
#panel.lock-screen { background-color: transparentize($osd_bg_color, 0.5); }
|
theme: Replace gnome-shell-sass submodule with subtree
As the style has grown bigger and more complex, generating the different
variants from a common source has been a good decision. However given how
intertwined the theme is with gnome-shell itself, relying on a submodule
has proven to be quite painful. And as things stand right now, it is going
to get worse:
- using either pre-generated CSS or generating it at build time is
odd, and violates meson's strict separation between source- and
build directories; we are therefore considering dropping the CSS
and depending on sassc to always generate it at build time
- with the migration to gitlab, our workflow shifts decisively towards
branches; however there is no support in either git or gitlab for
handling two brances of separate repositories consecutively, which
gets particularly awkward for branches in a private namespace
With those pain points in mind, we will adjust our setup as follows:
- remove the submodule from gnome-shell and instead import the
sass as subtree
- after that, the sass sources can be changed like any other files
in the repository, and regular contributors can forget that there
was ever anything special about them
- whenever we want to update the classic style, we can push the subtree
changes and bump gnome-shell-extension's sass submodule
In other words: Updating the classic styling will become slightly more
painful, but not much and only for me; in return, everyone else can
stop fiddling with submodules (and buy me a beer).
2018-02-09 13:22:55 -05:00
|
|
|
|
|
|
|
|
.screen-shield-background { //just the shadow, really
|
|
|
|
|
background: black;
|
|
|
|
|
box-shadow: 0px 2px 4px transparentize(black,0.6);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#lockDialogGroup {
|
2019-06-18 09:29:00 -04:00
|
|
|
background: lighten(#2e3436, 8%) url(resource:///org/gnome/shell/theme/noise-texture.png);
|
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
|
|
|
background-repeat: repeat;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#screenShieldNotifications {
|
|
|
|
|
StButton#vhandle, StButton#hhandle {
|
|
|
|
|
background-color: transparentize($bg_color,0.7);
|
|
|
|
|
&:hover, &:focus { background-color: transparentize($bg_color,0.5); }
|
|
|
|
|
&:active { background-color: transparentize($selected_bg_color,0.5); }
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
// Looking Glass
|
|
|
|
|
#LookingGlassDialog {
|
|
|
|
|
background-color: rgba(0,0,0,0.80);
|
|
|
|
|
spacing: 4px;
|
|
|
|
|
padding: 4px;
|
|
|
|
|
border: 2px solid grey;
|
|
|
|
|
border-radius: 4px;
|
|
|
|
|
& > #Toolbar {
|
|
|
|
|
border: 1px solid grey;
|
|
|
|
|
border-radius: 4px;
|
|
|
|
|
}
|
|
|
|
|
.labels { spacing: 4px; }
|
|
|
|
|
.notebook-tab {
|
|
|
|
|
-natural-hpadding: 12px;
|
|
|
|
|
-minimum-hpadding: 6px;
|
|
|
|
|
font-weight: bold;
|
|
|
|
|
color: #ccc;
|
|
|
|
|
transition-duration: 100ms;
|
|
|
|
|
padding-left: .3em;
|
|
|
|
|
padding-right: .3em;
|
|
|
|
|
&:hover {
|
|
|
|
|
color: white;
|
|
|
|
|
text-shadow: black 0px 2px 2px;
|
|
|
|
|
}
|
|
|
|
|
&:selected {
|
|
|
|
|
border-bottom-width: 2px;
|
|
|
|
|
border-color: lighten($selected_bg_color,5%);
|
|
|
|
|
color: white;
|
|
|
|
|
text-shadow: black 0px 2px 2px;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
StBoxLayout#EvalBox { padding: 4px; spacing: 4px; }
|
|
|
|
|
StBoxLayout#ResultsArea { spacing: 4px; }
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.lg-dialog {
|
|
|
|
|
StEntry {
|
|
|
|
|
selection-background-color: #bbbbbb;
|
|
|
|
|
selected-color: #333333;
|
|
|
|
|
}
|
|
|
|
|
.shell-link {
|
|
|
|
|
color: #999999;
|
|
|
|
|
&:hover { color: #dddddd; }
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.lg-completions-text {
|
|
|
|
|
font-size: .9em;
|
|
|
|
|
font-style: italic;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.lg-obj-inspector-title {
|
|
|
|
|
spacing: 4px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.lg-obj-inspector-button {
|
|
|
|
|
border: 1px solid gray;
|
|
|
|
|
padding: 4px;
|
|
|
|
|
border-radius: 4px;
|
|
|
|
|
&:hover { border: 1px solid #ffffff; }
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#lookingGlassExtensions { padding: 4px; }
|
|
|
|
|
|
|
|
|
|
.lg-extensions-list {
|
|
|
|
|
padding: 4px;
|
|
|
|
|
spacing: 6px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.lg-extension {
|
|
|
|
|
border: 1px solid #6f6f6f;
|
|
|
|
|
border-radius: 4px;
|
|
|
|
|
padding: 4px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.lg-extension-name {
|
|
|
|
|
font-weight: bold;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.lg-extension-meta {
|
|
|
|
|
spacing: 6px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#LookingGlassPropertyInspector {
|
|
|
|
|
background: rgba(0, 0, 0, 0.8);
|
|
|
|
|
border: 2px solid grey;
|
|
|
|
|
border-radius: 4px;
|
|
|
|
|
padding: 6px;
|
|
|
|
|
}
|