Hi
Last few days I have been working on "wlterm", a native terminal
emulator for wayland. You can find it here:
http://github.com/dvdhrm/kmscon
Or check it out from:
git://github.com/dvdhrm/kmscon.git
It shares the repository with "kmscon" currently. However, you can
build it independently with:
./autgen.sh --disable-kmscon --enable-wlterm && make
This will only build what is required for wlterm. The only required
dependency is libxkbcommon and libwayland-client/cursor! Everything
else is optional and will only be used when available during
./configure.
You can run it with:
./wlterm [--debug]
You can check out command-line options with:
./wlterm -h
You may wonder why wlterm is needed? There are several reason why I wrote it:
1) We need more independent clients written from scratch that try to
find bugs in the wayland-client API. If we use toytoolkit all the
time, we will probably not find them. wlterm draws its own decoration
and does not depend on any demo-code from the weston repository. So
its nice to check whether new weston features are working and how they
behave. The more independent implementations we have, the better
testing we get.
2) I use it to test the TSM library. TSM is a terminal-emulator state
machine that parses vt220/xterm control-sequences. It has no
dependencies at all and does not perform any rendering. It is solely
to parse and interpret CSI/OSC/etc. sequences. There is no such
library out there so I created TSM (which is already shared between
wlterm and kmscon). Other libraries like libvte have huge X, Gtk, Qt
etc. dependencies (sadly). And Kristian asked me whether it makes
sense to also share it with weston-terminal. Keep in mind that
weston-terminal does interpret only a small subset of xterm
escape-sequences and no-one really wants to maintain/develop a full
parser in weston-terminal (or is someone working on that?).
3) Get a proper and maintained emulator for weston. I intend to
maintain wlterm together with kmscon (but both will remain independent
from each other). So feel free to file bugreports, feature-requests or
happy-user-feedback. I am open to suggestions. But I am a horrible
designer so don't expect it to be fancy. I rather work on
functionality than on beautiful decorations. I will also keep the
"master" branch a "stable" branch so you can expect it to always work
and to contain no experimental features (no guarantee, though).
4) To get more insight into wayland protocol internals. As I am
working on man-pages for libwayland, I wrote the small fake-toolkit
from scratch to get a better feeling. I can recommend this to
everybody who wants to get more knowledge on how it works. And to
everybody who wants to contribute to the man-pages...
I don't know how I will continue this when the big toolkits get proper
wayland-support (with decorations) and the well-known
terminal-emulators work with weston. However, until then I try to
maintain it.
Thanks for the big help on IRC! (the resizing-bugs are fixed now)
Regards
David