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 2446 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

    On 11/9/2011 12:54 PM, Lix Paulian wrote:

    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: "SHIFTR" should rotate the part in 45 degrees increments, while "ALTR" 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 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 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 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, 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: "SHIFTR" should rotate the part in 45 degrees increments, while "ALTR" 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 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. 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 at this level would help increase Eagle's market share.

     

    Since 1984 when the first GUI becomes 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

     

    >

    >

     

    Hi Lix,

     

    I thought I would chime in on this one, and for full disclosure I do

    work for Cadsoft, however my opinions do not in any way reflect those of

    Cadsoft or Newark.

     

    Welcome to the forum, I've read a few of your other posts but I don't

    believe anyone has given you a formal welcome, I look forward to seeing

    more from you.

     

    Doing support I find that many of the points you mentioned are the one's

    that always come up with new users especially if they have previous

    experience with other PCB software. When you have a notion of how PCB

    systems in general work you tend to expect that with any new PCB

    software you run into, and as you've noticed EAGLE breaks the mold in

    several respects. However, I thought it would be good to go over some of

    the reasoning behind why EAGLE behaves the way it does.

     

    Most users are use to selecting the object, right clicking and then

    left-cliking the option they want to perform on the object. As I'm sure

    you've noticed EAGLE is 180 the other way around, you first select the

    action you want to perform then you left click on the item to perform it

    on. Now, why?

     

    In the normal scheme it takes 3 clicks to modify a single object, so for

    n objects we have 3n clicks. In EAGLE's scheme you have one initial

    click to select the action and then n clicks to modify n objects. So we

    have 3n clicks versus n+1 clicks. Efficiency wise this is a huge gain

    imagine a large design with hundred's of components and you'll realize

    why EAGLE is known for being a tool that can generate protype designs

    quickly. This is why suggestions one and three will probably never be

    implemented in EAGLE, it would break the working paradigm. Few users,

    ever realize this improvement in efficiency because they are so use to

    the "Windows" or standard way. I think you'll find that most of the GUI

    deviations are a direct result of this difference in paradigm.

     

    The cut/copy/paste functionality has been corrected for V6 copy now

    works as most users would expect, so that long standing annoyance has

    been resolved.

     

    When modifying groups of objects use the group command to select the

    parts you want to modify, click on the change command to set whatever

    change you want to perform to the group and then right-click in the

    middle of the group, left-click Change:Group and the changes will be

    applied to all of the selected objects. This is the GUI way, there are

    faster methods available.

     

    I have to disagree on your comments about the command line and why you

    are so adamant about it's removal from EAGLE. It really takes up very

    little screen real estate so it would be easy to ignore. How would you

    precisely place a component without a CLI in other words how would you

    specify x, y coordinates? In a dense schematic how would you search for

    a specific part without using the show @ operator? EAGLE has overtime

    given the users more GUI options in version 5 you can work with a

    context menu by simply right-clicking on a component and then

    left-clicking on the action you want to perform, which is pretty much

    the way everyone is used to working.

     

    For library management, I think now is a good time to introduce some

    ulps which you may find helpful. Many users have had the same idea so

    they've written ULPs to make things easier.

     

    - EAGLE comes with make-symbol-device-package-bsdl.ulp which takes a

    bsdl file and creates a complete device from it, very handy when making

    high-pin count components.

    - Many of the del-x ulps included with EAGLE can be useful for cleaning

    up the libraries.

    - The libedit.ulp addresses many of the issues you mentioned with the

    library management system in EAGLE. Obviously it would be better to

    implement some of these features into EAGLE itself but their are other

    features that are higher-up on the wishlist.

     

    I believe, I've written way too much. If you have any issues or

    questions about how a given operation feel free to send me an e-mail to

    support@cadsoftusa.com and I'll be happy to help.

     

    hth,

    Jorge Garcia

     

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

    Am 09.11.2011 21:26, schrieb Jorge Garcia:

    On 11/9/2011 12:54 PM, Lix Paulian wrote:

    >> "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

    I have to disagree on your comments about the command line and why you

    are so adamant about it's removal from EAGLE. It really takes up very

    little screen real estate so it would be easy to ignore. How would you

    precisely place a component without a CLI in other words how would you

    specify x, y coordinates? In a dense schematic how would you search for

    a specific part without using the show @ operator? EAGLE has overtime

    given the users more GUI options in version 5 you can work with a

    context menu by simply right-clicking on a component and then

    left-clicking on the action you want to perform, which is pretty much

    the way everyone is used to working.

    I agree with Lix on this (and most of his other points).

    The problem is not the screen real estate, but the fact that the current

    implementation stops you from using efficient one-key shorcuts.

    We had such threads earlies this year. My suggestion would be to

    give the input focus to the CLI when the user hits enter and to

    remove it again if he presses Enter in the empty CLI.

     

     

    A general comment about the CLI:

    It's nice to have it, but all standard actions should be covered

    by the GUI.

     

     

    Regards,

     

    Dietmar

     

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

    Dietmar Schwertberger wrote on Wed, 09 November 2011 15:51

    The problem is not the screen real estate, but the fact that the

    current

    implementation stops you from using efficient one-key shorcuts.

     

    You have the 12 function keys for single keystroke shortcuts.  Isn't that

    enough?  And of course there is a lot more with the trivial addition of

    shift or control.

     

    Quote:

    My suggestion would be to give the input focus to the CLI when the user

    hits enter and to

    remove it again if he presses Enter in the empty CLI.

     

    NO!!!  The command line must always be ready for typing else it's full

    power is diminished.

     

    Quote:

    A general comment about the CLI: It's nice to have it, but all standard

    actions should be covered by the GUI.

     

    You simply can't cover all actions with a GUI, like entering specific

    coordinates.  That happens a lot when making packages, for example.  Once

    you get good at the command line you'll find it's faster and requires less

    thought than the GUI.

    --

    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
  • e14 Contributor
    e14 Contributor over 14 years ago in reply to e14 Contributor

    Dietmar Schwertberger wrote on Wed, 09 November 2011 16:40

    "Efficient" means that the shortcuts can e.g. be

      - used with a single hand (left hand for people who use the mouse

    with

        their right hand) -> only 6 out of 12 function keys left

     

    Actually on my keyboard they are in 3 groups of 4.  In any case, it's easy

    enough to hit any of them with the left hand.  I do this routinely.

     

    Quote:

    - used without searching -> no function keys

     

    Huh?  The function keys are right there on the keyboard.  There is nothing

    to search for.

     

    Quote:

    - easily remembered -> letters, no function keys; with some exceptions

        (e.g. F5 for Ratsnest, as this is quite similar to the common use

         of F5 in other software).

     

    It doesn't take long at all to remember which function key to use for a

    particular command.  This is really very easy and comes without

    deliberately trying, just like you already learned F5 is RATSNEST in your

    setup.

     

    In fact, it takes little time before this goes another step.  Your fingers

    just know what to do without you having to conciously remembering exactly

    which key is which.  For example, I have ALT-F2 set up to do a best fit

    into the current window.  I just think "best fit" and the fingers

    automatically do the ALT-F2 without further thought.  I actually had to go

    thru the motion just now to see which key it was since I don't conciously

    remember the key name.  This is just like typing most other keys.  When you

    type "the", you don't think about the placement of the T, H and E keys

    individually.  The same thing will apply itself automatically to function

    keys with a little practise, which comes pretty quickly since you'd be

    mapping the common commands to the function keys.

     

    Once again, don't try to take away power user features just because you

    haven't gotten there.  And, you'd get there pretty quickly if you just

    stopped trying to fight it.

    --

    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
  • e14 Contributor
    e14 Contributor over 14 years ago in reply to e14 Contributor

    Am 09.11.2011 22:02, schrieb Olin Lathrop:

    Dietmar Schwertberger wrote on Wed, 09 November 2011 15:51

    >> The problem is not the screen real estate, but the fact that the

    >> current

    >> implementation stops you from using efficient one-key shorcuts.

     

    You have the 12 function keys for single keystroke shortcuts.  Isn't that

    enough?  And of course there is a lot more with the trivial addition of

    shift or control.

    "Efficient" means that the shortcuts can e.g. be

      - used with a single hand (left hand for people who use the mouse with

        their right hand) -> only 6 out of 12 function keys left

      - used without searching -> no function keys

      - easily remembered -> letters, no function keys; with some exceptions

        (e.g. F5 for Ratsnest, as this is quite similar to the common use

         of F5 in other software).

    Function keys are OK for rarely used functions, but not e.g. for MOVE,

    COPY, SIGNAL, ROUTE, RIPUP etc.

     

     

    Regards,

     

    Dietmar

     

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

    Am 09.11.2011 22:02, schrieb Olin Lathrop:

    Dietmar Schwertberger wrote on Wed, 09 November 2011 15:51

    >> The problem is not the screen real estate, but the fact that the

    >> current

    >> implementation stops you from using efficient one-key shorcuts.

     

    You have the 12 function keys for single keystroke shortcuts.  Isn't that

    enough?  And of course there is a lot more with the trivial addition of

    shift or control.

    "Efficient" means that the shortcuts can e.g. be

      - used with a single hand (left hand for people who use the mouse with

        their right hand) -> only 6 out of 12 function keys left

      - used without searching -> no function keys

      - easily remembered -> letters, no function keys; with some exceptions

        (e.g. F5 for Ratsnest, as this is quite similar to the common use

         of F5 in other software).

    Function keys are OK for rarely used functions, but not e.g. for MOVE,

    COPY, SIGNAL, ROUTE, RIPUP etc.

     

     

    Regards,

     

    Dietmar

     

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

    Dietmar Schwertberger wrote on Wed, 09 November 2011 16:40

    "Efficient" means that the shortcuts can e.g. be

      - used with a single hand (left hand for people who use the mouse

    with

        their right hand) -> only 6 out of 12 function keys left

     

    Actually on my keyboard they are in 3 groups of 4.  In any case, it's easy

    enough to hit any of them with the left hand.  I do this routinely.

     

    Quote:

    - used without searching -> no function keys

     

    Huh?  The function keys are right there on the keyboard.  There is nothing

    to search for.

     

    Quote:

    - easily remembered -> letters, no function keys; with some exceptions

        (e.g. F5 for Ratsnest, as this is quite similar to the common use

         of F5 in other software).

     

    It doesn't take long at all to remember which function key to use for a

    particular command.  This is really very easy and comes without

    deliberately trying, just like you already learned F5 is RATSNEST in your

    setup.

     

    In fact, it takes little time before this goes another step.  Your fingers

    just know what to do without you having to conciously remembering exactly

    which key is which.  For example, I have ALT-F2 set up to do a best fit

    into the current window.  I just think "best fit" and the fingers

    automatically do the ALT-F2 without further thought.  I actually had to go

    thru the motion just now to see which key it was since I don't conciously

    remember the key name.  This is just like typing most other keys.  When you

    type "the", you don't think about the placement of the T, H and E keys

    individually.  The same thing will apply itself automatically to function

    keys with a little practise, which comes pretty quickly since you'd be

    mapping the common commands to the function keys.

     

    Once again, don't try to take away power user features just because you

    haven't gotten there.  And, you'd get there pretty quickly if you just

    stopped trying to fight it.

    --

    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
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