isa/gnome-shell
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
a350e69248
gnome-shell/data/theme/gnome-shell-sass/_common.scss

2133 lines
49 KiB
SCSS
Raw Normal View History

theme: Replace gnome-shell-sass submodule with subtree As the style has grown bigger and more complex, generating the different variants from a common source has been a good decision. However given how intertwined the theme is with gnome-shell itself, relying on a submodule has proven to be quite painful. And as things stand right now, it is going to get worse: - using either pre-generated CSS or generating it at build time is odd, and violates meson's strict separation between source- and build directories; we are therefore considering dropping the CSS and depending on sassc to always generate it at build time - with the migration to gitlab, our workflow shifts decisively towards branches; however there is no support in either git or gitlab for handling two brances of separate repositories consecutively, which gets particularly awkward for branches in a private namespace With those pain points in mind, we will adjust our setup as follows: - remove the submodule from gnome-shell and instead import the sass as subtree - after that, the sass sources can be changed like any other files in the repository, and regular contributors can forget that there was ever anything special about them - whenever we want to update the classic style, we can push the subtree changes and bump gnome-shell-extension's sass submodule In other words: Updating the classic styling will become slightly more painful, but not much and only for me; in return, everyone else can stop fiddling with submodules (and buy me a beer).
2018-02-09 18:22:55 +00:00
//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} */
$panel-corner-radius: 6px;
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
$medium_radius: 9px;
theme: Replace gnome-shell-sass submodule with subtree As the style has grown bigger and more complex, generating the different variants from a common source has been a good decision. However given how intertwined the theme is with gnome-shell itself, relying on a submodule has proven to be quite painful. And as things stand right now, it is going to get worse: - using either pre-generated CSS or generating it at build time is odd, and violates meson's strict separation between source- and build directories; we are therefore considering dropping the CSS and depending on sassc to always generate it at build time - with the migration to gitlab, our workflow shifts decisively towards branches; however there is no support in either git or gitlab for handling two brances of separate repositories consecutively, which gets particularly awkward for branches in a private namespace With those pain points in mind, we will adjust our setup as follows: - remove the submodule from gnome-shell and instead import the sass as subtree - after that, the sass sources can be changed like any other files in the repository, and regular contributors can forget that there was ever anything special about them - whenever we want to update the classic style, we can push the subtree changes and bump gnome-shell-extension's sass submodule In other words: Updating the classic styling will become slightly more painful, but not much and only for me; in return, everyone else can stop fiddling with submodules (and buy me a beer).
2018-02-09 18:22:55 +00:00
/* 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 */
$font-size: 11;
$font-family: Cantarell, Sans-Serif;
stage {
font-family: $font-family;
@include fontsize($font-size);
color: $fg_color;
}
/* WIDGETS */
/* Buttons */
.button {
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
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 18:22:55 +00:00
border-width: 1px;
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00: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 18:22:55 +00:00
padding: 4px 32px;
@include button(normal);
&:focus { @include button(focus); }
theme: define proper :hover and :active states - buttons didn't actually have these properly defined fixes issue #523
2018-09-05 18:33:56 +00:00
&:hover { @include button(hover); }
theme: Replace gnome-shell-sass submodule with subtree As the style has grown bigger and more complex, generating the different variants from a common source has been a good decision. However given how intertwined the theme is with gnome-shell itself, relying on a submodule has proven to be quite painful. And as things stand right now, it is going to get worse: - using either pre-generated CSS or generating it at build time is odd, and violates meson's strict separation between source- and build directories; we are therefore considering dropping the CSS and depending on sassc to always generate it at build time - with the migration to gitlab, our workflow shifts decisively towards branches; however there is no support in either git or gitlab for handling two brances of separate repositories consecutively, which gets particularly awkward for branches in a private namespace With those pain points in mind, we will adjust our setup as follows: - remove the submodule from gnome-shell and instead import the sass as subtree - after that, the sass sources can be changed like any other files in the repository, and regular contributors can forget that there was ever anything special about them - whenever we want to update the classic style, we can push the subtree changes and bump gnome-shell-extension's sass submodule In other words: Updating the classic styling will become slightly more painful, but not much and only for me; in return, everyone else can stop fiddling with submodules (and buy me a beer).
2018-02-09 18:22:55 +00:00
&:insensitive { @include button(insensitive); }
&:active { @include button(active); }
}
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00: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 18:22:55 +00:00
border-right-width: 1px;
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
@include button(normal, $c:$bubble_bg_color, $tc:$bubble_fg_color);
&:insensitive { @include button(insensitive, $c:$bubble_bg_color, $tc:$bubble_fg_color); }
&:hover { @include button(hover, $c:$bubble_bg_color, $tc:$bubble_fg_color); }
&:focus { @include button(focus, $c:$bubble_bg_color, $tc:$bubble_fg_color); }
&:active { @include button(active, $c:$bubble_bg_color, $tc:$bubble_fg_color); }
theme: Replace gnome-shell-sass submodule with subtree As the style has grown bigger and more complex, generating the different variants from a common source has been a good decision. However given how intertwined the theme is with gnome-shell itself, relying on a submodule has proven to be quite painful. And as things stand right now, it is going to get worse: - using either pre-generated CSS or generating it at build time is odd, and violates meson's strict separation between source- and build directories; we are therefore considering dropping the CSS and depending on sassc to always generate it at build time - with the migration to gitlab, our workflow shifts decisively towards branches; however there is no support in either git or gitlab for handling two brances of separate repositories consecutively, which gets particularly awkward for branches in a private namespace With those pain points in mind, we will adjust our setup as follows: - remove the submodule from gnome-shell and instead import the sass as subtree - after that, the sass sources can be changed like any other files in the repository, and regular contributors can forget that there was ever anything special about them - whenever we want to update the classic style, we can push the subtree changes and bump gnome-shell-extension's sass submodule In other words: Updating the classic styling will become slightly more painful, but not much and only for me; in return, everyone else can stop fiddling with submodules (and buy me a beer).
2018-02-09 18:22:55 +00:00
padding: 12px;
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00: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 18:22:55 +00:00
&:first-child {
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
border-radius: 0px 0px 0px $medium_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 18:22:55 +00:00
}
&:last-child {
border-right-width: 0px;
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
border-radius: 0px 0px $medium_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 18:22:55 +00:00
}
&:first-child:last-child {
border-right-width: 0px;
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
border-radius: 0px 0px $medium_radius $medium_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 18:22:55 +00:00
}
}
/* Entries */
StEntry {
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
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 18:22:55 +00: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;
levelBar: Factor out bar drawing Split drawing logic from Slider to BarLevel subclass. This changes part of the theme css from -slider- to -barlevel-. https://bugzilla.gnome.org/show_bug.cgi?id=790280.
2018-02-08 18:04:42 +00:00
-barlevel-height: 0.3em;
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
-barlevel-background-color: lighten($bubble_fg_color, 25%); //background of the trough
-barlevel-border-color: transparent; //trough border color
levelBar: Factor out bar drawing Split drawing logic from Slider to BarLevel subclass. This changes part of the theme css from -slider- to -barlevel-. https://bugzilla.gnome.org/show_bug.cgi?id=790280.
2018-02-08 18:04:42 +00:00
-barlevel-active-background-color: $selected_bg_color; //active trough fill
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
-barlevel-active-border-color: transparent; //active trough border
barLevel: Add "overdrive" capability Implement for barLevel an overdrive area. This is a zone represented via a different styling to indicate that you are bypassing the normal zone of a given level, without reaching yet the maximum limit. https://bugzilla.gnome.org/show_bug.cgi?id=790280.
2018-07-31 13:49:06 +00:00
-barlevel-overdrive-color: $destructive_color;
-barlevel-overdrive-border-color: darken($destructive_color,10%);
-barlevel-overdrive-separator-width: 0.2em;
levelBar: Factor out bar drawing Split drawing logic from Slider to BarLevel subclass. This changes part of the theme css from -slider- to -barlevel-. https://bugzilla.gnome.org/show_bug.cgi?id=790280.
2018-02-08 18:04:42 +00:00
-barlevel-border-width: 1px;
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
-slider-handle-radius: 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 18:22:55 +00: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 {
theme: update toggle switch design - for the short term, just replace the SVG assets See https://gitlab.gnome.org/GNOME/gnome-shell/issues/841 for background
2019-04-16 14:05:10 +00: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 18:22:55 +00:00
height: 22px;
background-size: contain;
switch: Drop separate handling for US The switches no longer use ON/OFF or o/|, so just use the same class and artwork everywhere. https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/496
2019-04-16 17:21:02 +00:00
background-image: url("resource:///org/gnome/shell/theme/toggle-off-intl.svg");
&:checked { background-image: url("resource:///org/gnome/shell/theme/toggle-on-intl.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 18:22:55 +00: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 {
border-radius: 9px;
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00: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 18:22:55 +00: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);
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
font-weight: normal;
color: $bubble_fg_color;
theme: Replace gnome-shell-sass submodule with subtree As the style has grown bigger and more complex, generating the different variants from a common source has been a good decision. However given how intertwined the theme is with gnome-shell itself, relying on a submodule has proven to be quite painful. And as things stand right now, it is going to get worse: - using either pre-generated CSS or generating it at build time is odd, and violates meson's strict separation between source- and build directories; we are therefore considering dropping the CSS and depending on sassc to always generate it at build time - with the migration to gitlab, our workflow shifts decisively towards branches; however there is no support in either git or gitlab for handling two brances of separate repositories consecutively, which gets particularly awkward for branches in a private namespace With those pain points in mind, we will adjust our setup as follows: - remove the submodule from gnome-shell and instead import the sass as subtree - after that, the sass sources can be changed like any other files in the repository, and regular contributors can forget that there was ever anything special about them - whenever we want to update the classic style, we can push the subtree changes and bump gnome-shell-extension's sass submodule In other words: Updating the classic styling will become slightly more painful, but not much and only for me; in return, everyone else can stop fiddling with submodules (and buy me a beer).
2018-02-09 18:22:55 +00:00
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 {
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
color: $bubble_fg_color;
theme: Replace gnome-shell-sass submodule with subtree As the style has grown bigger and more complex, generating the different variants from a common source has been a good decision. However given how intertwined the theme is with gnome-shell itself, relying on a submodule has proven to be quite painful. And as things stand right now, it is going to get worse: - using either pre-generated CSS or generating it at build time is odd, and violates meson's strict separation between source- and build directories; we are therefore considering dropping the CSS and depending on sassc to always generate it at build time - with the migration to gitlab, our workflow shifts decisively towards branches; however there is no support in either git or gitlab for handling two brances of separate repositories consecutively, which gets particularly awkward for branches in a private namespace With those pain points in mind, we will adjust our setup as follows: - remove the submodule from gnome-shell and instead import the sass as subtree - after that, the sass sources can be changed like any other files in the repository, and regular contributors can forget that there was ever anything special about them - whenever we want to update the classic style, we can push the subtree changes and bump gnome-shell-extension's sass submodule In other words: Updating the classic styling will become slightly more painful, but not much and only for me; in return, everyone else can stop fiddling with submodules (and buy me a beer).
2018-02-09 18:22:55 +00:00
font-weight: bold;
}
/* End Session Dialog */
.end-session-dialog {
spacing: 42px;
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
border: 1px solid $bubble_outer_borders_color;
theme: Replace gnome-shell-sass submodule with subtree As the style has grown bigger and more complex, generating the different variants from a common source has been a good decision. However given how intertwined the theme is with gnome-shell itself, relying on a submodule has proven to be quite painful. And as things stand right now, it is going to get worse: - using either pre-generated CSS or generating it at build time is odd, and violates meson's strict separation between source- and build directories; we are therefore considering dropping the CSS and depending on sassc to always generate it at build time - with the migration to gitlab, our workflow shifts decisively towards branches; however there is no support in either git or gitlab for handling two brances of separate repositories consecutively, which gets particularly awkward for branches in a private namespace With those pain points in mind, we will adjust our setup as follows: - remove the submodule from gnome-shell and instead import the sass as subtree - after that, the sass sources can be changed like any other files in the repository, and regular contributors can forget that there was ever anything special about them - whenever we want to update the classic style, we can push the subtree changes and bump gnome-shell-extension's sass submodule In other words: Updating the classic styling will become slightly more painful, but not much and only for me; in return, everyone else can stop fiddling with submodules (and buy me a beer).
2018-02-09 18:22:55 +00:00
}
.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 {
userWidget: Remove frame around avatar There's a push for round user images, for which the existing square frame is a bad match. So remove the frame and enforce the shape. https://gitlab.gnome.org/GNOME/gnome-shell/issues/811
2019-02-05 16:28:41 +00: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 18:22:55 +00:00
width: 48px;
height: 48px;
background-size: contain;
}
.end-session-dialog-shutdown-icon {
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
color: $bubble_fg_color;
theme: Replace gnome-shell-sass submodule with subtree As the style has grown bigger and more complex, generating the different variants from a common source has been a good decision. However given how intertwined the theme is with gnome-shell itself, relying on a submodule has proven to be quite painful. And as things stand right now, it is going to get worse: - using either pre-generated CSS or generating it at build time is odd, and violates meson's strict separation between source- and build directories; we are therefore considering dropping the CSS and depending on sassc to always generate it at build time - with the migration to gitlab, our workflow shifts decisively towards branches; however there is no support in either git or gitlab for handling two brances of separate repositories consecutively, which gets particularly awkward for branches in a private namespace With those pain points in mind, we will adjust our setup as follows: - remove the submodule from gnome-shell and instead import the sass as subtree - after that, the sass sources can be changed like any other files in the repository, and regular contributors can forget that there was ever anything special about them - whenever we want to update the classic style, we can push the subtree changes and bump gnome-shell-extension's sass submodule In other words: Updating the classic styling will become slightly more painful, but not much and only for me; in return, everyone else can stop fiddling with submodules (and buy me a beer).
2018-02-09 18:22:55 +00:00
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 {
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
color: lighten($bubble_fg_color,10%);
&:hover { color: $bubble_fg_color; }
theme: Replace gnome-shell-sass submodule with subtree As the style has grown bigger and more complex, generating the different variants from a common source has been a good decision. However given how intertwined the theme is with gnome-shell itself, relying on a submodule has proven to be quite painful. And as things stand right now, it is going to get worse: - using either pre-generated CSS or generating it at build time is odd, and violates meson's strict separation between source- and build directories; we are therefore considering dropping the CSS and depending on sassc to always generate it at build time - with the migration to gitlab, our workflow shifts decisively towards branches; however there is no support in either git or gitlab for handling two brances of separate repositories consecutively, which gets particularly awkward for branches in a private namespace With those pain points in mind, we will adjust our setup as follows: - remove the submodule from gnome-shell and instead import the sass as subtree - after that, the sass sources can be changed like any other files in the repository, and regular contributors can forget that there was ever anything special about them - whenever we want to update the classic style, we can push the subtree changes and bump gnome-shell-extension's sass submodule In other words: Updating the classic styling will become slightly more painful, but not much and only for me; in return, everyone else can stop fiddling with submodules (and buy me a beer).
2018-02-09 18:22:55 +00:00
&: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 {
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00: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 18:22:55 +00: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; }
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
.message-dialog-title { color: lighten($bubble_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 18:22:55 +00:00
}
.prompt-dialog-description:rtl {
text-align: right;
}
.prompt-dialog-password-box {
spacing: 1em;
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00: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 18:22:55 +00:00
}
.prompt-dialog-error-label {
font-size: 10pt;
theme: improve legibility of error messages - the login dialog uses warning_color, so be consistent - nevertheless increase lightness of the error_color Fixes issue https://gitlab.gnome.org/GNOME/gnome-shell/issues/1016
2019-03-01 14:34:41 +00: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 18:22:55 +00: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;
}
shellMountOperation: Support TCRYPT This extends the ShellMountPasswordDialog by widgets which allow specifying parameters supported by TrueCrypt and VeraCrypt compatible volumes (TCRYPT). This includes: - Whether the volume to be unlocked is hidden. - Whether the volume to be unlocked is a system partition. Note: TrueCrypt and VeraCrypt only support encrypting Windows systems [1], so the label for this option is "Windows System Volume". - Whether to use a PIM [2]. - Whether to use keyfiles. Unfortunately, GMountOperation doesn't support TCRYPT keyfiles, so if this checkbox is checked, we tell the user that they should unlock the volume with Disks, which supports unlocking TCRYPT volumes with keyfiles. [1] https://www.veracrypt.fr/en/System%20Encryption.html [2] https://www.veracrypt.fr/en/Header%20Key%20Derivation.html https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/126
2019-04-07 21:35:07 +00:00
.prompt-dialog-pim-box {
spacing: 1em;
}
shellMountOperation: Move password entry to a grid This prepares for additional UI elements added for TCRYPT support. https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/126
2019-04-07 21:33:34 +00:00
.prompt-dialog-grid {
spacing-rows: 15px;
spacing-columns: 1em;
}
shellMountOperation: Support TCRYPT This extends the ShellMountPasswordDialog by widgets which allow specifying parameters supported by TrueCrypt and VeraCrypt compatible volumes (TCRYPT). This includes: - Whether the volume to be unlocked is hidden. - Whether the volume to be unlocked is a system partition. Note: TrueCrypt and VeraCrypt only support encrypting Windows systems [1], so the label for this option is "Windows System Volume". - Whether to use a PIM [2]. - Whether to use keyfiles. Unfortunately, GMountOperation doesn't support TCRYPT keyfiles, so if this checkbox is checked, we tell the user that they should unlock the volume with Disks, which supports unlocking TCRYPT volumes with keyfiles. [1] https://www.veracrypt.fr/en/System%20Encryption.html [2] https://www.veracrypt.fr/en/Header%20Key%20Derivation.html https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/126
2019-04-07 21:35:07 +00: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 18:22:55 +00: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 {
userWidget: Remove frame around avatar There's a push for round user images, for which the existing square frame is a bad match. So remove the frame and enforce the shape. https://gitlab.gnome.org/GNOME/gnome-shell/issues/811
2019-02-05 16:28:41 +00: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 18:22:55 +00:00
background-size: contain;
width: 48px;
height: 48px;
}
/* Audio selection dialog */
.audio-device-selection-dialog {
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00: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 18:22:55 +00: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 {
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00: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 18:22:55 +00:00
border-radius: 12px;
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
&:hover,&:focus { background-color: $bubble_hover_bg_color; }
&:active {
background-color: $bubble_active_bg_color;
color: $bubble_active_fg_color;
}
theme: Replace gnome-shell-sass submodule with subtree As the style has grown bigger and more complex, generating the different variants from a common source has been a good decision. However given how intertwined the theme is with gnome-shell itself, relying on a submodule has proven to be quite painful. And as things stand right now, it is going to get worse: - using either pre-generated CSS or generating it at build time is odd, and violates meson's strict separation between source- and build directories; we are therefore considering dropping the CSS and depending on sassc to always generate it at build time - with the migration to gitlab, our workflow shifts decisively towards branches; however there is no support in either git or gitlab for handling two brances of separate repositories consecutively, which gets particularly awkward for branches in a private namespace With those pain points in mind, we will adjust our setup as follows: - remove the submodule from gnome-shell and instead import the sass as subtree - after that, the sass sources can be changed like any other files in the repository, and regular contributors can forget that there was ever anything special about them - whenever we want to update the classic style, we can push the subtree changes and bump gnome-shell-extension's sass submodule In other words: Updating the classic styling will become slightly more painful, but not much and only for me; in return, everyone else can stop fiddling with submodules (and buy me a beer).
2018-02-09 18:22:55 +00:00
}
.audio-selection-device-box {
padding: 20px;
spacing: 20px;
}
.audio-selection-device-icon {
icon-size: 64px;
}
/* Access Dialog */
.access-dialog {
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00: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 18:22:55 +00:00
spacing: 30px;
}
/* Geolocation Dialog */
.geolocation-dialog {
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00: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 18:22:55 +00:00
spacing: 30px;
}
/* Extension Dialog */
.extension-dialog {
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00: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 18:22:55 +00:00
.message-dialog-main-layout { spacing: 24px; padding: 10px; }
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
.message-dialog-title { font-weight: normal; color: $bubble_fg_color; }
theme: Replace gnome-shell-sass submodule with subtree As the style has grown bigger and more complex, generating the different variants from a common source has been a good decision. However given how intertwined the theme is with gnome-shell itself, relying on a submodule has proven to be quite painful. And as things stand right now, it is going to get worse: - using either pre-generated CSS or generating it at build time is odd, and violates meson's strict separation between source- and build directories; we are therefore considering dropping the CSS and depending on sassc to always generate it at build time - with the migration to gitlab, our workflow shifts decisively towards branches; however there is no support in either git or gitlab for handling two brances of separate repositories consecutively, which gets particularly awkward for branches in a private namespace With those pain points in mind, we will adjust our setup as follows: - remove the submodule from gnome-shell and instead import the sass as subtree - after that, the sass sources can be changed like any other files in the repository, and regular contributors can forget that there was ever anything special about them - whenever we want to update the classic style, we can push the subtree changes and bump gnome-shell-extension's sass submodule In other words: Updating the classic styling will become slightly more painful, but not much and only for me; in return, everyone else can stop fiddling with submodules (and buy me a beer).
2018-02-09 18:22:55 +00:00
}
/* Inhibit-Shortcuts Dialog */
.inhibit-shortcuts-dialog {
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00: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 18:22:55 +00: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;
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
color: $bubble_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 18:22:55 +00:00
.popup-menu-arrow { } //defined globally in the TOP BAR
.popup-sub-menu {
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
background-color: darken($bubble_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 18:22:55 +00: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 {
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
background-color: $bubble_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 18:22:55 +00:00
font-weight: bold;
}
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
&.selected { background-color: $bubble_hover_bg_color; color: $bubble_fg_color; }
&:active {
background-color: $bubble_active_bg_color;
color: $bubble_active_fg_color;
}
&:insensitive { color: transparentize($bubble_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 18:22:55 +00:00
}
.popup-inactive-menu-item { //all icons and other graphical elements
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
color: $bubble_fg_color;
theme: Replace gnome-shell-sass submodule with subtree As the style has grown bigger and more complex, generating the different variants from a common source has been a good decision. However given how intertwined the theme is with gnome-shell itself, relying on a submodule has proven to be quite painful. And as things stand right now, it is going to get worse: - using either pre-generated CSS or generating it at build time is odd, and violates meson's strict separation between source- and build directories; we are therefore considering dropping the CSS and depending on sassc to always generate it at build time - with the migration to gitlab, our workflow shifts decisively towards branches; however there is no support in either git or gitlab for handling two brances of separate repositories consecutively, which gets particularly awkward for branches in a private namespace With those pain points in mind, we will adjust our setup as follows: - remove the submodule from gnome-shell and instead import the sass as subtree - after that, the sass sources can be changed like any other files in the repository, and regular contributors can forget that there was ever anything special about them - whenever we want to update the classic style, we can push the subtree changes and bump gnome-shell-extension's sass submodule In other words: Updating the classic styling will become slightly more painful, but not much and only for me; in return, everyone else can stop fiddling with submodules (and buy me a beer).
2018-02-09 18:22:55 +00:00
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
&:insensitive { color: transparentize($bubble_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 18:22:55 +00:00
}
//.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 {
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
-arrow-border-radius: $medium_radius;
-arrow-background-color: $bubble_bg_color;
theme: Replace gnome-shell-sass submodule with subtree As the style has grown bigger and more complex, generating the different variants from a common source has been a good decision. However given how intertwined the theme is with gnome-shell itself, relying on a submodule has proven to be quite painful. And as things stand right now, it is going to get worse: - using either pre-generated CSS or generating it at build time is odd, and violates meson's strict separation between source- and build directories; we are therefore considering dropping the CSS and depending on sassc to always generate it at build time - with the migration to gitlab, our workflow shifts decisively towards branches; however there is no support in either git or gitlab for handling two brances of separate repositories consecutively, which gets particularly awkward for branches in a private namespace With those pain points in mind, we will adjust our setup as follows: - remove the submodule from gnome-shell and instead import the sass as subtree - after that, the sass sources can be changed like any other files in the repository, and regular contributors can forget that there was ever anything special about them - whenever we want to update the classic style, we can push the subtree changes and bump gnome-shell-extension's sass submodule In other words: Updating the classic styling will become slightly more painful, but not much and only for me; in return, everyone else can stop fiddling with submodules (and buy me a beer).
2018-02-09 18:22:55 +00:00
-arrow-border-width: 1px;
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
-arrow-border-color: $bubble_outer_borders_color;
theme: Replace gnome-shell-sass submodule with subtree As the style has grown bigger and more complex, generating the different variants from a common source has been a good decision. However given how intertwined the theme is with gnome-shell itself, relying on a submodule has proven to be quite painful. And as things stand right now, it is going to get worse: - using either pre-generated CSS or generating it at build time is odd, and violates meson's strict separation between source- and build directories; we are therefore considering dropping the CSS and depending on sassc to always generate it at build time - with the migration to gitlab, our workflow shifts decisively towards branches; however there is no support in either git or gitlab for handling two brances of separate repositories consecutively, which gets particularly awkward for branches in a private namespace With those pain points in mind, we will adjust our setup as follows: - remove the submodule from gnome-shell and instead import the sass as subtree - after that, the sass sources can be changed like any other files in the repository, and regular contributors can forget that there was ever anything special about them - whenever we want to update the classic style, we can push the subtree changes and bump gnome-shell-extension's sass submodule In other words: Updating the classic styling will become slightly more painful, but not much and only for me; in return, everyone else can stop fiddling with submodules (and buy me a beer).
2018-02-09 18:22:55 +00:00
-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;
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00: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 18:22:55 +00: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
*/
/* 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;
osdWindow: Reuse BarLevel drawing functionality Reuse the BarLevel class to get similar drawing behavior as Slider. Rename theme css impacted properties and ensure that the osdWindow remains accessible. Ensure we don't force setting a custom border color like on the OSD. https://bugzilla.gnome.org/show_bug.cgi?id=790280.
2018-02-08 18:22:29 +00:00
-barlevel-height: 0.6em;
-barlevel-background-color: transparentize(darken($osd_bg_color,15%),0.5);
-barlevel-active-background-color: $osd_fg_color;
barLevel: Add "overdrive" capability Implement for barLevel an overdrive area. This is a zone represented via a different styling to indicate that you are bypassing the normal zone of a given level, without reaching yet the maximum limit. https://bugzilla.gnome.org/show_bug.cgi?id=790280.
2018-07-31 13:49:06 +00: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 18:22:55 +00: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 {
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00: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 18:22:55 +00: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;
}
.ws-switcher-active-up, .ws-switcher-active-down {
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 {
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
color: $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 18:22:55 +00:00
border-radius: 12px;
padding: 12px;
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
box-shadow: 0 3px 9px 1px transparentize(black, 0.5);
}
%bubble-entry {
color: $bubble_fg_color;
background-color: darken($bubble_bg_color, 2%);
border-color: $bubble_borders_color;
box-shadow: none;
&:focus { border: 2px solid $selected_bg_color; }
}
%bubble-panel {
color: $bubble_fg_color;
background-color: $bubble_bg_color;
border: 1px solid $bubble_outer_borders_color;
box-shadow: 0 3px 9px 1px transparentize(black, 0.5); // to match with the notification banner but maybe no?
StEntry { @extend %bubble-entry; }
.button {
&, &:hover, &:focus, &:active, &:disabled {
box-shadow: none;
border-color: $bubble_borders_color;
}
background-color: white;
color: $bubble_fg_color;
&:hover { background-color: $bubble_hover_bg_color; }
&:active {
background-color: $bubble_active_bg_color;
color: $bubble_active_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 18:22:55 +00: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 {
panel: Remove panel translucency Since commit 447bf55e45b we turn the top bar translucent when free-floating. While this looks fancy and reduces the appearance of cutting into the available screen space, it has also had a negative effect on legibility. Nobody stepped up to address those issues in two years, so revert back to the fully opaque top bar. https://gitlab.gnome.org/GNOME/gnome-shell/issues/408
2019-01-30 16:48:28 +00: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 18:22:55 +00:00
font-weight: bold;
height: 1.86em;
theme: Use tabular figures where appropriate In places where numbers appear in columns (like the calendar widget) or where changing numbers would result in labels jiggling around due to small width changes (like the clock), use the newly added font-feature-settings support to request tabular figures. https://gitlab.gnome.org/GNOME/gnome-shell/issues/34
2018-05-17 14:45:02 +00: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 18:22:55 +00: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;
panel: Remove panel translucency Since commit 447bf55e45b we turn the top bar translucent when free-floating. While this looks fancy and reduces the appearance of cutting into the available screen space, it has also had a negative effect on legibility. Nobody stepped up to address those issues in two years, so revert back to the fully opaque top bar. https://gitlab.gnome.org/GNOME/gnome-shell/issues/408
2019-01-30 16:48:28 +00: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 18:22:55 +00: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;
panel: Remove panel translucency Since commit 447bf55e45b we turn the top bar translucent when free-floating. While this looks fancy and reduces the appearance of cutting into the available screen space, it has also had a negative effect on legibility. Nobody stepped up to address those issues in two years, so revert back to the fully opaque top bar. https://gitlab.gnome.org/GNOME/gnome-shell/issues/408
2019-01-30 16:48:28 +00: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 18:22:55 +00:00
.app-menu-icon {
-st-icon-style: symbolic;
margin-left: 4px;
margin-right: 4px;
//dimensions of the icon are hardcoded
}
&:hover {
color: lighten($fg_color, 10%);
}
&: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%);
color: lighten($fg_color,10%);
}
.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; }
remoteAccess: Make indicator orange Make the indicator for active remote access use the warning color, to indicate the severity of allowing remote access. This only makes the indicator icon orange; the icon in the system menu is still white.
2018-07-27 16:07:52 +00: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 18:22:55 +00: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 {
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
border: 0 solid darken($bubble_bg_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 18:22:55 +00: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 {
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
&:hover, focus { background-color: darken($bubble_bg_color, 12%); }
&:active { background-color: darken($bubble_bg_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 18:22:55 +00:00
}
.datemenu-today-button .day-label {
}
.datemenu-today-button .date-label {
font-size: 1.5em;
theme: use cantarell light - lock screen - date in the calendar popover fixes issue #45
2018-02-14 15:42:56 +00: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 18:22:55 +00:00
}
.world-clocks-header,
.weather-header,
.events-section-title {
color: darken($fg_color,40%);
font-weight: bold;
}
dateMenu: Show weather location in section header It is useful information, in particular when the location is set automatically via geoclue. https://gitlab.gnome.org/GNOME/gnome-shell/issues/262
2019-01-11 16:42:22 +00:00
.weather-header.location {
font-weight: normal;
font-size: 0.9em;
}
dateMenu: Use graphical weather forecasts While the current textual forecast is non-intrusive, it may be too much so, making it less effective to spot the current conditions at a glance. Refresh the section to use a more conventional graphical representation, similar to the one used by gnome-weather itself. https://gitlab.gnome.org/GNOME/gnome-shell/issues/262
2018-12-13 13:45:22 +00: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 18:22:55 +00:00
spacing-rows: 0.4em;
dateMenu: Refresh world clocks section Update the section styling to accentuate the most relevant information, and include the timezone. https://gitlab.gnome.org/GNOME/gnome-shell/issues/262
2018-12-13 16:44:28 +00: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 18:22:55 +00:00
}
.weather-box {
spacing: 0.4em;
}
dateMenu: Refresh world clocks section Update the section styling to accentuate the most relevant information, and include the timezone. https://gitlab.gnome.org/GNOME/gnome-shell/issues/262
2018-12-13 16:44:28 +00: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 {
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
color: $bubble_fg_color;
dateMenu: Refresh world clocks section Update the section styling to accentuate the most relevant information, and include the timezone. https://gitlab.gnome.org/GNOME/gnome-shell/issues/262
2018-12-13 16:44:28 +00:00
font-feature-settings: "tnum";
font-size: 0.9em;
dateMenu: Use graphical weather forecasts While the current textual forecast is non-intrusive, it may be too much so, making it less effective to spot the current conditions at a glance. Refresh the section to use a more conventional graphical representation, similar to the one used by gnome-weather itself. https://gitlab.gnome.org/GNOME/gnome-shell/issues/262
2018-12-13 13:45:22 +00: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 18:22:55 +00:00
.calendar-month-label {
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
color: lighten($bubble_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 18:22:55 +00:00
font-weight: bold;
padding: 8px 0;
&:focus {}
}
.pager-button {
background-color: transparent;
width: 32px;
border-radius: 4px;
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
&:hover, focus { background-color: $bubble_hover_bg_color; }
&:active { background-color: transparentize($bubble_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 18:22:55 +00:00
}
theme: Replace calendar arrow images with symbolic icons and CSS https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/301
2018-11-20 16:55:31 +00: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 18:22:55 +00: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;
theme: Use tabular figures where appropriate In places where numbers appear in columns (like the calendar widget) or where changing numbers would result in labels jiggling around due to small width changes (like the clock), use the newly added font-feature-settings support to request tabular figures. https://gitlab.gnome.org/GNOME/gnome-shell/issues/34
2018-05-17 14:45:02 +00:00
font-feature-settings: "tnum";
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
&:hover, focus { background-color: $bubble_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 18:22:55 +00: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
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
color: lighten($bubble_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 18:22:55 +00: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%);
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00: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 18:22:55 +00:00
}
.calendar-day-with-events {
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
color: lighten($bubble_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 18:22:55 +00:00
font-weight: bold;
background-image: url("resource:///org/gnome/shell/theme/calendar-today.svg");
}
.calendar-other-month-day {
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
color: transparentize($bubble_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 18:22:55 +00: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;
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
background-color: $bubble_borders_color;
color: $bubble_fg_color;
theme: Replace gnome-shell-sass submodule with subtree As the style has grown bigger and more complex, generating the different variants from a common source has been a good decision. However given how intertwined the theme is with gnome-shell itself, relying on a submodule has proven to be quite painful. And as things stand right now, it is going to get worse: - using either pre-generated CSS or generating it at build time is odd, and violates meson's strict separation between source- and build directories; we are therefore considering dropping the CSS and depending on sassc to always generate it at build time - with the migration to gitlab, our workflow shifts decisively towards branches; however there is no support in either git or gitlab for handling two brances of separate repositories consecutively, which gets particularly awkward for branches in a private namespace With those pain points in mind, we will adjust our setup as follows: - remove the submodule from gnome-shell and instead import the sass as subtree - after that, the sass sources can be changed like any other files in the repository, and regular contributors can forget that there was ever anything special about them - whenever we want to update the classic style, we can push the subtree changes and bump gnome-shell-extension's sass submodule In other words: Updating the classic styling will become slightly more painful, but not much and only for me; in return, everyone else can stop fiddling with submodules (and buy me a beer).
2018-02-09 18:22:55 +00:00
}
/* Message list */
.message-list {
width: 31.5em;
}
.message-list-clear-button.button {
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
background-color: white;
color: $bubble_fg_color;
box-shadow: none;
border-color: $bubble_borders_color;
&:hover,&:focus { background-color: $bubble_hover_bg_color; }
&:active {
background-color: $bubble_active_bg_color;
color: $bubble_active_fg_color;
}
theme: Replace gnome-shell-sass submodule with subtree As the style has grown bigger and more complex, generating the different variants from a common source has been a good decision. However given how intertwined the theme is with gnome-shell itself, relying on a submodule has proven to be quite painful. And as things stand right now, it is going to get worse: - using either pre-generated CSS or generating it at build time is odd, and violates meson's strict separation between source- and build directories; we are therefore considering dropping the CSS and depending on sassc to always generate it at build time - with the migration to gitlab, our workflow shifts decisively towards branches; however there is no support in either git or gitlab for handling two brances of separate repositories consecutively, which gets particularly awkward for branches in a private namespace With those pain points in mind, we will adjust our setup as follows: - remove the submodule from gnome-shell and instead import the sass as subtree - after that, the sass sources can be changed like any other files in the repository, and regular contributors can forget that there was ever anything special about them - whenever we want to update the classic style, we can push the subtree changes and bump gnome-shell-extension's sass submodule In other words: Updating the classic styling will become slightly more painful, but not much and only for me; in return, everyone else can stop fiddling with submodules (and buy me a beer).
2018-02-09 18:22:55 +00:00
margin: 1.5em 1.5em 0;
}
.message-list-sections {
spacing: 1em;
}
.message-list-section,
.message-list-section-list {
spacing: 0.4em;
}
.message {
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
border: 1px solid $bubble_borders_color;
background-color: lighten($bubble_bg_color, 2%);
&:hover,&:focus { background-color: $bubble_hover_bg_color; }
&:active { background-color: transparentize($bubble_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 18:22:55 +00: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 {
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
color: $bubble_fg_color;
theme: Replace gnome-shell-sass submodule with subtree As the style has grown bigger and more complex, generating the different variants from a common source has been a good decision. However given how intertwined the theme is with gnome-shell itself, relying on a submodule has proven to be quite painful. And as things stand right now, it is going to get worse: - using either pre-generated CSS or generating it at build time is odd, and violates meson's strict separation between source- and build directories; we are therefore considering dropping the CSS and depending on sassc to always generate it at build time - with the migration to gitlab, our workflow shifts decisively towards branches; however there is no support in either git or gitlab for handling two brances of separate repositories consecutively, which gets particularly awkward for branches in a private namespace With those pain points in mind, we will adjust our setup as follows: - remove the submodule from gnome-shell and instead import the sass as subtree - after that, the sass sources can be changed like any other files in the repository, and regular contributors can forget that there was ever anything special about them - whenever we want to update the classic style, we can push the subtree changes and bump gnome-shell-extension's sass submodule In other words: Updating the classic styling will become slightly more painful, but not much and only for me; in return, everyone else can stop fiddling with submodules (and buy me a beer).
2018-02-09 18:22:55 +00:00
icon-size: 1.09em;
-st-icon-style: symbolic;
}
theme: Handle fallback app icons in notifications Since commit 3eb80dc6c0, the size of notification icons is determined by the theme to make it font-relative. Also handle the case where the icon isn't an StIcon, but a fallback window icon. https://gitlab.gnome.org/GNOME/gnome-shell/issues/1027
2019-03-08 13:12:12 +00: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 18:22:55 +00:00
.message-secondary-bin {
padding: 0 0.82em;;
}
.message-secondary-bin > .event-time {
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
color: $bubble_fg_color;
theme: Replace gnome-shell-sass submodule with subtree As the style has grown bigger and more complex, generating the different variants from a common source has been a good decision. However given how intertwined the theme is with gnome-shell itself, relying on a submodule has proven to be quite painful. And as things stand right now, it is going to get worse: - using either pre-generated CSS or generating it at build time is odd, and violates meson's strict separation between source- and build directories; we are therefore considering dropping the CSS and depending on sassc to always generate it at build time - with the migration to gitlab, our workflow shifts decisively towards branches; however there is no support in either git or gitlab for handling two brances of separate repositories consecutively, which gets particularly awkward for branches in a private namespace With those pain points in mind, we will adjust our setup as follows: - remove the submodule from gnome-shell and instead import the sass as subtree - after that, the sass sources can be changed like any other files in the repository, and regular contributors can forget that there was ever anything special about them - whenever we want to update the classic style, we can push the subtree changes and bump gnome-shell-extension's sass submodule In other words: Updating the classic styling will become slightly more painful, but not much and only for me; in return, everyone else can stop fiddling with submodules (and buy me a beer).
2018-02-09 18:22:55 +00:00
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 {
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
color: $bubble_fg_color;
theme: Replace gnome-shell-sass submodule with subtree As the style has grown bigger and more complex, generating the different variants from a common source has been a good decision. However given how intertwined the theme is with gnome-shell itself, relying on a submodule has proven to be quite painful. And as things stand right now, it is going to get worse: - using either pre-generated CSS or generating it at build time is odd, and violates meson's strict separation between source- and build directories; we are therefore considering dropping the CSS and depending on sassc to always generate it at build time - with the migration to gitlab, our workflow shifts decisively towards branches; however there is no support in either git or gitlab for handling two brances of separate repositories consecutively, which gets particularly awkward for branches in a private namespace With those pain points in mind, we will adjust our setup as follows: - remove the submodule from gnome-shell and instead import the sass as subtree - after that, the sass sources can be changed like any other files in the repository, and regular contributors can forget that there was ever anything special about them - whenever we want to update the classic style, we can push the subtree changes and bump gnome-shell-extension's sass submodule In other words: Updating the classic styling will become slightly more painful, but not much and only for me; in return, everyone else can stop fiddling with submodules (and buy me a beer).
2018-02-09 18:22:55 +00:00
}
.message-content {
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
color: darken($bubble_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 18:22:55 +00:00
padding: 10px;
}
.message-media-control {
padding: 12px;
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
color: lighten($bubble_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 18:22:55 +00:00
&:last-child:ltr { padding-right: 18px; }
&:last-child:rtl { padding-left: 18px; }
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
&:hover { color: $bubble_fg_color; }
theme: Replace gnome-shell-sass submodule with subtree As the style has grown bigger and more complex, generating the different variants from a common source has been a good decision. However given how intertwined the theme is with gnome-shell itself, relying on a submodule has proven to be quite painful. And as things stand right now, it is going to get worse: - using either pre-generated CSS or generating it at build time is odd, and violates meson's strict separation between source- and build directories; we are therefore considering dropping the CSS and depending on sassc to always generate it at build time - with the migration to gitlab, our workflow shifts decisively towards branches; however there is no support in either git or gitlab for handling two brances of separate repositories consecutively, which gets particularly awkward for branches in a private namespace With those pain points in mind, we will adjust our setup as follows: - remove the submodule from gnome-shell and instead import the sass as subtree - after that, the sass sources can be changed like any other files in the repository, and regular contributors can forget that there was ever anything special about them - whenever we want to update the classic style, we can push the subtree changes and bump gnome-shell-extension's sass submodule In other words: Updating the classic styling will become slightly more painful, but not much and only for me; in return, everyone else can stop fiddling with submodules (and buy me a beer).
2018-02-09 18:22:55 +00:00
&:insensitive { color: darken($fg_color,40%); }
}
.media-message-cover-icon {
icon-size: 48px !important;
&.fallback {
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
color: lighten($bubble_fg_color,10%);
background-color: $bubble_bg_color;
border: 1px solid $bubble_bg_color;
theme: Replace gnome-shell-sass submodule with subtree As the style has grown bigger and more complex, generating the different variants from a common source has been a good decision. However given how intertwined the theme is with gnome-shell itself, relying on a submodule has proven to be quite painful. And as things stand right now, it is going to get worse: - using either pre-generated CSS or generating it at build time is odd, and violates meson's strict separation between source- and build directories; we are therefore considering dropping the CSS and depending on sassc to always generate it at build time - with the migration to gitlab, our workflow shifts decisively towards branches; however there is no support in either git or gitlab for handling two brances of separate repositories consecutively, which gets particularly awkward for branches in a private namespace With those pain points in mind, we will adjust our setup as follows: - remove the submodule from gnome-shell and instead import the sass as subtree - after that, the sass sources can be changed like any other files in the repository, and regular contributors can forget that there was ever anything special about them - whenever we want to update the classic style, we can push the subtree changes and bump gnome-shell-extension's sass submodule In other words: Updating the classic styling will become slightly more painful, but not much and only for me; in return, everyone else can stop fiddling with submodules (and buy me a beer).
2018-02-09 18:22:55 +00:00
border-radius: 2px;
media section: Change size of the fallback cover Fallback cover used to be larger than the non-fallback one, making the media controls look inconsistent.
2018-09-13 18:14:05 +00: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 18:22:55 +00:00
}
// a little unstructured mess:
system: Always use default avatar in switch-user submenu It is too small to be really useful, and sticks out being the only color icon. https://gitlab.gnome.org/GNOME/gnome-shell/issues/957
2019-02-05 12:55:14 +00:00
.system-switch-user-submenu-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 18:22:55 +00:00
icon-size: 16px;
padding: 0 4px;
}
#appMenu {
spinner-image: url("resource:///org/gnome/shell/theme/process-working.svg");
spacing: 4px;
.label-shadow { color: transparent; }
}
panel: Restrict app menu width Window titles aren't restricted in length, so the menu may end up unwieldily width. Commit 0bec76b6ee therefore limited the app context menus, but that got accidentally dropped in commit 0ded0dbfd5. Add back the limitation and extend it to the new app menu as well. https://gitlab.gnome.org/GNOME/gnome-shell/issues/624
2019-02-05 00:11:43 +00: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 18:22:55 +00:00
.aggregate-menu {
min-width: 21em;
.popup-menu-icon { padding: 0 4px; }
system: Align submenu labels with parent - adjust for deeper hierarchies Adjust the previous commit which applied the alignment to :first-child descendants, instead of only immediate children. This fixes alignment issues for a number of Shell extensions by making it easier to override with a .popup-menu-item style-subclass.
2018-04-02 21:54:43 +00: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 18:22:55 +00: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 {
system: Enforce symbolic icons in action buttons We can simply request the symbolic variant from CSS so that we don't have to append '-symbolic' to all the names. This will always make it easier to pick up that information from external sources (like .desktop files). https://gitlab.gnome.org/GNOME/gnome-shell/issues/433
2018-07-24 14:29:56 +00:00
-st-icon-style: symbolic;
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
color: $bubble_fg_color;
theme: Replace gnome-shell-sass submodule with subtree As the style has grown bigger and more complex, generating the different variants from a common source has been a good decision. However given how intertwined the theme is with gnome-shell itself, relying on a submodule has proven to be quite painful. And as things stand right now, it is going to get worse: - using either pre-generated CSS or generating it at build time is odd, and violates meson's strict separation between source- and build directories; we are therefore considering dropping the CSS and depending on sassc to always generate it at build time - with the migration to gitlab, our workflow shifts decisively towards branches; however there is no support in either git or gitlab for handling two brances of separate repositories consecutively, which gets particularly awkward for branches in a private namespace With those pain points in mind, we will adjust our setup as follows: - remove the submodule from gnome-shell and instead import the sass as subtree - after that, the sass sources can be changed like any other files in the repository, and regular contributors can forget that there was ever anything special about them - whenever we want to update the classic style, we can push the subtree changes and bump gnome-shell-extension's sass submodule In other words: Updating the classic styling will become slightly more painful, but not much and only for me; in return, everyone else can stop fiddling with submodules (and buy me a beer).
2018-02-09 18:22:55 +00:00
border-radius: 32px; /* wish we could do 50% */
padding: 13px;
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00: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 18:22:55 +00:00
&:hover, &:focus {
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
background-color: $bubble_hover_bg_color;
color: $bubble_fg_color;
theme: Replace gnome-shell-sass submodule with subtree As the style has grown bigger and more complex, generating the different variants from a common source has been a good decision. However given how intertwined the theme is with gnome-shell itself, relying on a submodule has proven to be quite painful. And as things stand right now, it is going to get worse: - using either pre-generated CSS or generating it at build time is odd, and violates meson's strict separation between source- and build directories; we are therefore considering dropping the CSS and depending on sassc to always generate it at build time - with the migration to gitlab, our workflow shifts decisively towards branches; however there is no support in either git or gitlab for handling two brances of separate repositories consecutively, which gets particularly awkward for branches in a private namespace With those pain points in mind, we will adjust our setup as follows: - remove the submodule from gnome-shell and instead import the sass as subtree - after that, the sass sources can be changed like any other files in the repository, and regular contributors can forget that there was ever anything special about them - whenever we want to update the classic style, we can push the subtree changes and bump gnome-shell-extension's sass submodule In other words: Updating the classic styling will become slightly more painful, but not much and only for me; in return, everyone else can stop fiddling with submodules (and buy me a beer).
2018-02-09 18:22:55 +00:00
border: none;
padding: 14px;
}
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
&:active {
background-color: $bubble_active_bg_color;
color: $bubble_active_fg_color;
}
theme: Replace gnome-shell-sass submodule with subtree As the style has grown bigger and more complex, generating the different variants from a common source has been a good decision. However given how intertwined the theme is with gnome-shell itself, relying on a submodule has proven to be quite painful. And as things stand right now, it is going to get worse: - using either pre-generated CSS or generating it at build time is odd, and violates meson's strict separation between source- and build directories; we are therefore considering dropping the CSS and depending on sassc to always generate it at build time - with the migration to gitlab, our workflow shifts decisively towards branches; however there is no support in either git or gitlab for handling two brances of separate repositories consecutively, which gets particularly awkward for branches in a private namespace With those pain points in mind, we will adjust our setup as follows: - remove the submodule from gnome-shell and instead import the sass as subtree - after that, the sass sources can be changed like any other files in the repository, and regular contributors can forget that there was ever anything special about them - whenever we want to update the classic style, we can push the subtree changes and bump gnome-shell-extension's sass submodule In other words: Updating the classic styling will become slightly more painful, but not much and only for me; in return, everyone else can stop fiddling with submodules (and buy me a beer).
2018-02-09 18:22:55 +00:00
& > StIcon { icon-size: 16px; }
}
theme: Replace corner ripple png assets with css https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/298
2018-11-16 19:05:05 +00: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 18:22:55 +00:00
.ripple-box {
width: 52px;
height: 52px;
theme: Replace corner ripple png assets with css https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/298
2018-11-16 19:05:05 +00: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 18:22:55 +00:00
}
theme: Replace corner ripple png assets with css https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/298
2018-11-16 19:05:05 +00: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 18:22:55 +00:00
screenshot: Don't pick up rubberband style from GTK Selecting a screen area for a screenshot isn't the same as selecting items in an icon view, so there's no strong rationale for picking up the style from GTK. We stopped doing that for other elements like tile previews long ago, so just use our own style here too. https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/481
2019-04-04 14:03:54 +00:00
// Rubberband for select-area screenshots
.select-area-rubberband {
background-color: transparentize($selected_bg_color,0.7);
border: 1px 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 18:22:55 +00:00
// not really top bar only
theme: Fix menu arrows After the latest texture cache changes, loading the icon at its preferred size and scaling it via the actor size no longer works. Instead, use the icon-size property which is applied when loading the icon. https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/452
2019-03-10 20:57:54 +00: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 18:22:55 +00:00
.popup-menu-icon { icon-size: 1.09em; }
//close buttons
.window-close {
theme: Update window preview style - simplify the close button to use blue, lighter blue and darker blue solid disks for normal, hover and active states - use a milky, transparent white border for the hover effect of the border https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/461
2019-03-15 13:41:55 +00:00
background-color: $selected_bg_color;
color: white;
theme: Drop custom assets for window close buttons in overview They can be replaced by a themed icon and some CSS styling. https://gitlab.gnome.org/GNOME/gnome-shell/issues/782
2018-11-16 16:15:44 +00:00
border-radius: 24px;
theme: Update window preview style - simplify the close button to use blue, lighter blue and darker blue solid disks for normal, hover and active states - use a milky, transparent white border for the hover effect of the border https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/461
2019-03-15 13:41:55 +00:00
border: 2px solid $selected_bg_color;
theme: Drop custom assets for window close buttons in overview They can be replaced by a themed icon and some CSS styling. https://gitlab.gnome.org/GNOME/gnome-shell/issues/782
2018-11-16 16:15:44 +00:00
height: 24px;
width: 24px;
theme: Update window preview style - simplify the close button to use blue, lighter blue and darker blue solid disks for normal, hover and active states - use a milky, transparent white border for the hover effect of the border https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/461
2019-03-15 13:41:55 +00:00
-shell-close-overlap: 11px;
box-shadow: -1px 1px 5px 0px transparentize(black, 0.5);
theme: Drop custom assets for window close buttons in overview They can be replaced by a themed icon and some CSS styling. https://gitlab.gnome.org/GNOME/gnome-shell/issues/782
2018-11-16 16:15:44 +00:00
&:hover {
theme: Update window preview style - simplify the close button to use blue, lighter blue and darker blue solid disks for normal, hover and active states - use a milky, transparent white border for the hover effect of the border https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/461
2019-03-15 13:41:55 +00:00
background-color: lighten($selected_bg_color, 5%);
border-color: lighten($selected_bg_color, 5%);
theme: Drop custom assets for window close buttons in overview They can be replaced by a themed icon and some CSS styling. https://gitlab.gnome.org/GNOME/gnome-shell/issues/782
2018-11-16 16:15:44 +00:00
}
&:active {
theme: Update window preview style - simplify the close button to use blue, lighter blue and darker blue solid disks for normal, hover and active states - use a milky, transparent white border for the hover effect of the border https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/461
2019-03-15 13:41:55 +00:00
background-color: darken($selected_bg_color, 5%);
border-color: darken($selected_bg_color, 5%);
theme: Drop custom assets for window close buttons in overview They can be replaced by a themed icon and some CSS styling. https://gitlab.gnome.org/GNOME/gnome-shell/issues/782
2018-11-16 16:15:44 +00: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 18:22:55 +00:00
}
/* NETWORK DIALOGS */
.nm-dialog {
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00: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 18:22:55 +00: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 {
theme: Update window preview style - simplify the close button to use blue, lighter blue and darker blue solid disks for normal, hover and active states - use a milky, transparent white border for the hover effect of the border https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/461
2019-03-15 13:41:55 +00:00
$_bg: transparentize(white, 0.65);
border: 5px solid $_bg;
border-radius: 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 18:22:55 +00: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
theme: Update window preview style - simplify the close button to use blue, lighter blue and darker blue solid disks for normal, hover and active states - use a milky, transparent white border for the hover effect of the border https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/461
2019-03-15 13:41:55 +00: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 18:22:55 +00:00
.window-caption {
spacing: 25px;
color: $selected_fg_color;
background-color: $selected_bg_color;
border-radius: 8px;
padding: 4px 12px;
}
//search entry
.search-entry {
width: 320px;
padding: 7px 9px;
border-radius: 6px;
color: $osd_fg_color;
background-color: $osd_bg_color;
&:focus {
padding: 6px 8px;
border-width: 2px;
border-color: $selected_bg_color;
}
.search-entry-icon { icon-size: 1em; padding: 0 4px; color: transparentize($fg_color,.3); }
&:hover, &:focus {
.search-entry-icon { color: $fg_color; }
}
}
//search results
#searchResultsBin {
max-width: 1000px;
}
#searchResultsContent {
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); }
search: Hide the separator line of the last result If a result is displayed at the end of the search results, there should obviously not be a line separating it from the next result underneath it. To fix this, always hide the separator for the last result visible. https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/311
2018-11-24 23:45:19 +00: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 18:22:55 +00:00
.list-search-result-content { spacing: 30px; }
.list-search-result-title { color: darken($osd_fg_color,5%); spacing: 12px; }
.list-search-result-description { color: transparentize(darken($osd_fg_color,15%), 0.5); }
.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 {
font-size: 9pt;
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
color: $fg_color;
background-color: $osd_bg_color;
theme: Replace gnome-shell-sass submodule with subtree As the style has grown bigger and more complex, generating the different variants from a common source has been a good decision. However given how intertwined the theme is with gnome-shell itself, relying on a submodule has proven to be quite painful. And as things stand right now, it is going to get worse: - using either pre-generated CSS or generating it at build time is odd, and violates meson's strict separation between source- and build directories; we are therefore considering dropping the CSS and depending on sassc to always generate it at build time - with the migration to gitlab, our workflow shifts decisively towards branches; however there is no support in either git or gitlab for handling two brances of separate repositories consecutively, which gets particularly awkward for branches in a private namespace With those pain points in mind, we will adjust our setup as follows: - remove the submodule from gnome-shell and instead import the sass as subtree - after that, the sass sources can be changed like any other files in the repository, and regular contributors can forget that there was ever anything special about them - whenever we want to update the classic style, we can push the subtree changes and bump gnome-shell-extension's sass submodule In other words: Updating the classic styling will become slightly more painful, but not much and only for me; in return, everyone else can stop fiddling with submodules (and buy me a beer).
2018-02-09 18:22:55 +00:00
padding: 4px 0;
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00: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 18:22:55 +00:00
border-left: 0px;
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;
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00: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 18:22:55 +00: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;
&:checked { @include button(active); }
&:first-child {
border-right-width: 0;
border-radius: 3px 0 0 3px;
}
&:last-child {
border-radius: 0 3px 3px 0;
}
}
//Icon tile
.search-provider-icon,
.list-search-result {
@extend %icon_tile;
&:active, &:checked { background-color: transparentize(darken($osd_bg_color,10%),.1); }
&:focus, &:selected, &:hover {
background-color: transparentize($osd_fg_color,.9);
transition-duration: 200ms;
}
}
.app-well-app,
.app-well-app.app-folder,
.show-apps,
.grid-search-result {
& .overview-icon {
@extend %icon_tile;
}
&:active .overview-icon,
&:checked .overview-icon {
background-color: transparentize(darken($osd_bg_color,10%),.1);
box-shadow: inset 0 1px 2px $osd_borders_color;
}
&: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;
}
}
.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;
border-radius: 4px;
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;
-arrow-background-color: transparentize($osd_bg_color,0.7);
-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 {
theme: Replace page indicator assets with css https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/297
2018-11-16 18:44:52 +00:00
width: 12px;
height: 12px;
background-color: transparent;
border: 2px solid rgba(255, 255, 255, 0.4);
theme: Fix :checked:active page-indicator Closes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1036
2019-03-10 17:56:34 +00: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 18:22:55 +00:00
}
theme: Replace page indicator assets with css https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/297
2018-11-16 18:44:52 +00:00
&:hover .page-indicator-icon { border-color: white; }
theme: Fix :checked:active page-indicator Closes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1036
2019-03-10 17:56:34 +00: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 18:22:55 +00:00
&:checked .page-indicator-icon,
theme: Fix :checked:active page-indicator Closes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1036
2019-03-10 17:56:34 +00: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 18:22:55 +00: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 {
border: 4px solid $selected_bg_color;
padding: 1px;
}
//Some hacks I don't even
.search-display > StBoxLayout,
.all-apps,
.frequent-apps > StBoxLayout {
// horizontal padding to make sure scrollbars or dash don't overlap content
padding: 0px 88px 10px 88px;
}
%overview-panel {
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
color: $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 18:22:55 +00:00
}
%status_text {
font-size: 2em;
font-weight: bold;
color: $fg_color;
}
/* NOTIFICATIONS & MESSAGE TRAY */
.url-highlighter { link-color: lighten($selected_bg_color,10%); }
// Banners
.notification-banner {
font-size: 11pt;
width: 34em;
margin: 5px;
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
border-radius: $medium-radius;
border: none;
min-height: 64px;
box-shadow: 0 3px 9px 1px transparentize(black, 0.5);
&:hover { background: $bubble_bg_color; }
&, &:focus, &:active {
background-color: $bubble_bg_color;
.message-title { color: $bubble_fg_color }
.message-content { color: $bubble_fg_color; }
}
.message-icon-bin > StIcon {
color: $bubble_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 18:22:55 +00:00
.notification-content { padding: 5px; spacing: 5px; }
.secondary-icon { icon-size: 1.09em; }
.notification-actions {
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
padding-top: 0;
color: $bubble_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 18:22:55 +00:00
}
.notification-button {
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00: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 18:22:55 +00: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;
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
border: 2px solid $bubble_fg_color;
theme: Replace gnome-shell-sass submodule with subtree As the style has grown bigger and more complex, generating the different variants from a common source has been a good decision. However given how intertwined the theme is with gnome-shell itself, relying on a submodule has proven to be quite painful. And as things stand right now, it is going to get worse: - using either pre-generated CSS or generating it at build time is odd, and violates meson's strict separation between source- and build directories; we are therefore considering dropping the CSS and depending on sassc to always generate it at build time - with the migration to gitlab, our workflow shifts decisively towards branches; however there is no support in either git or gitlab for handling two brances of separate repositories consecutively, which gets particularly awkward for branches in a private namespace With those pain points in mind, we will adjust our setup as follows: - remove the submodule from gnome-shell and instead import the sass as subtree - after that, the sass sources can be changed like any other files in the repository, and regular contributors can forget that there was ever anything special about them - whenever we want to update the classic style, we can push the subtree changes and bump gnome-shell-extension's sass submodule In other words: Updating the classic styling will become slightly more painful, but not much and only for me; in return, everyone else can stop fiddling with submodules (and buy me a beer).
2018-02-09 18:22:55 +00:00
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; }
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
.chat-log-message { color: darken($bubble_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 18:22:55 +00:00
.chat-new-group { padding-top: 1em; }
.chat-received {
padding-left: 4px;
&:rtl { padding-left: 0px; padding-right: 4px; }
}
.chat-sent {
padding-left: 18pt;
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
color: lighten($bubble_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 18:22:55 +00:00
&:rtl { padding-left: 0; padding-right: 18pt; }
}
.chat-meta-message {
padding-left: 4px;
font-size: 9pt;
font-weight: bold;
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
color: lighten($bubble_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 18:22:55 +00:00
&:rtl { padding-left: 0; padding-right: 4px; }
}
//hotplug
.hotplug-transient-box {
spacing: 6px;
padding: 2px 72px 2px 12px;
}
.hotplug-notification-item {
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00: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 18:22:55 +00: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;
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
&:hover { background-color: $bubble_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 18:22:55 +00: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);
keyboard: Add Emoji keyboard This keyboard works similar to GTK+'s emoji chooser (actually, both pull from the same JSON file). Emojis are categorized in sections and variants and kept in a "model". The EmojiPager actor then uses this model to generate pages on-the-fly as the user swipes around. This is an important optimization since the amount of actors would rival with the rest of the shell otherwise. The EmojiSelection object puts the EmojiPager, the page indicators and a KeyContainer with the bottom row of emoji section shortcuts together to implement the emoji panel as a whole. The Keyboard object hooked this to an "emoji" key, which is just visible on the Clutter.InputContentPurpose where showing an emoji would be meaningful. Otherwise the surrounding buttons are made a bit wider to cover up for it (i.e. as it was before).
2017-12-22 15:02:51 +00: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 18:22:55 +00:00
}
.key-container {
padding: 4px;
spacing: 4px;
}
.keyboard-key {
background-color: #393f3f;
theme: Reduce minimum OSK key width/height The OSK panel uses 1/3rd of the monitor height, plus we specify a minimum size for the keys. This doesn't play along if contents won't fit (short monitor, big fonts, ...) pushing contents offscreen. Reduce the minimum size a bit so there's better chances to fit. Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/675
2019-01-21 20:34:27 +00:00
min-height: 1.2em;
min-width: 1.2em;
theme: Update OSK theme Enter/shift/layout/hide buttons have been made to use our own assets, key labels have been made slightly bigger, and incorrect padding has been removed from the extended keys popovers. https://gitlab.gnome.org/GNOME/gnome-shell/issues/46
2018-02-15 17:57:19 +00:00
font-size: 16pt;
theme: Replace gnome-shell-sass submodule with subtree As the style has grown bigger and more complex, generating the different variants from a common source has been a good decision. However given how intertwined the theme is with gnome-shell itself, relying on a submodule has proven to be quite painful. And as things stand right now, it is going to get worse: - using either pre-generated CSS or generating it at build time is odd, and violates meson's strict separation between source- and build directories; we are therefore considering dropping the CSS and depending on sassc to always generate it at build time - with the migration to gitlab, our workflow shifts decisively towards branches; however there is no support in either git or gitlab for handling two brances of separate repositories consecutively, which gets particularly awkward for branches in a private namespace With those pain points in mind, we will adjust our setup as follows: - remove the submodule from gnome-shell and instead import the sass as subtree - after that, the sass sources can be changed like any other files in the repository, and regular contributors can forget that there was ever anything special about them - whenever we want to update the classic style, we can push the subtree changes and bump gnome-shell-extension's sass submodule In other words: Updating the classic styling will become slightly more painful, but not much and only for me; in return, everyone else can stop fiddling with submodules (and buy me a beer).
2018-02-09 18:22:55 +00:00
border-radius: 3px;
border: 1px solid #464d4d;
color: #e5e5e5;
&:focus { @include button(focus); }
&:hover,&:checked { @include button(hover); }
&:active { @include button(active);}
&:grayed { //FIXME
background-color: $osd_bg_color;
color: $osd_fg_color;
border-color: $osd_borders_color;
}
&.default-key {
border-color: #2d3232;
background-color: #1d2020;
theme: Update OSK theme Enter/shift/layout/hide buttons have been made to use our own assets, key labels have been made slightly bigger, and incorrect padding has been removed from the extended keys popovers. https://gitlab.gnome.org/GNOME/gnome-shell/issues/46
2018-02-15 17:57:19 +00:00
background-size: 20px;
theme: Replace gnome-shell-sass submodule with subtree As the style has grown bigger and more complex, generating the different variants from a common source has been a good decision. However given how intertwined the theme is with gnome-shell itself, relying on a submodule has proven to be quite painful. And as things stand right now, it is going to get worse: - using either pre-generated CSS or generating it at build time is odd, and violates meson's strict separation between source- and build directories; we are therefore considering dropping the CSS and depending on sassc to always generate it at build time - with the migration to gitlab, our workflow shifts decisively towards branches; however there is no support in either git or gitlab for handling two brances of separate repositories consecutively, which gets particularly awkward for branches in a private namespace With those pain points in mind, we will adjust our setup as follows: - remove the submodule from gnome-shell and instead import the sass as subtree - after that, the sass sources can be changed like any other files in the repository, and regular contributors can forget that there was ever anything special about them - whenever we want to update the classic style, we can push the subtree changes and bump gnome-shell-extension's sass submodule In other words: Updating the classic styling will become slightly more painful, but not much and only for me; in return, everyone else can stop fiddling with submodules (and buy me a beer).
2018-02-09 18:22:55 +00:00
}
&.enter-key {
border-color: #005684;
background-color: #006098;
theme: Update OSK theme Enter/shift/layout/hide buttons have been made to use our own assets, key labels have been made slightly bigger, and incorrect padding has been removed from the extended keys popovers. https://gitlab.gnome.org/GNOME/gnome-shell/issues/46
2018-02-15 17:57:19 +00:00
background-image: url("resource:///org/gnome/shell/theme/key-enter.svg");
}
&.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 18:22:55 +00: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;
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00: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 18:22:55 +00:00
-arrow-base: 20px;
-arrow-rise: 10px;
-boxpointer-gap: 5px;
}
keyboard: Add Emoji keyboard This keyboard works similar to GTK+'s emoji chooser (actually, both pull from the same JSON file). Emojis are categorized in sections and variants and kept in a "model". The EmojiPager actor then uses this model to generate pages on-the-fly as the user swipes around. This is an important optimization since the amount of actors would rival with the rest of the shell otherwise. The EmojiSelection object puts the EmojiPager, the page indicators and a KeyContainer with the bottom row of emoji section shortcuts together to implement the emoji panel as a whole. The Keyboard object hooked this to an "emoji" key, which is just visible on the Clutter.InputContentPurpose where showing an emoji would be meaningful. Otherwise the surrounding buttons are made a bit wider to cover up for it (i.e. as it was before).
2017-12-22 15:02:51 +00:00
.emoji-page {
.keyboard-key {
background-color: transparent;
border: none;
}
}
.emoji-panel {
.keyboard-key:latched {
border-color: #005684;
background-color: #006098;
}
}
theme: Replace gnome-shell-sass submodule with subtree As the style has grown bigger and more complex, generating the different variants from a common source has been a good decision. However given how intertwined the theme is with gnome-shell itself, relying on a submodule has proven to be quite painful. And as things stand right now, it is going to get worse: - using either pre-generated CSS or generating it at build time is odd, and violates meson's strict separation between source- and build directories; we are therefore considering dropping the CSS and depending on sassc to always generate it at build time - with the migration to gitlab, our workflow shifts decisively towards branches; however there is no support in either git or gitlab for handling two brances of separate repositories consecutively, which gets particularly awkward for branches in a private namespace With those pain points in mind, we will adjust our setup as follows: - remove the submodule from gnome-shell and instead import the sass as subtree - after that, the sass sources can be changed like any other files in the repository, and regular contributors can forget that there was ever anything special about them - whenever we want to update the classic style, we can push the subtree changes and bump gnome-shell-extension's sass submodule In other words: Updating the classic styling will become slightly more painful, but not much and only for me; in return, everyone else can stop fiddling with submodules (and buy me a beer).
2018-02-09 18:22:55 +00:00
// 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 */
userWidget: Remove frame around avatar There's a push for round user images, for which the existing square frame is a bad match. So remove the frame and enforce the shape. https://gitlab.gnome.org/GNOME/gnome-shell/issues/811
2019-02-05 16:28:41 +00: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 18:22:55 +00:00
background-size: contain;
color: $osd_fg_color;
userWidget: Remove frame around avatar There's a push for round user images, for which the existing square frame is a bad match. So remove the frame and enforce the shape. https://gitlab.gnome.org/GNOME/gnome-shell/issues/811
2019-02-05 16:28:41 +00: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 18:22:55 +00: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;
.modal-dialog-button-box { spacing: 3px; }
.modal-dialog-button {
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
padding: 4px 18px;
theme: Replace gnome-shell-sass submodule with subtree As the style has grown bigger and more complex, generating the different variants from a common source has been a good decision. However given how intertwined the theme is with gnome-shell itself, relying on a submodule has proven to be quite painful. And as things stand right now, it is going to get worse: - using either pre-generated CSS or generating it at build time is odd, and violates meson's strict separation between source- and build directories; we are therefore considering dropping the CSS and depending on sassc to always generate it at build time - with the migration to gitlab, our workflow shifts decisively towards branches; however there is no support in either git or gitlab for handling two brances of separate repositories consecutively, which gets particularly awkward for branches in a private namespace With those pain points in mind, we will adjust our setup as follows: - remove the submodule from gnome-shell and instead import the sass as subtree - after that, the sass sources can be changed like any other files in the repository, and regular contributors can forget that there was ever anything special about them - whenever we want to update the classic style, we can push the subtree changes and bump gnome-shell-extension's sass submodule In other words: Updating the classic styling will become slightly more painful, but not much and only for me; in return, everyone else can stop fiddling with submodules (and buy me a beer).
2018-02-09 18:22:55 +00:00
&:default {
@include button(normal,$c:$selected_bg_color);
&:hover,&:focus { @include button(hover,$c:$selected_bg_color); }
&:active { @include button(active,$c:$selected_bg_color); }
&:insensitive { @include button(insensitive); }
}
}
}
.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;
theme: Use a padding of 6px on the user-list items according to HIG
2018-04-07 19:23:22 +00: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 18:22:55 +00:00
color: darken($osd_fg_color,30%);
theme: Improve look of login user-list * Remove tiny padding of user-list * Less space between avatar and username * Apply the 1em padding only to the user-widget, not the timed-login-indicator
2018-04-08 10:25:32 +00: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 18:22:55 +00:00
.login-dialog-timed-login-indicator {
height: 2px;
theme: Use a padding of 6px on the user-list items according to HIG
2018-04-07 19:23:22 +00: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 18:22:55 +00: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 {
theme: Improve look of login user-list * Remove tiny padding of user-list * Less space between avatar and username * Apply the 1em padding only to the user-widget, not the timed-login-indicator
2018-04-08 10:25:32 +00: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 18:22:55 +00: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
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00: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 18:22:55 +00:00
.screen-shield-arrows {
padding-bottom: 3em;
}
.screen-shield-arrows Gjs_Arrow {
color: white;
width: 80px;
height: 48px;
-arrow-thickness: 12px;
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00: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 18:22:55 +00:00
}
.screen-shield-clock {
color: white;
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
text-shadow: $_screenshield_shadow;
theme: use cantarell light - lock screen - date in the calendar popover fixes issue #45
2018-02-14 15:42:56 +00: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 18:22:55 +00:00
text-align: center;
padding-bottom: 1.5em;
}
.screen-shield-clock-time {
font-size: 72pt;
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00:00
text-shadow: $_screenshield_shadow;
theme: Use tabular figures where appropriate In places where numbers appear in columns (like the calendar widget) or where changing numbers would result in labels jiggling around due to small width changes (like the clock), use the newly added font-feature-settings support to request tabular figures. https://gitlab.gnome.org/GNOME/gnome-shell/issues/34
2018-05-17 14:45:02 +00: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 18:22:55 +00:00
}
theme: use cantarell light - lock screen - date in the calendar popover fixes issue #45
2018-02-14 15:42:56 +00:00
.screen-shield-clock-date {
theme: use cantarell light - lock screen - date in the calendar popover fixes issue #45
2018-02-14 15:42:56 +00:00
font-size: 28pt;
theme: use cantarell light - lock screen - date in the calendar popover fixes issue #45
2018-02-14 15:42:56 +00: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 18:22:55 +00: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;
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00: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 18:22:55 +00:00
background-color: transparentize($osd_bg_color,0.5);
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00: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 18:22:55 +00: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; }
Shell theme renew - light colored, bubble-like popovers, dialogues and notifications - unified OSD colors for OSD elements - small shadow for OSD elements to improve visibility above dark backgrounds - small screenshield shadow improvements - slightly bigger GDM buttons - rounder buttons, rounder entries - flatter entries
2019-05-29 12:47:42 +00: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 18:22:55 +00:00
.screen-shield-background { //just the shadow, really
background: black;
box-shadow: 0px 2px 4px transparentize(black,0.6);
}
#lockDialogGroup {
background: #2e3436 url(resource:///org/gnome/shell/theme/noise-texture.png);
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;
}
Reference in New Issue Copy Permalink