Modkey release
Hi,
I was wondering what the best way to capture the release of the modkey would be.
Basically (optionally after is pressed) i want an action to be fired
when modkey is released.
So far i've only managed things like (1) adding
awful.key({ }, "Super_L",
function ()
-- only here cos we don't get the release without it
end
),
awful.key({ "Mod4" }, "Super_L",
function () end,
modkey_release_function
)
to the global keys and (2)
awful.key(key_combo,
function ()
keygrabber.run(function (mod, key, event)
if (event == 'release') and (key == 'Super_L') then
keygrabber.stop()
modkey_release_function()
end
return true
end)
end
).
The first solution causes all clientkeys to be ignored, while the second means
that no other modkey+blah keybindings will work until the modkey has been
released. Both suffer from the explicit use of "Super_L" rather than modkey.
I suspect there's a clean solution involving signals, but i don't know how to
do it and haven't had much luck finding out.
Any ideas?
Thanks,
Matt
--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: doubt with mouse screen
> >{ rule = { class = "Chromium.*" , name = ".*Abrir.*" },
> >properties = {tag = tags[mouse.screen][2]}}, -- I use it in spanish
I think this will not work as hoped because it chooses mouse.screen when the
rules are loaded, not dynamically. My fix for this is to do the following:
{ rule = { },
callback = totag(2) },
And elsewhere in rc.lua, define:
function totag(i)
return function (c)
local screentags = screen[mouse.screen]:tags()
c:tags({screentags[i]})
c.screen = mouse.screen
awful.tag.viewonly(screentags[i])
end
end
The line "awful.tag.viewonly(...) is to automatically switch to the right tag,
so delete it if you don't want this behaviour. If you do, you might also find
you need to make sure switchtotag is not set to true by your rules (it causes
some weirdness, but i forget what).
Well, this is my hack anyway :)
Best,
Matt
--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: ontop for floating clients
> > > I believe he wants it to actually be conditional - as in, not set all
> > > clients to floating when created, but to make the client ontop IF it is
> > > floating.
> > a
> > exactly!
>
> You have to use a custom function. Try this instead of
> awful.client.floating.toggle in your keybindings:
>
> function (c)
> awful.client.floating.toggle(c)
> c.above = awful.client.floating.get(c)
> end
Another solution would be to add to
client.add_signal("manage", function (c, startup)
..
end)
in rc.lua the following code:
c.ontop = awful.client.floating.get(c)
c:add_signal("property::floating",
function (c)
c.ontop = awful.client.floating.get(c)
end
)
where the first line will set a client to ontop if it is floating when it is
started, while the second will keep the ontop property in sync with the
floating property if it changes. I'm not sure if both of these are wanted.
Matt
--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: ontop for floating clients
> > Another solution would be to add to
> >
> > client.add_signal("manage", function (c, startup)
> > ..
> > end)
> >
> > in rc.lua the following code:
> >
> > c.ontop = awful.client.floating.get(c)
> >
> > c:add_signal("property::floating",
> > function (c)
> > c.ontop = awful.client.floating.get(c)
> > end
> > )
> >
> > where the first line will set a client to ontop if it is floating when it is
> > started, while the second will keep the ontop property in sync with the
> > floating property if it changes. I'm not sure if both of these are wanted.
>
> As I said in my first post, this does not work here (Awesome 3.4.11)
Ah -- i can't test on 3.4.11 unfortunately, but this solution differs from
your original message, which was:
client.add_signal(
"property::floating",
function(c)
c.ontop=c.floating
end
)
I'm not sure where you put this code, but for my solution, you put it inside
the client.add_signal("manage", function (c, startup)... function (defined by
default in rc.lua). It also calls c:add_signal, rather than client.add_signal,
and uses awful.client.floating.get(c) instead of c.floating (which i don't
think exists).
The call back, however, only gets activated when the floating state changes.
Hence, i put c.ontop = awful.client.floating.get(c) inside the
client.add_signal("manage", function (c, startup)... function too, to set ontop
by the initial value of floating.
Apologies if i'm wasting everyones' time.
Best,
Matt
--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: doubt with mouse screen
> i tried your hack, but it the "open file" window is still raising at > the first screen :( Ah. I just tested my setup with two screens and Chromium, and the open file dialog comes up fine on mouse.screen. Maybe you could post your rules applying to Chromium -- could be something interfering? Best, Matt -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Evince / Key Focus Problems
Hi, I have a problem using Evince with Awesome: when changing tags, often -- but not always -- Evince seems to miss the "focus in" event and won't recognise any key presses until i either + click the window with the mouse, switch to another window and switch back, or + place the mouse over the window and execute the lua code client.focus = client.focus . I'm not sure whether this is an Awesome issue, an Evince issue, or a GTK3 issue, but i'm starting to think it's a problem with Awesome, given how the efficacy of "client.focus = client.focus" depends on the position of the mouse (and i can trick this "solution" a bit more by being fast enough :) ...). I've been playing with Evince all afternoon, and have observed the following behaviour. When changing away from the tag with Evince in, Evince gets GTK events telling it that focus has changed, visibility has changed, and the mouse has moved out of the window (if it was in the window to start with). When changing back it reliably gets the expected visibility and mouse events, but every so often the focus in event goes missing. I tried to track this a little more and added a "focus" signal to see what Awesome thinks is gaining focus. Even in the cases when focus in goes missing, a "focus" signal gets generated. However, this is a bit weird, because putting the mouse over Evince and executing client.focus = client.focus doesn't generate a "focus" signal, but does generate the focus in event... A hack i did try is changing my tag switching key bindings, so it runs awful.tag.viewprev/next then afterwards client.focus = client.focus. This generally stops the focus in event going missing, but i can break it by changing tags as fast as possible -- which may point to some concurrency issue in Awesome, if such a thing is possible (Evince is fullscreened, so it shouldn't be the mouse thing, i think...). So i'm at the end of my expertise :) Any help would be appreciated... Thanks, Matt -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: Evince / Key Focus Problems
> Anyone knows a GTK hacker who got some spare time and can figure this out? I'd > be curious about what exactly gtk is expecting here and why it is ignoring the > events (aka "What does it thing does have the input focus? Why does it think > so?) >From my playing, it looks like GTK is getting the focus in event from X11, but, before it generates a focus in event to pass on to the GTK app it checks whether the app already has focus. It considers the app to have focus if either has_focus is true, or, crucially, has_pointer_focus is true. (See gdk/x11/gdkdevicemanager-xi2.c, handle_focus_change function in the gtk3 source code.) I don't know whether X11, GTK, Awesome or Evince are at fault here, but maybe i should start hassling some other mailing lists :) But in case this kind of situation rings any bells to anyone, i thought i'd start here :) Thanks, Matt -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: Evince / Key Focus Problems
> From my playing, it looks like GTK is getting the focus in event from X11, > but, before it generates a focus in event to pass on to the GTK app it checks > whether the app already has focus. It considers the app to have focus if > either has_focus is true, or, crucially, has_pointer_focus is true. It would, of course, have been cleverer of me to mention, that in the cases where Evince doesn't get focus back, it's because the mouse is over the window and has_pointer_focus has been set to true. Matt -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: Client Movement between screens
There's a function awful.client.movetoscreen(c, s), which moves client c to screen s. I don't have a multi-screen set up to test this with, but my first attempt would be to add bindings to function (c) local nextscreen = c.screen + 1 if nextscreen > screen.count then nextscreen = 1 end awful.client.movetoscreen(c, nextscreen) end and function (c) local prevscreen = c.screen - 1 if prevscreen < 1 then prevscreen = screen.count end awful.client.movetoscreen(c, prevscreen) end to clientkeys in your rc.lua. There's probably some one-line way of choosing the next or previous screen, using %, but it's a bit too early in the morning here to think about that... (and it would obfuscate the code). Best, Matt On Thu, Mar 15, 2012 at 08:34:22PM -0500, Gerald Klein wrote: >Hi, The default ability to move clients between screens is in only 1 >direction, does anyone know if there is a way to go either directions or >directly to a screen so I don't have to cycle through all my screens to >get to where I am going. >thanks for any help you may give. >--jerry >-- > >Gerald Klein DBA > >www.geraldklein.com > >j...@zognet.com > >708-599-0352 > >Linux registered user #548580 > >The below contributed statements are wellfunny and I apologize if >someone is offended.not. > >Unix is user-friendly. It just isn't promiscuous about which users it's >friendly with. - Steven King > >Frustrated Windows users have two options. > >1. Resort to throwing computers out of windows. > >2. Resort to throwing Windows out of computers > >Ever realized that if you play Windows CD backwards you'll hear satanic >messages? > >But that's nothing! If you play it forward it will install Windows. > >"Ubuntu" -- an African word, meaning "Slackware is too hard for me". > >The day Microsoft makes a product that doesn't suck, is the day they make >a vacuum cleaner. > >Linux is like a wigwam: no gates, no windows and Apache inside. (Chinese >proverb c. 910 B.C.) > > > >"being a Linux user is sort of like living in a house inhabited by a large >family of carpenters and architects. Every morning when you wake up, the >house is a little different. Maybe there is a new turret, or some walls >have moved. Or perhaps someone has temporarily removed the floor under >your bed" * Unknown > > > >Customer: I'm running Windows... >Helpdesk: Yes... >Customer: ...and now my computer stopped working ! >Helpdesk: Yes, you already said that. > > > >The box said "Requires Windows 98 or better." > >So I installed Linux. > > > >I ran the Microsoft Malicious Software Removal tool > >but Internet Explorer is still installed on my computer. -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: Dependencies
At a guess, maybe pango or glib2 are either out-of-date or too-up-to-date (if you pulled them from [testing], for example). Matt On Tue, Apr 24, 2012 at 10:40:46PM +0100, David Gomes wrote: >I just tried to build awesome WM from git repository >(http://aur.archlinux.org/packages.php?ID=13916), but it needs >lua-oopango. >However, I can't build lua-oopango (I get this >error: http://pastebin.com/KFwj4L3W). >How's everybody managing to build Awesome and lua-oopango? > >(I tried both Lua 5.1.5 and Lua 5.2) >-- >David Gomes -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: Multiscreen problems + systray keyboard control + widget question
> 1. When I add activate external display, all my clients (windows) form > my LVDS screen momentarily switch to the external display. Is there a > way to force them to stay. I always use my LVDS as the primary for > work (coding, browsing) and the external for reading/presentations. I haven't noticed this problem. Here's the command i use to activate an external display: xrandr --output VGA1 --mode 1280x1024 --right-of LVDS1 It's nothing fancy, so maybe won't help, but just to throw it out there :) > 2. When I move a client to the external screen (say Chromium) and > maximise it, it jumps back to the LVDS screen maximised. I also have this problem, and am keen for a solution. > 3. When I put in xrandr my external left of my main, the resolution of > the external is completely garbled. The picture is tiled of the > picture from the main display. When I set the external's resultion to > the same as the main's everything is fine then. And i've never tried this :) Matt -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: Alt+tab just switches between two apps
>Anyway, do you find more usefull these key bindings? more than the >classical alt-tab? I can not find too much sense on it.. I think the idea behind vi using hjkl for movement is that you don't have to move your hands away from the home row to reach them. Alt+tab required a bit of an awkward stretch/wrist turn on my keyboards -- albeit one that i was so used to it didn't seem so bad -- so switching to mod+j/k made things noticeably more comfortable/smooth. It also depends on how easy it is to reach your mod key, of course :). That's still a bit awkward for me, but less so than alt-tab. Matt -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: Render active an application using a key binding
>I know that i can associate a key binding to open an app (Mod+Enter opens >the terminal). >But, how to render active the app with a key binding? >Should I associate a key binding to the app? or should i open always the >app in a specific tag (in that way i can render active the app using >Mod+1,2,3...) ?? Might be worth having a look at run or raise: http://awesome.naquadah.org/wiki/Run_or_raise (from the tips page http://awesome.naquadah.org/wiki/Main_Page) Matt -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: using awesome as a pure window manager (no status bar / wibox)
On Sun, Oct 21, 2012 at 10:02:50AM -0700, Thibaut Colar wrote: >I'm trying to use window manager (I really love the tiling options and >more) with razor-qt (bit of shinny). >I set awseome as the window manager of razor-qt and removed the wibox from >rc.lua but it's not quite working. >The wibox is not showing but it's "using space" (gray bar on top) as if it >was there, also it seem to really be running even if if it's not >"showing". I never did anything like that, but i hide the wibox by default, and use mod+tab to toggle its visibility. The essential code for hiding is mywibox[mouse.screen].visible = false With this setting, the wibox neither shows nor uses space. I'm just using awesome on its own though. Matt -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
