Re: Shutdown of this awesome mailing list

[Uli Schlachter]

On 28.10.2016 17:15, Uli Schlachter wrote:
>> Psychon is also answering some stackoverflow questions.
> 
> Well, yes. I subscribed to the "awesomewm" tag and get mail
> notifications. Still, this seems to be only me.

Since I was asked "how":

http://stackoverflow.com/tags/awesome-wm/info?

Hover over the "awesome-wm" in "About awesome-wm", wait for the popup
and click subscribe.

Cheers,
Uli
-- 
“Some people are worth melting for.” - Olaf

Re: Shutdown of this awesome mailing list

[Uli Schlachter]

Hi,

On 27.10.2016 10:30, Elv1313 . wrote:
> There is a subreddit for Awesome that's mostly used for questions.
> They usually get answered rather quickly.

I was under the impression that only Elv13 is on reddit.

> Psychon is also answering some stackoverflow questions.

Well, yes. I subscribed to the "awesomewm" tag and get mail
notifications. Still, this seems to be only me.

> IRC seems to be the most popular way.

With my IRC-time decreasing, this is again mostly Elv13 with some help
from Daniel, I think.

> We almost haven't seen questions on the ML in 3 years while IRC have
> at least one per day, usually more.

However, questions on the mailing list are addressed more often, I think.

> I guess we should mention that on our websites once the mailing list
> has been closed.

I'm not really sure. The current situation is non-intuitive and a bit
weird. I think "GitHub issues" is the only "communication channel" that
everything looks at. However, this will scare away people from asking
questions.

> On 27 October 2016 at 04:13, Кирилл Фунтов  wrote:
[...]
>> What do you think about gitter? I think I can organize and handle it.
[...]

First impression (after reading on Wikipedia what it is): One more
communication channel that reaches only a subset of people (which for
awesome means: only one person).

Uli
-- 
“I’m Olaf and I like warm hugs.”

--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: Mouse wrapping?

[Uli Schlachter]

On 25.09.2016 17:17, Abraham Baker wrote:

> When I shift focus between monitors in Awesome, I can "wrap" the focus from 
> the right-most monitor back to the left/first one.  So, I could cycle focus 
> between all the monitors indefinitely.
>
>
> How would I make the mouse-controlled cursor do the same thing? For example, 
> if I moused over the right border of the right-most monitor, the cursor would 
> then jump to the left-most monitor's left border.  Is this outside the scope 
> of the window manager?
You could create a 1px wide wibox at the edge of the screen to detect
when the mouse enters there and then warp the cursor to the other side
of the other screen. "Pure X11" would even allow an invisible
(InputOnly) window, which awesome does not provide. At least I think
that this is how some WMs (I don't remember which) implement "switch
workspace via mouse".

Cheers,
Uli

-- 
"Why make things difficult, when it is possible to make them cryptic
and totally illogical, with just a little bit more effort?" -- A. P. J.


-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: awful.placement confusion

[Uli Schlachter]

Am 12.09.2016 um 15:58 schrieb martin f krafft:
> Hello,
> 
> I am using Git master (@g39aace5) and experimenting on top of the
> stock configuration file.
> 
> One change I've just tried is to get the floating clients (in the
> stock ruleset) to display close to the mouse cursor, e.g. by adding
> 
>   placement = awful.placement.no_offscreen+awful.placement.under_mouse
> 
> to the rule definition, just after floating=true.
> 
> The effect is, however, not what I expect. The window now pops up
> under the mouse, but may well be off-screen.
> 
> If I invert the order of the two placement policies, then the mouse
> cursor position seems to be entirely ignored and instead the client
> appears in the top-left corner.
> 
> The behaviour I'd love to get is to have 100% on-screen placement,
> as close to the mouse pointer as possible.
> 
> How can this be achieved?

For the mailing list archives:

This is a bug in Git/master which is now tracked as
https://github.com/awesomeWM/awesome/issues/1092. The above code is correct (the
version with under_mouse+no_offscreen).

Cheers,
Uli
-- 
- Buck, when, exactly, did you lose your mind?
- Three months ago. I woke up one morning married to a pineapple.
  An ugly pineapple... But I loved her.

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: Fixing Firefox focus stealing

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

Am 12.09.2016 um 20:45 schrieb martin f. krafft:
> also sprach Uli Schlachter  [2016-09-12 17:25 +0200]:

Heh, ich mag die Art von Zitat. :-)

>>> If I have Firefox (v45) and a terminal on the same tag, and I run 
>>> "firefox http://debian.org"; in the terminal, Debian's website opens in 
>>> a new tab in Firefox (good!), *and* focus is shifted to that window 
>>> (bad!).
>> [...]
>>> How can I find out what causes the focus shift?
>> 
>> Sounds like awesome sends a _NET_ACTIVE_WINDOW request.
> 
> I don't really know enough about X or whatever to make sense of that, but 
> ok.

Whoops, I meant "firefox sends...". Basically, firefox says "dear window
manager, please give me the input focus".

>>> What can be done to prevent this behaviour?
>> 
>> Write your own handler for such requests. The following (untested) code 
>> *might* help:
> 
> It worked out of the box for the main window! \o/ THANK YOU SO MUCH!
> 
> Now the next task will be to make its dialogs not disturb me. These also
> go through ewmh.activate with context == "autofocus.check_focus" and that 
> makes me think there's a better way to disable the autofocus… so much to 
> learn…

Autofocus is awful.autofocus aka /usr/share/awesome/lib/awful/autofocus.lua.
It's quite a short file.

The idea of that code is "if nothing has the input focus (or the currently
focused window is not visible), then give the focus to the window that last
had the focus". So the dialogs already had the focus previously, but then
'something' happened.

At least I'm pretty sure that awful.autofocus is not where this issue actually
occurs. Quick test would be to "mkdir ~/.config/awesome/awful && touch
~/.config/awesome/awful/autofocus.lua" to force-disable autofocus.

Sorry that I don't have a better idea for this right now.

Cheers,
Uli
- -- 
“Some people are worth melting for.” - Olaf
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJX1wbgAAoJECLkKOvLj8sG5CYH/3TxqMtyO4GWuHOnbY+EW0LK
3sGRWZa+C+kLz0tfZv4ksbV+YoLTQ1TWY1BhJx1cirJzboXbyLoqz5z2rslQGCPE
xtYGnkJ1i9+cIXFPw/6dWzm3Crb5NXb+hHgf47rTrJlfkbz+ERvrPsMp7GJ/LjTk
qUEPx4ViWu1fn4v9clIYU3/ynIrsMH/re0A34mgLmKXXmuK7MqEJ5DBF+jBwLEVT
+uN/kDsS3wogOQuaxROGX5J2H3nQhuWw72X8XgeUdcQtPEEaSqh07XrA747SDxRn
txJzhshFUSiQFQavxED2RnTSh2/Xc98bN58MDMtlLnwXp7/aIn5cXgJ6s89D8Hc=
=wkdO
-END PGP SIGNATURE-

--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: Client placement on wrong screen

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

Am 12.09.2016 um 13:30 schrieb martin f krafft:
> I am running awesome from Git master (@g39aace5) on a XRandR-triple-head
> setup, with my screens from left to right being 2|1|3.
> 
> With the stock config, while focus (mouse) is e.g. on screen 1 (middle),
> creating a new client causes it to be placed on the left-most screen (2).

Sigh. This worked up until recently. I would guess that 21787444e4f1244 broke
this, but I can't test right now.
I reported this: https://github.com/awesomeWM/awesome/issues/1091

> 
> The only way to fix this I found was to add
> 
> screen = awful.screen.focused()
> 
> to the properties of the "all clients will match this rule" sub-table.
> 
> I wonder why this isn't part of the stock config, as the behaviour I am
> seeing can hardly be desirable. Or am I misunderstanding something?

Because with the above, all clients will open on screen 1 (or whatever screen
the mouse pointer is on when awesome starts). This table is created just once
at startup and not every time a new client appears.

Cheers,
Uli
- -- 
Bitte nicht mit dem verbleibenden Auge in den Laser gucken.
 - Vincent Ebert
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJX1sq9AAoJECLkKOvLj8sGvGgIAI8dDGlJ+RUjqPaenq4VOXrZ
XN67mjxjdeXuc6Wj6A+rSw52xIIfuBf10rj56AvgnbMABxokLNkr0wA2ZxO4fc87
Ag9dnncZy3CpTZ5m750e1ktHGFk9L7iakGbTy4YzS3u/tiJPo31v08LHqJJ9SSFy
950lSwJQrT4ryX+kTuG3G46BsnchD2FXlBB85A8Df0eCtDB5oDXm8qFldZlNAegN
laKaJUbvj2+kwbDVVftO32th2acMae8eV2IPlL8kgmTb/jgU3lvO3KoIo7lL7yYE
DRLbgRHUscn36FG/M90nSMRwJQ+h7qQVOSQJIhHKJNBENKeIqQVOKLdXgF7SlE4=
=9nNE
-END PGP SIGNATURE-

--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: Fixing Firefox focus stealing

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

Am 12.09.2016 um 16:39 schrieb martin f krafft:
[...]
> If I have Firefox (v45) and a terminal on the same tag, and I run "firefox
> http://debian.org"; in the terminal, Debian's website opens in a new tab in
> Firefox (good!), *and* focus is shifted to that window (bad!).
[...]
> How can I find out what causes the focus shift?

Sounds like awesome sends a _NET_ACTIVE_WINDOW request.

> What can be done to prevent this behaviour?

Write your own handler for such requests. The following (untested) code
*might* help:

client.disconnect_signal("request::activate", awful.ewmh.activate)
client.connect_signal("request::activate", function(c, context, hints)
  if c.class == "Firefox" -- This is wrong for sure, but you get the idea
  and context == "ewmh" -- The request came from _NET_ACTIVE_WINDOW
then
  -- Just ignore the request
  return
  end
  awful.ewmh.activate(c, context, hints)
end)

I don't know right know what class Firefox uses. If you just want to kill
_NET_ACTIVE_WINDOW completely, then leave out the check for firefox and ignore
context = "ewmh" all together.

Cheers,
Uli
- -- 
Bitte nicht mit dem verbleibenden Auge in den Laser gucken.
 - Vincent Ebert
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJX1sjZAAoJECLkKOvLj8sGIPAIAJIL+NGF6/s2iV36CVEPsApn
yzQQeVGWM8kFZ8FU3SZfhvw2sAe9TTNO4bhydGinbb8AHvfBLNyqdFKV3RevXow9
9q2VctspAtlfCF2k4uXV3IUjMLz3/az2K397KvRecy1WidE8rxCO38zQz0aIzGG8
0gSc0OSfCnmN7SDM+whZejfhtLCCcLKIg0tD6W+D5C3CqFLfrlbnHtt67pN/JsOF
WiLHjCUic23eCT0nT6/gmcpXKqwsRSGkDPXEBjMheaQyVZ+8uEKj8Of/+Y6B9l76
nyMN1F1D6FRcV++20vLzkWPN1of5B5kHCw0xWIZKadvnWorMCYQ6WIHaX98GIcs=
=9EMz
-END PGP SIGNATURE-

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: Awesome becomes unresponsive to mouse

[Uli Schlachter]

Hi,

Am 23.07.2016 um 05:25 schrieb Ranko Kohime:
> I've had the issue for a while that some combination of circumstances will 
> cause
> Awesome to be unresponsive to mouse clicks, on the menu, taglist, and
> clientlist, as well as any permanent (red) notifications.  System tray icons 
> are
> still responsive, and hotkeys are still responsive, just not the mouse.  I've
> pretty much narrowed it down to USB devices as the cause: nearly anytime I
> hotplug or hotunplug a USB audio device, mouse or keyboard (thumb drives don't
> seem to affect it), I get this problem.
[...]
> interested to know if anyone else has run into this problem, and possibly
> found a fix/workaround for it.

The problem is Qt. Close all Qt apps when this happens and mouse input will work
again.

https://github.com/awesomeWM/awesome/issues/415
https://bugreports.qt.io/browse/QTBUG-49952

A fix is to upgrade to a newer Qt version. A 'workaround' is to upgrade to a
newer awesome version. This will make the problem go away everywhere except on
the root window (but apparently you didn't even notice that mouse clicks don't
work here, so that might be ok for you).

Qt uses the XInput extension to be able to tell apart different input devices
(which of the connected mouses generated a mouse click?). When a new input
device appears, Qt re-grabs mouse events on all of its windows for all input
devices. Due to a bug in Qt, it also grabbed mouse events on the root window,
which means that awesome will not see the event as it is only sent to Qt.

The workaround in newer awesome versions makes awesome grab mouse input on its
own window instead of just on the root window where Qt steals them. However, no
workaround for clicks on the root window is possible.

Cheers,
Uli
-- 
"Every once in a while, declare peace. It confuses the hell out of your enemies"
 - 79th Rule of Acquisition

--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: FullScreens function problem

[Uli Schlachter]

Hi,

Am 12.06.2016 um 19:59 schrieb Abraham Baker:
[...]
> However, I need the client's upper-left corner to start on screen 0, but
> when I change the index to 0, I get an error: "invalid screen number: 0".

Lua counts things starting from 1. So 1 is the first screen, 2 the second etc.
There is no screen 0.

> xrandr claims that there is one screen (screen #0) with 3 displays
> attached.  Do I need to set nvidia-settings to have 3 separate screens, or
> can this function work the way it is currently set up?

...and screens in awesome's don't have anything to do with screens in xrandr's
output. They have something to do with outputs as listed in RandR.

So... what exactly is the problem that you are trying to solve by changing some
1 into a 0? And where did you do that? Do you perhabs want a 2 (or 3) instead of
0 here?

Cheers,
Uli

-- 
"Are you preparing for another war, Plutarch?" I ask.
"Oh, not now. Now we're in that sweet period where everyone agrees that our
recent horrors should never be repeated," he says. "But collective thinking is
usually short-lived. We're fickle, stupid beings with poor memories and a great
gift for self-destruction.

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: Split one screen into multiple

[Uli Schlachter]

Am 07.05.2016 um 15:32 schrieb Adam Nielsen:
> Hi all,
> 
> I have a 40" 4K monitor which *almost* works as a multi-monitor
> replacement, except that it's hard to switch between desktops without
> affecting the whole screen.
> 
> What I'd really like is to split the monitor into four quarters, so
> that it functions like four 1080p monitors, i.e. Mod4+F2 goes to the
> top-right sub-screen, Mod4+F3 goes to the bottom-left, etc.

I don't think awesome can do that currently, sorry.

> I don't want to use fake RandR stuff because I still want apps like
> mplayer to go full screen on the whole monitor,
[...]

Uhm, when mplayer wants to go fullscreen, it tells the window manager "please
make me fullscreen". So if awesome would see four different screens, that would
be exactly the result that you don't want

Sorry & cheers,
Uli
-- 
Bruce Schneier can read and understand Perl programs.

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: Vicious CPU graph direction

[Uli Schlachter]

Am 05.05.2016 um 23:09 schrieb Jeroen Budts:
> Hi all,
> 
> In my rc.lua I created a simple CPU graph using Vicious. Is it possible
> to change the direction in which this graph moves? Currently it moves
> from left to right, but I would like to see it move from right to left
> (the same as the CPu graph on xfce4-panel).
> 
> I use this code:
> cpuwidget = awful.widget.graph()
> cpuwidget:set_width(50)
> cpuwidget:set_background_color(theme.bg_normal)
> cpuwidget:set_color(theme.fg_focus)
> vicious.register(cpuwidget, vicious.widgets.cpu, "$1", 1)

Add a mirror layout around the cpuwidget. After the above, add a new line:

cpuwidget_mirrored = wibox.layout.mirror(cpuwidget, "vertical")

And then display cpuwidget_mirrored in your wibox.

Cheers,
Uli
-- 
Bruce Schneier can read and understand Perl programs.

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: Screen attach/detach: avoid restart?

[Uli Schlachter]

Am 30.04.2016 um 16:33 schrieb Bennett Piater:
> AFAIK, the only solution is to switch to i3wm.
> Awesome does not yet work very well with external monitors.

That's quite a 'solution' and quite a claim.

[...]
>> When I attach or detach an external screen (using xrandr) it seems
>> Awesome automatically restarts.
>> Is there any way to avoid this?

Not with awesome 3.5.9, no. Sorry.

However, for the next major release we are working on changing this[0]. This
requires quite some changes, because all the code right now assumes that all
screens are already known when the config file is loaded and doesn't change 
later.

[0]: https://github.com/awesomeWM/awesome/pull/672

>> During a regular working day I happen to
>> connect/disconnect my screen easily 3 to 5 times. This causes my layouts
>> to reset each time (size of master pane, number of applications in the
>> master etc), which is a bit annoying.
[...]

If you have some "frequent patter" for this, the only suggestion that I have is
to configure some more of these settings in your config. You can e.g. use
awful.tag.setmwfact(0.3, tags[1][3]) in your rc.lua to configure a "default"
mwfact for the third tag.

Cheers,
Uli
-- 
Q: Because it reverses the logical flow of conversation.
A: Why is putting a reply at the top of the message frowned upon?

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: AwesomeWM + Gvim resize crashes (segfault)

[Uli Schlachter]

Hi,

Am 30.04.2016 um 16:28 schrieb Jeroen Budts:
[...]
> When starting gvim with `strace gvim -V9log.txt file.tex > stdout.txt 2>
> stderr.txt` I got the following in stdout.txt:
> RenderBadPicture (invalid Picture parameter)
> Vim: Got X error
> Vim: Finished.
> 
> Any help on this is much appreciated.

I know that this isn't helpful at all, but this sounds like a problem with GVim.
A BadPicture means that gvim sent a request to the X11 server to act on some
picture, but that picture does not exist (or is not suitable for this request
due to some other reason). The window manager has nothing to do with Pictures,
so hm.

The only recommendations that I can give is to try other (newer?) versions of
gvim, gtk and cairo (the drawing library used by gtk).

Sorry & good luck,
Uli
-- 
Q: Because it reverses the logical flow of conversation.
A: Why is putting a reply at the top of the message frowned upon?

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: Can not switch client window with mouse click after screensaver

[Uli Schlachter]

Am 07.03.2016 um 07:24 schrieb Hacksign:
> I can not switch client window with my mouse cursor click after a screen 
> lock or  screen blank.
> When this situation happened, replace my rc.lua with default rc.lua then 
> restart awesome with mod4+ctrl+r still can not switch.
> Here is my config file :
> https://github.com/Hacksign/configs/tree/master/.config/awesome
> 
> any body knows the reason ?

Sounds like https://github.com/awesomeWM/awesome/issues/415

Qt starts stealing input events after an input hotplug event. The upstream bug
report is https://bugreports.qt.io/browse/QTBUG-49952 which was apparently fixed
in Qt 5.6.0.

Uli
-- 
Happiness can't be found -- it finds you.
 - Majic

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

[ANNOUNCE] awesome 3.5.9 released

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi again,

it's been awfully long since the last release and Google Chrome is playing
dirty tricks on us, so here is some new awesomeness to enjoy. Oh and we are
holding Java's hand some more so that it's slightly less confused about the
position of its own windows.

Cheers,
Uli
- -- 

awesome version 3.5.9 has been released. It is available from:

tar.xz: http://awesome.naquadah.org/download/awesome-3.5.9.tar.xz
md5: 62a0b5c6bd3baeb4879d7e8399e5ad87
sha1: 802a6e0524b5f79b7485026d3c68dc6df2dc4eab

tar.bz2: http://awesome.naquadah.org/download/awesome-3.5.9.tar.bz2
md5: 3e3268231fbd131fa9d5c27615b1efea
sha1: 3fc91f6b4d4dc5f69b4db18d12fad832542558d6

number of changes
- -
9

number of commiters
- ---
1

shortlog
- 
Uli Schlachter (9):
  Always send ConfigureNotifies
  Don't modify WM_HINTS in client_set_urgent()
  Fix awful.ewmh to handle window gravities
  Check that the Lua stack is empty in the main loop
  Fix unbalance Lua stack usage in event_handle_leavenotify()
  Balance the stack in luaA_loadrc()
  Fix arguments to luaL_checkstack()
  Make client key bindings for e.g. xeyes work again
  change codename


diffstat
- 
 awesome.c |  7 +++
 awesomeConfig.cmake   |  2 +-
 common/luaobject.c|  4 ++--
 event.c   |  5 -
 lib/awful/ewmh.lua.in |  4 ++--
 luaa.c| 57 
+
 objects/client.c  | 54 
++
 objects/client.h  |  3 +++
 8 files changed, 82 insertions(+), 54 deletions(-)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJW3DxlAAoJECLkKOvLj8sGockIAJlEJgIC3oKy7xIUrcf1UKL0
56y4iUKlfAyLvWUGkNE8vYdCtcnhQIa4Bf7kF1MbeAGU01/1luhKAMyj6E+HOz8l
dxsda0eFvKDZMOl9pRZkB79vxjdQocwSiwaUUsw6TyLPVA4UKOOso08SDil2PVSu
p4jJQlfdD35taE/rgo5nln1cB6nw3iS+vvCLJWkJoiuuViHGFvbkU/NAP8RNweDT
gicEoj0gsF3w1dEuLiB7klHETI1ysvOYkv9U5H5qeE0OJ3WAmKKoJB3E8ngQeNA3
+VQWVtxvrxBNrl+krhxbdzbD9cJsP6hwlUnBfN9xU0IXmUpRdYHLORWWe3RmuVQ=
=Wnd6
-END PGP SIGNATURE-

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

[ANNOUNCE] awesome 3.5.8 released

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi everyone,

it's been two weeks, time for a new release!

Well, to be honest, 3.5.7 had a bug where keyboard bindings stopped working
when the keyboard layout was changed. Sorry for that.

I was considering calling the new release "Oops, I did it again", but in the
end decided against it. :-)

Cheers,
Uli

- -- 

awesome version 3.5.8 has been released. It is available from:

tar.xz: http://awesome.naquadah.org/download/awesome-3.5.8.tar.xz
md5: bdca8e1740cd9c5a76bfc46f8d943cf1
sha1: 841ab68e96b8d75e895fcd2ab4956f1a7e82a4f8

tar.bz2: http://awesome.naquadah.org/download/awesome-3.5.8.tar.bz2
md5: 6dc7a60d9c4b30efd3bea4718cb1cd92
sha1: e5a09c7a64ae94bc75ef328be6ea836f74c78203

number of changes
- -
3

number of commiters
- ---
2

shortlog
- 
Uli Schlachter (2):
  Fix window key grabbing
  change codename

Roy Crihfield (1):
  menubar: handle nil Name in .desktop files


diffstat
- 
 awesomeConfig.cmake  | 2 +-
 event.c  | 4 ++--
 lib/menubar/utils.lua.in | 3 +++
 objects/client.c | 2 +-
 4 files changed, 7 insertions(+), 4 deletions(-)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJWrMLSAAoJECLkKOvLj8sGvHMH/2xpODGSaJslZtUmtTa8iXfN
fbrYCcf8Z+H8Aon4vDWyUsYVBIB4fxVqin2ATUcYJhM+NCU395C8EmCkoRb7OuAA
lFBYevjyjGG74RLMAHwjUq3QjwpU4vkjdJzWUHfTzzQpTurQbCbWl7SQtkvE19zG
2bKVEqeg9nwqLutOzI11CLnbpnxvRIsRpTPGjnmb5uzUU/MpUAzjWyDafmLhwPbd
P4Tiw0PLpc/LSCE8/vp9P0b/jhl+EB8OMZU66hRayDU457yi+TFzP3vZoBr7wOKR
jOTBd6AUm8L0W7Ie1C+XNPSUxxDZKkxnoR+GdbN5AGsX06tNtYTjPBZ5WBkeMKE=
=+XX5
-END PGP SIGNATURE-

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: Naughty notifications with buttons

[Uli Schlachter]

Hi,

Am 19.01.2016 um 11:00 schrieb Alexis BRENON:
> Hi guys,
> 
> I'm using blueman to transfer file between my laptop and my phone. But
> blueman display many notifications with buttons:
> To accept pairing
> To accept incoming file
> These notifications are displayed with naughty, but I can't click on the
> buttons... Is there a way to fix this problem?
> 
> Kind regards, Alexis.

Awesome from Git has support for notification actions.

Awesome 3.5 correctly signals that it doesn't support actions and so it's a bug
in blueman that it tries to use them anyway. You could stop using naughty and
instead use some other notification implementation that does support actions.

Cheers,
Uli
-- 
“I’m Olaf and I like warm hugs.”

--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

[ANNOUNCE] awesome 3.5.7 released

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi everyone,

it's been almost exactly a year. A couple of changes occurred in this
time and it's time for them to get a release.

Enjoy!
Uli

- -- 

awesome version 3.5.7 has been released. It is available from:

tar.xz: http://awesome.naquadah.org/download/awesome-3.5.7.tar.xz
md5: afab0b57fe0563ae3107d6b84d26f1aa
sha1: d93836272ff367880bff9e51c67716dad51c45a8

tar.bz2: http://awesome.naquadah.org/download/awesome-3.5.7.tar.bz2
md5: 87ff095e54f12b9e1c9573e481d661c5
sha1: f6207a16261e038523d1a9a203b9a6f7ec5b5d32

number of changes
- -
31

number of commiters
- ---
6

shortlog
- ----
Uli Schlachter (22):
  Remove titlebars from clients during shutdown (FS#1159)
  a_dbus_message_iter: Handle DBUS_TYPE_DOUBLE
  Ignore more events while minimizing a client
  Screen __index: Don't turn argument into a string
  Keep stacking order across restarts
  Keep client order across restarts
  Force systray redraw on BG color change
  Fix enter/leave events on titlebars
  Fix compilation
  Handle enter/leave events with detail=Inferior correctly
  Never explicitly focus the root window
  Fix client_apply_size_hints()
  Make awesome.quit() during startup work
  Fix obvious typo in xwindow_translate_for_gravity()
  Apply window gravity when a window moves itself
  Refactor code a little
  Apply window gravity for titlebar resizes
  Apply window gravity for border width changes
  Grab client keys on the client window (#496)
  Spawn: Improve handling of startup notification
  objects: Add .valid property (Fixes #110)
  change codename

Daniel Hahler (5):
  tag.lua: add "property::icon_only" signal
  Make stdout/stderr line buffered
  cmake: s/ESCAPE_QUOTE/ESCAPE_QUOTES
  awesome_atexit: keep client order always
  Add .travis.yml from master, ignoring functional tests

Heiko Becker (1):
  awesomeConfig.cmake: Allow setting AWESOME_DATA_DIR

Kazunobu Kuriyama (1):
  Fix the definition of A_STRNEQ_CASE

Kimball Thurston (1):
  Fix focus handling with multiple awesome instances

▟ ▖▟ ▖ (1):
  awful.menu: update t new layout api


diffstat
- 
 .travis.yml   |  66 
++
 awesome.c |  84 
+++-
 awesomeConfig.cmake   |  12 +---
 common/atoms.list |   1 +
 common/luaclass.c |  13 +
 common/util.h |   2 +-
 dbus.c|   1 +
 event.c   | 110 
--
 globalconf.h  |   6 ++
 lib/awful/menu.lua.in |   4 ++--
 lib/awful/tag.lua.in  |   1 +
 luaa.c|   2 ++
 luadoc/client.lua |   1 +
 objects/client.c  |  68 
+++-
 objects/window.c  |   4 
 objects/window.h  |   4 +++-
 screen.c  |   2 +-
 spawn.c   |  10 --
 systray.c |  17 +
 xwindow.c |   2 +-
 20 files changed, 347 insertions(+), 63 deletions(-)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJWmRiDAAoJECLkKOvLj8sGKO4H/igDOI0bfl0OsxOz3YJqK/c2
k1g9J9W3hKz1PhI4npY6i58+ssMzODyO/GDcIQOOVc7X/4ypQ2afyIoxKbJjIuDi
dDeoPBXAt6UXc+0q1jBefKL5jmwhPv92zcW9/QRtzzZNkIDp2nenUhWKkDhTWfLV
55ih7nErT2ZAlUWQJCZwkLS11F2uaQa1My8ujg8dA+4FdQkcDbV+uq2rS/JMWVJT
cOdTcIrVqjZ/Fb1BllyLaqNVkL0CMySGocx6fx2cBPen3xsoZR/3DqMxXSTXHTBg
cpaBmRo2IeoEw+JQgb3ScP64ogfUoZUXPBeuxg1pbxZQA//DKa+/zBxa9hgE5IQ=
=g7AI
-END PGP SIGNATURE-

--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: Reparenting windows manager

[Uli Schlachter]

Hi,

Am 08.10.2015 um 16:13 schrieb Javier Jaramago Fernandez:
> does anybody know if awesome is already a re-parenting windows manager?

yes it is since commit 102063db / since awesome version 3.5.

> I'm
> asking because it still have Java issues even when the problems were
> supposed to be caused because awesome was a non-re-parenting windows
> manager. If anybody knows we could trace the problem and try to fix it in
> the OpenJdk at least (if they are the bug source).

Yup. Half the reason for turning this into a reparenting WM was "Java is being
stupid", but sadly Java also seems to be stupid with reparenting WMs.

Sorry.

Cheers,
Uli
-- 
"Do you know that books smell like nutmeg or some spice from a foreign land?"
  -- Faber in Fahrenheit 451

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: Dynamic tagging and tyrannical

[Uli Schlachter]

Hi,

Am 20.09.2015 um 13:25 schrieb Fran:
> It happens with everything. I just used Inkscape for testing purposes as I 
> was trying a more complicated rule matching instance and class which is where 
> I noticed the problem.
[...]

Ok, another quick idea: Move it to screen 2 first.

callback = function(c)
  c.screen = 2
  c:tags({tags[2][2]})
end

Cheers,
Uli

-- 
“Cold. Cold. Cold. Cold. Cold. Cold. Cold. Cold. Cold. Cold.” – Anna

--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: Dynamic tagging and tyrannical

[Uli Schlachter]

Hi,

Am 18.09.2015 um 10:18 schrieb Fran Thomson:
[...]
>   { rule = { class = "Inkscape" },
>  properties = { tag = tags[2][2], },
>   }
> 
> and
> 
>   { rule = { class = "Inkscape" },
>  callback = function (c) c:tags({tags[2][2]}) end
>   }
> 
> If I change the first index of tags[2][2] to tags[1][2] it'll show on screen 
> 1,
> and vice versa. But it's ignoring the second index - it always shows on the 
> tag
> that's displaying at the time.
[...]

does this only happen with Inkscape? I would test with something like xterm or
urxvt and if these work, then either your rule doesn't match inkscape (you can
test with callback = function(c) naughty.notify{ text = c.name } end) or
inkscape is interfering (you could try looking through its options and check if
it has something like "Remember window position" that you can turn off).

Cheers,
Uli
-- 
A normal person is just someone you don't know well enough yet.
 - Nettie Wiebe

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: rc.lua - configure to open a file using vim using keyboard shortcut

[Uli Schlachter]

Hi,

Am 04.09.2015 um 19:53 schrieb Julian Martinez:
[...]
> awful.key({ modkey, "Shift"   }, "y", function () awful.util.spawn("vim
> /home/julian/Documents/Information/zen.txt") end),
> 
> If I reload and run the above, the cursor blinks but nothing happens; I'm
> guessing that it executes in a shell, then exits.
[...]

You want to run vim in a terminal:

awful.util.spawn("urxvt -e vim zen.txt")

Cheers,
Uli
-- 
“Cold. Cold. Cold. Cold. Cold. Cold. Cold. Cold. Cold. Cold.” – Anna

--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: Random error?

[Uli Schlachter]

Hi,

Am 17.08.2015 um 01:54 schrieb Abraham Baker:
> I just got this random error that occured without any kind of trigger:
> Oops, an error happened!
> /usr/share/lua/5.3/lgi/component.lua:302: bad arg #2 to 'element'
> (Pango.Layout expected, got userdata)

I assume this is from the red popup that appears on errors? Could you also check
standard error output if it says anything more useful?
The following might be able to tell you where standard error is sent to:

 $ ls -l /proc/$(pidof awesome)/fd/2

Besides that, I don't have any good ideas or suggestions. Sorry.

[...]
> In the future, would it be better to send info about bugs like this to
> https://github.com/awesomeWM/awesome/issues , or is this mailing list just
> as good?

Either one is fine by me.

Cheers,
Uli
-- 
- Captain, I think I should tell you I've never
  actually landed a starship before.
- That's all right, Lieutenant, neither have I.

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: Menus without icons

[Uli Schlachter]

Hi,

Am 05.08.2015 um 10:19 schrieb Fran:
[...]
> 1) menus - I'd like text rather than the awesome image to click on to open my 
> menu. There doesn't seem to be an easy way to do this? I'm guessing maybe I 
> could do it with a textbox widget but I'm completely out of ideas.

The default config has this to create the awesome icon:

mylauncher = awful.widget.launcher({ image = beautiful.awesome_icon, menu =
mymainmenu })

Internally this "just" create an imagebox and attaches the menu to it. If you
want to use a textbox instead:

mylauncher = wibox.widget.textbox("Foo")
mylauncher:buttons(awful.button({}, 1, nil, function() mymainmenu:toggle() end))

> 2) tags - if you've got named tags rather than numbered how do you refer to 
> them? I've got different tags on each screen and I want to make certain that 
> Firefox only ever opens in the WWW tag on screen 1. Can I refer to this by 
> name? If not how do I know which number tag it is? 
[...]

Uhm. How do you create the tags? I assume awful.tag({ "first", "second", "third"
}), right? This creates the tags in order. So tag 1 will be "first", 2 will be
"second" etc.

If you use something more dynamic for managing tags, well, that code surely must
be involved somehow. What are you using?

Cheers,
Uli
-- 
Happiness can't be found -- it finds you.
 - Majic

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: Lua versus any other programming language

[Uli Schlachter]

Hi,

Others have answered enough things, I guess, and this is all a bike-shedding
exercise anyway. I just have one question:

Am 31.07.2015 um 22:56 schrieb Alexis BRENON:
[...]
>- No multithreading/multi-CPU support (only coroutines)
[...]

Which language really has this?

Even C officially supports this since C11. I guess "go" has something "good" for
this with their goroutines, but I don't know the details. For example, Python
has its global interpreter lock and I guess most other languages (including
Lua!) have something like this, too.

Cheers,
Uli
-- 
 I think someone had a Xprint version of glxgears at one point,
but benchmarking how many GL pages you can print per second
was deemed too silly to merge

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: How to change mouse cursor size ?

[Uli Schlachter]

Am 04.07.2015 um 19:26 schrieb Hacksign:
> added Xcursor.size: 64 in ~/.Xresources, but no any effect.

Is this applied?

Does xrdb -merge ~/.Xresources and then restarting awesome (ctrl-mod-r in the
default config) help?

> BTW:
> icon also too small any way make it larger ?

Dunno, I don't know much about GTK theming.
-- 
Who needs a ~/.signature anyway?

--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: Trouble building on Debian 7 (wheezy)

[Uli Schlachter]

Hi,

Am 03.06.2015 um 18:08 schrieb John Yates:
> I am trying to build the git tip.  Things seem to go fine until it is time
> to build the man pages:
> 
> ...
>> Scanning dependencies of target lgi-check
>> [ 55%] Built target lgi-check
>> Scanning dependencies of target man
>> [ 56%] Generating manpages/man1/awesome.1.xml
>> [ 57%] Generating manpages/man1/awesome.1
>> Note: Writing awesome.1
>> make[3]: *** [manpages/man1/awesome.1] Error 1
>> make[2]: *** [CMakeFiles/man.dir/all] Error 2
>> make[1]: *** [all] Error 2
>> make: *** [install] Error 2
> 
> 
> Any suggestions?

Uhm. The .xml is generated by something like this:

  asciidoc -d manpage -b docbook -o awesome.1.xml < awesome.1.txt

This step works fine. The actual manpage is then generated via:

  xmlto man awesome.1.xml

This step goes wrong.

I suggest you could try running this by hand and see if you get any more useful
output? Perhaps xmlto crashes or something like that?

I vaguely remember that there was once a bug in xmlto that we ran into, but I
can't find anything about it right now.

Note: The above would need to be run in manpages/ in awesome's source.

Cheers,
Uli
-- 
Bitte nicht mit dem verbleibenden Auge in den Laser gucken.
 - Vincent Ebert

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: Question about client.add_signal("custom_signal")

[Uli Schlachter]

Hi,

Am 28.05.2015 um 13:32 schrieb Aleksander Szczygieł:
> I have question - I need custom signal in my rc and I used undocumented 
> function client.add_signal("custom_signal") (like it was made in 
> awesoem/lib/awful/client.lua) to do it before using 
> client.emit_signal("custom_signal"), but this function is undocumented so I'm 
> not so sure if my way doing it is correct...

Hm, yay for our documentation...

> copied example from rc.lua:
> 
> -- add signal for toggling wibox on top (needed for forcing maximized clients 
> resize)
> client.add_signal("wibox_toggle")
> .
> .
> .
> globalkeys = awful.util.table.join(
> .
> .
> .
> awful.key({ modkey,   }, "b",
> function ()
> mywibox[mouse.screen].visible = not mywibox[mouse.screen].visible
> client.emit_signal("wibox_toggle")
> end, "Toggle panel"),
> .
> .
> .
> -- Connect toggle wibox signal to a resize function
> client.connect_signal("wibox_toggle", reload_maximized_windows)
> 
> I'm not sure if this function should be used from user side (but it doesn't 
> work without it) and I think if it function can be used it should be written 
> in documentation.

Yes this works, but, well, why? Just call your function directly? Or connect via
drawin.connect_signal("property::visible", function() print("foo") end) to
"whenever any wibox' visible property changes".

But, yeah, you can just add arbitrary signals and emit these signals with
arbitrary arguments. These arguments will be given to every function connected
to this signal.

Cheers,
Uli
-- 
- Buck, when, exactly, did you lose your mind?
- Three months ago. I woke up one morning married to a pineapple.
  An ugly pineapple... But I loved her.

--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: How to make a window unfocusable?

[Uli Schlachter]

Hi,

Am 18.05.2015 um 15:45 schrieb Thomas Baruchel:
[...]
> I would like to go a little further; can I expect to:
> * remove the title of the window from the taskbar?

Set its skip_taskbar property to true (can be done with awful.rules)

> * make the window unmovable (my tiling mode is
>   awful.layout.suit.tile ; I can change it of course,
>   but what I like is to have the clock on the left "master window" (?)
>   and have my xterm sharing the empty space on the right on
>   this workspace);

Just make it floating? That wouldn't make the window completely unmovable, but
should be close...?

Also, I'd suggest calling awful.client.dockable.set(c, true) on the client. Hm,
or rather:

function (c)
  awful.client.dockable.set(c, true)
  c:struts({ left = c.width })
  c:geometry({ x = 0 })
end

The above reserves some space at the left edge of the screen for the client and
moves it "in that direction".

> * make the window unfocusable; when I change the focus with the keyboard
>   by cycling next/previous; is there a way to "jump" over this window in
>   order to remove it from the cycle?

No idea if the following matches xxxterm. Adapt the check for the class,
instance or whatever:

do
  local original_filter = awful.client.focus.filter
  awful.client.focus.filter = function(c)
return c.class ~= "xxxterm" and original_filter(c)
  end
done

Cheers,
Uli

-- 
"Because I'm in pain," he says. "That's the only way I get your attention."
He picks up the box. "Don't worry, Katniss. It'll pass."
He leaves before I can answer.

--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: Using extra mouse buttons, and preventing client from receiving them

[Uli Schlachter]

Am 25.04.2015 um 05:03 schrieb Rena:
> Two, somewhat related questions, regarding Awesome v3.5.6:
> 
> 1. How to use high-numbered mouse buttons? e.g. I've added to my
> clientbuttons table:
> awful.button({ }, 10, awful.mouse.client.move),
> awful.button({ "Shift" }, 10, awful.mouse.client.resize),
> When I press button 10 the cursor changes to the "move" icon (or, with
> Shift, changes to the "resize" icon and snaps to a corner of the
> window), but when dragging, nothing happens; the cursor returns to the
> normal pointer and the window isn't moved or resized.

Sorry, nope. Button press and release events are reported for such high buttons,
but button move events only report the state of some "low" buttons (the first 8
buttons? I'm not sure right now).

So... awesome would need to be fixed somehow for this. My last attempt at this
caused bugs with stuck mouse buttons.

> 2. How to block mouse events from reaching the client? e.g. I use
> Mod4+scroll wheel to adjust a window's opacity, but this also causes
> the window to scroll; how to prevent that?

Same response: Sorry.

Cheers,
Uli
-- 
Homophobia - The fear that another man will treat you the way you treat women.

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: Different screen resolution for each virtual desktop?

[Uli Schlachter]

Hi,

On 29.03.2015 18:09, Felix E. Klee wrote:

I am looking for a window manager with virtual desktops, where I can
configure different screen resolutions for each desktop. A lower
screen resolution may also be realized by some kind of software zoom
tool.

[...]

Sorry, but awesome is not the right tool for you. It handles changes of the 
display size by restarting and loses all state. Switching the physical 
resolution also always causes flicker when the monitor is reconfigured.


The best way to do something like this with X11 might be through a composite 
manager. Such a program gets all the window contents and then "composes them" to 
produce the final result for output. Such a program could scale up a window 
before drawing it to the screen without the "real" physical resolution being 
affected. However, X11 does not allow to re-route mouse events, so this would 
break input. This is why (AFAIK / AFAIR) compiz' screen magnifier has some 
"weird moving things around when you move the mouse cursor"-behavior.


So the best-best technical way for this would be wayland. Wayland also allows 
the compositor to "mess" with mouse events and correct for any scaling that 
might be applied to the client window.


Cheers,
Uli

--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: Would you pls help me check my xcb demo client against awesome

[Uli Schlachter]

Hi,

Am 13.03.2015 um 10:55 schrieb 于清:
> Hi,
> This is a help request rather than a bug report, so if you are kind enough 
> and have some spare time, pls help me find out why my xcb client won't work.
> All this xcb client trying to do is to create a system tray icon. I have read 
> the xembed and systemtray's freedesktop specification and followed their 
> instructions, but with awesome wm the tray icon is a seperate window on a 
> ridiculous position(It seems to work in KDE somehow).
> I have tried to read awesome's source, but still can't understand why my code 
> fails.

First of, your code fails here when trying to figure out the systray's depth.
However, the result of that calculation isn't used anyway, so an "#if 0" fixes 
this.

The next problem is that awesome registers your systray window as both a regular
client and as a systray window. Skipping the MapWindow request fixes this as 
well.

Patch is attached.

Cheers,
Uli
-- 
"Why make things difficult, when it is possible to make them cryptic
and totally illogical, with just a little bit more effort?" -- A. P. J.
--- xcbdemo.cpp.orig	2015-03-13 18:35:40.404285455 +0100
+++ xcbdemo.cpp	2015-03-13 22:53:52.958379071 +0100
@@ -153,6 +153,8 @@ int main(int argc, char* argv[])
 return 1;
   }
 
+  // All of this is not used
+#if 0
   uint8_t traywnd_depth = 0xff;
   auto tray_visualid_cookie = xcb_get_property_unchecked(connection, false, traywnd,
 ATOMS[_NET_SYSTEM_TRAY_VISUAL], XCB_ATOM_VISUALID, 0, 1);
@@ -174,10 +176,12 @@ int main(int argc, char* argv[])
   }
   xcb_free(tray_visualid_reply);
   if (traywnd_depth == 0xff) {
+std::cerr << "can't figure out visual" << std::endl;
 xcb_disconnect(connection);
 return 1;
   }
   std::cerr << "traywnd_depth(32 means having alpha channel ): " << (int32_t)traywnd_depth << std::endl;
+#endif
 
   /* Create the window */
   uint32_t value_list[1] = {
@@ -273,7 +277,7 @@ int main(int argc, char* argv[])
   xcb_change_window_attributes(connection, traywnd, XCB_CW_EVENT_MASK, value_list);
 
   /* Map the window on the screen */
-  xcb_map_window(connection, window);
+  //xcb_map_window(connection, window);
   xcb_flush(connection);
 
   /* Dock the window to system tray */

[ANNOUNCE] awesome 3.5.6 released

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi everyone,

as always, I will just say: "It's been a while and so here is a new version"

Enjoy!
Uli

- -- 

awesome version 3.5.6 has been released. It is available from:

tar.xz: http://awesome.naquadah.org/download/awesome-3.5.6.tar.xz
md5: db1c31de752ab8e5f7aaa338718202af
sha1: 24c7fa0494f740cdfd54721e7a6bb506bd09156b

tar.bz2: http://awesome.naquadah.org/download/awesome-3.5.6.tar.bz2
md5: 81c7353932dd067cc7a222d9ede1cdd7
sha1: 0956438f90f25003692c360cfbc867181bd0a3ef

number of changes
- -
24

number of commiters
- ---
7

shortlog
- 
Uli Schlachter (14):
  Call AllowEvents after grabbed events on a drawin
  wbox: Make :find_widgets() easily accessible
  systray: Only intern the atom once
  systray: Only register/unregister when needed
  awful.widget.button: Override :set_image() to do the right thing
  drawin: Don't special-case moves
  drawin_update_drawing: Remove optimization for invisible drawins
  wibox.layout.base.rect_to_device_geometry: Fix for "weird" rotations
  Don't move clients on ConfigureRequests (FS#1030)
  Implement icon_pixmap and icon_mask from WM_HINTS (FS#1297)
  Don't set a background-pixel for our client frame windows
  Unmap minimized clients
  awful.mouse.finder: Remove rounded_corners call
  change codename

Emmanuel Lepage Vallee (5):
  awful.tag.update: Fix identical tag set detection
  Add context to request::activate signal
  tag: Improve tag property::index support (FS#1229)
  tag.delete: Do not reset client tag when unnecessary
  layouts: Allow layouts to be invoked with fake data

Evžen (1):
  fix(lib.awful.taglist): multiple tag selection

Jason Yan (1):
  Fix check against clients in taglist.

Sindre Føring Devik (1):
  FS#1278 - Menubar should check all standard directories

findkiko (1):
  Vim style menu navigation in addition to arrow keys

memeplex (1):
  Fix for FS#1293


diffstat
- 
 awesomeConfig.cmake|   2 +-
 draw.c |  25 ++
 event.c|  18 
 ewmh.c |   3 ++-
 globalconf.h   |   4 
 lib/awful/layout/suit/magnifier.lua.in |   5 +++--
 lib/awful/layout/suit/tile.lua.in  |   2 +-
 lib/awful/menu.lua.in  |   8 +++
 lib/awful/mouse/finder.lua.in  |   6 --
 lib/awful/rules.lua.in |   2 +-
 lib/awful/tag.lua.in   |  83 
+++-
 lib/awful/widget/button.lua.in |  21 ---
 lib/awful/widget/taglist.lua.in|  12 +--
 lib/menubar/menu_gen.lua.in|   7 ++-
 lib/wibox/init.lua.in  |  10 +
 lib/wibox/layout/base.lua.in   |  16 +++---
 objects/client.c   | 119 
+--
 objects/client.h   |   5 -
 objects/drawin.c   |  14 +
 property.c |  14 +
 systray.c  |  73 
+--
 21 files changed, 305 insertions(+), 144 deletions(-)
- -- 
- - Captain, I think I should tell you I've never
  actually landed a starship before.
- - That's all right, Lieutenant, neither have I.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJUsYM8AAoJECLkKOvLj8sGmO0IAK/qwLQH/kT3NINTJDeedXCW
DAZOniBpiPmO+rUC9yt4iFMbIrsg/cTQNsDjXgxZRcD5/QfFftVMHGc/jIDaJoWG
ULziY9nX6rjJErtMxflOVSfCJDceGvs8CppL/0npvG5TPZQAXyGbX1sh+L+kkrVo
fovQb2v9NdsQUugbYAzC2OY99kFhJOYMMiQgg2HNHyT9ck3HRvUWbmy7Qyeyv4eL
1AJqmDyQeQMkdVuZz7Xc+dHOCs72DVzyWhl+bGMI3AHUV+HUsfxaF+0Px6mjxOJ+
9K+fp1PZj/9TNWDjWIj72O2lkgecCPzim1UEMJHK2JcHcCu465ksrXTT1nWJIY8=
=GOdI
-END PGP SIGNATURE-

--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: cairo painting turned slow

[Uli Schlachter]

Hi,

Am 12.12.2014 um 11:48 schrieb Joren Heit:
> My homemade alt-tab implementation (
> http://awesome.naquadah.org/wiki/Familiar_Alt_Tab) suddenly became
> exhaustingly slow after a recent (i.e. last couple of weeks) Debian
> upgrade. I think it's really the rendering-part with Cairo that is the
> cause.
[...]

How long is "last couple of weeks"? According to [0], unstable switched from
cairo 1.12 to 1.14 on 2014-10-21 and testing did so on 2014-11-03. Could your
check your /var/log/dpkg.log to see when you did that cairo upgrade? Could you
perhaps also get and install an older cario version (e.g. from debian stable) to
see if that fixes your issue?

Cheers,
Uli

[0]: https://packages.qa.debian.org/c/cairo.html
-- 
"Why make things difficult, when it is possible to make them cryptic
and totally illogical, with just a little bit more effort?" -- A. P. J.

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: compiling awesome on red hat 6

[Uli Schlachter]

Am 31.12.2014 um 15:11 schrieb Squires, Eric G:
> Greetings,
> 
> I have been using awesome on Arch for a while and now trying to compile
> it for a red hat 6 system. After installing all the dependencies (cairo,
> etc), I am getting the following when I make awesome (version 3.5.5):
> 
> $: cd awesome-3.5.5
> $: make
> 
>:
>:
> 
>CMakeFiles/awesome.dir/dbus.c.o: In function `luaA_rawlen':
>/home/esquires3/repos/software/awesome/awesome-3.5.5/luaa.h:99: undefined 
> reference to `lua_rawlen'
> 
> There are quite a few other similar undefined reference errors in the
> output. Lua is installed in /usr/local.
> 
> Can you all assist me with getting awesome compiled? 

Hi,

which lua versions did you install?

lua_rawlen is a function from lua 5.2 while the same function in lua 5.1 was
(pretty much) lua_objlen().

If you want to hear my theory: You are compiling awesome against lua headers
from lua 5.2 (which is it tries to use lua_rawlen()), but link it against the
library from lua 5.1 (which is why lua_rawlen() cannot be found).

Cheers,
Uli
-- 
"Why make things difficult, when it is possible to make them cryptic
and totally illogical, with just a little bit more effort?" -- A. P. J.

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: Placement of web notifications on the screen

[Uli Schlachter]

Hi,

Am 05.11.2014 um 04:39 schrieb Rob Hoelz:
[...]
> My problem is this: when I see a web notification
> (https://developer.mozilla.org/en-US/docs/Web/API/notification)
> displayed, it always appears on screen 0 of my two monitor set up, even
> if the browser displaying the notification is on screen 1.  As I tend
> to put "back burner" stuff on screen 0 and primarily work off of screen
> 1, this causes me to sometimes miss web notifications, which is pretty
> annoying.
> 
> Ideally, I would like them to show up in the upper right corner of
> screen 1, where I have naughty displaying its notifications.  However,
> after digging around, I've found that the X11 windows used to implement
> these notifications do not generate client manage events; in fact, they
> don't generate any events that are exposed to the Lua API, as far as I
> can tell.  It seems that they generate a map notify (rather than a map
> request, and not to be confused with a mapping notify) event, which
> awesome doesn't seem to handle.

Firefox doesn't like naughty's implementation of the notification spec because
it does not implement actions (see e.g. [0]). As a result, firefox uses its own,
built-in "notification daemon" replacement.

> Has anyone seen this behavior and come with a good solution for their
> rc.lua?  If not, developers of awesome: would you be open to a patch
> exposing map notify events via the Lua API so that users may handle
> this scenario?
[...]

What exactly would you want to do with those map notify events? They can't
really be used for anything.

Firefox shows its notifications through windows with override_redirect=1. This
property means "dear WM, I know better than you, do not dare to touch this
window". This is why awesome doesn't generate a manage event for these windows.
It doesn't get many events for these windows from the X server either. So to
awesome (and thus to lua code) these windows don't exist and there is not much
else that we can do.

Other kinds of override_redirect=1 windows are e.g. menus and tooltips.

Cheers,
Uli

[0]:
http://askubuntu.com/questions/33614/why-do-firefox-and-thunderbird-not-use-notify-osd
-- 
"Why make things difficult, when it is possible to make them cryptic
and totally illogical, with just a little bit more effort?" -- A. P. J.

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: memory leak in cairo context paint() method?

[Uli Schlachter]

Hi,

Am 03.11.2014 um 22:21 schrieb Joren Heit:
> I received a bug-report
>  on github the other
> day of someone who's been having problems with my alt-tab implementation.
> The preview-window that pops up is refreshed at some rate (e.g. 30fps)
> calling cr:paint() each time for every widget to draw the window-contents
> in a preview-box.

https://github.com/jorenheit/awesome_alttab/blob/master/init.lua#L151

local icon
if c.icon == nil then
   icon = gears.surface(gears.surface.load(noicon))
else
   icon = gears.surface(c.icon)
end

First: gears.surface() and gears.surface.load() are the same function. Replace
the above code with:

 local icon = gears.surface(c.icon or noicon)

Second: The above change will also fix a memory leak. (Technical details below)
However, I don't think that leaking icons is a big memory leak. Also, awesome
doesn't copy the icon when returning it to lua, so this isn't the leak that we
are looking for.

Third: Urgh. So the following code begins at line 209:

cr:translate(tx, ty)
cr:scale(sx, sy)
cr:set_source_surface(gears.surface(c.content), 0, 0)
cr:paint()

You don't want to know the details, but could you try this:

  local foo = gears.surface(c.content)
  cr:translate(tx, ty)
  cr:scale(sx, sy)
  cr:set_source_surface(foo, 0, 0)
  cr:paint()
  foo:finish()

But the above should (could?) be fixed via the collectgarbage() calls which you
already tried...

Also, my proposed change is technically wrong and might break later. So let's
see if it just helps in figuring out what's up.

You might also want to check your lua-lgi version because of this bug:

https://github.com/pavouk/lgi/issues/70

Cheers,
Uli

P.S.: Technical details:
Lua uses garbage collection. You don't have to explicitely free stuff, it
happens automagically for you. To free cairo surfaces, lua has to be told how
these can actually be freed. Due to the way that lgi works, the C core cannot
tell lua to do this. So accessing c.icon actually creates a memory leak. Then
gears.surface() does some magic to wrap things up so that lua can free the
surface properly. If you do "if c.icon == nil then", when the icon isn't
actually nil, the reference that the C code gives to lua is leaked. So every
call to c.icon really has to have its result passed to gears.surface().
-- 
"Because I'm in pain," he says. "That's the only way I get your attention."
He picks up the box. "Don't worry, Katniss. It'll pass."
He leaves before I can answer.

--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: How to place widgets on desktop itself?

[Uli Schlachter]

Am 10.10.2014 um 18:37 schrieb Elv1313 .:
> Wow... Huston, we have a problem
> 
> -- this work
> mydesktop_wibox.x = 100
> mydesktop_wibox.width = 100
> mydesktop_wibox.height = 100
> mydesktop_wibox.y = 100
> 
> 
> -- this doesn't work, have the problem described above
> mydesktop_wibox.x = 100
> mydesktop_wibox.y = 100
> mydesktop_wibox.width = 100
> mydesktop_wibox.height = 100
> 
> Uli, any idea about this?

Urgh.

My first idea would be:


--You have to create a wibox first:
local mydesktop_wibox = wibox({
   x = 100, y = 100, width = 100, height = 100, below = true})

--then make it transparent:
mydesktop_wibox:set_bg("#") --transparent

-- and set your widget
mydesktop_wibox:set_widget(your_widget)

mydesktop_wibox.visible = true


IMO nicer that way. I also moved the .visible = true to the end, although that
shouldn't really make a difference.

Anyway, for the bug in question:
Fixed by [0] and a similar case is fixed by [1].

Cheers,
Uli


[0]:
http://git.naquadah.org/?p=awesome.git;a=commit;h=70fef83e50336c5e0105d90cb14e83f6631214d0
[1]:
http://git.naquadah.org/?p=awesome.git;a=commit;h=d76e20bbcefd28de17300f2766a28bffb6bcafe3
-- 
99 little bugs in the code
99 little bugs in the code
Take one down, patch it around
117 little bugs in the code
  -- @irqed

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: awful.util.spawn creates a process with PPID=1. Any way to create a child of awesome process?

[Uli Schlachter]

On 09.10.2014 18:13, Dmitry Grigoriev wrote:
[...]

Now I want to show a confirmation yes-no dialog and get user's choice.
For now I know only one way - via external process, so I do this:

local pid = awful.util.spawn("Xdialog --yesno 'hello?' 7 34")
local x1, x2, status = posix.wait(pid)
if not x1 then error("posix.wait() failed for PID=" .. pid .. ": " ..
x2) end
local isYes = status == 0

The problem is that both spawn() and spawn_with_shell() create a child
of init process (PPID=1), not the child of awesome, so wait() always
gives me "No child processes" error. Is there any way to fix/overcome this?


No. awesome.spawn() (the function that awful.util.spawn() uses) tries to get as 
far away from the child process as possible. There was a bug report where 
awesome "crashed" when some special program was started. The reason was that 
this program killed its whole process group on some events. Since then, I don't 
think awesome has any business with being a parent of anything. Too risky.



I also tried os.exec() and posix.fork()+posix.exec(), both ways make WM
unresponsive: mouse cursor moves but no other reactions to my
mouse/keyboard commands.


How about io.popen()? I don't have Xdialog, but hopefully this represents its 
behavior:


> return io.popen("(exit 1) && echo yes"):read("*a")

> return io.popen("(exit 0) && echo yes"):read("*a")
yes

This assumes that Xdialog creates an override_redirect window. While Xdialog is 
running, awesome will freeze and stop doing anything until Xdialog exits. This 
is also what would happen with your posix.wait().


Cheers,
Uli

--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: awesome-client && dbus reply

[Uli Schlachter]

On 05.10.2014 17:17, Gerome Fournier wrote:

Hi,

I've been using awesome-client with success to execute some lua code
through dbus, but I'm wondering how to obtain a reply from this code.

If I have a function like this un my rc.lua file:

 dbus_test = function()
 -- do something...

 -- let's try to return a value
 return "test"
 end

when I call it through dbus, I dont get any response. The code is
executed, but the return statement is not handled properly, a dbus
reply is not generated (awesome-client is calling dbus-send
with the argument --print-reply):

 $ echo "dbus_test()" | awesome-client

[...]

Try something like this:

 $ echo 'return "foo"' | awesome-client
   string "foo"

So in your case you'd want:

 $ echo "return dbus_test()" | awesome-client

Cheers,
Uli

--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: glitches after update

[Uli Schlachter]

Hi,

Am 30.09.2014 um 21:35 schrieb Joren Heit:
> Hi,
> 
> I just upgraded my Debian Jessie systems, and noticed some weird stuff. I
> first saw it in my Alt-Tab implementation, about which I posted before (
> https://awesome.naquadah.org/wiki/Familiar_Alt_Tab). The client previews
> and icons now have pink borders around them. Then, when I resized a
> terminal window, more pinkness appeared. It's hard to explain, so I
> attached two screenshots that hopefully clarify the issue. I guess this
> must have something to do with the new cairo or lgi version that came with
> the upgrade. Does anyone have any idea how to fix this?

My guess would be "video driver bug". Are you using an intel video driver?

Try running awesome with --no-argb to work around this.

Cheers,
Uli

> Joren
> 
> package versions post-upgrade:
> awesome 3.5.5
> lua-lgi 0.8.0
> 
> $ dpkg -l | grep ciaro
> ii  libcairo-gobject2:amd64   1.12.16-5 amd64
> The Cairo 2D vector graphics library (GObject library)
> ii  libcairo-perl 1.104-2   amd64
> Perl interface to the Cairo graphics library
> ii  libcairo-script-interpreter2:amd641.12.16-5 amd64
> The Cairo 2D vector graphics library (script interpreter)
> ii  libcairo2:amd64   1.12.16-5 amd64
> The Cairo 2D vector graphics library
> ii  libcairo2-dev 1.12.16-5 amd64
> Development files for the Cairo 2D graphics library
> ii  libcairomm-1.0-1  1.10.0-1.1amd64
> C++ wrappers for Cairo (shared libraries)
> ii  libpangocairo-1.0-0:amd64 1.36.7-1  amd64
> Layout and rendering of internationalized text
> ii  libpixman-1-0:amd64   0.32.6-3  amd64
> pixel-manipulation library for X and cairo
> ii  libpixman-1-dev   0.32.6-3  amd64
> pixel-manipulation library for X and cairo (development files)
> ii  python-cairo  1.8.8-1+b2amd64
> Python bindings for the Cairo vector graphics library
> ii  python-gi-cairo   3.14.0-1  amd64
> Python Cairo bindings for the GObject library
> ii  python3-cairo 1.10.0+dfsg-4+b1  amd64
> Python 3 bindings for the Cairo vector graphics library
> ii  python3-gi-cairo  3.14.0-1  amd64
> Python 3 Cairo bindings for the GObject library
> 


-- 
Bruce Schneier can read and understand Perl programs.

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: client.content

[Uli Schlachter]

Hi,

Am 22.09.2014 um 13:06 schrieb Joren Heit:
> The client-table contains a field called 'content', which is an image
> representing the client window. Does anyone know how I can draw this onto a
> Cairo context?

$ echo 'local cairo = require("lgi").cairo local surface =
cairo.ImageSurface(cairo.Format.RGB24, 20, 20) local cr = cairo.Context(surface)
cr:set_source_surface(require("gears.surface")(client.focus.content), 0, 0)
cr:paint() surface:write_to_png("/tmp/foo.png")' | awesome-client
$ ls -l /tmp/foo.png
-rw-r--r-- 1 psychon psychon 358 Sep 23 09:47 /tmp/foo.png
$ feh /tmp/foo.png
[Displays some random character from my terminal]

Same code with some more line breaks:

  local cairo = require("lgi").cairo
  local surface = cairo.ImageSurface(cairo.Format.RGB24, 20, 20)
  local cr = cairo.Context(surface)
  cr:set_source_surface(require("gears.surface")(client.focus.content), 0, 0)
  cr:paint()
  surface:write_to_png("/tmp/foo.png")'

Cheers,
Uli
-- 
Happiness can't be found -- it finds you.
 - Majic

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: Shortcut to clear "urgent"-flag

[Uli Schlachter]

Hi,

Am 18.09.2014 um 09:49 schrieb Fabian Furger:
[...]
> local cc = awful.client.urgent.get()
> if (cc ~= nil) then
> urgent = tostring(cc.urgent)
> naughty.notify({ text = cc.name .. urgent })
> awesome.client.urgent.delete(cc)

Try cc.urgent = false. In contrast to awesome.client, this both exists and 
works.

> urgent = tostring(cc.urgent)
> naughty.notify({ text = cc.name .. urgent })
> end
[...]

Cheers,
Uli
-- 
- Buck, when, exactly, did you lose your mind?
- Three months ago. I woke up one morning married to a pineapple.
  An ugly pineapple... But I loved her.

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: Adjust screen brightness with launcher

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

Am 15.09.2014 um 12:39 schrieb Zum Testen:
[...]
> mybrightness.lua (the global mybrightness_launcher will be added to my
> wibox):
> 
> local awful = require("awful")
> 
> local mybrightness_menu = awful.menu({ items = {{"100%", function()
> awful.util.pread("xbacklight -time 0 -set 100"); brightness_update() end}, 
> {" 30%", function() awful.util.pread("xbacklight -time 0 -set  30");
> brightness_update() end}}}) mybrightness_launcher =
> awful.widget.launcher({image = "bright100.png", menu = mybrightness_menu})
> 
> function brightness_update() local max_brightness = awful.util.pread('cat
> /sys/class/backlight/intel_backlight/max_brightness') local
> actual_brightness = awful.util.pread('cat
> /sys/class/backlight/intel_backlight/actual_brightness') local
> brightness_percent = 0 if max_brightness ~= nil and actual_brightness ~=
> nil then brightness_percent = actual_brightness * 100 / max_brightness end
> 
> if brightness_percent > 50 then brightness_icon = "bright100.png" else 
> brightness_icon = "bright030.png" end 
> mybrightness_launcher:set_image(brightness_icon) end
> 
> brightness_update()

Apparently, :set_image() was never intended to be usable on launchers / be
accessible after the widget was created.

Fixed with this commit:

http://git.naquadah.org/?p=awesome.git;a=commitdiff;h=a113fe0f3c268f10e1a0264d0fbc2962d3c562a7;hp=305f148c4b747b7e28f679deaf6a6872ebbf6f8d

That commit is also attached to this mail.

If you are using 3.5, you should be able to apply these changes to your
/usr/share/awesome/lib/awful/widget/button.lua and your code starts working.

Cheers,
Uli
- -- 
"Are you preparing for another war, Plutarch?" I ask.
"Oh, not now. Now we're in that sweet period where everyone agrees that our
recent horrors should never be repeated," he says. "But collective thinking is
usually short-lived. We're fickle, stupid beings with poor memories and a great
gift for self-destruction.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJUFtV5AAoJECLkKOvLj8sGyzkH/itUsPywOP2TGAEzS8PJJuNA
2IEojotI2U0PWBbSVHb6omozWOJ2rENL39pXokkB6lcw1RNPSUqVwDd0fjDm/LSA
EdtoLH663xcBmncLr741p5HNxPi7GS/Kb0r9rBXft9WMEgjyLl0zFq/TWZcjuppF
N9hQCX722WH6qeRdoeNRpxisFRyVb9fY9hlR4jo4sb9aBnn8emav1K5NnUmtmm+q
6hKngYIZdXE1ghpQOpSmQKDzIJqH9XzmJfEPkS1UX0e6OiyBi3cnIsFans3UmyNn
tmEtHx5xFmFXl10igaGhN4vgizkLyfoSXFyViQqMsstPj1m/B9akvztrFjj6tAg=
=BxXf
-END PGP SIGNATURE-
From a113fe0f3c268f10e1a0264d0fbc2962d3c562a7 Mon Sep 17 00:00:00 2001
From: Uli Schlachter 
Date: Mon, 15 Sep 2014 13:55:21 +0200
Subject: [PATCH] awful.widget.button: Override :set_image() to do the right
 thing

Reported-at: http://article.gmane.org/gmane.comp.window-managers.awesome/10778
Signed-off-by: Uli Schlachter 
---
 lib/awful/widget/button.lua.in | 21 ++---
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/lib/awful/widget/button.lua.in b/lib/awful/widget/button.lua.in
index 0f0d758..204081e 100644
--- a/lib/awful/widget/button.lua.in
+++ b/lib/awful/widget/button.lua.in
@@ -24,15 +24,22 @@ function button.new(args)
 if not args or not args.image then
 return widget.empty_widget()
 end
-local img_release = surface.load(args.image)
-local img_press = cairo.ImageSurface(cairo.Format.ARGB32, img_release.width, img_release.height)
-local cr = cairo.Context(img_press)
-cr:set_source_surface(img_release, 2, 2)
-cr:paint()
 
 local w = imagebox()
-w:set_image(img_release)
-w:buttons(abutton({}, 1, function () w:set_image(img_press) end, function () w:set_image(img_release) end))
+local orig_set_image = w.set_image
+local img_release
+local img_press
+
+w.set_image = function(w, image)
+img_release = surface.load(image)
+img_press = img_release:create_similar(cairo.Content.COLOR_ALPHA, img_release.width, img_release.height)
+local cr = cairo.Context(img_press)
+cr:set_source_surface(img_release, 2, 2)
+cr:paint()
+orig_set_image(w, img_release)
+end
+w:set_image(args.image)
+w:buttons(abutton({}, 1, function () orig_set_image(w, img_press) end, function () orig_set_image(w, img_release) end))
 return w
 end
 
-- 
2.1.0



0001-awful.widget.button-Override-set_image-to-do-the-rig.patch.sig
Description: PGP signature

Re: change DPI

[Uli Schlachter]

Hey,

On 24.08.2014 11:51, Paul Jolly wrote:
> This almost worked for me, except that the menus are not correctly drawn;
> the font appears to be the correct, larger size, but the menus themselves
> don't appear to have grown to accommodate the larger font.
> 
> Any thoughts?

My thought is the "menu_height" option in your theme.

Awesome bases its wibox height on the font height (1.5 times the font height),
but the menu_height seems to be hardcoded in the theme.

Cheers,
Uli

> On 22 March 2014 14:14, Uli Schlachter  wrote:
> 
>> Hey,
>>
>> On 22.03.2014 11:30, Dan Milon wrote:
>>> I installed archlinux & awesome on a macbook pro with a retina
>>> display. As you can imagine everything was super tiny. I added "Xft.dpi
>>> = 196" to xrdb and now gtk, qt etc apps display normally, but the awesome
>>> status bar still shows tiny.
>>>
>>> It seems that awesome itself is unaffected by "Xft.dpi".
>>> Do you have any idea what I could do to fix this?
>>
>> No idea if this actually works, but (if you are using 3.5, which I think
>> you
>> are), you could try adding the following to the *beginning* (beginning is
>> the
>> very first line of your config, not later) of your rc.lua:
>>
>>   require("lgi").PangoCairo.font_map_get_default():set_resolution(196)
>>
>> Please tell me if this has any effect.
>>
>> Uli
>>
>>
>> P.S.: For future-Uli: Google knows about gdk_screen_get_resolution() and
>> Debian
>> code search figured out that this function is used in a call to
>> pango_cairo_context_set_resolution() inside
>> gtk_widget_update_pango_context().
>>
>> P.P.S.: It would be nice to figure out if lgi let's us use
>> gdk_screen_get_resolution() and gdk_screen_get_font_options() so that they
>> can
>> be used in wibox.widget.textbox. No idea how yet, but if we figure out a
>> way to
>> map gdk screens to awesome screens, that could be used for implementing
>> this
>> "properly". Or we just link awesome against Gdk and use this code properly
>> and
>> get rid of awesome's screens, but that might result in a fight about who
>> owns
>> the X11 connection...
>> --
>> Who needs a ~/.signature anyway?
>>
>> --
>> To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
>>
> 


-- 
- Captain, I think I should tell you I've never
  actually landed a starship before.
- That's all right, Lieutenant, neither have I.

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: Fullscreen and aspect ratio hints

[Uli Schlachter]

Hi,

On 15.07.2014 23:54, Alexandros Diamantidis wrote:
> I've encountered a little problem with the pqiv image viewer:
> fullscreen doesn't work correctly in many cases. I submitted a bug
> report to pqiv's bug tracker and its author believes it's a problem with
> awesome, namely that windows requesting an aspect ratio not matching the
> screen before going fullscreen don't actually become full-screen.
> 
> Here's the bug report:
> 
> https://github.com/phillipberndt/pqiv/issues/27
> 
> His workaround is calling
> 
> gtk_window_set_geometry_hints(main_window, NULL, NULL, 0);
> 
> before going fullscreen.

>From the bug tracker, here is some simple python to reproduce the bug:

import gtk
w = gtk.Window()
w.connect("hide", gtk.main_quit)
w.show()
w.set_size_request(400, 600)
w.set_geometry_hints(min_aspect=1, max_aspect=1)
w.fullscreen()
gtk.main()

> Comments? Is this indeed an awesome bug, or maybe something that I could
> fix with some local configuration?

Nope, I don't think you can do anything against this.

I played around a little with xtrace. This tool analyzes all the X11 protocol
traffic and prints what the above python script is doing. In X11, a
ConfigureWindow request can be used to resize a window. A ConfigureNotify event
is received when the window really was resized (e.g. by the window manager or by
the program itself).

Here are all the relevant ConfigureWindow and ConfigureNotify events that occur
on the programs main window (0x0263):

000:>:001c:32: Reply to InternAtom: atom=0x174("_NET_WM_STATE_FULLSCREEN")
(The fullscreen state has atom 0x174, this will be needed later)

000:>:00b7: Event ConfigureNotify(22) event=0x0263 window=0x0263
above-sibling=0x0260001b x=0 y=0 width=200 height=200 border-width=0
override-redirect=false(0x00)
000:>:00bb: Event MapNotify(19) event=0x0263 window=0x0263
override-redirect=false(0x00)
(MapNotify means the window became visible aka "mapped". So it first becomes
visible with a size of 200x200 which fits with the above python code because the
w.show() happens so early)

000:<:00bd: 44: Request(25): SendEvent propagate=false(0x00)
destination=0x009d event-mask=SubstructureNotify,SubstructureRedirect
ClientMessage(33) format=0x20 window=0x0263 type=0x171("_NET_WM_STATE")
data=0x01,0x00,0x00,0x00,0x74,0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00;
(Yay for this ugly format. So this wants to add (first four bytes, value 1) the
property 0x174 (next four bytes, this is _NET_WM_STATE_FULLSCREEN as seen above)
to the window. So this is the point where the fullscreen() call happens.)

000:>:00be: Event ConfigureNotify(22) event=0x0263 window=0x0263
above-sibling=None(0x) x=0 y=0 width=1920 height=1060 border-width=0
override-redirect=false(0x00)
000:>:00be: Event ConfigureNotify(22) event=0x0263 window=0x0263
above-sibling=None(0x) x=0 y=22 width=1920 height=1060 border-width=0
override-redirect=false(0x00)
000:>:00be: Event (generated) ConfigureNotify(22) event=0x0263
window=0x0263 above-sibling=None(0x) x=0 y=42 width=1920 height=1060
border-width=0 override-redirect=false(0x00)
000:>:00be: Event ConfigureNotify(22) event=0x0263 window=0x0263
above-sibling=None(0x) x=0 y=22 width=1920 height=1038 border-width=0
override-redirect=false(0x00)
000:>:00c0: Event ConfigureNotify(22) event=0x0263 window=0x0263
above-sibling=None(0x) x=0 y=0 width=1920 height=1080 border-width=0
override-redirect=false(0x00)
000:>:00c1: Event (generated) ConfigureNotify(22) event=0x0263
window=0x0263 above-sibling=None(0x) x=0 y=0 width=1920 height=1080
border-width=0 override-redirect=false(0x00)
(Some resizing happens and awesome takes a while to finally position the window.
Because I am on a tiling layout, the window ends up in size 1920x1038 (my screen
size is 1920x1060))

000:>:00c1: Event PropertyNotify(28) window=0x0263
atom=0x171("_NET_WM_STATE") time=0x00e637cb state=NewValue(0x00)
000:>:00c1: Event (generated) ConfigureNotify(22) event=0x0263
window=0x0263 above-sibling=None(0x) x=0 y=0 width=1920 height=1080
border-width=0 override-redirect=false(0x00)
(Window becomes fullscreen and has the correct size)

000:<:00c8: 96: Request(18): ChangeProperty mode=Replace(0x00) window=0x0263
property=0x28("WM_NORMAL_HINTS") type=0x29("WM_SIZE_HINTS")
data=0x0290,0x,0x,0x,0x,0x0190,0x0258,0x,0x,0x,0x,0x0001,0x0001,0x0001,0x0001,0x,0x,0x0001;
(The program changes its size hints. 0x190 is 400 in decimal and 0x258 is 600.
So the size request was just set. Why only now?!)

000:<:00e2: 96: Request(18): ChangeProperty mode=Replace(0x00) window=0x0263
property=0x28("WM_NORMAL_HINTS") type=0x29("WM_SIZE_HINTS")
data=0x0290,0x,0x,0x,0x,0x0190,0x0258,0x,0x0

Re: Problem with autofocus

[Uli Schlachter]

Hi,

On 25.06.2014 23:25, Matías Battocchia wrote:
> I've just upgraded Awesome. I am running version 3.5.2.164.g9a0ba0f-1 on
> Arch Linux with default rc.lua.
> 
> If I select a tag that contains at least one maximized window such tag does
> not get colored as selected nor the titlebar displays the windows title.
> Having more than one window allows me to focus on a non-focused one,
> Awesome noticing the focus. Waiting some random time (from seconds to
> minutes) also makes Awesome to color the tab and to write the window title.

Likely a video driver bug. No idea why, but some video drivers sometimes ignore
our repaints on tag switches. The "random time" likely is the time until the
clock widget updates the next time and causes another repaint.

Only known work-around is starting awesome with the --no-argb option (which has
its negative side effects, but unless you are using true transparency and are
running a composite manager, you shouldn't notice anything).

And no, --no-argb doesn't really change anything at all in what awesome does. I
am quite certain that anything that gets fixed via --no-argb is a video driver
bug or a bug in the X server itself.

> Also, a different problem: when trying to change the layout this error
> happens:
> 
> init.lua:80: attempt to perform arithmetic on local 'i' (a table value)
> 

Since you are using latest git, you likely didn't update your config for this
change:

http://git.naquadah.org/?p=awesome.git;a=commitdiff;h=3cbdc2a79ff7230fe717ec71c0f7442043e93fd1;hp=bfc6065ad9d508c82189c73c7b61c9f658a5118c

Cheers,
Uli
-- 
 I think someone had a Xprint version of glxgears at one point,
but benchmarking how many GL pages you can print per second
was deemed too silly to merge

--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: Assign client properties in rc.lua (for a scratchdrop extension)

[Uli Schlachter]

Hi,

On 10.06.2014 14:51, Markus Fuchs wrote:
> I tried to extend the scratchdrop module by Lucas de Vries such that
> the given clients keep their "scratchdrop properties" after awesome is
> restarted. You can find the code here:
> 
> https://gist.github.com/fixje/4a1ef48cbbfe5ba6e070
> 
> With scratchdrop you can assign keys which toggle the visibility of
> certain programs that do not show up as managed clients in awesome.
> The list of clients managed by the scratchdrop module is stored in a
> variable which is re-initialized after awesome is restarted. To
> circumvent this issue, I put the necessary values into custom X
> properties and re-assign them:
> 
> awesome.register_xproperty("AWESOME_SCRATCHTOP_VERT", "string")
> awesome.register_xproperty("AWESOME_SCRATCHTOP_HORIZ", "string")
> awesome.register_xproperty("AWESOME_SCRATCHTOP_WIDTH", "string")
> awesome.register_xproperty("AWESOME_SCRATCHTOP_HEIGHT", "string")
> awesome.register_xproperty("AWESOME_SCRATCHTOP_STICKY", "boolean")
> awesome.register_xproperty("AWESOME_SCRATCHTOP_SCREEN", "string")
> awesome.register_xproperty("AWESOME_SCRATCHTOP_PROG", "string")
> 
> function scratchdrop.restore()
> for k, c in pairs(client.get()) do
> if c:get_xproperty("AWESOME_SCRATCHTOP_VERT") ~= "" then
> local vert   = c:get_xproperty("AWESOME_SCRATCHTOP_VERT")
> local horiz  = c:get_xproperty("AWESOME_SCRATCHTOP_HORIZ")
> local width  = c:get_xproperty("AWESOME_SCRATCHTOP_WIDTH")
> local height = c:get_xproperty("AWESOME_SCRATCHTOP_HEIGHT")
> local sticky = c:get_xproperty("AWESOME_SCRATCHTOP_STICKY")
> local screen = c:get_xproperty("AWESOME_SCRATCHTOP_SCREEN")
> local prog = c:get_xproperty("AWESOME_SCRATCHTOP_PROG")
> width = tonumber(width)
> height = tonumber(height)
> screen = tonumber(screen)
> set_client_properties(c, vert, horiz, width, height,
> sticky, screen, prog)
> 
> if not dropdown[prog] then
> dropdown[prog] = {}
> end
> dropdown[prog][screen] = c
> 
> c.hidden = true
> local ctags = c:tags()
> for i, t in pairs(ctags) do
> ctags[i] = nil
> end
> c:tags(ctags)
> end
> end
> end
> 
> 
> The problem arises when I try to call scratchdrop.restore() from
> rc.lua. I tried to place it at the end of the config, but client
> attributed are not restored at all. On the other hand, I can just call
> the function from the awesome lua prompt after a successful restart
> and it works as I expect.
> Is there something I missed out from the startup process?

Step 1: Parse the config
Step 2: Start managing pre-existing clients
(So client.get() will just give you an empty table during step 1)
Step 3: Profit.

So you might want to replace scratchdrop.restore with a function that gets a
client as its argument and connect this function to the manage signal.

Cheers,
Uli
-- 
"Because I'm in pain," he says. "That's the only way I get your attention."
He picks up the box. "Don't worry, Katniss. It'll pass."
He leaves before I can answer.

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: Window Order Variable

[Uli Schlachter]

Hi,

On 17.05.2014 21:11, Peter Schroeder wrote:
> I am attempting to modify the taskbar to function like screen/tmux. I have
> figured out how to modify the text of the taskbar buttons to include a
> number to the left of it, but I can't figure out what variable or function
> to use to get the order of the windows to get the number. Am I looking for
> something that isn't there? Any help would be appreciated.

There is no generic function currently to get this information. This is mostly
because the tasklist gets a filter function and you can thus influence which
clients are included and which aren't. The order is always the order in which
e.g. client.get() or awful.client.visible() returns the clients.

The default config uses the currenttags filter:

  mytasklist[s] = awful.widget.tasklist(s,
awful.widget.tasklist.filter.currenttags, mytasklist.buttons)

So... uhm... to get a table that maps from integer index to client, we could do
the following (untested, s is the target screen):

local entries = {}
for _, c in ipairs(client.get(s)) do
  if awful.widget.tasklist.filter.currenttags(c, s) then
table.insert(entries, c)
  end
end

If you really, really want to get the index from some client, you could then use
awful.util.table.hasitem(entries, c) (despite the name, it will return the table
key (or nil) and thus will get you the number you want in this case).

Cheers,
Uli
-- 
Bruce Schneier can read and understand Perl programs.

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: wibox binding

[Uli Schlachter]

On 21.04.2014 09:50, david cobac wrote:
> Hi,
> 
> i'm trying to bind mouse wheel with a wibox just like :
> 
>  mywibox:buttons(awful.util.table.join(
>   awful.button({ }, 4, function () naughty.notify({ text="roulette 4" })
> end),
>   awful.button({ }, 5, function () naughty.notify({ text="roulette 5" })
> end)
>  ))
> 
> but it makes awesome freeze...
> Bug or should i use connect_signal or other ?

Bug fixed with commit a90f0c977, but feel free to replace the above with
:buttons() on the widget that your wibox displays.

Uli
-- 
A learning experience is one of those things that say,
'You know that thing you just did? Don't do that.'
 -- Douglas Adams

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: Updating an imagebox image

[Uli Schlachter]

On 17.04.2014 17:55, david cobac wrote:
> Hi,
> i have a png image file which periodically updates.
> 
> I've tried to display it with an imagebox and a timer but there's actually
> no updates in the display, here is a complete minimal (i hope) code :
> 
> function imagew_icon()
>local fic ="/tmp/image.png"
>imagew:set_image(fic)

Try this:

imagew:set_image(gears.surface.load_uncached("/tmp/image.png"))

(And if it complains about having no idea what "gears" is, local gears =
require("gears"))

> end
> imagew = wibox.widget.imagebox()
> imagew_timer = timer({ timeout = 10 })
> imagew_timer:connect_signal("timeout", function () imagew_icon()  end)
> imagew_timer:start()
> imagew_icon()
> 
> thanks for any help !
> 


-- 
“I’m Olaf and I like warm hugs.”

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: Prefix: C-o instead of Mod4?

[Uli Schlachter]

Hi,

On 17.04.2014 10:40, Thorsten Jolitz wrote:
> having used Tmux on the console and Stumpwm with X quite some time now,
> I got used to have the same prefix (C-o) and more or less the same
> keybindings for both WM's, so I don't have think about being on the
> console or in an X session. 
> 
> Now awesome is really awesome and a strong competitor to stumpwm and I
> want to try it. Changing keybindings would be easy, but how to set a
> keychord (Control + o) as prefix instead of single keys that have been
> added to Mod4 is not so obvious (but maybe I missed something obvious
> here).
> 
> Somebody somewhere asked about using C-M- as prefix (Control + Alt), and
> the answer was basically 'you can't'. 

Well, everything is possible.

In this case you would need to write something which catches the C-o key press
and then "activates some mode" by registering your other keybindings or starting
a keygrabber (so that e.g. Esc or some timeout can easily be used to de-activate
this "mode" again).

However, it's not possible in the sense of "AFAIK no one wrote and published
something that would make this easier".

Uli
-- 
A normal person is just someone you don't know well enough yet.
 - Nettie Wiebe

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: widget buttons

[Uli Schlachter]

Hi,

On 16.04.2014 20:54, david cobac wrote:
> Some precisions :
> it seems it finally interacts but not the whole widget...
> Since i have two of these widgets side by side, it appears that sensitive
> area overlaps on the other : it's like the area of the widget is on its
> bottom right and includes a part of the other widget...
> 
> A problem of position of the lgi.cairo surface with the widget itself ?
> 
> 
> 2014-04-16 16:54 GMT+02:00 david cobac :
> 
>> Hi !
>> I've several  widgets defined the same way :
>>
>> mpdtw  = wibox.widget.base.make_widget()
>> mpdtw.fit = function ( mpdtw , width , height )
>>local size = math.min ( width , height )
>>return size, size
>> end
>> mpdtw.draw = function ( mpdtw , wibox , cr , width , height )
>> ...
>> ...
>> end
>>
>> None of them react when i define events like this for example :
>>
>> mpdtw:buttons(awful.util.table.join(
>> awful.button({ }, 1, function () awful.util.spawn( "mpc toggle" ) end),
>> awful.button({ }, 4, function () awful.util.spawn( "mpc seek +2%" ) end),
>>  awful.button({ }, 5, function () awful.util.spawn( "mpc seek -2%" ) end)
>>   ))
>>
>> thanks for any help !
>>
>> awesome v3.5.5 (Kansas City Shuffle)
>>  • Build: Apr 12 2014 19:40:24 for x86_64 by gcc version 4.8.2 (root@antec
>> )
>>  • Compiled against Lua 5.1.5 (running with Lua 5.1)
>>  • D-Bus support: ✘

Attached is a patch describing my change in the default config. I place the
widget so that I can find it even though it doesn't actually draw anything. :-)

With this, everything works fine for me. I also tried clicking at various points
of the widget and all of them reacted fine.

Could it be that "mpc" fails to connect to mpd? You could try using
naughty.notify{text="clicked"} in the callback function to test if mpd or the
click failed.

Cheers,
Uli
-- 
A normal person is just someone you don't know well enough yet.
 - Nettie Wiebe
diff --git a/awesomerc.lua.in b/awesomerc.lua.in
index 2d61b31..a0e9792 100755
--- a/awesomerc.lua.in
+++ b/awesomerc.lua.in
@@ -112,6 +112,20 @@ menubar.utils.terminal = terminal -- Set the terminal for 
applications that requ
 mytextclock = awful.widget.textclock()
 
 -- Create a wibox for each screen and add it
+mpdtw = wibox.widget.base.make_widget()
+function mpdtw:fit(width, height)
+   local s = math.min(width, height)
+   return s, s
+end
+function mpdtw:draw()
+   -- Nothing to do here
+end
+mpdtw:buttons(awful.util.table.join(
+awful.button({ }, 1, function () print("a") end),
+awful.button({ }, 4, function () print("b") end),
+awful.button({ }, 5, function () print("c") end)
+  ))
+
 mywibox = {}
 mypromptbox = {}
 mylayoutbox = {}
@@ -184,6 +198,7 @@ for s = 1, screen.count() do
 -- Widgets that are aligned to the left
 local left_layout = wibox.layout.fixed.horizontal()
 left_layout:add(mylauncher)
+left_layout:add(mpdtw)
 left_layout:add(mytaglist[s])
 left_layout:add(mypromptbox[s])
 

Re: [ANNOUNCE] awesome 3.5.5 relased

[Uli Schlachter]

On 11.04.2014 20:36, Harvey wrote:
> Umm anyway you can get the fix for awful.util icon searching into here
> somewhere (see old post)

Uhm, fix?

> What is the official channel for submitting a patch on this?

Either sending the result of "git format-patch origin/master.." to the awesome
devel mailing list or submitting pull requests on github.

> H

Uli

> On 04/11/2014 05:20 AM, Uli Schlachter wrote:
>> Guys,
>>
>> could you please stop reporting bugs *after* a new release?
>>
>> Uli
>>
> 
> 
> 


-- 
"Are you preparing for another war, Plutarch?" I ask.
"Oh, not now. Now we're in that sweet period where everyone agrees that our
recent horrors should never be repeated," he says. "But collective thinking is
usually short-lived. We're fickle, stupid beings with poor memories and a great
gift for self-destruction.

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

[ANNOUNCE] awesome 3.5.5 relased

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Guys,

could you please stop reporting bugs *after* a new release?

Uli
- -- 

awesome version 3.5.5 has been released. It is available from:

tar.xz: http://awesome.naquadah.org/download/awesome-3.5.5.tar.xz
md5: 48a00b747f0279e6164d8b7e9c964346
sha1: 7701fc6810b0a5b9ce9ba140d55ea55b9e59607f

tar.bz2: http://awesome.naquadah.org/download/awesome-3.5.5.tar.bz2
md5: efba12d9fef5b663a104e19161e2bea4
sha1: 0c8e0c431ea40a14b5394cac269efedd558d3d1f

number of changes
- -
10

number of commiters
- ---
3

shortlog
- 
Uli Schlachter (7):
  imagebox: Don't try to scale by infinite (FS#1248)
  gears.color: Handle nil arguments correctly again
  naughty: Don't use the cache when loading icons (FS#1253)
  gears.surface: Handle the cache more intelligently
  awful.tag.move: Fix tag index setting
  awful.tag.setscreen: Check if old_screen == new_screen
  change codename again

Emmanuel Lepage Vallee (2):
  Move 'surface_size' to gears.surface and make it public
  Make sure gears.color.create_png_pattern are being repeated

Tin Benjamin Matuka (1):
  Allow reversing the icon order in systray


diffstat
- 
 awesomeConfig.cmake  |  2 +-
 lib/awful/tag.lua.in |  6 +++---
 lib/gears/color.lua.in   |  7 +--
 lib/gears/surface.lua.in | 26 --
 lib/gears/wallpaper.lua.in   | 15 +++
 lib/naughty.lua.in   |  2 +-
 lib/wibox/widget/imagebox.lua.in |  1 +
 lib/wibox/widget/systray.lua.in  | 10 --
 systray.c| 15 ---
 9 files changed, 54 insertions(+), 30 deletions(-)
- -- 
A normal person is just someone you don't know well enough yet.
 - Nettie Wiebe
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJTR7PEAAoJECLkKOvLj8sGVy8IAKjy5yFytvIfYfvajKRON3y/
zOw/624c25RU9vZpzEoll3Scv2w6/iRuOaxcu3u3rkDG0HVB4qrz/vIxSP6AeiRn
thdYI3ZPBZMYkkrw/mHUXsLyQIIcEtjLDAPLEoY5m0F0KmO8fzXwclI5o3RUgAI4
kiMaRsuYezERsMLf3AK7zX1YpZourSXFD83ssmGPmTzH3/bi3JqPGYeZx8sNnVcO
4NbY9Eh1i49pwzHpDkPvIW7gQg947PKawK7Q3wTnupdEAiXMx7P8bqzof+IetVX/
5VkveH5krK4H2U2obcMNoZ8Pg5uGI5p0Yhkd3o32VrBpC+H+/S6GK9F31zvP320=
=XpOu
-END PGP SIGNATURE-

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: create client and hold it in variable

[Uli Schlachter]

On 03.04.2014 17:40, Manuel Kasser wrote:
> Am 03.04.2014 07:50, schrieb Uli Schlachter:
[...]
>> [awesome awesome-code]
>> Why is this better than just finding the new urxvt by pid in the manage
>> hook? Dunno. It just gets more browny points for using some fancy API...
> I assume this set xproperty persists as long as the X-Server is up and
> running (aka over restarts of awesome)? That would solve another issue,
> tracking this urxvt over restarts of awesome (shall be spawned once, but
> not again when I restart awesome as it still fullfills its purpose).

The xproperty survives. However, the string is randomly-generated and gets
returned from awful.util.spawn(), so you cannot set it and thus...

> If so, the xproperty-String can be chosen as I see it fit, right?

Nope.

However, how about this:

-- Only needed once:
awesome.register_xproperty("_NET_STARTUP_ID", "string")
awesome.register_xproperty("AWESOME_IMPORTANT_URXVT_STARTUP_ID", "string")

function find_or_start_urxvt()
  -- First try to find it
  local startup_id = awesome.get_xproperty("AWESOME_IMPORTANT_URXVT_STARTUP_ID")
  if startup_id ~= "" then
local c = awful.util.table.iterate(client.get(), function(c)
  return c.startup_id == startup_id
end)
if c then
  return c
end
-- Add a return here if you don't want to start a new instance if one was
-- already started
  end
  -- Couldn't find it (doesn't run yet, still starting up or exited), start it
  local clpid, startup_id = awful.util.spawn('urxvt', true)
  awesome.set_xproperty("AWESOME_IMPORTANT_URXVT_STARTUP_ID", startup_id)
  return nil
end)

This one should survive restarts because it saves the startup id of the
interesting urxvt instance in a property on the root window.

Uli
-- 
- He made himself, me nothing, you nothing out of the dust
- Er machte sich mir nichts, dir nichts aus dem Staub

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: create client and hold it in variable

[Uli Schlachter]

Hi,

On 02.04.2014 23:08, Manuel Kasser wrote:

I want to create/spawn a new client (a new urxvt) and hold it/catch it
in a variable to do some stuff with it afterwards.

The way I am doing this now is by spawning, catching the pid and then
find the client with this pid:


clpid = awful.util.spawn('urxvt')
wait(1) -- waits 1 second
for c in awful.client.iterate(function(c) return

awful.rules.match(c, { pid = clpid }) end) do

persistent_c = c
end


Is it possible to spawn and catch a client in one step (or at least not
bringing out the artillery by spawning a client, throwing it away and
then get it back from the bunch of clients)?


You aren't spawning a client and throwing it away. You are spawning a *process*. 
That process later happens to open a new window and thus we get a client, but 
not all processes open one window.


Something like the following, untested code might make it easier to find the new 
process (beware, memleak for everything which doesn't support 
StartupNotification. Luckily urxvt seems to support it, needs awesome 3.5.3 or 
better):


-- Only needed once:
awesome.register_xproperty("_NET_STARTUP_ID", "string")

local clpid, startup_id = awful.util.spawn('urxvt', true)
client.connect_signal("manage", function(c)
  if c:get_xproperty("_NET_STARTUP_ID") == startup_id then
persistent_c = c
  end
end)

Why is this better than just finding the new urxvt by pid in the manage hook? 
Dunno. It just gets more browny points for using some fancy API...


Uli

--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

[ANNOUNCE] awesome 3.5.4 relased

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi everyone,

it's been a long time already and here it finally is!

Uli
- -- 
awesome version 3.5.4 has been released. It is available from:

tar.xz: http://awesome.naquadah.org/download/awesome-3.5.4.tar.xz
md5: 9d52a26bfbc142ace5427bfb55010359
sha1: 27f9c5901ff28c401f707bad938ff2171f355af3

tar.bz2: http://awesome.naquadah.org/download/awesome-3.5.4.tar.bz2
md5: d5177d66b1011d9d98d3aa805ace2dc1
sha1: 4e882816d5dfd64f5a3e5a7ee181078e377c04da

number of changes
- -
8

number of commiters
- ---
1

shortlog
- ----
Uli Schlachter (8):
  gears.surface: Cache files from disk
  gears.color: Add a pattern cache
  awful.tooltip: Small reorganization
  awful.tooltip: Add (and use) :set_markup() function
  systray: Don't set WM_STATE on embedded windows (FS#1246)
  Revert "root: Make sure cairo doesn't cache our temporary connection" 
(FS#1245)
  wibox.drawable: Assert that no cairo error occurred
  change codename


diffstat
- 
 awesomeConfig.cmake   |  2 +-
 lib/awful/tooltip.lua.in  | 37 +
 lib/gears/color.lua.in| 15 ---
 lib/gears/surface.lua.in  | 17 -
 lib/wibox/drawable.lua.in |  3 +++
 root.c|  5 -
 systray.c |  1 -
 7 files changed, 53 insertions(+), 27 deletions(-)
- -- 
- - Buck, when, exactly, did you lose your mind?
- - Three months ago. I woke up one morning married to a pineapple.
  An ugly pineapple... But I loved her.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJTO8X8AAoJECLkKOvLj8sG9iMH/0qxXxDjKHNf/l4JGT9quzCT
upA9YKohpU2e+7Tlk0KcQMBGDveVhbb6q0WmIEv0UuO3X9diQfRxJ0+nYnejXQ1L
GdSAWSvBLEJ+XM/84Xultcl4s6L12Y8y7a5AZYLS4fKPZZ8BUVAw00TqPJ6SNgvN
4GvpKIOWd+gQ2EmmN7Ok731Ov97O8N3qbU+JZIgXLxzzlckKmgR0WRsrjQT9PRUt
MQF6bE0aWMUugwHGWk6t2bWqdWAXTD7wqjxh8gCokNHrxLtML7EZDHiMvVod84lV
iB/UsxUZq4ddGwzV7sbFOVAiTLmX7K29trPh7cmiZnT8zYhSBUq1/ltOpPjKnh0=
=gSGO
-END PGP SIGNATURE-

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: Delayed autoraise

[Uli Schlachter]

Hi,

On 31.03.2014 11:06, Eugen Dedu wrote:
> I have been using awesome since a few months now, but there is one thing 
> I really miss: sloppy focus with autoraise after some delay.
> 
> I modified rc.lua from
> client.connect_signal("focus", function(c) c.border_color = 
> beautiful.border_focus end)
> to
> client.connect_signal("focus", function(c) c.border_color = 
> beautiful.border_focus ; c:raise() end)
[...]
> How to achieve this autoraising after some delay?  In other WM it is 
> possible to set a delay before autoraising, for ex. 500 ms.

Untested:

autoraise_target = nil
autoraise_timer = timer { timeout = 0.5 }
autoraise_timer:connect_signal("timeout", function()
  if autoraise_target then autoraise_target:raise() end
  autoraise_timer:stop()
end)
client.connect_signal("mouse::enter", function(c)
  autoraise_target = c
  autoraise_timer:again()
end)
client.connect_signal("mouse::leave", function(c)
  if autoraise_target == c then autoraise_target = nil end
end)

Uli
-- 
A learning experience is one of those things that say,
'You know that thing you just did? Don't do that.'
 -- Douglas Adams

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: lgi and awesome-3.5.2 - cpu usage - A dead horse?

[Uli Schlachter]

Hi,

On 31.03.2014 04:06, Harvey wrote:
> I'm still a little confused as to why the move to lgi was considered to
> be necessary at all.
[...]

I never liked some of the hacks that the widget layout code needed to do. It got
some nested tables containing widgets as arguments and had to return a flat
table whose indices was matched with the widgets via a depth first search
through the widgets table.

Do you remember having to use ".widget" to make progressbars and graphs (and
other things?) behave? Without that, they would ignore the layout and always be
put at the left side of the wibox.

I think originally the move to some lua-cairo-bindings started with "Make or
image API more powerful by using cairo bindings":

https://awesome.naquadah.org/bugs/index.php?do=details&task_id=757

(Oh and of course the new widget system existed and is in git since 2010, but no
one ever complained until v3.5 aka december 2012 aka two years later :-/ )

> I presume all of these X11 round trip calls and blocking issues existed
> in 3.4 branch for some time, but what does 3.4 do / utilize that is so
> much more efficient that lgi does not? Is it truely impossible to retain
> the new layout functionality and revive, if not in part some older 3.4
> components?
[...]

In 3.4, the C API implemented three widgets. There were textboxes, imageboxes
and the systray. Nothing else. Some lua code was called when necessary with the
widgets table and the available size as arguments and it calculated the position
and size of each widget.

There was the image API. This allowed to create images, draw (axis-aligned?)
lines and fill rectangles. Really powerful stuff... Not.

The C code then used all this information to do the actual drawing with cairo
and pango from C. So there was a really low overhead per call for the actual
drawing.

With 3.5, the C code just exposes a cairo surface to lua and all the drawing is
done in lua. Everything else is done in lua. So, for example, the progressbar
and graph widgets are now less of a hack.

AFAIK the higher cpu usage comes from a much higher per-call overhead for each
cairo and pango function that is called. But there are likely also some things
were we do more work than strictly necessary.

Cheers,
Uli

P.S.: During a blocking round trip (or sleeping for other reasons), a process
doesn't use the CPU. So this doesn't contribute to any CPU usage.

P.P.S.: I wonder how oocairo compares to lgi, performance-wise...
-- 
"In the beginning the Universe was created. This has made a lot of
 people very angry and has been widely regarded as a bad move."

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: [ANNOUNCE] awesome 3.5.3 released

[Uli Schlachter]

Hi,

On 30.03.2014 12:24, Quan Guo wrote:
> Congratulations! I'm wondering how I can get the newest codes from
> git.naquadah.org, if possible.
> 
> I tried to pull the newest master branch. But I still get awesome 3.5.2?
> Any ideas? 
[...]

There is a 3.5 branch and a master branch (and lots of other branches) in git.
Their merge-base (latest common commit) is v3.5.2-48-gc855b1b. So for the master
branch, the newest tag that git can find is the v3.5.2 tag, because the v3.5.3
tag is only reachable from the 3.5 branch.

Also, you don't get awesome 3.5.2, but you get awesome v3.5.2-119-gb9361d5. The
"119" in there means that there were 119 commits since the v3.5.2 tag and thus
lots of changes.

So... yeah... that version number is just an artifact that happened due to me
branching of 3.5 "suddenly".

Everything is ok. Move along. ;-)
Uli
-- 
A learning experience is one of those things that say,
'You know that thing you just did? Don't do that.'
 -- Douglas Adams

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

[ANNOUNCE] awesome 3.5.3 released

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey everyone,

due to "just because", here is a new release for you to enjoy. Now with three
times as many commits as 3.5.2 had to its predecessor!

So what changed? Take a look at the git history.

- - Lots of small fixes...
- - Full SHAPE support in the C code...
- - More fixes...
- - The new xproperty API which we have thanks to Elv1313 which allows 
accessing X11
  properties from Lua which can be used e.g. to save information across a 
restart...
- - Some fixes for excessive redraws (and black flickering)...

If you have a problem with clients not being raised when they appear, see
http://git.naquadah.org/?p=awesome.git;a=commitdiff;h=de46670c8ce339e7ddfaf5651e455d9d4c203536

In case you maintain a distro package for awesome:
Our minimum LGI dependency is 0.7.0 to avoid a LGI bug

Enjoy!
Uli

P.S.: A big "thanks!" to Daniel Hahler and Elv1313 for lots of great work!

P.P.S.: If the person who helped me with the release name reads this, say so.
You know that I mean you.

- -- 

awesome version 3.5.3 has been released. It is available from:

tar.xz: http://awesome.naquadah.org/download/awesome-3.5.3.tar.xz
md5: 730a5852cc61f5561588a1b788ec861e
sha1: 9ac67fd470215c04016eaa93f8b9e6a1cc360754

tar.bz2: http://awesome.naquadah.org/download/awesome-3.5.3.tar.bz2
md5: 2dbe0edf536048b3b89f2f9060311851
sha1: 53526451853d9ca04a45240a711c363ad2a09747

number of changes
- -
99

number of commiters
- ---
11

shortlog
- ----
Uli Schlachter (71):
  luadoc: Document screen outputs
  Print libxcb error codes for broken connections
  tasklist: Add default colors for broken themes
  Really ignore loops in transient_for (FS#1124)
  awful.tag.delete: Deactivate tags
  awful.menu: Add missing "local" declaration
  menubar: Fix API docs
  awful.tag.viewmore: Make screen optional (FS#1203)
  Finish C-side support for window shapes (FS#1051)
  awful.menu.clients: Fix API (FS#1200)
  naughty: fix ldoc
  Add awesome.composite_manager_running
  wibox.drawable: Cache the wallpaper
  client: Add c.blob property
  Improve the check for another window manager
  Update the luadoc for the C API
  client: Add request::activate signal (FS#848)
  awful.ewmh: Correctly handle bw change for maximized clients
  client: Emit property::screen after geometry
  awful.ewmh: Enforce client geometry (FS#764,FS#1216)
  root.wallpaper: Cleanup and correctness fixes
  Revert "awful.ewmh: Enforce client geometry (FS#764,FS#1216)"
  mouse.screen: Lie when we have no clue where the pointer is
  Measure the time a main loop iteration takes
  Update fields for capi.awesome in C comment
  Improve fatal signal handling
  awful.util.spawn*: Remove obsolete screen argument
  Make objects properly inherit signals from classes
  Add awesome.register_xproperty (FS#1212)
  Revert "client: Add c.blob property"
  Fix handling of _NET_CURRENT_DESKTOP messages (FS#1219,FS#1217)
  xproperty: Don't limit property lengths
  spawn: Don't try to spawn with empty argv (FS#1225)
  awesome.spawn(): Check table arguments better
  spawn: Remove useless argv[0] calculation
  drawin: Inline drawin_init() into its only caller
  drawin: Don't unconditionally redraw when made visible
  awful.tooltip: Work with all gears.colors as foreground
  drawin: Only redraw on move with translucent background
  Redraw titlebars more intelligently
  Fix cairo surface memory leak
  drawable: Add pixmap member
  root: Make sure cairo doesn't cache our temporary connection
  Add awesome.startup
  awful.client.movetoscreen: Don't untag clients completely (FS#1196)
  ewmh: Factor out common code into a helper function
  EWMH: Ignore invalid _NET_WM_DESKTOP
  ewmh: Use client_set_sticky() for making clients sticky
  EWMH: Handle _NET_WM_DESKTOP in lua
  Drawable: Ignore exposes when we have nothing to draw
  Fixup indentation
  Bump minimum lgi dependency to 0.7.0
  awful.rules: Emit request::activate on the client
  luaa: Remove lots of unused code
  awful.client: Add marked and unmarked signals (FS#1227)
  imagebox: Avoid division by zero
  wibox.layout.base.fit_widget: Enforce sane width and height
  window: Factor out helper functions for xproperties
  awesome: Add get_* and set_xproperty
  xproperty: Emit on "awesome" for root window properties
  rc.lua: Raise all clients by default (regression, FS#1234)
  Make debug::index::miss and newindex work on classes and all objects
  awesome.startup_errors: Never emit debug::index::miss
  beautiful: Don't use non-existant API
  gears.color.create_opaque_pattern: Fix for SurfacePatterns (FS#1236)
  drawin: Correct

Re: change DPI

[Uli Schlachter]

Hey,

On 22.03.2014 11:30, Dan Milon wrote:
> I installed archlinux & awesome on a macbook pro with a retina
> display. As you can imagine everything was super tiny. I added "Xft.dpi
> = 196" to xrdb and now gtk, qt etc apps display normally, but the awesome
> status bar still shows tiny.
> 
> It seems that awesome itself is unaffected by "Xft.dpi".
> Do you have any idea what I could do to fix this?

No idea if this actually works, but (if you are using 3.5, which I think you
are), you could try adding the following to the *beginning* (beginning is the
very first line of your config, not later) of your rc.lua:

  require("lgi").PangoCairo.font_map_get_default():set_resolution(196)

Please tell me if this has any effect.

Uli


P.S.: For future-Uli: Google knows about gdk_screen_get_resolution() and Debian
code search figured out that this function is used in a call to
pango_cairo_context_set_resolution() inside gtk_widget_update_pango_context().

P.P.S.: It would be nice to figure out if lgi let's us use
gdk_screen_get_resolution() and gdk_screen_get_font_options() so that they can
be used in wibox.widget.textbox. No idea how yet, but if we figure out a way to
map gdk screens to awesome screens, that could be used for implementing this
"properly". Or we just link awesome against Gdk and use this code properly and
get rid of awesome's screens, but that might result in a fight about who owns
the X11 connection...
-- 
Who needs a ~/.signature anyway?

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: Setting custom X properties for clients to preserve tags between awesome restarts

[Uli Schlachter]

On 23.02.2014 20:14, Elv1313 . wrote:
> Good points, but what about allowing a few types (number, string, boolean)
> to be read using methods like client:read_xprop_number("NAME") and allowing
> awesome to create/write new ones ones only in the AWESOME_NAQUADAH
> namespace? like client:write_xprop_number("COUNT",1000) ->
> AWESOME_NAQUADAH_COUNT ?

Not really symmetric. When I write something out with
:write_xprop_number("COUNT", 1000), I would need to know awesome's magic prefix
for reading it again. But I do like the underlying idea a lot.

So some thoughts about this:

We can just drop the "_number" from the method name. The C API can work with
number/strings/boolean in the same function and lua will have to be able to do
the same (after all, there is type()). That gets down the number of functions
needed by a factor of 3.

Then we likely also need some signals for this, so that things can know when
some property changed. However, this isn't really possible right now, because we
have to add signals before they can be used and this new API would allow quite
arbitrary signals. (Oh and the C code for implementing classes doesn't really
like dynamically added functions either)

So... uhm... require lua to register which properties it wants to use, like we
have add_signal() and connect_signal() right now? When such a property is
registered, its type could also be given.

That should make it possible to also add signals for all of this.

The final API could be something like this (I do not like the naming at all and
I still hope that someone can come up with better names for this):

-- ugly hack to read .name
-- Possible types are "string", "boolean" and "number", mapping to UTF8_STRING,
AWESOME_NAQUADAH_BOOLEAN and CARDINAL (hm... only UTF8_STRING really fits. There
are no boolean properties so far in X11 and CARDINAL is a non-negative integer
while lua's numbers are floating points... Do we really want more than just
strings?)
client.add_xproperty("_NET_WM_NAME", "string")
c:connect_signal("xproperty::_NET_WM_NAME", function() print("Oh?") end)
client.set_xproperty(c, "_NET_WM_NAME", "WMs must not set _NET_WM_NAME")
print(client.get_xproperty(c, "_NET_WM_NAME"))

> This feel like evil magic, and it is, but so is adding a single BLOB
> property. The use case your patch try to allow cannot be fixed using a
> single BLOB. I understand X11 is fragile, but do we really have a choice
> here?

Hm, yeah...

> On 23 February 2014 13:59, Uli Schlachter  wrote:
[...]

Cheers,
Uli

who is just thinking out loud right now
-- 
Happiness can't be found -- it finds you.
 - Majic

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: Setting custom X properties for clients to preserve tags between awesome restarts

[Uli Schlachter]

On 23.02.2014 19:15, Elv1313 . wrote:
[...]
> But would it be better to simply be able to access random xprops from lua
> rather than having to patch awesome everytime we want a new one?
[...]

The problem with accessing random X11 properties is that most random properties
have random formats. I can make UTF8_STRING and CARDINAL work properly, I can
pretend that STRING is UTF8_STRING, I can turn ATOMs into atom names and I can
pretend that WINDOW and PIXMAP really are just integers (client.window and
drawin.window already pretend the same).

This might help with many properties, but I fear that this will be a downhill
slope and eventually people will want access to more and more X11 properties.

Also, reading is way less harmful than writing a property. Lua would have to
specify a type here, too (or the alternative would again be a big hardcoded list
of types in C). And now configs would be able to set all kind of broken things.

Finally, this breaks all the (weak) abstractions that we have. The Lua API that
awesome provides isn't meant to be a Lua X11 protocol binding...

Uli
-- 
“Some people are worth melting for.” - Olaf

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: Setting custom X properties for clients to preserve tags between awesome restarts

[Uli Schlachter]

Hi,

On 05.12.2013 22:16, Uli Schlachter wrote:
> On 03.12.2013 11:06, Stanislav Ochotnicky wrote:
>> Quoting Uli Schlachter (2013-12-03 08:54:22)
>>> On 02.12.2013 23:39, Stanislav Ochotnicky wrote:
>>>> Quoting Uli Schlachter (2013-12-02 22:57:58)
>>> [...]
>>>>> I hope this clears up the current state. Feel free to come up with 
>>>>> suggestions
>>>>> on how to improve this.
>>>>
>>>> Thanks for quick reply. I don't think it makes sense to complicate core 
>>>> awesome
>>>> codebase by introducing custom X property. It *would* be nice if 
>>>> completely full
>>>> dynamic tagging would be easily possible but that's not really a 
>>>> discussion for
>>>> this thread :-)
>>>
>>> I just thought about adding a "blob" property which contains just a random
>>> string that is completely uninterpreted by awesome, but could be accessed by
>>> lua. This blob would however need a better name than just "blob", of course.
>>>
>>> This isn't much work on the C side and shifts the problem into lua-land 
>>> (aka "no
>>> longer my problem" ;-) ).
>>>
>>>
>>> If it were called "blob", I would save it in "AWESOME_BLOB" and have it
>>> accessible as c.blob. There are some obvious problems like "who controls the
>>> blob" where different modules both would want to save stuff in there. If 
>>> this
>>> should be solved, then "blob" would not only need a way better name, but 
>>> would
>>> also need to be a table. And I would have to think about how to serialize a 
>>> lua
>>> table into an X11 property...
>>
>> I am not sure about maximum size of X11 property but I can imagine few use 
>> cases
>> (mostly around preserving state between restarts, saving, restoring, maybe
>> profiles?)
> 
> Good question. The only thing I found in the docs:
> 
> "The maximum size of a property is server-dependent and may vary dynamically."
> 
> Anyway, attached is a patch which implements a "blob" property on clients. 
> This
> is a string that survives restarts. Of course, this needs some helper 
> functions
> in awful so that more than one thing can be saved in here. No idea about the
> format for this and too lazy to think about it.
> 
> So this patch is just a proof of concept that people can experiment with. 
> Also,
> I still don't like the name "blob".
> 
> [...]
>>> What do you guys think?
>>
>> I'd welcome uncle blob with open arms. I believe a nice Lua access API will 
>> be
>> needed but that's a separate point...
> 
> Looking forward to someone implementing this. :-)

Just pushed a commit to git which adds the c.blob property. Not much changed,
except that the X11 property is now called AWESOME_NAQUADAH_BLOB to have less
changes of name collisions.

Still looking forward to someone implementing some nice lua API on top of this.

Cheers,
Uli

P.S.: All code that messes with c.blob directly will be shot. We really need
some nice lua API for this that avoids collisions and is nicer than "just a 
string"!
-- 
"In the beginning the Universe was created. This has made a lot of
 people very angry and has been widely regarded as a bad move."

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: movetoscreen - still not having much luck...

[Uli Schlachter]

Hi,

On 23.02.2014 09:13, David Sorkovsky wrote:
[...]
> Dual monitors both working well with Awesome - like the independence, but 
> sometimes I use the RHS for my laptop and want to move apps to the LHS at 
> that time.
> 
> Wondering if there is something I needed to setup in Awesome?
> 
> 
> xrandr on LHS...
> 
> Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
> VGA1 disconnected (normal left inverted right x axis y axis)
> HDMI1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 
> 531mm x 299mm
>1920x1080  60.0*+
>1680x1050  60.0  
>1600x900   60.0  
>1280x1024  75.0 60.0  
>1280x960   60.0  
>1280x800   59.8  
>1152x864   75.0  
>1280x720   60.0  
>1024x768   75.1 60.0  
>1024x576   60.0  
>832x62474.6  
>800x60075.0 60.3  
>640x48075.0 60.0  
>720x40070.1  
> DP1 disconnected (normal left inverted right x axis y axis)
> HDMI2 disconnected (normal left inverted right x axis y axis)
> DP2 disconnected (normal left inverted right x axis y axis)
> 
> 
> Xrandr on RHS...
> 
> Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
> VGA1 disconnected (normal left inverted right x axis y axis)
> HDMI1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 
> 531mm x 299mm
>1920x1080  60.0*+
>1680x1050  60.0  
>1600x900   60.0  
>1280x1024  75.0 60.0  
>1280x960   60.0  
>1280x800   59.8  
>1152x864   75.0  
>1280x720   60.0  
>1024x768   75.1 60.0  
>1024x576   60.0  
>832x62474.6  
>800x60075.0 60.3  
>640x48075.0 60.0  
>720x40070.1  
> DP1 disconnected (normal left inverted right x axis y axis)
> HDMI2 disconnected (normal left inverted right x axis y axis)
> DP2 disconnected (normal left inverted right x axis y axis)

Welcome to 1987. You have two different protocol screens. They are completely
independent. They only share the keyboard and the mouse. That's it.

This does especially mean that you cannot move windows between screens. (This is
a limitation of X11!)

People were unhappy and Xinerama was invented and included in X11R6v4.0. This
makes multiple screens "look" to the X11 protocol like a single, big one. Since
from the protocol's point of view there is now just a single screen, windows can
now move around freely.

(At least I think that this is what's going on, since you are giving us two
times the same xrandr output and claim that it is for the different screens...)

> Xorg.conf...
> 
> # Manually adjusted/combined from the below...
> # X.org Configured
> # nvidia-xconfig: X configuration file generated by nvidia-xconfig # 
> nvidia-xconfig:  version 304.116
> (buildmeister@swio-display-x86-rhel47-01)  Mon Oct 28 21:46:08 PDT 2013
> 
> Section "ServerLayout"
>   Identifier "Layout"
>   Screen  0  "Screen0" 0 0
>   Screen  1  "Screen2" RightOf "Screen0"

Yeah, zaphod mode, not Xinerama.

>   InputDevice"Mouse0" "CorePointer"
>   InputDevice"Keyboard0" "CoreKeyboard"
> EndSection
[...]

Cheers,
Uli
-- 
 I think someone had a Xprint version of glxgears at one point,
but benchmarking how many GL pages you can print per second
was deemed too silly to merge

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: concerning titlebars

[Uli Schlachter]

On 21.02.2014 23:52, Manuel Kasser wrote:
> Hi,
> 
> I'm a little confused with a detail in the titlebar-implementation in
> awesome.
> I took the titlebar-code from the reference-rc.lua.
> Now I want to work on titlebar-stuff and noticed that the titlebar is
> set by setting the widget of the wibox "titlebar"/awful.titlebar(c).
> However, there is no awful.titlebar.show(c) in there, so is
> titlebar.show() an implicit effect of
> awful.titlebar(c):set_widget(layout) or do I lack overview over my
> configuration?

awful.titlebar(c, args) has two arguments. The first one is the client, the
second a list of options to apply to the titlebar. The function then returns the
drawable for that titlebar.

If no args are given, some default values are used. For the titlebar's height,
this is 1.5 times the height of the default font. So calling awful.titlebar()
without any arguments gives the titlebar a non-zero size.

This is in contrast to the default titlebar size of 0 that is used in the C code
and which effectively removes the titlebar.


Because this is indeed a bit confusing, awesome 3.5.2 added the functions
awful.titlebar.show(c, position), .hide and .toggle.

Cheers,
Uli

P.S.: And I just noticed that you will run into lua errors if you try to show a
non-existent titlebar...
-- 
 I think someone had a Xprint version of glxgears at one point,
but benchmarking how many GL pages you can print per second
was deemed too silly to merge

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: Behavior on SIGTERM

[Uli Schlachter]

Hi again,

On 19.02.2014 22:18, Manuel Kasser wrote:
[...]
> And if X dies ealier: if that means all graphical processes get
> SIGTERMed, it shouldn't be a problem anyways, even if they didn't
> receive the SIGTERM originally intended for them by the shutdown
> procedure but another one, should it?
> 
> This means: race or not, doesn't matter, does it?
[...]

When the X server exits, all that processes see is that their connection to the
X server is closed. This is an "end of file" condition on a unix socket. There
is no signal involved here. So this is a completely separate failure case.

Good night,
Uli
-- 
Sent from my Game Boy.

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: Behavior on SIGTERM

[Uli Schlachter]

Hi,

On 19.02.2014 21:45, Manuel Kasser wrote:
> I was wondering whether awesome behaves correctly on receiving SIGTERM,
> i. e. doing (more or less) awesome.quit(). I'm not sure how to check
> that myself.

>From awesome.c (all code can be found in the released tarballs or on
git.naquadah.org):

/* register function for signals */
g_unix_signal_add(SIGINT, exit_on_signal, NULL);
g_unix_signal_add(SIGTERM, exit_on_signal, NULL);
g_unix_signal_add(SIGHUP, restart_on_signal, NULL);

So awesome handles SIGINT, SIGTERM and SIGHUP. Let's look at the function
exit_on_signal():

static gboolean
exit_on_signal(gpointer data)
{
g_main_loop_quit(globalconf.loop);
return TRUE;
}

Now we can compare this to the implementation of awesome.quit():

static int
luaA_quit(lua_State *L)
{
g_main_loop_quit(globalconf.loop);
return 0;
}

Looks similar enough to me.

(Small side note to the interested reader: g_main_loop_quit() doesn't do
anything if the main loop isn't running yet. This is why awesome.quit() doesn't
work while awesome is starting up. So if you want to confuse people, append
"awesome.quit()" to the end of your rc.lua...)

> I'm asking that because I know from personal experience that there is
> software out there, that shuts down on SIGTERM, but interprets that as a
> crash. *cough* firefox *cough*

Uhm, ok... Why are you SIGTERM'ing your session anyway?

> I was wondering whether shutting down a system with running awesome is
> issuefree by using the system's ability to send SIGTERMs on shutdown.

Well, awesome itself has no permanent state. So even if you kill'd awesome,
nothing bad could happen (I guess...). However, if you SIGTERM all running
processes and expect everything to shut down cleanly, you got a race.

The order in which SIGTERMs are delivered is undefined (AFAIK) and it could
happen that the X server exits before e.g. firefox had the time to react to the
signal. So before firefox gets the signal that tells it to shut down, it sees
that the X server died. Most programs (actually gdk, I think) handle this by
just killing the process. I guess this means "interpret as a crash"...

Cheers,
Uli
-- 
Sent from my Game Boy.

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: New windows to parent tag/workspace

[Uli Schlachter]

Hi,

On 28.01.2014 17:57, wu, sa wrote:
> Is it possible to force windows spawned by
> programs/processes/scripts, to stick to its parents workspace/tag?

What exactly do you mean by programs/processes/scripts? Script sounds like a
shell script to me and shell scripts don't really have a tag.

> I have some programs/scripts, which run for a while and at some point
> spawn (and sometimes keep spawning)  windows..., e.g.
> plotting/rendering stuff that just takes time.
> 
> Normally, these new windows just appear on the tag I currently work on,
> which is really annoying...
> 
> As far as I have experienced, the download dialogs of the chromium
> browser already do what I want: automatically stick to the tag, where
> chromium is running, regardless of where my focus currently resides.

If you want me to guess: Chromium's download dialog have the WM_TRANSIENT_FOR
property set and pointing to chromium's main window. This tells awesome that the
dialog belongs to chromium and the following code from awful.tag then does just
what you want:

capi.client.connect_signal("manage", function(c, startup)
-- If we are not managing this application at startup,
-- move it to the screen where the mouse is.
-- We only do it for "normal" windows (i.e. no dock, etc).
if not startup and c.type ~= "desktop" and c.type ~= "dock" then
if c.transient_for then
c.screen = c.transient_for.screen
if not c.sticky then
c:tags(c.transient_for:tags())
end
[snip]

(If a new client has transient_for set, move it to the screen and tag of its
transient_for)

> Is there some way to configure awesome to do this for every new window?

Nope, because awesome always does this. However, it seems like whatever
programs/processes/scripts you are using don't set the WM_TRANSIENT_FOR
property. If this is the case:
How would awesome know that the clients belong together?

> And no, I don't want to force all windows of one particular program to
> one predetermined tag.
> 
> Thank you all and Best regards from Bonn,
> Sa.

Cheers from Oldenburg,
Uli

-- 
 I think someone had a Xprint version of glxgears at one point,
but benchmarking how many GL pages you can print per second
was deemed too silly to merge

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: How to delete wiboxes

[Uli Schlachter]

Hi,

On 01.01.2014 19:42, Csaba Dunai wrote:
> Uli Schlachter  znc.in> writes:
[...]
> Thanks for the quick reply. Unfortunately my problem is still not solved. My
> point is not only to make the wibox disappear but also to free up the memory
> it occupies.
> 
> I have run the following test:
> 
> 1) run awesome as is: used ~1% of my RAM
> 
> 2) run awesome and make 1 wiboxes: used ~8% of my ram
> 
> [CODE]
> 
> listOfWiboxes = {}
> for i = 1,1 do
>   listOfWiboxboxes[i] = wibox({})
> end
> 
> [END CODE]
> 
> 3) run awesome, make 1 wiboxes and then remove them: used ~8% of my ram.
> 
> [CODE]
> 
> listOfWiboxes = {}
> for i = 1,1 do
>   listOfWiboxes[i] = wibox({})
> 
>   listOfWiboxes[i].visible = false
>   listOfWiboxes[i] = nil  -- (I've also tried by leaving this line away)
> end
> 
> [END CODE]
> 
> As you can see setting the visible field to false isn't enough to free the
> memory. Is there a way to solve this issue?
> 
> Thanks again for your effort.
> 
> Best Regards

I did my own experiments. Instead of looking at memory usage in top, I asked
lua's collectgarbage() function for an estimation of the memory used. This
should result in more exact numbers.

Also, since the wibox was never visible, the ".visible = false" isn't necessary.
Sorry for suggesting it.

TL;DR: Seems to work fine here.

Due to the redraw optimizations (wiboxes are redrawn only some time after
something notices they need a redraw), wiboxes cannot be garbage collected while
a redraw is pending. I solve this in the code below by starting a timer that
fires after one second. Also, for some reason that I don't understand, I have to
run the garbage collector twice.

My (ugly!) code:

local wibox = require("wibox")
collectgarbage("collect")
print(collectgarbage("count"))
local foo = {}
for i = 1,100 do
  table.insert(foo, wibox({}))
end
collectgarbage("collect")
print(collectgarbage("count"))
foo = nil
collectgarbage("collect")
print(collectgarbage("count"))
local t = timer({timeout = 1})
t:connect_signal("timeout", function()
collectgarbage("collect")
   collectgarbage("collect")
   print(collectgarbage("count"))
   awesome.quit()
end)
t:start()

The code's output when I use this as awesome's rc.lua:

814.64453125
2122.6962890625
2107.4267578125
848.3525390625

What this means: Right after startup and loading the wibox library, 814 KiB is
used (I am not sure if this really is measured in KiB, but I will just assume
so). After 100 wiboxes are created, this jumps to 2122 KiB. Right after the "foo
= nil" line, the wiboxes should be garbage collectable, but due to the redraw
magic mentioned above, there are still internal references to them. Thus, the
garbage collector only manages to free 15 KiB of memory (2122-2107).

After a second, the timer runs. For some reason that I don't understand, I have
to run the garbage collector here twice. This took me way too long to notice.
Weird. :-(

Anyway, in the second since their creation, the needed redraws were run and the
wiboxes can be garbage collected. And indeed, the memory usage drops down to 848
KiB. This is still 34 KiB more than right after startup, but I will assume that
this is (at least partly) due to the timer object that cannot be garbage 
collected.

So the wiboxes are deleted without any issue here.

Cheers (and a happy new year),
Uli
-- 
"In the beginning the Universe was created. This has made a lot of
 people very angry and has been widely regarded as a bad move."

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: Setting custom X properties for clients to preserve tags between awesome restarts

[Uli Schlachter]

Hi,

On 03.12.2013 11:06, Stanislav Ochotnicky wrote:
> Quoting Uli Schlachter (2013-12-03 08:54:22)
>> On 02.12.2013 23:39, Stanislav Ochotnicky wrote:
>>> Quoting Uli Schlachter (2013-12-02 22:57:58)
>> [...]
>>>> I hope this clears up the current state. Feel free to come up with 
>>>> suggestions
>>>> on how to improve this.
>>>
>>> Thanks for quick reply. I don't think it makes sense to complicate core 
>>> awesome
>>> codebase by introducing custom X property. It *would* be nice if completely 
>>> full
>>> dynamic tagging would be easily possible but that's not really a discussion 
>>> for
>>> this thread :-)
>>
>> I just thought about adding a "blob" property which contains just a random
>> string that is completely uninterpreted by awesome, but could be accessed by
>> lua. This blob would however need a better name than just "blob", of course.
>>
>> This isn't much work on the C side and shifts the problem into lua-land (aka 
>> "no
>> longer my problem" ;-) ).
>>
>>
>> If it were called "blob", I would save it in "AWESOME_BLOB" and have it
>> accessible as c.blob. There are some obvious problems like "who controls the
>> blob" where different modules both would want to save stuff in there. If this
>> should be solved, then "blob" would not only need a way better name, but 
>> would
>> also need to be a table. And I would have to think about how to serialize a 
>> lua
>> table into an X11 property...
> 
> I am not sure about maximum size of X11 property but I can imagine few use 
> cases
> (mostly around preserving state between restarts, saving, restoring, maybe
> profiles?)

Good question. The only thing I found in the docs:

"The maximum size of a property is server-dependent and may vary dynamically."

Anyway, attached is a patch which implements a "blob" property on clients. This
is a string that survives restarts. Of course, this needs some helper functions
in awful so that more than one thing can be saved in here. No idea about the
format for this and too lazy to think about it.

So this patch is just a proof of concept that people can experiment with. Also,
I still don't like the name "blob".

[...]
>> What do you guys think?
> 
> I'd welcome uncle blob with open arms. I believe a nice Lua access API will be
> needed but that's a separate point...

Looking forward to someone implementing this. :-)

Uli
-- 
Happiness can't be found -- it finds you.
 - Majic
diff --git a/common/atoms.list b/common/atoms.list
index 507a7ff..4c71893 100644
--- a/common/atoms.list
+++ b/common/atoms.list
@@ -1,3 +1,4 @@
+AWESOME_BLOB
 _NET_SUPPORTED
 _NET_STARTUP_ID
 _NET_CLIENT_LIST
diff --git a/objects/client.c b/objects/client.c
index bdbcaae..d59554a 100644
--- a/objects/client.c
+++ b/objects/client.c
@@ -431,6 +431,10 @@ client_manage(xcb_window_t w, xcb_get_geometry_reply_t *wgeom, bool startup)
 return;
 }
 
+xcb_get_property_cookie_t blob_q;
+blob_q = xcb_get_property(globalconf.connection, false, w, AWESOME_BLOB,
+  XCB_GET_PROPERTY_TYPE_ANY, 0, UINT_MAX);
+
 /* If this is a new client that just has been launched, then request its
  * startup id. */
 xcb_get_property_cookie_t startup_id_q = { 0 };
@@ -494,6 +498,19 @@ client_manage(xcb_window_t w, xcb_get_geometry_reply_t *wgeom, bool startup)
 xcb_ungrab_server(globalconf.connection);
 }
 
+{
+/* Request our response */
+xcb_get_property_reply_t *reply =
+xcb_get_property_reply(globalconf.connection, blob_q, NULL);
+
+if (reply)
+{
+c->blob.length = xcb_get_property_value_length(reply);
+c->blob.data = p_dup((char *) xcb_get_property_value(reply), c->blob.length);
+}
+p_delete(&reply);
+}
+
 /* Do this now so that we don't get any events for the above
  * (Else, reparent could cause an UnmapNotify) */
 xcb_change_window_attributes(globalconf.connection, w, XCB_CW_EVENT_MASK, select_input_val);
@@ -1763,6 +1780,13 @@ luaA_client_get_icon_name(lua_State *L, client_t *c)
 return 1;
 }
 
+static int
+luaA_client_get_blob(lua_State *L, client_t *c)
+{
+lua_pushlstring(L, NONULL(c->blob.data), c->blob.length);
+return 1;
+}
+
 LUA_OBJECT_EXPORT_PROPERTY(client, client_t, class, lua_pushstring)
 LUA_OBJECT_EXPORT_PROPERTY(client, client_t, instance, lua_pushstring)
 LUA_OBJECT_EXPORT_PROPERTY(client, client_t, machine, lua_pushstring)
@@ -2006,6 +2030,23 @@ luaA_client_set_shape_clip(lua_State *L, client_t *c)
 return 0;
 }
 
+/** Set the cli

Re: Setting custom X properties for clients to preserve tags between awesome restarts

[Uli Schlachter]

On 02.12.2013 23:39, Stanislav Ochotnicky wrote:
> Quoting Uli Schlachter (2013-12-02 22:57:58)
[...]
>> I hope this clears up the current state. Feel free to come up with 
>> suggestions
>> on how to improve this.
> 
> Thanks for quick reply. I don't think it makes sense to complicate core 
> awesome
> codebase by introducing custom X property. It *would* be nice if completely 
> full
> dynamic tagging would be easily possible but that's not really a discussion 
> for
> this thread :-)

I just thought about adding a "blob" property which contains just a random
string that is completely uninterpreted by awesome, but could be accessed by
lua. This blob would however need a better name than just "blob", of course.

This isn't much work on the C side and shifts the problem into lua-land (aka "no
longer my problem" ;-) ).

If it were called "blob", I would save it in "AWESOME_BLOB" and have it
accessible as c.blob. There are some obvious problems like "who controls the
blob" where different modules both would want to save stuff in there. If this
should be solved, then "blob" would not only need a way better name, but would
also need to be a table. And I would have to think about how to serialize a lua
table into an X11 property...

What do you guys think?

Uli
-- 
"Do you know that books smell like nutmeg or some spice from a foreign land?"
  -- Faber in Fahrenheit 451

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: Setting custom X properties for clients to preserve tags between awesome restarts

[Uli Schlachter]

On 03.12.2013 08:44, Vincent Bernat wrote:
>  ❦  2 décembre 2013 22:57 CET, Uli Schlachter  :
> 
>>> [1] xprop -f WM_AWESOME_TAGS 8s -set WM_AWESOME_TAGS tag1,tag2
>>
>> Such a property (almost) already exists and is called _NET_WM_DESKTOP. It is
>> used for saving the first (and only the first, this is the "almost" part) tag
>> that a client is attached to (mostly because EWMH demands this).
> 
> Is it possible to read it from Lua without using an external tool?

Nope, by the time Lua sees a client and can work with it, awesome already
overwrote that property with whatever tags the client now belongs to, sorry.

Uli
-- 
"Do you know that books smell like nutmeg or some spice from a foreign land?"
  -- Faber in Fahrenheit 451

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: mytaskslist at bottom vs top

[Uli Schlachter]

On 02.12.2013 23:50, Jason Hunt wrote:
> Afternoon.  I created a new wibox in rc.lua for supplemental statusbar:
> 
> mywibox2 = {}
> mywibox2 = awful.wibox({ position = "bottom", screen = 1, border_width = 0,
> height = 16 })
> 
> 
> Currently, it is just an empty status bar.  I commented out the below, so
> open clients would not appear in top statusbar:
> 
> -- Now bring it all together (with the tasklist in the middle)
> --  layout:set_middle(mytasklist[s])
> 
> Ok, so now open clients do not appear at the top statusbar.  I would like
> open clients to appear on the bottom status bar.  How?  I want to keep the
> top task bar just for widgets and available tags.  Thanks in advance for
> any insight.
> 

mywibox2:set_widget(mytasklist[s])

Cheers,
Uli
-- 
"Do you know that books smell like nutmeg or some spice from a foreign land?"
  -- Faber in Fahrenheit 451

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: Setting custom X properties for clients to preserve tags between awesome restarts

[Uli Schlachter]

Hi,

On 02.12.2013 22:18, Stanislav Ochotnicky wrote:
> First my use case (perhaps someone will suggest a different way to deal with
> this):
> I use dynamic tagging facilities in awesome (and tyrranical). I have
> configuration for most applications that I use but I often connect to several
> hosts and for each I create a separate tag so that I don't mess up.
> 
> Now the issue is that when I disconnect my laptop from docking station, 
> awesome
> restarts due to XRandR change and all the consoles and apps without specific
> rules end up on the first tag.
> 
> I came up with a possible solution:
> * For each client awesome would set custom X property[1]
> * On restart awesome would look at that custom property and it would
>   override whatever rules were configured
> 
> There are possible caveats but I'd say this might still be useful.
> 
> Is this perhaps something that someone else has already implemented? Couldn't
> find anything in the archives. Ideally this would be done in the library code,
> but as PoC I might just do a custom configuration
> 
> [1] xprop -f WM_AWESOME_TAGS 8s -set WM_AWESOME_TAGS tag1,tag2

Such a property (almost) already exists and is called _NET_WM_DESKTOP. It is
used for saving the first (and only the first, this is the "almost" part) tag
that a client is attached to (mostly because EWMH demands this).

After parsing the config, the C code goes through all already-existing clients
and manages them (thus creates client objects for them and call the manage
signal). Before emiting the manage hook, the C code checks if the client has the
_NET_WM_DESKTOP property set and tags it with the appropriate tag. This is done
in the following C code:

reply = xcb_get_property_reply(globalconf.connection, c0, NULL);
if(reply && reply->value_len && (data = xcb_get_property_value(reply)))
{
desktop = *(uint32_t *) data;
if(desktop == -1)
c->sticky = true;
else if (desktop >= 0 && desktop < globalconf.tags.len)
for(int i = 0; i < globalconf.tags.len; i++)
if(desktop == i)
{
luaA_object_push(globalconf.L, globalconf.tags.tab[i]);
tag_client(c);
}
else
untag_client(c, globalconf.tags.tab[i]);
else
/* Value out of bounds, just give it the first tag */
if (globalconf.tags.len > 0)
{
luaA_object_push(globalconf.L, globalconf.tags.tab[0]);
tag_client(c);
}
}

This does work with the default config. Now why doesn't it work with your 
config?

> I use dynamic tagging facilities in awesome (and tyrranical).

After your config was parsed, there is only a single tag (at least I guess so).
Thus, the above code cannot tag the client appropriately.

I hope this clears up the current state. Feel free to come up with suggestions
on how to improve this.

Cheers,
Uli
-- 
A normal person is just someone you don't know well enough yet.
 - Nettie Wiebe

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: awesome hangs on starting x11-ssh-askpass

[Uli Schlachter]

On 23.11.2013 03:49, Kasimir Knallkopf wrote:
>> sudo apt-get install ssh-askpass
>> 
>> DISPLAY=:1 ssh-askpass
>>
>> The askpass window appeared, I entered foobar, pressed enter and the window
>> disappeared.
> 
> I can reproduce this bug on the default configuration of awesome
> on archlinux. I even created another user, started another Xorg
> session, and awesome hangs.

Meh. Still cannot reproduce this on debian, but this is reproducible on Arch.

http://git.naquadah.org/?p=awesome.git;a=commit;h=389a54e356f700a4f2a621e05dbdbafab4a3a03a

Uli
-- 
- He made himself, me nothing, you nothing out of the dust
- Er machte sich mir nichts, dir nichts aus dem Staub

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: awesome hangs on starting x11-ssh-askpass

[Uli Schlachter]

On 20.11.2013 09:43, Namikaze Minato wrote:
> Well, something similar is happening to me when I use evince with the
> mozilla plugin for reading PDFs on chromium and that I click on the
> PDF viewer (scrolling is fine), but it's too much of an edge case for me
>  to report it as a bug. (awesome completely hangs and I need to go to
> a tty to HUP awesome)

This sounds like FS#762:

https://awesome.naquadah.org/bugs/index.php?do=details&task_id=762

Uli

> In any case, you should HUP awesome instead of rebooting your machine,
> at least as a temporary measure. I think "pkill -HUP awesome" works,
> but I've always done it through htop so I'm not sure.
> 
> Regards,
> Camusensei
> 
> On 20 November 2013 05:42, Kasimir Knallkopf  wrote:
>>> Which awesome version are you running?
>>
>> awesome v3.5.2 (The Fox)
>>  ⢠Build: Oct 13 2013 01:33:36 for x86_64 by gcc version 4.8.1 (nobody@)
>>  ⢠Compiled against Lua 5.2.2 (running with Lua 5.2)
>>  ⢠D-Bus support: â
>>
>> So it's a new bug then. The x11-askpass window doesn't appear at all and it 
>> basically hangs awesome. I can still type in the termin that I started 
>> x11-askpass from, but that's basically what works. So at least I can type 
>> reboot.
>>
>> It should be reproducible on other systems. Does nobody on this list have a 
>> problem when starting x11-askpass?
>>
>> Thanks.
>>
>> --
>> To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
> 


-- 
No matter how much cats fight, there always seem to be plenty of kittens.

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: awesome hangs on starting x11-ssh-askpass

[Uli Schlachter]

On 20.11.2013 05:42, Kasimir Knallkopf wrote:
>> Which awesome version are you running? 
> 
> awesome v3.5.2 (The Fox)
>  ⢠Build: Oct 13 2013 01:33:36 for x86_64 by gcc version 4.8.1 (nobody@)
>  ⢠Compiled against Lua 5.2.2 (running with Lua 5.2)
>  ⢠D-Bus support: â
> 
> So it's a new bug then. The x11-askpass window doesn't appear at all and it 
> basically hangs awesome. I can still type in the termin that I started 
> x11-askpass from, but that's basically what works. So at least I can type 
> reboot.
> 
> It should be reproducible on other systems. Does nobody on this list have a 
> problem when starting x11-askpass?

So I did the following:

sudo apt-get install ssh-askpass

DISPLAY=:1 ssh-askpass

The askpass window appeared, I entered foobar, pressed enter and the window
disappeared.

So to answer your question:
I can't reproduce this and who uses askpass anyway?

Uli
-- 
Who needs a ~/.signature anyway?

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: Questions about "awful.widget.layout.margins" on awesome 3.5

[Uli Schlachter]

Hi,

On 20.11.2013 11:12, Dong Zhu wrote:
[...]

on awesome 3.5 I change the codes as below:
membar = awful.widget.progressbar()
membar:set_width(50)
membar:set_height(8)
membar:set_vertical(false)
membar:set_background_color("#3F3F3F")
membar:set_border_color(nil)
membar:set_color({ type = "linear", from = { 0, 0 }, to = { 10,0 }, stops = { {0, "#AECF96"}, {0.5, 
"#88A175"}, {1, "#FF5656"}}})
vicious.register(membar, vicious.widgets.mem, "$1", 13)
memwidget = wibox.widget.textbox()
memwidget.set_align("left")
vicious.register(memwidget, vicious.widgets.mem, "$2Mb", 5)

This "awful.widget.layout.margins[membar.widget] = { top = 8 }" seems
not work as expect and the membar is very very big.  How to make membar

> align with middle ?

Use the following to get a new widget with that margin:

memwidgetmargin = wibox.layout.margin()
memwidgetmargin:set_widget(memwidget)
memwidgetmargin:set_top(8)


Uli

--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: awesome hangs on starting x11-ssh-askpass

[Uli Schlachter]

Hi,

On 19.11.2013 14:03, Kasimir Knallkopf wrote:
> I would like to use askpass to enter passwords through the gui. When I 
> start /usr/lib/ssh/x11-ssh-askpass, then the askpass window will not appear 
> *and* the screen focus will be locked to the terminal from which I started 
> askpass. It seems that this is probably a known bug:
> https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1124

Which awesome version are you running? The commit that is referenced from the
bug didn't find its way into a release, but the equivalent code from
ed66fda1f1d390db18383810c6f91e5aec6ebf16 is part of v3.5.2.

Also, you are refering to the wrong bug. The above bug is only about
"ssh-askpass is below all other windows". You are looking for FS#573:

https://awesome.naquadah.org/bugs/index.php?do=details&task_id=573

This bug was reported and fixed in 2009. So unless you are running something as
old as 3.4.0 (yes, I did look this up), you shouldn't hit this bug...

> The bug has no found its way from the git version to the release version.

The bug was never reported against git, so it always affected releases.

> Is
> there a way to fix this through the config file without the need to apply a 
> patch?
> Thanks.

Yeah, upgrade to the latest release. If you can't do that for some reason
(why?), then nope, your config won't help.

Uli
-- 
"Why make things difficult, when it is possible to make them cryptic
and totally illogical, with just a little bit more effort?" -- A. P. J.

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: Apps do not show on the systray

[Uli Schlachter]

Hi,

On 06.11.2013 03:40, Alfredo Palhares wrote:
> Apps like Skype, Steam, network manager, dropbox or anything really
> do not show on the systray on my config. There is absoluty nothing 
> in the tty. Would a someone give a look? The wibox is created on
> cfg/wibox.lua.
> 
> 
> Here is the git repository: 
> https://github.com/masterkorp/Awesome-config-files
> 
> The master branch is affected.
> 
> awesome v3.5.2 (The Fox)
>  • Build: Oct 13 2013 01:33:36 for x86_64 by gcc version 4.8.1 (nobody@)
>  • Compiled against Lua 5.2.2 (running with Lua 5.2)
>  • D-Bus support: ✔
> 
> On archlinx, up to date.

I might be missing something, but which systray?

$ git clone https://github.com/masterkorp/Awesome-config-files.git
Klone nach 'Awesome-config-files'...
remote: Counting objects: 739, done.
remote: Compressing objects: 100% (288/288), done.
Empfange Objekte: 100% (739/739), 7.30 MiB | 1.74 MiB/s, done.
remote: Total 739 (delta 454), reused 733 (delta 448)
Löse Unterschiede auf: 100% (454/454), done.
Prüfe Konnektivität... Fertig
$ cd Awesome-config-files/
$ git grep systray
$

Uli
-- 
A learning experience is one of those things that say,
'You know that thing you just did? Don't do that.'
 -- Douglas Adams

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: updated wiki page xrandr screen table

[Uli Schlachter]

Good Morning,

On 31.10.2013 05:46, Andre Klärner wrote:
> On Wed 30.10.2013 20:28:32, Uli Schlachter wrote:
[...]
>> Having written this mail and re-reading it before sending it, I notice that 
>> you
>> mentioned awesome 3.4.15. A quick look confirms that 3.4 does not have this
>> feature. It was introduced in the following commit:
>>
>> commit 9393b2d1110b308edddf3255b5a001fe64f49478
>> Author: Julien Danjou 
>> Date:   Mon Sep 21 20:35:14 2009 +0200
>>
>> screen: add index by output name (FS#361)
>>
>> Signed-off-by: Julien Danjou 
> 
> Well, I think one should document this in the wiki. I think I read this bug
> report way back when I first searched for this. Unfortunately I seemingly
> missed the "fixed in 3.5 part".

Documented this in git. No idea if my explanation makes much sense.

http://git.naquadah.org/?p=awesome.git;a=commitdiff;h=29ecc6095f6f566757d17538635eb2b7674ed96f

>>> I tried to find the code responsible for creating the screens array, but it
>>> seems like I am not a really good C-reader. But if such a feature was
>>> available it would definately ease my day.
>>
>> Heh. :-)
>>
>> Look at screen.c, function luaA_screen_module_index(). This function is 
>> called
>> whenever you index the screen object. It's implementation is:
>>
[...]
> 
> Well, obviously this can't be found in 3.4's code (as I checked it out via
> apt-source..). But I am still very impressed.. there should be a how-to on
> reading source code.. ;)

No idea how such a how-to should look like. It seems like the problem here was
partly in our magic for implementing classes in lua. However, most of that is
part of lua already...

> Thanks a lot, I think it won't take long until I finally get around
> switching to 3.5.

Arnau once mentioned that 3.5.1 was uploaded to debian experimental, because it
didn't work for him. His bug report (FS#1155) was fixed with 3.5.2 and thus I
guess 3.5.2 might show up in unstable eventually...

[...]

Uli
-- 
If you ask me to debug your code, I'm going to mail you spiders.

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: updated wiki page xrandr screen table

[Uli Schlachter]

Hi again,

On 30.10.2013 18:42, Andre Klärner wrote:
> On Wed 30.10.2013 18:00:33, Uli Schlachter wrote:
>> On 30.10.2013 03:37, Andre Klärner wrote:
>>> as my setup at home is a bit more complex than the one on the go and at
>>> work I had to modify the xrandr screen table function a bit. To not keep it
>>> just for me I updated the wiki page for it.
>>>
>>> https://awesome.naquadah.org/wiki/XRandR_Screen_Table
>>>
>>> I'd be grateful if anyone using the script might try out the updated
>>> version and tell me if and what mistakes I made.
>>
>> I might be missing something, but I think that this code (copied from that 
>> wiki
>> page):
>>
>>  screens = xrandr_screens()
>>  client.focus.screen = screens["VGA"]
>>
>> is equivalent to this code:
>>
>>  client.focus.screen = screen.VGA.index
> 
> This doesn't work for me. I tried with v3.4.15 and it first struggeled with
> the output name "DP-1", and on my laptop with an output named "LVDS" it
> also returned nothing at all.

For DP-1, you would need screen["DP-1"].index. In lua, foo.bar is syntactic
sugar for foo["bar"], but the later is more generic and also works with
non-lua-identifiers.

I tested this for all my screens locally with:

$ echo 'return screen.LVDS1.index' | awesome-client
   double 2
$ echo 'return screen.VGA1.index' | awesome-client
   double 1


Having written this mail and re-reading it before sending it, I notice that you
mentioned awesome 3.4.15. A quick look confirms that 3.4 does not have this
feature. It was introduced in the following commit:

commit 9393b2d1110b308edddf3255b5a001fe64f49478
Author: Julien Danjou 
Date:   Mon Sep 21 20:35:14 2009 +0200

screen: add index by output name (FS#361)

Signed-off-by: Julien Danjou 

> I tried to find the code responsible for creating the screens array, but it
> seems like I am not a really good C-reader. But if such a feature was
> available it would definately ease my day.

Heh. :-)

Look at screen.c, function luaA_screen_module_index(). This function is called
whenever you index the screen object. It's implementation is:

/** Screen module.
 * \param L The Lua VM state.
 * \return The number of elements pushed on stack.
 * \luastack
 * \lfield number The screen number, to get a screen.
 */
static int
luaA_screen_module_index(lua_State *L)
{
const char *name;

if((name = lua_tostring(L, 2)))
foreach(screen, globalconf.screens)
foreach(output, screen->outputs)
if(A_STREQ(output->name, name))
return luaA_pushscreen(L, screen);

int screen = luaL_checknumber(L, 2) - 1;
luaA_checkscreen(screen);
return luaA_pushscreen(L, &globalconf.screens.tab[screen]);
}

So it checks all screens and for each of its output, it checks its name (a
screen can have more than one output! A screen object tells you about its output
with the "outputs" key. This is a table with the keys being the output name and
the values being another table with entries "mm_width" and "mm_height")

Uli
-- 
Bruce Schneier can read and understand Perl programs.

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: updated wiki page xrandr screen table

[Uli Schlachter]

Hi,

On 30.10.2013 03:37, Andre Klärner wrote:
> as my setup at home is a bit more complex than the one on the go and at
> work I had to modify the xrandr screen table function a bit. To not keep it
> just for me I updated the wiki page for it.
> 
> https://awesome.naquadah.org/wiki/XRandR_Screen_Table
> 
> I'd be grateful if anyone using the script might try out the updated
> version and tell me if and what mistakes I made.

I might be missing something, but I think that this code (copied from that wiki
page):

 screens = xrandr_screens()
 client.focus.screen = screens["VGA"]

is equivalent to this code:

 client.focus.screen = screen.VGA.index

No idea if this feature is documented anywhere, but I think I just found a
volunteer to mention this in the wiki.

Of course, this does not work if awesome is not using RANDR for querying the
monitor configuration. Also, there doesn't seem to be a way for querying the
list of available screens.

Cheers,
Uli
-- 
Bruce Schneier can read and understand Perl programs.

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: Dividing up a screen

[Uli Schlachter]

Hi,

On 22.10.2013 21:14, Rena wrote:
> Since a GPU upgrade, I have 3 screens, and xrandr sees them individually,
> but awesome only sees a single large screen.

What exactly is a GPU upgrade?
Could you provide the output of "xrandr" and "xdpyinfo -ext XINERAMA"? Which
awesome version are you using?

> Can I configure awesome to
> divide this area up into three parts, so that each screen has its own tags,
> layout, wiboxes, etc, like it was before the upgrade when it actually saw
> them as three separate screens?

Cheers,
Uli
-- 
No matter how much cats fight, there always seem to be plenty of kittens.

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: [ANNOUNCE] awesome 3.5.2 released

[Uli Schlachter]

Hi,

On 13.10.2013 19:28, Raphael Cervantes wrote:
> Hi,
> I was unable to get it to compile on arch linux. I'm attaching the error 
> messages I get when I run make. I'll be greatful of any help or advice.

Did you build awesome yourself before, too?

I guess that awesome was compiled against the headers of lua 5.2, but the linker
tries to link it with lua 5.1. The Arch PKGBUILD[0] uses
-DLUA_LIBRARY=/usr/lib/liblua.so.5.2 to make sure that the correct library is 
used.

Uli


[0]:
https://projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/awesome
-- 
99 little bugs in the code
99 little bugs in the code
Take one down, patch it around
117 little bugs in the code
  -- @irqed

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

[ANNOUNCE] awesome 3.5.2 released

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Good evening,

it's been a while already and lots of small and weird issues were fixed. So
here is awesome 3.5.2 "The Fox" for you to enjoy.

There is one problem with this release: It should be backwards compatible to
3.5.1. This means your "old" rc.lua will still work with 3.5.2. Terrible, I 
know.

I want to thank Michael Stapelberg, the author of xcb-cursor. Due to this
library, awesome doesn't use Xlib any more. The only reason we were using it
was so that we can use libxcursor and this was now replaced with xcb-cursor.
(Also, I got rid of the xcb-image dependency)

Enjoy!
Uli
- -- 

awesome version 3.5.2 has been released. It is available from:

tar.xz: http://awesome.naquadah.org/download/awesome-3.5.2.tar.xz
md5: c16eaaaddf6f56b4e041007952e2a4fe
sha1: b7dfb5bd105a884fb0421c48eb9040fb0a46b17e

tar.bz2: http://awesome.naquadah.org/download/awesome-3.5.2.tar.bz2
md5: 575b2c2a6d38510c6d059dca09bc269f
sha1: 5617b51733142dfcabdc7ac2c5bcdd293964a85a

number of changes
- -
32

number of commiters
- -------
5

shortlog
- 
Uli Schlachter (28):
  Implement window gravity in ConfigureRequests (FS#1137)
  awful.tooltip: Set the bg color correctly (FS#1148)
  lua: Print traceback on startup errors
  luadoc: Clients have a leader_window, not leader_id
  Fix WM_CLIENT_LEADER handling
  client: Ignore "fake" string property changes
  wibox: Add widget geometry cache
  draw: Add function for finding a visual by id
  client.content: Use correct client size (FS#1150)
  client.content: Return a cairo xcb surface
  Stop linking against xcb-image
  awful.titlebar: Add show, hide, toggle functions
  Switch from libXcursor to libxcb-cursor
  CMake: Look for both "ldoc" and "ldoc.lua"
  Use $PATH when starting $SHELL
  ewmh: remove _NET_DESKTOP_GEOMETRY support
  screen: Make sure we always have a screen
  Fix possible deadlock during startup
  naughty: Verify image parameters coming from dbus (FS#1162)
  awful.screen.focus: Don't move mouse to (0, 0) first (FS#1173)
  awful.client.tiled: Ignore fullscreen (etc) clients (FS#1106)
  client: Ignore transient_for causing loops (FS#1124)
  screen: Fix screen equality comparison (FS#1151)
  client: Don't move clients around across restarts (FS#1159)
  Revert "client: Don't move clients around across restarts (FS#1159)"
  event: Handle MotionNotify before ButtonPress/Release (FS#1136)
  awful.tag.withcurrent: Also act on restarts (FS#1155)
  change codename

Alexander Kondratev (1):
  fixed #1184. Calling movetotag method throw an error on a blank screen

Björn Åström (1):
  wibox.layout.fixed: Fix fill space

David Mohr (1):
  Revert "client: add a limit to the loop (FS#573)"

kardan (1):
  honor appended -c option for --check


diffstat
- 
 awesome.c  | 57
-
 awesomeConfig.cmake| 11 ++-
 awesomerc.lua.in   | 16 ++--
 common/atoms.list  |  1 -
 common/util.c  |  4 ++--
 common/xcursor.c   |  8 +---
 common/xcursor.h   |  6 ++
 draw.c |  9 +++--
 draw.h |  1 +
 event.c| 31 ++-
 ewmh.c | 15 ---
 globalconf.h   |  5 +++--
 lib/awful/client.lua.in|  5 -
 lib/awful/screen.lua.in|  1 -
 lib/awful/tag.lua.in   | 21 +
 lib/awful/titlebar.lua.in  | 63
++-
 lib/awful/tooltip.lua.in   |  2 +-
 lib/naughty.lua.in |  8 
 lib/wibox/layout/align.lua.in  | 14 +++---
 lib/wibox/layout/base.lua.in   | 21 +
 lib/wibox/layout/constraint.lua.in |  2 +-
 lib/wibox/layout/fixed.lua.in  | 10 +-
 lib/wibox/layout/flex.lua.in   |  2 +-
 lib/wibox/layout/margin.lua.in |  2 +-
 lib/wibox/layout/mirror.lua.in |  2 +-
 lib/wibox/layout/rotate.lua.in |  2 +-
 lib/wibox/widget/base.lua.in   |  7 +++
 luaa.c |  5 -
 luadoc/client.lua  |  2 +-
 mousegrabber.c |  2 +-
 objects/client.c   | 47
+--
 objects/client.h   |  6 ++
 objects/drawin.c   |  4 ++--
 property.c | 14 --
 root.c |  2 +-
 screen.c   | 42
++--

Re: cairo widget borders

[Uli Schlachter]

On 11.10.2013 23:04, Andrey V Golovin wrote:
> Thanks for swift reply, Uli
> 
> 
> The function to draw is:
> colors for bg and fg are taken from array
> 
> function sep(fg,bg)
>sp = wibox.widget.base.make_widget()
>sp.fit = function(mycross, width, height)
>local size = math.min(width, height)
>return size/2, size
>end

Just a random guess: I need to round the result of fit().

Could you try this:

  return math.ceil(size/2), size

Uli

>sp.draw = function(sp, wibox, cr,width, height)
>r,g,b,a = hexadecimal_to_rgba_percent(fg)
>cr:move_to(width,0)
>cr:line_to(0, height)
>cr:line_to(width,height)
>cr:close_path()
>cr:set_line_width(0)
>cr:set_source_rgba(r,g,b,a)
>cr:fill()
>if string.match(bg,"#%w+")
>then
> r,g,b,a = hexadecimal_to_rgba_percent(bg)
> cr:move_to(0,0)
> cr:line_to(width,0)
> cr:line_to(0,height)
> cr:close_path()
> cr:set_line_width(3)
> cr:set_source_rgba(r,g,b,a)
> cr:fill()
>   else
> r,g,b,a = hexadecimal_to_rgba_percent(fg)
> cr:move_to(0,0)
> cr:line_to(width,0)
> cr:line_to(0,height)
> cr:close_path()
> cr:set_line_width(3)
> cr:set_source_rgba(r,g,b,a)
> cr:fill()
>end
> 
>end
>return sp
> end


-- 
- Buck, when, exactly, did you lose your mind?
- Three months ago. I woke up one morning married to a pineapple.
  An ugly pineapple... But I loved her.

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: cairo widget borders

[Uli Schlachter]

On 11.10.2013 12:40, Andrey V Golovin wrote:
> Hi all
> I made simple cairo drawing in widget area.
> http://imgur.com/pIGDMXP.png
> 
> But, these one pixel lines between drawings looks bad. I played with cairo
> colors it does not help. Is somebody has an idea how to fix it would be
> very nice to share.
> Thanks in advance.

Sorry, no idea here. How are you drawing those dark lines between the widgets?
What does the code look like and do? How exactly are these backgrounds drawn?

Uli
-- 
Sent from my Game Boy.

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: Prevent calls to XMoveWindow and XMoveResizeWindow

[Uli Schlachter]

Hi,

On 05.09.2013 12:24, Vincent Bernat wrote:
> Some programs like to resize and replace themselves after start. This is
> annoying as they may move to another screen. For example, Wireshark is
> like that.
> 
> It uses GTK but ultimately, this is the call to XResizeWindow or
> XMoveResizeWindow which triggers this behaviour. Would it be possible to
> tell Awesome to ignore those?
> 
> If not, such a behaviour could be overrident with LD_PRELOAD. For
> example, there is already something done specifically for Steam about
> this:
>  https://github.com/dscharrer/steamwm
> 
> However, I would like something more generic that I could LD_PRELOAD for
> the whole session. Unfortunately, there are some legit use of
> XMoveResizeWindow. Would it be possible for Awesome to help me when to
> prevent such a resize? For example, is it possible for Awesome to set a
> property on a window that I could easily read when intercepting
> XMoveWindow?

There is no "easy" way to do this in awesome. No idea what you mean with that
property thing, but when a window resizes itself, the X11 server sends a
ConfigureRequest to awesome. This ends up in event.c,
event_handle_configurerequest() where awesome just allows that change. If you
know some C, this is the place were $MAGIC could be done to "defeat"
XMoveResizeWindow().

Uli
-- 
Sent from my Game Boy.

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: How to delete wiboxes

[Uli Schlachter]

Hi,

On 04.09.2013 17:30, Csaba Dunai wrote:
[...]
> a = wibox({})
> a.screen = 1
> a.visible = true
> a.ontop = true
> a.x = 10
> a.y = 10
> a.width = 100
> a.height = 100
> a:set_bg("#ffa500")
> a.screen = nil
> a = nil

Wiboxes no longer have a .screen property, because there is just a single, "big"
screen. So now you get rid of wiboxes via a.visible = false.

> --end example--
> 
> However the wibox remains where it is. What am I doing wrong? Has the way
> of deleting wiboxes changed in the meanwhile?
> 
> My awesome version is:
> 
> awesome v3.5.1 (Ruby Tuesday)
>  • Build: Apr  1 2013 19:51:47 for x86_64 by gcc version 4.7.2 (nobody@copy)
>  • Compiled against Lua 5.2.1 (running with Lua 5.2)
>  • D-Bus support: ✔
> 
> Kind regards

Cheers,
-- 
A normal person is just someone you don't know well enough yet.
 - Nettie Wiebe

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: Documenting vicious for awesome v3.5

[Uli Schlachter]

Hi,

On 18.08.2013 14:56, Adrian C. wrote:
> Hello, is someone using awesome v3.5 willing to rewrite "Usage examples" 
> section[1] and the next section "Format functions" of the documentation 
> for the new widget API? Thanks.

attached patch should help anyone who wants to work on this. I just went through
those two sections and changed things into 3.5-syntax.

This patch is completely untested and thus only a normal diff and not a proper
git-formatted patch!

The idea is just to help someone else who wants to actually do this work. (I
don't suppose that the 3.4-specific information should just be dropped?)

Uli
-- 
A normal person is just someone you don't know well enough yet.
 - Nettie Wiebe
diff --git a/README b/README
index bf16d36..6ecac3b 100644
--- a/README
+++ b/README
@@ -387,7 +387,7 @@ file with their GPG key. Trough the GPG Passphrase Agent they could
 then decrypt the file transparently while their session is active.
 
 
-Usage examples (for awesome v3.4)
+Usage examples (for awesome v3.5)
 -
 Start with a simple widget, like date. Then build your setup from
 there, one widget at a time. Also remember that besides creating and
@@ -395,14 +395,14 @@ registering widgets you have to add them to a wibox (statusbar) in
 order to actually display them.
 
 Date widget
-  datewidget = widget({ type = "textbox" })
+  datewidget = wibox.widget.textbox()
   vicious.register(datewidget, vicious.widgets.date, "%b %d, %R")
 
   - updated every 2 seconds (the default interval), uses standard
 date sequences as the format string
 
 Memory widget
-  memwidget = widget({ type = "textbox" })
+  memwidget = wibox.widget.textbox()
   vicious.cache(vicious.widgets.mem)
   vicious.register(memwidget, vicious.widgets.mem, "$1 ($2MB/$3MB)", 13)
 
@@ -410,7 +410,7 @@ Memory widget
 values and enables caching of this widget type
 
 HDD temperature widget
-  hddtempwidget = widget({ type = "textbox" })
+  hddtempwidget = wibox.widget.textbox()
   vicious.register(hddtempwidget, vicious.widgets.hddtemp, "${/dev/sda} °C", 19)
 
   - updated every 19 seconds, requests the temperature level of the
@@ -418,7 +418,7 @@ HDD temperature widget
 not provide the port argument so default port is used
 
 Mbox widget
-  mboxwidget = widget({ type = "textbox" })
+  hddtempwidget = wibox.widget.textbox()
   vicious.register(mboxwidget, vicious.widgets.mbox, "$1", 5, "/home/user/mail/Inbox")
 
   - updated every 5 seconds, provides full path to the mbox as an
@@ -431,8 +431,8 @@ Battery widget
   batwidget:set_vertical(true)
   batwidget:set_background_color("#494B4F")
   batwidget:set_border_color(nil)
-  batwidget:set_color("#AECF96")
-  batwidget:set_gradient_colors({ "#AECF96", "#88A175", "#FF5656" })
+  batwidget:set_color({ type = "linear", from = { 0, 0 }, to = { 0, 10 },
+  stops = { { 0, "#AECF96" }, { 0.5, "#88A175" }, { 1, "#FF5656" }})
   vicious.register(batwidget, vicious.widgets.bat, "$2", 61, "BAT0")
 
   - updated every 61 seconds, requests the current battery charge
@@ -443,8 +443,8 @@ CPU usage widget
   cpuwidget = awful.widget.graph()
   cpuwidget:set_width(50)
   cpuwidget:set_background_color("#494B4F")
-  cpuwidget:set_color("#FF5656")
-  cpuwidget:set_gradient_colors({ "#FF5656", "#88A175", "#AECF96" })
+  cpuwidget:set_color({ type = "linear", from = { 0, 0 }, to = { 50, 0 },
+  stops = { { 0, "#FF5656" }, { 0.5, "#88A175" }, { 1, "#AECF96" }})
   vicious.register(cpuwidget, vicious.widgets.cpu, "$1", 3)
 
   - updated every 3 seconds, feeds the graph with total usage
@@ -468,7 +468,7 @@ second argument, and will return the text/data to be used for the
 widget.
 
 Example
-  mpdwidget = widget({ type = "textbox" })
+  mpdwidget = wibox.widget.textbox()
   vicious.register(mpdwidget, vicious.widgets.mpd,
 function (widget, args)
   if   args["{state}"] == "Stop" then return ""
@@ -481,7 +481,7 @@ Example
 seconds (the default interval)
 
 Example
-  uptimewidget = widget({ type = "textbox" })
+  uptimewidget = wibox.widget.textbox()
   vicious.register(uptimewidget, vicious.widgets.uptime,
 function (widget, args)
   return string.format("Uptime: %2dd %02d:%02d ", args[1], args[2], args[3])
@@ -496,9 +496,10 @@ textbox widgets by changing their .width field (by default width is
 automatically adapted to text width).
 
 Example
-  uptimewidget = widget({ type = "textbox" })
-  uptimewidget.width, uptimewidget.align = 50, "right"
+  uptimewidget = wibox.widget.textbox()
+  uptimewidget:set_align("right")
   vicious.register(uptimewidget, vicious.widgets.uptime, "$1 $2:$3", 61)
+  uptimewidget = wibox.layout.constraint(uptimewidget, "exact", 50, nil)
 
   - forces a fixed width of 50px to the uptime widget, and aligns its
 text to the right
@@ -509,7 +510,7 @@ color index arguments elegantly. But they are not unusable, far from
 it.
 
 Example
-  ctext = widget({ type = "textbox"})
+  ctext = wibox.widget.textbox()
   cgraph = awful.wid

Re: help on custom layout

[Uli Schlachter]

Hi,

On 15.08.2013 23:18, luke bonham wrote:

Hi everyone, I was trying to get to work 'termfair' layout from this
good old module: https://github.com/vain/awesome-vain

This is what I got: http://pastebin.com/gecFkxj0

However I keep getting this error:

"/usr/share/lua/5.2/lgi/override/Pango.lua:60: bad argument #3 to 
'pango_layout_set_text' (string expected, got nil)"

and I don't understand how it's caused and how could I fix it.

Any clue?


You are calling box:set_text(nil) somewhere on a wibox.widget.textbox, but "nil" 
is not a valid string. This used to work in 3.4. However, no idea where you are 
doing this and I can't really see from your provided pastes.


I would suggest a hack like this:

local PL = require("lgi").Pango.Layout
local set_text = PL.set_text
function PL._method:set_text(text, len)
  if text == nil then
print(debug.traceback())
  end
  return set_text(self, text, len)
end

That should print a traceback right before the error so that you can see where 
this "nil" is coming from.


Cheers,
Uli

--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: Changing window geometry in non-floating layouts

[Uli Schlachter]

Hi,

On 25.07.2013 11:12, Marshall Mason wrote:
> I'm a heavy user of dmenu and dzen2. I'm trying to figure out how to
> configure Awesome so the clients move down and back up in the brief moments
> that dmenu and dzen2 show up rather than just covering them over.
[...]
> However, this is very kludgy, and I'd like to find a more elegant solution.
> Is there a way to force non-floating modes to accept new geometries? Or
> else is there some way to mimic the behavior of the wibox when toggling
> visibility, i.e. telling all the clients to shrink?

The size of your monitor is called the screen's geometry in awesome. The tiling
algorithm place clients inside the workarea. The workarea is the screen geometry
minus area reserved for struts. And finally: Struts are a way to reserve space
at the edge of the screen.

So let's do some magic to mess with struts. I will assume that you have an
awful.rules-rule that matches dmenu and/or dzen2. This rule gets this function
as a callback:

 function(c)  c:struts({ top = c.geometry().height })  end

However, I just noticed that this won't work. Awesome does not see dmenu
appearing because it creates an override-redirect window ("a window which the WM
is not informed about and which it will not manage").

So that makes me wonder how your solution for the floating case works?

Uli
-- 
"For saving the Earth.. and eating cheesecake!"

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: Current Context

[Uli Schlachter]

Hi,

On 17.07.2013 02:58, Gerald Klein wrote:
[..]
> 1. how to get the current screen object

What exactly is "current" for you?

If you want the mouse's screen, you can use mouse.screen and
screen[mouse.screen] turns that into a screen object.

If you want the currently focused client (if there is one) and fall back to the
mouse otherwise:
screen[client.focus and client.focus.screen or mouse.screen]

> 2. how to get the current tag object.

awful.tag.selected(s) and/or awful.tag.selectedlist(s). If no screen number(!)
is given as an argument, this uses mouse.screen instead.

> The documentation has improved since I last looked but there still
> somethings which are not apparent.

Any suggestions to improve this are appreciated. :-)

> Any help is appreciated.

Cheers,
Uli
-- 
Sent from my Game Boy.

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: set application rule in all tags

[Uli Schlachter]

On 06.07.2013 19:26, debecio wrote:
> Hello, I'm finding the way to show a logout/shutdown dialog window on all 
> tags. Do it exists anything like:
> 
> { rule = { class = {"Logout"} },
>   properties = {
>  floating = true,
>  ontop = true,
>  tag = tags[1][*] } },
> 
> or with
> 
> tag = tags[][1-9]

You are looking for:

  sticky = true

Uli
-- 
"Why make things difficult, when it is possible to make them cryptic
and totally illogical, with just a little bit more effort?" -- A. P. J.

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: Alternative environments?

[Uli Schlachter]

On 28.06.2013 00:59, John Yates wrote:

Any thoughts about supporting awesome on Surface or Mir?

http://lwn.net/Articles/554758/


"Surface" as in "SurfaceFlinger"? What? Why?


I know little about XCB.


"XCB" stands for "X11 C Bindings".

> I know that it encapsulates the godawful X semantics.

XCB is a C binding to X11. It allows you to send and receive X11 
requests/events/replies.


> But is XCB clean enough in its own right that one could provide

an XCB interface to another environment?


We are talking about a protocol binding for X11. As such, it is quite X11 
specific. The idea behind Wayland (btw why don't you mention wayland in your 
mail?) and Mir is to replace X11 with something else. This means that it does 
not try to be compatible with X11 at all, but replace it.


TL;DR: No, XCB is not "clean" enough.

Uli

--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.

Re: client-property leader_id

[Uli Schlachter]

On 19.06.2013 00:25, Manuel Kasser wrote:
> I just wondered what a client's leader_id contains (or, to be more
> precise, in which circumstances there IS a leader_id). I couldn't
> produce a scenario where a client's leader_id is set, but maybe I just
> tried out the wrong scenarios.

Urgh. There is so much wrong in there. First, it is leader_window, not
leader_id. This rename was done here, but the luadoc was forgotten:

commit a02d026f775a45701cd6d93a5b7c5222e043c4d7
Date:   Mon Aug 17 17:02:45 2009 +0200

client: port to new object system

After querying leader_window instead of leader_id, I still didn't get any useful
result, thanks to:

commit 5d0a81c8bf4881d4a0716112e7cedfc3a096a838
Date:   Sun Aug 8 18:31:07 2010 +0200

fix some deprecated atom constants

 client_leader_q = xcb_get_property_unchecked(globalconf.connection,
false, c->window,
- WM_CLIENT_LEADER, WINDOW, 0, 32);
+ WM_CLIENT_LEADER, XCB_ATOM_WINDOW, 1, 32);

(This accidentally(?) replaces a 0 with a 1)

Both of these are fixed now in latest git. Yay.

> What is ment by "spawned by the same
> command" as said in the API*.

This property just gives you the WM_CLIENT_LEADER property of the client. ICCCM
defines its meaning:

   The client must identify one top level window as the "client leader."
   [...]
   All top-level, non-transient windows created by a client on the same display
   as the client leader must have a WM_CLIENT_LEADER property.

http://tronche.com/gui/x/icccm/sec-5.html

So this is "spawned by the same command" (or perhaps more like "windows which
belong to the same process").

Cheers,
Uli
-- 
"Every once in a while, declare peace. It confuses the hell out of your enemies"
 - 79th Rule of Acquisition

-- 
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.