[prev in list] [next in list] [prev in thread] [next in thread]
List: konsole-devel
Subject: [Konsole-devel] terminal emulation. (various points)
From: Lars Doelle <lars.doelle () on-line ! de>
Date: 2012-09-30 12:20:16
Message-ID: 201209301420.16827.lars.doelle () on-line ! de
[Download RAW message or body]
Hi All,
as pronounced, i forward the mail containing a list
of topics that could improve terminal emulation in
principle.
-Lars
["forwarded message" (message/rfc822)]
Return-path: <dh.herrmann@googlemail.com>
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on x64.localnet
X-Spam-Level:
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
RCVD_IN_DNSWL_LOW,SPF_PASS,T_DKIM_INVALID autolearn=unavailable version=3.3.2
Envelope-to: doelle@localhost
Delivery-date: Sat, 29 Sep 2012 21:26:48 +0200
Received: from ip6-localhost ([::1] helo=x64.localnet)
by x64.localnet with esmtp (Exim 4.80)
(envelope-from <dh.herrmann@googlemail.com>)
id 1TI2ga-00073h-La
for doelle@localhost; Sat, 29 Sep 2012 21:26:48 +0200
Received: from mail.exess.net [195.64.106.47]
by x64.localnet with POP3 (fetchmail-6.3.22)
for <doelle@localhost> (single-drop); Sat, 29 Sep 2012 21:26:48 +0200 (CEST)
Received: from mail-we0-f179.google.com ([74.125.82.179])
by pdns2.isc.de with esmtp (Exim 4.72)
(envelope-from <dh.herrmann@googlemail.com>)
id 1TI2gO-0006dn-SS
for lars.doelle@on-line.de; Sat, 29 Sep 2012 21:26:38 +0200
Received: by weyz49 with SMTP id z49so2436085wey.24
for <lars.doelle@on-line.de>; Sat, 29 Sep 2012 12:26:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlemail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type:content-transfer-encoding;
bh=DeQAEjXgHjA1zUIH5GKQOmX93ttNnq6TAUMpDM3bEJw=;
b=s/Y3jeWLxlNHDX8W9laA/g1kx6BejK26yqmcH5btFFzVFDcm2JffZ4nZ5GkZKutD7R
bDjGWdC2erlebpElwWITEzhrADzg1A8raeyXG9W84AzZbyrj7LgUGxXEy+1rg8Kl4M9N
Ghk8YPHAt32y9ZeO9TlUhug3YHtUS2Suv3D4zwv5DtVibEh7A/xaQmjGud3eumzD2vJJ
gXTu7ClhjJxxbbG4yiG26g65t6x/HmzsXj7ayw05EXQ++Tu+Lnij0PmV8mKeaZlLSvU7
JuPQiYp5D8aYDKBHJx+IrHJ6hSrFOczhyjdLXhrAm29wj/tjYAZW+NyBWTW2vTe2Bhzy
MePg==
MIME-Version: 1.0
Received: by 10.180.87.34 with SMTP id u2mr4892972wiz.4.1348945436801; Sat, 29
Sep 2012 12:03:56 -0700 (PDT)
Received: by 10.216.14.166 with HTTP; Sat, 29 Sep 2012 12:03:56 -0700 (PDT)
In-Reply-To: <201209291905.55035.lars.doelle@on-line.de>
References: <201209291905.55035.lars.doelle@on-line.de>
Date: Sat, 29 Sep 2012 21:03:56 +0200
Message-ID: <CANq1E4RYT5ZrR8ea6n8uzgMvNTuvwQCh-V01fgwvrP4Qa4ndrg@mail.gmail.com>
Subject: Re: wlterm
From: David Herrmann <dh.herrmann@googlemail.com>
To: Lars Doelle <lars.doelle@on-line.de>
Cc: Thomas Dickey <dickey@his.com>
Content-Type: text/plain;
charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-UID:
Hi Lars
On Sat, Sep 29, 2012 at 7:05 PM, Lars Doelle <lars.doelle@on-line.de> wrote=
:
> David,
>
> i saw an article about wlterm on LWN.
>
> I'm the author of the konsole, the terminal in the KDE distribution
> and i write to get in contact with you.
>
> As a matter of fact, contact between the authors of the various
> terminal emulators is rare, and i only exchanged a few lines with
> Thomas Dickey, who maintains the xterm and the ncurses
> library now since an eternety.
That's sad. I am mostly working on kernel-development and
communication is the most important thing we have there. However, I
feel flattered that you contacted me. wlterm emerged out of kmscon
(which is still the main project I am working on in this regard) and
so I am not into terminal-emulation for very long. The reason I
started developing TSM (the terminal-emulation layer behind
wlterm/kmscon) was that I couldn't find a decent library that does
terminal-emulation without doing rendering. Both wlterm and kmscon
require independent rendering layers so I couldn't use the known
libraries like libvte.
Anyway, you're not the first person who asks me whether this wouldn't
be a good opportunity to try something new in terminal-emulation.
> Personally, i have retired from the development of the konsole,
> as maintaining it means to cope with a bug list that always have
> a score of 90 open points, though the application was bug-free
> from the very beginning. Terminal applications are simply used
> in so many different ways.
>
> I followed the wayland development with quite some interest and
> even managed to run one of the releases. Not sure, if the terminal
> that was included there, is the one from your pen.
No, weston shipped weston-terminal, which is just a proof-of-concept
but never intended to be maintained for a longer time. I started
wlterm actually just 6 days ago so you've probably not used it, yet.
But wlterm was just about rendering, anyway. I started TSM like 1 year
ago.
> Terminal-wise, i wonder from to time, if it would not be possible to
> do a step ahead and redefine the (use of the) protocol. My cloudy
> idea is that one could more cleanly separate the fullscreen mode
> from the command line mode and extend the support of the later.
>
> One could then for instance provice features as separting the
> stdout/stderr with different colors, honor the return codes, fold
> long lines in the history (which have arbitrary length) and improve
> support of the Unix process management (i.e. Stevens' Unix
> programming Chapter 9) extend session management to
> command line applications, etc. pp.
I am always interested in new ideas. Wayland itself is defining new
standards so it is indeed a perfect time to think about more. However,
I definitely need some more-detailed explanations of your ideas. I
know that process/session-management is often asked for by users. But
I cannot follow what you mean by separating "fullscreen" and
command-line mode?
I think the first step is to arouse interest (especially mine). I have
a lot of interesting projects running currently and haven't though
that much about terminal-emulation (to be honest). So I would be glad
if you could give me some more input here.
If there are interesting ideas to work on, I bet we can find people to
work on it.
> As the terminal is wired deep into the Unix-DNA, and the command
> line is handled by readline- and the ncurses-library as well as by the
> bash, such a project would be challenging both from a technical and
> from a social point of perspective.
>
> Many yet individual projects would have to agree upon a common
> way of handling things. Clearly, such a task is to much for one, so
> i ask, if you might have interest in working in such a direction. I for
> one have only limited resources, but i could put some time into it.
That is solvable. Kernel-development taught me that if there are
interesting problems to solve, 2000 people can work together in short
times-spans to create the most awesome code you can think of.
> Perhaps, as Wayland renews the graphical surface now, the
> command line should take this chance to catch up, too.
I am open to any ideas. I appreciate the fact that you contacted me
and that there is actual interest in this area. While developing TSM I
noticed what big legacy terminal-emulation actually is. So many stuff
that is just not used or which doesn't even make sense in actual
_emulators_. Yet, there seems to be much stuff missing. Multi-language
output is still weird (also that may be related to the fact that CJK
letters need like twice the horizontal space), process management is
hooked up via applications on top of it (whether its bash-management,
screen or one of the new fancy stuff) and frame-management is entirely
missing.
I have to admit, I am no fan of the features that the Enlightenment
people added to their new "terminology" emulator. Images, videos and
such stuff is simply not the responsibility of terminal-emulation. But
I am really open to improving actual terminal-emulation.
> Kind regards,
>
> Lars D=F6lle
Regards
David
_______________________________________________
konsole-devel mailing list
konsole-devel@kde.org
https://mail.kde.org/mailman/listinfo/konsole-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic