Alopex: a tiling tagging tabbed window manager with fur

HalosGhost · 2013-07-07 11:59:24

Trilby wrote:

Have you tried the default config?

Yes, I've tried the default config; and it has the same issue for me (which either means this is unrelated to alopex, or just unrelated to the config). If it's not related to alopex, then I am thoroughly stumped; I've changed very little recently, and what I've changed seems like it shouldn't be causing this kind of trouble.

Especially the fact that the keybinding for the window list still functions, but nothing else seems recognized; that's really throwing me for a loop…

All the best,

-HG

Greduan · 2013-07-07 13:10:31

I just want to point out that I am not having any problems like HalosGhost.

Earnestly · 2013-07-07 13:17:17

HalosGhost wrote:

which either means this is unrelated to alopex

You've said that it works with other WMs such as i3? Does it fail for any others such as wmii, dwm, xmonad, etc. or is it just i3 which works?

Greduan wrote:

I just want to point out that I am not having any problems like HalosGhost.

Not helpful.

Trilby · 2013-07-07 14:29:51

I'm a bit baffled by this. I could revert the changes for the windowlist function - but unless the key binding is pressed, that code never executes. There are no global data structures or any initialization associated with it. It is a self-contained function.

If you want, you could comment out the windowlist function in alopex.c and rebuild, to see if that changes anything ... but it really shouldn't.

To clarify, none of your bindings are recognized even *before* you try to use the windowlist function, right? I wouldn't know how, but it could at least be possible for something to go wrong in the windowlist function that could freeze up everything else after it's been called.

I just double checked the diffs on github to make sure I didn't do anything else with the windowlist function. Nothing else was changed.

Last edited by Trilby (2013-07-07 14:34:33)

Trilby · 2013-07-07 14:37:47

HalosGhost wrote:

I've changed very little recently, and what I've changed seems like it shouldn't be causing this kind of trouble.

What is this 'very little'?

If you comment out the window list function in alopex.c, and remove the keybinding for it from the config, then build and run, if you still have the problem that rules out any recent changes in the code.

when you have eliminated the impossible, whatever remains, however improbable, must be the truth

EDIT: as a heads-up to all alopex users, I'm going to substantially rearrange the Modifier naming in the next git push. I think it was bgc who wanted the ability to redifine one constant to change all the bindings to use something other than the Super/Win key, and this is a good idea. But I foolishly ended up calling this Super/Win key MOD1, and the Alt key MOD2, and so on, when the Super/Win is Mod4Mask and Alt is Mod1Mask - this can make discussions of bindings very hairy. The defines of the modifiers will remain, but they'll just be renamed to avoid the ambiguity, so they will be KEY1-KEY4, where by default KEY1=Mod4Mask. There will not be any need to actually make these changes in your config, though I'd recommend it. It would only take a sed command or two, and it would make discussion much easier.

Last edited by Trilby (2013-07-07 14:51:31)

Greduan · 2013-07-07 15:09:21

Trilby wrote:

EDIT: as a heads-up to all alopex users, I'm going to substantially rearrange the Modifier naming in the next git push. I think it was bgc who wanted the ability to redifine one constant to change all the bindings to use something other than the Super/Win key, and this is a good idea. But I foolishly ended up calling this Super/Win key MOD1, and the Alt key MOD2, and so on, when the Super/Win is Mod4Mask and Alt is Mod1Mask - this can make discussions of bindings very hairy. The defines of the modifiers will remain, but they'll just be renamed to avoid the ambiguity, so they will be KEY1-KEY4, where by default KEY1=Mod4Mask. There will not be any need to actually make these changes in your config, though I'd recommend it. It would only take a sed command or two, and it would make discussion much easier.

Thanks for the heads up.

I was gonna mention this before, I thought it was on purpose though.

HalosGhost · 2013-07-07 15:36:29

Kaustic wrote:

You've said that it works with other WMs such as i3? Does it fail for any others such as wmii, dwm, xmonad, etc. or is it just i3 which works?

I just tested, and wmii and dwm both work. I guess I can test more if need be, but I think it's pretty clearly only affecting Alopex at this point.

Trilby wrote:

To clarify, none of your bindings are recognized even *before* you try to use the windowlist function, right? I wouldn't know how, but it could at least be possible for something to go wrong in the windowlist function that could freeze up everything else after it's been called.

That is correct. None of my keybinds are recognized at any point, save the windowlist keybind.

What is this 'very little'?

The only things I have changed since this problem cropped up were some typos in my systemd --user service files (but I've checked and rechecked them; they do not appear to be the problem), and the interrobang rewrite.

If you comment out the window list function in alopex.c, and remove the keybinding for it from the config, then build and run, if you still have the problem that rules out any recent changes in the code.

I am about to do this now. This has been confirmed, this issue has nothing to do with the new windowlist function. Now, I am entirely out of ideas. Why is it that only Alopex is affected?

[Edit]: I am a complete idiot. Somehow, two of my modifier keys in my config.h got switched around (I don't remember doing this, but I must have)—this is also why the default config appeared to not help; the default config has the modifiers switched around in the same way. As a result, "none of my keybinds" worked because I wasn't actually testing any of my keybinds. The one keybind that appeared to work was one that was set to use no modifier key (and by complete coincidence, happened to be the windowlist keybind).

I am sorry that I wasted all of y'all's time on the epic PEBKAC that just happened.

All the best,

-HG

Last edited by HalosGhost (2013-07-07 15:52:40)

Trilby · 2013-07-07 16:05:08

All errors are PEBKAC errors - It's just a matter of narrowing down which keyboard and chair.

HalosGhost · 2013-07-07 16:09:53

Trilby wrote:

All errors are PEBKAC errors - It's just a matter of narrowing down which keyboard and chair.

Well hello, my new forum signature.

All the best,

-HG

bgc1954 · 2013-07-07 17:49:27

Another case of PEBKAC here, as well. I got my .alopex_config.h to work fine merging the windowlist changes on my desktop. I find I generally do better if I just use a brand new config.h and apply my few keybinding changes, but sometimes it bites me in the rear as was the case with my netbook, last night, as I was missing an asterisk in my font name and alopex doesn't like it if you don't have a proper font description. All is fine in my world...until the next config.h change.

HalosGhost · 2013-07-08 14:42:09

Trilby, I'd like to propose an option for the default modifier identifiers.

At the moment, I use the following:

#define ALTR Mod1Mask
#define CTRL ControlMask
#define SHFT ShiftMask
#define SUPR Mod4Mask

This offers the nice advantage of making the config's keybindings far more human readable.

It might be more universal to replace "SUPR" with "META" though.

Thoughts?

All the best,

-HG

Last edited by HalosGhost (2013-07-08 14:50:09)

Trilby · 2013-07-08 14:46:39

HG, what would be the point of that, then? If you're redefining Shift as SHFT, you've added no flexibility, which was the whole point in the first place - unless of course one were content to use SHFT as a modifier in their config when what they really meant was Win/Super, and they'd use SUPR when what they really mean is Alt.

Greduan · 2013-07-08 14:48:11

I think he means to do it that way so in the keybindings, instead of doing Mod1 you do SUPR, so that it's easier to see what's going on. From what I understood. Is that right HalosGhost?

Trilby · 2013-07-08 14:51:00

I know what he means - but that would make it far LESS clear to anyone who doesn't use the exact same bindings as he does.

Convenience for one user that will screw everyone else is not a feature. There is no need for these defines at all *except* to allow users to use something other than Win/Super as their main modifier key. And if they are to do that, calling it SUPR, is just silly. Then we'd be calling Super ALT and alt SHFT and shift SUPR - does *that* make any sense?

KEY1-4 allows one user to define KEY1 as Mod4Mask while another defines KEY1 as Mod2Mask. We can still then talk about KEY1 without any ambiguity or confusion.

Last edited by Trilby (2013-07-08 14:54:15)

HalosGhost · 2013-07-08 14:54:56

Trilby wrote:

HG, what would be the point of that, then? If you're redefining Shift as SHFT, you've added no flexibility, which was the whole point in the first place - unless of course one were content to use SHFT as a modifier in their config when what they really meant was Win/Super, and they'd use SUPR when what they really mean is Alt.

My understanding of why the modifier definitions exist was to save space (users could just use "Mod4Mask", but "MOD4" is quicker. To that end, my idea was just to keep the shortcuts human-readable. That way, when you look at a keybind, the syntax itself tells you which keys you would use.

[Edit]: Ahh, I see what you're saying. Scratch that proposal then.

All the best,

-HG

Last edited by HalosGhost (2013-07-08 15:35:19)

bgc1954 · 2013-07-09 14:47:05

Since I am the one that originally asked for this function, I must say I agree with Trilby that KEY1-4 is suitable for my needs. I have an old thinkpad that has no super key so I have to use something else on that one and I'm now just used to using Alt for MOD1 after all my time with this and other tilers--and too stubborn to change.

Greduan · 2013-07-12 15:17:48

Cool new avatar Trilby. I should upload mine...

Just wondering, when is this commit that changes the key bindings happen. Just so I can plan ahead a bit with my config.

Trilby · 2013-07-12 16:29:12

Just did.

But you don't actually need to change your config - it would work just hte way it was. Jut just changes the default template.

Greduan · 2013-07-12 17:21:56

Ah OK. For some reason I thought you were gonna change the Alopex code. lol

Greduan · 2013-08-10 16:00:58

I'm back! Feels good to use Linux/Alopex again (was using a Mac for a while).

While on the Mac I did some general research on Linux and developing software on it and I found out about Wayland through this excellent video.

Are there any plans to support Wayland in the nearby future? Perhaps in a different branch.

I see it as a big move, but it makes it much easier to add features or make it lighter and faster.

Last edited by Greduan (2013-08-10 16:11:25)

Unia · 2013-08-10 16:17:47

Interesting question. I know that alot of developers of tiling WMs will wait, like the i3 devs and dwm as well. The only author I know who will look into a Wayland port is Baskerville of bspwm.

Someone did start a port of dmenu and st to Wayland, just fyi.

EDIT: Oh, and there is already one tiler out there for Wayland: http://www.phoronix.com/scan.php?page=n … px=MTA5MTA

Last edited by Unia (2013-08-10 16:18:18)

Greduan · 2013-08-10 16:22:57

Oh I'd like to point out, Enlightenment and EFL are supporting Wayland. https://phab.enlightenment.org/phame/li … g_wayland/

Trilby · 2013-08-10 16:50:16

Nope. No plans at all, and unless wayland drastically changes directions there never will be. I don't like wayland.

Advocates of wayland point to some flaws in X. Wayland is designed to replace X and not have those flaws. But if you want to actually use it, you need to run X within wayland anyways!

I don't get their logic. X is claimed to be a flawed system. But I don't see how a flawed system running within an impotent system is better than just running the flawed system alone.

But take this with a large grain of salt, I stopped following Wayland a while back. Maybe they have completely changed directions.

I don't see what purpose this would serve anyways. The only (alleged) flaws that wayland is supposed to resolve are for compositing. Alopex is not a compositing window manager. I kind of agree with some of the criticisms - compositing in X is really horrible, just look at the code of any composite manager. Still, alopex doesn't use compositing, so it's use of X isn't subject to those criticisms and the alleged benefits are thus non-existent.

Last edited by Trilby (2013-08-10 16:53:14)

Unia · 2013-08-10 17:05:00

Trilby wrote:

Advocates of wayland point to some flaws in X. Wayland is designed to replace X and not have those flaws. But if you want to actually use it, you need to run X within wayland anyways!

XWayland is only a solution for legacy applications or those that have not yet been ported.

Greduan · 2013-08-10 17:10:15

Unia wrote:

Trilby wrote:
Advocates of wayland point to some flaws in X. Wayland is designed to replace X and not have those flaws. But if you want to actually use it, you need to run X within wayland anyways!
XWayland is only a solution for legacy applications or those that have not yet been ported.

And I *believe* it is now called Weston.

Arch Linux

#576 2013-07-07 11:59:24

Re: Alopex: a tiling tagging tabbed window manager with fur

#577 2013-07-07 13:10:31

Re: Alopex: a tiling tagging tabbed window manager with fur

#578 2013-07-07 13:17:17

Re: Alopex: a tiling tagging tabbed window manager with fur

#579 2013-07-07 14:29:51

Re: Alopex: a tiling tagging tabbed window manager with fur

#580 2013-07-07 14:37:47

Re: Alopex: a tiling tagging tabbed window manager with fur

#581 2013-07-07 15:09:21

Re: Alopex: a tiling tagging tabbed window manager with fur

#582 2013-07-07 15:36:29

Re: Alopex: a tiling tagging tabbed window manager with fur

#583 2013-07-07 16:05:08

Re: Alopex: a tiling tagging tabbed window manager with fur

#584 2013-07-07 16:09:53

Re: Alopex: a tiling tagging tabbed window manager with fur

#585 2013-07-07 17:49:27

Re: Alopex: a tiling tagging tabbed window manager with fur

#586 2013-07-08 14:42:09

Re: Alopex: a tiling tagging tabbed window manager with fur

#587 2013-07-08 14:46:39

Re: Alopex: a tiling tagging tabbed window manager with fur

#588 2013-07-08 14:48:11

Re: Alopex: a tiling tagging tabbed window manager with fur

#589 2013-07-08 14:51:00

Re: Alopex: a tiling tagging tabbed window manager with fur

#590 2013-07-08 14:54:56

Re: Alopex: a tiling tagging tabbed window manager with fur

#591 2013-07-09 14:47:05

Re: Alopex: a tiling tagging tabbed window manager with fur

#592 2013-07-12 15:17:48

Re: Alopex: a tiling tagging tabbed window manager with fur

#593 2013-07-12 16:29:12

Re: Alopex: a tiling tagging tabbed window manager with fur

#594 2013-07-12 17:21:56

Re: Alopex: a tiling tagging tabbed window manager with fur

#595 2013-08-10 16:00:58

Re: Alopex: a tiling tagging tabbed window manager with fur

#596 2013-08-10 16:17:47

Re: Alopex: a tiling tagging tabbed window manager with fur

#597 2013-08-10 16:22:57

Re: Alopex: a tiling tagging tabbed window manager with fur

#598 2013-08-10 16:50:16

Re: Alopex: a tiling tagging tabbed window manager with fur

#599 2013-08-10 17:05:00

Re: Alopex: a tiling tagging tabbed window manager with fur

#600 2013-08-10 17:10:15

Re: Alopex: a tiling tagging tabbed window manager with fur

Board footer