Re: Great SWT Program



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?

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? 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). 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).

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.

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.

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.

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). 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!

You seem to be addressing two groups here: People who fix things
that ain't broke, and people who'd prefer to make changes by editing
a text file than by using a GUI. I claim that I'm solidly in the
camp of "if it ain't broke, don't fix it", and that my preference
for configuring things in the old way actually supports that. :-)?
I'm also solidly in the second group, in part because I'm vaguely
uneasy with tools that store information in locations and formats
I can't easily discover. On some level I suppose that really applies
to text files as well. <shrug>

I do prefer hand-hackable config files (especially to the registry) as
long as the expectation isn't that ordinary usage will require messing
with them. Making the config tool hand-editable serves expert users;
making it GUI-editable serves everyone else. You can have both. Old
Windows stuff used human-editable ini files instead of the registry.

For the record, if I were developing software for non-techies to
use, I *think* I'd try to come up with some way of storing and
manipulating configuration information that would provide them with
the kind of interface they want and still allow expert users to go
in and modify things in other ways if they wanted to.

See ini files, above. :)


.



Relevant Pages

  • 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: Great SWT Program
    ... configuration tools typically provided now. ... GUI to configure something. ... The bad experiences that come to mind ... I haven't found any way to tell Eclipse about that other than to ...
    (comp.lang.java.programmer)
  • Re: Great SWT Program
    ... As in "change the program's options by modifying the configuration ... to produce mysterious impossible-to-clean-up messes that the GUI ... Windoze software that required me to hand-hack the registry to do ... It's solidly in the "old-style Unix programs" camp, ...
    (comp.lang.java.programmer)
  • Re: error "respawning too fast" on Toshiba Protege 7200
    ... > 1) How do you stop linux from booting into the GUI and go into Command Line mode? ... > 2) How do I searchout this error and fix it? ... Next we need to try to correct the X configuration. ... Next we probably want to investigate what video card you have and you ...
    (Fedora)
  • 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)