Mail Archives: geda-user/2015/08/02/19:06:21
On Aug 2, 2015, at 5:10 PM, Edward Hennessy (ehennes AT sbcglobal DOT net) [via geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:
>
>> On Aug 2, 2015, at 10:12 AM, John Doty <jpd AT noqsi DOT com> wrote:
>>
>> Perhaps I’m misunderstanding, but it appears that you are assuming that the pages open in gschem represent some sort of coherent, organized design. In real life, they don’t: the coherence eventually emerges from what you’re doing with the pages, but it’s not necessarily present in the set of pages you have open.
>
> I've only used flat for schematic designs, but it is becoming apparent:
>
> - The page manager can only make a best guess to the hierarchy of a design. If a page isn’t loaded, it won’t show the complete story.
Or if pages from multiple designs are loaded, the story gets muddy, especially when the pages don’t all use the same configuration file.
>
> - A schematic can have multiple parents,
Who’s the “parent” of /usr/include/stdint.h? Many, many C source files, including other header files, include it. Symbols and schematic files in gEDA are like source files for a program.
> but gschem doesn’t have the functionality to track more than one parent. And this variable only stores the most recent “up.”
>
> It seems to me:
>
> - That the page manager shouldn’t try and track the hierarchy. It should have a flat list of all the pages that are loaded. If hierarchy is tracked, it should be done somewhere outside gschem.
It’s handy to be able to go down and up. Knowledge of hierarchy is local in gschem, and that’s fine. There’s no guarantee that there’s a consistent, finite global hierarchy for gschem to use. It’s perfectly possible to hang gnetlist up traversing recursive hierarchy, but gschem shouldn’t fall into this trap. If you accidentally make a recursive hierarchy, you need a tool that can repair the mistake! Gschem is safe because it doesn’t explore the whole hierarchy: it only moves locally as you tell it. Locality is pragmatic.
>
> - The page manager could possibly show one level more, but just the dependent filenames.
>
> - The push schematic menu item should expand into a list of all the source files that could be descended into for that symbol.
Right now, it opens the whole module, all of the schematics mentioned in source= attributes. You can then move among them with > and <. That’s handy, too. One current design of mine has eight pages in one of the modules, and I certainly don’t remember the details of which functions are on what page!
>
> - The “up” should not be stored in the schematic page data structure. It is associated with the view and stored as a stack. The view would push and pop pages on the stack as the user pushes symbols/schematics.
That would not be a disaster, but I sometimes use the page manager to navigate the portion of hierarchy that’s open.
>
> Ideas?
>
> Ed
>
John Doty Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd AT noqsi DOT com
- Raw text -