Abraham Baker | 4 Feb 03:02 2016

Re: Naughty Notifications on multiple monitors

Just in case anyone finds this interesting/useful:
After updating to awesome v3.5.8, I had to re-remove the .id from line 600 of naughty.lua to avoid the error I got before.

Re-removing the .id returned the notification behavior to the way it was, which works really well!

Abe

On Fri, Jun 5, 2015 at 11:58 AM, Abraham Baker <z1693060 <at> students.niu.edu> wrote:
Hi,

Changing naughty.lua:600 to
local id = naughty.notify(args) --no .id
results in notifications on all screens + no error! Thanks!

So, for clarification, my naughy.lua now looks like this on line 600:
local id = naughty.notify(args)

and my rc.lua looks like this where the local naughty module is defined:
local naughty = require("naughty")
naughty.notify_ = naughty.notify
naughty.notify = function (args,...)
   for i = 1, screen.count() do
       args.screen = i
       naughty.notify_(args,...)
   end
end

<at> David: removing the .id part in naughty.lua:600 is necessary to prevent the error that happens when not trying to deal with keeping the id's in a table (which is what Alexis was suggesting). If I understand it correctly, if you want to be able to change the same notification without creating a new one, you have to manage the id's.

e.g. without managing id's, changing the backlight from 0 to 100% might result in 100 1% notifications piling up!

However, since I don't use high-frequency notifications on my desktop, I can ignore the need for notification id's for now.

Thanks everyone!
Abe

On Fri, Jun 5, 2015 at 8:31 AM, David Sorkovsky <DavidSorkovsky <at> hotmail.com> wrote:

 

Of I understand the…

 

local naughty = require("naughty")
naughty.notify_ = naughty.notify
naughty.notify = function (args,...)
   for i = 1, screen.count() do
       args.screen = i
       naughty.notify_(args,...)
   end
end

 

 

… code correctly, would you even need to modify naughty.lua?

 

 

Regards

 

Dave

 

From: Alexis BRENON [mailto:brenon.alexis <at> gmail.com]
Sent: Friday, 5 June 2015 11:07 PM
To: Abraham Baker
Cc: Elv1313 .; awesome
Subject: Re: Naughty Notifications on multiple monitors

 

Instead of hidding the error just replace line 600 from:
local id = naughty.notify(args).id

to

naughty.notify(args)

 

You don't need the id any more if you don't use it. This way, no more error.

Le ven. 5 juin 2015 à 14:57, Abraham Baker <z1693060 <at> students.niu.edu> a écrit :

Hi,

My goal is to get every notification to show up on all monitors.  This isn't critical; it just makes switching between standing/sitting easier. 


I don't use often-updating notifications, so I (for now) don't care about the notification id's.  So, I'm thinking Elv1313's solution + hiding the naughty.lua:600 error would be enough.

 

The relevant part of my rc.lua:

-- Standard awesome library
local gears = require("gears")
local awful = require("awful")
awful.rules = require("awful.rules")
require("awful.autofocus")
-- Widget and layout library
local wibox = require("wibox")
-- Theme handling library
local beautiful = require("beautiful")
-- Notification library


local naughty = require("naughty")
naughty.notify_ = naughty.notify
naughty.notify = function (args,...)
   for i = 1, screen.count() do
       args.screen = i
       naughty.notify_(args,...)
   end
end

local menubar = require("menubar")
local revelation=require("revelation")
-- {{{ Error handling
-- Check if awesome encountered an error during startup and fell back to
-- another config (This code will only ever execute for the fallback config)
if awesome.startup_errors then
    naughty.notify({ preset = naughty.config.presets.critical,
                     title = "Oops, there were errors during startup!",
                     text = awesome.startup_errors })
end

-- Handle runtime errors after startup
do
    local in_error = false
    awesome.connect_signal("debug::error", function (err)
        -- Make sure we don't go into an endless error loop
        if in_error then return end
        in_error = true

        naughty.notify({ preset = naughty.config.presets.critical,
                         title = "Oops, an error happened!",
                         text = err })
        in_error = false
    end)
end
-- }}}

The relevant part of naughty.lua (the only part changed from default):
local id = naughty.notify(args).id
            return "u", id
--local notifs = naughty.notify(args)
--local id = {}
--for notif in ipairs(notifs) do
--  id:insert(notif.id)
--end

Thanks,

Abe

 

On Fri, Jun 5, 2015 at 2:22 AM, Alexis BRENON <brenon.alexis <at> gmail.com> wrote:

Hi Abraham,

I'm sorry, I don't understand what and when did commented out ?

Can you please post your config file on pastebin (http://pastebin.com/) or something like that (github?).

 

To fix the error about 'insert' method, you can replace the line :

notifications:insert(i, naughty.notify_(args,...))

by

table.insert(notifications, i, naughty.notify)

 

Maybe you will have also to cheat a little bit if i doesn't start to 1...

 

Maybe I can explain you a little deeper what are the goals, this way you will be able to debug yourself.

 

So, you want to have your notifications displayed on many screens (the exact number is not important).

To do so, you have to redefine the classic naughty.notify function, to call the initial naughty.notify function with the screen arg which loop over all your screen. This is what is done by the code sent by Elv1313.

 

Nevertheless, the initial notify function returns a table representing the notification, containing for example an ID (the id field). If you don't need it, so fine, stick to the Elv1313 solution and remove any naughty.notify(...).id code in your config.

But this ID can be useful if you need to replace a notification instead of adding a new one (this can be the case if you use notification to display volume changement, backlight modification, battery alert, whatever).

To handle this, your new notify function must return the created notifications, or at least their ID.

This is what my code intend to do. For each call to the initial notify function, I put the resulting table in a 'result' table, indexed by the index of the screen on which the notification is displayed. Up to ypu after to use it the right way.

 

The last chunk of code I sent you, handle the case where you want to use the replaces_id argument of notify. As, in your case, you will have not only one, but many notifications to replace (one on each screen), you will pass the replaces_id argument as a table. This is not handled by the initial notify function, so for the actual call you use the value at the index representing your screen, as we do for the 'screen' arg.

 

I hope the reasonning is clear.

 

Alexis

 

Le ven. 5 juin 2015 à 05:13, Abraham Baker <z1693060 <at> students.niu.edu> a écrit :

Hi,

When I commented out 600 and 601 of naughty.lua before changing rc.lua, I got:

naughty.lua:604: bad arg #1 to 'ipairs' (table expected, got nil)

on both screens.

 

Then, when I added the updated naughy.notify function to rc.lua, I got:

rc.lua:22 attempt to call a nil value (method 'insert')

on only one screen

Ironically, the previous solution would work perfectly if it wasn't for the error messages (which are critical and have to be clicked away)!

Is there a way to selectively silence the error messages related to naughty.lua without silencing all errors?

Thanks,

Abe

 

 

On Thu, Jun 4, 2015 at 2:08 AM, Alexis BRENON <brenon.alexis <at> gmail.com> wrote:

Hum, well, you will have to update a little bit your config!

First, the default naughty.notify function returns a table representing the notification, but your new notify function doesn't, so update it :

 

naughty.notify_ = naughty.notify

naughty.notify = function (args,...)

  notifications = {}

   for i = 1, screen.count() do

       args.screen = i

       notifications:insert(i, naughty.notify_(args,...))

   end

   return notifications

end

 

Then line 600 you update to something like :

local notifs = naughty.notify(args)

local id = {}

for notif in ipairs(notifs) do

  id:insert(notif.id)

end

 

Nevertheless, I think that you use the id value to replace the notification, do you ? In this case, you will have to update again your custom notification to handle the case if args.id is a table (instead of a number) :

 

naughty.notify = function (args,...)

   notifications = {}

   naughty_args = args

   for i = 1, screen.count() do

       if args.replaces_id and type(args.replaces_id) == "table" then

          naughty_args.replaces_id = args.replaces_id[i]

       end

       naughty_args.screen = i

       notifications:insert(i, naughty.notify_(args,...))

   end

   return notifications

end

 

Or something like that.

 

Cheers,

Alexis

 

Le mer. 3 juin 2015 à 22:30, Abraham Baker <z1693060 <at> students.niu.edu> a écrit :

That actually works, but also generates an error (in the form of a critical notification on both screens) at the same time:

/usr/share/awesome/lib/naughty.lua:600: attempt to index a nil value

For context, line 600 is:
local id = naughty.notify(args).id

Looks like this is close to working right! Thanks!

 

On Wed, Jun 3, 2015 at 2:24 PM, Elv1313 . <elv1313 <at> gmail.com> wrote:

This should help:

local naughty = require('naughty')
naughty.notify_ = naughty.notify
naughty.notify = function (args,...)
   for i = 1, screen.count() do
       args.screen = i
       naughty.notify_(args,...)
   end
end


On 3 June 2015 at 10:42, Abraham Baker <z1693060 <at> students.niu.edu> wrote:
> I tried adding that code right after the local naughty = require("naughty")
> that was already there, but it didn't work and actually stopped any
> notifications from showing on any monitor.
>
> I doubt it was the cause, but some other functions in my rc.lua also use
> local i as a counter;  these shouldn't interfere with each other as long as
> they are inside their own functions, right?
>
> Thanks,
> Abe
>
> On Wed, Jun 3, 2015 at 8:20 AM, Alexis BRENON <brenon.alexis <at> gmail.com>
> wrote:
>>
>> Hi Abraham,
>>
>> you have to call the anughty.notift() function twice, once for each
>> screen.
>> Maybe you can define a function which do it for you :
>>
>> local naughty = require('naughty')
>> naughty.notify = function (args)
>> local i = 1
>> while i <= screen.count() do
>>     args.screen = i
>>     naughty.notify(args)
>> end
>> end
>>
>> Or something like that
>>
>> Regards,
>> Alexis
>>
>> Le mer. 3 juin 2015 à 15:13, Abraham Baker <z1693060 <at> students.niu.edu> a
>> écrit :
>>>
>>> Hi,
>>>
>>> I have a standing/sitting monitor arrangement on my desk that makes it
>>> hard to see notifications on the upper monitor while sitting and vice versa.
>>> I've been trying to change the default naughty config so notifications
>>> appear on both monitors at once, but so far I'm only able to just change
>>> which monitor it shows up on (not both).
>>>
>>> Is there an easy way to have notifications shown on all monitors?
>>>
>>> Thanks,
>>> Abe Baker
>
>

 

 

 



Antonio Marín | 2 Feb 16:45 2016
Picon

Re: My problems with the last version

Thanks.
I was using xcompmgr. That was the problem. I have my arch always up to date. But for some reason xcompmgr it's breaking all now. I'!! try compton maybe... but it does not matter for me!
Solved!

2016-02-02 15:02 GMT+01:00 Cayetano Santos <csantosb <at> inventati.org>:


On 02-02-16 08:40:45, Maxwell Anselm wrote:

If you're running a compositor such as compton, try disabling it.
On Feb 2, 2016 08:20, "Antonio Marín" <antoniomaring <at> gmail.com> wrote:

Awesome for Arch (x86_64) is my only one window manager... in my home...
in the office.
But the last versions (3.5.7 and 3.5.8, from Arch repository)  give me
problems.
I had to downgrade to 3.5.6 that works perfectly for me.

The problem is when I try to init my X via startx with the last versions.
Someone can help me to solve this little problem?
All seems a xorg configuration problem. But the question is that's all ok
with the 3.5.6 version.

Hi, running up to date arch x86_64, awesome 3.5.8.1 from the repos and compton,
and things are running smoothly for me; have you tried to startx with an empty
rc.lua ?

--

Cayetano Santos



That's a trace  in my Xorg log:

342 [   350.478] (EE)
343 [   350.478] (EE) Backtrace:
344 [   350.478] (EE) 0: /usr/lib/xorg-server/Xorg (OsLookupColor+0x139)
[0x598499]
345 [   350.479] (EE) 1: /usr/lib/libc.so.6 (__restore_rt+0x0)
[0x7fb7ba73b67f]
346 [   350.480] (EE) 2: /usr/lib/libpixman-1.so.0
(pixman_region_fini+0x9) [0x7fb7bb650a69]
347 [   350.480] (EE) 3: /usr/lib/xorg/modules/drivers/intel_drv.so
(_init+0x58576) [0x7fb7b535f336]
348 [   350.480] (EE) 4: /usr/lib/xorg/modules/drivers/intel_drv.so
(_init+0x56141) [0x7fb7b535a3e1]
349 [   350.480] (EE) 5: /usr/lib/xorg-server/Xorg
(DamageRegionAppend+0x621) [0x51c361]
350 [   350.481] (EE) 6: /usr/lib/xorg-server/Xorg (AddTraps+0x40d7)
[0x5159c7]
351 [   350.481] (EE) 7: /usr/lib/xorg-server/Xorg
(SendErrorToClient+0x2df) [0x43626f]
352 [   350.481] (EE) 8: /usr/lib/xorg-server/Xorg
(remove_fs_handlers+0x453) [0x43a293]
353 [   350.481] (EE) 9: /usr/lib/libc.so.6 (__libc_start_main+0xf0)
[0x7fb7ba728610]
354 [   350.482] (EE) 10: /usr/lib/xorg-server/Xorg (_start+0x29)
[0x4245c9]
355 [   350.482] (EE) 11: ? (?+0x29) [0x29]
356 [   350.482] (EE)
357 [   350.482] (EE) Segmentation fault at address 0x0
358 [   350.482] (EE)
359 Fatal server error:
360 [   350.482] (EE) Caught signal 11 (Segmentation fault). Server
aborting
361 [   350.482] (EE)
362 [   350.482] (EE)
363 Please consult the The X.Org Foundation support
364      at http://wiki.x.org
365  for help.
366 [   350.482] (EE) Please also check the log file at ................
for additional information.
367 [   350.482] (EE)
368 [   350.482] (II) AIGLX: Suspending AIGLX clients for VT switch
369 [   350.591] (EE) Server terminated with error (1). Closing log file.

--
Antonio Marín




--
Antonio Marín
Antonio Marín | 2 Feb 14:20 2016
Picon

My problems with the last version

Awesome for Arch (x86_64) is my only one window manager... in my home... in the office. 
But the last versions (3.5.7 and 3.5.8, from Arch repository)  give me problems. 
I had to downgrade to 3.5.6 that works perfectly for me. 

The problem is when I try to init my X via startx with the last versions. 
Someone can help me to solve this little problem?
All seems a xorg configuration problem. But the question is that's all ok with the 3.5.6 version.

That's a trace  in my Xorg log:

342 [   350.478] (EE) 
343 [   350.478] (EE) Backtrace:
344 [   350.478] (EE) 0: /usr/lib/xorg-server/Xorg (OsLookupColor+0x139) [0x598499]
345 [   350.479] (EE) 1: /usr/lib/libc.so.6 (__restore_rt+0x0) [0x7fb7ba73b67f]
346 [   350.480] (EE) 2: /usr/lib/libpixman-1.so.0 (pixman_region_fini+0x9) [0x7fb7bb650a69]
347 [   350.480] (EE) 3: /usr/lib/xorg/modules/drivers/intel_drv.so (_init+0x58576) [0x7fb7b535f336]
348 [   350.480] (EE) 4: /usr/lib/xorg/modules/drivers/intel_drv.so (_init+0x56141) [0x7fb7b535a3e1]
349 [   350.480] (EE) 5: /usr/lib/xorg-server/Xorg (DamageRegionAppend+0x621) [0x51c361]
350 [   350.481] (EE) 6: /usr/lib/xorg-server/Xorg (AddTraps+0x40d7) [0x5159c7]
351 [   350.481] (EE) 7: /usr/lib/xorg-server/Xorg (SendErrorToClient+0x2df) [0x43626f]
352 [   350.481] (EE) 8: /usr/lib/xorg-server/Xorg (remove_fs_handlers+0x453) [0x43a293]
353 [   350.481] (EE) 9: /usr/lib/libc.so.6 (__libc_start_main+0xf0) [0x7fb7ba728610]
354 [   350.482] (EE) 10: /usr/lib/xorg-server/Xorg (_start+0x29) [0x4245c9]
355 [   350.482] (EE) 11: ? (?+0x29) [0x29]
356 [   350.482] (EE) 
357 [   350.482] (EE) Segmentation fault at address 0x0
358 [   350.482] (EE) 
359 Fatal server error:
360 [   350.482] (EE) Caught signal 11 (Segmentation fault). Server aborting
361 [   350.482] (EE)
362 [   350.482] (EE) 
363 Please consult the The X.Org Foundation support
364      at http://wiki.x.org 
365  for help. 
366 [   350.482] (EE) Please also check the log file at ................ for additional information.
367 [   350.482] (EE) 
368 [   350.482] (II) AIGLX: Suspending AIGLX clients for VT switch
369 [   350.591] (EE) Server terminated with error (1). Closing log file.

--
Antonio Marín
Uli Schlachter | 30 Jan 15:04 2016
Picon
Gravatar

[ANNOUNCE] awesome 3.5.8 released


Hi everyone,

it's been two weeks, time for a new release!

Well, to be honest, 3.5.7 had a bug where keyboard bindings stopped working
when the keyboard layout was changed. Sorry for that.

I was considering calling the new release "Oops, I did it again", but in the
end decided against it. :-)

Cheers,
Uli

-- 

awesome version 3.5.8 has been released. It is available from:

tar.xz: http://awesome.naquadah.org/download/awesome-3.5.8.tar.xz
md5: bdca8e1740cd9c5a76bfc46f8d943cf1
sha1: 841ab68e96b8d75e895fcd2ab4956f1a7e82a4f8

tar.bz2: http://awesome.naquadah.org/download/awesome-3.5.8.tar.bz2
md5: 6dc7a60d9c4b30efd3bea4718cb1cd92
sha1: e5a09c7a64ae94bc75ef328be6ea836f74c78203

number of changes
-----------------
3

number of commiters
-------------------
2

shortlog
--------
Uli Schlachter (2):
      Fix window key grabbing
      change codename

Roy Crihfield (1):
      menubar: handle nil Name in .desktop files

diffstat
--------
 awesomeConfig.cmake      | 2 +-
 event.c                  | 4 ++--
 lib/menubar/utils.lua.in | 3 +++
 objects/client.c         | 2 +-
 4 files changed, 7 insertions(+), 4 deletions(-)
Matt Lee | 21 Jan 13:05 2016
Picon
Gravatar

XF86 keys causing client key bindings to disable

Hi All,

I have an issue with my XF86 keys (volume, play/pause, calculator etc)
they appear to disable my client key bindings, by which I mean those
applied via `awful.rules.rules.properties.keys`.

For example I have Alt+F4 bound to client:kill this initially works
fine. If I then press any XF86 key (with an awesome key binding or
not) that key functions as expected, but then Alt+F4 doesn't work, for
clients open before the key was pressed but it works fine for clients
opened after the XF86 key press. Restarting awesome (via
awesome.restart()) resolves the issue, until the next time I press an
XF86 key.

xev doesn't appear to report anything different between the case when
it works and when it doesn't. There are no errors in .xsession-errors.
Because new clients appear to be created fine, I've assumed that it is
an issue with awful.rules, I had a quick look at the lua source code
but was soon out of my depth. But if someone can give me pointers I'm
happy to keep digging!

If it is useful, my awesome config is here:
https://github.com/thatismatt/dotfiles/tree/master/_config/awesome

awesome -v reports:
awesome v3.5.7 (Space Oddity)
 • Build: Jan 18 2016 18:52:30 for x86_64 by gcc version 4.9.2 (buildd <at> lgw01-18)
 • Compiled against Lua 5.1.5 (running with Lua 5.1)
 • D-Bus support: ✔

Thanks to all who contribute to Awesome, I now can't live without it!
Also, I'm new here, so please forgive me if I get the etiquette wrong.
Matt

Alexis BRENON | 19 Jan 11:00 2016
Picon
Gravatar

Naughty notifications with buttons

Hi guys, 


I'm using blueman to transfer file between my laptop and my phone. But blueman display many notifications with buttons:
    To accept pairing
    To accept incoming file
These notifications are displayed with naughty, but I can't click on the buttons... Is there a way to fix this problem? 

Kind regards, Alexis. 
Uli Schlachter | 15 Jan 17:04 2016
Picon
Gravatar

[ANNOUNCE] awesome 3.5.7 released


Hi everyone,

it's been almost exactly a year. A couple of changes occurred in this
time and it's time for them to get a release.

Enjoy!
Uli

-- 

awesome version 3.5.7 has been released. It is available from:

tar.xz: http://awesome.naquadah.org/download/awesome-3.5.7.tar.xz
md5: afab0b57fe0563ae3107d6b84d26f1aa
sha1: d93836272ff367880bff9e51c67716dad51c45a8

tar.bz2: http://awesome.naquadah.org/download/awesome-3.5.7.tar.bz2
md5: 87ff095e54f12b9e1c9573e481d661c5
sha1: f6207a16261e038523d1a9a203b9a6f7ec5b5d32

number of changes
-----------------
31

number of commiters
-------------------
6

shortlog
--------
Uli Schlachter (22):
      Remove titlebars from clients during shutdown (FS#1159)
      a_dbus_message_iter: Handle DBUS_TYPE_DOUBLE
      Ignore more events while minimizing a client
      Screen __index: Don't turn argument into a string
      Keep stacking order across restarts
      Keep client order across restarts
      Force systray redraw on BG color change
      Fix enter/leave events on titlebars
      Fix compilation
      Handle enter/leave events with detail=Inferior correctly
      Never explicitly focus the root window
      Fix client_apply_size_hints()
      Make awesome.quit() during startup work
      Fix obvious typo in xwindow_translate_for_gravity()
      Apply window gravity when a window moves itself
      Refactor code a little
      Apply window gravity for titlebar resizes
      Apply window gravity for border width changes
      Grab client keys on the client window (#496)
      Spawn: Improve handling of startup notification
      objects: Add .valid property (Fixes #110)
      change codename

Daniel Hahler (5):
      tag.lua: add "property::icon_only" signal
      Make stdout/stderr line buffered
      cmake: s/ESCAPE_QUOTE/ESCAPE_QUOTES
      awesome_atexit: keep client order always
      Add .travis.yml from master, ignoring functional tests

Heiko Becker (1):
      awesomeConfig.cmake: Allow setting AWESOME_DATA_DIR

Kazunobu Kuriyama (1):
      Fix the definition of A_STRNEQ_CASE

Kimball Thurston (1):
      Fix focus handling with multiple awesome instances

▟ ▖▟ ▖ (1):
      awful.menu: update t new layout api

diffstat
--------
 .travis.yml           |  66 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 awesome.c             |  84 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---------
 awesomeConfig.cmake   |  12 +++++++++---
 common/atoms.list     |   1 +
 common/luaclass.c     |  13 +++++++++++++
 common/util.h         |   2 +-
 dbus.c                |   1 +
 event.c               | 110 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++------------------------------
 globalconf.h          |   6 ++++++
 lib/awful/menu.lua.in |   4 ++--
 lib/awful/tag.lua.in  |   1 +
 luaa.c                |   2 ++
 luadoc/client.lua     |   1 +
 objects/client.c      |  68 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---------
 objects/window.c      |   4 ++++
 objects/window.h      |   4 +++-
 screen.c              |   2 +-
 spawn.c               |  10 ++++++++--
 systray.c             |  17 +++++++++++++----
 xwindow.c             |   2 +-
 20 files changed, 347 insertions(+), 63 deletions(-)
Dvenum | 28 Dec 06:34 2015
Picon
Gravatar

Teamviewer and awesome on target machine

Hello.

I have a problem with my pc when I connecting to it via teamviewer
(teamviewer.com)
This do no reaction for win key as modkey, Alt and Ctrl.

There is Debian jessie with awesome 3.5 and teamviewer 11.
I'll happy from any advices and guesses, if you please?

--

-- 
dvenum
dvenum.at <at> gmail.com

Greg Bell | 23 Dec 09:08 2015
Picon
Gravatar

Making conky un-minimizable

I have Conky set up much like here: 
http://awesome.naquadah.org/wiki/Conky_HUD

However, when I get window-clutter-overwhelm, I like to hold down Mod4 
+ n and just minimize everybody and start over again.

Problem is, when I get to the desktop, often Conky is up so it gets 
minimized too.  Once that happens the toggle (conky.ontop) doesn't 
work any more.  I have to killall -9 conky, then re-run it.

It has "focusable = false" in the properties, like in the wiki, so I 
would have thought this couldn't happen.

What am I doing wrong?

Many thanks,
Greg

Riccardo Sven Risuleo | 17 Nov 10:25 2015
Picon

Keyboard switches and awesome

Hi all,
I have a problem that has been bugging me for a while,  and I hope somebody knows how to solve it...

I have a keyboard layout switch, set with

setxkbmap -layout us,us -variant dvorak, -option caps:escape,grp:toggle,grp:alts_toggle,grp_led:caps

This will allow me to toggle my layout from us to dvorak by pressing both the alts keys.
This works perfectly, and the keymap switches fine, however all the bindings for awesome do not change. For instance if I move between the clients with 'hjkl' in dvorak mapping, I will move with 'jcvp' in the us mapping. It is like the command is linked to the physical key on the keyboard and not to the character sent...

Does anyone know a solution to this? I have been able to replicate this behaviour on two computers.

Thanks in advance for any comments or suggestions,
Have a splendid day
Rsrsl
Alexander Tsepkov | 10 Oct 04:24 2015
Picon

numpad keys issues

My numpad keys don't seem to be recognized by awesome wm (I've tried using KP_0 through KP_9 - like xev reports) as well as names like KP_HOME, with no effect. Remapping same function to something like modkey +"y" works fine. I'm also confused because I don't see much info about this online aside from a thread or 2 claiming that what I'm doing should work: http://comments.gmane.org/gmane.comp.window-managers.awesome/3101

Here is one example:

    awful.key({ modkey,           }, "KP_1", function (c) naughty.notify({title='foo',text='dd'}) end),


Thanks, here is my version info:

$ awesome -v
awesome v3.5.6 (For Those About To Rock)
 • Build: Jan 14 2015 20:56:29 for x86_64 by gcc version 4.8.2 (buildd <at> lgw01-04)
 • Compiled against Lua 5.1.5 (running with Lua 5.1)
 • D-Bus support: ✔


Gmane