[awesome bugs] #1084 - Input loss, focus loss, black flickering and way to many redraw in awesome 3.5

2013-01-20 Thread awesome
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#1084 - Input loss, focus loss, black flickering and way to many redraw in awesome 3.5 User who did this - Emmanuel Lepage Vallee (Elv13) -- Early tests of the mailing list patch (Uli one) seem to

Re: Wine woes and hacky solution

2013-01-20 Thread Uli Schlachter
On 20.01.2013 18:43, Nikos Ntarmos wrote: > On Sun, Jan 20, 2013 at 10:16:15AM +0100, Uli Schlachter wrote: >> Hi, >> >> On 20.01.2013 02:08, Nikos Ntarmos wrote: >>> Still using the 3.4 branch here and I'm bumping on the well-known issue >>> with clients refusing focus through WM_HINTS and relying

Re: Wine woes and hacky solution

2013-01-20 Thread Nikos Ntarmos
On Sun, Jan 20, 2013 at 10:16:15AM +0100, Uli Schlachter wrote: > Hi, > > On 20.01.2013 02:08, Nikos Ntarmos wrote: > > Still using the 3.4 branch here and I'm bumping on the well-known issue > > with clients refusing focus through WM_HINTS and relying on > > WM_TAKE_FOCUS instead (e.g., several W

Re: [RFC] Remove the focusin xcb handler.

2013-01-20 Thread Uli Schlachter
Hi, welcome to the local X11 self-help group. Please grab a seat and have a cookie. On 20.01.2013 15:50, Stefan Haller wrote: [...] > It seems to me, that awesome is handling all the focus itself but then > there is the focusin-event listener. Probably awesome is switching the > focus very fast (

[RFC] Remove the focusin xcb handler.

2013-01-20 Thread Stefan Haller
Awesome already handles all focus changes explicitely itself. The focusin handler is responsible for a bug where awesome is not able to focus the correct client on fast focus switches (occuring due to sloppy focus). Awesome sets the focus to some clients in a fast sequence and then the xcb focusin

[RFC] Remove the focusin xcb handler.

2013-01-20 Thread Stefan Haller
Hi, there exists a regression in awesome 3.5 (see [1] and maybe [2]): It’s not possible to use sloppy focus to exactly define which window should have the input focus. On fast mouse moves the wrong window is getting the focus. I tried to eliminate the problem and I even found a working solution (a

[PATCH] Raise the window on EWMH request.

2013-01-20 Thread Stefan Haller
Additionally to handing over the focus to the window this commit raises the window too. Otherwise a window which is hidden below other windows can request the focus and because the window is not fully exposed, the user is unaware which window has the input focus and is actually receiving the keystr

[PATCH] Raise the window on EWMH request.

2013-01-20 Thread Stefan Haller
Hi, this is my first patch for awesome, so I hope I’m doing it right. My problem was, than when I click on a link, Firefox is getting the input focus, which is the right thing. The problem is, that Firefox is usually hidden below other windows, because I’m using the fullscreen layout for a worksp

[PATCH 2/2] wibox.widget.textbox: return 0, 0 from fit() if either w or h is 0

2013-01-20 Thread Lukáš Hrázký
A hack around abusing the fact that width of a textbox is 0 when its empty, while it's height is still set according to the font. Signed-off-by: Lukáš Hrázký --- lib/wibox/widget/textbox.lua.in | 5 + 1 file changed, 5 insertions(+) diff --git a/lib/wibox/widget/textbox.lua.in b/lib/wibox/w

[PATCH 1/2] wibox.layout.flex: add set_max_widget_size() function

2013-01-20 Thread Lukáš Hrázký
The function can be used to set the maximum size the widget in the flex layout should take. Signed-off-by: Lukáš Hrázký --- lib/wibox/layout/flex.lua.in | 23 +-- 1 file changed, 21 insertions(+), 2 deletions(-) diff --git a/lib/wibox/layout/flex.lua.in b/lib/wibox/layout/fl

[PATCH] more layout patches

2013-01-20 Thread Lukáš Hrázký
Hi, I'm sending the amended patches. lukash -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.

Re: [PATCH 2/2] wibox.widget.textbox: return 0 height if width is 0 from fit()

2013-01-20 Thread lukash
On Sat, 19 Jan 2013 18:51:27 +0100 Uli Schlachter wrote: > On 19.01.2013 16:06, Lukáš Hrázký wrote: > > A hack around abusing the fact that width of a textbox is 0 when its > > empty, while it's height is still set according to the font. > > > > Signed-off-by: Lukáš Hrázký > > --- > > lib/wibo

Re: Wine woes and hacky solution

2013-01-20 Thread Uli Schlachter
Hi, On 20.01.2013 02:08, Nikos Ntarmos wrote: > Still using the 3.4 branch here and I'm bumping on the well-known issue > with clients refusing focus through WM_HINTS and relying on > WM_TAKE_FOCUS instead (e.g., several Wine applications). I've been > running with the attached diff for some time