[Konsole-devel] Bare bones Konsole
lars.doelle at on-line.de
lars.doelle at on-line.de
Sat Dec 3 08:09:09 UTC 2005
> I am the author of Anthias (http://anthias.sf.net).
You might find a related attempt of interest:
> I want to integrate
> Konsole into the application using the Konsole-KPart.
I fear, you will not come much beyond konqueror's "midnight commander" profile
with only a kpart, and i think you'll might have to dig deeper both into the
konsole and bash. But i may well misinterprete your approach.
> I am trying something simple for starters and not able to get it to work.
> Probably doing something stupid somewhere; I am a newbie to the KDE API.
> I have attached a tiny demo code, which creates a Konsole KPart and tries
> to run an application. But the KPart starts running a shell as soon as it
> is shown. Is there someway to simply run the specified program, without
> invoking the shell?
No. But you can:
1) export SHELL, and create the part, but this is not what you want, since you
appear to do this more but once.
2) use konsolePart::sendInput("myprogram\n") to the running part, but this is
not what you want, since you want to have control over myprogram, too, for
instance to gain the return code or recognize it is done or get stdout and
stderr separately, as you appear to want from your mockup.
(I do not like that this function exists at all, btw, as it is an exploitable
security hole under some circumstances, e.g. because a user might run a root
session too, which can then be accessed with only user rights over dcop.
It is unlikely though, that a kpart has a "su" session, say in konqueror or
kdevelop, but in the program you are about to write, it would be).
> (Btw, I have dug into the Konsole's code, and my hunch is this is the
> expected behaviour of Konsole, but I will wait for the group's comments.)
I believe, you'll end binding your program with some konsole material.
You might try to extend the kpart interface, but my suspicion is that you'll
run in other limitations then, with respect to your purpose.
The basic problem, i think you're facing, is, that both the shell and the
terminal emulation have a very particular task at hand that you attempt to
merged somehow for a finer integration, but merging a shell and a terminal
emulation is not a good idea, too.
My clue is, that you'd need to extend both the konsole and the zsh for your
purpose. You'll need to extend the konsole as the rendering you plan have to
be different (e.g. different fonts within one session). You'll need to extend
the shell, to gain the particular information you need (e.g. command executed
signal, return code, cwd, stderr, etc.).
To this end, you'd need to define a kind of interface between the terminal
(this is partly the konsole and partly your program) and shell (the bash).
It could work such, that between the shell and the terminal, a private
communication tunnel over the usual file handles is established, which would
means to extend the escape sequences to create such a tunnel. This would for
instance mean a "prompt" issued to the terminal, which translates it to the
user. You can go a long way e.g., with the existing bash, using PS1, which
only misses the return code. You could already set it such, that it issues
escape sequences, so that some of the info you need get separated.
Note that no stderr channel exists between the shell and the terminal, as
their communication is supposed to run over a serial line, and it fact, they
do so (pty). So you miss the third line, which you need to tunnel, to be able
to display them in red, as you plan to.
Note further, that whenever a program is called, and that can happen
recursively, the "language" spoken on the line changes. You plan to interpret
it, but you have very few means to sort this out. Extra escape sequences
could be a mean, if the concept is consistent.
You cannot display the information as you want to in the konsole part, i.e.
with different font sizes, as the konsole's renderer does not do that and it
would break the character matrix conception each terminal has. It would need
a different concept of rendering and session, which is delicate, see below.
Though this is all possible, you'd better be clear about what you run into.
> Note that, in the application that I am planning, the shell is "outside"
> the konsole, and requests programs to be run inside the konsole.
I sense misconceptions of how a shell and a terminal interact both in your
mail and concept page. So following some more challenges, you'll likely face.
From your mockups and the screen layout, you consider a shell being a kind of
user front end to "exec". This is not the case.
An interactive shell does not execute one but many programs, either
a) redirection (e.g. grep bla * | less)
b) UNIX job control (e.g. jobs, fg, bg, &, ^Z, see bash manual page)
Further, a shell
c) has its own set of commands, e.g. 'set', which cannot be emulated.
d) maintains its own state, e.g. environment, it is not a stateless.
As you plan to have a separate input field, consider the following problems:
The shell passes signals to the processes ^C -> sigint, or otherwise processes
control characters like ^D, ^S, ^Q, ... (this is done via the device, really,
but has to be realized somehow when having an edit field for input only).
You might run in significant problems with programs that don't change to the
secondary screen, and the most important is the readline library often used
for command completion and history, e.g. ^R or TAB in the bash. You might
take much away from the effectiveness of the command line with having only a
one line edit field for command input, that is submitted to the shell when
typing return. What happens with "cat > a << etx", btw?
And when do you switch from raw to edited input? In fact, your input field
would have to be a kind of konsole widget possibly growing or shrinking.
The commands output is also not without problems:
X terminals have two different screen, a fact you might exploit to run "vi"
and other curses-based full screen applications. (This is why the old screen
image reappears after leaving "vi".)
Commands can come with colorful output like "ls --color" or with some kind of
ascii progress bars for instance, (e.g. wget, cdparanoia) which assume a fix
spaced font and a particular width of the terminal. libreadline does so too,
and makes up its own idea when wrapping occurs and what to do then.
You can hardly know how many "near fullscreen" features an particular
application on the primary screen might take. Some none (like cat), some
more, some all. You could attempt to define the primary screen with a kind of
reduced emulation, but this might be delicate.
Hope it helps.
More information about the konsole-devel