Alexander Yakushev | 3 Apr 02:02 2012
Picon

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

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

Денис | 4 Apr 08:42 2012
Picon

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.

Javier Barroso | 4 Apr 19:13 2012
Picon

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

Uli Schlachter | 4 Apr 23:17 2012
Picon

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

-- 
(Continue reading)

Julien Danjou | 5 Apr 09:57 2012

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

On Wed, Apr 04 2012, Uli Schlachter wrote:

> 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

(Continue reading)

Zsolt Udvari | 5 Apr 10:41 2012
Picon

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

ali.mousavi@gmail.com | 5 Apr 15:57 2012
Picon

Re: Setting keyboard layout per client

ali.mousavi, don't you use Debian Wheezy? Some days ago I've got a strange issue with old configs for keyboard layout changing on Wheezy.

Sorry for answering so much late, I must have missed this email somehow. I'm using Arch linux, my guess is that these packages are a little buggy with the new systems and probably nobody cares that much to fix them. :)
 
W Wlourf | 6 Apr 10:07 2012
Picon

rules for Gimp-dock windows

Hi all,


I have a 3-monitors configuration and whith Gimp, I can't set the position of  the "Layer Dock" where I wan't (on the second screen). With this code it works with the Toolbox window but not with the "Layers windows" :

    { rule = { name = "Toolbox" },
        properties = {
            tag = tags[2][4],
            floating = true,
            switchtotag = true,
            x = 400,
            y = 100,
            width = 250,
            ontop=true
       
        }
    },
  
        { rule = { name = "Layers" },
        properties = {
            tag = tags[2][4],
            floating = true,
            switchtotag = true,
            x = 600,
            y= 100,
            width = 250,
            ontop=true
        }
    } ,
   
    { rule = { name = "GNU Image Manipulation Program"},
        properties = {
        tag = tags[3][4]  ,
        floating = true,
        switchtotag = true,
        }
    }


In Gimp's Preferences, I set the hint for the toolbox and for the docks to "Normal window" but when I run xprop :
on the toolbox , I get this :
WM_WINDOW_ROLE(STRING) = "gimp-toolbox"
on the layer window, I get this :
WM_WINDOW_ROLE(STRING) = "gimp-dock"

Any help is welcome !

Thanks
Uli Schlachter | 7 Apr 14:14 2012
Picon

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.

basilio | 7 Apr 22:41 2012
Picon

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.


Gmane