Re: Great SWT Program
- From: bbound@xxxxxxxxx
- Date: Sun, 16 Dec 2007 05:51:36 -0800 (PST)
On Dec 14, 9:44 am, blm...@xxxxxxxxxxxxx <blm...@xxxxxxxxxxxxx> wrote:
Hmm .... I started to write "yes indeed", because it's certainly
the case that I'm more apt to be annoyed when a GUI application
behaves in a way I find limiting, while I'm more forgiving
about the shortcomings of my old-friend text-mode applications.
Aha! Bias!
Also, sometimes when you find a GUI limiting it's because you're
trying to do X by doing Y, where Y is the crufty and inefficient only
way to do X in the text-mode apps but the GUI lets you do X much more
smoothly and efficiently by doing Z, which isn't even possible in text-
mode (or would be even nastier than Y if you managed to implement it
in text mode, whereas Y is nastier in a proper UI). So you try to do Y
in the GUI and it's either even clunkier and more awkward than you're
used to or it simply isn't possible, while overlooking Z.
people don't go looking for features they don't know about or
imagine existing.
Indeed; see above. At least with GUIs when they *do* go looking they
can actually *find* it in a nice way.
GUIs might make it a little easier to explore
all available features, in that one can do so by poking around in
menus rather than reading documentation, but I wonder how many
people actually do that.
I certainly do, at least if I'm specifically looking for a way to do
something in particular or speed something repetitive up. Search the
docs, too, if the docs are nicely browseable and searchable, something
that's common with GUIs and unheard-of with text-mode unix stuff. Docs
are sometimes not very comprehensive or detailed though. Then again,
skimpy docs you can actually find and navigate nicely within beat the
hell out of extensive docs with no apparent navigation other than page
down x60,000 or extensive docs you can't even find to access.
BOTH sides could use docs with more "how to get started" and "how to
do X" oriented sections in addition to the usual reference-style
material.
I tried to automate some image manipulation task in Photoshop and
couldn't find decent docs on the VBScript in there, nor any simpler
macro-recorder type functionality. There was a fat reference manual in
the online help for the VBScript but no overview/getting started stuff
that I could find, so it was unusable. A list of available function
calls is not enough; it would have been like trying to learn Java from
just the API docs, with no Java tutorial, no explanation of the
keywords or syntax of the language, no information about the compiler,
etc.; and this despite my having some experience with three or four
older BASICs at that. Particularly, since it was an embedded
environment, I'd have needed information on how to make a function to
do some particular thing and how to bind it so I could invoke it with
particular arguments. I wound up locating and downloading a separate
tool to do the batch image manipulations in question.
I'm not sure it would have occurred to me that a tool would be able
to generate "import" statements semi-automatically if someone hadn't
mentioned it -- obvious enough that it's possible once it's been
mentioned, but ....
This kind of thing commonly accompanies a jump to a new genre of
application (e.g. IDEs). It doesn't help if there's not much
"overview" doc material, nor a tutorial. But browsing the menus and
right-clicking in various places and the like can reveal a great deal.
I don't think it's so much a matter of having lots of features,
but of having features that are, well, expert-friendly.
Sorry, circular definition error.
(what I remember is difficulties in figuring out how to have a
library of macros to be shared among documents, though that may
be a problem that's easy to solve if you know how), and there are,
as I understand it, some security-risk implications.
You put them in normal.dot, or use your own .dot when creating the
documents you want to use the libary in, and have the macros in that
dot.
The security risk implications are going to arise wherever there's a
highly programmable macro facility. The main problem is that they
architected Word to store macros into documents, instead of load them
from the dot template but put only a reference to this in the document
(and the macros become unavailable if the document is used on an
install that lacks the template in question, or where it exists but
lacks the macros). This allows documents to carry macros from machine
to machine, enabling viral behavior. The sole reason the security risk
is less with say elisp is that emacs-created .txt files don't contain
elisp macros.
I wonder if Microsoft has already redesigned Word to not transport
macros in documents, but instead reference files containing them from
documents and degrade gracefully when the macros are missing as
described above.
* Support for external automation. AFAICT, both vi and emacs lack
this; scripting text manipulation tends to be done with sed instead.
I can't speak for real vi or emacs, but vim can be run in a sort
of batch mode in which it's controlled by an external script.
How wacky. Screen-oriented interactive programs will however make poor
automation fodder. For starters they'll clobber any previous output
from a running script when they start up and overwrite the whole
display. Second, they are heavyweight compared to things like sed,
which I'm given to understand was specificlaly made to do text
manipulation from inside scripts. Right tool for the job and all that.
For one-off jobs it usually seems easier to use vim's
macro-recording-and-replay features. (emacs also has macro
recording and replay.)
That's internal scriptability, rather than external, though.
* No mouse; no GUI. Bent seems to like GUI variants of emacs, even if
he hates everything else with mouse support ever coded by man.
Leaving aside the [implied insult deleted]
None of the nasty things that you have said or implied about me are at
all true.
Yeah, I find that in general the GUI paradigm uses up screen
real-estate for purposes that are really attractive in something
one doesn't use often but not so important for a tool that will
get a lot of use.
And the latter often provide ways of hiding or reconfiguring things.
Most paint programs, for example, can be "super-maximized" to full
screen and nearly everything with toolbars lets you rearrange or
remove them unless it's only ever going to be used infrequently by its
very nature or screen real-estate above a certain amount is not useful
for the task it's for. An icon editor window, for example, needs to
have maybe a 321x321 pixel area for the icon editing proper, with a
32x32 grid of 1-pixel-thick grid lines and 9x9 square enlarged pixels.
On even a 640x480(!) display there's enough room left over for the
taskbar, title bar, menu bar, and one toolbar (even with the bloated
kid's-toy default Windows XP theme those don't add 160 vertical
pixels; maybe 120, and closer to 90 with the decent "classic" theme).
And yes, I don't like to have to reach for the mouse when there's a
sensible alternative.
Trouble brews when people start considering search a "sensible
alternative" to scrolling for navigating inside familiar, sub-10,000-
line prose documents. :P
It might have something to do with having been trained in touch
typing, which emphasizes, hm, the "old part" of the keyboard.
Mainly because it is itself old and optimized for older hardware
that's now disused.
(Have you looked up the origins or meaning of "home row" yet?)
Aren't you the vi partisan? Bent and the others are the emacs
partisans.
The key characteristics that make something "expert-friendly"
therefore appear to be some subset of:
* Support for remote use from ancient hardware no-one uses anymore
* Novice-hostile.
The first one doesn't seem important,
And yet apparently some of us think there's some benefit to having
a tool that can be used in situations where graphical applications
are either impossible (e.g., fixing a system where the configuration
of the graphical environment has gone wrong) or impractical (remote
use over a slow connection).
Rare and fixable-with-a-better-wire-protocol, respectively, as
previously discussed. Most power users, never mind normal users, will
never need either, at least given a sensible system recovery
capability. Windows has safe mode, for example, and the System Restore
tool. At least any decently recent Windows version does.
which leaves the second.
And speaks volumes about the motives of nearly everyone participating
in this thread that isn't named bbound, nebulous, or twerpinator.
There's a certain snob appeal to being able to use something
not everyone apparently can manage, sure
Frank admission of guilt noted for the record.
But I'd say I'm not so much actively opposed to tools' being
beginner-friendly as simply indifferent.
Yet, making it novice-friendly seems to suffice to make you no longer
consider it expert-friendly. Interesting, that.
Nah. There seems to always be more to learn, plus there's the fun
of figuring out how to put one's tools to use to solve new problems.
If all you've got is a hammer, everything looks like a nail? :P
[snip]
.
- Follow-Ups:
- Re: Great SWT Program
- From: blmblm
- Re: Great SWT Program
- References:
- Re: Great SWT Program
- From: bbound
- Re: Great SWT Program
- From: blmblm
- Re: Great SWT Program
- From: nebulous99
- Re: Great SWT Program
- From: blmblm
- Re: Great SWT Program
- Prev by Date: Re: Great SWT Program
- Next by Date: Reason why enums since JDK1.5 cannot inherit
- Previous by thread: Re: Great SWT Program
- Next by thread: Re: Great SWT Program
- Index(es):
Relevant Pages
|
