Semantics of text virtual console vs. xterm
- From: phil-news-nospam@xxxxxxxx
- Date: 24 Feb 2008 01:26:25 GMT
I use both X Windows as well as the text virtual console. I have used the
latter in the past because computers were simply not fast enough to keep up
as well as text mode could, when doing things like rapid scrolling in large
geometries (like 128x72 characters). Maybe now computers are fast enough.
In xterm, the scrolling is still not as fast as in text mode, but at least
now the differences are so dimished as to not matter. Scrolling in xterm
today is certainly faster than scrolling in text mode was a few years ago.
So I am looking at what I need to do to migrate from being a regular user
of the text mode virtual console, to using some kind of terminal emulation
program under X most effectively. But, as it turns out, speed is not the
only issue. Speed was merely the most insurmountable issue of the past.
The remaining issues, I believe, can be addressed. The problem is, I do
not think I am the one best able to address them. In theory, I could do a
lot of reading of manuals, documentation, and source code, and figure out
what to do to change things to work as I need to have them work for most
effective usage. But I just do not have the time to do that in the near
time frame. Maybe in 2 or 3 years? My hope is someone else has already
recognized the issues and found solutions or figure out changes, or at the
very least, determine what and where to change. If I knew _where_ to do
the changes, maybe that would be enough (I can write code).
The first issue is fonts. This one should be fairly simple since there are
a choice of fonts. I've just found that they are in weird formats, and not
even all in the same format. A document that would tell me how to put my
own font designs into a file, and where to put that file, so it can be used
by xterm or other terminal programs, would be the key to moving forward.
The second issue is mouse mechanics. This one looks to be more troubling.
In text mode, the mouse position at any moment is clear and unambiguous.
This is because it uses a full block inversion over the character cell to
show the mouse position. In X with xterm (and other applications), that
position is uncertain. The mouse symbol over text is the "I bar". There
are multiple pixel level positions the mouse can be moved to. But not all
of them behave as the mouse being over the character that the "I bar" will
appear to be over. For example, when highlighting text, unless you move
the mouse sufficiently far enough to the LEFT SIDE of the first character
to be highlighted, it will miss that character and start highlighting on
the character to the right. The same issue in reverse exists at the ending
character. I need to get this fixed. If the cause of this is in the code
of the application, or in a library it uses, maybe it is fixable in the
application. I have seen some applications that change mouse behaviour
around, so there is hope. But I'm not about to go trying to figure out the
parts of those applications that change mouse behaviour apart from all the
other stuff those applications do (writing code is easy ... reading other
people's code is hard).
Another aspect of the mouse issue is when doing things like double clicking
and triple clicking, just what gets highlighted is different. Highlighting
a word by double clicking highlights a full file path in text mode, but not
in xterm. That appears to be an issue of what characters are allowed to
stop the span of the highlight. Changing that, once it is found where they
are, should, I would think, be simple. But I haven't found where (I have
only looked in the xterm source code).
The third issue is to find a way to rapidly switch between different screens
of text. In text mode, the traditional virtual console involves Alt+FX,
where FX is one of the "F" function keys on the top row of the keyboard.
I have, through keyboard mapping, expanded that to so that Alt+X, where X
is either one of the function keys or one of just about any other key on
the main part of the keyboard (including space and ESC). I have 63 such
mappings to virtual consoles, and use them all. Alt+F10, Alt+F11, and
Alt+F12 are each going to X Windows (I run three instances of X at the
same time). The rest go to one of 60 different virtual consoles, all of
which are logged in and used. When I press Alt+X the switch is very rapid.
Some people have suggested using screen, but it is awkward to use for this
kind of rapid switching (I sometimes switch back and forth a few times a
second). I would thus want to have some kind of means to do such rapid
keyboard based switching while in X. That would not be switching between
the different instances of X (that's way too slow, anyway). It could be
switching between different windows of xterm, or subwindows within xterm,
or different virtual desktops within the same instance of X. Whichever is
the fastest is the way to go. But how to set that up? Maybe it needs a
new window manager? Or is one already available that can do that.
Non-specific advice won't be helpful. Does anyone have any specific advice?
--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2008-02-23-1858@xxxxxxxx |
|------------------------------------/-------------------------------------|
.
- Follow-Ups:
- Re: Semantics of text virtual console vs. xterm
- From: Bill Marcum
- Re: Semantics of text virtual console vs. xterm
- From: Floyd L. Davidson
- Re: Semantics of text virtual console vs. xterm
- Prev by Date: Problem with X11 window size resource.
- Next by Date: Re: Semantics of text virtual console vs. xterm
- Previous by thread: Problem with X11 window size resource.
- Next by thread: Re: Semantics of text virtual console vs. xterm
- Index(es):
Relevant Pages
|
