rethink import and library path strategy

[hneemann]

If a file is opened the library path is set to the folder of the opened file. All files in and below that location are used as library files, which means you can include them by the components menu.
This avoid the dealing with additional library paths, to include components. You also can simply zip a folder and you have all the components needed to work with the circuit.
But in some cases this behavior is confusing to the user (See #32, #38). Maybe the handling of libraries should be changed.

[guiweber]

I think it would also be good to consider including all circuits below the Digital folder (i.e. the content of the example folder) by default as the "standard library" so that all those circuits are available from the get-go without having to save the circuit first and move library files around.

[hneemann]

@guiweber Maybe you are right. In this pre release verison i have added a folder "lib" and all its content is always added to the components menu. Maybe this solves some of the hassle dealing wit 74xx circuits.

[guiweber]

I like it. The only think I might consider changing is putting the content imported from the "lib" folder and the content imported from folders relative to the circuit file in two different folders in the component tree view.

So the tree view would look something like

--Lib
------74xx
------Some_other_std_lib
--Custom
------my_custom_circuit
------my_other_custom_circuit

[hneemann]

Thats a good idea. I will implement that.

[peterb12]

I agree that this is one of the more confusing parts of the app as it stands now. It feels like the app is doing a lot of things implicitly, which is probably very convenient when you understand what it's doing - but which makes it hard to initially comprehend. For comparison one aspect of logisim that i actually like a lot is that i can think entirely in terms of circuits (in a given project) but not really have to worry about managing multiple files.

[hneemann]

Multiple files have advantages:

1. Versioning is easier. For example, you can only revert the whole project, not only a single circuit if everything is stored in a single file.
2. Different people can work on different files without conflicts. This is important because the files are nearly impossible to merge.
3. Its easier to share circuits.

[peterb12]

I'll buy rationales 1 and 2 (although, I'd suggest version control is a more effective solution than architecting the app for this). But: is #3 really true? Imagine I create a library with multiple circuits that reference each other. I grab a single .circ file from the library and send it to my associate. What happens?

I just tried it, and here's what the associate would get:

So I think this is a false economy. Yes, in some sense I can "share" individual circuits, but now you've created an implicit, hidden requirement on the user to only transport (or at a minimum use) circuits along with their entire library.

This is isomorphic to code development in many ways, and I would suggest you consider how IDEs like Xcode or Eclipse treat files: yes, you can still address (or share) individual files, but there is an explicit, surfaced concept of a "Project", and it's well-understood that there is state associated with that project and if you decide to share .c, .m, or .java files without the Project, you don't get that state. I think you are aiming for a world where a .circ file is equivalent to an implementation file, which is fine, but the analogue to the Project is very implicit. That's what I think is confusing.

[hneemann]

Perhaps you are right and I have tried to avoid something like a "Project" because it feels too complicated and have created something that is at least of the same complexity.

At the other hand: LaTeX works just fine without a project file and uses the same approach as Digital: A defined folder for libraries and all other includes are located relative to the root file.

[jsegarraf]

I feel comfortable with the current behavior. It is simple and easy to understand. The "export to zip" feature also solves any sharing problem.

Maybe it would be clearer if the .dig files used in the current circuit could be included in the circuit statistics (Simulation menu), with an additional column sort of "Built-in/Custom (not embedded)" or something like that.

On the other hand, .hex files to preload to RAM/ROM do not follow previous behavior. Instead, absolute paths are stored in the .dig file. This does make the circuit unusable outside the current computer, even if you share all the required files, because the path will change. Note that even the path format and the valid file names depend on the system. So, projects/paths are the actual "false economy" from this point of view, since they provide an organization feeling that is only valid for the local computer.

I would keep the current behavior for circuits, and extend it to .hex files for RAM/ROM.

[hneemann]

@jsegarraf

Maybe it would be clearer if the .dig files used in the current circuit could be included in the circuit statistics (Simulation menu), with an additional column sort of "Built-in/Custom (not embedded)" or something like that.

This was the case in the first implementation of the statistics function. But with the introduction of generics this was no longer possible. Now the statistics can only be generated from the model which no longer contains information about the original embedded circuits because it is completley "flat".

On the other hand, .hex files to preload to RAM/ROM do not follow previous behavior. Instead, absolute paths are stored in the .dig file. This does make the circuit unusable outside the current computer, even if you share all the required files, because the path will change.

If you load any content to a ROM, this content is stored in the .dig file.
And to distribute a RAM component with preloaded content seems strange to me. This "preload" function is intended to be used for debugging only, and should not be used to distribute a circuit.
But you are right: No absolute paths should be stored in a .dig file. I have to think about it.

[Tompouce-onGit]

I absolutely agree that the import system should be revised. To me it is quite nonsensical which is a shame, and I'm saying this with no mean intention whatsoever, I love this simulator.

Say I have a circuit saved that would be useful to include in many other circuits. Now suppose I want to use it in other but unrelated projects. To me it is comon sense to save those projects in seperate folders since they are unrelated, yet in doing so the only way to use this component in them is to have a copy of it in all the folders where it is needed.
This makes it impossible to have a clean and organised folder hierarchy without having to make multiple copies of multiple circuits, all of which have to be kept up to date with each other, in the project folders that need them.

The current system just makes maintenance a hastle. Moreover, Digital is the only place I have ever encountered such a system and I absolutely do not understand why there would be a need for it or what problem it is supposed to solve.
The documentation says that it is supposed to "avoid a complex administration of import paths" and to "support the various work methods of the users". But I believe firmly that it does the complete opposite, instead forcing the user to choose between having to maintain multiple copies of the same circuits, and having a complex and convoluted folder hierarchy.

To me this proposition by @guiweber is comon sense and solves all of the problems that I have expressed above very simply, and is what I would have expected.
So please consider implementing that change in the next release because I really love every other facet Digital, but this system is incredibly frustrating to me and I don't understand why it is handled the way it is.

[hneemann]

@Tompouce-onGit

Say I have a circuit saved that would be useful to include in many other circuits.

Store the circuit in the "lib" folder or in a folder below the "lib" folder (see the settings). Than the circuit is available in any other circuit. This way you can create your own library of circuits used as building blocks.
All the 74xx circuits a handled this way: They are stored in the lib folder and therefore available in any other circuit.

To me this proposition by @guiweber is comon sense and solves all of the problems that I have expressed above very simply, and is what I would have expected.

But this suggestion from @guiweber was implemented two years ago.

[hneemann]

I decided to close this issue with a "Wont-Fix". I do not want to change the import system. All practical cases it seems to handle well, and with moving the "lib" folder it feels finished.