[Konsole-devel] Bare bones Konsole

[lars.doelle at on-line.de]

Harshad,

> I am the author of Anthias (http://anthias.sf.net).

You might find a related attempt of interest:
http://xmlterm.sourceforge.net/screenshots.html


> 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 
by
    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.

-lars