Comments (4)
I agree entirely with section 1. I am too unsure how to approach single opamps, but IMO I would go for consistency here, and make the symbols in such a way that the power pins can be placed onto the opamp symbols.
For section 2 (Large digital ICs), I think there is some value to split them. But there is another value in having them visually represented as one monolithic unit (which in the end, physically they are). Maybe there is a way to get both?
For section 3 I again agree totally, nothing to add.
For section 4 I agree mostly, while I am not sure about the Optocoupler part (4i), below is the LCR-0202 I made:
If you search google images you will find that most optocoupler symbols are in fact visually coupled. This is IMO for a good reason.
I see a similar problem like the one mentioned in section 2: how can we get the advantage of making units movable while visually making clear that they are part of a bigger thing?
- dashed bounding box lines? With these one could get some degree of flexibility.
- light dashed lines connecting these things? Would convolute to a visual mess quite quickly.
- reference lettering? Prone to reading mistakes
Maybe we could think about a more flexible way, to break out sub-units only if needed or something like that.
from horizon-pool-convention.
Thanks for the feedback!
For the single op amps, the user would have to smash the components and hide the text for one of them manually after rearranging them on top of each other. That isn't totally pleasant and introduces another source of error (erroneously swapping components, typos while changing the reference designators). On the other hand, it doesn't cost much to include and might be useful for people doing a “prettying up” pass on the schematic before publishing/archiving it.
If you search google images you will find that most optocoupler symbols are in fact visually coupled. This is IMO for a good reason.
You're right. If we allowed separation of transmitter and reciever, we'd need a naming scheme for the reference designators, so a quadruple optocoupler's eight symbols wouldn't get completely confusing.
- dashed bounding box lines? With these one could get some degree of flexibility.
Could you elaborate? I don't think I understand this one fully.
Maybe we could think about a more flexible way, to break out sub-units only if needed or something like that.
I don't think there is a way to comfortably offer both splitting up monolithic components and drawing them as one without integrated support from Horizon. That, however, could get pretty complicated and opaque to the user. Personally, I'd step back from that idea and take only one way of displaying into account.
from horizon-pool-convention.
On a second thought I agree on the conclusion, that splitting monolithic parts could be a bit too intransparent. In the end we will have to decide for each part anyways – should it be multiple units or one?
For the dashed line idea, I did a quick and dirty mockup:
In my imagination that would be something that could be switched on or of on a per Entity, and obviously it would only be meant for special parts (I don't really like the IC example above, but it illustrates the idea).
Maybe this could even work for parts on different pages:
This shows visually that these belong together (in a package sense), while still allowing some degree of movment.
from horizon-pool-convention.
Ah, I see. This would certainly look nice in some situations, but I think it would add unnecessary visual noise in most cases (and become confusing once the dashed outlines for multiple parts intersect). Reference designators are probably still the best solution…
from horizon-pool-convention.
Related Issues (13)
- File name capitalisation rules HOT 3
- Hyphens or underscores for spaces? HOT 2
- Placement of the package origin/anchor HOT 3
- Rectangular pin 1 pads for THT packages? HOT 6
- Special-purpose pad name convention HOT 2
- Courtyard rules for connectors HOT 1
- Power pin positioning HOT 5
- Dash in the package name: SO-8 or SO8?
- Checklist "how to contribute" HOT 7
- Different packages with the same name HOT 1
- Requirements/process for a package to be ‘generic’
- Package orientation rules
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from horizon-pool-convention.