awesomewm-mirrors
/
awesome
mirror of https://github.com/awesomeWM/awesome.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
awesome/docs/common/client_theme.ldoc

567 lines
12 KiB
Plaintext
Raw Normal View History

client: Turn `rc.lua` logic into a new `request::border` signal. The default `rc.lua` was using the focus/unfocus signals to set the border color along with `awful.rules`. This logic block was no longer aligned with the rest of `rc.lua` since it was the only place where `beautiful` variables where only used by `rc.lua`. On top of this, the new request handler also has extra contexts for the urgent and floating/maximixed use cases. So it can be used by themes to implement much smarter borders than just focus based ones. They were previously limited by the fact most of the (un-monkey-patchable) logic was in `rc.lua`. Note that this commit also shuffle the awful.rules order between the titlebar and the border and changes the tests accordignly. After some consideration, I came to the conclusion the previous behavior was bogus and the fact that the placement tests required to know about the titlebar height is simply a proof of that. The change was required in this commit because since the border is no longer in the default rules, a new buggy edge case surfaced.
2019-11-11 02:47:43 +01:00
*/
Border_marked naming consistency (#3084) * finish renaming border_marked to border_color_marked * doc: document border_color_fullscreen, update border_color_marked and fix typo * deprecate instead of removing * doc: fix border_color_marked
2020-05-04 10:42:09 +02:00
/**
* The border color when the client is marked.
* It has priority over the rest of beautiful border color properties.
* Note that only solid colors are supported.
* @beautiful beautiful.border_color_marked
* @param color
* @see request::border
*/
client: Turn `rc.lua` logic into a new `request::border` signal. The default `rc.lua` was using the focus/unfocus signals to set the border color along with `awful.rules`. This logic block was no longer aligned with the rest of `rc.lua` since it was the only place where `beautiful` variables where only used by `rc.lua`. On top of this, the new request handler also has extra contexts for the urgent and floating/maximixed use cases. So it can be used by themes to implement much smarter borders than just focus based ones. They were previously limited by the fact most of the (un-monkey-patchable) logic was in `rc.lua`. Note that this commit also shuffle the awful.rules order between the titlebar and the border and changes the tests accordignly. After some consideration, I came to the conclusion the previous behavior was bogus and the fact that the placement tests required to know about the titlebar height is simply a proof of that. The change was required in this commit because since the border is no longer in the default rules, a new buggy edge case surfaced.
2019-11-11 02:47:43 +01:00
/**
* The fallback border color when the client is floating.
*
* @beautiful beautiful.border_color_floating
* @param color
* @see request::border
* @see beautiful.border_color_floating_active
* @see beautiful.border_color_floating_normal
* @see beautiful.border_color_floating_urgent
* @see beautiful.border_color_floating_new
*/
/**
Border_marked naming consistency (#3084) * finish renaming border_marked to border_color_marked * doc: document border_color_fullscreen, update border_color_marked and fix typo * deprecate instead of removing * doc: fix border_color_marked
2020-05-04 10:42:09 +02:00
* The fallback border color when the client is maximized.
client: Turn `rc.lua` logic into a new `request::border` signal. The default `rc.lua` was using the focus/unfocus signals to set the border color along with `awful.rules`. This logic block was no longer aligned with the rest of `rc.lua` since it was the only place where `beautiful` variables where only used by `rc.lua`. On top of this, the new request handler also has extra contexts for the urgent and floating/maximixed use cases. So it can be used by themes to implement much smarter borders than just focus based ones. They were previously limited by the fact most of the (un-monkey-patchable) logic was in `rc.lua`. Note that this commit also shuffle the awful.rules order between the titlebar and the border and changes the tests accordignly. After some consideration, I came to the conclusion the previous behavior was bogus and the fact that the placement tests required to know about the titlebar height is simply a proof of that. The change was required in this commit because since the border is no longer in the default rules, a new buggy edge case surfaced.
2019-11-11 02:47:43 +01:00
*
Border_marked naming consistency (#3084) * finish renaming border_marked to border_color_marked * doc: document border_color_fullscreen, update border_color_marked and fix typo * deprecate instead of removing * doc: fix border_color_marked
2020-05-04 10:42:09 +02:00
* @beautiful beautiful.border_color_maximized
client: Turn `rc.lua` logic into a new `request::border` signal. The default `rc.lua` was using the focus/unfocus signals to set the border color along with `awful.rules`. This logic block was no longer aligned with the rest of `rc.lua` since it was the only place where `beautiful` variables where only used by `rc.lua`. On top of this, the new request handler also has extra contexts for the urgent and floating/maximixed use cases. So it can be used by themes to implement much smarter borders than just focus based ones. They were previously limited by the fact most of the (un-monkey-patchable) logic was in `rc.lua`. Note that this commit also shuffle the awful.rules order between the titlebar and the border and changes the tests accordignly. After some consideration, I came to the conclusion the previous behavior was bogus and the fact that the placement tests required to know about the titlebar height is simply a proof of that. The change was required in this commit because since the border is no longer in the default rules, a new buggy edge case surfaced.
2019-11-11 02:47:43 +01:00
* @param color
* @see request::border
* @see beautiful.border_color_maximized_active
* @see beautiful.border_color_maximized_normal
* @see beautiful.border_color_maximized_urgent
* @see beautiful.border_color_maximized_new
*/
Border_marked naming consistency (#3084) * finish renaming border_marked to border_color_marked * doc: document border_color_fullscreen, update border_color_marked and fix typo * deprecate instead of removing * doc: fix border_color_marked
2020-05-04 10:42:09 +02:00
/**
* The fallback border color when the client is fullscreen.
*
* @beautiful beautiful.border_color_fullscreen
* @param color
* @see request::border
* @see beautiful.border_color_fullscreen_active
* @see beautiful.border_color_fullscreen_normal
* @see beautiful.border_color_fullscreen_urgent
* @see beautiful.border_color_fullscreen_new
*/
client: Turn `rc.lua` logic into a new `request::border` signal. The default `rc.lua` was using the focus/unfocus signals to set the border color along with `awful.rules`. This logic block was no longer aligned with the rest of `rc.lua` since it was the only place where `beautiful` variables where only used by `rc.lua`. On top of this, the new request handler also has extra contexts for the urgent and floating/maximixed use cases. So it can be used by themes to implement much smarter borders than just focus based ones. They were previously limited by the fact most of the (un-monkey-patchable) logic was in `rc.lua`. Note that this commit also shuffle the awful.rules order between the titlebar and the border and changes the tests accordignly. After some consideration, I came to the conclusion the previous behavior was bogus and the fact that the placement tests required to know about the titlebar height is simply a proof of that. The change was required in this commit because since the border is no longer in the default rules, a new buggy edge case surfaced.
2019-11-11 02:47:43 +01:00
/**
* The border color when the client is active.
*
* @beautiful beautiful.border_color_active
* @param color
* @see request::border
*/
/**
* The border color when the client is not active.
*
* @beautiful beautiful.border_color_normal
* @param color
* @see request::border
*/
/**
* The border color when the client has the urgent property set.
*
* @beautiful beautiful.border_color_urgent
* @param color
* @see request::border
*/
/**
* The border color when the client is not active and new.
*
* @beautiful beautiful.border_color_new
* @param color
* @see request::border
*/
/**
* The border color when the (floating) client is active.
*
* @beautiful beautiful.border_color_floating_active
* @param color
* @see request::border
*/
/**
* The border color when the (floating) client is not active.
*
* @beautiful beautiful.border_color_floating_normal
* @param color
* @see request::border
*/
/**
* The border color when the (floating) client has the urgent property set.
*
* @beautiful beautiful.border_color_floating_urgent
* @param color
* @see request::border
*/
/**
* The border color when the (floating) client is not active and new.
*
* @beautiful beautiful.border_color_floating_new
* @param color
* @see request::border
*/
/**
* The border color when the (maximized) client is active.
*
* @beautiful beautiful.border_color_maximized_active
* @param color
* @see request::border
*/
/**
* The border color when the (maximized) client is not active.
*
* @beautiful beautiful.border_color_maximized_normal
* @param color
* @see request::border
*/
/**
* The border color when the (maximized) client has the urgent property set.
*
* @beautiful beautiful.border_color_maximized_urgent
* @param color
* @see request::border
*/
/**
* The border color when the (maximized) client is not active and new.
*
* @beautiful beautiful.border_color_maximized_new
* @param color
* @see request::border
*/
/**
* The border color when the (fullscreen) client is active.
*
* @beautiful beautiful.border_color_fullscreen_active
* @param color
* @see request::border
*/
/**
* The border color when the (fullscreen) client is not active.
*
* @beautiful beautiful.border_color_fullscreen_normal
* @param color
* @see request::border
*/
/**
* The border color when the (fullscreen) client has the urgent property set.
*
* @beautiful beautiful.border_color_fullscreen_urgent
* @param color
* @see request::border
*/
/**
* The border color when the (fullscreen) client is not active and new.
*
* @beautiful beautiful.border_color_fullscreen_new
* @param color
* @see request::border
*/
/**
* The fallback border width when nothing else is set.
*
* @beautiful beautiful.border_width
* @param integer
* @see request::border
* @see beautiful.border_width_floating
Border_marked naming consistency (#3084) * finish renaming border_marked to border_color_marked * doc: document border_color_fullscreen, update border_color_marked and fix typo * deprecate instead of removing * doc: fix border_color_marked
2020-05-04 10:42:09 +02:00
* @see beautiful.border_width_maximized
client: Turn `rc.lua` logic into a new `request::border` signal. The default `rc.lua` was using the focus/unfocus signals to set the border color along with `awful.rules`. This logic block was no longer aligned with the rest of `rc.lua` since it was the only place where `beautiful` variables where only used by `rc.lua`. On top of this, the new request handler also has extra contexts for the urgent and floating/maximixed use cases. So it can be used by themes to implement much smarter borders than just focus based ones. They were previously limited by the fact most of the (un-monkey-patchable) logic was in `rc.lua`. Note that this commit also shuffle the awful.rules order between the titlebar and the border and changes the tests accordignly. After some consideration, I came to the conclusion the previous behavior was bogus and the fact that the placement tests required to know about the titlebar height is simply a proof of that. The change was required in this commit because since the border is no longer in the default rules, a new buggy edge case surfaced.
2019-11-11 02:47:43 +01:00
* @see beautiful.border_width_floating_active
* @see beautiful.border_width_floating_normal
* @see beautiful.border_width_floating_urgent
* @see beautiful.border_width_floating_new
* @see beautiful.border_width_maximized_active
* @see beautiful.border_width_maximized_normal
* @see beautiful.border_width_maximized_urgent
* @see beautiful.border_width_maximized_new
*/
/**
* The fallback border width when the client is floating.
*
* @beautiful beautiful.border_width_floating
* @param integer
* @see request::border
* @see beautiful.border_width_floating_active
* @see beautiful.border_width_floating_normal
* @see beautiful.border_width_floating_urgent
* @see beautiful.border_width_floating_new
*/
/**
Border_marked naming consistency (#3084) * finish renaming border_marked to border_color_marked * doc: document border_color_fullscreen, update border_color_marked and fix typo * deprecate instead of removing * doc: fix border_color_marked
2020-05-04 10:42:09 +02:00
* The fallback border width when the client is maximized.
client: Turn `rc.lua` logic into a new `request::border` signal. The default `rc.lua` was using the focus/unfocus signals to set the border color along with `awful.rules`. This logic block was no longer aligned with the rest of `rc.lua` since it was the only place where `beautiful` variables where only used by `rc.lua`. On top of this, the new request handler also has extra contexts for the urgent and floating/maximixed use cases. So it can be used by themes to implement much smarter borders than just focus based ones. They were previously limited by the fact most of the (un-monkey-patchable) logic was in `rc.lua`. Note that this commit also shuffle the awful.rules order between the titlebar and the border and changes the tests accordignly. After some consideration, I came to the conclusion the previous behavior was bogus and the fact that the placement tests required to know about the titlebar height is simply a proof of that. The change was required in this commit because since the border is no longer in the default rules, a new buggy edge case surfaced.
2019-11-11 02:47:43 +01:00
*
Border_marked naming consistency (#3084) * finish renaming border_marked to border_color_marked * doc: document border_color_fullscreen, update border_color_marked and fix typo * deprecate instead of removing * doc: fix border_color_marked
2020-05-04 10:42:09 +02:00
* @beautiful beautiful.border_width_maximized
client: Turn `rc.lua` logic into a new `request::border` signal. The default `rc.lua` was using the focus/unfocus signals to set the border color along with `awful.rules`. This logic block was no longer aligned with the rest of `rc.lua` since it was the only place where `beautiful` variables where only used by `rc.lua`. On top of this, the new request handler also has extra contexts for the urgent and floating/maximixed use cases. So it can be used by themes to implement much smarter borders than just focus based ones. They were previously limited by the fact most of the (un-monkey-patchable) logic was in `rc.lua`. Note that this commit also shuffle the awful.rules order between the titlebar and the border and changes the tests accordignly. After some consideration, I came to the conclusion the previous behavior was bogus and the fact that the placement tests required to know about the titlebar height is simply a proof of that. The change was required in this commit because since the border is no longer in the default rules, a new buggy edge case surfaced.
2019-11-11 02:47:43 +01:00
* @param integer
* @see request::border
* @see beautiful.border_width_maximized_active
* @see beautiful.border_width_maximized_normal
* @see beautiful.border_width_maximized_urgent
* @see beautiful.border_width_maximized_new
*/
/**
* The client border width for the normal clients.
*
* @beautiful beautiful.border_width_normal
* @param integer
* @see request::border
*/
/**
* The client border width for the active client.
*
* @beautiful beautiful.border_width_active
* @param integer
* @see request::border
*/
/**
* The client border width for the urgent clients.
*
* @beautiful beautiful.border_width_urgent
* @param integer
* @see request::border
*/
/**
* The client border width for the new clients.
*
* @beautiful beautiful.border_width_new
* @param integer
* @see request::border
*/
/**
* The client border width for the normal floating clients.
*
* @beautiful beautiful.border_width_floating_normal
* @param integer
* @see request::border
*/
/**
* The client border width for the active floating client.
*
* @beautiful beautiful.border_width_floating_active
* @param integer
* @see request::border
*/
/**
* The client border width for the urgent floating clients.
*
* @beautiful beautiful.border_width_floating_urgent
* @param integer
* @see request::border
*/
/**
* The client border width for the new floating clients.
*
* @beautiful beautiful.border_width_floating_new
* @param integer
* @see request::border
*/
/**
* The client border width for the normal maximized clients.
*
* @beautiful beautiful.border_width_maximized_normal
* @param integer
* @see request::border
*/
/**
* The client border width for the active maximized client.
*
* @beautiful beautiful.border_width_maximized_active
* @param integer
* @see request::border
*/
/**
* The client border width for the urgent maximized clients.
*
* @beautiful beautiful.border_width_maximized_urgent
* @param integer
* @see request::border
*/
/**
* The client border width for the new maximized clients.
*
* @beautiful beautiful.border_width_maximized_new
* @param integer
* @see request::border
*/
/**
* The client border width for the normal fullscreen clients.
*
* @beautiful beautiful.border_width_fullscreen_normal
* @param integer
* @see request::border
*/
/**
* The client border width for the active fullscreen client.
*
* @beautiful beautiful.border_width_fullscreen_active
* @param integer
* @see request::border
*/
/**
* The client border width for the urgent fullscreen clients.
*
* @beautiful beautiful.border_width_fullscreen_urgent
* @param integer
* @see request::border
*/
/**
* The client border width for the new fullscreen clients.
*
* @beautiful beautiful.border_width_fullscreen_new
* @param integer
* @see request::border
*/
doc: Add documentation linting and fix all issues it found.
2021-12-21 06:54:15 +01:00
/**
* The client border width for the fullscreen clients.
*
* This is the fallback if the more stateful version, like
* `beautiful.border_width_fullscreen_urgent` isn't set.
*
* @beautiful beautiful.border_width_fullscreen
* @param integer
* @see request::border
* @see beautiful.border_width_fullscreen_active
* @see beautiful.border_width_fullscreen_normal
* @see beautiful.border_width_fullscreen_urgent
* @see beautiful.border_width_fullscreen_new
*/
client: Turn `rc.lua` logic into a new `request::border` signal. The default `rc.lua` was using the focus/unfocus signals to set the border color along with `awful.rules`. This logic block was no longer aligned with the rest of `rc.lua` since it was the only place where `beautiful` variables where only used by `rc.lua`. On top of this, the new request handler also has extra contexts for the urgent and floating/maximixed use cases. So it can be used by themes to implement much smarter borders than just focus based ones. They were previously limited by the fact most of the (un-monkey-patchable) logic was in `rc.lua`. Note that this commit also shuffle the awful.rules order between the titlebar and the border and changes the tests accordignly. After some consideration, I came to the conclusion the previous behavior was bogus and the fact that the placement tests required to know about the titlebar height is simply a proof of that. The change was required in this commit because since the border is no longer in the default rules, a new buggy edge case surfaced.
2019-11-11 02:47:43 +01:00
/**
* The client opacity for the normal clients.
*
* A number between 0 and 1.
*
* @beautiful beautiful.opacity_normal
* @param[opt=1] number
* @see request::border
*/
/**
* The client opacity for the active client.
*
* A number between 0 and 1.
*
* @beautiful beautiful.opacity_active
* @param[opt=1] number
* @see request::border
*/
/**
* The client opacity for the urgent clients.
*
* A number between 0 and 1.
*
* @beautiful beautiful.opacity_urgent
* @param[opt=1] number
* @see request::border
*/
/**
* The client opacity for the new clients.
*
* A number between 0 and 1.
*
* @beautiful beautiful.opacity_new
* @param[opt=1] number
* @see request::border
*/
/**
* The client opacity for the normal floating clients.
*
* A number between 0 and 1.
*
* @beautiful beautiful.opacity_floating_normal
* @param[opt=1] number
*/
/**
* The client opacity for the active floating client.
*
* A number between 0 and 1.
*
* @beautiful beautiful.opacity_floating_active
* @param[opt=1] number
* @see request::border
*/
/**
* The client opacity for the urgent floating clients.
*
* A number between 0 and 1.
*
* @beautiful beautiful.opacity_floating_urgent
* @param[opt=1] number
* @see request::border
*/
/**
* The client opacity for the new floating clients.
*
* A number between 0 and 1.
*
* @beautiful beautiful.opacity_floating_new
* @param[opt=1] number
* @see request::border
*/
doc: Add documentation linting and fix all issues it found.
2021-12-21 06:54:15 +01:00
/**
* The client opacity for the floating clients.
*
* A number between 0 and 1. This is the fallback if the more stateful
* variables, like `beautiful.opacity_floating_new` are not set.
*
* @beautiful beautiful.opacity_floating
* @param[opt=1] number
* @see request::border
* @see beautiful.opacity_floating_normal
* @see beautiful.opacity_floating_active
* @see beautiful.opacity_floating_urgent
* @see beautiful.opacity_floating_new
*/
client: Turn `rc.lua` logic into a new `request::border` signal. The default `rc.lua` was using the focus/unfocus signals to set the border color along with `awful.rules`. This logic block was no longer aligned with the rest of `rc.lua` since it was the only place where `beautiful` variables where only used by `rc.lua`. On top of this, the new request handler also has extra contexts for the urgent and floating/maximixed use cases. So it can be used by themes to implement much smarter borders than just focus based ones. They were previously limited by the fact most of the (un-monkey-patchable) logic was in `rc.lua`. Note that this commit also shuffle the awful.rules order between the titlebar and the border and changes the tests accordignly. After some consideration, I came to the conclusion the previous behavior was bogus and the fact that the placement tests required to know about the titlebar height is simply a proof of that. The change was required in this commit because since the border is no longer in the default rules, a new buggy edge case surfaced.
2019-11-11 02:47:43 +01:00
/**
* The client opacity for the normal maximized clients.
*
* A number between 0 and 1.
*
* @beautiful beautiful.opacity_maximized_normal
* @param[opt=1] number
*/
/**
* The client opacity for the active maximized client.
*
* A number between 0 and 1.
*
* @beautiful beautiful.opacity_maximized_active
* @param[opt=1] number
* @see request::border
*/
/**
* The client opacity for the urgent maximized clients.
*
* A number between 0 and 1.
*
* @beautiful beautiful.opacity_maximized_urgent
* @param[opt=1] number
* @see request::border
*/
/**
* The client opacity for the new maximized clients.
*
* A number between 0 and 1.
*
* @beautiful beautiful.opacity_maximized_new
* @param[opt=1] number
* @see request::border
*/
doc: Add documentation linting and fix all issues it found.
2021-12-21 06:54:15 +01:00
/**
* The client opacity for the maximized clients.
*
* A number between 0 and 1. This is the fallback if a more stateful
* variable, like `beautiful.opacity_maximized_urgent`, isn't set.
*
* @beautiful beautiful.opacity_maximized
* @param[opt=1] number
* @see request::border
* @see beautiful.opacity_maximized_normal
* @see beautiful.opacity_maximized_active
* @see beautiful.opacity_maximized_urgent
* @see beautiful.opacity_maximized_new
*/
client: Turn `rc.lua` logic into a new `request::border` signal. The default `rc.lua` was using the focus/unfocus signals to set the border color along with `awful.rules`. This logic block was no longer aligned with the rest of `rc.lua` since it was the only place where `beautiful` variables where only used by `rc.lua`. On top of this, the new request handler also has extra contexts for the urgent and floating/maximixed use cases. So it can be used by themes to implement much smarter borders than just focus based ones. They were previously limited by the fact most of the (un-monkey-patchable) logic was in `rc.lua`. Note that this commit also shuffle the awful.rules order between the titlebar and the border and changes the tests accordignly. After some consideration, I came to the conclusion the previous behavior was bogus and the fact that the placement tests required to know about the titlebar height is simply a proof of that. The change was required in this commit because since the border is no longer in the default rules, a new buggy edge case surfaced.
2019-11-11 02:47:43 +01:00
/**
* The client opacity for the normal fullscreen clients.
*
* A number between 0 and 1.
*
* @beautiful beautiful.opacity_fullscreen_normal
* @param[opt=1] number
*/
/**
* The client opacity for the active fullscreen client.
*
* A number between 0 and 1.
*
* @beautiful beautiful.opacity_fullscreen_active
* @param[opt=1] number
* @see request::border
*/
/**
* The client opacity for the urgent fullscreen clients.
*
* A number between 0 and 1.
*
* @beautiful beautiful.opacity_fullscreen_urgent
* @param[opt=1] number
* @see request::border
*/
/**
* The client opacity for the new fullscreen clients.
*
* A number between 0 and 1.
*
* @beautiful beautiful.opacity_fullscreen_new
* @param[opt=1] number
* @see request::border
*/
doc: Add documentation linting and fix all issues it found.
2021-12-21 06:54:15 +01:00
/**
* The client opacity for the fullscreen clients.
*
* A number between 0 and 1. This is the fallback if the variables
* for more stateful versions, like `beautiful.opacity_fullscreen_urgent`,
* are not set.
*
* @beautiful beautiful.opacity_fullscreen
* @param[opt=1] number
* @see request::border
* @see beautiful.opacity_fullscreen_new
* @see beautiful.opacity_fullscreen_urgent
* @see beautiful.opacity_fullscreen_active
* @see beautiful.opacity_fullscreen_normal
*/
client: Turn `rc.lua` logic into a new `request::border` signal. The default `rc.lua` was using the focus/unfocus signals to set the border color along with `awful.rules`. This logic block was no longer aligned with the rest of `rc.lua` since it was the only place where `beautiful` variables where only used by `rc.lua`. On top of this, the new request handler also has extra contexts for the urgent and floating/maximixed use cases. So it can be used by themes to implement much smarter borders than just focus based ones. They were previously limited by the fact most of the (un-monkey-patchable) logic was in `rc.lua`. Note that this commit also shuffle the awful.rules order between the titlebar and the border and changes the tests accordignly. After some consideration, I came to the conclusion the previous behavior was bogus and the fact that the placement tests required to know about the titlebar height is simply a proof of that. The change was required in this commit because since the border is no longer in the default rules, a new buggy edge case surfaced.
2019-11-11 02:47:43 +01:00
/*