On Friday 25 November 2016 10:30:35 John Kasunich wrote: > This looks like a great start. I've wanted something like this since > pretty much day 1 of HAL. But I never tackled it because I'm > definitely not a GUI programmer. (Halscope about killed me, > thankfully others made it into the nice tool it is today.) > > Some comments: > > As you and others pointed out, font sizes quickly become a problem. > Part of the reason is that our pin names tend to be long. Regular > schematic programs get around this by using pin numbers and > reference designators, but I don't think that is an option for HAL. > > How about this 2-part suggestion: > > Part 1 - every component has a type (such as "or2" or "near", and > an instance name (such as "or2_0" or "near_speed"). The box at > the top of the component currently contains only the type. Make > that box into a two-line display. One line displays the component > type, the other displays the instance name. That box is already > almost tall enough to display two lines, so it won't increase the > size of the symbol much. (Also, the font could be shrunk a bit > since the pin-name font is already much smaller). > > Your call as to which goes on top - I would lean toward instance > name on top. In a schematic, an IC might be described as > "U1/LM741", where U1 is the instance name. It is far less common > to write "LM741/U1". > > Part 2 - many if not most pin names start with the instance name. > For example, component "or2_0" has pins named "or2_0.in0", > "or2_0.in1", and "or2_0.out". Part 1 above displays the instance > name at the top of the component. So it is redundant to display > it on every pin. For any pin, drop all leading characters that match > the component instance name before displaying the pin name. > That means instead of "or2_0.in0", the pin name will be "in0". > And "near_speed.out" becomes "out". These much shorter pin > names will allow either a larger font or smaller boxes. > Again comparing to an electrical schematic - if you want to refer > to a pin in the overall context, you might say "U1 pin 7". But on > the schematic itself, the pin is just labeled "7", because it is > clearly part of the U1 symbol.
This could be confused by the pin numerology of our modules not having a consistent base1/base0 start. And I sure don't have a clue how that could be fixed without a total compatibility breakage between versions. So we're stuck with it till the rapture I guess. That prevents an enum approach to pin numbering, something I'd like to see hal do all by itself as the recipe was loaded. But thats one of those horses beggars like me would ride. :) > Again, this is great to see and I hope you keep going! I agree again. Thanks Jim Craig. > On Thu, Nov 24, 2016, at 10:08 AM, Jim Craig wrote: > > Progress report. I have the graphics area drawing, panning and > > zooming how I like it. Currently I am just drawing the entire active > > configuration on a single design sheet. I plan on keeping this > > overall design sheet for the final application. It gives a good > > overview of the entire configuration. However, it may get pretty > > cluttered up on a large configuration. > > > > Just for reference I am attaching a PDF printout of the Gmoccapy sim > > config design layout. This design layout was initially > > auto-generated (Components and signals were placed automatically). > > Then I used the drag functionality to drag the components around to > > the most logical places and then regenerated the signal paths > > automatically. No signals were manually relocated on this layout. > > > > To declutter I am adding some functionality. Signals can be added to > > a selection which then colors them to clearly show which pins they > > connect to and the routing of the signal. This feature is shown in > > the PDF. Another feature that I plan to add for further clarity of > > subsections of the design is the ability to "Isolate" selected > > signals and selected components. This would mean that if a component > > is selected and isolated only the signals that are connected to that > > component will be shown. Any components that are attached to the > > selected component signals will also be shown. If a signal is > > selected and isolated then only that signal and the connected > > components would be shown. I think these features will greatly help > > navigate a large configuration. > > > > For further decluttering the components only show pins that have > > signals connected to them. This simplifies the overall design layout > > as there can be many pins that are not used taking up space. To > > connect a signal to an unused pin you would right click on the > > component and select the pin from a context menu > > > > Some additional features I will be adding is the ability to right > > click on a component and select from a context menu to show the man > > page for that component. This will cut down on time to look up > > documentation for what you are working on. Another feature is to add > > a context menu option that will pull up a halmeter for each of the > > selected signals if requested. > > > > I also have to write the code to save the locations of components > > and signals to an external file for future use. > > > > Once I get the above functionality added I will work on processing > > the .ini file and the subsequent .hal files to separate the overall > > config into separate design layouts that represent each .hal file > > individually. This will require adding cross page connectors to jump > > a signal from one design layout to another. This will also require > > creating a subcomponent item which will take a component like and2 > > that can be initialized with count =15 or names = * and split the > > component into subcomponents that represent each instance of the > > main component. This is to simplify signal routing and allow > > subcomponents to be on .hal file design layouts in which they were > > not initialized. > > > > Anyway I am very interested in your comments or suggestions. There > > is a lot left to complete this program but I feel that I am making > > pretty good progress to this point. > > > > At what point should I commit this to the project so that others can > > play with it? > > > > Happy Thanksgiving, to all of you and for those that don't celebrate > > I am sure I will eat enough Turkey for you as well. > > > > Thanks, > > > > Jim > > -------------------------------------------------------------------- > >---------- _______________________________________________ > > Emc-developers mailing list > > Emc-developers@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/emc-developers > > Email had 1 attachment: > > + test.pdf > > 42k (application/pdf) Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene> ------------------------------------------------------------------------------ _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
