Discussion:
UI
(too old to reply)
Ivan Shmakov
2013-02-03 12:09:54 UTC
Permalink
[Cross-posting to news:comp.unix.misc, for there weren't a good
thread in a long time. Somehow, I also feel that it may be
appropriate to eventually drop news:alt.folklore.computers from
Newsgroups: should this thread progress further.]

[...]
One more point is that one can "copypaste" a span of text from
anywhere on the text VT screen, and not just from the widgets that
are chosen to allow for such by the programmer. (Check, e. g., a
random X application's "About" widget: rarely it will allow you to
copy its contents into another program all that easily.)
X allows copying by marking with the left mouse button and pasting
with the middle one - mostly anyway!
No, it doesn't, unless by "mostly" you mean "when explicitly
coded to allow so by the programmer."

For an example: start Firefox, choose "Help", then "About ..."
Here, try to copy the text inside this widget.

Or, there's an even better example: while choosing "Help", try
to copy the contents of the menu itself.

(As for the sensibility of the task, consider that I'm writing a
Firefox manual, or a similar document.)

Anyway, in X, the contents of any window is -- first and
foremost -- a bitmap image. Whether or not there's a "backing
text" for such an image is left solely to the application
programmer's discretion.

(I guess that NeWS was to be different in that respect.)
I went to the trouble of building a modern text-only unix box, Linux
kernel 3.7.5 etc. and it's very useable, does everything except
graphics - including playing music.
Same here. I don't recall any particular trouble, however.
(JFTR: I'm using Debian GNU/Linux "Squeeze" 6.0. Usually, I'd
set one up via a direct debootstrap(8) invocation, not from the
Debian Installer "shell", as I've recently described in [1].)

[1] news:***@violet.siamics.net (part 1) news:***@violet.siamics.net (part 2)
(in Russian, though.)
It has a trackball which allows me to copy/paste text from any login
screen to another.
Alternatively, you could use GNU Screen for keyboard-based
"copypasting." Thanks to the support for incremental search,
copying "all the text from here and back to the previous command
prompt" (for example) is especially convenient.
(Just getting to grips with LaTeX, too. Produces nice output...)
Indeed. Though, as everything else, LaTeX has its deficiencies.
(AIUI, some of them were recently discussed in
news:comp.text.tex.)

Unfortunately, given the sheer amount of extensions coded in "Ye
Good Olde TeX," there's a little chance that the underlying
language itself will ever improve significantly, which is a
prerequisite of addressing some of the existing issues.
And then, there's GNU Screen...
I prefer multiple terminal sessions 'cos screen only seems to give
you VT-style terminals and I need colour and run an odd screen size -
128x52 - as I can't find a 132 column font that's readable on my lcd
monitor :-(
While there may be minor issues with colors under GNU Screen
(why, under X, I'd typically use a monochrome, Navy Blue on
White UXTerm, -- I don't deem colors to be all that important),
I have never faced a problem with arbitrary terminal sizes.

For instance, the single Screen session I'm typing this text
within is attached to both an 80 x 31 UXTerm, /and/ a 80 x 27
Linux VT -- at the same time. And, as soon as I'd opt to, I can
detach it from either (or both) of them, and re-attach to any
other terminal I'd need to. (It's especially useful given that
I now use four separate machines at home, and keep SSH'ing
between them all the time.)

Then, there's a "screen locking" feature, which lets you lock
the terminal (the Screen session is attached to), yet retain all
the running applications.

After all these years, I'd dub all these features "essential."
--
FSF associate member #7257
Peter Flass
2013-02-03 14:01:18 UTC
Permalink
Post by Ivan Shmakov
X allows copying by marking with the left mouse button and pasting
with the middle one - mostly anyway!
No, it doesn't, unless by "mostly" you mean "when explicitly
coded to allow so by the programmer."
For an example: start Firefox, choose "Help", then "About ..."
Here, try to copy the text inside this widget.
This is a pet peeve of mine. The GUI paradigm should operate uniformly.
Any text that's displayed on the screen should be capable of being
copied and pasted. 'Doze has the same problem. I can understand
applications like Acrobat, where sometimes an image is being displayed
rather than text, but *help text*?
--
Pete
Aaron W. Hsu
2013-02-03 18:35:49 UTC
Permalink
Post by Peter Flass
The GUI paradigm should operate uniformly.
Any text that's displayed on the screen should be capable of being
copied and pasted. 'Doze has the same problem. I can understand
applications like Acrobat, where sometimes an image is being displayed
rather than text, but *help text*?
Just to throw this in there, the Acme environment in Plan9 follows this
pattern, where text is a universal means of interacting with the system. All
the text is selectable and can be used to drive commands.
--
Aaron W. Hsu | ***@sacrideo.us | http://www.sacrideo.us
לֵ֤ב חֲכָמִים֙ בְּבֵ֣ית אֵ֔בֶל וְלֵ֥ב כְּסִילִ֖ים בְּבֵ֥ית שִׂמְחָֽה׃
Ivan Shmakov
2013-02-04 10:18:24 UTC
Permalink
Post by Peter Flass
X allows copying by marking with the left mouse button and pasting
with the middle one - mostly anyway!
No, it doesn't, unless by "mostly" you mean "when explicitly coded
to allow so by the programmer."
For an example: start Firefox, choose "Help", then "About ..."
Here, try to copy the text inside this widget.
This is a pet peeve of mine. The GUI paradigm should operate
uniformly.
And it does. As long as XTerm is virtually the only X
application used. (But even then, XTerm's own menus aren't
"copyable...")
Post by Peter Flass
Any text that's displayed on the screen should be capable of being
copied and pasted.
I wonder if there's any "GUI toolkit" that allows for easy
development of such "copy any text" (and then, "search any
text", too) applications.

So far, I'm yet to try PDCurses. And also Emacs' own engine.
Post by Peter Flass
'Doze has the same problem.
Yes.
Post by Peter Flass
I can understand applications like Acrobat, where sometimes an image
is being displayed rather than text,
Well, there're also HTML pages like that, not to mention the
raster images by themselves...
Post by Peter Flass
but *help text*?
--
FSF associate member #7257
Ivan Shmakov
2013-02-04 09:49:18 UTC
Permalink
[It seems that this discussion is no longer relevant to either
AFC or X. Hence trying to move it to news:comp.unix.misc,
though I'm open for other suggestions.]
However still no colour in elinks under screen - probably the reason
I abandoned screen originally - I forget, the old brain gets tired
these days :-( Must be an elinks bug, it wouldn't do colour on my
Sun box either.
You might also want to investigate 'tmux', which some claim is more
http://tmux.sourceforge.net/
You can find lots of comparisons if you do a search like "screen vs
tmux".
Well, as per the resource which came first in the Web search:

--cut: https://www.wikivs.com/wiki/Screen_vs_tmux --
The following features are specific to tmux and not shared by
GNU Screen.

Vertical splitting

GNU screen has it only as a patch and has not been added to an
official source code.
--cut: https://www.wikivs.com/wiki/Screen_vs_tmux --

Still, the Debian version [1] of Screen has this patch applied.

[1] http://packages.debian.org/wheezy/screen

--cut: https://www.wikivs.com/wiki/Screen_vs_tmux --
Client/Server System

When the first tmux session is created (equivalent to screen -d
-m), a server instance is started automatically, and the session
runs as a client for that server. Further sessions operate as
clients, connecting to the same server instance (equivalent to
screen -x). [...]
--cut: https://www.wikivs.com/wiki/Screen_vs_tmux --

I don't understand this one. Given that this feature is
"equivalent to" certain Screen commands, how this can be taken
for "this feature is specific to tmux and not shared by
GNU Screen?"

--cut: https://www.wikivs.com/wiki/Screen_vs_tmux --
Synchronize-panes

tmux can duplicate input to any pane to all other panes in the
same window (not available for panes in special mode e. g.
copy-mode). [...]
--cut: https://www.wikivs.com/wiki/Screen_vs_tmux --

Indeed.

--cut: https://www.wikivs.com/wiki/Screen_vs_tmux --
The following features are specific to GNU Screen and not shared by
tmux.

[...]

attaching to a serial tty

In GNU Screen, you can connect to a serial device (screen -r
/dev/ttyS0 115200.) Tmux does not support this feature.
--cut: https://www.wikivs.com/wiki/Screen_vs_tmux --

I wonder if this also means that tmux cannot connect to a pseudo
terminal (pty)? I make occasional use of this feature, as I'm
both interested in "virtualized environments" (as in: KVM, QEMU,
UML, etc.), and in "embedded" software development (as in:
interfacing AVR 8-bit MCU's.) As it seems, this one makes tmux
a no-go for me.
--
FSF associate member #7257
Aaron W. Hsu
2013-02-04 16:49:19 UTC
Permalink
Post by Ivan Shmakov
I wonder if this also means that tmux cannot connect to a pseudo
terminal (pty)? I make occasional use of this feature, as I'm
both interested in "virtualized environments" (as in: KVM, QEMU,
interfacing AVR 8-bit MCU's.) As it seems, this one makes tmux
a no-go for me.
I have also heard that tmux in the wild is a little different than the tmux
in OpenBSD. I am not sure about that, but I know that OpenBSD packages tmux
by default as their preferred system, and I seem to recall a lot of bug
fixes and features adjustments in their branch. Whether those made it
upstream or not I do not know.
--
Aaron W. Hsu | ***@sacrideo.us | http://www.sacrideo.us
לֵ֤ב חֲכָמִים֙ בְּבֵ֣ית אֵ֔בֶל וְלֵ֥ב כְּסִילִ֖ים בְּבֵ֥ית שִׂמְחָֽה׃
Continue reading on narkive:
Loading...