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

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

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.

Hi Daniel,

While I completly agree with you about the context-menu and everything

else you wrote, I couldn't disagree more on this point: there is no way

a GUI could ever support wildcards. Most of the eagle commands (sadly,

not all of them) support using wildcards to selectively modify certain

groups of objects. No GUI could ever beat that.

I beg to differ on this one, either I don't get the meaning of what "wildcards" in this context is, or you haven't seen how such a problem is solved with a GUI. With many graphic editors, one can select certain objects (or certain type of objects) and apply a transformation on all of them with one click. Is this not what you mean by "wildcard"? See also below, I believe it is in the same context.

Operations performed on multiple objects are sorely missing (maybe

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

 

you didn't find the GROUP command? It's in plain sight

Yes, I've even used it, but I guess we have different ideas about multiple selection. Please refer to the example I gave: how would you modify all pin lenghts of an IC with 24 pins using the GROUP command? Going further (and speaking about wildcards) I maintain that the GUI variant is more advanced than a CLI, in that using shift-click and cmd-click one can selectively add or remove objects in the selection before executing the command (delete, modify, etc.). That is, wildcards with exceptions. Do this with a CLI (grep/awk come to my mind, but I don't think Eagle's CLI is that advanced ;-).

Eagle supports tooltips, just hover the mouse over a GUI element to

show the name of the command. Strange you didn't find that, it's

standard on all GUIs.

Of course, but who ever look at tooltips? One simply clicks the button and it's done. Tooltips appear only after a delay.

simply because there are no scroll bars unless you zoom in. This

behavior is incorrect, the content's size must remain unchanged and

 

That's simply not true. There is no common standard about that. (Maybe

there should, but I wouldn't consider that as the biggest problem in

Eagle)

You're right, this is not a big problem with Eagle, but it is however true. Just start Eagle with a Schematic or Layout editor open and without zooming in, try to resize the window. When Eagle first opens a file, it displays it as "zoom all". As long as you don't zoom in, everytime you try to resize the editor window, the content will be also resized and no scroll bars will appear. After zooming in, everything is back to normal.

are you telling people that you want to use a CAD program with a

multi-touch display and your fingers? Without mouse? Without CLI?

Not only that, but I already do this! In this project I used the CLI only two or three times (after being exasperated with the CUT/DELETE buttons) and the mouse probably 30% of the time. Everything else I've done with the trackpad. If you would have told me this two years ago, I wouldn't believe it either. You get a feeling how far these multitouch trackpads came, only after using one for a while. There are many possible gestures and after a while they become so natural you do them automatically. Sadly, Eagle does not support many of them, beacause they by-passed the OS, otherwise all gestures would have been automagically supported (in particular I am missing the horizontal scroll and the zoom-in/out gestures).

Best regards,

Lix

Vom: Wed, 09 Nov 2011 17:54:41 GMT

Hi,

your post is a nice read. Let me share some thoughts about this:

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

I completly agree with this. Sadly, eagle lacks any form of API.

Personally I believe that someone would have created a better GUI (or

even multiple projects for different tastes) sitting on the Eagle core

if there only would be a way to do that. Even the original GUI could be

greatly improved by a decent plugin-interface (Strangely I seem to be

the only person asking for that, but lots of people complain about the

GUI)

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

While I completly agree with you about the context-menu and everything

else you wrote, I couldn't disagree more on this point: there is no way

a GUI could ever support wildcards. Most of the eagle commands (sadly,

not all of them) support using wildcards to selectively modify certain

groups of objects. No GUI could ever beat that.

And I really don't think the small CLI line hurts anyone in any way.

Of course, it also wouldn't hurt to introduce the possibility to hide

it, but it would prevent people from learning to use it. Imho, the only

efficient way to use CAD software is a mixture of gui and cli.

4.

Operations performed on multiple objects are sorely missing (maybe

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

you didn't find the GROUP command? It's in plain sight

manual, simply because I confused the CUT button with the DELETE

button (in this case indeed, the CLI saved me, because typing the

Eagle supports tooltips, just hover the mouse over a GUI element to

show the name of the command. Strange you didn't find that, it's

standard on all GUIs.

simply because there are no scroll bars unless you zoom in. This

behavior is incorrect, the content's size must remain unchanged and

That's simply not true. There is no common standard about that. (Maybe

there should, but I wouldn't consider that as the biggest problem in

Eagle)

only the scroll bars should be updated (if required). But again,

these side-effects are the result of not using the APIs provided by

I'm not 100% sure, but I think eagle uses the Qt libraries? (Someone

correct me if wrong, please)

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

are you telling people that you want to use a CAD program with a

multi-touch display and your fingers? Without mouse? Without CLI?

Anyway, a lot of the stuff you mentioned is true and I guess not easy

to solve. Personally I believe, that eagle has become a monolithic

code-monster over time and a new major release with minor changes

and a bit of lametta doesn't solve problems.

Instead, it should be cleaned and modularized according to "modern"

software-design principles. (But what do I know, you need to see

the code to really be able to judge that).

Using XML is a great step into that direction imo, but sadly it's the

only step. With well designed software, good GUI design is just a

matter of interfaces and "fast graphics output". For anything else you

don't even need a software-developer.

many regards