How to create library part with thermal pad?

On 4/4/2011 7:00 AM, Olin Lathrop wrote:

Klaus Schmidinger wrote on Mon, 04 April 2011 04:35

>> Well, I'm sorry I got into contact with the GED before I was

>> "contaminated" with Windows,

 

It's not a Windows thing.  The copy and cut convention was around well

before that.

 

Quote:

>> To get this recurring discussion over with once and for all I suggest

>> the following changes for version 6:

 

The current problem is one of naming, not of how the commands actually

work.  I think that changing anything now will cause too much pain to

people that have managed to get used to how it works, and more importantly

that have scripts and ULPs that rely on the existing names.

 

The fix is therefore documentation, not changing code.  There should be a

"Introduction to Eagle" section or something new users will find that

explains the various unobvious things about Eagle.  CUT doing just a COPY

should be prominently mentioned, and what COPY really does and when you'd

use that over CUT also needs to be made clear.  That would have saved me a

bunch of time back when I started.  (actually I'm still a little hazy about

when to use COPY versus CUT, although I haven't spent the time to

deliberately try and educate myself either)

 

I think the problem is not the functionality of the commands, it's the

misleading use of language to describe what they do. I agree that if

copy is renamed to "duplicate", it is consistent with other software and

obvious what it does. And cut then becomes copy, which would be

misleading except that in all other software, copy has a consistent

meaning of "place into paste buffer".

These command names in English predate Windows by many, many years. I

remember using a DEC CRT terminal (smart terminal) on a mainframe that

had local editing capability with a cut/copy/paste buffer in the 1980's.

Although "invoke" can be traced to the latin roots for "call in" ( which

is exactly what it does), the word invoke, in american english, can not

be used in this way. Changing the name to "Call Gates" or, even better,

"More Gates" or "Add Gates" would be a good start for a workable name

for this command. You could just leave the old "invoke" as well and not

tell anybody about it.

None of these changes have anything to do with experienced users, they

just clarify things for new users. It seems rather unprofessional to

have variances from accepted UI practice, /especially when it could be

done without them/. So, some of EAGLE's odd use of mouse controls is

much more acceptable, because it's not clear how it could be done with

the established UI model. But misleading names = sloppy software in the

new user's eyes.

Am 04.04.2011 21:58, schrieb Gary Gofstein:

On 4/4/2011 7:00 AM, Olin Lathrop wrote:

>> Klaus Schmidinger wrote on Mon, 04 April 2011 04:35

>>> Well, I'm sorry I got into contact with the GED before I was

>>> "contaminated" with Windows,

>>

>> It's not a Windows thing. The copy and cut convention was around well

>> before that.

>>

>> Quote:

>>> To get this recurring discussion over with once and for all I suggest

>>> the following changes for version 6:

>>

>> The current problem is one of naming, not of how the commands actually

>> work. I think that changing anything now will cause too much pain to

>> people that have managed to get used to how it works, and more

>> importantly

>> that have scripts and ULPs that rely on the existing names.

>>

>> The fix is therefore documentation, not changing code. There should be a

>> "Introduction to Eagle" section or something new users will find that

>> explains the various unobvious things about Eagle. CUT doing just a COPY

>> should be prominently mentioned, and what COPY really does and when you'd

>> use that over CUT also needs to be made clear. That would have saved me a

>> bunch of time back when I started. (actually I'm still a little hazy

>> about

>> when to use COPY versus CUT, although I haven't spent the time to

>> deliberately try and educate myself either)

>>

I think the problem is not the functionality of the commands, it's the

misleading use of language to describe what they do. I agree that if

copy is renamed to "duplicate", it is consistent with other software and

obvious what it does. And cut then becomes copy, which would be

misleading except that in all other software, copy has a consistent

meaning of "place into paste buffer".

 

These command names in English predate Windows by many, many years. I

remember using a DEC CRT terminal (smart terminal) on a mainframe that

had local editing capability with a cut/copy/paste buffer in the 1980's.

 

Although "invoke" can be traced to the latin roots for "call in" ( which

is exactly what it does), the word invoke, in american english, can not

be used in this way. Changing the name to "Call Gates" or, even better,

"More Gates" or "Add Gates" would be a good start for a workable name

for this command. You could just leave the old "invoke" as well and not

tell anybody about it.

 

None of these changes have anything to do with experienced users, they

just clarify things for new users. It seems rather unprofessional to

have variances from accepted UI practice, /especially when it could be

done without them/. So, some of EAGLE's odd use of mouse controls is

much more acceptable, because it's not clear how it could be done with

the established UI model. But misleading names = sloppy software in the

new user's eyes.

I think this should be discussed in a new thread since it has nothing to

do with thermal pads.

--

Mit freundlichen Grüßen / With best regards

Joern Paschedag

On Sun, 3 Apr 2011, Olin Lathrop wrote to us saying :

However,

>pretty universally when you see vertical text here it is written going

>down, not up.  This applies to signs, the spines of books, and just about

>everything else.  Vertical text going up looks stupid, at least here.

Here in the UK that's not true. Sure, book spines are (usually) set to

read down, but that's actually for a book-specific reason: if you lay

the book down on a table with the front cover up, the text on the spine

is right-reading. Vertical text on a page usually runs upward, because

in the old days when it was a hand-written annotation a right-handed

person will always find it easier to write upward.

--

Rob Pearce                       http://www.bdt-home.demon.co.uk

The contents of     | All power corrupts, but we need electricity.

this message are    |

purely my opinion.  |

Don't believe a     |

word.               |

Klaus Schmidinger wrote:

>> It is pretty universally understood that CUT does a copy and delete.  This

>> was well established before Eagle was written.  It is totally beyond me

>> what Klaus and company were thinking when they named the copy command

>> "cut".

>The user interface of EAGLE was inspired by the "Valid GED", a graphical

>editor I was working with during my time at Siemens. In that editor the

Thanks for the insight. I always wondered where the naming comes from.

>To get this recurring discussion over with once and for all I suggest

>the following changes for version 6:

Please don't change the behaviour of the commands this way. It would

be a severe drawback!

As others wrote, it's a naming problem - the main issue is that the

current CUT command does "copy" to the buffer, not "cut".

I'm not sure whether renaming of the commands is suitable (compromise

"compatibility" vs. "new user friendliness"), and since I use Eagle

for a long time, I'm not able to give an unbiased vote.

If you ever think about changing the function, I strongly suggest to

start threads in the relevant groups and get the opinions from a

broader audience.

We might consider the relationship between COPY and CUT, and the use

of the left mouse button with CUT in this case.

Oliver

On Wed, 6 Apr 2011, Oliver Betz wrote to us saying :

>As others wrote, it's a naming problem - the main issue is that the

>current CUT command does "copy" to the buffer, not "cut".

The command currently referred to as "cut" is the problem, but if

renamed to "copy" then the existing command of that name causes trouble.

The best "fix" would be to alias the cut command to something clear and

unambiguous that doesn't clash with an existing command. But I can't

think of anything suitable. The existing "copy" command could be called

"clone" or something like that, since its functionality is akin to

duplicating individual components, but that in itself doesn't help

because it's the "cut" command that confuses people. I suppose "cut"

could be renamed to "clone" but that would, at least to me, still feel

to be the wrong way round.

Sorry, I'm not helping am I.

--

Rob Pearce                       http://www.bdt-home.demon.co.uk

The contents of     | All power corrupts, but we need electricity.

this message are    |

purely my opinion.  |

Don't believe a     |

word.               |

On 04/01/11 14:58, Olin Lathrop wrote:

...

Another annoying "feature" that is due to Eagle's origin is that vertical

text reads up not down.  That is the german convention.  However, I am

using the english language version, and judging from the number of

downloads and the activity in this forum, the english language version is

much more popular.  Is this ever going to get fixed?  It's been reported

as a problem long ago.  At the very least there should be a setting for

default vertical text direction.

I'm currently looking into this and would appreciate your advice on the

exact details.

The "German" convention is to have texts be readable from bottom

or right, as shown in the attached image. So any text with an angle

of '90 < angle <= 270' is drawn "upside down".

I understand that the texts "ABC R90" and "ABC R270" would have to

be drawn upside down in the American convention, but what's with

the other texts? Can you give me an expression like the above one,

which takes the angle and calculates whether or not to modify

the orientation?

Or can you point me to a web page that explains the American convention

for text orientations?

Klaus Schmidinger

--

_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10

CadSoft Computer GmbH                   Fax:   +49-8635-6989-40

Pleidolfweg 15                          Email:   kls@cadsoft.de

D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de

_______________________________________________________________

Attachments:

On 09/20/11 11:47, Klaus Schmidinger wrote:

On 04/01/11 14:58, Olin Lathrop wrote:

>> ...

>> Another annoying "feature" that is due to Eagle's origin is that vertical

>> text reads up not down. That is the german convention. However, I am

>> using the english language version, and judging from the number of

>> downloads and the activity in this forum, the english language version is

>> much more popular. Is this ever going to get fixed? It's been reported

>> as a problem long ago. At the very least there should be a setting for

>> default vertical text direction.

 

I'm currently looking into this and would appreciate your advice on the

exact details.

 

The "German" convention is to have texts be readable from bottom

or right, as shown in the attached image. So any text with an angle

of '90 < angle <= 270' is drawn "upside down".

 

I understand that the texts "ABC R90" and "ABC R270" would have to

be drawn upside down in the American convention, but what's with

the other texts? Can you give me an expression like the above one,

which takes the angle and calculates whether or not to modify

the orientation?

Answering to myself: I guess the only two texts that need to

be modified are those with rotation R90 and R270. All others will

be left as is.

The attached images show how this will look. Note that the pad names

of vertical pins will be drawn on the opposite side of the pin wire,

so that when looking at a pin the text is always "above" the pin wire.

Klaus Schmidinger

--

_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10

CadSoft Computer GmbH                   Fax:   +49-8635-6989-40

Pleidolfweg 15                          Email:   kls@cadsoft.de

D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de

_______________________________________________________________

Attachments:

Klaus Schmidinger wrote on Wed, 21 September 2011 10:06

The attached images show how this will look. Note that the pad names of

vertical pins will be drawn on the opposite side of the pin wire, so that

when looking at a pin the text is always "above" the pin wire.

One way or another, vertically oriented text needs to read down, not up.

If you look at a bookshelf here in the US, the titles on the bindings all

read down, for example.

What to do about text that is not exactly vertical or horizontal is a gray

area that I think doesn't have a single right answer.  The example in your

first picture is probably as good as any.  Your second picture is right

on.

Perhaps this whole thing is a problem only because of two unfortunate

design choices:  Eagle wants to "fix" something it maybe shouldn't be

messing with at all, and it doesn't have general text anchoring

capability.

Most systems that have to deal with graphical text allow at least the

choice of the 9 common anchor positions.  The text string extent is

considered a rectangle which can be anchored at any of the 4 corners, the

centers of the 4 edges, or the middle.  With a system like that there is

little need to automatically flip text orientation - in fact it's better to

leave it alone and let the user do what he wants.

To use a Eagle example, suppose I'm making the symbol for a horizontal

resistor.  I want to have the part designator above the symbol and the

value below, but each centered horizontally.  There is no way to do that in

Eagle now.  You have to guess how wide each string is going to be and move

it around so that it will be centered for the nominal width.  Short strings

will end up a little to the left and long strings to the right.  What I

really want to do is anchor the top string to its lower middle point and

the bottom string to its top middle point.  Fortunately for a resistor

there is usually enough room and a little misalignment can be ignored.

However, that was just to illustrate the point.

If Eagle doesn't automatically try to "fix" text orientation, this issue

wouldn't be a problem.  I guess that's like saying the spin flag should

always be on.  After laying out and routing a board, you always expect to

clean up the silkscreen and move text around to where it will be visible

and meaningful.  The text starts out a mess, but that's expected.  Having

that also be upside down makes it no worse.  As you're moving the strings

around with the mouse, a simple right click rotates it another 90 degrees

left.  If it reads up and I want it reading down, two quick mouse clicks

fix that.  The extra mouse clicks are irrelevant since it's a lot less than

moving the text to a decent spot to begin with.  The problem is when Eagle

decides to fix it and never allow the preferred vertical orientation

without having to turn on the spin flag.  That is a bid deal since it's

outside the simple workflow of moving the text around with the mouse.

So I think a better answer is to get rid of the spin flag altogether, give

us at least the 9 basic text anchor points, and never have Eagle think it

knows anything about what direction text should be other than how the user

set it.

Of course I'd have to actually try that to know for sure

--

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

Would it make sense to keep your circle of labels independant on view

rotation? If so, both are wrong, and you would need a flag to set

direction.

On 21.09.2011 18:53, Olin Lathrop wrote:

...

give us at least the 9 basic text anchor points

This will be possible in version 6.

Klaus Schmidinger

--

_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10

CadSoft Computer GmbH                   Fax:   +49-8635-6989-40

Pleidolfweg 15                          Email:   kls@cadsoft.de

D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de

_______________________________________________________________