THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#821 - xcompmgr and awesome menus
User who did this - Roman Kosenko (kite)
----------
Could we split the _NET_WM_WINDOW_TYPE into a seperate feature-request issue? I
hate mixing stuff.
Ok, I've created new ticket FS#828.
wibox_refresh() is called all the time via awesome_refresh(). So we do draw the
wibox after it was mapped. This got to cause some damage events, I guess.
Ah... This is doing from global loop.
Maybe is damage events generated too fast? If xcompmgr didn't successfully
process MapNotify and it can't properly invalidate window. Let's see, this
works with xcompmgr:
wibox.visibility = false
wibox.screen = screen_index
util.spawn("/bin/sh -c 'sleep .1'", false)
wibox.visibility = true
And this doesn't work:
wibox.visibility = false
wibox.screen = screen_index
wibox.visibility = true
So, this is bug in xcompmgr and can be simply fixed by attached patch
(initially sets 'damaged' flag after MapNotify event). But in any way xcompmgr
contained a lot of other bugs, memory leaks, etc. As I understand this
demonstrate program isn't aimed for every-day use.
So, let's discuss awesome bugs... When each item in menu is separate window any
abstract compositing manager will decorate them separately. This is not what
user want.
Similar problem in titlebar - it is decorated separately from main window.
----------
More information can be found at the following URL:
http://awesome.naquadah.org/bugs/index.php?do=details&task_id=821#comment2392
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.
--
To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
