Alopex: a tiling tagging tabbed window manager with fur

Trilby · 2013-08-10 17:10:41

But there is not way to "port". Wayland doesn't have an event hander or any way to interface with input devices .... except by using X. Weston is the shell, wayland is the interface.

http://wayland.freedesktop.org/ wrote:

Wayland is a protocol for a compositor to talk to its clients as well as a C library implementation of that protocol.

Alopex is not a compositor. Wayland is not relevent.

If you run a compositor, then wayland could be relevant.

Also,

http://wayland.freedesktop.org/faq.html#heading_toc_j_4 wrote:

Is wayland replacing the X server?
It could replace X as the native Linux graphics server, but I'm sure X will always be there on the side.

Wayland may do compositing better than X (it couldn't do it worse). But I don't do compositing at all so why would I be interested in a tool that does it better?

Last edited by Trilby (2013-08-10 17:31:06)

kaszak696 · 2013-08-10 17:17:17

Greduan wrote:

And I *believe* it is now called Weston.

[Malicious Offtopic]
Weston is a reference compositor (window manager, kind of) that has been split from Wayland code, nothing more, nothing less. New window managers can be written either as a plugin (shell) for weston, or as a full compositor, independent from Weston.
Good article about why Wayland exists - http://www.phoronix.com/scan.php?page=a … tion&num=1
[/Malicious Offtopic]

Unia · 2013-08-10 17:29:48

Trilby wrote:

But there is not way to "port". Wayland doesn't have an event hander or any way to interface with input devices .... except by using X. Weston is the shell, wayland is the interface.

Oke, true, you have to start from scratch with "porting" a window manager. But, can't you just take Weston, remove all the stacking/reparenting/window moving code and implement tiling? Maybe (probably) I'm just talking nonsense, I admit I haven't looked more into Wayland except for reading news articles.

Trilby · 2013-08-10 17:34:30

And then alopex could only run wayland/weston client programs. If you wanted to run dwb, firefox, urxt, or any x application you'd have to run x within that!

So all you'd have is Wayland + Stripped Down Weston + X + Alopex + Client Programs.

Compare that to X + Alopex + Client Programs.

I don't care how sleek wayland is. The second version there is more efficient. The first would include two separate processes for what benefit? Just to say we did?

And not to sound like a broken record, but alopex isn't a compositor, alopex doesn't use a compositor. Wayland is not replacing X, it is replacing X's compositors. So tacking it on at the end serves no purpose.

Why would anyone want alopex to run in Wayland? What purpose would this serve? What problem would it solve? Would it just allow you to brag to your friends that you use a Wayland window manager? If that's all you want, I can just statically link in all the wayland code, but just not use any of it. Then I'll slap a big "W" somewhere in a logo, and you can show it off to friends. There'd be no new functionality, no change in behavior, but there would be a much bigger binary.

EDIT: this is actually my gripe with Wayland, not that it doesn't seem like a great idea and could work great - but that people just think it's "cool" without knowing what it actually does. It's not marketed with facts, it's marketted with fad status "Its the future", "All the cool kids are using it". Alopex has no need to be cool - it's an arctic fox, it's cold enough.

EDIT 2: I don't mean this to sound confrontational - it's just how I see it currently. I'll happily change my views when presented new information. Specifically answers to the questions that may otherwise seem like rhetorical questions above. What new functionality would wayland allow? What purpose would it serve? I would never add a new dependency to a program just to say I used that dependency. I could (in theory) be convinced to use a new dependency if it is the best way to accomplish some goal. What is the goal?

Last edited by Trilby (2013-08-10 17:55:30)

Unia · 2013-08-10 18:10:46

Oke, so you share the same opinion as dwm and i3 developers

Earnestly · 2013-08-10 21:48:20

It's going to take a long time before people understand what wayland is and what weston is. Although they also confuse X and Xorg too, so maybe not...

Please can all of you either research the topics you're discussing or simply not and thus prevent polluting google results with FUD?

Unia · 2013-08-29 18:29:56

Just mentioning that there now is another project on Github with the names Alopex and Lagopus:

https://github.com/nexcore?tab=repositories

Not sure if you can do something about it or if it will even lead to confusion as both projects are very different, but I thought you might be interested in knowing this.

Trilby · 2013-08-29 18:48:43

Thanks for the heads up. I don't really mind. I think it is common courtesy to search for other software with similar names before using a name - but with all the open source software out there, some name collisions are inevitable. That is such a different project that I don't think there is any risk of confusion.

If it were a window manager, I might email the author. But as is, I'm not even sure what it is, something about generating javascirpt code for web pages as far as I can tell.

Also I certainly am not the first to use it - there is a pattern matching algorithm that goes by the same name.

Last edited by Trilby (2013-08-29 18:51:22)

dysoco · 2013-08-31 14:50:33

Are you limiting the Lines of Code to a certain amount like i3 does? Or you don't care?
Because honestly the code is a bit of mess, I could help cleaning it up a bit, but it'd obviously add more whitespace and more LOC.

Also you should consider creating a code style guideline, at least basic stuff like how to write ifs and so on.

Trilby · 2013-08-31 14:55:21

https://bbs.archlinux.org/viewtopic.php … 3#p1250693

I didn't know i3 limited the lines of code - they already have an order of magnitude more than alopex does.

Everyone has different coding styles. If you don't like mine, fine. But insults are not the way to suggest changes. I've written the code in my style in the way I find most useful.

EDIT: there are several bits I need to clean up - I just looked and a few parts of the "draw()" function would be included. One thing not in that linked-to previous post is that I tend to put experimental bits that I am unsure of as unindented. That way they are easy to find and remove if they cause a big problem. I'd usually go back and indent them properly if they seem to work. The draw() function has a couple of these I haven't gone back to yet.

Last edited by Trilby (2013-08-31 16:56:25)

KieranQuinn · 2013-08-31 15:37:58

dysoco wrote:

Are you limiting the Lines of Code to a certain amount like i3 does? Or you don't care?
Because honestly the code is a bit of mess, I could help cleaning it up a bit, but it'd obviously add more whitespace and more LOC.
Also you should consider creating a code style guideline, at least basic stuff like how to write ifs and so on.

You obviously haven't had to read through genuinely messy code. This source code is very readable and the style is pretty consistent. What more could you want from an open-source project?

Last edited by KieranQuinn (2013-08-31 15:43:56)

dysoco · 2013-08-31 20:12:45

Sorry, it wasn't my intention to criticise the code or insult anyone.

I was just saying that, being a tiny wm, it'd be interesting if it could be taken as a "learning example", but honestly, I find the code a bit difficult to read: And I was just curious if you were aiming for a specific number of LOC or something.
I read your comment and I understand it's just your way of writing code, and I accept that.

Thanks.

Unia · 2013-08-31 20:15:59

Catwm can be a nice learning example.

Trilby · 2013-08-31 20:24:32

No problem - tone is really lost online - and the comment may have just caught me at the wrong moment.

For learning, I'd really recommend TinyWM. ~50 lines of code and it does the very basics of what a window manager should do. Both of my WMs started with tinyWM and built from there.

And alopex is written in my style. It looks the way it looks be cause that's what I indended - with perhaps few exceptions, it isn't just like it is *by accident*. However, I certainly can be persuaded to revise my coding style. One thing that I am working on changing my habits with are tabs. I have used vim with ts=4 for a long while, but when tab indents are used for code structure, this can really go haywire when the code is shared with others who used different tabspacing. I am certainly open to suggestions on changing such things - so if there are aspects to my coding style you'd prefer to have done differently, feel free to bring them up. But 'mess' is too subjective - It's not a mess to me.

Last edited by Trilby (2013-08-31 20:32:42)

SolarBoyMatt · 2013-09-01 16:12:03

I seem to be having some issues setting window rules in my config...

I would like to have dwb only open on tag 1, and urxvt only on tag 2, so I added these lines

static Rule rules[] = {
	/* name				class		tags		flags */
	/* tags/flags=0 means no change to default */
	{ NULL,			        "float",	0,		FLAG_FLOATING },
	{ "float",		       NULL,	0,		FLAG_FLOATING },
	{ NULL,			        "dwb",       	1,		0 },
	{ NULL,			        "urxvt",	2,		0 },
};

But, both still open up on the currently focused tag. I even checked with xprop to make sure those are the correct class strings, but there must be something that I'm missing. Unless I misunderstood the man page, this should be a correct way to do this, right?

Last edited by SolarBoyMatt (2013-09-01 16:13:34)

Trilby · 2013-09-01 16:14:57

I just checked with xprop - those are not the correct class strings: they are case sensitive.

Those will match for name, or "URxvt" and "Dwb" should match for class.

SolarBoyMatt · 2013-09-01 16:34:28

Thanks, that worked.

When I ran xprop on dwb I saw:

WM_CLASS(STRING) = "dwb", "Dwb"

and something similar for urxvt, and just entered in the first string. I guess it was a case of misreading the xprop output.

Thanks again.

Trilby · 2013-09-01 16:40:20

It's an unfortunate name class between two entirely different strings. WM_CLASS contains the resource name string and the resource class string. Neither of these have anything to do with WM_NAME, even though the first is called the name. Window rules only match against these two, as matching against WM_NAME would be silly - it is constantly changing for most windows.

http://tronche.com/gui/x/xlib/ICC/clien … class.html

Trilby · 2013-10-03 01:58:58

I just implemented utf8 support for tags, titles, and status bars due to an emailed request. It seems to be working, but I pushed it to git after only the most minimal of testing. More testing would be appreciated, particularly from any users from locales that would make regular use of accented or other utf8 characters. My regular use will not have me encounter these enough to know if/how this works.

EDIT: if you pull this update, be sure your font in your local config.h is appropriate for utf8. Honestly I don't know much about fonts or internationalization, but I had a terminus font string there, and all my text was mangled upon restarting. I replaced the last bit of the terminus fonts string with a * and now it works perfectly:

static const char font[] =  "-xos4-terminus-medium-r-normal--14-140-72-72-c-80-*";

Last edited by Trilby (2013-10-03 02:09:35)

Knusperkeks · 2013-10-07 10:30:52

Thanks for this great piece of software
I'm really enjoying your little window manager but it doesn't want to work with a second monitor here

When using xrandr to activate my second monitor, my wallpaper apears and i can move my cursor there,
but i'm not able to get a window there. Neither can i move nor spawn a window on the second screen exept moving a floating by mouse.
The only thing i changed is XK_equal to XK_plus because the '=' is bit inconvinient to type on a german keyboard but all the other functions work fine.

Trilby · 2013-10-07 12:40:59

Knusperkeks, thanks for reporting this. Currently I can't replicate that problem, but I do know that multi-monitor support is still *very* limited in alopex. Someday it will be a fully-featured multimonitor WM, but if that is important to you, it may be a while before it is a good option.

That said, the problems you report are certainly bugs. Alopex should do what you expect there, and it does for me. I'll try to look into this in the coming week or so and will likely ask for more input as I do. Currently, though, the dayjob is taking a lot of my time, so my FOSS coding work has tapered off a bit for the time being.

bgc1954 · 2013-11-22 20:30:59

Trilby, it's been awhile.

When you find some time, I wonder if you could check into a fullscreen problem I seem to be having with alopex. It must have been there all along and I checked back in this thread but don't really see anything mentioned anywhere. I just built a game called monsterz from AUR and it plays fine until you try to go to fullscreen mode in the game. The resolution changes and all I see is my status bar enlarged at the bottom of the screen and the rest of the screen is black. No alopex keybindings function but I can exit by using ctrl+alt+backspace option which is in my .xinitrc.

After seeing this, I tried another game that I got from AUR called blockattack--exactly the same behavior and flobopuyo, which is in the community repo, does the same thing. All these games function fine in fullscreen mode in openbox.

Trilby · 2013-11-22 21:24:15

I just checked this out and consistently replicated the pretty nasty problem. I tracked down the cause almost immediately: when I added multimonitor support, I wanted alopex to transition smoothly between monitor configurations being changed, so it responds to any resizing events on the root window. But this conflicts with how these SDL games change the screen resolution.

While I don't know if it is a long term solution, I've put in a work around that seems to work quite smoothly (smooth for the user, if a bit inellegant in code). This added a new boolean variable to config.h and a new option and keybinding to the toggle function. If you only ever use one monitor configuration, then you can set the "ignore_root_resize" variable to "True" and never look back - it should work as desired with SDL games. If, however, you sometimes plug into external monitors and want alopex to be able to use them, then you should keep this variable set as False, but you can use the new keybinding to termparily toggle this to True in order to play an SDL game.

If/when I get around to working on a 3.0 of alopex, I suspect I'll do multimonitor very different, and I'll be sure to avoid such issues from the outset.

Last edited by Trilby (2013-11-22 21:24:56)

bgc1954 · 2013-11-23 03:15:32

Hey Trilby,

Thx for the quick response, as always Your solution would work great for me as I have no need for multi-monitor support at present.

Unfortunately, this is what I get when trying to build with makepkg -i

In file included from alopex.c:150:0:
config.h:59:1: error: stray ‘\302’ in program
 static Bool                        ignore_root_resize        = True;
 ^
config.h:59:1: error: stray ‘\240’ in program
config.h:59:1: error: stray ‘\302’ in program
config.h:59:1: error: stray ‘\240’ in program
config.h:59:1: error: stray ‘\302’ in program
config.h:59:1: error: stray ‘\240’ in program
config.h:59:1: error: stray ‘\302’ in program
config.h:59:1: error: stray ‘\240’ in program
config.h:59:1: error: stray ‘\302’ in program
config.h:59:1: error: stray ‘\240’ in program
config.h:59:1: error: stray ‘\302’ in program
config.h:59:1: error: stray ‘\240’ in program
config.h:59:1: error: stray ‘\302’ in program
config.h:59:1: error: stray ‘\240’ in program
config.h:59:1: error: stray ‘\302’ in program
config.h:59:1: error: stray ‘\240’ in program
config.h:59:1: error: stray ‘\302’ in program
config.h:59:1: error: stray ‘\240’ in program
config.h:59:1: error: stray ‘\302’ in program
config.h:59:1: error: stray ‘\240’ in program
config.h:59:1: error: stray ‘\302’ in program
config.h:59:1: error: stray ‘\240’ in program
config.h:59:1: error: stray ‘\302’ in program
config.h:59:1: error: stray ‘\240’ in program
config.h:59:1: error: stray ‘\302’ in program
config.h:59:1: error: stray ‘\240’ in program
config.h:59:1: error: stray ‘\302’ in program
config.h:59:1: error: stray ‘\240’ in program
config.h:59:1: error: stray ‘\302’ in program
config.h:59:1: error: stray ‘\240’ in program
config.h:59:1: error: stray ‘\302’ in program
config.h:59:1: error: stray ‘\240’ in program
config.h:59:1: error: stray ‘\302’ in program
config.h:59:1: error: stray ‘\240’ in program
config.h:59:1: error: stray ‘\302’ in program
config.h:59:1: error: stray ‘\240’ in program
config.h:59:1: error: stray ‘\302’ in program
config.h:59:1: error: stray ‘\240’ in program
config.h:59:1: error: stray ‘\302’ in program
config.h:59:1: error: stray ‘\240’ in program
config.h:59:1: error: stray ‘\302’ in program
config.h:59:1: error: stray ‘\240’ in program
config.h:59:1: error: stray ‘\302’ in program
config.h:59:1: error: stray ‘\240’ in program
config.h:59:1: error: stray ‘\302’ in program
config.h:59:1: error: stray ‘\240’ in program
config.h:59:1: error: stray ‘\302’ in program
config.h:59:1: error: stray ‘\240’ in program
config.h:59:1: error: stray ‘\302’ in program
config.h:59:1: error: stray ‘\240’ in program
config.h:59:1: error: stray ‘\302’ in program
config.h:59:1: error: stray ‘\240’ in program
config.h:59:1: error: stray ‘\302’ in program
config.h:59:1: error: stray ‘\240’ in program
config.h:59:1: error: stray ‘\302’ in program
config.h:59:1: error: stray ‘\240’ in program
config.h:59:1: error: stray ‘\302’ in program
config.h:59:1: error: stray ‘\240’ in program
config.h:59:1: error: stray ‘\302’ in program
config.h:59:1: error: stray ‘\240’ in program
config.h:59:1: error: stray ‘\302’ in program
config.h:59:1: error: stray ‘\240’ in program
config.h:59:1: error: stray ‘\302’ in program
config.h:59:1: error: stray ‘\240’ in program
In file included from alopex.c:150:0:
config.h:101:2: error: stray ‘\302’ in program
  { KEY1|KEY2,                    XK_r,           toggle,         "root resize"        },
  ^
config.h:101:2: error: stray ‘\240’ in program
config.h:101:2: error: stray ‘\302’ in program
config.h:101:2: error: stray ‘\240’ in program
config.h:101:2: error: stray ‘\302’ in program
config.h:101:2: error: stray ‘\240’ in program
config.h:101:2: error: stray ‘\302’ in program
config.h:101:2: error: stray ‘\240’ in program
config.h:101:2: error: stray ‘\302’ in program
config.h:101:2: error: stray ‘\240’ in program
config.h:101:2: error: stray ‘\302’ in program
config.h:101:2: error: stray ‘\240’ in program
config.h:101:2: error: stray ‘\302’ in program
config.h:101:2: error: stray ‘\240’ in program
config.h:101:2: error: stray ‘\302’ in program
config.h:101:2: error: stray ‘\240’ in program
config.h:101:2: error: stray ‘\302’ in program
config.h:101:2: error: stray ‘\240’ in program
config.h:101:2: error: stray ‘\302’ in program
config.h:101:2: error: stray ‘\240’ in program
config.h:101:2: error: stray ‘\302’ in program
config.h:101:2: error: stray ‘\240’ in program
config.h:101:2: error: stray ‘\302’ in program
config.h:101:2: error: stray ‘\240’ in program
config.h:101:2: error: stray ‘\302’ in program
config.h:101:2: error: stray ‘\240’ in program
config.h:101:2: error: stray ‘\302’ in program
config.h:101:2: error: stray ‘\240’ in program
config.h:101:2: error: stray ‘\302’ in program
config.h:101:2: error: stray ‘\240’ in program
config.h:101:2: error: stray ‘\302’ in program
config.h:101:2: error: stray ‘\240’ in program
config.h:101:2: error: stray ‘\302’ in program
config.h:101:2: error: stray ‘\240’ in program
config.h:101:2: error: stray ‘\302’ in program
config.h:101:2: error: stray ‘\240’ in program
config.h:101:2: error: stray ‘\302’ in program
config.h:101:2: error: stray ‘\240’ in program
config.h:101:2: error: stray ‘\302’ in program
config.h:101:2: error: stray ‘\240’ in program
config.h:101:2: error: stray ‘\302’ in program
config.h:101:2: error: stray ‘\240’ in program
config.h:101:2: error: stray ‘\302’ in program
config.h:101:2: error: stray ‘\240’ in program
config.h:101:2: error: stray ‘\302’ in program
config.h:101:2: error: stray ‘\240’ in program
config.h:101:2: error: stray ‘\302’ in program
config.h:101:2: error: stray ‘\240’ in program
config.h:101:2: error: stray ‘\302’ in program
config.h:101:2: error: stray ‘\240’ in program
config.h:101:2: error: stray ‘\302’ in program
config.h:101:2: error: stray ‘\240’ in program
config.h:101:2: error: stray ‘\302’ in program
config.h:101:2: error: stray ‘\240’ in program
config.h:101:2: error: stray ‘\302’ in program
config.h:101:2: error: stray ‘\240’ in program
config.h:101:2: error: stray ‘\302’ in program
config.h:101:2: error: stray ‘\240’ in program
config.h:101:2: error: stray ‘\302’ in program
config.h:101:2: error: stray ‘\240’ in program
config.h:101:2: error: stray ‘\302’ in program
config.h:101:2: error: stray ‘\240’ in program
config.h:101:2: error: stray ‘\302’ in program
config.h:101:2: error: stray ‘\240’ in program
config.h:101:2: error: stray ‘\302’ in program
config.h:101:2: error: stray ‘\240’ in program
config.h:101:2: error: stray ‘\302’ in program
config.h:101:2: error: stray ‘\240’ in program
config.h:101:2: error: stray ‘\302’ in program
config.h:101:2: error: stray ‘\240’ in program
config.h:101:2: error: stray ‘\302’ in program
config.h:101:2: error: stray ‘\240’ in program
config.h:101:2: error: stray ‘\302’ in program
config.h:101:2: error: stray ‘\240’ in program
config.h:101:2: error: stray ‘\302’ in program
config.h:101:2: error: stray ‘\240’ in program
config.h:101:2: error: stray ‘\302’ in program
config.h:101:2: error: stray ‘\240’ in program
config.h:101:2: error: stray ‘\302’ in program
config.h:101:2: error: stray ‘\240’ in program
config.h:101:2: error: stray ‘\302’ in program
config.h:101:2: error: stray ‘\240’ in program
config.h:101:2: error: stray ‘\302’ in program
config.h:101:2: error: stray ‘\240’ in program
config.h:101:2: error: stray ‘\302’ in program
config.h:101:2: error: stray ‘\240’ in program
config.h:101:2: error: stray ‘\302’ in program
config.h:101:2: error: stray ‘\240’ in program
Makefile:10: recipe for target 'alopex' failed
make: *** [alopex] Error 1
==> ERROR: A failure occurred in build().
    Aborting...

Something I'm doing wrong?

Last edited by bgc1954 (2013-11-23 03:27:57)

Trilby · 2013-11-23 03:48:33

Did you copy and paste something from the github website? Those warnings are due to non-breaking-space characters in the code. They are not in the actual file - but they are added by github's web display of the code so copy and paste will not work.

Arch Linux

#601 2013-08-10 17:10:41

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

#602 2013-08-10 17:17:17

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

#603 2013-08-10 17:29:48

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

#604 2013-08-10 17:34:30

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

#605 2013-08-10 18:10:46

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

#606 2013-08-10 21:48:20

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

#607 2013-08-29 18:29:56

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

#608 2013-08-29 18:48:43

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

#609 2013-08-31 14:50:33

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

#610 2013-08-31 14:55:21

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

#611 2013-08-31 15:37:58

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

#612 2013-08-31 20:12:45

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

#613 2013-08-31 20:15:59

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

#614 2013-08-31 20:24:32

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

#615 2013-09-01 16:12:03

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

#616 2013-09-01 16:14:57

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

#617 2013-09-01 16:34:28

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

#618 2013-09-01 16:40:20

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

#619 2013-10-03 01:58:58

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

#620 2013-10-07 10:30:52

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

#621 2013-10-07 12:40:59

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

#622 2013-11-22 20:30:59

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

#623 2013-11-22 21:24:15

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

#624 2013-11-23 03:15:32

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

#625 2013-11-23 03:48:33

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

Board footer