Re: A simple dmenu_run kind of application to search and focus a client in any tag
Hi,
I have written a function to do exactly this, I'll just paste it below,
maybe you can make use of it or parts of it.
There is one little issue with this code and I have no fucking clue why:
I need a naughty.notify in there to make it work for whatever reason. I
haven't looked into that, but that might expose a bug? I don't know,
maybe you can paste your own function or tell if you encounter a similar
behavior.
Manuel
function clientViadmenu()
--get list of all clients by name to pipe into dmenu
clientlist =
for c in awful.client.iterate(function(c) return true end) do
clientlist = clientlist .. c.name .. \n
end
naughty.destroy(naughty.notify{text = }) --WTF!? Without this it
doesn't work, I have no fucking clue why
--select the wanted title
wanted = awful.util.pread(printf ' .. clientlist .. ' | dmenu -i -l
50):gsub(\n, )
--wanted = awful.util.pread(/home/jonas/.myprogs/dmenuselect ..
clientlist )
-- get the (first) client that matches that title
for c in awful.client.iterate(function(c) return awful.rules.match(c, {
name = wanted }) end) do
if c.minimized then
c.minimized = false
end
awful.client.jumpto(c)
break
end
end
--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: A simple dmenu_run kind of application to search and focus a client in any tag
Ah, forgot the script I'm calling, dmenuselect: #!/bin/bash var=$(printf $1 | dmenu -i -l 50) echo -n $var Just a simple wrapper around dmenu. -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: create client and hold it in variable
Am 03.04.2014 07:50, schrieb Uli Schlachter: You aren't spawning a client and throwing it away. You are spawning a *process*. That process later happens to open a new window and thus we get a client, but not all processes open one window. Ah, that's definitely true, obviously slipped my mind yesterday. [awesome awesome-code] Why is this better than just finding the new urxvt by pid in the manage hook? Dunno. It just gets more browny points for using some fancy API... I assume this set xproperty persists as long as the X-Server is up and running (aka over restarts of awesome)? That would solve another issue, tracking this urxvt over restarts of awesome (shall be spawned once, but not again when I restart awesome as it still fullfills its purpose). If so, the xproperty-String can be chosen as I see it fit, right? Thanks, Manuel -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
create client and hold it in variable
Hi,
I want to create/spawn a new client (a new urxvt) and hold it/catch it
in a variable to do some stuff with it afterwards.
The way I am doing this now is by spawning, catching the pid and then
find the client with this pid:
clpid = awful.util.spawn('urxvt')
wait(1) -- waits 1 second
for c in awful.client.iterate(function(c) return
awful.rules.match(c, { pid = clpid }) end) do
persistent_c = c
end
Is it possible to spawn and catch a client in one step (or at least not
bringing out the artillery by spawning a client, throwing it away and
then get it back from the bunch of clients)?
Thanks in advance,
Manuel
--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: Delayed autoraise
Tested and in productive use:
function delayFunctionCall(time, funct)
local t = timer({ timeout = time or 0.01 })
t:connect_signal(timeout, function() t:stop(); funct() end)
t:start()
end
just hand over your wanted delay (if nil, 0.01s is used) and the
function doing what you want to have delayed. Works like a charm for me.
Cheers,
Manuel
--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
get layout icon
Hi, is there a possibility to get the layout-icon of a layout (assuming I have the layout/layout-table at hand)? I was searching the api, but without success so far. And if this is possible, are naughty-notifications capable of displaying icons? Cheers, Manuel -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: get layout icon
Am 22.03.2014 23:10, schrieb Elv1313 .: beautiful[layout..your_layout_name] works almost. beautiful[layout_..your_layout_name] is doing the trick. Thanks! Manuel -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: concerning titlebars
Ah, that makes sense! Thanks for clarification! Only one question remaining I'm not absolutely sure about: Does every client have a default empty titlebar of size 0 upon start of existence? At least during my experiments I sometimes got an empty titlebar on a client. P.S.: And I just noticed that you will run into lua errors if you try to show a non-existent titlebar... Yep, I noticed that as well. Cheers, Manuel -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
concerning titlebars
Hi, I'm a little confused with a detail in the titlebar-implementation in awesome. I took the titlebar-code from the reference-rc.lua. Now I want to work on titlebar-stuff and noticed that the titlebar is set by setting the widget of the wibox titlebar/awful.titlebar(c). However, there is no awful.titlebar.show(c) in there, so is titlebar.show() an implicit effect of awful.titlebar(c):set_widget(layout) or do I lack overview over my configuration? Thanks for help, Manuel -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Behavior on SIGTERM
Hi, I was wondering whether awesome behaves correctly on receiving SIGTERM, i. e. doing (more or less) awesome.quit(). I'm not sure how to check that myself. I'm asking that because I know from personal experience that there is software out there, that shuts down on SIGTERM, but interprets that as a crash. *cough* firefox *cough* I was wondering whether shutting down a system with running awesome is issuefree by using the system's ability to send SIGTERMs on shutdown. Thanks for help, Manuel -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: Behavior on SIGTERM
Hi Uli, Am 19.02.2014 22:00, schrieb Uli Schlachter: Looks similar enough to me. Indeed, thanks for the fast and especially detailed response. So if you want to confuse people, append awesome.quit() to the end of your rc.lua...) I might indeed consider that one when I'm showing someone my rc.lua.^^ Uhm, ok... Why are you SIGTERM'ing your session anyway? Because if every application is behaving correctly, why closing everything by hand when the system is emitting SIGTERMs anyway? Minimizing work and so on. ;) Firefox itself is assuming a crash if it gets a SIGTERM anytime, not just on shutdown. Just killall firefox makes you end up in a crash report with an attempt to restore the session upon next startup. So there might be the problem you mentioned about X, however, there is incorrect behavior anyways, so I never came to deal with that particular situation. I haven't thought about the point you made with sigterming X, however. Luckily, the setup I use at the moment for shutting down (in the attempt to solve the firefox issue) solves that anyways by using EWMH. And if X dies ealier: if that means all graphical processes get SIGTERMed, it shouldn't be a problem anyways, even if they didn't receive the SIGTERM originally intended for them by the shutdown procedure but another one, should it? This means: race or not, doesn't matter, does it? Cheers, Manuel PS: And thanks for all the good work on awesome, your efforts make it a piece of software worth its name! I really appreciate that! -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: key not bindable
Am 30.01.2014 02:09, schrieb M Vitaly: You can then go try debugging your keypresses using https://wiki.archlinux.org/index.php/Extra_Keyboard_Keys this guide. The keypresses are fine, every key ist registered. That doesn't seem to be the problem. If simply I move the line where I declare the key from the Clientkey-Table to the Globalkey-Table (without changing anything) it somehow works out of a sudden. I really don't understand that. There are no keys that can override it in the clientkeys-table, neither in clienkeys itself before or after nor in the globalkeys-table. Best Regards, Manuel -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
key not bindable
Hi guys,
I have a quite confusing problem: I want to bind a function to modkey +
p. However, it simply doesn't work.
Extract from clientkeys:
awful.key({ modkey, },m,functionone ), --works
awful.key({ modkey, },p,functiontwo ), --doesn't
Function one is working perfectly, function two does not get called on
keypress.
The interesting point is: if I just swap m and p and thus simply
switch the bindings, function two works, function one does not, so it's
not the function but the keybind.
If I move the p-line into the globalkeys, everything works.
I am sure I have no doubling in binding something to p. This occures
as well if p is the first entry or the very last entry.
I'm running out of ideas. Any ideas would be very appreciated. modkey is
Alt_L if that's of importance.
Cheers,
Manuel
--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: Fullscreen Firefox
Am 22.10.2013 15:33, schrieb Sean Goodwin: Any ideas? How does F11 behave (Firefox' own keybinding for this)? -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
client-property leader_id
Hi, I just wondered what a client's leader_id contains (or, to be more precise, in which circumstances there IS a leader_id). I couldn't produce a scenario where a client's leader_id is set, but maybe I just tried out the wrong scenarios. What is ment by spawned by the same command as said in the API*. Thanks in advance, Manuel *) http://awesome.naquadah.org/doc/api/modules/client.html#client -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: spawn something on a certain tag without rules
Hi Andre,
Did you ran a xprop on a started window?
I created a rule = { class = pcmanfm } and created a function called
via callback which reports (via naughty.notify) certain attributes of
the client started. This gave me the hint for this, because when I *see*
the client, its name is the folder's name, but because the rule
mentioned shows otherwise (just for the first pcmanfm-window started,
further ones don't result in a new process, as I found out) I assume
that the client has already passed the rule when I can see it (then the
name of the client is changed to the folder's name). This is supported
by the fact that a rule aiming at the name of the client works
charmingly with the second window started the same way but not the first
one.
You are right, the client is started via script, in fact a simple cd
folder; pcmanfm, nothing spechial. But the idea of starting pcmanfm
with a certain name was a good one, far more elegant than my actual
variant with the signal handling. There is indeed a cli argument for
pcmanfm to do this. Saved 14 lines of code, thanks for the idea!
Just one rule now.
Cheers,
Manuel
--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: spawn something on a certain tag without rules
rulehelpzeuch(cl) has to be replaced by rulehelpPCManFMPlacement(cl) of course for working code. ^^' -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
spawn something on a certain tag without rules
Hi, I want to start a process on a certain tag. I could do this combining awful.util.spawn() and a rule, but in this case I need to do it entirely without a rule. The exact scenario is that I have a script which changes to a certain directory and starts a filemanager (pcmanfm) in there afterwards. This filemanager shall come up on a certain tag (getting the correct tag is no problem). But just this filemanager spawned by this script shall be started on this one tag, other filemanager processes shall not be affected by this (that's why I can't work with a rule, because the way of spawning is the only differernce between certain instances). Any good ideas how to archieve that? I can pipe most commands to awesome from a shellscript via echo 'command' | awesome-client, if someone knows how to implement it completely (with the directory change) in awesome/lua, feel free to tell me about that way! Thanks in advance, Manuel -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re:
I can confirm Zsolts assumption, I've played around with Caps Lock as a modifier key myself, if it isn't disabled before you started to use it, it won't be by using it in your config. Best regards, Manuel -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: Netwidget with two interfaces
Thanks! Now I've got a netwidget running as I want it to have, showing all active interfaces and hiding those, which are not active (or displaying no network if there isn't any connection). Your code was a very fruitful source of inspiration. Best regards, Manuel -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: Client with multiple tags
Am 08.04.2013 09:59, schrieb Corentin Henry: In the wiki I see that it is possible to *place clients on several tags* but I couldn't find how to do this. As far as I remember this is done in the default rc.lua via holding the modkey and right click on the tag the focused client should also be on. It it what you where looking for? Best Regards, Manuel -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Netwidget with two interfaces
Hi there, I was wondering if someone has an idea how to solve my little problem: I have two networkinterfaces in my machine, WLAN and a wired connection. Depending on the place I am either the one or the other is in use. Though, as I have a network usage widget (the one that comes with vicious) in my wibox, I have to manually switch the used interface in my configuration code to get the network traffic of the used interface. Is there a way to use vicious' netwidget to monitor the traffic going over both of the interfaces (or just showing the one which is up) or do I have to write my own widget? I'm displaying the traffic down as well as up next to each other, if that's important in some way. Thanks in advance, Manuel -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: Run Or Raise and urxvt
I would just set the wanted variable on login, then you don't have to deal with that problem at all during your session/in ranger. Do you use a login manager or do you login via console? In case you login via console, I just would put the line export EDITOR=vim into your .bashprofile or .zprofile, .kprofile, whatever shell you use. Then $EDITOR should be set during your entire session. In case you use a loginmanager I would try to do something similar, for example execute a script on login with this line in it. In case you have no idea how to do it with your login manager, you can just put awful.util.spawn(path/to/your/script) at the end of your rc.lua (you could of course also call your wished shell directly to execute the export-command without pointing at a separate script (should be something like /bin/zsh -c export $EDITOR=vim ) Best Regards, Manuel -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: Set rxvt-unicode as default term
Am 19.03.2013 20:25, schrieb Louis MARIE: I would like to know how to set rxvt-unicode as default term when i press modkey (Mod4) + enter At least in the default rc.lua there is a variable called terminal, which is set to xterm by default. If you haven't modified your rc.lua too much it should be enough to just change this from xterm to urxvt (or whatever the rxvt-unicode is called on your machine). In the globalkeys (at least default-rc.lua) there is a keybind for Mod4+Enter which spawns the program in the terminal-variable. You can also change that from terminal to urxvt if you just want to have urxvt be started via this keybind, but I assume you want to use rxvt-unicode as the default terminal emulator for everything, so the upper way is yours. Cheers, Manuel -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: Problems banshee program tag window matching
The property WM_CLASS(STRING) of the xprop-output mentioned by Vitor is needed. Type xprop into Terminal and then a click on banshee. The second value of WM_CLASS(STRING) is what you have to adress by class in the rules. Is this value really Banshee and not banshee or something like that? Manuel -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
ruleset not working
Hi,
I've got a problem concerning a set of rules which isn't working as
expected.
I have a tag music and I want to have the vlc media player opened
tiled on this tag but floating on all other tags.
To archieve this I wrote two rules. functions.getTagByPattern definitely
returns the mentioned music-tag.
The first rule shall make sure that the player is opened tiled on the
music-tag:
{ rule = { class = Vlc, tag = functions.getTagByPattern(music) },
properties = { floating = false }, callback = awful.client.setslave }
The second one shall ensure that vlc is opened floating on the other tags:
{rule = { class = Vlc}, except_any = { tag =
functions.getTagByPattern(music) }, properties = { floating = true } }
Both are executed (or at least written in the rules-table in rc.lua) in
the order I wrote them.
Unfortunately they don't seem to have any effect.
Does someone spot an error of any kind in there? At least it is accepted
syntactically by awesome.
Thanks,
Manuel
--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
use rule just on a certain tag
Hi,
still the problem with the ruleset, but I've run some experiments and I
by accident I was able to localize the problem: Because the wiki speaks
about properties concerning the rule-, and except-table I assumed
that I could use everything I can in the properties-table of a rule.
However, it seems that in a ruleset the tag-property can just be set via
properties = { tag = some-certain-tag }, but cannot be used within
rule or except.
Does someone know a way to make a rule just be applied on clients on a
certain tag?
Thanks in advance,
Manuel
--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
tasklist-style - foreground color
Hi, I recently wanted to change the colors of my tasklist and I found something out that I don't understand completely: When I use the style-table as a fourth argument to override the default colors, the colors have to be given as #ab12ef or something like that, a hexadecimal value. Everything works fine doing so, but when I assign them without '#', it also works for the color, but the text in the tasklist changes to invalid text when assigning a foreground color without '#'. Why is a hexadecimal number accepted and working for the background color with and without '#', but isn't for the text/foreground color. Is it because the background color is handed to awesome, which accepts hex-colors without '#' for drawing, while the foreground color is handed to a pango markup, which doesn't accept this? Just a guess, I would be glad if someone could illuminate me. Manuel -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
localizing of modules' variables
Hi there, I've got a question concerining the new module-call: Using the previous version of lua one had to localize all the variables by putting a local var = var above the module-call in the module code because the module-call set a new environement untill lua 5.1, which was changed in lua 5.2 to not to do that and awesome has (at least as the default package in Arch Linux) a dependency on lua 5.2. If I remember correctly this should mean that it isn't necessary anymore to do those localizing of variables. But it isn't in my configuration, I still have to localize all of them I use, so am I doing something wrong? Thanks for in advance for help! Manuel PS: in rc.lua: [default modules] mymodule = require(mymodule) ... [rc-code] ... in mymodule: local var = var ... module(mymodule) ...[a bunch of functions]... -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: Increase the space between tags in taglist
Would it be an idea to insert spaces at the beginning and at the end of the tags' names? Seems to do what you want. Greetings Manuel -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
can't stop resizing/moving sometimes
Hi, I've encountered a problem in awesome 3.5: Sometimes when I resize or move a client via mouse by pressing modkey + Button 1 respectively Button 3 awesome doesn't stop resizing or moving it when I release the modkey or the button. The mouse isn't usable anymore, it stayes at e.g. resize and also a switch to another tag works, but doesn't help, the pointer keeps his resize-form and I can't click on anything. Switching back to the tag where I wanted to resize it goes on resizing the window I wanted to resize depending on how I move the pointer. I have to restart awesome by keybind to continue working, this is the only possibility I have found until now. The button-bindings are exactely the same as in the default config and I don't get any error messages, at least not in the X-server's output, I don't know if there are other places where I can find some. I looked through the other logs but didn't find anything useful, not even anything concerning awesome. Does anyone of you know how I could localize the problem or even solve it? Is it maybe already known? Or isn't that a problem of awesome though it just happens (sometimes) on resizing or moving clients? Thanks in advance, Manuel -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
proposal for changing the default config to avoid a non-starting awesome 3.5
Hi there, I just want to put something up for discussion: not to add a systray in the default config or keep the line with the systray commented out, because it can lead to an entirely unstartable awesome. The reason is that when awesome's rc.lua has runtime errors awesome falls back to default rc.lua while keeping the things done in the user's rc.lua executed to the point of failure (which can result in two taglists, for example, when crashing here I often see mine and the default one). But that could also mean that the user's rc.lua has created a systray and because of a coding error the default rc.lua is executed as fallback, creating a second systray, which results (at least with me) in a total quit of awesome*. Because I just use the .xinitrc with startx to start the X-Server with awesome X quits after awesome quits, taking all started X-applications down with it (which it of course doesn't do if awesome just restarts, then everything is still there), including the editor the configuration is potentially modified in (annoying when it falls back to commandline an you have vim or sth. like that, but I don't know if there might be a scenario where you might have a real problem with a not-starting awesome). After I realized why awesome was going down that far, because the second systray is created in the default configuration, I commented it out there to avoid this behavior for the future, which works quite well. So, because already a little negligence at the wrong point, which I think happens from time to time to most of us, can cause this annoyance, I want to propose to modify the default rc.lua that way. Feel free to comment this idea! Cheers Manuel *) Error: /usr/share/awesome/lib/wibox/widget/systray.lua:60: More than one systray created! -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: Widget spacer
On 01.01.2013, 20:57, Piotr Adamus wrote: myspacer = wibox.widget.textbox() myspacer.text = | But above doesn't work nor returns an error. Could I ask you for a help? The second line has to be rewritten into myspacer:set_text( | ), that should work. You also could use myspacer:set_markup( | ) if you have a markup on the textbox which shall be respected. Cheers Manuel -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: no focus-update when screen content changes without mouse
I just found a solution for the problem: minimizing clients as well as closing ones emit the unfocus-signal, so I simply put it into the client's unfocus-signal-handler and it seems to work so far. Cheers, Manuel -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
no focus-update when screen content changes without mouse
Hi, I just stumbled on a little problem with focusing the clients: When I change the screen's content without touching the mouse, e. g. by minimizing or closing a client by keyboard or typing exit into a terminal, the focus goes to another visible client, but not always the one under the pointer. In fact, if the focus switched to another client than the one under the pointer I have to move the pointer out of this client and back in, to focus it or click on it. I would like to have always the client under the pointer having the focus, unless I change the focus manually by keyboard, because I routinely orient myself by the pointer's position (thicker borders isn't the preferred way, if possible). I could probably bind something to the minimize-signal (haven't tried yet), but that wouldn't cover the quitting clients. Is there a way for implementing this without having to write every minimize- and kill-statement into a function which does this and actualizes the focus afterwards (which still wouldn't help when I close a terminal by typing exit, which happens quite often here)? Thanks in advance, Manuel -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
show client-list in menu by functioncall
Hi,
I want to write a function (code below) to get a list of all running
clients in a menu. In fact, the code is already in the default
configuration, but I just get it working by placing the function as an
entry in another menu.
Called by an entry of this menu, everything works fine, but when I call
the function directly via keybind just nothing happens and there isn't
any output by awesome either. I tried different arguments for
awful.menu:clients, but nothing changes (or I just by accident didn't
spot the right combination).
Does anyone spot the problem?
Thanks in advance,
Manuel
The used function:
function showWindowlist()
if instance then
instance:hide()
instance = nil
else
instance = awful.menu:clients({ width=500 })
--instance:show() -- doesn't change anything
end
end
--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: focus client on tag switch
Finally I had the time for trying it out, sorry for the answering-delay. On 28.11.2012, 23:50, Christopher Schmidt wrote: Delay that call. [some delay-code] Works perfectly! Thanks! And I dove into the possibilities of signal handling, quite a convenient extra. One more question: What would happen if I don't stop the timer on receiving the timout-signal but just execute my function? Manuel PS: For those who are interested in this: It still works when I set the delay time to 0.1 seconds. -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: [ANNOUNCE] awesome 3.5-rc1 released
On 24.11.2012, 15:48, Uli Schlachter wrote: Also, we did some changes to make awesome future-proof. With lua 5.2, module() was deprecated in lua. Awesome no longer uses this function. What's about the entire local var = var stuff at the beginning of a module before the module()-call itself? This was necessary, because module() set the environment to a new one, so all variables were nil. Does the drop of module() mean this bunch of variable-transport isn't necessary anymore because the modules get the original environment by default? Cheers, Manuel -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: [ANNOUNCE] awesome 3.5-rc1 released
On 01.12.2012, 15:23, Uli Schlachter wrote: However, the change was already big enough without removing these locals and some modules rename variables while localizing them. That's right, of course, I just thougt about that because I regularly stumble about it when awesome tells me about an error in a module because I forgot localizing something I use, so that comes quite convenient. ;) Thanks for the info! Manuel -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: [ANNOUNCE] awesome 3.5-rc1 released
Great news and my heartfelt thanks to the awesome-devs and everyone who contributed! Manuel -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
focus client on tag switch
Hi, when I switch to another tag by keyboard, there is usually a certain client under the cursor. I want that client to be focused without having to move the cursor or even clicking. I tried to replace the function awful.tag.viewnext by this: function nextTag() awful.tag.viewnext() client.focus = mouse.object_under_pointer() end but still the object the pointer is on doesn't get the focus unless I click or move the cursor over a border to another client which is focused then. Does anyone knows a solution for this? Thanks in advance Manuel -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: root.fake_input() doesn't work as exprected
Am 20.11.2012 18:06, schrieb Uli Schlachter:
How about using
awful.key({ modkey }, F2, nil, experiment)
This works. First, it's a bit weird, but it's logical that I get the
modkey+spacebar-keybind when I release F2 because I still have modkey
pressed. But it was quite a funny behavior before I realized that.
Works now and is understood, thank you!
I noticed another interesting thing: When I bind the space-fake-event to
a mouse button and press this mouse button over a xev-window, xev,
according to the event output on the terminal, gets the spacebar's
key_press and key_release event before the button's key_press event,
which should trigger the fake event. But doesn't awesome also rely on
these events? But that would mean that the fake spacebar-event has to be
between the button's key_press and key_release-event, wouldn't it? In
this case they would still be two separated key-events, assuming that
xev gives a proper view on the logic of X11 and its event-handling.
Thanks and cheers,
Manuel
--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
root.fake_input() doesn't work as exprected
Hi, I'm experimenting with fake input and I'm failing epicly. I just do not get it to work. I tried to fake one press on spacebar, so I figured out what keycode this is (keycode 65, via xev) and wrote the following code: root.fake_input(key_press, 65, mouse.coords()[1], mouse.coords()[2], 1) root.fake_input(key_release, 65, mouse.coords()[1], mouse.coords()[2], 1) I put them into a function an call this function via another keybind. But unfortunately nothing happens, I assume I'm just using the function the wrong way (with wrong parameters/parameter format). Is someone used to this function and can help me? Thanks in advice, Manuel -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: root.fake_input() doesn't work as exprected
Hi,
now I'm totally confused.
On 19.11.2012, 21:37, Uli Schlachter wrote:
Works for me. I wrote the following into a terminal, pressed enter and a new
space got entered.
$ echo 'root.fake_input(key_press, 65) root.fake_input(key_release, 65)' |
awesome-client
Thank you, that indeed helped me, because it worked for me too in a
terminal. So I searched somwhere else and found out that my non-working
function works when I bind the function to a mouse-button via the
clientbuttons-table.
But doesn't work when I bind it to modkey+F2 or modkey via the
clientkeys-table. It is exact the same function, it works on a
mouse-button-bind but doesn't on a keybind.
Pressing Modkey+F2 (the same with modkey+z) over a xev-window gives me
just
MappingNotify event, serial 41, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 8, count 248
MappingNotify event, serial 42, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 8, count 248
instead of the key_press- and key_release-event.
Any ideas why this happens? Even though faking a keypress with another
keypress doesn't make much sense in practice, it should work, shouldn't it?
Cheers,
Manuel
---# attachement (just in case it's interesting for the problem, I don't
think so, but that doesn't mean anything, so just to make sure) #---
I put this into my clientkey-table:
awful.key({ modkey }, F2, functions.experiment )
and the functions.experiment is:
function experiment(c)
root.fake_input(key_press, 65)
root.fake_input(key_release, 65)
throwOut(Done!) --just puts out a message via naughty
end
Nothing special, I think.
--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: How to use thumb buttons of the mouse
Hi, I'd suggest running xev in a terminal. [...] Works perfectly, button is identified and usable. Now I just have to put functionality on it. Thanks! Is it possible, to throw a key-event via function? A lot of programs use keybinds for certain functions, but it's difficult to bind a button to them. For example, can I throw a Ctrl + P-Event to trigger play/pause in my music player, so that I can bind it to my mouse button in the clientkeys-table? Cheers Manuel -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
How to use thumb buttons of the mouse
Hi, I wondered how I could use the thumb buttons of my mouse. They are working as forward/backward-buttons in the programs that have that function, e.g. data browser, web browser, but simply do nothing with other programs. So I thougt about configuring them additionally, but is it possible to adress them in the config? At least I didn't manage to do so, what shouldn't mean anything. ;) Or do I have to configure them somewhere else than in awesome? Thanks in advice! Manuel -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Button with two button-actions
Hi, I want to have a button in my wibox which gives me a menu by left-clicking on it and one by right-clicking. I just wondered whether I could use an awful.widget.launcher for this, though it seems in the Reference API that a launcher can only handle one menu, but maybe I'm wrong, or whether I really have to use something else like a textbox or somewhat and bind all button-commands to it myself. Does anyone know whether a launcher can do that? Thanks in advance, Manuel -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
concerning widgets
Hi, I just wondered if the function vicious.widgets.[place-widget-name-here] can be called outside of a vicious.register-call. I think about it because I'm working on a volume-widget at the moment and this only needs to be adjusted when I change the volume level. So didn't register it with vicious but have functions called on mouse-events on the widget. But I quite like the output of vicious' predefined volume widget, so I wondered if it is possible to use it outside of a vicious.register-call, at least I didn't manage to do so. Is that possible at all? I could code all the stuff myself, but I think using the predefined function would be far more elegant. Alternatively I could use the predefined widget and just actualize it by function call, but since vicious.register expects the actualizing interval I don't think that this is a possible way, is it? Thanks in advice! Manuel -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: concerning widgets
Hi! On 11.11.2012, 20:47, Adrian C. wrote: anrxc@sputnik:$ lua widgets = require(vicious.widgets) print(widgets.volume(nil, Master)[1]) Ok, but is there somewhere an api-documentation of vicious? Or where can I look up what arguments the function needs (especially the nil in your example and Master being the second one)?. There's a force() function provided which can be called to update a widget on events like mouse scroll. Thats in fact comes very handy! Thanks! But force() just works on registered widgets, I assume? And if yes, is there any possibility to register widgets without having them updated (apart from setting the interval to sth. big)? I don't need that at the moment, but just to know it, if I really want to make a widget that needs to be updated just on events. But let's take me as an example, sometimes I will drop a terminal to run alsamixer. Or I can lower the volume in mplayer while watching a video. It's useful to have some timer on vicious.widgets.volume to reflect _those_ changes. That's indeed right. Well, I think I go on as planned for learning purposes and will do it with register() and force() finally. Thanks, Manuel -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: concerning widgets
Am 11.11.2012 23:15, schrieb Adrian C.: On Sun, 11 Nov 2012, Manuel Kasser wrote: is there somewhere an api-documentation of vicious? See README file. This one: http://git.sysphere.org/vicious/tree/README ? Because unfortunately at some widgets (for example the volume widget) there is only said what it takes as an argument (that it takes the name of the alsamixer control as an argument, but nothing about having the first one nil and the second one the control's name). But of course: Thanks for help! Manuel -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: GVim open partly offscreen
On 09.11.2012, 01:17, Adrian C. wrote:
Try ignoring size hints, at least for gvim class or instance. It's a
property like any other, you'll figure out how to apply it.
So, to my understanding, the rule must be sth. like this:
{ rule = { class = Gvim }, properties = { size_hints_honor = false } }
However, unfortunately it has no effect. In fact I just opened and
closed GVim a couple of times with the same file and the first time,
everything was ok, then it was again over the edge on the left and
stayed there the following times, but was sometimes resized zu full
screen width (so GVim was broader than my screen and reduced again to
screen width, but still shoved to the left. It doesn't seem predictable
to me.
Could GVim put his part to this problem somehow? I mean, awesome does
the window management, but it's just GVim having this.
Manuel
--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: GVim open partly offscreen
On 8.11.2012, 18:57, Vitor Eiji Justus Sakaguti wrote: You probably want to put those functions in the client.add_signal(manage, function (c) portion of your config. Also, I don't think nooverlap and nooffscreen are valid signals... Ah, thanks, indeed a mistake of mine. I also noticed both calls, awful.placement.no_overlap(c), and awful.placement.no_offscreen(c) are already put there, don't know why I did not see them in the first place. The manage-signal is still as it is in default rc.lua, I even commented out the if-statements but nothing changes. GVim is still opening partly outside the screen and in some cases, as I noticed, extends to the right side of the screen while being offscreen on the left. I'm quite confused why the awful.placement-calls don't work with GVim. Manuel -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: GVim open partly offscreen
On 8.11.2012, 23:38, Adrian C. wrote: Maybe it's the other way around; by forcing the gvim window to open with an offset it goes over the screen edge for reasons known only to it. So try disabling one by one then both awful.placement calls and repeat. Thanks for the proposal. It's in fact awful.placement.no_offscreen(c) what's causing it. But without this GVim opens above my wibox, which also isn't that nice. But why do you even float gvim? Wouldn't you be more comfortable with a maximized gvim in its own tag. It's a general tag for everyday stuff with a floating layout, that's why I float GVim. But I'm thinking of a separate tag at the moment. But since you do, you can try applying a custom geometry to gvim in awful.rules.rules. See xterm example here It's an idea, I think I'll try something like that. Also the last obvious question. Are you ignoring size hints for gvim (or all windows?). See size_hints_honor = false in your awful.rules.rules. There is nothing like that in my rules-table, so if it isn't standard I don't think I ignore it (correct thought?). Since the out-of-screen-part is the numbers of the lines I assumed that might be the cause (although I don't see why). Thanks for the advices. I'll try some of them. However, I'm still interested to solve that problem itself because this behavior doesn't seem logical to me. Manuel -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
GVim open partly offscreen
Good evening! I've got a little inconvenience concerning GVim: it always opens about 20 pixels off screen on the left while having exact these 20 pixels still free screen space next to it on the right hand side. And this really happens every time I open GVim in floating layout (and just then), even when I have put it to the right position last time (it's scaled to fit exactly the width of my screen). There was a hint in the awesome-FAQ [1], so I added client.add_signal(nooverlap, function (c) awful.placement.no_overlap(c) end) client.add_signal(nooffscreen, function (c) awful.placement.no_offscreen(c) end) to the very end of my rc.lua, but it doesn't fix the problem. As far as I noticed it's just GVim doing that. Does somebody have an idea how to prevent it from doing this (or making the proposal from the FAQ working)? Unfortunately I can't find any output of awesome concerning that specifying the problem, probably because it is indeed no technical problem as such. Thanks in advance! Manuel [1] http://awesome.naquadah.org/wiki/FAQ#How_to_prevent_floating_clients_opening_offscreen.3F -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: wibox.widgets - table-widgets are leftmost
Am 1.11.2012, 18:06, schrieb Uli Schlachter: Welcome to 3.4's widget layout code which causes all sorts of weirdness. [..] All that I can tell you is that 3.5's widget layouts will be more sane (IMHO, which doesn't mean much since I wrote the new code but didn't write the old one). Ok, thanks! I don't feel less confused, but at least it doesn't feel that bad now being confused.^^ Looking forward to awesome 3.5, Manuel -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: Externalise part of the wibox.widgets-code
On 31.10.2012, 19:15, Alexandru Băluț wrote: You can change these methods to return nil if you don't want the widget to appear. That's an idea. Well, I still prefer having just one function in my mspec-file that I change so I don't have to change the code that creates my widgets but just the one function that collects them (because then I can also insert separator-widgets dynamically, without adding these separators to the widget itself), but this does sound as a valid workaround. But I'm still open for ideas! ;) Or if you want to move that logic into rc.lua, you can use variables: myvolwidget = condition and mspec.volwidget() or nil That's exactly what I do not want. When switching to a entirely new system I do not even want to have to touch my rc.lua, I just want to make changes in my machine-specific file. Definitely: Thanks Andre and Alexandru! Manuel -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
wibox.widgets - table-widgets are leftmost
Hi,
I'm experimenting with the wibox.widgets-table of my wibox and I noticed
a confusing behavior:
I can place tables in the wibox and the objects in this, and I can add
an entry
layout = awful.widget.layout.horizontal.foo
to it. My wibox.widgets-code is shown down below. What confused me is
the fact, that the content of tables will be placed at the position it
is placed in the wibox.widgets-table ONLY when the internal layout is
the same as the global layout of the wibox.widgets-table.
Otherwise, if internal and external layout do not match, the contents of
the table are placed rightmost (with internal layout = rightleft) or
leftmost (when the internal layout is leftright), no matter whether
other widgets are put before or after them.
The order of the widgets of the table have the layout specified in the
table.
Long text to explain my question: Why does another internal layout than
the external affect the total order of the wibox widgets this way? Why
can't I place a table with another layout in the middle of the
wibox-table? Does that have a technical (or any other) certain reason or
is it just a decision of design? (Or maybe a bug, but I don't think so,
because I assume someone other will already have noticed this behavior.)
I deliver some examples down below (because I'm not sure I made the
problem clear, my text sounds quite confusing to me).
I hope I explained my problem clearly and I also hope someone can bring
some light into the darkness of my mind.
Thanks in advance,
Manuel
Code-excerpts:
VARIANT 1
mywibox[s].widgets = {
{
launcher,
taglist[s],
layout = awful.widget.layout.horizontal.leftright
},
layoutbox[s],
textclock,
{testwidget, testwidget, separatorline, layout =
awful.widget.layout.horizontal.rightleft},
tasklist[s],
layout = awful.widget.layout.horizontal.rightleft
}
With this code the wibox will be:
launcher, taglist, tasklist, separatorline, testwidget, testwidget,
textclock, layoutbox
VARIANT 2
mywibox[s].widgets = {
{
launcher,
taglist[s],
layout = awful.widget.layout.horizontal.leftright
},
layoutbox[s],
textclock,
{testwidget, testwidget, separatorline, layout =
awful.widget.layout.horizontal.leftright},
tasklist[s],
layout = awful.widget.layout.horizontal.rightleft
}
With this code the wibox will be:
launcher, taglist, testwidget, testwidget, separatorline, tasklist,
textclock, layoutbox
VARIANT3
mywibox[s].widgets = {
{
launcher,
taglist[s],
layout = awful.widget.layout.horizontal.leftright
},
layoutbox[s],
textclock,
{testwidget, testwidget, separatorline, layout =
awful.widget.layout.horizontal.leftright},
tasklist[s],
layout = awful.widget.layout.horizontal.leftright
}
With this code the wibox will be:
launcher, taglist, layoutbox, textclock, testwidget, testwidget,
separatorline, tasklist
--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Externalise part of the wibox.widgets-code
Hi,
I again need your advice.
The situation is, I have two machines running awesome and I want to
externalize every machine-specific part of my rc.lua so I just have to
sync my rc.lua upon changes and do not have to adapt it.
Part of this plan is that both computers shall use a different set of
widgets (e. g. I don't need a battery widget on a stationary system).
mspec is the file with the machine-specific parts of code, the widgets
itself are working well and are created inside the mspec-Methods.
At the moment, my wibox is constructed like this:
--variant 1:
mywibox[s].widgets = {
{
--launcher, taglist, promptbox
},
mylayoutbox[s],
mytextclock,
--MyWidgets
mspec.volwidget(),--Volwidget
mspec.netwidget(), --Netwidget
mspec.memtxtw(), --Memory-Widget
mspec.cputxtw(), --CPU-Widget
--EndMyWidgets
s == 1 and mysystray or nil,
mytasklist[s],
layout = awful.widget.layout.horizontal.rightleft
}
My idea was that I want to get an array of widgets by calling
mspec.getWidgets() --returns { volwidget , memorywidget , cpuwidget }
and cycle over this array and insert these widgets into my wibox.
I tried:
--variant 2:
wid = mspec.getWidgets()
mywibox[s].widgets = {
{
--launcher, taglist, promptbox
},
mylayoutbox[s],
mytextclock,
--MyWidgets
wid,
--EndMyWidgets
s == 1 and mysystray or nil,
mytasklist[s],
layout = awful.widget.layout.horizontal.rightleft
}
The problem with variant 2 is that the widgets aren't placed where the
widgets were placed in variant 1, between mytextclock and mytasklist,
but between the first array with the taglist and the promptbox and the
tasklist.
Does anyone have an idea how I could implement this intelligently
(preferred by using mspec.getWidgets() and its array)? A for-loop to
cycle over the array does not work inside an array, of course.
Thanks in advance!
Manuel
--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Addition: Externalise part of the wibox.widgets-code
Another Problem with variant 2 is that the widgets are placed one over
another instead of next to each other. I can see all the letters but
can't read them because they are on top of other letters. Quite strange,
I have to say.
Am 30.10.2012, 23:27, schrieb Manuel Kasser:
--variant 2:
wid = mspec.getWidgets()
mywibox[s].widgets = {
{
--launcher, taglist, promptbox
},
mylayoutbox[s],
mytextclock,
--MyWidgets
wid,
--EndMyWidgets
s == 1 and mysystray or nil,
mytasklist[s],
layout = awful.widget.layout.horizontal.rightleft
}
--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Fwd: Re: Click-sensitive widget
Forgot to CC awesome.
Hi,
On 27.10.2012, 14:26, Alexander Yakushev wrote:
You should use this one but the second like should look like:
cputxt:buttons(awful.util.table.join(awful.button({ }, 1,
functions.throwOutExampleMessage))
works! Thanks a lot. Quite strange because I tied something like
cputxt:buttons..., but I probably have just made a slight mistake which
broke my code.
As said: thanks a lot! Now I can continue doing my volume-widget.
Greetings
Manuel
--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Click-sensitive widget
Hi,
I've got another problem, hoping not to get on your nerves.
I want to make an audio-controlling widget, I thought of a simple
textbox displaying the volume in percent and the possibility of raising
the volume by left-clicking on it an lowering it by right-clicking.
So I tried to trigger a function call by binding a mouse button to this
widget, but I spectacularly failed.
I'm experimenting with my CPU-widget, which is a simple textbox-widget,
registered to vicious but I don't think that makes any difference.
The interesting code in my rc.lua:
Neither
cputxt = function-to-return-a-working-registered-cpu-textbox-widget()
cputxt.buttons = awful.util.table.join(awful.button({ }, 1,
functions.throwOutExampleMessage ) )
nor
cputxt = {}
cputxt.buttons = awful.util.table.join(awful.button({ }, 1,
functions.throwOutExampleMessage ) )
cputxt = function-to-return-a-working-registered-cpu-textbox-widget()
gives any example message. However, a
functions.throwOutExampleMessage(), inserted at the end of my rc.lua,
throws my example message as planned.
I don't get any errors not even a commentary from awesome, it just works
fine except for the fact that just nothing happens when I left-click on
my widget. cputxt is inserted into wibox.widgets as usual and also works
fine, it still shows me CPU-Usage as it did before starting the experiment.
According to the API [1] the way of cputxt.buttons should be working
(unless I misinterprete the reference API), as it does with tasklist and
taglist.
Does anyone see something obviously wrong with my code? (Or is just some
more info necessary?)
Thanks in advance,
Manuel
[1] http://awesome.naquadah.org/doc/api/modules/widget.html
--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: What should titlebars be like?
I'm in with the congratulations to you, Uli, awesome work! Are these titlebars wiboxes? And, just an idea, can one dynamically toggle the visibility of it so that I can kind of dynamically add and remove them to show me properties like CPU-Usage of it's client in it if I need to see this (despite the fact that this PID-Stuff isn't implemented, was just an idea coming up in my mind because I love awesome being hackable^^)? Greetings Manuel -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: What should titlebars be like?
Am 25.10.2012, 21:42, schrieb Uli Schlachter: The pid of a window is accessible as c.pid since ages. That is also available in awesome 3.4 (of course only if the client sets a _NET_WM_PID property on its window). You're right, I just misinterpreted something I read, I checked this, completely my mistake. Thanks again for all the infos! Cheers Manuel -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: What should titlebars be like?
Something that just came into my mind: a are the widgets of a titlebar/drawable at height 0 inactive or do they still perform their job and I just don't see them? -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: What should titlebars be like?
Thanks for the prompt answer! On 25.10.2012, 22:02, Uli Schlachter wrote: What do you mean with perform their job? Their job is to display something and they cannot display anything when their is no space. A CPU-Widget for example has do check on CPU usage periodically (1/s usually if I programmed it), which would be unnecessary if it isn't displayed (in case of CPU-widgets that would be no big problem, but I know me and I have no idea what crazy stuff I would try out in the titlebar...^^). And I think there might be some cases in which the widget might be better stopped if it isn't necessary. The question if such a widget should be in a titlebar is another one, of course. ;) Cheers Manuel -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: Widgets in external file
On 19.10.2012 12:45, Uli Schlachter wrote:
However, without module(), the module doesn't get placed into a global
variable.
This means you have to do
widgetfile = require(widgetfile)
This is a good thing!
Full ACK, this is imho really the best solution.
module() replaces the environment (_G) with a new, empty table. You could do
the
same directly with _G = {}. This new environment is accessible as _M. Because
it
is empty, nothing is accessible.
However, local variables aren't resolved through the environment and thus stay
accessible.
Ah, this is logical (even though I assume that the necessity of an empty
_G isn't given really often). And module being deprecated/disappearing
means _G won't disappear unless I do it explicitly?
This is the end of today's lua course. Man, I know way too much about lua...
I'm glad that I was allowed to participate, thanks!
Manuel
--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: What's the : for in lua?
Thanks Clément, thanks Alexander and thanks Yussi! I think I got it! Sounds definitely useful, now I can inspect the affected parts of my configuration for their functionality. :) Cheers Manuel -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
What's the : for in lua?
Hi, I've got a question not especially concerning awesome, but I'm sure some of you will know it: What's the :-operator for when I use it on an object (e.g. string:name() if that is a valid example). Searching for it with my standard search engine didn't help because I get a lot of lua-tutorials and wiki-pages, but those where the : is used to separate examples of code from the introductional text etc., which doesn't really help and I had no luck in finding a useful wiki page, where the operator is explained, just some, where it is declared as a special operator. Could someone help me? Thanks in advance, Manuel -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: Widgets in external file
Functions are normal values in lua. So you can give a function as an argument to another function. So I could write a function returning another function and can make the functionality of a keybind depending on certain variables? Cool. :D However, with lua 5.2 module() was deprecated. :-) Does that mean that require will work without the module()-line in the required file? And if module handles the placing of stuff of foo under foo.*, will that mean that this is also vanishing? Or does require take over at this point? Finally, I chose the require-way for me, because I prefer having the functions placed after the name of the file (sort of) they are in for better overview over the configuration. One question concerning that: why does stuff like local client = client work, more precisely: why is the second client accessable as the global one before module, but not after? Is this especially designed this way, that in this case lua checks for global variables or does it have another reason? Again thanks for your help, I think I'm getting into it! Manuel -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Widgets in external file
Hi,
due to using awesome on different computers I want to externalize some
widgets into another file, because I have to edit their code in the
rc.lua when porting the configuration file to another machine due to a
smaller screen size. So I want to externalize them to have a file with
width-adapted widgets for each machine.
Unfortunately I haven't found any explanation or example, so I hope
someone here can help me.
What I tried:
I created a file named widgetfile.lua, which contains:
local awful = require(awful)
local vicious = vicious
local widget = widget
module(widgetfile)
function makecpuw()
cputxt = widget({type = textbox})
vicious.register(cputxt, vicious.widgets.cpu, 'span
color=#9393ccCPU: $1%/span', 1)
return cputxt
end
The relevant part of the rc.lua contains (originally the first two lines
of the makecpuw-function were located at this point (and it worked well)):
cputxt = widgetfile.makecpuw
And a require(widgetfile) at the end of the require-block.
I would be glad if someone could help me getting this to work (or reveal
to me that it is technically impossible, which I do not hope).
Thanks in advance!
Manuel
--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: Widgets in external file
Am 17.10.2012 22:38, schrieb Uli Schlachter:
Well, it would help a lot if you would tell us which error you get. Because
your
code looks fine to me.
Oh, sorry, I forgot, because I do not get an error at all. I just have
no CPU monitor anymore.
I made it work just by changing cputxt = widgetfile.makecpuw to
cputxt = widgetfile.makecpuw(), inspired by you (probably routinely)
writing the function calls *with* brackets.
Therefore: Thanks a lot!
Do I usually call functions with brackets, but when I want to bind them
to key- or mousebinds, then I just give the name of the function and
awesome calls them itself (with brackets(?)) when triggered? Because in
the keybind-section I always place the fuction calls without brackets,
otherwise I get a crash of my configuration.
As you can see, I'm still a little bit inexperienced, sorry for the
circumstances.
However, for the purpose of experimenting and learning, I adapted the
code, the ~/.config/awesome/widgetfile.lua is now:
function makecpuw()
cputxt = widget({type = textbox})
vicious.register(cputxt, vicious.widgets.cpu, 'span
color=#9393ccCPU: $1%/span', 1)
return cputxt
end
The rc.lua is adapted by changing required(widgetfile) to
dofile(/home/me/.config/awesome/widgetfile.lua) and the line where I
put the widget into cputxt to
cputxt = makecpuw()
That's how it should be? At least, it's working this way, however, I
have to use the absolute path in the dofile-command, I can't use just
the file name nor ./filename, not even ~/.config/awesome/filename (I
guess ~ is a thing just for the shell).
And what's the exact difference between a module/required-command and a
dofile-command? And a dofile-file is treated as being part of the rc.lua
itself?
Cheers
Manuel
--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
transfering function code into separate file
Hi,
to get a better overview over my rc.lua-file I want to transfer all
function code into a separate file. For that I created a file named
functions.lua in my .config/awesome-directory next to my rc.lua.
The plan is to put all the function code into the functions.lua and just
call the functions by name in the rc.lua to make it shorter and better
readable.
I put a require(funtions) after the other require-calls into my
rc.lua and copied the function code (at the moment just three functions
for testing) into the functions.lua-file which starts with the line
module(functions).
The functions got names in the new file and are, as mentioned, called by
calling them by functions.[functionname] with [functionname] the
chosen name of the function in the functions.lua.
Unfortunately my configuration breaks, so obviously I haven't done it right.
Does anyone have an idea what's my mistake? Thanks in advance!
My testobjects were the functions in tasklist.buttons (surrounding code,
marked as awesome-config-code is from original rc.lua). My actual try
in the rc.lua is:
[code]
-- require-calls
require(functions)
-- some awesome-config-code
mytasklist.buttons = awful.util.table.join(
awful.button({ }, 1, functions.buttonone(c) ),
awful.button({ }, 3, functions.buttonthree() ),
awful.button({ }, 4, functions.buttonfour() ),
awful.button({ }, 5, function ()
awful.client.focus.byidx(-1)
if client.focus then
client.focus:raise() end
end))
-- more awesome-config-code
[/code]
And the complete functions.lua-file is:
[code]
module(functions)
--tasklist-stuff
function buttonone(c)
if c == client.focus then
c.minimized = true
else
if not c:isvisible() then
awful.tag.viewonly(c:tags()[1])
end
-- This will also un-minimize
-- the client, if needed
client.focus = c
c:raise()
end
end
function buttonthree()
if instance then
instance:hide()
instance = nil
else
instance = awful.menu.clients({ width=250 })
end
end
function buttonfour()
awful.client.focus.byidx(1)
if client.focus then client.focus:raise() end
end
[/code]
--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: transfering function code into separate file
On 08.10.2012, 21:08, Uli Schlachter wrote: Does that mean you are just moving functions out to another file? They were already separate functions before? Indeed, but a lot of functions are longer than three lines (e.g. the buttonone-function has 12 lines). My idea was to make the rc.lua shorter so I get a better overview over the logic structure of my config. I think bringing out the line-intense functions will make it short enough to be handled in one file and the functions are often functions called by certain keybinds etc. and if I want to change the functionality of a certain keybind it is quite unimportant whether this function is in the rc.lua itself or another file while the logic will still be in one central file. That's the idea behind. And as a bonus I can get used to modifying awesome. ;) Eventually I want to be able to use it's potential. If you want me to guess: [...] Do you really want to call the function here? I think you want functions.buttonfour instead of functions.buttonfour(). Bingo. Now it works, thanks a lot. Experienced people guessing is sometimes extremely helpful. ;) My mind was stuck to other programming languages (Java, C++), so I was on the trip thinking there have to be brackets after every method call. Probably functions in C are also called without brackets? Also, what's the c argument to buttonone? That's what awesome was also complaning about. Explanation similar to the one above: I assumed that do be a parameter that has to be passed to the function when it's somewhere else, but obviously the parameter (?) are known when specified in another file. However, his c argument was from the original awesome config (function (c) $functioncode end). I assumed it to be the actual client given as a parameter, so that the function can manipulate it? This accesses global stuff like awful and client. Those aren't visible in modules by default. To get them, you need special magic before the module()-call: Added, but it seem to work even if I comment these lines out. Well, I will observe that. Again thanks a lot. I'm still into the learning process. ;) Cheers, Manuel -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: transfering function code into separate file
On 08.10.2012 22:38, Manuel Kasser wrote: This accesses global stuff like awful and client. Those aren't visible in modules by default. To get them, you need special magic before the module()-call: Added, but it seem to work even if I comment these lines out. Well, I will observe that. Observation finished, it seems that I just forgot the restart, without the lines the functionality breaks. Just for completeness. -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: Improve hard coded numer of tags
I experimented with this:
--code
awful.key({ modkey }, F2,
function (c)
local taks = screen[mouse.screen]:tags() --get the tag table of the
current screen
--start counting tags
local takcount = 1
while taks[takcount+1] do
takcount = takcount + 1
end
--end of counting tags
local tak = awful.tag.getidx(c:tags()[1]) --getting the active
tag's number
awful.client.movetotag( (tak%takcount) + 1, c)
awful.tag.viewonly(tak)
c:raise()
end),
--end of code
But there are two problems: First, my attempt of counting the tags
returns one tag more than I have and I don't understand why, second I
get an error in the line where I want to get the active tag's number:
attempt to indes local 'c' (a nil value)
Feel free to use and modify it or parts of it and if you can make it work (or
have another working solution), please tell me. ;)
Greetings
Manuel
--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: getting count of all tags
Hi,
because I couldn't find a getn-function in the API I tried to code it
myself. But there are some problems remaining. This is my code for
moving a window on the tag right to its current tag:
awful.key({ modkey }, F2,
function (c)
local taks = screen[mouse.screen]:tags() --gets me the tag
table of the current screen
--beginning of counting tags
local takcount = 1
while taks[takcount+1] do
takcount = takcount + 1
end
--end of counting tags
local tak = awful.tag.getidx(c:tags()[1]) --getting the
active tag's number
awful.client.movetotag( (tak%takcount) + 1, c)
awful.tag.viewonly(tak)
c:raise()
end),
But there are two problems: First, my attempt of counting the tags
returns one tag more than I have and I don't understand why, second I
get an error in the line where I want to get the active tag's number:
attempt to indes local 'c' (a nil value)
Why does awesome can't access c, I thougt, the active client is passed
over to the function as the c in function (c)?
Thanks in advance,
Manuel
--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: getting count of all tags
Hi everyone,
thanks a lot for helping me and sorry for responding that late,
unfortunately I was unexpected busy last week and thus had no time to
deal with that matter.
I examined this part of code:
awful.key({ modkey }, F2,
function (c)
local tak = tags[1].getn(1) -- this shall give me the tag
next to the active one on the right
awful.client.movetotag(tak, c) --this puts the active client
c to the tag with the number tak
awful.tag.viewonly(tak) --this sets the tag where the
client have been put active
c:raise() --this sets the moved client on top of all on the
new tag (just relevant with floating clients, I think)
end),
But tags[1].getn(1) produces an error: attempt to call field 'getn' (a
nil value)
Might happen because tags is an awful.tag-object and I can't find a
getn-function in awesome's reference entry for awful.tag.
tags[1].getn() without a number does the same (no surprise if I really
call a nonexisting function).
The line of the original given function local tak =
myrc.tagman.getn(1) complains about a nil-value right at myrc. Maybe
I just have do adapt myrc and tagman, but I don't really know what
type of object they are.
Maybe you can help me again?
Thanks
Manuel
getting count of all tags
Hi, I wanted to write a function for awesome, so that I'm able to shove a selected client to the previous or next tag with a certain keybind. I can, even by default, already do this by sending a client to a certain tag, but I want do add the functionality for doing this for the next tag, no matter what tag is active. My problem is, I want the tag after the last tag to be the first tag, like a circle of all tags, but I think I need the total number of tags on my screen to do so. I could do that hardcoded, but to avoid inconsistency I would prefer to get the number of tags after they've been created, so I don't have to change an extra variable when changing the number of tags. But I wasn't able to find a function which gives me the number of tags on a screen (or I just misunderstood the documentation). I thougt about getting the actual tag number and then putting the client to the tag (number%totaltagnumber + 1) or (number%totaltagnumber - 1), depending on what direction is selected. If this idea means a whole amount of unnecessary, maybe inefficient code, I'm glad if you would tell me, I'm new to awesome (but already fascinated) and not very experienced. Thanks in advance, Manuel -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
