X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Date: Sat, 27 Oct 2012 00:47:16 +0200 From: Bas Gieltjes To: geda-user AT delorie DOT com Subject: Re: [geda-user] The state of gEDA/gaf (Was gEDA/PCBs diversity, Was: Pin hole size) Message-ID: <20121027004716.6d970660@Parasomnia.thuis.lan> In-Reply-To: <834283D4-0891-486E-A981-2FF20B32C615@noqsi.com> References: <2CB304B5-9587-4734-84E4-49F464744D11 AT noqsi DOT com> <6BF2E986-51EB-41E9-A4AD-8071CD00B1A1 AT jump-ing DOT de> <834283D4-0891-486E-A981-2FF20B32C615 AT noqsi DOT com> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-OriginalArrivalTime: 26 Oct 2012 22:47:16.0626 (UTC) FILETIME=[D9227720:01CDB3CB] X-RcptDomain: delorie.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id q9QMlL5U031620 Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > >> I can see somebody writing a new schematic editor using 21st > >> century GUI conventions, but it wouldn't be gschem, it would be a > >> new development. > > > > And how does that stop gschem moving to 21st GUI conventions, too? > > Because the internals of gschem reflect very old notions of GUI. You > can't get there from here in any practical way. > > > Currently we have ridiculous situations like that pcb and gschem > > can't even agree on the same mouse button for panning/zooming. > > They are separate, independent tools with separate, independent > histories, both predating modern GUI conventions. Why would you > expect consistency here? > > > Much less on other usage items. Arguments like "that's the most > > powerful way" - which actually means "I'm used to this" - can't be > > right for both. > > > > What I simply do not get is why so many gEDA users literally insist > > on gEDA's GUI being non-conformant to any other GUI tool out there. > > Trying to tinker with gschem to make it look modern will result in a > miserable kludge. But understand that gschem is actually a very > shallow tool: it's simply a graphical editor for a rather simple file > format. So, start with a modern GUI framework, the gEDA schematic > file format, and fill in the glue. Leave gschem alone for those of us > who are used to it. > > > Or where else have you seen a tool which requires typing "e" and > > "r" in that order to rotate an item? > > Viewlogic. Two decades ago. gschem is very old-fashioned. Nice explanation. But you forgot to mention the strength of your favourite toolkit: system-gschemrc. Using the configure option (global-set-key "keybinding" 'hotkey) gives the possibility to change keybindings to something that "21st GUI conventions" users prefer. Check the file gschemrc in this repository: https://github.com/nixotic/gEDA-tools, "middle-button" and "third-button" are configurable. Nice, I didn't know that this is configurable. Is there geda-wiki information? No. Can these options be used to move to a "21st GUI conventions"? Maybe. Not being an expert with geda-pcb, but even those menu's are configurable. Check or google "gpcb-menu.res". Not as easy as system-gschemrc, you also need to supply the complete menu instead of only the keybindings. A pcb expert can shed more light. I don't know what 21st GUI conventions for mouse and keyboard actions are. It should be possible to apply them to gschem and pcb, without breaking the current mouse and keyboard actions. Some patches are probably needed to make gschem and pcb accept them. Make the above the default for new users. Experienced user can stick with the current defaults. You know how to wield the power of the toolkit. > > Except their usage is confusing enough to make them a science on > > their own. If there weren't helpers like xgsch2pcb or the recent > > direct schematics import I couldn't encourage people to use gEDA. > > Competitors like Fritzing are so much easier and more intuitive to > > use. > > That's the usual "I don't want a toolkit, but an integrated tool" > complaint. But Fritzing can't do most of the things that gEDA can. I am still wondering why the toolkit can't be used to resemble an integrated tool without breaking or obstructing the underlying toolkit. So that when integrated tool users gain more experience or want more control they can use the underlying toolkit. But first give them easy and consistent access to the tools. Trying to halt development because it might obstruct your toolkit use is not constructive. Try coaching users and (new) developers instead of rejecting everything that eventually might obstruct your tool usage. Bas --