[Konsole-devel] Bare bones Konsole

[Harshad RJ]

Thanks Lars, for the detailed response!

On Saturday 03 Dec 2005 1:39 pm, lars.doelle at on-line.de wrote:
> > 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. 

I am using the TerminalInterface (kde_terminal_interface.h) which declares a 
function called startProgram (QString, QStringList). According to the 
description, this function should start a given program in the KPart.

Is this a deprecated function, or have I misunderstood it? Or is there a bug, 
and should I file a bug report?

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

These are round-about ways of running a program. The first one has an unwanted 
side-effect of changing the environment of the executed program, while the 
second one starts an entire new (login?) shell.

Also, as you point out, there are security issues with the second option.

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

Well, Anthias was initially concieved as an extended shell (a rather grandiose 
plan, perhaps), which would provide to the user all the typical functions of 
a shell, while providing a separate terminal interface to every executed 
program. I have visualised the GUI part here:
http://anthias.sourceforge.net/design.png

[If this discussion is off-topic for Konsole, we can continue it on Anthias' 
forums.]

Every program gets a Cell widget, and every Cell widget, has
1. A Title Widget
2. A Progress bar Widget
3. A Status Widget
4. A Terminal Widget

The progress bar that you see for the unsermake command, for example, can be 
achieved by modifying 'unsermake' to detect an Anthias Terminal, and emitting 
a special escape sequence to update the progress bar widget.

Note that, the terminal widget will never have proportional fonts. So, the 
Konsole KPart is an ideal candidate for this widget.

However, I am considering alternate ideas. I have been interacting with Fish 
developers [http://roo.no-ip.org/fish/], to come up with an alternate plan. 
The GUI will be similar. But in this scenario, Anthias is only an extended 
terminal and provides services to the user's shell and other applications. 
The shell or  applications can use ANSI-term escape sequences as well as an 
Anthias defined protocol to access additional functions of the Anthias 
Terminal. This is more modular in its approach since Anthias will be a 
dumb-terminal, and leave the intelligence to the user's shell.

See this page:
http://anthias.sourceforge.net/PlanB.html
for details. 


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

Err, I have reservations against different fonts or proportional fonts in the 
the terminal session. I think it would decrease the usability rather than 
boost it.

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

If I understand you correctly, this is exactly one of the alternatives we are 
considering in Plan B; having a dedicated channel of communication between 
the Anthias Terminal and any interested program running inside the Terminal.

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

Colorful stderr is not a must-have, but a nice-to-have. Anyway, I think it can 
achieved by having an io-manager which takes any output on stderr and formats 
it with escape sequences, and outputs to stdout. I have been using such a 
program for a while now:
http://sourceforge.net/projects/hilite

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

I didn't understand the changing 'language' concept. Can you please elaborate?

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

To reiterate, no proportional fonts in the terminal widget are planned.

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

Well, I am new to this domain, and I am quite sure I may have projected a 
wrong-picture somewhere. Hope this mail clarifies.

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

I agree with you there. If Anthias does get developed into a shell, it won't 
be an 'exec' frontend for sure.

> 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?

The input-field used in the mockup, is a QLineEdit. If Anthias implements a 
shell, it would be some kind of multi-line edit, with syntax higlighting, 
command completion, history search, the works.

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

Well, I don't know how exactly the Konsole KPart manages the screen size. I am 
hoping for a size-policy (now or future) along these lines:

1. A maximum width and a maximum height are defined.

2. The KPart always expands to occupy the max width. Any text that spills over 
is wrapped, or a horizontal scroll-bar is displayed, according to the 
wrap-policy.

3. The KPart starts off with a height of one line of text. As text grows, the 
kpart grows vertically to accomodate the text. When it reaches max_height, it 
opens a vertical scroll bar.

>
> Hope it helps.

Thanks again,
-- 
Harshad