element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • Community Hub
    Community Hub
    • What's New on element14
    • Feedback and Support
    • Benefits of Membership
    • Personal Blogs
    • Members Area
    • Achievement Levels
  • Learn
    Learn
    • Ask an Expert
    • eBooks
    • element14 presents
    • Learning Center
    • Tech Spotlight
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents Projects
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Avnet & Tria Boards Community
    • Dev Tools
    • Manufacturers
    • Multicomp Pro
    • Product Groups
    • Raspberry Pi
    • RoadTests & Reviews
  • About Us
    About the element14 Community
  • Store
    Store
    • Visit Your Store
    • Choose another store...
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      •  Japan
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      •  Vietnam
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
  • Settings
Autodesk EAGLE
  • Products
  • More
Autodesk EAGLE
EAGLE User Support (English) A newcomer's experience and what can be done about it
  • Blog
  • Forum
  • Documents
  • Events
  • Polls
  • Files
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Join Autodesk EAGLE to participate - click to join for free!
Actions
  • Share
  • More
  • Cancel
Forum Thread Details
  • Replies 34 replies
  • Subscribers 189 subscribers
  • Views 2453 views
  • Users 0 members are here
  • standardization
  • gui
  • library
  • usability
Related

A newcomer's experience and what can be done about it

lix
lix over 14 years ago
Hello,
As I just finished my first (small) project in Eagle, I want to express some thoughts on how the program could be improved, especially from the point of view of a new user who did not gave up after his first contact with the software (as probably many other did!). Although I read that an upcoming V6 is under way, however I have no hopes that CadSoft would take my suggestion seriously (it's probably too late anyway); in this respect, you can see my post as an exercise in futility…
First, some relevant information on myself: although I am a newcomer to Eagle, I have a large engineering experience in electronics and software development. During the mid-eighties I led a small team who designed a PCB layout program on a graphical CP/M machine (using a mouse!); by the end of the eighties I jumped on Orcad, then in the nineties on Accel Technology's Tango suite (under DOS), and later on P-CAD 2000 under Windows, which I still use today. On occasion I had to professionally evaluate several CAD programs, including but not limited to Protel, Specctra and Ultiboard.
I also stumbled upon Eagle several times, but it never made it, as the UI was so clumsy. I re-visited it now for several reasons: as I am soon going to retire but still plan to work on hobby projects, I need a reliable and low-cost tool, which ideally should work also on a Macintosh. As the Mac version now runs natively (previous releases required the X11 windowing subsystem), I saw it as suitable solution.
In order to make things straight: I have no issues with any OS or computer maker, be it Linux, Windows or MacOS X. I had (and partially still have) to deal in my career with all of them, and many other Unices in-between (HP-UX, AIX, DG-UX, Nextstep, etc.). And yes, I am a long time user of many CLIs (command line interfaces), from CP/M to DOS to sh, tcsh, bash, etc., even to some written by myself while developing software for various projects.
However, for personal reasons I need not to explain, my current working machine is a MacBook Pro notebook (and I am very happy with it). I use the Parallels virtualization software to run several virtual machines, among others a Ubuntu Linux and a Windows 7.
Now back to Eagle. My remarks are based on the use of the freeware, unregistered Eagle version 5.11.0 on a MacBook Pro running MacOS X 10.6.8 (Snow Leopard).
To summarize my experience in a single phrase: Eagle is an incredibly solid and powerful piece of software, with an incredibly poor user interface. Let me now go to the details.
The good: the software is very solid, during my three weeks experience with Eagle, it never crashed and I never lost files or parts I've designed in my own library. I was particularly impressed with the autorouter. I've used and seen quite some of them in my professional life, including the Cooper & Chan autorouter, quite famous by the end of the nineties, but for this price Eagle is really outstanding. And last but not least, Eagle is probably one of the few (if not the single) serious CAD packages that runs natively on the Mac.
The bad: the user interface is non-standard by any of today's GUI standards, be it Windows, Mac or Linux. The library management system is a complete torture. The fact that Eagle runs on more than one platform may have led to some curious decisions by the developers, as for instance ignoring many of the underlying APIs of the individual OSes and rather build instead their own functions/classes (wheel re-invention). The net result is that the program looks and acts strange, gives the feeling of "not belonging here". Frustration is the first feeling a newcomer gets, so in this respect, the acronim "Easily Applicable Graphical Layout Editor" (Eagle) is only wishful thinking.
There are many issues that I consider as not being compliant with modern GUI design principles, but I will list only the most glaring of them. I believe changing these would not alienate current users, but would greatly increase the number of new users adopting Eagle.
1. This one must be written in bold letters: elimination of the "MOVE" command (button). This should be replaced with the default state of the GUI, that should be reached by clicking a button represented normally by an arrow (standard for most drawing programs). In this state, it should be possible to click on an object, be it a part, a text, a pad, a line, etc. and move it by acting on the mouse. A right click should bring a context sensitive menu that should allow additional operations like "delete", "rotate", "replace", or show "properties". In addition, several keys should be used as shortcuts that would greatly increase the speed of operation (e.g. "R" for rotate, "DEL" or "backspace" for delete, etc.). Obviously, the keys should have some defaults, but should be user assignable. It is important that the shortcuts should work without modifier keys (i.e. CTRL, ALT, CMD, SHIFT), therefore a solution must be found for the CLI. And this brings me to the second issue:
2. Eliminate the CLI from the GUI, or at least allow it to be hidden (this should be the default). I spent quite some time reading the forum and I noticed that there are a couple of die-hard users that would rather get rid of one of their fingers than of the CLI. However, they are a small minority. There is even someone claiming being able to do certain operations 10 times faster with the CLI than in the GUI: this doesn't mean that the CLI (or for that matter that guy) is better, rather that the GUI is so poorly designed, that it does not offer the same functionality!
3. Another disturbing deviation from standard GUI practices is the use of the right-click button for the ROTATE function. Right-click brings a context menu on all platforms, be it Windows, Mac or Linux. Eagle is inconsistent in this respect: there are situations where a right-click brings indeed a contextual menu, but others where not. Rotate should be implemented through a simple key (user-programmable): as long as an object is selected, pressing a key without modifiers (e.g. "R") should perform the rotation. And still better: "SHIFT+R" should rotate the part in 45 degrees increments, while "ALT+R" in one-degree increments.
4. Operations performed on multiple objects are sorely missing (maybe they are possible within the CLI, but this is not the point). For instance, there are no ways (or at least I've found none) to change at once one or more characteristics of all pins in a package (library edit), or to change the width of a set of lines, or the parameters of several vias. You need to take each and every object individually and apply the required modification. If you can do this with a simple CLI command, then it is understandably why some users  need it, but again, this only demonstrates a badly designed GUI.
5. The total confusion surrounding the cut/copy/paste operations (largely discussed elsewhere on the forum). Why should Eagle use different meanings for these commands, when everybody knows by now what they should do? The presence of two similar buttons (cut and delete) is confusing enough. I had a hard time copying a symbol from a library into my own library following the step-by-step procedure in the manual, simply because I confused the CUT button with the DELETE button (in this case indeed, the CLI saved me, because typing the commands indicated in the manual led to the expected result; later I found out that in fact I have had to use the scissors button). To resume: the actual DELETE should be renamed CUT while the actual CUT should be renamed COPY. And PASTE should paste the same object as long as it is used, without the need to re-copy the object. In fact the PASTE button is now mixture of COPY and PASTE, which is wrong. If I need to copy&paste one pin 24 times (e.g. for an IC), why do I need to click double so much times as necessary? It should work like this: select the master pin, click copy (or, better right-click and select copy), then click paste 24 times.
6. Another strange thing is that after the initial start, if you resize a schematic or layout editor window its content is also resized. Thus it's impossible to scroll, simply because there are no scroll bars unless you zoom in. This behavior is incorrect, the content's size must remain unchanged and only the scroll bars should be updated (if required). But again, these side-effects are the result of not using the APIs provided by the individual underlying OS on which Eagle is running.
7. The library management must be re-worked. The general paradigm is quite well thought (the Device/Package/Symbol concept), however, there are many implementation issues. I find inconsistent that the symbols are not displayed in the library hierarchy. Deleting library objects is awkward, one must always know the exact name of the object in order to delete it. Why not simply search for it in the library hierarchy, right-click and choose "delete"? The same applies for "rename". And, as I already hinted before, there should be a much obvious way to create new packages/symbols starting from existing objects, e.g: open an existing object, modify it and then save it into the same library with a different name, or into a different library with any name you want. A sort of "save as…" for devices/packages/symbols.
8. There are serious issues with the mouse and display, at least on the Mac version: sometimes when scrolling the drawing is only partially redrawn. I need to click the redraw button to correct the situation. In addition, due to the proprietary mouse control implementation, I can't scroll left/right, which would be a major benefit, especially for those users having a multi-touch capable trackpad (all MacsBooks manufactured after 2007 have one). By the way, it is my experience that a multi-touch capable trackpad can almost completely replace a mouse and it is much confortable to work with.
9. And finally, a minor one: ESC should terminate all commands, including "place via" or "place hole".
All the above suggestions concern only the user interface. There are obviously other potential improvements in other areas, and many of them have already been suggested by other posters. As a beginner with Eagle I am not yet in a position to comment on this. From what I have seen so far, Eagle seems to me a very solid piece of software with great potential. It's a pity that due to the unconventional user interface so maney potential users are scared away. I suspect improvements at this level would help increase Eagle's market share.
Since 1984 when the first GUI becomes available for the large masses (the launch of the original Macintosh), the GUI has established itself and reached a good level of standardization. The graphics may be different between Windows, Mac and Linux, but most of the mouse and keyboard interactions are rather common on all of them. Why should Eagle be different?
Nevertheless, no matter what CadSoft will do with their next release, I plan to continue using Eagle for future projects, but only for private use for the time being (I will probably even buy the hobbyist version). If during the next releases the user interface will improve (and standardize), I might even recommend it for professional use.
Lix

Hello,

 

As I just finished my first (small) project in Eagle, I want to express some thoughts on how the program could be improved, especially from the point of view of a new user who did not gave up after his first contact with the software (as probably many other did!). Although I read that an upcoming V6 is under way, however I have no hopes that CadSoft would take my suggestions seriously (it's probably too late anyway); in this respect, you can see my post as an exercise in futility…

 

First, some relevant information about myself: although I am a newcomer to Eagle, I have a large engineering experience in electronics and software development. During the mid-eighties I led a small team who designed a PCB layout program on a graphical CP/M machine (using a mouse!); by the end of the eighties I jumped on Orcad, then in the nineties on Accel Technology's Tango suite (under DOS), and later on P-CAD 2000 under Windows, which I still use today. On occasion I had to professionally evaluate several CAD programs, including but not limited to Protel, Specctra and Ultiboard.

 

I also stumbled upon Eagle several times, but it never made it, as the UI was so clumsy. I re-visited it now for several reasons: as I am soon going to retire but still plan to work on hobby projects, I need a reliable and low-cost tool, which ideally should work also on a Macintosh. As the Mac version now runs natively (previous releases required the X11 windowing subsystem), I saw it as suitable solution.

 

In order to make things straight: I have no issues with any OS or computer maker, be it Linux, Windows or MacOS X. I had (and partially still have) to deal in my career with all of them, and many other Unices in-between (HP-UX, AIX, DG-UX, Nextstep, etc.). And yes, I am a long time user of many CLIs (command line interfaces), from CP/M to DOS to sh, tcsh, bash, etc., even to some written by myself while developing software for various projects.

 

However, for personal reasons I need not to explain, my current working machine is a MacBook Pro notebook (and BTW, I am very happy with it). I use Parallels virtualization software to run several virtual machines, among others a Ubuntu Linux and a Windows 7.

 

Now back to Eagle. My remarks are based on the use of the freeware, unregistered Eagle version 5.11.0 on a MacBook Pro running MacOS X 10.6.8 (Snow Leopard).

 

To summarize my experience in a single phrase: Eagle is an incredibly solid and powerful piece of software, with an incredibly poor user interface. Let me now go into details.

 

The good: the software is very solid, during my three weeks experience with Eagle, it never crashed and I never lost files or parts I've designed in my own library. I was particularly impressed with the autorouter. I've used and seen quite some of them in my professional life, including the Cooper & Chan autorouter, quite famous by the end of the nineties, but for this price Eagle is really outstanding. And last but not least, Eagle is probably one of the few (if not the single) serious CAD packages that run natively on the Mac.

 

The bad: the user interface is non-standard by any of today's GUI standards, be it Windows, Mac or Linux. The library management system is a torture. The fact that Eagle runs on more than one platform may have led to some curious decisions by the developers, as for instance ignoring many of the underlying APIs of the individual OSes and rather build instead their own functions/classes (wheel re-invention). The net result is that the program looks and acts strange, gives the feeling of "not belonging here". Frustration is the first feeling a newcomer gets, so with all due respect, the acronim "Easily Applicable Graphical Layout Editor" (Eagle) is only wishful thinking (maybe it was true 15 years ago, but not anymore today).

 

There are many issues that I consider as not being compliant with modern GUI design principles, but I will list only the most glaring of them. I believe changing these would not alienate current users, but would greatly increase the number of new users adopting Eagle.

 

1. This one must be written in bold letters: elimination of the "MOVE" command (button). This should be replaced with the default state of the GUI, that should be reached by clicking a button represented normally by an arrow (standard for most drawing programs). In this state, it should be possible to click on an object, be it a part, a text, a pad, a line, etc. and move it by acting on the mouse. A right click should bring a context sensitive menu that should allow additional operations like "delete", "rotate", "replace", or show "properties". In addition, several keys should be used as shortcuts that would greatly increase the speed of operation (e.g. "R" for rotate, "DEL" or "backspace" for delete, etc.). Obviously, the keys should have some defaults, but should be user assignable. It is important that the shortcuts work without modifier keys (i.e. CTRL, ALT, CMD, SHIFT), therefore a solution must be found for the CLI. And this brings me to the second issue:

 

2. Eliminate the CLI from the GUI, or at least allow it to be hidden (this should be the default). I spent quite some time reading the forum and I noticed that there are a couple of die-hard users that would rather get rid of one of their fingers than of the CLI. However, these are a small minority. Someone claimed being able to do certain operations 10 times faster with the CLI than in the GUI: this doesn't mean that the CLI (or for that matter that guy) is better, rather that the GUI is so poorly designed and not offering the same functionality!

 

3. Another disturbing deviation from standard GUI practices is the use of the right-click button for the ROTATE function. Right-click brings a context menu on all platforms, be it Windows, Mac or Linux. Eagle is inconsistent in this respect: there are situations where a right-click brings indeed a contextual menu, but others where not. Rotate should be implemented through a simple key (user-programmable): as long as an object is selected, pressing a key without modifiers (e.g. "R") should perform the rotation. And still better: "SHIFT+R" should rotate the part in 45 degrees increments, while "ALT+R" in one-degree increments.

 

4. Operations performed on multiple objects are sorely missing (maybe they are possible within the CLI, but this is not the point). For instance, there are no ways (or at least I've found none) to change at once one or more characteristics of all pins in a package (library edit), or to change the width of a set of lines, or the parameters of several vias. You need to take each and every object individually and apply the required modification. If you can do this with a simple CLI command, then it is understandably why some users  need it, but again, this only demonstrates a badly designed GUI.

 

5. The cut/copy/paste operations are totaly confusing (this is largely discussed elsewhere on the forum). Why should Eagle use different meanings for these commands, when everybody knows by now what they should do? The presence of two similar buttons (CUT and DELETE) is confusing enough. I had a hard time copying a symbol from a library into my own library following the step-by-step procedure in the manual, simply because I confused the CUT button with the DELETE button (in this case indeed, the CLI saved me, because typing the commands indicated in the manual led to the expected result; later I found out that in fact I have had to use the scissors button). To resume: the actual DELETE should be renamed CUT while the actual CUT should be renamed COPY. And PASTE should paste the same object as long as it is used, without the need to re-copy the object. In fact the PASTE button is now a mixture of COPY and PASTE, which is confusing. If I need to copy&paste one pin 24 times (e.g. for an IC), why do I need to click double so much times as necessary? It should work like this: select the master pin, click copy (or, better right-click and select copy), then click paste 24 times.

 

6. Another strange thing is that after the initial start, if you resize a schematic or layout editor window, its content is also resized. Thus it's impossible to scroll, simply because there are no scroll bars unless you zoom in. This behavior is incorrect, the content's size must remain unchanged and only the scroll bars should be updated (if required). But again, these side-effects are probably the result of not using the APIs provided by the individual underlying OS on which Eagle runs.

 

7. The library management must be re-worked. The general paradigm is quite well thought (the Device/Package/Symbol concept), however, there are many implementation issues. For example I find inconsistent that the symbols are not displayed in the library hierarchy. Deleting library objects is awkward, one must always know the exact name of the object in order to delete it. Why not simply search for it in the library hierarchy, right-click and choose "delete"? The same applies for "rename". And, there should be a much obvious way to create new packages/symbols starting from existing objects, e.g: open an existing object, modify it and then save it into the same library with a different name, or into a different library with any name you want. A sort of "save as…" for devices/packages/symbols.

 

8. There are serious issues with the mouse and display, at least on the Mac version: sometimes when scrolling the drawing is only partially redrawn, large screen areas remain blank. I need to click the redraw button to correct the situation. In addition, due to the proprietary mouse control implementation, I can't scroll left/right, which would be a major benefit, especially for those users having a multi-touch capable trackpad (all MacsBooks manufactured after 2007 have one). By the way, it is my experience that a multi-touch capable trackpad can almost completely replace the mouse and is much comfortable to work with.

 

9. And finally, a minor one: ESC should terminate all commands, including "place via" or "place hole".

 

All the above suggestions concern only the user interface. There are probably other potential improvements in other areas, and some of them have already been suggested by other posters. As a beginner with Eagle I am not yet in a position to comment on this. From what I have seen so far, Eagle seems to me a very solid piece of software with great potential. It's a pity that due to the unconventional user interface so many initial users are scared away. I suspect improvements in this area would help increase Eagle's market share.

 

Since 1984 when the first GUI became available for the large masses (with the launch of the original Macintosh), the GUI has established itself and reached a good level of standardization. After all, 27 years passed since then! The graphics may be different between Windows, Mac and Linux, but most of user interactions with the mouse and the keyboard are rather common on all of them. Why should Eagle be different?

 

Nevertheless, no matter what CadSoft will do with their next release, I plan to continue using Eagle for future projects, but only for private use for the time being (I will probably even buy the hobbyist version). If future releases will improve (and standardize) on the user interface, I might even recommend it for professional use.

 

Lix

  • Sign in to reply
  • Cancel
Parents
  • e14 Contributor
    e14 Contributor over 14 years ago

    Element 14 User wrote on Wed, 09 November 2011 12:54

    As I just finished my first (small) project in Eagle, I want to express

    some thoughts on how the program could be improved,

     

    At least you didn't come here ranting and raving, especially without having

    learned at least some of Eagle.  We do get that a lot here.

     

    I can see the point behind some of your statements, but others make it

    clear you are unaware of some Eagle features.

     

    Quote:

    the user interface is non-standard by any of today's GUI standards, be

    it Windows, Mac or Linux.

     

    That may be true, but keep in mind that Eagle started a long time ago

    before there was any consensus on such conventions, and it grew up on

    Windows.  MAC users are a small minority.

     

    Quote:

    The library management system is a complete torture.

     

    I'm not sure what you mean by "library management".  Think of the supplied

    Eagle libraries as either toys for hobbyists or examples at best.  Serious

    users make their own libraries.  I'm not sure what exactly there is to

    "manage", but I guess I haven't run into it maybe because I've made all my

    own libraries.

     

    Quote:

    1. This one must be written in bold letters: elimination of the "MOVE"

    command (button). This should be replaced with the default state of the

    GUI,

     

    I don't fully understand.  Clearly eliminating the MOVE command makes no

    sense.  Things still need to be moved and other operations performed, so

    the real question is when the MOVE command should be active.  I guess what

    you're saying is that you want MOVE to become active whenever any other

    command is unambiguously ended?  Hmm, I suppose that could be possible, but

    the unambiguously ending part sounds like it would be difficult or

    impossible in many instances.  If I start a ROUTE command, for example, I

    don't want to have to explicitly start routing again after completing a

    route.  Usually you do a bunch of routes in sequence, so this modal concept

    makes sense.

     

    Part of the problem appears to be you are not aware of the hot key

    capability, or haven't set it up usefully.  I use F7 as a shortcut for

    MOVE, so starting a move when I'm not already in MOVE is trivial and not a

    problem for me.

     

    Quote:

    that should be reached by clicking a button represented normally by an

    arrow (standard for most drawing programs). In this state, it should be

    possible to click on an object, be it a part, a text, a pad, a line, etc.

    and move it by acting on the mouse.

     

    Isn't that exactly how it already works?  It certainly does when starting

    MOVE by command or hot key.  I don't use the clickety-click tool buttons

    because a hot key or typing a command is so much faster, but I'd be real

    surprised if clicking whatever the move tool button is doesn't do exactly

    what you ask.

     

    Quote:

    It is important that the shortcuts should work without modifier keys

    (i.e. CTRL, ALT, CMD, SHIFT), therefore a solution must be found for the

    CLI.

     

    You seem to not be aware that the function keys can be mapped to arbitrary

    command strings.  Do you really need more than 12 things you can do with a

    single keystroke without modifiers?  I have most of the F keys bare, shift,

    and ctrl mapped to various commands.  The ones that require modifiers are

    only a tiny bit more to type, and it sortof happens automatically without

    concious thought once you get used to it anyway.  It seems like 12 single

    keystroke commands, and 24 more with a single modifier is a decent amount.

     

    Quote:

    Eliminate the CLI from the GUI,

     

    NO, NO, NO and NO again!!!

     

    The fact that everything is a command leads to much of what is powerful and

    great about Eagle.  Just because some people don't want to use it for some

    reason doesn't change the fact that it's very powerful and useful.  Once

    you get good at it, you'll see it speeds up your workflow more than any

    fancy mouse interactions can.  This is inherent to mouse movements

    requiring eye-hand coordination that require concious thought, versus

    typing which eventually gets done a bit below the concious level once you

    get good at it.  Even when it doesn't take less time, the fact that it's

    partly done sub-conciously makes it at least feel like it takes less time,

    probably because you can be thinking about something else while your

    fingers are performing the mechanics of the command you thought about a few

    100 milliseconds earlier.

     

    Unfortunately too many people are unwilling to get good at the command line

    and therefore can't get the full power from it, and therefore bash it when

    in fact it's one of the really powerful things about Eagle that sets it

    apart from other software.  A pure clickety-click interface may be easy to

    use and cute at first, but it gets tiresome quickly.  Unfortunately, too

    many people can't seem to get past the instant gratification phase.  That

    doesn't make the command line less powerful though.

     

    Quote:

    or at least allow it to be hidden (this should be the default).

     

    NO again!  The value of the command line is greatly diminished if it isn't

    always there.  If there is ever a option to hide it, that must be a

    concious deliberate act so that it doesn't happen accidentally.

     

    Quote:

    I spent quite some time reading the forum and I noticed that there are

    a couple of die-hard users that would rather get rid of one of their

    fingers than of the CLI.

     

    You'll find a lot of Eagle power users like that.  Don't try to take away

    the power user tools just because you haven't become one yet.  Someday you

    may get there and then wish you could have them back.

     

    Quote:

    However, they are a small minority.

     

    I don't know how you think you know this, but I seriously doubt that it

    true among long time Eagle users and power users.

     

    Quote:

    Rotate should be implemented through a simple key (user-programmable):

    as long as an object is selected, pressing a key without modifiers (e.g.

    "R") should perform the rotation. And still better: "SHIFT+R" should

    rotate the part in 45 degrees increments, while "ALT+R" in one-degree

    increments.

     

    You really need to read up on the ASSIGN command.

     

    Quote:

    Operations performed on multiple objects are sorely missing

     

    No, they generally aren't.  I think you're missing the GROUP command.  Once

    you define a group, for the most part you can apply commands to it and they

    effect all the objects in the group.

     

    Quote:

    (maybe they are possible within the CLI, but this is not the point).

     

    There will always be complicated things that can't be reasonably described

    with clickety-clicking or a few commands.  This is where ULPs and the

    command language make Eagle so powerful.  By writing a ULP or sometimes

    external program that writes a command script, you can do some really

    complicated things in a automated way.  For example, I have external

    programs that write scripts for repetitively placing pads of IC packages.

    There are too many intricacies and special cases to build something like

    this into Eagle, but it's not hard at all to write a program to do these

    strange operations.

     

    Quote:

    For instance, there are no ways (or at least I've found none) to change

    at once one or more characteristics of all pins in a package (library

    edit), or to change the width of a set of lines, or the parameters of

    several vias.

     

    Again, it sounds like you are unaware of GROUP.

     

    Quote:

    The total confusion surrounding the cut/copy/paste operations (largely

    discussed elsewhere on the forum).

     

    Yes, there are some rather poor choices for command names in Eagle.  But

    note these are naming issues only.  The actual operation of the commands if

    they were properly named are usually reasonable enough.

     

    For example, in Eagle you just have to learn that CUT does a COPY, and COPY

    rarely does anything you actually want.  In a schematic, WIRE is used to

    draw lines except when those lines represent wires, then you have to use

    NET.  In a board WIRE draws lines except when they are wires, then you use

    ROUTE.

     

    Quote:

    Another strange thing is that after the initial start, if you resize a

    schematic or layout editor window its content is also resized.

     

    That's not strange, that's exactly how it should be.  You generally want to

    work with the schematic page, for example, as large as possible in the

    window.

     

    Quote:

    Thus it's impossible to scroll, simply because there are no scroll bars

    unless you zoom in.

     

    Panning and zooming in Eagle is much nicer than using scroll bars.  You

    simply hold the middle mouse button down and everything pans as if it were

    attached to the pointer.  This is about as intuitive and simple as it gets.

    The scroll wheel zooms in and out, and of course you can set up hot keys

    to zoom in and out relative or go back to best fit or whatever.  I like the

    way this works much better than other programs that use scroll bars.  Not

    only do the scroll bars use up pixels better spent on higher resolution,

    but to use them you have to move to the edge of the window then back when

    you finally got the display where you want it.  No thanks.

     

    Quote:

    There are serious issues with the mouse and display, at least on the

    Mac version: sometimes when scrolling the drawing is only partially

    redrawn.

     

    I've never seen this on Windows 2000 or Windows XP.  It sounds like a bug.

     

    Quote:

    due to the proprietary mouse control implementation, I can't scroll

    left/right,

     

    You sure can.  Just hold down the middle mouse button and you can pan the

    display arbitrarily in both dimensions at once.  Very nice, intuitive, and

    quick.  I use this a lot.

    --

    Web access to CadSoft support forums at www.eaglecentral.ca.  Where the CadSoft EAGLE community meets.

     

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
Reply
  • e14 Contributor
    e14 Contributor over 14 years ago

    Element 14 User wrote on Wed, 09 November 2011 12:54

    As I just finished my first (small) project in Eagle, I want to express

    some thoughts on how the program could be improved,

     

    At least you didn't come here ranting and raving, especially without having

    learned at least some of Eagle.  We do get that a lot here.

     

    I can see the point behind some of your statements, but others make it

    clear you are unaware of some Eagle features.

     

    Quote:

    the user interface is non-standard by any of today's GUI standards, be

    it Windows, Mac or Linux.

     

    That may be true, but keep in mind that Eagle started a long time ago

    before there was any consensus on such conventions, and it grew up on

    Windows.  MAC users are a small minority.

     

    Quote:

    The library management system is a complete torture.

     

    I'm not sure what you mean by "library management".  Think of the supplied

    Eagle libraries as either toys for hobbyists or examples at best.  Serious

    users make their own libraries.  I'm not sure what exactly there is to

    "manage", but I guess I haven't run into it maybe because I've made all my

    own libraries.

     

    Quote:

    1. This one must be written in bold letters: elimination of the "MOVE"

    command (button). This should be replaced with the default state of the

    GUI,

     

    I don't fully understand.  Clearly eliminating the MOVE command makes no

    sense.  Things still need to be moved and other operations performed, so

    the real question is when the MOVE command should be active.  I guess what

    you're saying is that you want MOVE to become active whenever any other

    command is unambiguously ended?  Hmm, I suppose that could be possible, but

    the unambiguously ending part sounds like it would be difficult or

    impossible in many instances.  If I start a ROUTE command, for example, I

    don't want to have to explicitly start routing again after completing a

    route.  Usually you do a bunch of routes in sequence, so this modal concept

    makes sense.

     

    Part of the problem appears to be you are not aware of the hot key

    capability, or haven't set it up usefully.  I use F7 as a shortcut for

    MOVE, so starting a move when I'm not already in MOVE is trivial and not a

    problem for me.

     

    Quote:

    that should be reached by clicking a button represented normally by an

    arrow (standard for most drawing programs). In this state, it should be

    possible to click on an object, be it a part, a text, a pad, a line, etc.

    and move it by acting on the mouse.

     

    Isn't that exactly how it already works?  It certainly does when starting

    MOVE by command or hot key.  I don't use the clickety-click tool buttons

    because a hot key or typing a command is so much faster, but I'd be real

    surprised if clicking whatever the move tool button is doesn't do exactly

    what you ask.

     

    Quote:

    It is important that the shortcuts should work without modifier keys

    (i.e. CTRL, ALT, CMD, SHIFT), therefore a solution must be found for the

    CLI.

     

    You seem to not be aware that the function keys can be mapped to arbitrary

    command strings.  Do you really need more than 12 things you can do with a

    single keystroke without modifiers?  I have most of the F keys bare, shift,

    and ctrl mapped to various commands.  The ones that require modifiers are

    only a tiny bit more to type, and it sortof happens automatically without

    concious thought once you get used to it anyway.  It seems like 12 single

    keystroke commands, and 24 more with a single modifier is a decent amount.

     

    Quote:

    Eliminate the CLI from the GUI,

     

    NO, NO, NO and NO again!!!

     

    The fact that everything is a command leads to much of what is powerful and

    great about Eagle.  Just because some people don't want to use it for some

    reason doesn't change the fact that it's very powerful and useful.  Once

    you get good at it, you'll see it speeds up your workflow more than any

    fancy mouse interactions can.  This is inherent to mouse movements

    requiring eye-hand coordination that require concious thought, versus

    typing which eventually gets done a bit below the concious level once you

    get good at it.  Even when it doesn't take less time, the fact that it's

    partly done sub-conciously makes it at least feel like it takes less time,

    probably because you can be thinking about something else while your

    fingers are performing the mechanics of the command you thought about a few

    100 milliseconds earlier.

     

    Unfortunately too many people are unwilling to get good at the command line

    and therefore can't get the full power from it, and therefore bash it when

    in fact it's one of the really powerful things about Eagle that sets it

    apart from other software.  A pure clickety-click interface may be easy to

    use and cute at first, but it gets tiresome quickly.  Unfortunately, too

    many people can't seem to get past the instant gratification phase.  That

    doesn't make the command line less powerful though.

     

    Quote:

    or at least allow it to be hidden (this should be the default).

     

    NO again!  The value of the command line is greatly diminished if it isn't

    always there.  If there is ever a option to hide it, that must be a

    concious deliberate act so that it doesn't happen accidentally.

     

    Quote:

    I spent quite some time reading the forum and I noticed that there are

    a couple of die-hard users that would rather get rid of one of their

    fingers than of the CLI.

     

    You'll find a lot of Eagle power users like that.  Don't try to take away

    the power user tools just because you haven't become one yet.  Someday you

    may get there and then wish you could have them back.

     

    Quote:

    However, they are a small minority.

     

    I don't know how you think you know this, but I seriously doubt that it

    true among long time Eagle users and power users.

     

    Quote:

    Rotate should be implemented through a simple key (user-programmable):

    as long as an object is selected, pressing a key without modifiers (e.g.

    "R") should perform the rotation. And still better: "SHIFT+R" should

    rotate the part in 45 degrees increments, while "ALT+R" in one-degree

    increments.

     

    You really need to read up on the ASSIGN command.

     

    Quote:

    Operations performed on multiple objects are sorely missing

     

    No, they generally aren't.  I think you're missing the GROUP command.  Once

    you define a group, for the most part you can apply commands to it and they

    effect all the objects in the group.

     

    Quote:

    (maybe they are possible within the CLI, but this is not the point).

     

    There will always be complicated things that can't be reasonably described

    with clickety-clicking or a few commands.  This is where ULPs and the

    command language make Eagle so powerful.  By writing a ULP or sometimes

    external program that writes a command script, you can do some really

    complicated things in a automated way.  For example, I have external

    programs that write scripts for repetitively placing pads of IC packages.

    There are too many intricacies and special cases to build something like

    this into Eagle, but it's not hard at all to write a program to do these

    strange operations.

     

    Quote:

    For instance, there are no ways (or at least I've found none) to change

    at once one or more characteristics of all pins in a package (library

    edit), or to change the width of a set of lines, or the parameters of

    several vias.

     

    Again, it sounds like you are unaware of GROUP.

     

    Quote:

    The total confusion surrounding the cut/copy/paste operations (largely

    discussed elsewhere on the forum).

     

    Yes, there are some rather poor choices for command names in Eagle.  But

    note these are naming issues only.  The actual operation of the commands if

    they were properly named are usually reasonable enough.

     

    For example, in Eagle you just have to learn that CUT does a COPY, and COPY

    rarely does anything you actually want.  In a schematic, WIRE is used to

    draw lines except when those lines represent wires, then you have to use

    NET.  In a board WIRE draws lines except when they are wires, then you use

    ROUTE.

     

    Quote:

    Another strange thing is that after the initial start, if you resize a

    schematic or layout editor window its content is also resized.

     

    That's not strange, that's exactly how it should be.  You generally want to

    work with the schematic page, for example, as large as possible in the

    window.

     

    Quote:

    Thus it's impossible to scroll, simply because there are no scroll bars

    unless you zoom in.

     

    Panning and zooming in Eagle is much nicer than using scroll bars.  You

    simply hold the middle mouse button down and everything pans as if it were

    attached to the pointer.  This is about as intuitive and simple as it gets.

    The scroll wheel zooms in and out, and of course you can set up hot keys

    to zoom in and out relative or go back to best fit or whatever.  I like the

    way this works much better than other programs that use scroll bars.  Not

    only do the scroll bars use up pixels better spent on higher resolution,

    but to use them you have to move to the edge of the window then back when

    you finally got the display where you want it.  No thanks.

     

    Quote:

    There are serious issues with the mouse and display, at least on the

    Mac version: sometimes when scrolling the drawing is only partially

    redrawn.

     

    I've never seen this on Windows 2000 or Windows XP.  It sounds like a bug.

     

    Quote:

    due to the proprietary mouse control implementation, I can't scroll

    left/right,

     

    You sure can.  Just hold down the middle mouse button and you can pan the

    display arbitrarily in both dimensions at once.  Very nice, intuitive, and

    quick.  I use this a lot.

    --

    Web access to CadSoft support forums at www.eaglecentral.ca.  Where the CadSoft EAGLE community meets.

     

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
Children
No Data
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2026 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

Follow element14

  • X
  • Facebook
  • linkedin
  • YouTube