[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gEDA-user: Solving the light/heavy symbol problem


> -----Original Message-----
> From: geda-user-bounces@xxxxxxxxxxxxxx 
> [mailto:geda-user-bounces@xxxxxxxxxxxxxx] On Behalf Of John Doty
> Sent: Tuesday, May 24, 2011 3:05 PM
> To: gEDA user mailing list
> Subject: Re: gEDA-user: Solving the light/heavy symbol problem
> On May 24, 2011, at 9:43 PM, DJ Delorie wrote:
> > My flows are also heavily scripted, so yes, I'll remember.  The 
> > underlying data and low-level tools follow the scripting paradigm - 
> > stepwise progress from A to Z via simple apps that interact with 
> > simple data.  The GUI needs to *hide* that, not replace it, 
> making the 
> > underlying data *seem* integrated and easy to manage, when 
> in fact it 
> > is not.
> This is where we disagree. The GUI needs to make the data 
> easy to manage, but at the same time it needs to *reveal* its 
> machinations. If it hides everything, the user winds up either:

The easy answer to this is to do what Cisco does with their ASDM software:  you can set an option that tells it to present to the user the exact text of every command it is sending to the router.  That's how I've learned to manage my routers.  There are a few complex functions that can't be done through ASDM, for which you need to use the command line, but by the time you're doing those, you already know your way around the router fairly well.

The exact same mechanism would likely work very well for GEDA, allowing users to learn the command line usage while getting help from the GUI along the way.  Adding an option to dump the commands to a text file as they're executed through the GUI would enable to develop fully fleshed-out work flows as well.  

This also helps ensure that the developers don't do anything that REQUIRES the GUI, since every command has to be displayed to the user along the way.


geda-user mailing list