gnome-shell/data/theme/gnome-shell-sass/_common.scss

240 lines
6.1 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 13:22:55 -05:00
//This is the RIGHT PLACE to edit the stylesheet
//let's start by telling people not to edit the generated CSS:
$cakeisalie: "This stylesheet is generated, DO NOT EDIT";
/* #{$cakeisalie} */
/* Copyright 2009, 2015 Red Hat, Inc.
*
* Portions adapted from Mx's data/style/default.css
* Copyright 2009 Intel Corporation
*
* This program is free software; you can redistribute it and/or modify it
* under the terms and conditions of the GNU Lesser General Public License,
* version 2.1, as published by the Free Software Foundation.
*
* This program is distributed in the hope it will be useful, but WITHOUT ANY
* WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
* FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for
* more details.
*
* You should have received a copy of the GNU Lesser General Public License
* along with this program; if not, write to the Free Software Foundation,
* Inc., 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
*/
/* Global Values */
// padding, margin and spacing
$base_padding: 6px;
$base_margin: 4px;
$base_spacing: 6px;
// border radii
$base_border_radius: 5px;
$modal_radius:$base_border_radius * 2;
// non-standard colors
$bubble_borders_color: lighten($borders_color, if($variant=='light', 0%, 5%));
// $bubble_borders_color: if($variant == 'light', rgba(255,255,255,0.1), rgba(0,0,0,0.3));
theme: Replace gnome-shell-sass submodule with subtree As the style has grown bigger and more complex, generating the different variants from a common source has been a good decision. However given how intertwined the theme is with gnome-shell itself, relying on a submodule has proven to be quite painful. And as things stand right now, it is going to get worse: - using either pre-generated CSS or generating it at build time is odd, and violates meson's strict separation between source- and build directories; we are therefore considering dropping the CSS and depending on sassc to always generate it at build time - with the migration to gitlab, our workflow shifts decisively towards branches; however there is no support in either git or gitlab for handling two brances of separate repositories consecutively, which gets particularly awkward for branches in a private namespace With those pain points in mind, we will adjust our setup as follows: - remove the submodule from gnome-shell and instead import the sass as subtree - after that, the sass sources can be changed like any other files in the repository, and regular contributors can forget that there was ever anything special about them - whenever we want to update the classic style, we can push the subtree changes and bump gnome-shell-extension's sass submodule In other words: Updating the classic styling will become slightly more painful, but not much and only for me; in return, everyone else can stop fiddling with submodules (and buy me a beer).
2018-02-09 13:22:55 -05:00
// hover
$hover_bg_color: if($variant=='light', darken($bg_color, 3%), lighten($bg_color, 5%));
$hover_fg_color: if($variant=='light', darken($fg_color, 5%), lighten($fg_color, 5%));
$hover_borders_color: lighten($borders_color,if($variant=='light', 5%, 3%));
// active
$active_bg_color: if($variant == 'light', darken($bg_color, 7%), darken($bg_color, 9%));
$active_fg_color: darken($fg_color,if($variant=='light', 5%, 3%));
$active_borders_color: darken($borders_color,if($variant=='light', 5%, 3%));
// fonts
$base_font_size: 11;
$text_shadow_color: if($variant == 'light', rgba(255,255,255,0.3), rgba(0,0,0,0.2));
theme: Replace gnome-shell-sass submodule with subtree As the style has grown bigger and more complex, generating the different variants from a common source has been a good decision. However given how intertwined the theme is with gnome-shell itself, relying on a submodule has proven to be quite painful. And as things stand right now, it is going to get worse: - using either pre-generated CSS or generating it at build time is odd, and violates meson's strict separation between source- and build directories; we are therefore considering dropping the CSS and depending on sassc to always generate it at build time - with the migration to gitlab, our workflow shifts decisively towards branches; however there is no support in either git or gitlab for handling two brances of separate repositories consecutively, which gets particularly awkward for branches in a private namespace With those pain points in mind, we will adjust our setup as follows: - remove the submodule from gnome-shell and instead import the sass as subtree - after that, the sass sources can be changed like any other files in the repository, and regular contributors can forget that there was ever anything special about them - whenever we want to update the classic style, we can push the subtree changes and bump gnome-shell-extension's sass submodule In other words: Updating the classic styling will become slightly more painful, but not much and only for me; in return, everyone else can stop fiddling with submodules (and buy me a beer).
2018-02-09 13:22:55 -05:00
// icons
// $base_icon_size: 1.09em;
$base_icon_size: 16px;
theme: Replace gnome-shell-sass submodule with subtree As the style has grown bigger and more complex, generating the different variants from a common source has been a good decision. However given how intertwined the theme is with gnome-shell itself, relying on a submodule has proven to be quite painful. And as things stand right now, it is going to get worse: - using either pre-generated CSS or generating it at build time is odd, and violates meson's strict separation between source- and build directories; we are therefore considering dropping the CSS and depending on sassc to always generate it at build time - with the migration to gitlab, our workflow shifts decisively towards branches; however there is no support in either git or gitlab for handling two brances of separate repositories consecutively, which gets particularly awkward for branches in a private namespace With those pain points in mind, we will adjust our setup as follows: - remove the submodule from gnome-shell and instead import the sass as subtree - after that, the sass sources can be changed like any other files in the repository, and regular contributors can forget that there was ever anything special about them - whenever we want to update the classic style, we can push the subtree changes and bump gnome-shell-extension's sass submodule In other words: Updating the classic styling will become slightly more painful, but not much and only for me; in return, everyone else can stop fiddling with submodules (and buy me a beer).
2018-02-09 13:22:55 -05:00
// Stage
stage {
@include fontsize($base_font_size);
color: $fg_color;
theme: Replace gnome-shell-sass submodule with subtree As the style has grown bigger and more complex, generating the different variants from a common source has been a good decision. However given how intertwined the theme is with gnome-shell itself, relying on a submodule has proven to be quite painful. And as things stand right now, it is going to get worse: - using either pre-generated CSS or generating it at build time is odd, and violates meson's strict separation between source- and build directories; we are therefore considering dropping the CSS and depending on sassc to always generate it at build time - with the migration to gitlab, our workflow shifts decisively towards branches; however there is no support in either git or gitlab for handling two brances of separate repositories consecutively, which gets particularly awkward for branches in a private namespace With those pain points in mind, we will adjust our setup as follows: - remove the submodule from gnome-shell and instead import the sass as subtree - after that, the sass sources can be changed like any other files in the repository, and regular contributors can forget that there was ever anything special about them - whenever we want to update the classic style, we can push the subtree changes and bump gnome-shell-extension's sass submodule In other words: Updating the classic styling will become slightly more painful, but not much and only for me; in return, everyone else can stop fiddling with submodules (and buy me a beer).
2018-02-09 13:22:55 -05:00
}
/* WIDGETS */
@import 'widgets/app-grid';
@import 'widgets/app-switcher';
@import 'widgets/buttons';
@import 'widgets/calendar';
@import 'widgets/check-box';
@import 'widgets/corner-ripple';
@import 'widgets/dash';
@import 'widgets/dialogs';
@import 'widgets/end-session-dialog';
@import 'widgets/entries';
@import 'widgets/hotplug';
@import 'widgets/ibus-popup';
@import 'widgets/keyboard';
@import 'widgets/login-dialog';
@import 'widgets/looking-glass';
@import 'widgets/message-list';
@import 'widgets/notifications';
@import 'widgets/misc';
@import 'widgets/network-dialog';
@import 'widgets/osd';
@import 'widgets/overview';
@import 'widgets/panel';
@import 'widgets/popovers';
@import 'widgets/screen-shield';
@import 'widgets/scrollbars';
@import 'widgets/search-entry';
@import 'widgets/search-results';
@import 'widgets/slider';
@import 'widgets/switches';
@import 'widgets/tiled-previews';
@import 'widgets/window-picker';
@import 'widgets/workspace-switcher';
/* Common Stylings */
// Text
theme: Replace gnome-shell-sass submodule with subtree As the style has grown bigger and more complex, generating the different variants from a common source has been a good decision. However given how intertwined the theme is with gnome-shell itself, relying on a submodule has proven to be quite painful. And as things stand right now, it is going to get worse: - using either pre-generated CSS or generating it at build time is odd, and violates meson's strict separation between source- and build directories; we are therefore considering dropping the CSS and depending on sassc to always generate it at build time - with the migration to gitlab, our workflow shifts decisively towards branches; however there is no support in either git or gitlab for handling two brances of separate repositories consecutively, which gets particularly awkward for branches in a private namespace With those pain points in mind, we will adjust our setup as follows: - remove the submodule from gnome-shell and instead import the sass as subtree - after that, the sass sources can be changed like any other files in the repository, and regular contributors can forget that there was ever anything special about them - whenever we want to update the classic style, we can push the subtree changes and bump gnome-shell-extension's sass submodule In other words: Updating the classic styling will become slightly more painful, but not much and only for me; in return, everyone else can stop fiddling with submodules (and buy me a beer).
2018-02-09 13:22:55 -05:00
%status_text {
font-size: 2em;
font-weight: bold;
color: $osd_fg_color;
}
// osd panels
%osd_panel {
color: $osd_fg_color;
background-color: $osd_bg_color;
border: 1px solid $osd_outer_borders_color;
border-radius: $base_border_radius * 2 + 4px;
padding: $base_padding * 2;
}
// Overview panels
// for the dash and workspace switcher
%overview_panel {
color: $osd_fg_color;
background-color: transparentize($osd_bg_color, 0.2);
border: 1px solid $osd_outer_borders_color;
}
// icon tiles
%icon_tile {
background-color: transparent; // no background
color: $osd_fg_color;
border-radius: $base_border_radius + 4px;
padding: $base_padding;
border: 2px solid transparent;
transition-duration: 100ms;
text-align: center;
}
// dialogs
%bubble_panel {
color: $fg_color;
background-color: $bg_color;
border: 1px solid if($variant=='light', rgba(0,0,0, 0.6), $borders_color);
// entry
StEntry { @extend %bubble_entry;}
// button
.button {
background-color: $bg_color;
color: $fg_color;
box-shadow: none;
&, &:hover, &:focus, &:active, &:disabled {
border-color: $bubble_borders_color;
}
&:hover { background-color: $hover_bg_color;}
&:active {
background-color: $selected_bg_color;
color: $selected_fg_color;
}
&:disabled { color: $insensitive_fg_color;}
}
}
// entries in dialogs
%bubble_entry {
color: $fg_color;
background-color: darken($bg_color, 2%);
border-color: $bubble_borders_color;
box-shadow: none;
&:focus { border: 2px solid $selected_bg_color;}
}
// buttons in dialogs
%bubble_button {
@include button(normal);
padding: $base_padding * 2;
border-color: $bubble_borders_color;
border-style: solid;
border-width: 0 !important;
border-top-width: 1px !important;
box-shadow:none !important;
&:insensitive { @include button(insensitive);}
&:hover { @include button(hover);}
&:focus { @include button(focus);}
&:active { @include button(active);}
// radius is 2 pixel less to fit in bubble
&:first-child {
border-right-width: 1px !important;
border-radius: 0px 0px 0px $modal_radius - 2px;
}
&:last-child {
border-right-width: 0 !important;
border-radius: 0px 0px $modal_radius - 2px 0px;
}
&:first-child:last-child {
border-radius: 0px 0px $modal_radius - 2px $modal_radius - 2px;
}
}
// button styling
%button {
border-radius: $base_border_radius;
border-width: 1px;
min-height: 22px;
padding: $base_padding * 0.5 $base_padding * 4;
@include button(normal);
&:focus { @include button(focus);}
&:hover { @include button(hover);}
&:insensitive { @include button(insensitive);}
&:active { @include button(active);}
}
// notification styling
%notification_bubble {
border-radius:$base_border_radius + 2px;
padding: 0;
margin: $base_margin;
@include button(normal);
&:focus,
&:hover {
// margin-top: $base_margin - 1px;
// margin-bottom: $base_margin + 1px;
@include button(hover);
}
&:active {
@include button(active);
// margin: $base_margin;
}
}