Awesome from git failing in arch linux
Hello all, I'm having some trouble getting the git version of awesome (from the AUR) to run properly. This is the error message I always get: X Protocol Version 11, Revision 0 Build Operating System: Linux 3.4.4-3-ARCH x86_64 Current Operating System: Linux westley 3.4.4-3-ARCH #1 SMP PREEMPT Tue Jul 3 14:36:44 UTC 2012 x86_64 Kernel command line: root=/dev/mapper/lvm-root cryptdevice=/dev/sda3:crypt ro Build Date: 09 July 2012 03:59:39PM Current version of pixman: 0.26.2 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.1.log, Time: Fri Jul 20 02:00:48 2012 (==) Using config directory: /etc/X11/xorg.conf.d /home/sib/.xinitrc: line 7: /home/sib/.xinit-trackpoint: Permission denied /home/sib/.config/awesome/rc.lua:57: attempt to index global 'awful' (a nil value) /usr/share/awesome/lib/naughty.lua:312: attempt to index local 'beautiful' (a nil value) E: awesome: main:555: couldn't find any rc file xinit: connection to X server lost waiting for X server to shut down Server terminated successfully (0). Closing log file. This is a pretty much fresh install of Arch and the problem persisted from before the reinstallation. Can anyone offer any suggestions for this? Ellie -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: Awesome from git failing in arch linux
On 20.07.2012 11:15, Ellie Frost wrote: Hello all, I'm having some trouble getting the git version of awesome (from the AUR) to run properly. This is the error message I always get: X Protocol Version 11, Revision 0 Build Operating System: Linux 3.4.4-3-ARCH x86_64 Current Operating System: Linux westley 3.4.4-3-ARCH #1 SMP PREEMPT Tue Jul 3 14:36:44 UTC 2012 x86_64 Kernel command line: root=/dev/mapper/lvm-root cryptdevice=/dev/sda3:crypt ro Build Date: 09 July 2012 03:59:39PM Current version of pixman: 0.26.2 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.1.log, Time: Fri Jul 20 02:00:48 2012 (==) Using config directory: /etc/X11/xorg.conf.d /home/sib/.xinitrc: line 7: /home/sib/.xinit-trackpoint: Permission denied /home/sib/.config/awesome/rc.lua:57: attempt to index global 'awful' (a nil value) /usr/share/awesome/lib/naughty.lua:312: attempt to index local 'beautiful' (a nil value) E: awesome: main:555: couldn't find any rc file xinit: connection to X server lost waiting for X server to shut down Server terminated successfully (0). Closing log file. This is a pretty much fresh install of Arch and the problem persisted from before the reinstallation. Can anyone offer any suggestions for this? Hi, here's the plan: 1. Try the default config 2. Notice that it works 3. Blame lua 5.2 for breaking everyone's config 4. ??? 5. Profit (You have to do 'local beautiful = require(beautiful)' instead of just plain 'require(beautiful)' now) Uli -- - 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-unsubscr...@naquadah.org.
Float on top
Hi guys does anyone know if you can make a floated window always on top? thanks --jerry -- Gerald Klein DBA contac...@geraldklein.com www.geraldklein.com http://geraldklein.com/ j...@zognet.com 708-599-0352 Arch Awesome, Ranger Vim the coding triple threat. Linux registered user #548580
Float on top
Mod + t in the default keybinds :) Cheers On Fri, Jul 20, 2012 at 4:59 PM, Gerald Klein j...@zognet.com wrote: Hi guys does anyone know if you can make a floated window always on top? thanks --jerry -- Gerald Klein DBA contac...@geraldklein.com www.geraldklein.com j...@zognet.com 708-599-0352 Arch Awesome, Ranger Vim the coding triple threat. Linux registered user #548580 -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: Float on top
Gerald Klein wrote: Hi guys does anyone know if you can make a floated window always on top? I have this near the end of my rc.lua: ---[[ Arrange signal handler. for s = 1, screen.count() do screen[s]:add_signal(arrange, function () local clients = awful.client.visible(s) local layout = awful.layout.getname(awful.layout.get(s)) for _, c in pairs(clients) do if awful.client.floating.get(c) or layout == floating then if not c.fullscreen then -- Floaters always on top c.above = true end else c.above = false end end end) end --]] Cheers, mih -- 'aware water' is an anagram for 'we are at war' -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: Float on top
Antonio Santos wrote:
Mod + t in the default keybinds :)
Cheers
On Fri, Jul 20, 2012 at 4:59 PM, Gerald Klein j...@zognet.com wrote:
Hi guys does anyone know if you can make a floated window always on top?
Oh, if you want this permanent for just one application there's the ontop
property, e.g.:
{ rule = { class = xzoom },
properties = { ontop = true } },
Cheers, mih
--
'aware water' is an anagram for 'we are at war'
--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
auto completion broken? (3.4.12-2)
Hi, mod+r, xt[tab] gives me xterm/...there is no directory xterm (and this error occurs with every other application, also when [tab]bing further for more results, the slash stays. Hints? Known issue? Reproducable here, what about others? debian testing (current) and $ awesome --version awesome debian/3.4.12-2 (Starlight) • Build: Jun 13 2012 11:30:57 for x86_64 by gcc version 4.7.0 (@zelenka) • D-Bus support: ✔ Thorsten -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: auto completion broken? (3.4.12-2)
I can't reproduce it here but I'm using 3.4.13. I don't see any closed/open bugs on it either. Perhaps it's specific to debian testing? Maybe your rc.lua has something - mind attaching it/pasting it somewhere?
Re: auto completion broken? (3.4.12-2)
On 20.07.2012 20:18, Musee U wrote: I can't reproduce it here but I'm using 3.4.13. I don't see any closed/open bugs on it either. Perhaps it's specific to debian testing? Maybe your rc.lua has something - mind attaching it/pasting it somewhere? Nevermind, I have no clue. I reinstalled the awesome files (because I remembered editing /usr/share/awesome/lib/awful/completion.lua for another error someone else talked about) and it was gone. Most probably my own fault. But since the topic is the same, I'm just writing down what I wanted to fix myself (and didn't do it, yet): If you have a path with spaces (like in my case /files/Daten/Eigene Dateien/) and press tab to complete it, it will do that (and escape the space), but then fail to complete further (deeper) paths and show this error after [tab] in .xsession-errors: /bin/bash: Line 0: test: /files/Daten/Eigene: binary operator expected We guess that in above file, line 126 if os.execute(test -d .. line) == 0 then is the cause. But just a guess.. Thorsten
Re: Autofocus and skipping clients
Douglas K. Rand rand at meridian-enviro.com writes:
I've got a couple of stickey clients (like GKrellM and Psi's roster)
that are shown on every tag:
{ rule = { name = gkrellm },
properties = { border_width = 0,
skip_taskbar = true,
sticky = true,
floating = true } },
{ rule = { name = ^Psi$ },
properties = { border_width = 0,
skip_taskbar = true,
sticky = true,
floating = true } },
But I'm also using awful.autofocus, and it is always GKrellm or the
Psi roster that has the focus when I switch tags, and I'm finding that
annoying. What I've found is that this small patch to focus.filter in
awful/client.lua seems to fix the problem for me, and also seems to be
reasonable also.
--- client.lua-orig 2011-04-30 20:17:25.0 -0500
+++ client.lua 2011-04-30 20:17:02.0 -0500
@@ -114,6 +114,7 @@
if c.type == desktop
or c.type == dock
or c.type == splash
+or c.skip_taskbar
or not c.focusable then
return nil
end
That if the client isn't using the taskbar, it shouldn't be in the
focus history either.
What are other's thoughts? I thought I'd ask here before creating a
Flyspray task.
I agree. A few months ago, I noticed this behavior as well. Awesome used to
remember which window was focused in each tag (or so it seemed), but there was a
bug in the config file that would cause gkrellm to steal focus. I fixed the bug,
then noticed that someone else fixed it upstream a little while later. Now, I
can't find any way in the config file to fix this behavior.
Please do submit this as a bug, and I'll accept any fix that's reasonable.
Docked apps should not get focus when switching tags.
Gkrellm keeps changing colors and font sizes every now and then due to stolen
keystrokes...
--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Dialog windows leaving titlebars behind
Hi,
I'm using the following code to add titlebars to floating windows:
|awful.hooks.property.register(function (c, prop)
-- Remove the titlebar if fullscreen
if c.fullscreen then
awful.titlebar.remove(c)
elseif not c.fullscreen then
-- Add title bar for floating apps
if c.titlebar == nil and awful.client.floating.get(c) then
awful.titlebar.add(c, { modkey = modkey })
-- Remove title bar, if it's not floating
elseif c.titlebar and not awful.client.floating.get(c) then
awful.titlebar.remove(c)
end
end
end)
|
On closing certain windows (e.g. the standard GTK file handler window in
Emacs, or the options dialog in Firefox) a rectangle is left behind
where the titlebar was, with the color theme.bg_normal. It sits on top
of all other windows, can't be moved, and won't go away until I restart
awesome. I'm using awesome Octopus on Arch with X.Org 1.12.3. Is this a
problem with my code, is this a known bug, or am I just spectacularly
unlucky?
Thanks in advance.
[awesome bugs] #994 - flash player bleeding between tags
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#994 - flash player bleeding between tags User who did this - Lauri Niskanen (Ape) -- This is not a bug in Awesome. It's caused by the combination of buggy video drivers (nvidia) and flash. It's possible that we could apply some hacky workaround on Awesome to fix this, but I don't think it's worth it. Instead the video drivers and flash should be fixed (or replaced with something else). I'd close this bug. -- More information can be found at the following URL: https://awesome.naquadah.org/bugs/index.php?do=detailstask_id=994#comment3128 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
