Re: [i3] How to display in `i3bar` (via `i3status`) the amount of free memory
Ciprian Dorin Craciun writes: > The whole purpose of `i3status` is that it's lightweight both in terms > of resources and OS calls. Wrapping it in a script that each second > spawns a bunch of processes just to add memory usage is counter to its > purpose... Just in case you are using i3bar in hide mode: In that case i3bar will SIGSTOP i3status anyway, when the bar isn't shown, so this won't be a huge problem. :) If you use it in docked mode of course, you are kind of out of luck with this.
Re: [i3] How to get i3wm statically linked?
Hi, Mike Bonar writes: > https://faq.i3wm.org/question/68/how-to-build-and-install-i3-from-sources/ > > How to build from source. this does not answer, how to link it statically. I have no real idea how to do that (and if it's possible) either. I tried building using LDFLAGS=-static and replacing --libs in the pkg-config by --static. That does not seem to be enough.
Re: [i3] i3-msg - move all/some workspaces to another output
I actually have the *exact* same problem and assigning workspaces to
VGA1 is not a real solution for me, as I regularly use the VGA port for
presentations and such and then I actually *don't* want any workspaces
(apart from the one running the presentation of course) on the beamer.
I currently use something like this, to move all my workspaces to VGA1:
#!/bin/sh
for i in `seq 10`
do
i3 "workspace $i, move workspace to output VGA1"
done
for i in `seq 10`
do
i3 workspace $i
done
i3 "workspace 11, move workspace to output LVDS1"
(I am not sure what the second loop was for… it had *some* point…), but
it is pretty racey and very often a workspace ∈ {1,…,0} remains on LVDS1
(most often something in {5,…,8} or so, and always an empty one).
I haven't found a solution to that yet and am not annoyed enough to
invest a lot of time into it, but *if* anyone has a race-free way of
doing that, I would be glad to hear it ;) I guess one way *might* be to
unroll the loop and send all workspace-switcheroo in one ipc-command, I
guess then i3 has no choice but do it sequentally in the right order…
Best,
Axel Wagner
Re: [i3] Suggestion: Configuration with lua
Hi, Timo Schmiade writes: > - Avoid maintenance of own configuration file format (features + bug > fixes) But adding the necessity to maintain a stable API towards LUA, which is a *lot* more difficult, actually. > - Is this something the i3 developers would want? This was actually discussed a lot. As far as I can tell, the general feeling is, that the IPC-interface is a far better approach. You still have to maintain an API, but at least you interface with *all* languages, not just one. Also, as mentioned, if anyone doesn't want to take advantage of scripting, there is a simple, stable, declarative configuration format. So, if you want to be able to easily script i3, a better investment of your time would be probably, to add more events and commands to the ipc interface. Best, Merovius
Re: [i3] i3 does not swallow title correctly
Hi, you should really look at the i3 logs, as often windows change their titles and such *after* they are mapped and afaik firefox is a prime example of this. So the state of the window when you run Xprop is really no indication as to what you should put in your i3 config (as this is afaik applied during mapping, as this is the only sane thing to do). Best, Merovius PS: In the future, could you pretty please attach large logs as files, instead of pasting them inline?
Re: [i3] window focus with pidgin-im
Hi, > which in turn leads to new chats in auto-opened mode do not get raised > to attention. if there are any hints how i can help to catch that > secret signal pidgin might be sending or not, i am happy to follow > along. I use the "message notification" plugin (comes per default, I think) and have it configured to set the URGENT hint. This will highlight the chatwindow (and the workspace it's on in i3bar) whenever you get a new message. Best, Merovius
Re: [i3] monitor dependent workspaces
Hi,
I think the easiest way would be, to have a perl-script, that gets the
currently active output over IPC and sends the command "workspace
$1_{output}", when called with "scriptname n", then put into your config
file something like this:
bindsym 1 exec /path/to/scriptname 1
bindsym 2 exec /path/to/scriptname 2
…
workspace 1_DPI1 output DPI1
workspace 2_DPI1 output DPI2
…
workspace 1_eDPI1 output eDPI1
…
Alternatively you could do without an external script, by using modes in
your config, so effectively duplicate all your bindings into two modes,
just change the keybindings for switching between workspaces. Then have
a binding to toggle between modes (effectively switching outputs).
Best,
Axel
Re: [i3] [i3lock] blur effect
Hi Karl, nice idea, but I don't really understand why you not just draw on i3lock's window? That way you don't have to maintain a fork, we keep the number of forks to a minimum (so… 0 hopefully ^^) and still everyone gets to implement their favourite thingy as a wrapper. You can use "xwininfo -name i3lock" or something similar to get the window id of i3lock. Just a thought. Best, Axel
Re: [i3] conky output on i3lock
Since I used the wrong mail-address before, again to the mailing-list: Hi Michael, Michael Stapelberg writes: > I’m slightly confused. What would I need to merge? Your reference points > to an i3lock-external shell script (which I have attached to this > message, so that it doesn’t get lost when sprunge garbage collects). Sorry, I wasn't very clear here. I can see mostly one shortcoming of a script like this to the mentioned fork: The inability to log and display failed login-attempts. Currently the only way to do this would be to run i3lock in debug mode and grep for "Authentication failure", counting the lines, that come up and show this somehow in conky. I see this as a little bit ugly (but nevertheless possible, it only occured to me later), so a nicer way would be for i3lock to output failed attempts even without debug-mode (possibly with an additional switch?). So no, there actually is nothing to merge yet. If someone wants this functionality, that _might_ be a way to do it, _if_ a change like this (in some way expose failed login attempts) would be accepted. As I said, I just wanted to dump some of my thoughts and results of a bit of discussion, in case someone might be interested in doing such a thing. Best, Axel
[i3] conky output on i3lock
Hi all, there has been people who want to display time and similar statistics in a locked screen. In fact there has already been a fork [1] to do such things. If you want something similar, but don't want to follow or maintain a fork (and don't need the number of failed unlock attempts), you might also use a conky instance that is configured to draw on the i3lock-window. Without much testing, any commitment to maintain anything and just as a starting point, I provide [2], which is a working proof of concept. If someone has interest and the time to further expand upon this script and make it more stable and widely usable, I would be very glad and appreciate a notice. If Michael would be willing to merge something like this, you could probably also add the number of failed unlock attempts, by having i3lock output a message on stdout/stderr on a failed attemp, counting them and using this in conky (or else grep through the debug-output). I think that would be general enough to not add a lot of bloat to i3lock, while still enabling some nice usecases. But I did not think that through yet. Best, Merovius [1] https://github.com/popoffka/i3lock [2] http://sprunge.us/jiJg
Re: [i3] error: i3-wm: signature from "Thorsten Töpper " is unknown trust
Hi, this appears to be an archlinux-specific problem. Maybe you should consult the arch-forum, maybe there is a solution there. Best, Merovius
Re: [i3] Feature request: disable switching to virtual terminal with i3lock
Axel Wagner writes: > [1] https://github.com/dannyn/slimlock/blob/master/slimlock.cpp#L86 Ohm, scratch that, I should read before I rant, I overloocked the run/var difference. My other points are still valid, though.
Re: [i3] Feature request: disable switching to virtual terminal with i3lock
Hi, Izzy writes: > There's just one thing that kind of bothers me, though: with slimlock > it's possible to use an option (called 'tty_lock') which disables > switching to another virtual terminal while the screen is locked (using > VT_LOCKSWITCH). > > I think this is a nice "security feature", if you wish. So, I was > wondering: first if this would be desirable in i3lock, and in that case > if it could be possible to add a similar option. It doesn't seem to be > _that_ difficult to implement, but unfortunately I don't know C, so > submitting a patch is out of the question. Yuck. I'm no expert, but this seems only possible, if you run as root. And indeed, slimlock is installed setuid root. I don't think, it is very wise, to have an X-application run as setuid root, let alone i3lock, I'm not sure, the code is ripe for that as that's not the security model it was written under. I also wouldn't use slimlock in the future, btw. I wouldn't trust any application with code like [1] for security-sensitive purposes (let alone having it setuid root). Indeed, AFAICT slimlock is not even dropping it's priviledges at any point. So, IMHO you grossly underestimate the complexity of doing this right. You would probably need a seperate setuid-helper-binary for that and you would have to worry about what the security-implications of this feature are (for example: What if I log in, lock all terminals and lock out again? No one would be able to use them. Is that acceptable?). I think you better look for some application that does this standalone and add it to your i3lock-invocation. Best, Axel [1] https://github.com/dannyn/slimlock/blob/master/slimlock.cpp#L86
[i3] [OT] shellex - shell based launcher
Hi all, though not really i3-specific, there were a few people in the past who asked in the IRC-channel for a command launcher with history support and tab-completion. Some people use bashrun for that, some people where referred to shellex, an old try at a zsh based launcher of mine, which was in no state to use. I recently restarted work on shellex [1] and would like to announce it here in case anyone is still looking for such a thing. It is still WIP and not yet as comfortable to use as dmenu, but I now consider it stable enough to be used and to be usefull (for example history and tab completion worked on every system I tried). Kind Regards, Merovius [1] https://github.com/Merovius/shellex signature.asc Description: PGP signature
Re: [i3] Containers in i3
Hi, Excerpts from Harry Allenby's message of 2013-07-15 07:50:39 +0200: > I'm a very literal-minded mathematician Then let me, as a fellow mathematician try to explain at least part of your questions ;) > (3) I just don't grasp the concept of a container in i3. It seems to > me that the basic objects are windows, and that "container" is a > derived, relational notion, namely: two windows may (or may not) be in > the same container. [So, mathematically, I think of a container as an > equivalence class of windows; but I don't know what the equivalence > relation is.] Mathematically it is pretty simple. Containers are nodes in a tree, whose root the X-root-window is. Children of this root level there are individual outputs, children of the outputs are the workspaces, whose children in turn are the container-trees containing the windows you see. A container can either be an inner node containing more containers (I think this is called a „split-container“ in the documentation), or it can be a leaf, containing a window. The nodes are not all equal, leafs contain windows and near the top of the hierarchy there has to be special treatment (to use the more user-friendly abstractions of outputs and workspaces), but mostly this should be the way to think of it. > (2) If I press mod+v and make some windows, are they all in the same > container? If I now press mod+h and make some more windows, are they > in a different container? Yes and no. If by „window“ you think of „a leaf node in the container tree“, then yes. If you create some windows (for example pressing Mod+Enter to open some terminals), then each one is put in an individual container. These containers are then put in a big container. If you then press mod+h, the currently focused node in the tree (which would be a leaf in most cases, so a container having a window inside it) is replaced by a new container, with the old content as a subtree. If you then open some windows, they are new leafs which are put in that new container. So I think the solution here is to stop thinking about windows as entities in the container-tree, because they're really not. The container-tree is an abstraction used by i3 and leaf-nodes in this tree have a window-property attached to them. > (1) I'm sitting in front of an i3-screen with a focused window. I want > to know (preferably in a semi-algorithmic statement), if I press Mod + > s, exactly which windows will be stacked. In particular, does the > answer depend on the history of the focused window? I'm actually not very clear of this myself. It just magically does exactly what I want. I _think_ the container being stacked is always the parent of the currently focused container. So, if you just open a bunch of terminals on an empty workspace, focus one of them, your layout would be something like (I apologize for my crude ASCII-art): Workspace / | | | \ C1 C2 C3 C4 C5 | | | | | T1 T2 T3 T4 T5 With C1…C5 being node-containers and T1…T5 are the five windows attached to these node-containers. Pressing Alt+s would (if you focus for example T1, or rather C1) stack all your terminals. If on the other hand you open some terminals, split one leaf and open some more, your tree will look like this: Workspace / | \ C1 C2 C3 || / \ T1 T2 C4 C5 || T4 T5 Now if you focus C4 or C5 and press Mod+s, you will get a workspace with two terminals visible (T1/T2) and one stacked container (C3), containing two terminals (T4/T5). If on the other hand you focus C1 ore C2 and press Mod+s, you will get a stacked workspace and can cycle between T1, T2 and (T4+T5). One small warning: I think near the top of the container-tree (at the workspace-level and above) there is some special-casing regarding this, because you cannot sensibly „stack“ workspaces. So if you try focusing an entire workspace (via focus parent) you just might get unexpected results. So, I hope I could make at least some things more clear. Maybe I confused you even more, in that case „sorry“ ;) Kind regards, Axel signature.asc Description: PGP signature
Re: [i3] i3bar: toggle mode
Excerpts from justus jonas's message of 2013-04-13 18:24:00 +0200: > What do you think? It makes everything I personally want from it possible, so a big thumbs up from me for implementing this feature I always wanted but always was to lazy to build ;) When I started writing this mail, it came to me, that we can really do without the force_unhide-mode, which would reduce the configuration-complexity. If someone (like me) still want the feature, the simplest thing is to advice them to send i3bar a SIGSTOP when hidden to force_hide and a SIGCONT to return to normal operation. Though that may have unintended side-effects (not sure, how well the process-management works with it, for example) it is probably best to fix those anyhow. Hope this helps, Axel signature.asc Description: PGP signature
Re: [i3] i3bar: toggle mode
Hi all, basically I like Michael's way, just a few additional questions/thoughts: How does the manual toggling play together with the autohiding and the urgency-hint? Because I (obviously) like the way it's done now, in general, but also would want to take advantage of an explizit hiding or showing (for example hiding it despite urgency-hints during presentations, or watch some output of i3bar for a while). There are a couple of reasonings one could take, which would suggest different behaviours, I for my reason would like the following, if it is not too complicated: When mode is hide, do the old autohiding thing, if sent a „hide“-command, make it hidden (i.e. ignore urgency-hints and hide-modificator), if sent a „show“-command, make it show (i.e. treat the hide-modificator as always pressed). Excerpts from Michael Stapelberg's message of 2013-04-13 15:59:14 +0200: > 2) Introduce a new i3 command named “bar toggle” (bonus points for also >implementing “bar show” and “bar hide”, they are trivial), that >optionally accepts a parameter, which is the bar id. For this, imho, there should also (but possibly later in a seperate patch) be a way to identify the bar in the config. As far as I know, the identifier currently is a random string generated by i3, but if there are key-bindings in the i3-config to controll the bars, this is not sufficient, because it is only know at runtime (is it?). > 3) Users configure e.g. “bindsym $mod+x bar toggle” in their i3 config, >i3 sends the config update with “hidden” as state to all bar >instances (or only the specified one). > > The advantages are: > • i3 already provides keybinding configuration, so it should probably go > into i3 anyways Again, in the long-run, this could also mean simplifying i3bar by ripping out all this key-handling-code and have i3 handle that - it would only be the continuation of that logic. That would mean that (to make the current behaviour possible) we need to be able to make bindings on key-press and key-releases. Well, all that just as general thoughts ;) The latter two have no immediate significance to this feature, but the first should be decided. signature.asc Description: PGP signature
Re: [i3] i3bar POC: workspace button with focused window name
Hi,
what justus said was also my first reaction. Everything you explained in
your second mail is pretty much implemented conceptually, with the
“caption” being called name and “identifier” being the number.
The complexity of the needed ipc-script is reduced accordingly, you only
need something like:
while true:
wait_for_event
workspaces = get_workspaces
for each workspace:
active_con = null
for each container:
if container.focused:
active_con = container
break
workspace.rename("%d: %s", workspace.number, active_con.title)
With one of the libraries existing that encapsulate the
i3-protocol a working script should not be very much longer than the
pseudocode above (I'm actually not sure wether the number-syntax works
in the rename command, if not, that would be a nice thing to implement
too, imho ;).
I also presume that a change as you originally proposed would not be
accepted in the mainline i3, for the reasons I mentioned, but I only
extrapolate from similar proposals in the past.
Kind regards,
Axel
signature.asc
Description: PGP signature
Re: [i3] i3bar POC: workspace button with focused window name
Hi, Excerpts from Fam Zheng's message of 2013-03-21 04:16:32 +0100: > Of course a bar option can be added too to enable/disable this > feature. Or even give some sophisticated format option for the title, > and also enable user to manually rename it. Would this feature be > useful? > > To do this we need to add a few new events trigger and maybe a "title" > field in get_workspace msg. I already have a demo modification for you > to test how it feels, based on master. Now my life with many > workspaces is much easier. :) I think the only modification needed to i3 would be a focus-change-event (and maybe with a little hack not even that) and what you want can be entirely done with an ipc-script, no modifications to i3bar necessary. So I would do it like that: Have a daemon running that listens for focus events, everytime such an event is triggered, get the current workspaces, find out for each one, what window is currently focused (maybe the focus event could include the „change“-data which would make this step unnecessary) and change the title of that workspace to the title of that window. As I said, I think it could also be possible with a little „hack“: By using the workspace-event you could change the title everytime you change away from a ws. Then you would have accurately titles for every ws _not_ currently focused, which should be enough for getting an overview. I think i3bar is definitely the wrong place to do what you want, though it is a good idea. Doing it in i3 (by including an option to change the ws-title to the currently focused window) would be better, because then the feature would be available to users of alternative ws-bars, if they exist. But this would still be a lot of complexity added to i3 in C for something, that can be done with IPC and a scripting-language. Implementing the focus-change-event you should do in any case, imho, because I ran over a few usecases which would profit from that in my time. Regards, Axel signature.asc Description: PGP signature
[i3] [PATCH] i3-dump-log: Correct comment to reflect truth
I just stumbled upon this comment in i3-dump-log. I assume, this is what was intended, as we obviously have to read. Also, a few lines later, the comment again refers to O_RDWR, though there it should actually be PROT_WRITE. Regards, Axel 0001-i3-dump-log-Correct-comment-to-reflect-truth.patch Description: Binary data signature.asc Description: PGP signature
Re: [i3] vi and ADM-3A terminal
Hi Daniel, Excerpts from Daniel Bolgheroni's message of 2012-04-26 16:52:01 +0200: > Are there any reasons to shift "right" the classic vi 'hjkl' directions > commands to 'hjk;'? Yes, hjk; is on the homerow, that is, you don't have to take your hands of your keyboard, while typing, to navigate your windows. > There is a historic reason for using 'hjkl': > > http://www.catonmat.net/blog/why-vim-uses-hjkl-as-arrow-keys/ > http://news.ycombinator.com/item?id=3684763 I personally don't care that much about “historical reasons”, the whole qwertz-layout-thing is due to “historical reasons” and it sucks ;) > Besides this, there is a practical reason too. On a lot of non-US layout > keyboards, ';' doesn't come at the right side of 'k', where 'hjkl' is > almost universal. This makes a pain use i3 with the default conf. In the default, i3 should run the configuration-manager at startup. The default-config uses keycodes and it should use your current keyboard, to transform that into keysymbols. Therefore the layout you use shouldn't matter in the default-case. If you switch layouts often, use the default-default-config (in /etc/i3/config in debian, or in ./i3.config in the source), it uses keycodes and will therefore automatically adapt to your needs ;) The main developer (and the biggest userbase at least in the beginnings of i3) uses a non-US-layout by the way ;) Kind regards, Axel signature.asc Description: PGP signature
Re: [i3] How to restart i3bar?
Hi, how about $ i3 restart or (if you don't want to restart the whole of i3) $ i3 reload $ BARS=$(ps -C i3bar -o args=) $ killall i3bar And then execute every line of $BARS again (I'm not that good in shellscripting, sorry)? Regards, Axel signature.asc Description: PGP signature
Re: [i3] EWMH for panels
Hi, Excerpts from Alexander Corvinus's message of 2012-03-20 15:21:17 +0100: > Can you please elaborate, which hints need to be set? You need to set the window-type to _NET_WM_WINDOW_TYPE_DOCK and set the _NET_WM_STRUT_PARTIAL property, which basically says how much space you want and where you want to be placed. You can find an example of both in i3bar/src/xcb.c:1241 resp. i3bar/src/xcb.c:1283. Furthor information about _NET_WM_STRUT_PARTIAL is provided in the EWMH-spec [1] > Can they be set in something like devilspie? I looked at [2] and there does not seem to exist an action to set STRUT or STRUT_PARTIAL, but you can set the window-type. Oddly there appears to be no way to set arbitrary EWMH-properties, which I find pretty unflexible… I don't know from the top of my head, what i3 does, when you request to be docking but don't set STRUT_PARTIAL. Iirc it used to put the window at the top of the screen. > Even dzen2's stable release currently can't set > them on its own, so panel overlaps windows or other content. This is only because the developer of dzen2 hasn't done a stable release in years. The code exists in the svn-repository for quite some time ;) Regards, Axel [1] http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2578550 [2] http://www.foosel.org/linux/devilspie#actions signature.asc Description: PGP signature
Re: [i3] i3status patch
Hi, I could think of a few, maybe not that critical ones - for example you could have a hook for some updates (like ethernet or battery-status, just to name two), which sends a USR1. This would then make the information more „realtime“ with a one-second update while not putting additional stress on the system for refreshing _all_ the information several times a second. Yipp, not very important, an event based statusline-generator (like dstatus from fernando) might be better suited for ppl who want that… regards, Axel signature.asc Description: PGP signature
Re: [i3] [PATCH] Improved i3bar hide mode behavior (In my point of view)
Excerpts from DR's message of 2012-02-22 10:15:41 +0100: > When the urgent workspace is currently focused, i3bar will hide as > soon as the urgent mark has gone. excellent, when this patch does, what you're saying it does, it fixes a bug, that has bothered me from the beginning, but I never had the nerve to fix ;) Regards, Axel signature.asc Description: PGP signature
Re: [i3] question about 'containers'
Hi Alex,
Excerpts from Alex V. Koval's message of 2012-01-29 17:50:32 +0100:
> For example, I can not find any information what does mean 'another
> container' which appears sometimes on top?
This is the title of a container, that does not contain a window, but
only other containers.
Let me illustrate this with an example:
1. You open up a terminal
This creates a container with a window. The title of the container
becomes the title of the terminal.
2. You open a second terminal
This does the same as above, but it will also do more - the two
containers are now put together into a bigger one. Each child will have
the title of the terminal it contains, but the parent-container does not
contain a window, so it get's the title „another container“. You
normally don't see that, because containers without windows don't get
titles. There are however a few exceptions:
3. You put the parent in stacked mode. This will show a seperate titlebar
for every child of the parent, displaying it's title.
4. You then select one of the children and split it up (and say, just for
the sake of the argument, that you open up another terminal there after
that).
Now you have a tree like this:
C1
/ \
T1 C2
/ \
T2 T3
Where T stands for a container having a window (the terminals) and
C{1,2} are containers, that merely have child-containers.
Now the title of C2 will be „another container“ (as above and normally
not shown) and be shown in the titlebars of C1.
So I hope that cleared it up somehow. Just think of „another container“
as meaning „there isn't just a window below this, but a whole tree“.
I think the wording „another container“ is a remnant from times, where
the tree-thing was still very experimental and that it will be replaced
by something more meaningfull in the future.
Kind regards,
Axel
signature.asc
Description: PGP signature
Re: [i3] track changes on the doc page
Excerpts from Marcus Moeller's message of 2012-01-29 09:35:57 +0100: > is there a way to receive a notification if the user doc page has been > extended/changed? http://code.stapelberg.de/git/i3/atom/docs/userguide?h=master replace ”master“ by the branch you want to track. Regards, Axel signature.asc Description: PGP signature
Re: [i3] Exchangin Mod1 and Mod3 in config file
Hello jorge, are you sure, that the windows key is Mod3? It's Mod4 on most systems I saw. Try looking for "Super_L" in the output of xmodmap to be sure. Kind regards, Axel signature.asc Description: PGP signature
Re: [i3] rpm .spec file
Hi, Excerpts from Jan Krcmar's message of 2011-02-28 18:12:20 +0100: > i've just written .spec file for version 3.e-bf2, maybe it would be > useful rpm users, great ;) But I guess „improved tiling window manager“ makes for a better slogan, than „completely written from scratch“ ;) Regards, Merovius
Re: [i3] Nested key bindings?
Hi, if I'm not totally mistaken, the new command-parser of -tree was supposed to support command-chaining, I remember explicitly talking about that to sECuRE. So with command-chaining you could do something like the “bind Mod1+34 exec 'i3-msg "h"; i3-msg "mode default"'“-stuff with i3-internals. Iirc the mode-stuff was one of the reasons I suggested command-chaining as a vital part of any new command-syntax in the first place. So though sECuRE noted it as „nice to have“ my answer would have actually been „planned for -tree“ ;) Greetings, Merovius
[i3] Testmail
This is a testmail. Hope it makes sECuRE wheep of joy ^^
