#include <hallo.h>
* Jeff Teunissen [Thu, Oct 07 2004, 09:10:56AM]:
> > > 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.
By whom?
> We could do just about any other type, including graphics terminals,
> but TERM=linux is decent and simple.
And primitive. And unuseable or not so comfortable when opening a shell
on non-Linux system.
> > 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.
I do not know which nonsence you mean but I do not have something
special, just default Debian GNU/Linux environment and there it did not
work. I had to set this switch.
> > 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
It does not print anything useful when executed with -h or --help. It
just ignores these options, that is not a very userfriendly behaviour,
IMHO.
> 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.
Okay.
> > 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.
Add more? It does not support UTF-8 well.
> > 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.
Yeah. And a sane Unicode compatible terminal would try fallback to
similar fonts. That is what Rxvt-Unicode or Gnome-Terminal do. Of course
you can use the "missing in this font" excuse, but then you should made
at least the font selector work. Currently, I see only four fonts there,
and the selecting another one is either not stored, or has no effect.
> The ART backend graphics target's glyph generator doesn't currently do glyph
> combining or font substitution, though the latter is apparently in progress.
Then please don't call it UTF-8 capable before it really supports most
of it.
> > Choosing the "Handle widht-chars" option has broken the output
> > completely.
>
> Works here, what backend and font were you using?
What is a "backend"? I just assumed what other people said and started
it with defaults.
> > 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
0.9.4-2.2 - may be old, but then blame the maintainer. Or maybe there is
nobody who cares about the package.
> > 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.
Some applications (vim) support it with proper terminfo entry (not
"linux").
Regards,
Eduard.
--
<Joey> Ok, da steckt auch nicht mehr Arbeit fuer mich hinter?
Dann bin ich's doch.
