Re: Terminal - a good terminal?
Eduard Bloch wrote:
>
> #include <hallo.h>
> * Jeff Teunissen [Thu, Oct 07 2004, 02:20:31AM]:
>
> > > If we are going to allow generic names, then obviously they would be
> > > applied to the most commonly used or "best for the novice" example,
> > > so I'm pretty sure that GNUstep apps aren't going to get them.
> >
> > On one of those counts, many GNUstep-using apps often win over their
> > "competition". e.g. Terminal is a _very_ nice terminal emulator with
> > excellent compatibility (it does UTF-8 well, and emulates the Linux
> > console
>
> Who said that the "linux" console is a good kind of terminal emulation?
It's what's expected. We could do just about any other type, including
graphics terminals, but TERM=linux is decent and simple.
> > very well) and many features that are not found elsewhere.
>
> Such as? Let's compare. It may be look nice, but is it really good for
> daily use?. I just tried version 0.9.4-2.2 and have "mixed feelings" (to
> avoid a bad word) after comparing to rxvt-unicode.
>
> meta-keys in UTF-8 mode? Only after manual configuration.
Not true -- OpenStep has an extra modifier key.
Command is bound to the Alt_L keysym by default in gnustep-gui.
Alternate is by default bound to Alt_R. A different program lets you easily
set which keysyms get bound to the various modifiers.
Alternate always does "meta". Command usually is grabbed for key equivalents
in the menus. The option to set Command as meta overrides this. The option
was created because on some configurations the right Alt key changed its
keysym to ISO_Level3_Shift or some other such nonsense.
On my 104-key I have two Alts and two Commands, so it's all good.
> Manpage? None (or not easy to find).
Correct. There's no point.
> Command line options? No idea, either none or the program reacts insane.
Only the standard *step ones, like -NSOpen, are "seen" (others get added to
the defaults system temporarily). As I said, I'll be writing an
optionally-blocking xterm-like client interface for it to expose its
features to the command-line.
> UTF-8 support? Lousy or none. One has to choose it manually (and it
> supports only few encoding anyways).
It can support more by just adding a couple of lines to the popup button;
GNUstep does all of its string handling in UTF-16 internally.
> And failed to display any glyphs from the known UTF-8-demo.txt except of
> those from charsets in the menu.
> Not even the threading in mutt is displayed properly.
Nothing to do with Terminal. The font you were using didn't have the glyphs
Terminal was trying to display, so it had to use the "no glyph" glyph, which
I see occasionally too.
The ART backend graphics target's glyph generator doesn't currently do glyph
combining or font substitution, though the latter is apparently in progress.
·
> Choosing the "Handle widht-chars" option has broken the output
> completely.
Works here, what backend and font were you using?
> Automatic guessing of the charset (on-the-fly)? No.
> Self-configuration by locale settings? No.
>
> Speed? Lousy. From time to time feels slow like hell, even compared to
> the gnome-terminal. No way to choose core X fonts instead of XFT.
> Measure performance ("locate bmp", not precise): 2 times slower than
> Gnome-Terminal, 8 times slower than Konsole or Urxvt(w. XFT), about 20
> times slower than urxvt (core fonts, UTF-8 mode).
Speed is a fair criticism, but it can't get a whole lot faster because of
the display model -- getting closer to X basically isn't an option, but it's
a fair tradeoff because of the other things we can do with it.
> Bold/Bright fonts? No. There is a selection for the Bold font but seems
> to be broken.
It's not, unless the version of Terminal in Debian is ancient. You can
choose any arbitrary fonts for either the regular or the "bold" font. It's
recommended that the chosen bold font be about the same size as the regular
one though, because it will be clipped to either a normal or wide character
cell.
> Italic font support? No.
For what? There isn't an italic display command. Though I suppose we could
overload the blink bit to set italic, it hardly seems proper.
> Customisable color palette? No.
Maybe later. The colors match pretty closely with the console.
> Extra features (transparency, background image, etc.) - no.
The former can't be done (no way to read the contents of the root window,
and X doesn't support proper alpha control ATM so that's a wash -- though
the GNUstep composition system certainly supports it). The latter could be
done trivially, but why?
> Memory usage? Terrific. 30MiB to be loaded - get one a simple terminal
> window! Compare with rxvt-unicode: 7MiB (2MiB RSS), 1MiB more in XFT
> mode.
> The good part: ~800kb per new window (urxvtd takes ~600kb), that's fair
The memory use for Terminal itself is much lower than that. Most of it is
shlibs and overhead that needs to be addressed in the class libraries
(GNUstep).
> Configurable by xresources or similar mechanism? No (apparently).
Not possible. Keep in mind that it's not an X program, it just happens to
work on X with a suitable backend bundle loaded.
> Changing settings on-the-fly? No.
I've wanted to set that up, but it hasn't been important enough yet.
> So there are not many nice things about this "Terminal". The only one I
> can see is the *step integration but it is a matter of taste.
Actually, it's more a matter of interface. Terminal services can be really
powerful (like adding a "run shell command" menu item to every application,
or a command to run the selected text through a filter and replace it with
the result), but there needs to be a way to access them. Right now the only
way to do that is through the pasteboard, but that's fixable.
> And I have to say the same thing as before - calling this package
> "terminal" is unfair, it will attract the attention of newbies to a
> program that is below average, feature and performancewise.
> "gnustep-terminal" would be much more appropriate - it is a Terminal for
> real GNUstep fans.
It's one of the few packages that hasn't been updated to the naming
compromise, it seems. It should be called "terminal.app".
--
| Jeff Teunissen -=- Pres., Dusk To Dawn Computing -=- deek @ d2dc.net
| GPG: 1024D/9840105A 7102 808A 7733 C2F3 097B 161B 9222 DAB8 9840 105A
| Core developer, The QuakeForge Project http://www.quakeforge.net/
| Specializing in Debian GNU/Linux http://www.d2dc.net/~deek/
Reply to: