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

    Some comments to some of your suggestions.,

     

    John Miles <jmiles@pop.net> wrote:

     

    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.

     

    Yes please. If version control some day gets built in, an indicator telling

    that the local file is different from the last comitted would also

    be nice.

     

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

    on the top or bottom layers to be hidden.

     

    How about an option to hide or color airwires that is drawn between

    wires/pads on hidden layers?

     

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

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

     

    I'd like to see classes improved so we could do more advanced rules for one

    class only. Today its all or none.

     

    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.

     

    I never use smash. In fact I never use silkscreen and prefer a pdf that can

    be searched. On schematics I always make space for the default positions.

     

    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.

     

    Ive missed that function!

     

    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.

     

    Missed that too!

     

    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.

     

    Sometimes I wished for the layer changes to be a stack with several "last"

    levels.

     

    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.

     

    Yes pls

     

    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?

     

    Current value is what I prefer. But in the case the component value was

    overridden by the lib default (for those with value not set to 'used'), I

    would prefet to see the original value too. Maybe with a requester

    presenting a textbox with current value and a reset button to use lib

    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.

     

    I guess this is just a case of making it visible in the GUI.

     

    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.

     

    I see a potential for mess up here. Maybe it could work on the lib

    currently open in the lib editor?

     

    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.

     

    Also an Eagle viewer only would be nice. I dont want unskilled viewers to

    mess up my designs. And the manufacturer could use it to get detailed

    information without having to buy a license or call us for every simple

    question.

    Also a simple passwd lock of the design would be nice.

     

    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.

     

    Im mot sure how, but Id like to see changes for sure.

     

    22) Silkscreen width should be checkable by DRC.

     

    I guess the CAM has some warnings on that?

     

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

     

    Yes, Yes and Yes!

     

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

    Some comments to some of your suggestions.,

     

    John Miles <jmiles@pop.net> wrote:

     

    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.

     

    Yes please. If version control some day gets built in, an indicator telling

    that the local file is different from the last comitted would also

    be nice.

     

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

    on the top or bottom layers to be hidden.

     

    How about an option to hide or color airwires that is drawn between

    wires/pads on hidden layers?

     

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

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

     

    I'd like to see classes improved so we could do more advanced rules for one

    class only. Today its all or none.

     

    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.

     

    I never use smash. In fact I never use silkscreen and prefer a pdf that can

    be searched. On schematics I always make space for the default positions.

     

    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.

     

    Ive missed that function!

     

    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.

     

    Missed that too!

     

    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.

     

    Sometimes I wished for the layer changes to be a stack with several "last"

    levels.

     

    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.

     

    Yes pls

     

    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?

     

    Current value is what I prefer. But in the case the component value was

    overridden by the lib default (for those with value not set to 'used'), I

    would prefet to see the original value too. Maybe with a requester

    presenting a textbox with current value and a reset button to use lib

    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.

     

    I guess this is just a case of making it visible in the GUI.

     

    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.

     

    I see a potential for mess up here. Maybe it could work on the lib

    currently open in the lib editor?

     

    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.

     

    Also an Eagle viewer only would be nice. I dont want unskilled viewers to

    mess up my designs. And the manufacturer could use it to get detailed

    information without having to buy a license or call us for every simple

    question.

    Also a simple passwd lock of the design would be nice.

     

    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.

     

    Im mot sure how, but Id like to see changes for sure.

     

    22) Silkscreen width should be checkable by DRC.

     

    I guess the CAM has some warnings on that?

     

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

     

    Yes, Yes and Yes!

     

    • 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

    John Miles <jmiles@pop.net> wrote:

    Morten Leikvoll replied:

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

     

    I see a potential for mess up here. Maybe it could work on the lib

    currently open in the lib editor?

     

     

    Currently if you have the a library name repeated in more than one place in

    your paths it's the first match that gets used. I would like to see all

    paths searched when attempting a library match and if there are two or more

    matches then you are alerted and choose the library of interest.

     

    I would be useful to also get this warning upon initially saving a new

    library so you do not inadvertantly  create one with the same name.

     

    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