Skip navigation

community

610 Views 13 Replies Latest reply: Feb 9, 2012 2:15 AM by Petteri Matilainen RSS
Currently Being Moderated

Oct 9, 2011 5:17 PM

A few (dozen) specific requests for version 6

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

 

Attributes

  • Currently Being Moderated
    2. Oct 11, 2011 11:59 AM (in response to KE5FX)
    Re: A few (dozen) specific requests for version 6

    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

     

  • 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

     

     

     

  • Currently Being Moderated
    5. Oct 12, 2011 1:07 AM (in response to KE5FX)
    Re: A few (dozen) specific requests for version 6

    Am 12.10.2011 03:02, schrieb John Miles:

    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.

     

     

     

    You know that you can hide airwires of certain signals?

    Check the HELP for RATSNEST.

     

      RATSNEST ! GND VCC

    hides all GND and VCC airwires.

     

      RATSNEST ! * GND

     

    shows nothing except GND.

     

     

     

    --

    Mit freundlichen Gruessen / Best regards

    Richard Hammerl

      CadSoft Support -- hotline@cadsoft.de

      FAQ: http://www.cadsoft.de/training/faq/

     

     

  • Currently Being Moderated
    6. Oct 12, 2011 1:32 AM (in response to Richard_H)
    Re: A few (dozen) specific requests for version 6

     

    "Richard Hammerl" <ric@cadsoft.de> wrote in message

    news:j73ar9$ftt$1@cheetah.cadsoft.de...

     

    You know that you can hide airwires of certain signals?

    Check the HELP for RATSNEST.

     

    RATSNEST ! GND VCC

    hides all GND and VCC airwires.

     

    RATSNEST ! * GND

     

    shows nothing except GND.

     

    if the airwires of a certain netclass could be hidden, then John Miles would

    be happy.

     

     

     

  • Currently Being Moderated
    7. Oct 12, 2011 2:03 AM (in response to KE5FX)
    Re: A few (dozen) specific requests for version 6

    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!

     

  • Currently Being Moderated
    8. Oct 12, 2011 8:42 AM (in response to KE5FX)
    Re: A few (dozen) specific requests for version 6

    Am 12.10.2011 03:02, schrieb John Miles:

    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.

     

    Ah, THAT's the problem. EAGLE parses the command line from left to

    right. Therefore, it FIRST changes the grid to 1.27 of the CURRENT grid

    unit, and AFTERWARDS changes the unit to mm, keeping the grid distance.

    That's somehow logical, but obviously not what one expects from scratch.

     

    The whole things works as expected (and as you want) if you change the

    order of things:

       GRID mm 1.27;

     

    Andreas Weidner

     

  • 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

     

     

     

  •  

    "Warren Brayshaw" <warrenbrayshaw@paradise.net.nz> wrote in message

    news:j74r22$pp3$1@cheetah.cadsoft.de...

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

     

     

    a perfect solution would be to use a "project's library". Any edited part

    would be stored only here, will be used only in this project (unless you

    copy-it to other project), and will not change any other finished project

    that use that component from that library.

     

    PS: I doubt someone will listen (and I allready see Olin preparing an acid

    answer to this proposal)

     

     

     

  • Andreas Weidner wrote:

    >Am 12.10.2011 03:02, schrieb John Miles:

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

    >Ah, THAT's the problem. EAGLE parses the command line from left to

    >right. Therefore, it FIRST changes the grid to 1.27 of the CURRENT grid

    >unit, and AFTERWARDS changes the unit to mm, keeping the grid distance.

    >That's somehow logical, but obviously not what one expects from scratch.

    >The whole things works as expected (and as you want) if you change the

    >order of things:

      GRID mm 1.27;

     

    or if there is no whitespace between the value and the unit?

    --

     

    Lorenz

     

  • Currently Being Moderated
    13. Feb 9, 2012 2:15 AM (in response to KE5FX)
    Re: A few (dozen) specific requests for v ersion 6

    A few feature requests that have been since v5.x. Now using v6.1, Windows

    XP SP3.

     

    1. Library editor:

     

    a) The grid settings should be remembered. Now every time I open a symbol

    or a package in the same library the grid settings are back to default.

     

    b) Only way to stop the Pin command is the stop button. Esc does nothing.

     

    c) The Edit device/package/symbol window behaviour should be: when

    selecting an existing symbol/package/device the name should come up in the

    text field so when creating a number of symbols/devices/packages that have

    almost the same name the user wouldn't have to type the entire name every

    time. Of course there are copy and paste but this would be much nicer

    feature.

    --

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

     

Related Content


Related Products
Discussions
  • Retrieving data ...

Bookmarked By (0)