Re: gEDA-user: PCB a bad name ?

["Samuel A. Falvo II" <sam.falvo@xxxxxxxxx>]

On 9/21/06, Igor2 <igor2@xxxxxxxxxxx> wrote:
> Of course, it would make more sense if HIDs could be loaded runtime
> :) Before that, there could be 2 binaries and on download and/or install
> and/or ./configure the user could choose. I'm not sure how comfortable to
> manage 2 branches of the mostly same HID with cvs, it's more or less ok
> with SVN (but means extra work of course).

Having to recompile something to turn off balloon help seems a bit of
a stretch, no?  Remember that when recompiling, you always run the
risk of breaking something.  It's like tearing down your current house
and building a new one, just to change a light fixture.

The dynamically loadable HIDs are a good idea, of course -- this is
essentially how PC/GEOS worked to allow configuration not only of the
core OS, but also its support for novice/intermediate/advanced users
for most GeoWorks applications.  But that sounds like a heavy-weight
process that 99% of the people here just won't use -- thus still
putting code in that you won't use.

There is nothing wrong with supporting balloon help, and it's hardly
what I'd call heavyweight.  PCB needs to maintain some form of command
tables *anyway* -- extending them with quick synopses and creating a
function to render them into a balloon seems to me like it'd be a
whole lot less heavyweight than any other idea proposed.

Remember, my complaint (about a year ago?) with PCB was *consistency*
and *learnability* with gschem.  They are such similar programs from
the user's perspective (both allowing you to draw and manage objects
on a 2D surface) that they should, ideally, have similarly invoked
command-sets.  We know from experience that they DO have similar
functionality at the graphical level (move this here, rotate that
there, etc).  Commands to "move this here" and "rotate that there"
should have similar names.

Some might say, "But, now you're advocating integration!"  No --
they're not integrated any more than Emacs is integrated with Word.
Yet both have such a similar interface that knowledge of Word allows
one to (at least minimally) use Emacs, and vice versa.  I won't get
into Vi (though Vi is my favorite editor of choice currently, I must
point out that I spent the better part of a year learning it while
becoming increasingly frustrated with alternatives like joe and jed.
Even today, however, I'm *still* learning new commands for common
tasks in Vi.  Emacs is still as opaque to me as a cinder block,
despite having used MicroEmacs on AmigaOS for years; but I can still
do *basic* editing with it).  But I'm digressing, hopefully with a
point to prove that similar interfaces do not an integrated
application make.

The balloon help would go a long way towards reminding the user, "Hey,
this is what you can do with this object, and here are the keyboard
commands to do it."  Eventually, as experience with the program grows,
you won't need the balloons.  So you can turn them off.

Actually, on second thought, perhaps balloons aren't the right tool,
despite being the right concept.  Instead, a semi-transparent pane can
appear at the bottom of the screen (if the mouse is above half-way the
view's height), or at the top of the screen (if the mouse is below the
halfway mark).  That seems to make more sense.

--
Samuel A. Falvo II


_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user