On 9/21/06, Igor2 <[EMAIL PROTECTED]> 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 [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
