Re: Great SWT Program

In article <1189986847.247248.125640@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
<nebulous99@xxxxxxxxx> wrote:
On Sep 15, 10:38 am, blm...@xxxxxxxxxxxxx <blm...@xxxxxxxxxxxxx>
wrote:
(I think you claimed a while back to have encountered real-world
damage incurred by words in Usenet, but you didn't, possibly
couldn't, provide enough detail for me to really understand.
Probably not worth pursuing.)

Or maybe you don't want to understand?

I wouldn't put it that way. The way I remember the discussion, you
said you had observed real-world damage resulting from something
that happened in Usenet, without providing any details. To me
that sounds like your saying "I can't provide details, but take
my word for it, it can happen." Given how frequently I disagree
with your summaries of what other people say, I wasn't willing to
do that. I'm not saying you're not right to not share details,
just that without them .... <shrug>

My experience is that this method of
configuring things is not very novice-friendly, but it's less apt
to produce mysterious impossible-to-clean-up messes that the GUI
configuration tools typically provided now.

This is insane. LESS apt to?

It occurs to me that in writing the above paragraph I may have
grouped together an assortment of bad experiences with vaguely
GUI-related things, none of which are really related to using a
GUI to configure something. The bad experiences that come to mind
mostly have to do with trying to switch back and forth between
different versions of some GUI-ish program (GNOME and OpenOffice
are the examples that come to mind). What seems to happen is
that the newer version silently changes configuration files in
a way that presumably reflects changes from the older version.
Sometimes these changes break things. Sometimes the result is
configuration files that can't be read properly by the older
version. I seem to also remember Eclipse becoming confused in
some way that seemed easiest to resolve by shutting it down and
tidying up from the command line. All of this is a bit vague,
but maybe it helps a little. <shrug>

The GUI, if properly designed, constrains
things to reasonable values and can give helpful and immediate alerts
(e.g. that the .sig file you pointed it to doesn't exist).

In principle this is true.

My
experience with things without proper configuration tools is that you
have to hand-edit them, with either inadequate or overly-verbose
documentation (never a straightforward how to do the basics type thing
-- it's either a comprehensive reference unsuited for answering "how
do I?" questions, or it's woefully lacking in any useful information
at all, often by the specific fault of not existing...) and then
separately, later, run whatever uses the file and cope with cryptic
and uninformative error messages or (worse) silent faulty behavior
(e.g. it says "File not found" without saying what file, or what it
wanted the file for; or just posts, apparently successfully, with
no .sig and you don't even know about it until the *next* time you
read news and see all your own posts from the previous session).

Okay: Your mileage varies from mine. (It sounds like you might
be basing what you say on bad experiences with some text-based
newsreader. Care to say which one? Just curious.)

In some contexts "not very novice-friendly" is a significant
drawback. Then again, sometimes the only way I can figure out
to clean up a GUI-tool-created mess is to just delete every
configuration file that looks like it might be related and let
the system start again from the defaults, which has its drawbacks
as well. Perhaps someone more experienced with these tools would
do better.

You must be running into a lot of poor GUI tools. Most likely, half-
assed attempts to graft a GUI onto something from the Stone Age rather
than something designed from the ground up by GUI-aware programmers in
a modern time frame. Crummy GUIs on graphical ports of console apps
being my main suspects here.

No, I don't really use many of those -- I use a lot of text-mode
tools, but since one of the things I like about them is that they
*are* text-mode, why would I use a GUI-fied version of them?

Specific tools I can remember having trouble with are mentioned
earlier. Maybe they *are* poor GUI tools; I'm certainly not the
best person to judge.

And perhaps someone more experienced would also know good ways to
deal with another problem I routinely encounter with GUI tools:
lack of what I'd call "scriptability" (possibly not the best
choice of words, but I can't think of a better one).

This would sometimes be nice for advanced users; the problem being
that as a rule scriptability comes at the expense of having a proper
UI, as the UI becomes a programming language instead of a human-
oriented interface. The real fix is to have a scriptable, not directly
human-usable engine and a GUI front-end driving it. If well-designed
such a system would satisfy both human usability concerns and
usability via automation concerns.

Wow. Something we more or less agree on!

Example: I dabble a little with Eclipse. For reasons that seem
good to me (though that might be debatable), I often create groups
of small projects in which the source code lives somewhere other
than in Eclipse's workspace. If I move that source code later,
I haven't found any way to tell Eclipse about that other than to
delete the old projects and create new ones, one at a time, using
the GUI, which I find tedious beyond words. If configuration
information were stored in text files, I could just do a
mass edit and change all occurrences of OldPathToSource with
NewPathToSource, which would be a lot less work. (Risky? Maybe.
If I were worried, I'd make a backup copy of everything first.)

Is it possible to move the files from within eclipse? It should keep
track of them properly then. Renaming within eclipse works and avoids
all the problems of renaming externally and then eclipse wondering
where the hell the files went. Moving probably works similarly.

I'm not sure it is (possible to move files in an external source
location from within Eclipse). A quick experiment shows that
the (external) location shows up in the project "Properties",
but there's no obvious way to change it, and I'm not finding a
menu item that sounds promising.

but at some point I had that "you are in a maze of twisty passages"
feeling, and I gave up the attempt. I often have this feeling
with GUI tools. Probably more practice with them would help.
Probably that would help me in other ways as well.

If that's true you're probably not too familiar with the basics of
operating whatever GUI this was (Windoze, Mac, or some X WM I guess).
The good news is you only have to learn one of these once, and the
knowledge can be used to operate every native application (YMMV with
dodgy ports, though).

Could be. I've had enough practice that I don't have a lot of
trouble with the mechanics (and have been very happy to discover
that many of these GUI things are a lot more keyboard-drivable
than they at first appear to be). Most of this practice is with
programs running under various X-based environments, but there's
a little Windows in there too. I think what I'm not so good
at is guessing where to find, in a complicated menu structure,
something useful for the task I have in mind. Online help is
sometimes excellent, sometimes frustratingly inadequate.

With the wacky and endlessly-varied interfaces
to console apps (including old DOS stuff before CUA was settled on as
a standard, as well as old Unix stuff) you have to learn that much
stuff for *each application* before it becomes usable!

Well, yeah, kind of .... A lot of them these days provide
some kind of text menu to help new users, and there are a
lot of keystrokes that do the same thing in many applications.
I don't think the situation is quite as bad as you make out, but
total consistency -- yeah, not so much. How much this annoys a
person, and whether there are compensating advantages, might be
a YMMV thing.

[ snip ]

--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.
.

Relevant Pages

  • Re: Great SWT Program
    ... to produce mysterious impossible-to-clean-up messes that the GUI ... configuration tools typically provided now. ... experience with things without proper configuration tools is that you ... I haven't found any way to tell Eclipse about that other than to ...
    (comp.lang.java.programmer)
  • Re: Code-and-Fix for GUIs [Was: Rework]
    ... Randy Howard wrote: ... >>concentrated on one aspect at the expense of others (the GUI ... > slayed his fair share of dragons. ... > few really bad process experiences in the last few years) to ...
    (comp.object)
  • Re: Code-and-Fix for GUIs [Was: Rework]
    ... Randy Howard wrote: ... >>concentrated on one aspect at the expense of others (the GUI ... > slayed his fair share of dragons. ... > few really bad process experiences in the last few years) to ...
    (comp.programming)
  • Re: zinc performance
    ... >>> Is zinc stable for real time system like vxWorks? ... So I am mostly using code to design my GUI rather ... > I have had the same problem of designer crashing on windows 2000. ... These are different approaches to device configuration. ...
    (comp.os.vxworks)
  • Re: [SLE] NetBeans 5.5 Released
    ... it wasn't until I started playing with Eclipse that I even ... apps are Win32 or Win64 and don't run on Linux or Macintosh. ... I couldn't do the GUI wanted without having to resort to ... nesting layouts like in straight Java. ...
    (SuSE)