Re: [ANN] Definitely Awesome - the latest news about awesome wm

Awesome Weekly #6 is out: 
http://definitely-awesome.posterous.com/awesome-weekly-6

Wibox not responds

Hello to all!

Not long ago my panel with widgets (except tray) after some clicks on it, for example on tags, becomes
insensitive for clicks. Taglist, tasklists and textclock don't reacts when I click on it. After change
tag with keyboard it like resets and situation repeats again. What's happened? Recently all was ok! With
default rc.lua situation is similar. Where I can find any logs? If I start awesome with
startx command nothing is put out in tty1.

Thanks! 
Denis Speranskiy.

Re: Using remote display as screen in awesome ?

Well, ... my reporting ...

On Wed, Mar 21, 2012 at 5:18 PM, Javier Barroso <javibarroso <at> gmail.com> wrote:
> Hi,
>
> I have 2 computers, each with a screen and a graphics card. I would
> like to use the second computer only like an graphic card + screen, so
> I can work with only one keyboard and one mouse which are connected to
> the first computer, and I would like to awesome view two screens (one
> local and one remote)
>
> Of course second computer, I will use though ssh ...
>
> I will take a look to xdmx project (inside Xorg), but I'm afraid it
> would not work (I will post if I success with it), maybe I will have
> to use that in combination with synergy (or not, I'm not sure)
>
> Other possibility is starting awesome with DISPLAY=xxx:0 where xxx is
> the ip of the second computer, using synergy to use only one keyboard,
> but doing that I lose the possibility of change windows from one
> screen to other, and I'm not sure If I can run both awesome instances
> (I think this should not be a problem, but who knows ?)
>
> So, any advice ?
>
> Thanks !!
Hi,

Finally I tried various mode, but no one convince me, lets call B to
the second computer (remote), and A to the local:

Spawning processes, handling their output non-blocking and separated by stdout/stderr

Hi list,

people occasionally complain about awesome awesome.spawn() (and the wrappers
awful.util.spawn() and spawn_with_shell()). They want more control over the
argument array that is passed to the new process. They want to handle stdout and
stderr individually. They want all of this to be non-blocking, so that their WM
doesn't freeze. They want the child's exist code.

And the coder heard their complaints. But he didn't want to write any code. So
he asked the almighty Google. Anyway, attached is a sample program which does
all of the above. This needs lua-ev[0] and luaposix[1]. lua-ev handles the
non-blocking part (and accidentally integrates with awesome's main loop) while
luaposix let's us set up pipes, fork and execute a process.

Actually, I lied. To make lua-ev work with awesome, it needs a simple patch[2].
However, I hope that gets resolved eventually.

So now that I mentioned this, let's see what cool stuff you come up with.
Actually, I write this mail mostly as a reminder to myself, but whatever.

Cheers,
Uli

P.S.: Yes, POSIX is not trivial, nor is libev. So what? :-P

[0] https://github.com/brimworks/lua-ev
[1] https://github.com/rrthomas/luaposix
[2]
https://github.com/psychon/lua-ev/commit/7580fb759b8664f6598199eed4ac0c9d70c4352c
--

-- 

Re: Spawning processes, handling their output non-blocking and separated by stdout/stderr

Hi list!

I've wrote a wiki-article about this two months ago:
http://awesome.naquadah.org/wiki/Run_commands_in_background
It isn't so professional solution but it works in simple cases.

Maybe you can write your solution to wiki ;) Two solutions is more than one.

Cheers,
  Zsolt

2012/4/4 Uli Schlachter <psychon <at> znc.in>:
> Hi list,
>
> people occasionally complain about awesome awesome.spawn() (and the wrappers
> awful.util.spawn() and spawn_with_shell()). They want more control over the
> argument array that is passed to the new process. They want to handle stdout and
> stderr individually. They want all of this to be non-blocking, so that their WM
> doesn't freeze. They want the child's exist code.
>
> And the coder heard their complaints. But he didn't want to write any code. So
> he asked the almighty Google. Anyway, attached is a sample program which does
> all of the above. This needs lua-ev[0] and luaposix[1]. lua-ev handles the
> non-blocking part (and accidentally integrates with awesome's main loop) while
> luaposix let's us set up pipes, fork and execute a process.
>
> Actually, I lied. To make lua-ev work with awesome, it needs a simple patch[2].
> However, I hope that gets resolved eventually.
>
> So now that I mentioned this, let's see what cool stuff you come up with.

Re: Setting keyboard layout per client

rules for Gimp-dock windows

Re: Focus Issue

On 22.03.2012 14:55, Can Altıparmak wrote:
> Uli,
> 
> FreeMind 0.9 :
> 		Client accepts input or input focus: False
> WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS
> 
> Jdownloader 0.9.581:
> 		Client accepts input or input focus: False
> WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS
> 
> full paste: http://paste.pocoo.org/show/569489/
> 
> I guess both using globally active model and yes it might be the same problem.
> On awesome 3.4.11 with java version "1.7.0"

Sorry that I am so slow at replying. Also sorry for the half-bad news:

This will be fixed in 3.5.0, but the 3.4 branch will have to live with this bug.
The problem happens with every client which has the following in its WM_HINTS:
Client accepts input or input focus: False

(Technical detail: In client.c, function client_focus(), client_focus_update()
is only called if the above is not set to false)

Uli

P.S.: This was FS#800
http://awesome.naquadah.org/bugs/index.php?do=details&task_id=800
-- 
- 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-unsubscribe <at> naquadah.org.

Cups/Num Lock change event

Hi to all!

Is there a way to trace Cups/Num lock change event from rc.lua?
(Other than awful.key({ }, "Caps_Lock", ))
I need that for triggering update of the widget with Cups & Num locks
state. Thanks ahead.

Awesome with Avant Window Navigator

I'm running awesome wm with avant window navigator set to "Window dodge" mode,
but it is not behaving exactly the way it should.  

Here is what happens:

When I start avant, everything works fine.  It will appear when I move my mouse
over it, even when it is obscured by a window.  Once I click on any window,
avant no longer pops up when it should.  If I then click on the avant bar, it
will behave normally again until I click on another window.

Is there a few lines I can add to my rc.lua to make it work right?