Alopex: a tiling tagging tabbed window manager with fur

bgc1954 · 2013-11-23 05:51:21

Actually, I did, but I've never had a problem before. I git cloned alopex and edited my own keybnding preferences and now it's all working fine so thanks for the quick fix. All is well in my world now.

bgc1954 · 2013-11-23 16:57:56

This AM, I had quite a time getting the latest push to work on my netbook. It took me awhile to figure out you changed the config directory to ~/.config/alopex/config.h in the PKGBUILD. I checked my desktop and sure enough, somehow, I still had an old PKGBUILD that used ~/.alopex_config.h so it built fine there last nite. Thanks for the mental gymnastics I got this AM.

Trilby · 2013-11-23 17:25:22

Ah, yeah. ~/.alopex_config.h was the original, then ~/.config or $XDG_CONFIG_HOME was requested, then other files (icons.h, theme.h) were added and it just got crazy. I decided to simply to a single place.

Trilby · 2013-11-29 19:43:27

ALOPEX 3.x is coming soon.

The master branch of the github repo is now for 3.x development. But as this is not even close to read yet for normal use, version 2 is still available on a "version2" branch on github. I've updated the PKGBUILD in the AUR to only pull from the version2 branch for now. So in other words, I can still patch up any bugs in v2, but no more development will happen there.

Note that if you have local PKGBUILDS, they will likely now fail - or if they work at all, they'll be grabbing the 3.x code which is not ready for regular use. Feel free to try it, but don't expect stability or complete functionality.

Some previews of what is coming in alopex 3:

1) there is no 'universal' status bar anymore. Instead I'm using
containers (a bit like i3's logic). These are not actual windows
in which other clients are reparented (as i3 does it), rather they are
just abstractions in the code. Each container has it's own "bar" which
will display the tabs of all windows stacked in that container.

2) Containers are tiled in bstack, rstack, or monocle (only one
container) layouts.

3) Windows are not assigned to specific containers, instead they fill
the lowest numbered container first and 'overflow' into higher numbered
containers. The user can define the maximum number of windows per
container in their config. So for TTWM (1.0) style tiling, one would
set the container capacities to {1, -1} so the first "master" container
only gets one window, and everything after that stacks in the second
container. I like {1, 3, 3, -1} as a nice default.

4) Containers size can be adjusted at run time, as can the padding (gap)
between containers.

5) There are two user-defined status bars. One is on the left of
container #1's bar, the other is on the right of container #2's bar (or
right of container #1's if there is only one container visible). The
user can define where the tags are displayed and whether they show
names, icons, or both. A built in clock can be displayed, and input
from from a status script can be placed in either location (or both).

6) There will be minimal traditional key bindings. Instead alopex 3
will use a vim-style key chaining. If you press the MOD key and hit
another key, that will activate the keybinding (if there is one). But
if you press and release the MOD key without hitting anything else, you
go into a command mode (~vim's normal mode). Keys pressed after that
are chained together and parsed as commands. The core functionality of
this is in place, but most of the commands haven't been implemented yet.

7) The user can also define arbitrary "strings" which can be names of
commands to launch, or can be 'macros' of command-mode strings.

8) All drawing has been moved to using cairo rather than Xlib's drawing.
This will make antialiased drawing much easier, and (once complete) the
tab drawing should be much prettier. This may make customizing font's
more challenging (for me) but then it makes using those damned xft fonts
more likely (which others want).

HalosGhost · 2013-11-29 19:54:59

Woohoo! So excited to get to see the next stage of awesome!

All the best,

-HG

Unia · 2013-11-29 20:10:04

Trilby wrote:

it makes using those damned xft fonts more likely (which others want).

Or Pango

Trilby · 2013-11-29 20:41:04

HalosGhost wrote:

Woohoo! So excited to get to see the next stage of ~~awesome!~~alopex!

Fixed that for you. Wrong WM

Unia wrote:

Or Pango

Indeed, I'm open to whatever would be best here. I've never used XFT fonts, all I know is they are a royal pain. If pango is easy without much overhead, I'll go with that. But I'm a complete noob with font stuff ... so I'll have to check out a few of the options to see what will work best.

EDIT: Pango seems to be like bringing a thermonuclear weapon to a knife fight. FreeType may be more fitting.

EDIT: FreeType fonts have been added. You must specify the font with a full path to the font file. This is most likely temporary, but it is nice in that it takes all the guess work out of the format of those silly font specifier strings ... so maybe it won't be temporary. On another point, if anyone it testing this out, don't worry, I know the default aesthetics are rather grotesque. Those are definitely temporary. But by everything being bindingly obvious, it makes it hard to miss little things. Polish (and customizable colors and tab shapes) will come later.

Last edited by Trilby (2013-11-29 21:40:12)

Trilby · 2013-12-04 16:22:24

Version 3 is ready for testing - it is not in the AUR yet, but a v3 PKGBUILD is available on github.

I just finished a few coding bits, and we'll need to work on documentation as there are a lot of changes. Configuration is now down via a runtime config file. A default is provide in /usr/share/alopex/config. This can be copied to $XDG_CONFIG_HOME/alopex/ or ~/.config/alopex/ for modification. The syntax is fairly strict: there are "blocks" for different elements. Each block is started by a line starting at column zero ending in a colon. Every line after that that starts with a tab (not spaces) belongs to that block. There cannot be any comments within a block. A block ends at the first line that does not start with a tab. There must be at least one blank or comment line between subsequent blocks. The theme colors are read by order in the list - the names are for humans only, the program ignores the names (every other block it reads the parameter names. The config file can be reloaded at runtime (live reconfig) by the sequence Mod Shift+R (that's press-mod, release-mod, press shift+r).

Key chaining is working well. And I've implemented a macro language with which users can write their own mini-macros. For an example see the fullscreen toggle. The sequence "mod ; f" which is also bound to "mod+f" will run a macro using a ternary operator for conditional behavior to toggle a fullscreen view of the currently focused window.

More information to come soon. See the TODO on github to see what is left to do.

Unia · 2013-12-04 16:51:56

I see keychaining is getting popular, you could almost say they are appearing all over the place: Baskerville's sxhkd, you... and I'm pretty sure there were more because now my statement is invalid

I see in the TODO there is a line about getting client icons; are you thinking of displaying actual icons in the bar? Also, how are you planning on doing the transparency? Last time I tried this (with your help, so I suppose it's gonna be like this) the text also got transparent as you made the bar transparent. Not an ideal solution IMO. Nevermind, just noted and remembered you were going to use Cairo.

And I'm still curious which font "renderer" you are going to use!

EDIT: Oh and keep up the good work, of course! I'm following this!

EDIT2: Hmmm... I might steal your Cairo code and see if I can implement it in DWM.

Last edited by Unia (2013-12-04 16:56:28)

Trilby · 2013-12-04 17:34:09

Key chaining is really handy, and not hard at all to implement. This helps avoid an overload of bindings leading to an emacs style window manager: Mod4+Shift+Cntrl+#+pray-you-don't-get-carpel-tunnel to reassign a client to tags. Chaining allows for 'vim-like' interaction, but there can also be more traditional bindings for commonly used actions.

For icons in tabs, I will use the client-provided icons. There can also be user-specified icons in the status bar and tag indicators (not yet done).

You can be curious about the font renderer - or you could read above or see the code - that was all done a while ago: libfreetype2.

Feel free to steal whatever is useful. When I started coding I avoided using cario and I really didn't think much of it. But it turns out my view was biased by a handful of programs out there that use it *very* badly. I was under the impression that all cairo apps were resource hogs and buggy - but it was more likely that it is so easy to use, that people who don't know anything else about coding can throw together very bad cairo programs. The cairo library itself actually is very efficient when used well and very good at what it does.

As for seeing how the (pseudo-)transparency works, fire it up - the default config uses transparent bars.

Unia · 2013-12-04 17:54:01

I am definitely going to try it out later tonight!

EDIT: Do I need some special steps to get it to work? X fails to start if I try to start it with Alopex. I cloned your repo, ran make and point to the binary in .xinitrc.

Last edited by Unia (2013-12-04 18:04:28)

Trilby · 2013-12-04 18:30:51

That should do it. That's how I'm running it on two computers. I assume you'd have the dependencies installed right? libfreetype2 and cairo are new dependencies from version 2.

HalosGhost · 2013-12-04 18:34:27

Good lord, development has gone blisteringly fast. Congratulations on it all and keep up the awesome work
I was hoping that there would not just be vim-like commands, but also an input line so that nothing would take effect until the whole command is passed (rather than keychaining). Is this still planned/possible?

All the best,

-HG

Unia · 2013-12-04 18:35:31

I have both cario and freetype2 (from Bohoomil's infinality set) installed, and I assumed no less since Make did not complain about missing libraries. I'll dig into it more later, have to figure out how to get X's output into a file since that has never worked for me to date.

HalosGhost · 2013-12-04 18:37:14

Unia wrote:

I have both cario and freetype2 (from Bohoomil's infinality set) installed, and I assumed no less since Make did not complain about missing libraries. I'll dig into it more later, have to figure out how to get X's output into a file since that has never worked for me to date.

You mean you don't have /var/log/Xorg.<TTY#>.log ?

All the best,

-HG

Unia · 2013-12-04 18:41:23

HalosGhost wrote:

Unia wrote:
I have both cario and freetype2 (from Bohoomil's infinality set) installed, and I assumed no less since Make did not complain about missing libraries. I'll dig into it more later, have to figure out how to get X's output into a file since that has never worked for me to date.
You mean you don't have /var/log/Xorg.<TTY#>.log ?
All the best,
-HG

No, I meant the following:

startx >$HOME/startx.log 2>&1

I now feel embarrased for saying this I fixed the issue; Alopex couldn't find a config file because I hadn't moved the config to ~/.config/alopex. Perhaps some default settings should be used if no config can be found?

HalosGhost · 2013-12-04 18:44:01

Unia wrote:

Perhaps some default settings should be used if no config can be found?

I would argue against this; building in defaults tends to create weird border cases and almost always creates unneeded redundancy. However, perhaps a command-line option to explicitly specify a configuration to use might be good?

All the best,

-HG

Unia · 2013-12-04 18:48:21

An example of defaults being built-in is dmenu and I have never heard of any issues regarding these. Regarding the redundancy, you are correct, but so do runtime configs in general if we're going down this path

Trilby · 2013-12-04 18:53:40

If you used the PKGBUILD or makefile, you would have had the file where it needed to be

Sometimes hardcoded defaults can work - but here they won't. It would take a *lot* of code to make coded defaults viable as each reading of a configuration requires free'ing and allocating a good about of data. With dmenu there is no allocation - statically sized data is simply overwritten - this is easy to have a default that gets overwritten.

Unia · 2013-12-04 18:55:56

Gotcha Cairo definitely has my attention now after seeing what you did with it - when I have time I'm going to see if I can get it into DWM.

Trilby · 2013-12-04 20:05:56

HalosGhost wrote:

I was hoping that there would not just be vim-like commands, but also an input line so that nothing would take effect until the whole command is passed (rather than keychaining). Is this still planned/possible?

I replied to this ealier, but it seems to have disappeared - lets try again:

I'm not sure if I'm understanding this correctly, but there is one configuration option I haven't implemented yet (though it will be very easy to do). That is for the delay on the key chain 'timeout' or the time after the last key press that the chain automatically ends. This is currently hardcoded to half a second, but when I add a config variable for it, you'll be able to set it to zero to have no time out (EDIT: DONE). So when you press and release the mod key you'll be in "chain mode" until you hit Enter or Esc. The input line can also be displayed in a status bar. With the default config it is displayed in green text to the left of the tag indicators in the upper left corner. The status string in the config could move that somewhere else. This input is format specifier "%I".

This needs a lot of documentation, and that will be coming soon. I've even implemented a mini macro language which currently has conditionals (see the "fullscreen" toggle in the config). This reminds me I've done fullscreen very different in v3. There really is no special fullscreen window mode. Instead, fullscreening is a chain of actions: switch to monocle mode, hide the bar, set the gap to zero. This is "3M1bh0g" in alopexian, but that can be bound to a key, or set as a "string" which are macros that can be invoked by their letter.

To "unfullscreen" you'd reset the tiling mode to your preference (rstack in this example), show the bar again, and set the gap to your preference (4 pixels here), or "1M1bs4g". But with the ternary operator (if then else) these can be combined into "(=0g?1M1bs4g:3M1bh0g)" which means If the gap is zero ( =0g ) then go to normal mode, or else go to fullscreen.

Last edited by Trilby (2013-12-04 23:26:25)

bgc1954 · 2013-12-06 19:55:38

Hey Trilby,

I really like the new aesthetics in version 3 and development, as always, is quick. Yesterday, I was trying it out but config wasn't showing up in /usr/share/alopex--I did find and use the one in the share folder of the alopex git clone though--today, it's there. Yesterday, bottom bar wasn't working for me, today it's fine.

Just a few observations/questions:

-I like the sort of ellipse around the tags and status clock but here it seems to be a bit shallow--the font is overlapping it and I'm using your droid-14 in the default config.
-Is there a way to set default tile mode? I've changed the fullscreen keychaining so I can get back to monocle but I guess I need the documentation as experimenting at my end isn't getting results...yet. Still trying to set a key binding but not yet successful. I used to be good at new languages.
-Is there still work to be done on status input or do I just still need documentation? If I set my status script path, I just get kicked back to xdm. I thought I saw some input string format yesterday but can't seem to find it today. I'll keep looking.
-SDL games behave like version 2 before you added in the hack/fix--won't run in fullscreen.

Overall it's quite useable and I really like the new look. It's like having a brand new toy to play with. I'll keep fiddling with it to see if I can resolve the above queries on my own but will wait patiently for the documentation as well.

Thanks

Edit: Progress on my part as I just set up a string and key binding to switch between monocle and bstack but when I'm in monocle mode I can't switch beween windows using the Super+Tab keybinding which works fine in bstack.

Last edited by bgc1954 (2013-12-06 20:21:30)

Trilby · 2013-12-06 20:24:59

bgc1954 wrote:

-I like the sort of ellipse around the tags and status clock but here it seems to be a bit shallow--the font is overlapping it and I'm using your droid-14 in the default config.

Originally this was an accident, but I liked the 3D'ish look it gave so I kept it - though this is likely dependent on the wallpaper behind it. The default theme(s) are hopefully useable, but with some of them I am going to go to extremes to demonstrate what can be done - they are very configurable - but docs are needed to outline how this themeing is done. For this specific example, all the tabs and status bar backgrounds are drawn as rounded rectangles. These rectangle's shapes are adjusted with "tab offset" and "status offset". The program calculates the coordinates where the tab or bar can fill, then the offset is applied with the five values representing X Y Width Height and Radius. X and Y offsets are simply added to the top left bounds, Width and Height are added to the bounding box width and height. Radius is the radius of the rounded corners.

So the default theme uses 2.0 1.0 -4.0 10.0 6.0 for tabs: tabs are inset two pixels left and 1 down, then their width is reduced by 4 (for a two pixel pad on either side) and height increased by 10. This last part makes the bottom of the rectangle fall out of the drawn area, so they look like 'tabs'. Status bars are 2.0 2.0 -4.0 -8.0 6.0: 2, 2, and -4 are similar to the tabs, then -8 height pulls the bottom up. This is what I initially overestimated, but I thought it had the nice effect. You could also try 2.0 -10.0 -4.0 8.0 6.0 to get a tab coming out from the screen edge which I considered as a default.

bgc1954 wrote:

-Is there a way to set default tile mode? I've changed the fullscreen keychaining so I can get back to monocle but I guess I need the documentation as experimenting at my end isn't getting results...yet. Still trying to set a key binding but not yet successful. I used to be good at new languages.

Not yet - but this is definitely coming. Right now the modes are assigned to rstack, bstack, and monocle (1, 2, and 3). But an option will be provided for this soon.

bgc1954 wrote:

- Is there still work to be done on status input or do I just still need documentation? If I set my status script path, I just get kicked back to xdm. I thought I saw some input string format yesterday but can't seem to find it today. I'll keep looking.

As above, this is simply the lack of instructions/documentation. The input reader is "working", but it is a bit different than version 2. The color codes are not hex codes, instead they are 4 floating point numbers for RGBA. So to translate from v2 to v3 status input {#RRGGBB} should become {R.R G.G B.B A.A} where the value range from 0.0 to 1.0, so {#0088FF} becomes {0.0 0.5 1.0 1.0} if you want full opacity, or less than 1.0 in the last place for partial transparency.

The icon sets will be entirely different, but the syntax for specifying icons from the status input will be the same {i#}, but icon drawing isn't quite done yet.

Also note the script path currently has to be a full path and cannot take any parameters (yet).

bgc1954 wrote:

-SDL games behave like version 2 before you added in the hack/fix--won't run in fullscreen.

I expect many of the quirks I had to deal with in v2 will have to be addressed again as I started from scratch with the code. But as I get around to them, I should be able to import and/or revise code from v2 - so a fix will be coming, but there may be lots of other bits to get in place first.

For stable use I'd still encourage users to stick with version 2 for now. The v3 code is currently best viewed as a preview. I am starting to use v3 on a regular basis, but there are many bugs or incomplete parts that make me switch back to v2 at work.

bgc1954 · 2013-12-06 20:59:59

Thanks Trilby,

This will give me something to play around with. I knew it was probably just documentation I needed--maybe not as patient as I say. I will likely flip back and forth between ver. 2 and 3 so I can stay in the loop with development but day to day--esp. gaming-- will be ver. 2. Thanks again for providing a new--but somewhat familiar--tiler/wm.

Trilby · 2013-12-07 00:19:01

bgc, the fullscreen sdl issue was actually something entirely different this time around. The fix from v2 wasn't (yet) relevant. The current issue was that the SDL game creates a window that it does not intend to follow any standard window manager rules, yet they are do not have the override_redirect flag (I'd say this is a very big bug in whatever does this, SDL?). So the window get's managed my window managers, and in alopex it ended up getting tiled and other windows get placed above it - but it also grabs the keyboard so no window manager key bindings can bring it back up.

Alopex 2 survived this as it labeled transient windows as floating, and raised them to the top layer. But v3 does not float transient windows (yet?).

However a different fix was applied, and you can thank Unia for this one as it came from a comment of his on github a while back. Tiled windows are no longer raised to the top of the stacking order.

Arch Linux

#626 2013-11-23 05:51:21

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

#627 2013-11-23 16:57:56

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

#628 2013-11-23 17:25:22

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

#629 2013-11-29 19:43:27

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

#630 2013-11-29 19:54:59

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

#631 2013-11-29 20:10:04

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

#632 2013-11-29 20:41:04

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

#633 2013-12-04 16:22:24

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

#634 2013-12-04 16:51:56

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

#635 2013-12-04 17:34:09

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

#636 2013-12-04 17:54:01

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

#637 2013-12-04 18:30:51

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

#638 2013-12-04 18:34:27

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

#639 2013-12-04 18:35:31

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

#640 2013-12-04 18:37:14

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

#641 2013-12-04 18:41:23

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

#642 2013-12-04 18:44:01

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

#643 2013-12-04 18:48:21

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

#644 2013-12-04 18:53:40

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

#645 2013-12-04 18:55:56

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

#646 2013-12-04 20:05:56

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

#647 2013-12-06 19:55:38

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

#648 2013-12-06 20:24:59

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

#649 2013-12-06 20:59:59

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

#650 2013-12-07 00:19:01

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

Board footer