Re: [i3] How to display in `i3bar` (via `i3status`) the amount of free memory

[Axel Wagner]

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?

[Axel Wagner]

Hi,

Mike Bonar oldp...@gmail.com 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

[Axel Wagner]

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] i3 does not swallow title correctly

[Axel Wagner]

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

[Axel Wagner]

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

[Axel Wagner]

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

[Axel Wagner]

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

[Axel Wagner]

Since I used the wrong mail-address before, again to the mailing-list:

Hi Michael,

Michael Stapelberg mich...@i3wm.org 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

Re: [i3] error: i3-wm: signature from Thorsten Töpper atsut...@freethoughts.de is unknown trust

[Axel Wagner]

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]

Hi,

Izzy m...@izzybl.tk 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

Re: [i3] Feature request: disable switching to virtual terminal with i3lock

[Axel Wagner]

Axel Wagner m...@merovius.de 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] Containers in i3

[Axel Wagner]

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

[Axel Wagner]

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 POC: workspace button with focused window name

[Axel Wagner]

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

Re: [i3] i3bar POC: workspace button with focused window name

[Axel Wagner]

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

[i3] [PATCH] i3-dump-log: Correct comment to reflect truth

[Axel Wagner]

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

[Axel Wagner]

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?

[Axel Wagner]

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

[Axel Wagner]

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] track changes on the doc page

[Axel Wagner]

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