awesome | 10 Dec 07:54 2014

[awesome bugs] #1309 - Crossover/WINWORD.exe is invisible

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task has a new comment added:

FS#1309 - Crossover/WINWORD.exe is invisible
User who did this - Oleksii Shevchuk (alxchk)

----------
Magically all works on the latest git (v3.5.2-225-g30b313f)
----------

More information can be found at the following URL:
https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1309#comment4204

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you
did not expect this message or don't want to receive mails in future, you can change your notification
settings at the URL shown above.

awesome | 7 Dec 14:18 2014

[awesome bugs] #1312 - Initial fullscreen with mpv not working

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task is now closed:

FS#1312 - Initial fullscreen with mpv not working
User who did this - Uli Schlachter (psychon)

Reason for closing: Not a bug
More information can be found at the following URL:
https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1312

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you
did not expect this message or don't want to receive mails in future, you can change your notification
settings at the URL shown above.

awesome | 7 Dec 14:17 2014

[awesome bugs] #1297 - Add support for XCB_ICCCM_WM_HINT_ICON_PIXMAP

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task is now closed:

FS#1297 - Add support for XCB_ICCCM_WM_HINT_ICON_PIXMAP
User who did this - Uli Schlachter (psychon)

Reason for closing: Fixed
Additional comments about closing: commit 30b313f77a4a3986e36e2a22d5ce65eaab3b7a0f
Author: Uli Schlachter <psychon <at> znc.in>
Date:   Sun Dec 7 14:09:35 2014 +0100

    Implement icon_pixmap and icon_mask from WM_HINTS (FS#1297)

    Fun fact: ICCCM specifies that icon_pixmap must have depth 1. Xterm uses a
    pixmap with depth 24. Yay... As such, I don't have any test for the depth == 1
    case and will just assume that it does the right thing. If it doesn't, I bet no
    one will notice anyway.

    Signed-off-by: Uli Schlachter <psychon <at> znc.in

More information can be found at the following URL:
https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1297

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you
did not expect this message or don't want to receive mails in future, you can change your notification
settings at the URL shown above.

awesome | 7 Dec 13:59 2014

[awesome bugs] #1312 - Initial fullscreen with mpv not working

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task has a new comment added:

FS#1312 - Initial fullscreen with mpv not working
User who did this - Sven Greiner (SammysHP)

----------
Ooops… it is related to a manage signal handler that I've added some time ago. That's embarrassing. :/
----------

More information can be found at the following URL:
https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1312#comment4203

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you
did not expect this message or don't want to receive mails in future, you can change your notification
settings at the URL shown above.

awesome | 7 Dec 13:36 2014

[awesome bugs] #1312 - Initial fullscreen with mpv not working

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task has a new comment added:

FS#1312 - Initial fullscreen with mpv not working
User who did this - Sven Greiner (SammysHP)

----------
PS: I've tested it with all possible outputs.
----------

More information can be found at the following URL:
https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1312#comment4202

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you
did not expect this message or don't want to receive mails in future, you can change your notification
settings at the URL shown above.

awesome | 7 Dec 13:34 2014

[awesome bugs] #1312 - Initial fullscreen with mpv not working

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task has a new comment added:

FS#1312 - Initial fullscreen with mpv not working
User who did this - Sven Greiner (SammysHP)

----------
Yes, mplayer works fine, but mpv does not.
----------

More information can be found at the following URL:
https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1312#comment4201

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you
did not expect this message or don't want to receive mails in future, you can change your notification
settings at the URL shown above.

awesome | 7 Dec 12:00 2014

[awesome bugs] #1271 - Placment rule for xcalc only obeyed some times

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task has a new comment added:

FS#1271 - Placment rule for xcalc only obeyed some times
User who did this - Uli Schlachter (psychon)

----------
This is due to pairs() iterating tables in "some" order. I added print(c,"applying property", property)
to the "inner loop" in awful.rules.execute and the result is:

window/client(Calculator): 0x1bc1a78	applying property	buttons
window/client(Calculator): 0x1bc1a78	applying property	raise
window/client(Calculator): 0x1bc1a78	applying property	y
window/client(Calculator): 0x1bc1a78	applying property	x
window/client(Calculator): 0x1bc1a78	applying property	focus
window/client(Calculator): 0x1bc1a78	applying property	keys
window/client(Calculator): 0x1bc1a78	applying property	floating
window/client(Calculator): 0x1bc1a78	applying property	border_width
window/client(Calculator): 0x1bc1a78	applying property	border_color

So x/y are applied before xcalc is made floating.

I wonder... why don't we lazily arrange clients, just like wiboxes are redrawn lazily...?
----------

More information can be found at the following URL:
https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1271#comment4200

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you
(Continue reading)

awesome | 6 Dec 20:19 2014

[awesome bugs] #1296 - Updated signal causes total relayout (Attachment added)

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task has a new comment added:

FS#1296 - Updated signal causes total relayout
User who did this - Uli Schlachter (psychon)

----------
TL;DR: I'd be interested in suggestions for the API.

Once again, here is a new version (mostly bugfixes). And once again, here is the API that a widget can implement:

- widget:fit(width, height): As before, given a space of width x height, this widget should return its
desired width and height
- widget:draw(wibox, cr, width, height): As before, the widget should draw itself on the cairo context cr
in the are from (0, 0) having size (width, height)
- widget:before_draw_children(wibox, cr, width, height) and widget:after_draw_children(wibox, cr,
width, height): These are called before/after children are painted. before_draw_children is
basically the same thing as draw and exists just for consistency. Here the widget can e.g. call
cr:set_source_rgb(0,1,0) to influence its children. And after_draw_children() could be used for...
things. Someone will come up with a use! ;-)
- widget:layout(width, height): This returns the layout of the children of the widget. This should return
a list of widget placements. Such a placement can be generated via base.place_widget(widget, matrix,
width, height) where Matrix is a cairo matrix that describes placement and rotation of the widget inside
of its parent's area. Most commonly such a matrix should come from
require("lgi").cairo.Matrix.create_translate(x, y) to place a widget at (x, y).

In contrast to the current area, none of these callbacks are recursive / should call other widgets. The
wibox code does all of that for us.
If a widget needs to be redrawn, but neither its :fit() nor :layout() changed, then it should emit widget::redraw_needed.
(Continue reading)

awesome | 5 Dec 18:44 2014

[awesome bugs] #1030 - Wine floating windows move to the right&down by themselves

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task has a new comment added:

FS#1030 - Wine floating windows move to the right&down by themselves
User who did this - Uli Schlachter (psychon)

----------
This really should be fixed with the following commit, but blueyed claims it isn't for him. Here my urxvt no
longer moves around, while for him it still does. At least wine seems to be fixed. Weird...

What do other say? Can this bug be closed?

commit f0ab2aebebfaa391de3efdc9598e5fb23a52e483
Author: Uli Schlachter <psychon <at> znc.in>
Date:   Fri Dec 5 18:40:06 2014 +0100

    Don't move clients on ConfigureRequests (FS#1030)

    I never saw a single program that set a border on its own windows. However,
    awesome commonly sets borders on its clients and the position of a client is the
    part outside of the border. So when processing a position request from a client,
    we also have to include this border and fix things up correspondingly.

    However, the same isn't needed for the client size, because the size does not
    include the borders, but just the titlebar plus the "real" client content.

    Thanks to Daniel Hahler for providing a simple test case based on urxvt for
    debugging this!

(Continue reading)

awesome | 4 Dec 19:01 2014

[awesome bugs] #1299 - MyPaint (GTK3/git version) cannot be fullscreened.

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task is now closed:

FS#1299 - MyPaint (GTK3/git version) cannot be fullscreened.
User who did this - Uli Schlachter (psychon)

Reason for closing: Not a bug
More information can be found at the following URL:
https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1299

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you
did not expect this message or don't want to receive mails in future, you can change your notification
settings at the URL shown above.

awesome | 4 Dec 18:52 2014

[awesome bugs] #1311 - awful.util.spawn crashes during startup, works fine afterwards

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task has a new comment added:

FS#1311 - awful.util.spawn crashes during startup, works fine afterwards
User who did this - Uli Schlachter (psychon)

----------
Your error message does not come from awesome. That is Xlib's default error handler complaining about a
BadWindow error. Also, no idea what the difference between echo and yes would be...

Why do you claim that awesome crashes? Can you provide a backtrace of the crash? What does your
/var/log/Xorg.0.log look like after this? Did perhaps your X server crash? (although awesome would
print an error message saying "X server connection broke (error <some number>)" in that case...)
----------

More information can be found at the following URL:
https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1311#comment4197

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you
did not expect this message or don't want to receive mails in future, you can change your notification
settings at the URL shown above.


Gmane