This makes sure that an invalid value for this property doesn't cause the client
to have no tag at all. This should be especially useful when one uses dynamic
tags and restarts awesome which causes less tags to exist than before.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Julien Danjou <julien@danjou.info>
EWMH says that "Window Managers MUST keep this property updated on all windows",
but doesn't say anything about clients which got no desktop at all. Removing the
property seems to be the best we could do.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Julien Danjou <julien@danjou.info>
tag.add(name, props):
make tags and pass a table of properties to apply to it
tag.new:
modified to use add() instead of calling capi.tag
Signed-off-by: Perry Hargrave <perry.hargrave@gmail.com>
Signed-off-by: Julien Danjou <julien@danjou.info>
tag.getidx(t):
Return the index of 't' in the screen[]:tags() table. Return 'nil'
if 't' is not found.
Signed-off-by: Perry Hargrave <perry.hargrave@gmail.com>
Signed-off-by: Julien Danjou <julien@danjou.info>
tag.move(i, t):
move tag 't', or tag.selected(), to index 'i' in the current
screen's tags table.
Signed-off-by: Perry Hargrave <perry.hargrave@gmail.com>
Signed-off-by: Julien Danjou <julien@danjou.info>
This will store the widgets references that the wibox have inside their
environment table, and not in the global registry, avoiding memory leaks.
This should fix FS#771.
Signed-off-by: Julien Danjou <julien@danjou.info>
Raising it makes it more obvious that the focus was really changed and makes
working with the client easier since it's, well, raised.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Julien Danjou <julien@danjou.info>
Patch allows user to define menu position in pixels when
showing menu in keyboard-driven mode.
Note: Patch changes signature of show() and toggle() functions.
Signed-off-by: Julien Danjou <julien@danjou.info>
On 09/04/2010, Julien Danjou <julien@danjou.info> wrote:
>
> Well, I cannot find anything to say against this patch, so I've merged
> it.
>
Thanks for the kind comments and for your quick reply, I'm glad you
find this contribution useful.
I also noticed that in the previous patch there is a line that was not
supposed to be there, since its purpose was to help debugging the
cmake file. My apologies for that: I have removed it and attached the
corresponding patch (against the already patched version).
Signed-off-by: Diego Moreda <diego.plan9@gmail.com>
Signed-off-by: Julien Danjou <julien@danjou.info>
The patch changes the path where the manual pages are compiled, resulting in
a tree structure that follows the man-db convention: the man pages of each
language are stored in a subdirectory of the main man path. For example, the
input file "$AWESOME_SRC/manpages/awesome.1.fr.txt" would be compiled as
"$BUILD_DIR/manpages/fr/man1/awesome.1". The installation step just copies
the resulting directory (in the example, "$BUILD_DIR/manpages/") into the
global man path of the system, excluding the temporary files.
The input .txt files for the translations are not added directly to
AWE_MAN_FILES: instead, the new variable AWE_MAN_LANGS stores the language
names and their input file names are generated automatically. The main
reason of this modification is that it was more convenient for my testing
purposes: this behaviour can be changed back with minor modifications to the
code. This patch is supposed to be a first draft, after all, and it is far
from being perfect, but I hope it is of help.
Signed-off-by: Diego Moreda <diego.plan9@gmail.com>
Signed-off-by: Julien Danjou <julien@danjou.info>
If a window didn't have a WM_STATE set, xwindow_get_state_reply() returned 0
which just happened to be XCB_WM_STATE_WITHDRAWN. This caused issues in scan().
Instead, we now assume a window is in state normal if no state is explicitly
set, which makes a lot more sense and fixes actual bugs.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Julien Danjou <julien@danjou.info>
A window is unmapped if it is not mapped (oh noes! ;). If it is mapped, it can
be either mapped or unviewable. If any of its ancestors is unmapped, it's
unviewable, else it's unmapped
Since this code looks at children of the root window, it should never be seeing
clients which are unviewable (can one unmap the root window at all...?). What
this really wants to check for is unmapped, so this patch implements this.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Julien Danjou <julien@danjou.info>
Initial implementation of stacked graphs. Adds two new methods,
set_stack (false by default) and set_stack_colors (i.e. {"red",
"white", "blue"}). The order of the colors matters, because the
add_value method now accepts an (optional) last argument, an index of
a color from your stack color group.
Signed-off-by: Adrian C. (anrxc) <anrxc@sysphere.org>
Signed-off-by: Julien Danjou <julien@danjou.info>
Setting width or height (horizontal or vertical) to an arbitrary value
causes the wibox not to be stretched. Instead the align() function is
called, which might not modify any wibox property in many situations,
or none when align parameter was not provided by the user. The major
side effect is that wibox struts were never updated and clients
covered the wibox (until a first signal handler caused struts to be
updated).
Signed-off-by: Adrian C. (anrxc) <anrxc@sysphere.org>
Signed-off-by: Julien Danjou <julien@danjou.info>
Second implementation of the progressbar ticks. Adds set_ticks,
set_ticks_gap and set_ticks_size methods. Default gap is 1, size 4 in
respect to the default progressbar width of 100px.
Signed-off-by: Adrian C. (anrxc) <anrxc@sysphere.org>
Signed-off-by: Julien Danjou <julien@danjou.info>
The memory referred to by the reply argument of
property_update_wm_protocols is automatically free'd
by xcb later on, so it is not safe to simply use the
value of reply in our own data structures. If we did
this, future calls to xcb_get_wm_protocols_reply_wipe
free the data which has already been free'd by xcb,
causing a double-free and corrupting the heap. In
addition, it isn't safe to use free'd memory as if
it is still allocated. Instead, duplicate the data
referred to by reply and use the duplicate instead.
It seems to me as if the duplication should actually
be done in xcb_get_wm_protocols_from_reply, but I'm
not really sure. If that is the case, this is simply
a work-around until xcb can be fixed.
Signed-off-by: Ari Entlich <atrigent@ccs.neu.edu>
Signed-off-by: Julien Danjou <julien@danjou.info>
Return the label of the selected menu item as an argument for the
callback function
Signed-off-by: Pierre Mazière <pierre.maziere@gmail.com>
Signed-off-by: Julien Danjou <julien@danjou.info>
Changing the width or height of a (right or bottom positioned)wibox,
after it was initialized, to a value different than used when it was
created would leave the wibox in a wrong position. Position was off by
as many pixels as the difference between the old and the new
value. Now every wibox is repositioned to reflect this new setup.
Signed-off-by: Adrian C. (anrxc) <anrxc@sysphere.org>
Signed-off-by: Julien Danjou <julien@danjou.info>
If c->honor_size_hints is set to false and the client indicates through
its hints that it wants to be fixed size (by setting min and max width
equal), size hints are not ignored due to client_isfixed not taking
honor_size_hints being false into account. This commit fixes that.
Signed-off-by: Gregor Best <gbe@ring0.de>
Signed-off-by: Julien Danjou <julien@danjou.info>
The awful.widget.graph allows to change the maximum value a graph can
handle, thus allows users to use widgets and scripts that don't scale
the values down to 0 - 1 range. The progressbars did not allow this
and worked with a hard-coded value of 1.
Signed-off-by: Adrian C. (anrxc) <anrxc@sysphere.org>
Signed-off-by: Julien Danjou <julien@danjou.info>
fvwm-root is a part of the FVWM window manager, and is one of those
utilities that properly support transparency because it can retain and
publish the Pixmap with which the background has been set. It supports
XBM, XPM, PNG and SVG image formats, but is not very rich in options
as opposed to habak or feh.
Signed-off-by: Adrian C. (anrxc) <anrxc@sysphere.org>
Signed-off-by: Julien Danjou <julien@danjou.info>
Commit 87070ca introduced support for access keys in menus. Chosen
character was "&", an XML entity that has potential to cause problems;
if a user tries to add multiple access keys or just put an ampersand
in the name of the item the menu will break. Breaking happened because
ampersands were not escaped - first one was substituted and the rest
were ignored, but not escaped which triggered a pango markup error.
Signed-off-by: Adrian C. (anrxc) <anrxc@sysphere.org>
Signed-off-by: Julien Danjou <julien@danjou.info>
You can define a menuitem like before:
awful.menu({ items = { { "&awesome", myawesomemenu,
beautiful.awesome_icon },
{ "open &terminal", terminal },
})
and the letters following the ampersand in itemname can be used as
access key. (at least former fvwm users might find this familiar)
When there are submenus open awesome ascends during the search from the
current menu to the top level menu.
The access key is shown underlined.
There is no warning for multiple used keys, only the first one found
gets the price.
Signed-off-by: Julien Danjou <julien@danjou.info>