Re: Great SWT Program

On Nov 22, 1:46 am, Owen Jacobson <angrybald...@xxxxxxxxx> wrote:
Given that your computing needs are rather specialized and unusual,
your experiences cannot really provide much of a useful guideline for
the rest of the world in general.

And yet, there is a large enough community of computer users to
support the development of tools to support my needs, saving me from
having to write them myself.

"Large enough" being maybe the population of a small town, in a world
with over a billion people that routinely use computers.

If these numbers don't bother you and make you rethink your grandiose
claims about emacs and its ilk, then you must be some sort of an
elitist.

There is also a relatively large pool of users for whom the same
tools provide arguable benefit at best

If you call one billion minus a few thousand a "relatively large
pool". :)

for
any of a number of reasons. Even Big Vendors (Apple, Microsoft, Sun,
as well as less-known names like Be, before they got bought out), who
are only in it for the money, are improving, rather than eliminating,
support for text-mode tools and command lines.

Because there's a niche market for them. Companies that are only in it
for the money also make luxury cars that only a few thousand people
can even afford, big and expensive machinery that only a few thousand
businesses have any use for, and the like.

Also, I was never bashing noninteractive command-line tools for use in
scripts. I've bashed a) poorly-organized and lacking documentation for
same and b) interactive text-mode tools whose user-interfaces suck.
I've mentioned one interactive text-mode tool whose user interface was
fairly decent: MS-DOS Edit from the later DOS years. And they were
imitating some Borland product, or so I've heard. These had CUA
bindings and mouse support, and no kooky selection, backspace, undo,
or paste semantics either. Of course, a text-mode display is still
primitive and claustrophobic, but they were *usable*. The same cannot
be said for the kooky editors Bent and blmblm champion, *not even
graphical versions of same*.

So the "it sucks" dividing line is clearly not as straightforward as
text-mode vs. graphical, nor DOS/Windows vs. unix, although the things
that fall on the wrong side of it do *tend* to be either text-mode or
have text-mode ancestors/forks/relatives, and tend to be either unix
applications or ports of unix applications as well.

(The new version of OS X adds first-party support for SSH passphrases
in Keychain. I'm very pleased.)

Keychain being what, the password manager?

Ah, someone here (other than me) finally acknowledges that those
things have faults.

I don't think anyone here has claimed that emacs or vi or bash or any
other program is perfect and flawless.

I dunno about that; the hyperbole coming from Bent, at least, is
enough to inflate a whole fleet of zeppelins and mount a successful
invasion of Nicaragua. :P

I just dispute whether having faults I can understand and work with
(even if others apparently can't or won't) makes a tool worthless.

I consider serious faults such as "actively misleads the user in two
separate situations" to be showstoppers, myself. Even if in theory you
can learn to predict its behavior despite same, and thus to control it
despite same.

I also find your definition of "faults" to be pretty wildly divergent
from mine.

It's not my fault if your definition is wrong.

The only place perfect programs exist is in Discrete Mathematics
textbooks. All actual software sucks.

Some more than others.

The drugs you're on ... can I have some, please? Or at least be hooked
up with your supplier? :)

Absolutely.
<http://www.apple.ca/>

Hardly a pharmacist. Then again, they've done something funky with EM
brain manipulation, to judge by the rabid fanbois, unaccountable
popularity of the iPod (you know, the only handheld music player whose
batteries you can't replace), and infamous "reality distortion field"
about Steve Jobs (he must wear a portable emitter of whatever they've
come up with...and they've probably got one built into every Mac, if
not every iPod). No doubt it's the only way they could conceive of to
beat or even survive the monopolistic Microsoft juggernaut, with such
useful side effects as customer satisfaction, enabling a credible bid
for world domination sometime around 2012, and free viral marketing,
but still...:P

And this while Mac capabilities have tended to lag behind PCs. Speed;
the last desktop-computer maker to start actually supporting color
graphics; one-button mice...all while the machines have tended to be
more expensive. Until OSX they were also not amenable to home hacking
-- no free development tools included or easily found, unlike the case
with unixes (included) or Windows (easily found online). And yeah, no
command line, for those occasions where it's actually useful, mainly
because a graphical equivalent of something wasn't developed yet.

<http://www.macromates.com/>

?

-- My God, why are you connecting to one machine to then operate an
SVN client, check out some files, and edit them remotely, instead of
connecting to the repository directly from your local machine and
skipping the middleman?!

Frequently I have the same files checked out in both places. What of
it? Some tasks are easier or more natural to do in-place

What in the name of Moore are you talking about? You're not doing
something "in-place" if you're checking a source file out of a
repository and editing it; you may as well do the editing where there
isn't latency between you and the editor and the editor can proffer a
decent UI without running into bandwidth issues, i.e. on the machine
you're physically sitting at. There's simply no use for a middleman
machine when working on the contents of a source repository; just the
one you're at and the one housing the repository.

have you
ever tried to configure JBoss without editing things in place? It's
even more spectacularly unpleasant than the alternative.

I don't see any relevance to editing files in a source code
repository.

Did you have a point here? Thing being, the public Internet in a few
years will have the speeds and quality that I2 has now, although the
I2 at that time will also have advanced. The bandwidth to comfortably
run a Windows-style GUI remotely will be here in less than a decade
and probably no more than five years.

[implied insult deleted] it's much more likely that, by the
time bandwidth, latency, and reliability to the average remote node on
the internet are good enough that you can run a modern-as-of-2007 GUI
seamlessly over it, GUIs will have become even more bandwidth-
intensive.

How so? Even existing network connections could, with a protocol that
nobody's bothered to implement yet, support a decent GUI. (Said
protocol would not involve full-motion video at the full screen
resolution, but rather a description of the GUI to build locally
accompanied by a protocol for retrieving images from the far side plus
a video-stream protocol. The latter would only be needed when there
was full-motion video inside the UI, such as a movie playback or
something. With suitable client-side caching, of the descriptions and
images, especially precaching of those needed for dialog boxes and
other things that might be invoked at any moment by the user, this
would not need very much bandwidth at all. Think of it as separating
an existing program's GUI from its engine and putting the GUI on a
different machine, turning the interlayer communication within the
original program into a wire protocol. It's not, but the bandwidth
requirements are the same.

Between two Windows machines, it would look something like this:
* Remote machine has graphical app running that tells the Windows
widgets API to display a button labeled "foo" at these coordinates.
Normally it would just do this; instead it sends a message over the
network to the client to display a button labeled "foo" at those
coordinates.
* Client does so.
* User clicks button.
* Client sends a message that the "foo" button got clicked.
* Remote machine server software passes this message on to the
application, which sees a button click as if there was normal user
interaction.

The two biggest bandwidth consumers I foresee in such a scheme are a)
sending images and particularly video in the cases where it's really
necessary, of which the biggest in most cases will be the splash
screen graphic at startup, which can safely be omitted, and b) sending
a steady stream of mouse coordinates up to the server when the
software has mouse motion listeners registered. Most drag and drop
behavior won't require this, only a description of whether each
visible object should respond to a drop and what mouse pointer graphic
to use when hovering with a droppable item over each.

If some existing remote desktop protocols do work this way instead of
simply transmitting sixty screenshots of the remote session a second
one way and all keyboard and mouse activity the other way, and
nonetheless run into bandwidth problems on typical DSL/cable
broadband, then they must be implemented very badly. As evidenced by
Web sites displaying GUIs based on forms and AJAX that are quite
responsive over broadband and even somewhat usable over dial-up, which
prove that remote GUI presentation can be done with a) no specialized
clients (just a Javascript-supporting browser, without Java or Flash)
and b) no bandwidth problems on today's internet.

Lastly, I doubt that GUIs will become "more bandwidth intensive" (not
that they are intrinsically bandwidth-intensive *now*) unless
arbitrary full-motion video in the UI becomes commonplace in
application design or some sort of massive navigated 3D spaces type of
UI takes over, which is more of a movie cliche than an especially
likely real-world interface design.

Then the likely result is what one already observes with Web sites
that use Flash or Java: slow loading, but a responsive interface once
loaded, given the logical implementation in the form of applets JIT-
delivered to the client side. Flash games that require twitch reflexes
are playable on dial-up; never wondered why?

Certainly they seem to be heading that way now, with
marketing wonks and salescreatures in charge of adding pretty-but-
useless features like reflective widgets (that drive up the entropy of
the widget's graphics and make it hard to compress)

This presupposes a naive implementation in transmitting sixty
screenshots a second, unless you just mean the widget graphics.

and application-
controlled skins (that eschew standardized control drawing and make it
impossible to delegate rendering to the nearer-to-the-user peer) to
GUI programs.

You can delegate rendering if you just make applications have to
provide a suitable description of the controls to the OS, regardless,
and the remote presentation then just has the system lative L&F
instead of whatever customized drawing the remote end used.
Application designers could mark some custom-drawn controls as crucial
to preserve as is, and their graphics would be transmitted (and, if
static, transmitted once and then cached client-side). This would be
needed on e.g. drawing canvases and for various types of games (but
games, even multiplayer ones, are better off designed with a
specialized local client anyway).

The ultimate direction, though, is probably to put all of the
application logic client-side and extend the idea of source code
repositories to a remote version-controlling filesystem in general, or
even a distributed one. This even supports remote admin, in that
ultimately one needs to modify system files on the adminned machine
whose contents determine its state vis-a-vis user accounts and things
like that; the files simply need to participate in the remote FS, and
the remote FS needs to have a notion of permissions and an
authentication infrastructure, preferably based on public key
cryptography on a challenge-response model; when you ran something
that tried to read /etc/passwd (which, while world-readable on the
remote machine, would not in this FS have the additional "remotely
visible to everyone" flag; there'd be a separate set of rwxrwx
permissions for remote access that could be set stricter) the server
would challenge the client for root authorization; again when your
something tried to save changes to the file. The challenge/response
cycles would happen transparently unless you had not yet authenticated
yourself for the required permissions, in which case you'd get a modal
popup asking for your private key or whatever. (This would be cached
for the session. If you owned the local hardware you were using you
could have it keep a permanent record. Same as password managers
nowadays do, and login cookies, and the like, only secure against
packet sniffing.) Of course if you hit cancel or used the wrong key
the operation would fail, and the server could log and/or temporarily
blackhole IPs generating too many consecutive botched attempts at
authentication (hitting cancel would not count here), not that brute-
forcing a 128-bit private key wouldn't take ages anyway.

And even if bandwidth does eventually catch up to GUIs, you can't go
faster than the speed of light: the fastest a remote interface can
possibly respond when you're sitting halfway around the world from the
computer the program is running on is around 120ms.

This latency will be a potential problem for any interactive UI
presented from a distance, but less so the more the UI's detailed
behavior is delegated to the client end. Which means a text UI
transmitting an 80x24 grid of characters 60 times a second one way and
all of your typing the other is going to suffer far more than a GUI
much of whose behavior is running at the client end.

A simple comparison: a text mode or a graphical app, with a non-naive
implementation for the latter; the user performs a search.

Text mode: user hits search key, waits a bit, hits first letter of
query, waits a bit, hits second letter of query, waits a bit...

GUI: user hits search key, waits a bit, and types entire query rapidly
into a text input field, then hits enter. The whole query is now sent
over the wire in one shot, and after a short delay the user sees the
first search result.

The GUI comes out ahead, unless the text-mode user types ahead of
what's being echoed back, in which case they're typing blind and if
they make a typo they have to go back to correct the GUI again comes
out ahead. Especially when one considers that it's easy to backspace
precisely back to the error quickly with the locally-provided text
input field and not so easy when the backspace feedback lags 120ms
behind your input! You're likely to overshoot when backspacing to an
error and have to retype more than strictly necessary with the remote,
latency-afflicted text-mode UI than with the remote, latency-afflicted
GUI. Overshooting with left-arrow means a few extra left-arrows plus
as many right-arrows to correct, likewise.

Ultimately, this is the result of the same thing I've kept complaining
about: the lack of regularity in text-mode UIs makes it impossible to
do the same kind of delegation of UI-presentation details to the
client side. With a GUI this is easy, and any field with no or a
standardized type of on-the-fly validation logic can be filled
entirely client-side without per-character round trips to the server
being at all required.

When you're
typing, a steady, reliable tenth-of-a-second lag is annoying, but not
distressingly so. When you're waiting for a control to be redrawn or
for a menu to open, a tenth of a second is very jarring and
unpleasant.

Ridiculous. When you're typing, lag means you type blind or you type
slow. When you're waiting for a control to be redrawn or for a menu to
open, it means that not enough was delegated to the client side; in
the former case, roll-over graphics or other such behavior should be
delegated, and likewise when a window is described to the client this
should include the menu items, so only selecting an actual menu item
should necessitate a round trip to the server; you'll click File and
see an immediate result, click Open and then get a slight delay, then
see a file chooser with the remote machine's filesystem visible
within. Expanding subdirectories and actually submitting the dialog
would be the only things that would incur the latency here (the former
because sending a listing of the whole filesystem instead of one
directory at a time on-demand would obviously be slow even on a
megabit-class connection, so each little + expanded or directory
opened necessitates a trip to the server).

Try it yourself sometime: borrow Raymond Chen's example
program or one of the .net samples and add a 60ms sleep at the start
and another at the end of all the UI event handlers.

This isn't going to simulate the latency profile of a well-designed
remote GUI protocol. See above.

Or just consider the kinds of GUIs already being remotely presented to
a general-purpose client in the form of forms+AJAX Web sites. For all
its flaws this includes Google Groups, and I don't notice any latency
issues editing the form I'm typing this post into.
.