the euclid-wm thread

wmdiem · 2010-06-23 18:11:00

Hi all.
I wanted to announce a new tiling window manager that is currently under development: euclid-wm.

It is hosted on googlecode, and is currently available via svn:
http://code.google.com/p/euclid-wm/

The arch linux forums seem to have a lot of tiling wm types so I thought this would be a good place to look for people who might be interested in giving it a test drive.

Obviously any feedback would be very much appreciated.
Thanks.

Cheers.

Last edited by wmdiem (2011-12-15 00:42:19)

falconindy · 2010-06-23 18:54:12

You should learn to write a proper Makefile -- not just for distribution but for yourself as well. Maintaining lots of separate batch scripts will be unwieldly and possibly even unportable.

Your install file is also wrong -- the man page needs to be installed to /usr/share/man/man1 otherwise man will be unable to find it. I also find your start-euclid script to be unnecessary. A lightweight WM such as this is much more easily started via .xinitrc.

I'm a DWM user myself, and unfortunately I see nothing shockingly new or revolutionary about your WM. What features are you going to provide to make this stand apart from say... scrotwm, dwm, wmi, or musca?

For anyone interested in trying it, here's a PKGBUILD:

pkgname=euclid-wm-svn
pkgver=33
pkgrel=1
pkgdesc="a minimalist, tiling window manager for X11"
arch=('i686' 'x86_64')
url="http://code.google.com/p/euclid-wm/"
license=('custom')
depends=('libx11')
makedepends=('subversion')

_svntrunk=http://euclid-wm.googlecode.com/svn/trunk/
_svnmod=euclid-wm-read-only

build() {
  cd "$srcdir"

  if [ -d $_svnmod/.svn ]; then
    (cd $_svnmod && svn up -r $pkgver)
  else
    svn co $_svntrunk --config-dir ./ -r $pkgver $_svnmod
  fi

  msg "SVN checkout done or server timeout"
  msg "Starting make..."

  rm -rf "$srcdir/$_svnmod-build"
  cp -r "$srcdir/$_svnmod" "$srcdir/$_svnmod-build"
  cd "$srcdir/$_svnmod-build"

  ./compile || return 1
}

package() {
  cd "$srcdir/$_svnmod-build"

  install -m755 euclid-wm -D ${pkgdir}/usr/bin/euclid-wm
  install -m644 euclid.desktop -D "$pkgdir/usr/share/xsessions/euclid.desktop"
  install -m644 euclid.1 -D "$pkgdir/usr/share/man/man1/euclid-wm.1"
}

If someone else wants to slap their name on this and post it to the AUR, be my guest.

wmdiem · 2010-06-23 19:24:21

@falconindy
"You should learn to write a proper Makefile -- not just for distribution but for yourself as well. Maintaining lots of separate batch scripts will be unwieldly and possibly even unportable."
I know. It's on my TODO list.

"Your install file is also wrong -- the man page needs to be installed to /usr/share/man/man1 otherwise man will be unable to find it"
Thanks for catching that. I don't know when or why that got changed, it used to be in the right spot.

"I also find your start-euclid script to be unnecessary."
Yes, it is pretty well pointless at the moment. I had it there in case I wanted to do some autoexec or catch crashes. But you are right. It is at the moment unnecessary.

"I'm a DWM user myself, and unfortunately I see nothing shockingly new or revolutionary about your WM."
I don't claim that it's shocking or revolutionary. It allowed a workflow that the other WMs I tried didn't seem able to fill. you could say I had an itch. In general they seemed like they either had very intuitive interfaces (keybindings) at the cost of flexibility (e.g., scrotwm), or they had infinite flexibility layouts but awkward interfaces (e.g., i3).

The particulars:
1) Pretty flexible layouts (if you have lots of windows and want something really crazy, euclid might not be able to do it, but euclid can achieve any configuration I've ever needed with very few keypresses).
2) The stack implementation: The windows are actually unmapped, their titles are displayed in a single stack that can be shown at the bottom of the screen. wmii does something a little bit like this, iirc, but it is actually quite different (the stack is per container, and it gets split between the top and bottom, I liked the idea but it seemed a bit clumsy.)

I made some comments on this here: http://code.google.com/p/euclid-wm/wiki/QnA

Thanks a lot for taking the time to look it over and type up your thoughts. It's really appreciated.

Inxsible · 2010-06-23 19:40:33

I use i3 now. I used to use Musca, but there were a couple of bugs relating to fullscreen apps and multi-monitor which made me go look somewhere else. One thing that I did find quirky about i3 was that it left empty cells unless proper spans were done for certain windows -- meaning additional keystrokes.

I will try out euclid later today and see how it goes. I hope euclid avoids that.

But you did come to the right place to have your wm be given a whirl, because as you mentioned, Archers do tend to use tiling WMs more than anything else.

Last edited by Inxsible (2010-06-23 19:41:44)

wmdiem · 2010-06-23 19:44:18

It does avoid the empty cell issue (that bugged me too).
It's handling of apps that put themselves in fullscreen is buggy (no particular issue I just haven't gotten around to properly handling it yet). Current work around for this: if you want to watch a fs flash video, put euclid in fs mode first, then click the fs button in the flashplayer.

Sirsurthur · 2010-06-23 20:37:55

Not sure if I did something wrong but by using slim and .xinitrc "exec /usr/bin/euclid-wm", euclid-wm does not start.

wmdiem · 2010-06-23 21:52:52

I'm really sorry to hear that. But thanks for letting me know.

First off I haven't used slim, so if I ask irrelevant questions(or generally seem clueless) forgive me.

What did you get? (e.g., did it look like a crash? did it just sit at the login and do nothing? Did an xscreen flash for a second and then dump you back at the login?)

Just to rule out the obvious,

I assume it compiled (xlib headers are installed) and installed without error, including setting permissions.

I'm assuming you didn't just get a blank screen and assume that it hadn't started (that is what it looks like when it starts). One thing that could make this (much) worse, is if there is no x-terminal-emulator and not dmenu_run on your system (my install script checked for these, I don't think the PKGBUILD does). Then you wouldn't be able to do anything, and it would just sit there with the default x screen.

Assuming none of these is the culprit:

euclid-wm prints some basic info as it starts up, which could help me figure out what could be going wrong. I don't know where stdout goes in your setup, but if you do, could you send it to me? If not, could you try starting euclid redirecting stdout to a file, e.g.,

euclid-wm > ~/euclid_debug

Another thing that might rule out a few things is to start a new vt and try to start it directly e.g.:

#xinit -- :1 vt12

Then in the terminal you get:

#euclid-wm

Please send any information you can on what happened. I (obviously) would like to get this ironed out if you are willing.
Thanks.

BTW, Has anyone else has this happen? Or is Sirsurthur the first brave victim?

BKLive · 2010-06-23 23:10:30

Added this to the AUR

bkl

wmdiem · 2010-06-23 23:21:32

Many thanks!

As an aside, after the initial scolding from falconindy for not having a Makefile, I added a basic one. It is pretty crude but it seems to work (after limited testing); If anyone wants to point out sophomoric mistakes or portability issues I'll correct it.

Also, regarding Sirsurthur's problem, when I went to write the Makefile I realized that the install script I had was missing the chmod lines, so if you were using that script it wouldn't have worked. How they went missing I don't know, I guess I retyped it by hand at some point, and was just sloppy.

Best

falconindy · 2010-06-24 01:11:55

wmdiem wrote:

As an aside, after the initial scolding from falconindy for not having a Makefile, I added a basic one. It is pretty crude but it seems to work (after limited testing); If anyone wants to point out sophomoric mistakes or portability issues I'll correct it.

Aww, now I feel bad. ;P

Cleaned it up a bit for you. Granted, it's more like my own style now, but it does address a few legit concerns as well (mainly honoring a prefix and DESTDIR)

PREFIX    = usr
SHAREDIR  = ${PREFIX}/share
MANDIR    = ${SHAREDIR}/man
BINDIR    = ${PREFIX}/bin

CC = cc -pedantic -Wall
CFLAGS = -O2 -g
LDFLAGS = -lX11

.PHONY: all install clean uninstall

all: euclid-wm

euclid-wm: euclid-wm.c
    ${CC} ${LDFLAGS} ${CFLAGS} $< -o $@

install: all
    @echo "Installing to ${DESTDIR}/${PREFIX}"
    mkdir -p "${DESTDIR}/${BINDIR}"
    cp euclid-wm ${DESTDIR}/${BINDIR}
    chmod 755 "${DESTDIR}/${BINDIR}/euclid-wm"
    cp start-euclid "${DESTDIR}/${BINDIR}/start-euclid"
    chmod 755 "${DESTDIR}/${BINDIR}/start-euclid"
    mkdir -p "${DESTDIR}/${SHAREDIR}/xsessions"
    cp euclid.desktop "${DESTDIR}/${SHAREDIR}/xsessions"
    chmod 644 "${DESTDIR}/${SHAREDIR}/xsessions/euclid.desktop"
    mkdir -p "${DESTDIR}/${MANDIR}/man1"
    cp euclid.1 "${DESTDIR}/${MANDIR}/man1/euclid-wm.1"
    chmod 644 "${DESTDIR}/${MANDIR}/man1/euclid-wm.1"


uninstall:
    rm -f ${DESTDIR}/${BINDIR}/euclid-wm
    rm -f ${DESTDIR}/${BINDIR}/start-euclid
    rm -f ${DESTDIR}/${SHAREDIR}/xsessions/euclid.desktop
    rm -f ${DESTDIR}/${MANDIR}/man1/euclid-wm.1

clean:
    rm -f euclid-wm

andresp · 2010-06-24 01:25:53

you're supposed to use install -Dm644, not mkdir -p && cp && chmod

falconindy · 2010-06-24 01:33:42

Sure, except that install isn't portable. On some systems it's a shell script, and on some it just doesn't exist.

andresp · 2010-06-24 01:39:14

falconindy wrote:

Sure, except that install isn't portable. On some systems it's a shell script, and on some it just doesn't exist.

Then again neither is mkdir -p: autoconf docs on the subject.

install is posix, if he's going for a lower common denominator, then a hand written makefile isn't going to cut it. Look into cmake (yes) or autoconf (ew).

falconindy · 2010-06-24 01:52:10

andresp wrote:

falconindy wrote:
Sure, except that install isn't portable. On some systems it's a shell script, and on some it just doesn't exist.
Then again neither is mkdir -p: autoconf docs on the subject.
install is posix, if he's going for a lower common denominator, then a hand written makefile isn't going to cut it. Look into cmake (yes) or autoconf (ew).

Fair enough. That's a pretty decent reference. Probably the only thing I'll ever take from autotools.

Using install certainly does clean it up a bit...

install: all
    @install -m755 euclid-wm -D ${DESTDIR}/${BINDIR}/euclid-wm
    @install -m755 start-euclid -D ${DESTDIR}/${BINDIR}/start-euclid
    @install -m644 euclid.desktop -D ${DESTDIR}/${SHAREDIR}/xsessions/euclid.desktop
    @install -m644 euclid.1 ${DESTDIR}/${MANDIR}/man1/euclid-wm.1

andresp · 2010-06-24 02:00:02

falconindy wrote:

Fair enough. That's a pretty decent reference. Probably the
only thing I'll ever take from autotools.

Just because I think the subject is interesting, a quote from netbsd's
bootstrap:

# Some versions of mkdir (notably SunOS) bail out too easily, so use the
# install-sh wrapper instead.
mkdir_p()
{
    for dir in $@; do
        run_cmd "$install_sh -d -o $user -g $group $dir"
    done
}

mkdir_p_early()
{
    [ -d "$1" ] && return 0    
    mkdir -p "$1" 2> /dev/null && return 0
    parent=`dirname "$1"`
    mkdir_p_early "$parent"
    if [ ! -d "$1" ] && mkdir "$1"; then
        echo_msg "mkdir $1 exited with status $?"
        die "aborted."
    fi
    return 0
}

http://cvsweb.netbsd.org/bsdweb.cgi/pkg … h_tag=MAIN

Where install_sh is the shell replica of install you were talking about.

Anyway, ot...

saline · 2010-06-24 05:37:39

Subversion...... I imagine that's a choice of hosting, though.

Builds fine and I can run it in :1 with a call to new xinit without mucking anything up (ArchWiki ftw).

Cons:
When I move or resize windows, everything flickers. That is just 3 urxvt terminals.
I can't pull in a view (Think Mod-Ctrl-2 in dwm).
M-C-Backspace does not quit (possibly unless you allow that to kill X in your configs, but that is a hack).

Pros:
The vim-style key bindings are a plus.
Arbitraily moving windows around could be useful, but I never really moved windows in Awesome.

I don't want to be harsh; this has potential. However, dwm and tmux currently do a better job for me. Keep working on it and I'll play around with it every once in a while.

Last edited by saline (2010-06-24 05:41:34)

dmz · 2010-06-24 07:07:39

The biggest questions that arise:
* Can you use escapekeys just like in screen, ratpoison and stumpwm?
* How does it work with multihead setups?

Inxsible · 2010-06-24 12:47:02

dmz wrote:

The biggest questions that arise:
* Can you use escapekeys just like in screen, ratpoison and stumpwm?
* How does it work with multihead setups?

In his TODO list, he has put in support for multi-head. So I am assuming that currently multi-head is not fully supported.

I havn't had much time to play around with this, but the one feature I like is the improvement over i3 (which I currently use) and that is empty cells when moving windows in a Table Cell.

Last edited by Inxsible (2010-06-24 12:48:30)

BKLive · 2010-06-24 13:42:30

I've posted a few bugs on your google code site. One of them was me being dumb, so I apologize, but the rest were legit.

Namely: when x-terminal-emulator isn't explicitly defined, then it just errors out in the console (you have to Alt+F1 to see it, as I use CLI to log in); Using Alt+(direction key) before any windows are opened crashes the system; and finally, when you first start it up, there is no mouse unless you open an application (does not come up if you open dmenu).

Very breezy though! I like the instananeousness of it! (Which is probably why I've been "regressing" from KDE to XFCE to *box+xfce4-panel to *box+tint2 to i3... to CLI lol)

Inxsible · 2010-06-24 14:38:46

BKLive wrote:

............ (Which is probably why I've been "regressing" from KDE to XFCE to *box+xfce4-panel to *box+tint2 to i3... to CLI lol)

Regress ????

I would call that PROGRESS !!

wmdiem · 2010-06-24 16:50:23

First, I've updated the makefile. A big thanks to falconindy and andresp, for the help on that.

@saline: Thanks for the critiques. As far as the exit, it was a shameless, lazy hack. I've now added a basic exit binding (mod + ctrl + del).
To the flicker, I suppose It hadn't bothered me. I might be able to do something to make it more aesthetic (e.g., maybe lowering the resize increment would improve it). I'd have to play around to figure out what could be done. As to pulling in a view, it's been awhile since i looked at dwm, what does ctr + mod + 2 do? I can't find a description (my google fu must be weak).

@dmz: It does not have escape keys. I've thought (several times) about making it modal, but have not decided that it would be beneficial. As to how it does on multi-head, I have no idea. I don't have a mulithead setup at the moment, so that is a pretty big obstacle to adding multihead awareness (although I have tried to write it so it could be added in later without too much nastiness or rewriting, but at the moment there are higher priority issues).

@BKLive: thanks for the bug reports. I've tried to address the segfault, but it needs to be tested (also, I asked for a little more information, it looked to me like two issues, and I want to make sure the second one is separate and harmless). As to the responsiveness, I know, it's one of the things i love about it. Crank the load up, and it doesn't falter. Run it for a few days with plenty of windows and workspaces and it still has < 1sec of cpu time, and around 1MB of RAM. As to your "regression" I've jokingly said that euclid is really an xterm multiplexer and anything else is unsupported (so consider yourself lucky if it works).

In general thanks to everyone who has given it a try. The feedback has been a huge help.

portix · 2010-06-24 18:48:20

wmdiem wrote:

I've tried to address the segfault, but it needs to be tested

The segfault is in line 817, but you can also put something like

if (!cv->mfocus) {
    return;
}

at the beginning of "shift_windows", if there is no window, there is nothing to shift,.

wmdiem · 2010-06-24 19:00:57

@portix: Thanks for catching it. I've added a check at the top. I don't know how I let things like that slid through.

Aedit · 2010-06-24 19:05:59

Nice to see another tiling wm. I rather like the window move and resize functions.

I notice that vertical moves (alt+JK) and horizontal moves (alt+HL) are treated differently: a vertical move cannot move a window into a new row, but a horizontal move can create a new column. As far as I can see, there is no reason for not allowing it. (Note after rotating with Alt+Tab it is horizontal moves which cannot create a new column.)

You could build more usability into the default layout creation. If I open 3 terminals in a row I almost never want them arranged according to your default (3 one above the other). I could move them of course, but in scrotwm or xmonad I would already have one master on the left and 2 piled up on the right. You could cycle through some more automatic layouts under Alt-Tab.

Just a few issues I noticed:
In /usr/share/xsessions/euclid.desktop Exec=start-euclid should be Exec=euclid-wm.

After rotating (Alt+Tab) the Alt+H/L keys are the wrong way round.

Are transient windows just treated like other windows?

In the man page the keybinding for toggle stack visibility should be M+space not M+shift+space.

The line system("x-terminal-emulator &"); should be system("xterm &");

There are a lot of source code lines containing just tabs or ending in spaces. It would be good to clean them up. Also there are a bunch of unnecessary files pulled in by the PKGBUILD to the src directory. I'd vote for git rather than subversion btw.

Looking forward to a text config file and a status bar...

wmdiem · 2010-06-24 19:54:28

@Aedit: "Nice to see another tiling wm. I rather like the window move and resize functions."
Thanks!
"a vertical move cannot move a window into a new row, but a horizontal move can create a new column. As far as I can see, there is no reason for not allowing it."
The behavior you describe (if I follow you) is exactly what I originally envisioned. Unfortunately (maybe I'm brain dead) but I couldn't figure out a non-clunky way of doing it. Essentially the problem comes down to what the intuitive behavior becomes once you allow mixing horizontal and vertical tracks in a single layout. If someone can think of a good way of implementing this (with well defined intuitive behavior after the horizontal and vertical are mixed and nested) I would be quite willing to try to implement it. But I tried once, gave up, and rewrote it as it is. The current behavior is a sort of workable compromise.

"You could build more usability into the default layout creation. If I open 3 terminals in a row I almost never want them arranged according to your default (3 one above the other)"
I've thought of doing this (it wouldn't be hard), but it hasn't worked it's way up on the priority list yet. My reason for not worrying about it is just that moving windows is easy.

"In /usr/share/xsessions/euclid.desktop Exec=start-euclid should be Exec=euclid-wm."
Yes, start-euclid no longer serves a purpose and will be removed unless and until I find a need for a wrapper.

"After rotating (Alt+Tab) the Alt+H/L keys are the wrong way round"
Will fix. This whole opening it up to testing has been really humbling. I've had more facepalm/what-were-you-thinking/how-did-you-miss-that moments in the last 48 hrs than I thought I ever could. Thanks for catching it.

"Are transient windows just treated like other windows?"
yes. I spent a considerable amount of time trying to figure out what to do with transient windows. Finally I decided that if I really bought the whole "floating windows don't belong" thing then it applies to transients too (as an example: sometimes when i'm looking at a save dialog I want to be able to see the main window, e.g., to remember what I'm saving). That said, they don't always cooperate (I'm looking at you Chrome).

"In the man page the keybinding for toggle stack visibility should be M+space not M+shift+space"
Will fix it, thanks for noticing.

"The line system("x-terminal-emulator &"); should be system("xterm &");"
Why's that? At least on Debian, xterm is an actual executable (that many people don't like to use), x-terminal-emulator is a link that the user can point to whatever emulator he likes. The real solution to this will come when I write a config, then the user can point to anything he wants.

"There are a lot of source code lines containing just tabs or ending in spaces. It would be good to clean them up."
Yeah, the source is a mess right now. It's on the list.

"Also there are a bunch of unnecessary files pulled in by the PKGBUILD to the src directory."
The PKGBUILD is very kindly maintained by BKLive above.

"Looking forward to a text config file and a status bar."
*grimmace* I'll get down to the config once the deluge of bugs clams down. I'd really like to do the status bar as a separate executable. If I did, it would come with the whole issue of how to handle dock-type apps, which I've been thinking about, but haven't yet resolved.

Arch Linux

#1 2010-06-23 18:11:00

the euclid-wm thread

#2 2010-06-23 18:54:12

Re: the euclid-wm thread

#3 2010-06-23 19:24:21

Re: the euclid-wm thread

#4 2010-06-23 19:40:33

Re: the euclid-wm thread

#5 2010-06-23 19:44:18

Re: the euclid-wm thread

#6 2010-06-23 20:37:55

Re: the euclid-wm thread

#7 2010-06-23 21:52:52

Re: the euclid-wm thread

#8 2010-06-23 23:10:30

Re: the euclid-wm thread

#9 2010-06-23 23:21:32

Re: the euclid-wm thread

#10 2010-06-24 01:11:55

Re: the euclid-wm thread

#11 2010-06-24 01:25:53

Re: the euclid-wm thread

#12 2010-06-24 01:33:42

Re: the euclid-wm thread

#13 2010-06-24 01:39:14

Re: the euclid-wm thread

#14 2010-06-24 01:52:10

Re: the euclid-wm thread

#15 2010-06-24 02:00:02

Re: the euclid-wm thread

#16 2010-06-24 05:37:39

Re: the euclid-wm thread

#17 2010-06-24 07:07:39

Re: the euclid-wm thread

#18 2010-06-24 12:47:02

Re: the euclid-wm thread

#19 2010-06-24 13:42:30

Re: the euclid-wm thread

#20 2010-06-24 14:38:46

Re: the euclid-wm thread

#21 2010-06-24 16:50:23

Re: the euclid-wm thread

#22 2010-06-24 18:48:20

Re: the euclid-wm thread

#23 2010-06-24 19:00:57

Re: the euclid-wm thread

#24 2010-06-24 19:05:59

Re: the euclid-wm thread

#25 2010-06-24 19:54:28

Re: the euclid-wm thread

Board footer