Change the direction of a new client appearance in Awesome Window Manager

.rcawesome

In previous releases of Awesome WM new client title appeared to the right from the previous client. So, client titles were ordered from left to right by their order of appearance.

In new releases of Awesome this order has reversed. Quit naggingly, each new client title appears to the left from the old client.

How to make such that title for each new client will appear to the right from old client?

Example: There is a single client –internet browser — opened in a current workspace. I press MODKey+Enter and, irrespectively of windows layout, title of terminal client appears to the left from the title of the internet browser. Personally for me it would make much more sense if this new terminal title would be to the right from old browser title.

Best Answer

In rc.lua uncomment line if not awesome.startup then awful.client.setslave(c) end

Related Solutions

Awesome Window Manager – Using on CentOS 7

For Starters, I would remove the source you compiled, then add the official YUM Repo for Fedora, using the Steps from this post. Afterwards, since the repo you just added contains AwesomeWM, use YUM to install it. See Here.

Reasoning: It's nearly impossible to mix a source based package with a system based on binary packages, as you easily create a version mismatch. Consider the following:

Binary package Version A depends on and only works with dependency Version B. Dependency Version B uses Library C.
Connecting the Logic in 1, Binary Package Version A, also implicitly depends on Library C.
You built dependency Version B with library Version D (If C = 1.0, D = 1.1)
Dependency Version B built successfully, but Binary Package Version A is still linked to Library Version C, therefore Binary Package A, now loads unresolved symbols, because the symbols in Library Version C were replaced with newer symbols in Version D.
Library Version D, superseded Library Version C, therefore the developer decided not to link his new Version D to Version C.
To Fix this, every package on the system, that is linked to library Version C, must be recompiled using Library Version D.

You're Stuck Here because all the packages on a Binary System were prepackaged, and some or all of them will break, when compiled from source

You may be able to fix this by finding newer versions of all packages using Library Version D, but from experience, this is very unlikely, which is why I use Gentoo.

Update from Deleted Comments

I was asked to explain how to handle an out of date repo, and what to do if the repo expires, since CentOS, and Fedora are on radically different release schedules.

As per your questions in now deleted comments below, when adding a repository:

If support for that repository ends, add the repository that superseded it. i.e., Fedora 19's repo will be replaced by Fedora 20.
After updating to the new repository, you must decide as a user which direction to take, as you will have version number mismatches between packages in the new repo. For Example in CentOS Library Version A will have been superseded by Library Version B in Fedora. Having Added Fedora as a repo, if a package you want exists in Fedora, but NOT in CentOS, and it is asking for a newer version of a package, you must either a.) see if the same package exists in the CentOS Testing repo, or b.) allow the install to install the package from the Fedora repo. In this way, you will have a mixed or hybrid install. If you add the CentOS Testing repo in the same way you added the Fedora Repo above, I believe YUM will ask you which package you want to use, if the same package exists in both.
If there is a Stable Library Version B in Fedora, and a Testing Library Version B in CentOS, use the Testing Version in CentOS, as that version is "native" to your OS. Whenever possible, you want to install versions native to your OS, even if they are in Testing. By doing so, if the package doesn't work you report a bug to your OS maintainers, so that the package stays in Testing until the bug is fixed before being moved to Stable

Awesome window manager stops recognizing shortcuts

Going by your description, the window manager hasn't crashed: it's still responding to window-related events, the problem is that it is no longer detecting keyboard events.

What is probably happening is that your keyboard configuration has changed in a way that awesome doesn't recognize. Check that ignore_modifiers is set correctly: if it's missing Lock or your NumLock modifier, then your keyboard and mouse shortcuts won't work while Caps Lock / Num Lock are on. Also, check that the key that you think sends Mod4 is still sending that modifier.

To check what your keyboard is sending, run the command xev in a terminal and press keys in the xev window. If you press A then you should see something like

KeyPress event, serial 33, synthetic NO, window 0x4a00001,
    root 0xab, subw 0x0, time 291526925, (443,-11), root:(454,44),
    state 0x0, keycode 38 (keysym 0x61, a), same_screen YES,
    XLookupString gives 1 bytes: (61) "a"
    XmbLookupString gives 1 bytes: (61) "a"
    XFilterEvent returns: False

KeyRelease event, serial 33, synthetic NO, window 0x4a00001,
    root 0xab, subw 0x0, time 291527038, (443,-11), root:(454,44),
    state 0x0, keycode 38 (keysym 0x61, a), same_screen YES,
    XLookupString gives 1 bytes: (61) "a"
    XFilterEvent returns: False

If you see a state that's different from 0x0 then some modifier is on, for example 0x2 indicates that Caps Lock is on. When you press the Mod4 key, the state should change to 0x40.

Best Answer

Related Solutions

Awesome Window Manager – Using on CentOS 7

Awesome window manager stops recognizing shortcuts

Related Question