awesome | 24 Oct 21:21 2014

[awesome bugs] #1308 - Menubar - missing horizontal scrolling

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

A new Flyspray task has been opened.  Details are below. 

User who did this - Miloslav Nenadal (nenadalm) 

Attached to Project - awesome
Summary - Menubar - missing horizontal scrolling
Task Type - Bug Report
Category - Core
Status - Unconfirmed
Assigned To - 
Operating System - Linux
Severity - Low
Priority - Normal
Reported Version - 3.5.5
Due in Version - Undecided
Due Date - Undecided
Details - There is no vertical scrolling so I can't go through all installed applications (only these which
fit into first "page" of the menubar)

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

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 | 22 Oct 09:11 2014

[awesome bugs] #1307 - connecting mouse::* signals don't work on awful.menu

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

A new Flyspray task has been opened.  Details are below. 

User who did this - J Y (razamatan) 

Attached to Project - awesome
Summary - connecting mouse::* signals don't work on awful.menu 
Task Type - Bug Report
Category - awful
Status - Unconfirmed
Assigned To - 
Operating System - Linux
Severity - Medium
Priority - Normal
Reported Version - 3.5.5
Due in Version - Undecided
Due Date - Undecided
Details - mymainmenu = awful.menu({ items = {
   { "terminal", terminal, icon_dir .. 'scalable/apps/gnome-terminal.svg' },
   { "browser", browser, icon_dir .. 'scalable/apps/web-browser.svg' },
   { "awesome", myawesomemenu, beautiful.awesome_icon },
}})
mymainmenu:connect_signal("mouse::leave", function() mymainmenu:hide() end)

also characterized by:

http://comments.gmane.org/gmane.comp.window-managers.awesome/9721

i also tried connecting the mouse::enter signal, too and it fails
(Continue reading)

awesome | 18 Oct 21:42 2014

[awesome bugs] #1233 - Some signal for titlebar sizes

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task is now closed:

FS#1233 - Some signal for titlebar sizes
User who did this - Uli Schlachter (psychon)

Reason for closing: Implemented
Additional comments about closing: commit daeb9aee19285e19784d7a221fef3caf3b51701d
Author: Uli Schlachter <psychon <at> znc.in>
Date:   Sat Oct 18 21:41:38 2014 +0200

    Add signals for titlebar resizes (FS#1233)

    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=1233

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 | 18 Oct 06:42 2014

[awesome bugs] #1306 - Postpone/block layout (re)arrangement during applying of awful.rules / manage signal

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

A new Flyspray task has been opened.  Details are below. 

User who did this - Daniel Hahler (blueyed) 

Attached to Project - awesome
Summary - Postpone/block layout (re)arrangement during applying of awful.rules / manage signal
Task Type - Bug Report
Category - Core
Status - Unconfirmed
Assigned To - 
Operating System - All
Severity - Medium
Priority - Normal
Reported Version - git/master
Due in Version - Undecided
Due Date - Undecided
Details - Could the layout (re-)arrangement get postponed during the execution of the "manage" hook?

I have just debugged an issue with my config, where starting a new client that was set to floating in a
function connected to the manage signal (after awful.rules.apply) caused screen/layout flickering.

Setup:
1. tile layout
2. one master client
3. start a new client, which gets set to floating through a custom "manage" signal handler

There were quite a lot of calls to arrange/do_tile and the number of master and other windows changed
inbetween them.
(Continue reading)

awesome | 15 Oct 23:44 2014

[awesome bugs] #1301 - Failures with "make test" / do not use "test" target by default

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task is now closed:

FS#1301 - Failures with "make test" / do not use "test" target by default
User who did this - Uli Schlachter (psychon)

Reason for closing: Fixed
Additional comments about closing: commit cf9db056f957f26b9b63c67b61568e36bbd01c66
Author: Uli Schlachter <psychon <at> znc.in>
Date:   Wed Oct 15 23:42:24 2014 +0200

    gears.color spec: Don't depend on order of pairs() (FS#1301)

    The previous code assumed that pairs() iterates over the table in a specific
    order which is not a safe assumption.

    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=1301

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 | 15 Oct 16:17 2014

[awesome bugs] #1301 - Failures with "make test" / do not use "test" target by default

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task has a new comment added:

FS#1301 - Failures with "make test" / do not use "test" target by default
User who did this - Daniel Hahler (blueyed)

----------
Yes, this patch fixes the failures.

Thanks!
----------

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

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 | 14 Oct 16:17 2014

[awesome bugs] #1296 - Updated signal causes total relayout

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 - Emmanuel Lepage Vallee (Elv13)

----------
The minus-pixel/over pixel would work, however if region A is painted over by region B, then if region A is
repainted, how is region B noticed? (random thought, I didn't look at the implementation). It currently
work because the paint order is very predictable.

As for the scroll, I guess you meant surface, not wibox. In that case the redraw code still need to take into
consideration what is visible and what is not, so it can only partially work.
----------

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

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 | 14 Oct 15:46 2014

[awesome bugs] #1296 - Updated signal causes total relayout

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)

----------
Ok, glad that I seem to make sense and that you understand me.
However, I don't feel like I understand your proposal, sorry. (How do widgets claim arbitrary space on the
screen? How important is the BVH tree to your implementation?)

What "feels" importing to me is that layouts/magic like we have them currently are possible:

- The background (through explicitly drawing something) and foreground (by setting the cairo context's
source) can be controlled for other widgets.
- Widgets can be rotated and scaled (and currently an arbitrary transformation is possible, although that
might not be all that important/useful).

Take your time to come up with some proof of concept, perhaps I'll understand better then. No hurry.
----------

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

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.

(Continue reading)

awesome | 14 Oct 15:39 2014

[awesome bugs] #1296 - Updated signal causes total relayout

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 - Vlad Leberstein (owl)

----------
Psychon, I understand your approach and its limitations. Thats why I believe we should decide now if widget
should be allowed to draw anywhere it wants because the whole GUI implementation heavily depends on this
decision. I already described the way multi-region widget system can be implemented IMO, but didn't have
time to do it yet. I'll try to show the working proof-of-concept at the end of the week.
----------

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

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 | 14 Oct 11:00 2014

[awesome bugs] #1296 - Updated signal causes total relayout

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)

----------
The area outside of the "dirty_area" in my code is not redrawn at all. So if a widget unsets the clip and draws a
shadow outside of the dirty_area, the shadow won't be drawn on the background color, but ontop of the
previous shadow. So on each redraw the shadow would become darker and darker.
(but now I wonder what would happen if a layout places a widget outside of its own area. The dirty_area would
be updated correctly and I wonder if the clipping would also Do The Right Thing(tm) for the shadows. Could
this be a good idea for implementing this? What I mean exactly: The layout returns 10, 10 for :fit(), but
places a widget from -5,-5 with size 20, 20 in :layout(). This could actually work, right?)

Elv13: Do you want a clever scrolling layout or something similar to what is implemented in FS#1218? IMO a
clever scrolling layout would make itself incompatible with the systray and use something like an
"invisible wibox" where it draws its child to. In its own :draw() method it would then just copy the right
part of that "invisible wibox" over.
That's the best implementation I can think of after thinking about it for 0.5 seconds. Something like "real
scrolling" where it moves the already-drawn part and redraws the rest might be a lot harder to implement
and I'm not sure if it is worth it.
----------

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

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
(Continue reading)

awesome | 14 Oct 10:02 2014

[awesome bugs] #1295 - Menubar doesn't adapt width to different screen widths

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task has a new comment added:

FS#1295 - Menubar doesn't adapt width to different screen widths
User who did this - yauhen (actionless)

----------
 <at> tuusjr, does it reproduces when u're not assigning anything to `menubar.geometry.width `?
----------

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

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