3e3b0ca9de
There is a limit to how much one can do with step_shape callback. By its nature it can only have three parameters, and that list can't be extended, because the user is expected to set the property to a function from gears.shape, all of which have different meanings for parameters past the first 3. Moreover step_shape requires the current coordinate system to be modified accordingly because it draws the shape at (0,0). Lastly it's not expected to handle NaN heights and thus is never called for NaN values. This makes it hard to implement things like the following: 1) drawing steps which depend on knowing their position relative to other steps. (e.g. connecting data points with bezier curves) 2) drawing steps while appropriately handling NaN values in any way other than not drawing anything, which might be still wrong or not sufficient. (e.g. interpolating data points requires to know *where* there are gaps in data, not simply continuing with the next present value) 3) drawing steps that need the knowledge of the exact value that is being drawn (e.g. drawing value tooltips over bars) The step_hook callback (name bikeshedding welcome) is designed to solve the problems (for now only the first two of the 3). Whenever it's set, it takes precedence over step_shape property and is used to draw steps. No coordinate transformation before calling it takes place like for step_shape(). The (0, 0) is always the top-left corner of the graph drawing area (sans borders), when it's called. In contrast to step_shape() which only accepts three parameters (cairo, width, height), step_hook() accepts (cairo, x, y, baseline_y, step_width, options). (x, y) is what would be (0, 0) in step_shape, i.e. the coordinates of the bar top. The y parameter can be NaN, and step_hook() is expected to handle that. baseline_y is the y coordinate of the bar bottom. (baseline_y - y) is what is known as `height` in step_shape. But note that baseline_y is never NaN, so even in the NaN case step_hook() can at least know where the baseline is. step_width is the bar's width, just like in step_shape. options is the same table that is passed to the group_start()/group_finish() callbacks, it contains some useful data for nontrivial drawing needs and it could be extended later with more useful data at leisure, e.g. with `value`, if such need arises, without fear of coming in conflict with other user's parameters. |
||
|---|---|---|
| build-utils | ||
| common | ||
| docs | ||
| icons | ||
| lib | ||
| manpages | ||
| objects | ||
| spec | ||
| tests | ||
| themes | ||
| utils | ||
| .busted | ||
| .editorconfig | ||
| .gitignore | ||
| .luacheckrc | ||
| .luacov | ||
| .mergify.yml | ||
| .travis.yml | ||
| AutoOption.cmake | ||
| CMakeLists.txt | ||
| ISSUE_TEMPLATE.md | ||
| LICENSE | ||
| Makefile | ||
| Packaging.cmake | ||
| README.md | ||
| awesome-version-internal.h | ||
| awesome.c | ||
| awesome.desktop | ||
| awesome.h | ||
| awesomeConfig.cmake | ||
| awesomerc.lua | ||
| banning.c | ||
| banning.h | ||
| color.c | ||
| color.h | ||
| config.h | ||
| dbus.c | ||
| dbus.h | ||
| draw.c | ||
| draw.h | ||
| event.c | ||
| event.h | ||
| ewmh.c | ||
| ewmh.h | ||
| globalconf.h | ||
| keygrabber.c | ||
| keygrabber.h | ||
| luaa.c | ||
| luaa.h | ||
| mouse.c | ||
| mouse.h | ||
| mousegrabber.c | ||
| mousegrabber.h | ||
| options.c | ||
| options.h | ||
| property.c | ||
| property.h | ||
| root.c | ||
| selection.c | ||
| selection.h | ||
| spawn.c | ||
| spawn.h | ||
| stack.c | ||
| stack.h | ||
| strut.c | ||
| strut.h | ||
| systray.c | ||
| systray.h | ||
| xkb.c | ||
| xkb.h | ||
| xkb_utf32_to_keysym_compat.c | ||
| xrdb.c | ||
| xrdb.h | ||
| xwindow.c | ||
| xwindow.h | ||
README.md
Readme
About Awesome
Awesome is a highly configurable, next generation framework window manager for X.
Building and installation
After extracting the dist tarball or cloning the repository, run:
make
sudo make install
This will
- create a build directory at
./build, - run
cmake, - build Awesome and
- install it to the default prefix path
/usr/local.
Alternatively to the above, you can generate a .deb or .rpm package, for easy installation management:
make package
sudo dpkg -i awesome-x.y.z.deb
# or
sudo rpm -Uvh awesome-x.y.z.rpm
Advanced options and testing
A full list of dependencies, more advanced build options, as well as instructions on how to use the test suite can be found here.
Installing current git master as a package receipts
Arch Linux AUR
sudo pacman -S --needed base-devel git
git clone https://aur.archlinux.org/awesome-git.git
cd awesome-git
makepkg -fsri
Debian-based
sudo apt build-dep awesome
git clone https://github.com/awesomewm/awesome
cd awesome
make package
sudo apt install *.deb
Running Awesome
You can directly select Awesome from your display manager. If not, you can
add the following line to your .xinitrc to start Awesome using startx
or to .xsession to start Awesome using your display manager:
exec awesome
In order to connect Awesome to a specific display, make sure that
the DISPLAY environment variable is set correctly, e.g.:
DISPLAY=foo.bar:1 exec awesome
(This will start Awesome on display :1 of the host foo.bar.)
Configuration
The configuration of Awesome is done by creating a
$XDG_CONFIG_HOME/awesome/rc.lua file, typically ~/.config/awesome/rc.lua.
An example configuration named awesomerc.lua is provided in the source.
Troubleshooting
On most systems any message printed by Awesome (including warnings and errors)
is written to ~/.xsession-errors.
If Awesome does not start or the configuration file is not producing the desired results the user should examine this file to gain insight into the problem.
Debugging tips
You can call awesome with gdb like this:
DISPLAY=:2 gdb awesome
Then in gdb set any arguments and run it:
(gdb) set args --replace
(gdb) run
Asking questions
IRC
You can join us in the #awesome channel on the OFTC IRC network.
Stack Overflow
You can ask questions on Stack Overflow.
We also have a awesome subreddit where you can share your work and ask questions.
Reporting issues
Please report any issues you may find on our bugtracker.
Contributing code
You can submit pull requests on the github repository. Please read the contributing guide for any coding, documentation or patch guidelines.
Status
Documentation
Online documentation is available here.
License
The project is licensed under GNU General Public License v2 or later. You can read it online at (v2 or v3).