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 few (dozen) specific requests for version 6
  • 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 13 replies
  • Subscribers 189 subscribers
  • Views 1154 views
  • Users 0 members are here
Related

A few (dozen) specific requests for version 6

KE5FX
KE5FX over 14 years ago

Some of these may be redundant with others' wishlists, but I'll mention

them anyway to lend my support.

 

1) Undo/redo functionality would be more effective if there were a way

to see the 'stack' of the last few commands.  To make this happen, all

commands that can actually alter the board, schematic, or library data

should generate an acknowledgement message in the status line as well as

an entry on the 'stack.'

 

Essentially, it should always be clear what an undo or redo command will

actually undo or redo.  Most people have probably seen the

"Schematic/board not saved.  Save?" prompt when exiting EAGLE after

being away from their PC for a few hours, and quite a few of us have

been left wondering exactly what we did before our attention-deficit

disorder kicked in.

 

2) It'd be nice to have a visual indication of whether or not the board

or schematic has been changed since the last save.  Many editors put an

asterisk next to the window title, or use some similar indicator.

 

3) Consider using tUnrouted / bUnrouted layers to allow airwires

entirely on the top or bottom layers to be hidden.

 

4) Net classes need to have user-specifiable colors associated with

them... ideally for both traces and airwires, but at least for the latter.

 

5) The MARK command should be persistent.  No real purpose is served by

toggling back to the previous command after a MARK, since users often

need to move the reference mark around multiple times if they're using

that command at all.  In general, the fact that some commmands are

'sticky' while others are not is more confusing/distracting than helpful.

 

6) If a part has been smashed, it might be nice if clicking on any

silkscreen associated with it would select the tName instead of the part

itself.  This would help avoid the "hunt the '+'" problem familiar to

anyone who has worked with a crowded board layout full of smashed parts.

 

6a) Along those lines I agree with those who argue that the smashed

state should be the default.  I can't remember the last time I used an

unsmashed part.  At least make this a user preference.

 

7) Failing that, when the MOVE command is active, at least highlight all

the '+' markers associated with smashed parts.  It's frustrating to move

silkscreen labels around in a dense layout because you always tend to

select the part instead of the labels unless you remembered to lock the

parts down or deselect the tOrigins/bOrigins layers.

 

8) Allow groups to be moved to explicit coordinates, just as individual

parts can be.  (Perhaps this is already supported and I've missed it.)

 

9) When dragging a part, group, or trace, allow SHIFT to be held down to

constrain the motion to the first direction of movement.  This is a very

common feature in graphical editors of all sorts, and would save a lot

of grid manipulation.

 

10) Allow multiple arguments for commands such as MOVE.  When doing

initial parts placement on a new board, it'd be nice if I could say

"MOVE R1, R2, R4, R5" to pull in a whole stack of related components at

once.

 

11) The 'Cancel' button in the DISPLAY dialog should restore the layer

selection that was active when the dialog was first called up.  The way

it works now, what's the difference between hitting 'OK' and 'Cancel'?

In both cases the current layer selection will be kept.

 

12) In general layer selection is a weak point of the UI.  If it could

be made completely modeless without conflicting with the 'stack'

suggestion above, that would be a big improvement.

 

13) When changing the name of a part on a schematic, don't just tell me

that the new name "Already exists" -- give me the option to swap names

with the conflicting part.  Same with pad names in the package editor.

 

14) Pulldowns for user grid and layer aliases should have check marks

for the current selection, if the current grid or layer configuration

still corresponds to the last selected alias.

 

15) It should be possible to press CTRL to snap a MOVE target to the

nearest grid location at any time while the command is in progress, not

just when the move is initiated.

 

16) Don't try to convert between units in the GRID dialog, or at least

make it possible to disable this behavior with a user preference.  When

switching between metric and English units, it seems I have to issue

every GRID command twice... once to set the unit, and again to override

the ridiculous value EAGLE adopts when it tries to interpret my new

value in the old unit or vice versa.

 

17) The default value for the VALUE command should be the previous

entered value, not the component's current value.  The current value is

the one value that is known not to be desired, so why use it as the

default?

 

18) Along the same lines, consider adding VALUE to the options

accessible via the CHANGE command.  This would make it easier to assign

a new value to multiple components.

 

19) It might be nice to offer a compiled version for x64 editions of

Windows and other 64-bit OSes.  This buys you an extra 10% or so of

speed for no real work, assuming your dependencies are all available in

64-bit versions.

 

20) "Edit device in library" and "Edit package in library" should be

available on the right-click context menus in the schematic and board

editors.

 

21) If there's a way to run multiple copies of EAGLE at once without

trampling eaglerc.usr and any other configuration files, it would be

appreciated.  It's frustrating to lose a lot of custom ASSIGNs and

aliases because you forgot to exit from another instance that was only

launched to refer to another board layout.

 

I'd suggest keeping assignments and aliases in a separate file alongside

eaglerc.usr that is not overwritten except when its contents change.

This would also have the advantage of not losing assignments and aliases

just because the user didn't save the .brd/.sch that was open at the time.

 

22) Silkscreen width should be checkable by DRC.

 

23) DRC should also report the current airwire count, a la RATSNEST.

 

24) The default selection when the four-way arrow cursor is used to

choose from objects on multiple layers beneath the mouse cursor should

be the object on the last selected layer, since 99% of the time that is

what the user will want.

 

25) Pressing ESC should terminate the VIA command, as it does with most

other commands.  Right now the only way to terminate the VIA command

appears to be to reach all the way up to the Stop icon on the toolbar.

 

26) When drawing a rectangle, show the size of the rectangle alongside

the current cursor position.

 

27) One thing that tripped me up recently is your use of the $HOME

environment variable.  My (Windows 7) system didn't originally have a

HOME environment variable until I installed the msysgit package the

other day.  At that point, EAGLE appeared to "forget" all of my aliases,

assignments, and UI preferences.  I eventually realized that when the

HOME variable appeared courtesy of msysgit, EAGLE created a new

eaglerc.usr in $HOME\eagle (users\johnm\eagle) and forgot about the one

in users\johnm.  Suggest either not using $HOME at all, or ensuring that

it is created during installation if it doesn't already exist.

 

...

 

It may not be apparent from this huge list of nitpicks, but I actually

really enjoyed using 5.11.0 on a large-scale project recently, coming

back to EAGLE for the first time in a couple of years.  There were

absolutely no crashes or instances of data loss, and the new

alpha-blending renderer introduced with V5 worked way better than I

thought it would.  Thanks for your hard work on V5 and for your

consideration of these requests.

 

-- john, KE5FX

 

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

    Am 10.10.2011 00:17, schrieb John Miles:

    3) Consider using tUnrouted / bUnrouted layers to allow airwires

    entirely on the top or bottom layers to be hidden.

     

    Since it is unclear on which layer the user WANTS to route airwires, I

    don't see how the above suggestion could work properly: Even if an

    airwire goes from bottom to bottom, the user might want to create the

    copper connection at a completely different position from top to top -

    who knows? And what about airwires going from top to bottom, or even

    from some intermediate layer to another one? There are SO many

    possibilities...

     

    4) Net classes need to have user-specifiable colors associated with

    them... ideally for both traces and airwires, but at least for the latter.

     

    For the latter, that seems to be OK. For the former, the class colour

    might clash with the layer colour, so one could suddenly not distinguish

    LAYERS anymore. That seems to be worse than not being able to identify

    classes...

     

    8) Allow groups to be moved to explicit coordinates, just as individual

    parts can be. (Perhaps this is already supported and I've missed it.)

     

    Something similar CAN be done by

      - creating the group via the command line or mouse

      - and moving the group from explicit point to explicit point via

        command line or mouse.

    E.g.

      - group (0 0) (1 0) (1 1) (>0 1);

      - move (>0 0) (1 1);

     

    9) When dragging a part, group, or trace, allow SHIFT to be held down to

    constrain the motion to the first direction of movement. This is a very

    common feature in graphical editors of all sorts, and would save a lot

    of grid manipulation.

     

    Yes, that could be useful.

     

    11) The 'Cancel' button in the DISPLAY dialog should restore the layer

    selection that was active when the dialog was first called up. The way

    it works now, what's the difference between hitting 'OK' and 'Cancel'?

    In both cases the current layer selection will be kept.

     

    It already does that - at least in the current version of EAGLE (5.11.2).

     

    16) Don't try to convert between units in the GRID dialog, or at least

    make it possible to disable this behavior with a user preference. When

    switching between metric and English units, it seems I have to issue

    every GRID command twice... once to set the unit, and again to override

    the ridiculous value EAGLE adopts when it tries to interpret my new

    value in the old unit or vice versa.

     

    By just changing the grid UNIT, the grid DISTANCE should NOT change, so

    EAGLE's current behaviour seems to be very nice: VERY often, one works

    with the usual inch grid for creating a board, but when it comes to

    MEASURING mechanical positions, one wants them in millimetres. Just

    typing 'grid mm' will do that properly without disturbing the current grid.

     

    17) The default value for the VALUE command should be the previous

    entered value, not the component's current value. The current value is

    the one value that is known not to be desired, so why use it as the

    default?

     

    Sometimes one just wants to copy this value to the clipboard or look at

    it or whatever. Even if the user WANTS to change the value, it is NEVER

    known what the user wants to change the value INTO, so the current

    behaviour makes more sense to me. Your way, accidentally clicking the

    WRONG part would immediately put the wrong value into the dialog box,

    and one would not even SEE that one clicked on the wrong part...

     

    18) Along the same lines, consider adding VALUE to the options

    accessible via the CHANGE command. This would make it easier to assign a

    new value to multiple components.

     

    You can already do this:

      - value '100n' (click) (click) (click)...

    Type the desired value ONCE and click on the desired parts.

     

    23) DRC should also report the current airwire count, a la RATSNEST.

     

    Yes, please. That's another thing that belongs into the DRC and was

    already requested several times.

     

    As for the other points of your post, I don't really have a decent

    opinion on those subjects...

     

    Andreas Weidner

     

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

    Am 10.10.2011 00:17, schrieb John Miles:

    3) Consider using tUnrouted / bUnrouted layers to allow airwires

    entirely on the top or bottom layers to be hidden.

     

    Since it is unclear on which layer the user WANTS to route airwires, I

    don't see how the above suggestion could work properly: Even if an

    airwire goes from bottom to bottom, the user might want to create the

    copper connection at a completely different position from top to top -

    who knows? And what about airwires going from top to bottom, or even

    from some intermediate layer to another one? There are SO many

    possibilities...

     

    4) Net classes need to have user-specifiable colors associated with

    them... ideally for both traces and airwires, but at least for the latter.

     

    For the latter, that seems to be OK. For the former, the class colour

    might clash with the layer colour, so one could suddenly not distinguish

    LAYERS anymore. That seems to be worse than not being able to identify

    classes...

     

    8) Allow groups to be moved to explicit coordinates, just as individual

    parts can be. (Perhaps this is already supported and I've missed it.)

     

    Something similar CAN be done by

      - creating the group via the command line or mouse

      - and moving the group from explicit point to explicit point via

        command line or mouse.

    E.g.

      - group (0 0) (1 0) (1 1) (>0 1);

      - move (>0 0) (1 1);

     

    9) When dragging a part, group, or trace, allow SHIFT to be held down to

    constrain the motion to the first direction of movement. This is a very

    common feature in graphical editors of all sorts, and would save a lot

    of grid manipulation.

     

    Yes, that could be useful.

     

    11) The 'Cancel' button in the DISPLAY dialog should restore the layer

    selection that was active when the dialog was first called up. The way

    it works now, what's the difference between hitting 'OK' and 'Cancel'?

    In both cases the current layer selection will be kept.

     

    It already does that - at least in the current version of EAGLE (5.11.2).

     

    16) Don't try to convert between units in the GRID dialog, or at least

    make it possible to disable this behavior with a user preference. When

    switching between metric and English units, it seems I have to issue

    every GRID command twice... once to set the unit, and again to override

    the ridiculous value EAGLE adopts when it tries to interpret my new

    value in the old unit or vice versa.

     

    By just changing the grid UNIT, the grid DISTANCE should NOT change, so

    EAGLE's current behaviour seems to be very nice: VERY often, one works

    with the usual inch grid for creating a board, but when it comes to

    MEASURING mechanical positions, one wants them in millimetres. Just

    typing 'grid mm' will do that properly without disturbing the current grid.

     

    17) The default value for the VALUE command should be the previous

    entered value, not the component's current value. The current value is

    the one value that is known not to be desired, so why use it as the

    default?

     

    Sometimes one just wants to copy this value to the clipboard or look at

    it or whatever. Even if the user WANTS to change the value, it is NEVER

    known what the user wants to change the value INTO, so the current

    behaviour makes more sense to me. Your way, accidentally clicking the

    WRONG part would immediately put the wrong value into the dialog box,

    and one would not even SEE that one clicked on the wrong part...

     

    18) Along the same lines, consider adding VALUE to the options

    accessible via the CHANGE command. This would make it easier to assign a

    new value to multiple components.

     

    You can already do this:

      - value '100n' (click) (click) (click)...

    Type the desired value ONCE and click on the desired parts.

     

    23) DRC should also report the current airwire count, a la RATSNEST.

     

    Yes, please. That's another thing that belongs into the DRC and was

    already requested several times.

     

    As for the other points of your post, I don't really have a decent

    opinion on those subjects...

     

    Andreas Weidner

     

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

     

    >> 11) The 'Cancel' button in the DISPLAY dialog should restore the layer

    >> selection that was active when the dialog was first called up. The way

    >> it works now, what's the difference between hitting 'OK' and 'Cancel'?

    >> In both cases the current layer selection will be kept.

     

    It already does that - at least in the current version of EAGLE (5.11.2).

     

    Actually, no, it doesn't.  If you hit 'Apply', you lose the ability to

    revert your changes by hitting 'Cancel.'

     

    This is one of those UI quirks that seems like a real no-brainer to fix,

    like the GRID business, but maybe I'm missing something.

     

    -- john

     

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

    On 10/11/2011 9:59 AM, Andreas Weidner wrote:

    Am 10.10.2011 00:17, schrieb John Miles:

    >> 3) Consider using tUnrouted / bUnrouted layers to allow airwires

    >> entirely on the top or bottom layers to be hidden.

     

    Since it is unclear on which layer the user WANTS to route airwires, I

    don't see how the above suggestion could work properly: Even if an

    airwire goes from bottom to bottom, the user might want to create the

    copper connection at a completely different position from top to top -

    who knows? And what about airwires going from top to bottom, or even

    from some intermediate layer to another one? There are SO many

    possibilities...

     

    Mostly I'm fishing for a way to hide masses of airwires on the side of

    the board opposite to what I'm working on.  Most airwires don't end up

    crossing layers at all, so they're just in the way.

     

    That said, I agree there doesn't seem to be an obvious way to scratch

    this itch cleanly.  Not a huge deal.

     

    >> 11) The 'Cancel' button in the DISPLAY dialog should restore the layer

    >> selection that was active when the dialog was first called up. The way

    >> it works now, what's the difference between hitting 'OK' and 'Cancel'?

    >> In both cases the current layer selection will be kept.

     

    It already does that - at least in the current version of EAGLE (5.11.2).

     

    Cool.  Originally their plan was to refrain from posting any further

    betas beyond 5.11.0, so I haven't been checking...

     

    By just changing the grid UNIT, the grid DISTANCE should NOT change, so

    EAGLE's current behaviour seems to be very nice: VERY often, one works

    with the usual inch grid for creating a board, but when it comes to

    MEASURING mechanical positions, one wants them in millimetres. Just

    typing 'grid mm' will do that properly without disturbing the current grid.

     

    That's fine, but nothing else on the planet works the way the GRID

    command does now, when both a new unit and a new distance are specified.

      If I currently have a 0.005" grid and I type GRID 1.27 mm, it's

    ridiculous for EAGLE to interpret this as a request for a 32.258 mm grid.

     

    Sometimes one just wants to copy this value to the clipboard or look at

    it or whatever. Even if the user WANTS to change the value, it is NEVER

    known what the user wants to change the value INTO, so the current

    behaviour makes more sense to me. Your way, accidentally clicking the

    WRONG part would immediately put the wrong value into the dialog box,

    and one would not even SEE that one clicked on the wrong part...

     

    Perhaps, but if I want to see the current value, I'll generally turn on

    tValues/bValues.  If I'm modifying values, there's a good chance I want

    to do it repeatedly.  But your point below addresses this well.

     

    >> 18) Along the same lines, consider adding VALUE to the options

    >> accessible via the CHANGE command. This would make it easier to assign a

    >> new value to multiple components.

     

    You can already do this:

    - value '100n' (click) (click) (click)...

    Type the desired value ONCE and click on the desired parts.

     

    Ah, right you are!  That works.

     

    -- john

     

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

    John Miles wrote

    Andreas Weidner replied

     

     

    >> 9) When dragging a part, group, or trace, allow SHIFT to be held

    >> down to constrain the motion to the first direction of movement.

    >> This is a very common feature in graphical editors of all sorts, and

    >> would save a lot

    >> of grid manipulation.

     

    Yes, that could be useful.

     

     

    I would like this.  In MSPaint, if you hold down the shift key, lines

    (wires) are restrained to the orthagonals and this is very usful.

     

    Eagle should replicate this for drawing wires and moving all objects/groups

    or their points

     

    Warren

     

    --

    Viewed / responded via the newsgroup at

    news.cadsoft.de

     

     

     

    • 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