Thanks for taking the time to follow up. I hope my reply makes things more clear.
On Fri, Oct 16, 2015 at 11:33 AM, <frede...@ofb.net> wrote: > Hi Michael, > > Thanks again for the great piece of software. > > I'm replying off-list because I didn't want to get into a public > I’m adding the list to CC again because I think the clarifications might be useful not only for you, but also for other people interested in the thread. I hope you don’t mind. > argument - at first I thought you were a troll, and then I saw that > you're the author of i3wm! :) Maybe I'm not realizing something about > my suggestions, but here is some more clarification in response to > your comments: > > (regarding i3-config-wizard) > > > The key _positions_ make some sense, the key mnemonics likely don’t. > > I don’t think this is a big problem, as users are very likely to > > change their config file anyway. Also, you’re free to use/not use > > the wizard as you see fit — for most users, using the wizard seems > > to be the best solution, which is why it’s started by default. > > If I recall, the wizard runs (or offers to run) by default, and > doesn't explain what it's doing, so new Dvorak users don't have a > warning of why the config file bindings look so strange - nor do they > have any indication that another option is available for obtaining a > default config. I don't know why you say it seems to be the best > solution for most users - obviously, most users are Qwerty users, for > whom the config wizard does almost nothing, it just queries the user > for a modifier key, IIRC. > It asks for the modifier key and creates the config file. Both of that could be achieved by using “sed 's/$mod Mod1/$mod Mod4/g' /etc/i3/config > ~/.i3/config”, yes. The main point why the wizard starts by default is that the default config file has to use Mod1 (Alt by default) because there are computers which don’t have a physical Mod4 (Windows by default) key. We strongly want to encourage people to use Mod4 as a modifier, because that avoids clashes with key combinations that other software uses. At the same time, we cannot make the default config use Mod4, because then i3 would just not work on computers which lack the Windows key. > > I think we both understand the rationale of the config wizard: it > makes the navigation keys match up - but all the other keys become > wrong, which means that 95% (rough estimate) of the config file is > 13 lines out of 69 lines in the i3 default config are bindings that use keys whose positions typically change depending on the layout — that’s not even 20% :). Regardless of the numbers, I think it boils down to personal preference: i3 currently goes the route where the positions make some sense (navigation keys first and foremost, but also how the remaining keys are positioned). Some people might prefer the mnemonics to make sense. It’s impossible to please both crowds. > wrong. On my system, /etc/i3/config already has variable aliases for > the navigation keys, which seems like a much better solution (didn't > check whether this is part of the Arch package or your i3wm > distribution) > > set $up l > set $down k > set $left j > set $right semicolon > > Why would anyone not prefer to just have a copy of this file in ~/.i3/ > to start out with? > > I'm not sure but it seems like Layus was also agreeing with me in his > reply: "Also, it is easier to have the same bindings on all > installations, even if misplaced. This way, the tutorials can assume > that the users all have Mod+p [sic] for restart." > > > Does “workspace_layout tabbed” do what you want? > > Yes, thank you! > > > Can you please send a pull request for https://github.com/i3/i3 > > which adds an explanation where you think it makes sense? > > I'm not familiar with git but I'll give you a human-readable patch. In > the i3 man page, after: > > Window > > An X11 window, like the Firefox browser window or a terminal > emulator. > > I would insert > > Floating Window > > A window which "floats" on top of other windows. This style is > used by i3 to display X11 windows with type "dialog", such as > the "Print" or "Open File" dialog boxes in many GUI > applications. Use of floating windows can be fine-tuned with > the for_window command (see HTML userguide). > > I think that should be more than enough - I originally became > frustrated when not finding the word "dialog" in the man page. I hope > the last sentence isn't out of place. If you want an actual patch for > that text, let me know. > https://github.com/i3/i3/commit/d56264e00185023d433a913ef468428d345a3c7a > > > > - Even after learning the "floating toggle" binding it sometimes > > > becomes annoying or confusing to have to press it each time - > > > for instance if I have to print a lot of stuff in Firefox, but I > > > sometimes want to navigate to other windows when the print > > > dialog is open. I also sometimes accidentally turn Firefox into > > > a floating window when I'm doing this, and then I wonder where > > > all the other windows went.... I would appreciate an option to > > > have dialogs always come up as windows by default. > > > If the print dialog is clearly meant to be floating, Firefox should > > set the appropriate window hints. Since you describe you have to > > manually make it floating, apparently Firefox doesn’t. You should > > file a Firefox bug, but you can work around this with a for_window > > rule, see > > > http://i3wm.org/docs/userguide.html#_arbitrary_commands_for_specific_windows_for_window > > You misunderstood, sorry - I was intending to describe manually making > windows unfloating. I used the suggestion of Layus, > Ah, sorry, should have read more carefully. > > for_window [title=".*"] floating disable > > which works great. If I were you I might put a commented-out copy of > this line in the default config file, but then if I were you I > The default config file is intentionally kept rather short so as to not overwhelm users. I’m aware of software which goes the opposite route, e.g. the dovecot config file, which is a reference in which you can remove the comment sign in front of lots of examples. Again, this is just a matter of preference. While the use-case you have is certainly valid, consider that there are hundreds of equally valid use-cases. I don’t think listing them all in the default config file is a good idea. > wouldn't have written the floating window support, not to mention the > rest of the window manager. :) > > > > - "focus right" is not always the reverse of "focus left". For > > > instance, if the rightmost tab is split horizontally, then one > > > command will cycle through all the windows, but the other will > > > get stuck cycling through the children of the tab which has been > > > split. Same with "focus up" and "focus down" in the stacking > > > layout, when a child is split vertically. It seems it would be > > > cleaner to have these pairs be strict opposites. > > > There are several places where the directional commands don’t > > strictly operate on the tree and hence focus left/right are not > > always direct opposites. We believe that bottomline, this makes it > > easier for users. Even if it didn’t make it easier for users, > > changing it now would be very disruptive to existing users, so I > > don’t think we can do much about it. If you feel strongly, you might > > be able to implement your own logic using the IPC interface: > > http://i3wm.org/docs/ipc.html > > I'm not sure if you tried out my example. It seems quite weird that > I didn’t try it at the time, both because I’m usually very pressed on time, and also because I’m not good at understanding what people mean when they talk about window hierarchies. I tend to ask for specific commands to reproduce layouts. I take it you used <open window>, “layout tabbed”, <open window>, “splith”, <open window>. Note that in such a situation, you can use “focus parent” to get out of being stuck. > navigating the focus to the right gets stuck in a container only if > the container is (1) at the far right, and (2) has multiple child > windows. If the container is in the middle, or has only one child > window, then we can move out of it with 'focus right', but otherwise > we get stuck. Why? When you said "We believe that bottomline, this > makes it easier for users", I thought he's just trolling or being > To clarify, I didn’t mean to say “this specific behavior is easy for users”. What I was trying to convey is that the logic which the directional focus commands use is made such that many use-cases are intuitive (notably these which plenty of users reported as confusing). The price for that is that in some other situations, the logic is not ideal. > defensive or something. Also, the assertion that "changing it now > would be very disruptive to existing users" seems highly questionable > ("very"?). But maybe I'm just not smart enough to figure out the use > Empirically, we have enough users that almost every change which is not an addition of new behavior will affect existing users. Most of these changes affect edge cases, but changes to the focus command have a much bigger chance of being disruptive, just because every single i3 user uses the focus command. In addition, the focus command is not something about which you think before using it; it quickly goes into your muscle memory. I think it deserves special attention. i3’s take on backwards compatibility is rather strong. We try really hard to not break configuration files or existing workflows. > cases you have in mind. You don't have to waste your time explaining > it to me, I'm just communicating my reaction to you in case you wanted > to know. > > (regarding i3-nagbar) > > > It’s designed to nag you, so this is working as intended :). > > Are you really saying that your software is intended to be annoying? > In general, my software should be the opposite of annoying. In the case of i3-nagbar specifically, though, yes, it absolutely should be annoying. The reason depends on the occasion on which you get to see i3-nagbar: 1. You have an error in your configfile: i3-nagbar nags you so that you don’t nag us. Historically, before we had i3-nagbar, a very frequent bugreport we’d get was caused by users who had a configuration file error and did not know about the logfile which i3 writes. Introducing i3-nagbar reduced these sorts of reports significantly. In case you were just editing your configfile and made a mistake, note that you don’t have to reach to your mouse: just fix your configfile, reload i3, i3-nagbar will be gone. 2. Your config file is really old (i3 v3) and we’ve tried to migrate it to a v4 config file but couldn’t ensure that every directive you’ve had before could be successfully converted. This is a more debatable case. Our opinion is that you should be alerted prominently until your config file is in a working state again. Since you’ll see this message when you start up i3 (not during your work), we think it’s better to spend a minute fixing the config file instead of realizing a feature doesn’t work while you are getting your actual work done. 3. You use the default config file and pressed the keybinding to exit i3. People were occasionally hitting the keybinding by accident and were really disappointed by losing their entire session. Having i3-nagbar in here with its annoying confirmation fixes the problem — you have to be really unlucky or very sure to exit i3. If you dislike this behavior, please change your configfile to not use i3-nagbar. > You have so many enthusiastic users, I bet someone would be willing to > modify "move focus up" to focus the nagbar... but first you'd have to > solicit such a patch, of course... > > I noticed that in this FAQ entry > > > https://faq.i3wm.org/question/1977/why-is-the-i3-irc-channel-not-on-freenode/ > > you said "By using a separate server, we separate the wheat from the > chaff: people who just join the channel easily to ask a troll question > don’t bother." - I guess this kind of device is potentially important > in all areas of a project, especially a free software project - so > perhaps some of i3's rough edges are serving the same purpose of > filtering out particular users, who would otherwise be a burden to > you. If that's necessary, so be it. Accepting that possibility, is > another reason why I replied off list to your comments. > > Take care, > > Frederick > -- Best regards, Michael
