Could You please improve project management panels

[Babak M.]

The root is also a project? Or the root is the "project group"?

The root is not a project; it is a container for other projects. In Visual Studio, the root is called a solution. The solution actually is a container for projects and has a few options for choosing run priority.

Ok, now I get slightly confused...

I had a similar conversation with someone else, and they said "In VS you have Solutions in a Workspace" => making it sound like solutions are the project.

But according to https://learn.microsoft.com/en-us/visualstudio/ide/solutions-and-projects-in-visual-studio?view=vs-2022
- Solutions:
 

It's simply a container for one or more related projects, along with build information

  Solutions are project groups.
- And projects are also called project.

The difference seems to be that VS has all build/run related stuff in the project group. Lazarus merely offers to trigger the build/run from the group, but has the settings (and tools) in the Project.

However, there also was the mention of Workspaces, and they seem to exist https://learn.microsoft.com/en-us/visualstudio/extensibility/workspaces?view=vs-2022
But there is no info how they relate to solution or project.

Anyway that does not really much matter, except for: If/When we use them in this conversation we need to set out a definition what we mean by them.

I have not used workspaces in Visual Studio yet. I found the following descriptions:


In Visual Studio, both workspaces and solutions are used to manage collections of files, but they serve different purposes and have distinct characteristics:

Solutions:
•  Definition: A solution is a container for one or more related projects. It organizes projects, build information, Visual Studio window settings, and any miscellaneous files that aren't associated with a particular project. https://learn.microsoft.com/en-us/visualstudio/ide/solutions-and-projects-in-visual-studio?view=vs-2022.

•  Structure: Solutions are described by a .sln file, which contains information about the projects included in the solution and their configurations. https://learn.microsoft.com/en-us/visualstudio/ide/solutions-and-projects-in-visual-studio?view=vs-2022

•  Usage: Solutions are typically used for larger, more complex applications that consist of multiple projects. They provide a way to manage dependencies between projects and ensure they are built in the correct order.https://learn.microsoft.com/en-us/visualstudio/ide/solutions-and-projects-in-visual-studio?view=vs-2022

•  Features: Solutions support features like solution-level properties, build configurations, and the ability to set startup projects .https://learn.microsoft.com/en-us/visualstudio/ide/solutions-and-projects-in-visual-studio?view=vs-2022

Workspaces:
•  Definition: A workspace represents any collection of files opened in a folder. It is used primarily in the context of the "Open Folder" feature in Visual Studio. https://learn.microsoft.com/en-us/visualstudio/extensibility/workspaces?view=vs-2022

•  Structure: Workspaces do not have a specific file format like solutions. Instead, they rely on the folder structure and the files within it. https://learn.microsoft.com/en-us/visualstudio/extensibility/workspaces?view=vs-2022

•  Usage: Workspaces are ideal for scenarios where you want to work with a set of files without the overhead of creating and managing a solution. This is useful for smaller projects, quick edits, or when working with code that doesn't fit neatly into a project/solution structure. https://learn.microsoft.com/en-us/visualstudio/extensibility/workspaces?view=vs-2022

•  Features: Workspaces provide a general set of APIs for extensions to produce and consume data related to the files. They support features like contextual file information, symbols in source files, and build functionality through workspace providers and services. https://learn.microsoft.com/en-us/visualstudio/extensibility/workspaces?view=vs-2022

Key Differences:
•  File Management: Solutions use a .sln file to manage projects, while workspaces rely on the folder structure.

•  Complexity: Solutions are suited for complex, multi-project applications, whereas workspaces are better for simpler, file-based projects.

•  Features: Solutions offer more advanced features for managing project dependencies and build configurations, while workspaces provide a lightweight way to work with files and folders.

Both solutions and workspaces have their own strengths and are suited to different types of development tasks. Choosing between them depends on the complexity of your project and your specific needs.

[Babak M.]

Ok, unless I missed it (in which case I am sorry) I had no feedback to my latest "build list" comment.

IMHO "building all projects" is a subset of "building a group of specified projects".

And, IMHO "building all" is rarely needed during development. Since we talk about using proper design, I assume testcases, and mock entities are part of the development process. So I would expect that in a project that size, over 90% of all builds are some testcase, wich will only include one or two "live" projects, and "mock" projects for the rest.

So you do need a place to define "list of projects" that need to be build depending on what you are changing and testing. => That is the aim of the "build lists" idea.

In fact, you may get conflicts if you build mock and live entities at the same time, if they both produce the same binary in the same location. So you definitely need to be able to choose.

Your example of combining test projects with other projects in a single project group was great. There is a "build configuration" option in the solution properties in Visual Studio. You can define a new configuration and set which projects must be built.

[Babak M.]

In the 2nd image: How many such settings for "startup project" can you have in a solution?
E.g. could you create something like "build modes" in Lazarus, and for each such "build mode" have a different setting for "startup project"?

You cannot define multiple startup plans in Visual Studio. However, if there are distinct build configuration models, defining different startup plans makes sense.

[Martin_fr]

Ok, so then the only difference I see to my idea "build list" is that in VS this is on the "Solution" (the project group). While I would put it on each project.

And I really don't see the point of it on the group. If I build have a test project open, then surely I will never build the release from that? Well ok, if I never change to the main project then yes.
But normally I would expect that I get those "startup project" build settings that relate to the project I have open.

---EDIT
You posted an update while I posted: So then my ideas allows several plans. Better.

Just need to get it implemented....

[Babak M.]

To me, the main point is to provide the features  that you have in VS (or in other words "allow to do the same things with similar effort").
But not necessarily the same user interface. Not even necessarily the same concepts. (There may be better concepts after all / and we need to integrate our existing concepts without loss or duplication).

I completely agree with you. It doesn't matter if you have the same UI and the same look and feel, but in my opinion, when a user has to ask someone about a functionality, we encounter a bad and ambiguous design. When you apply a de facto standard, you gain more points for your design.

I am not an expert in compiler/IDE development, only I have expressed a problem. I am confident that you and the other team members will definitely find the best solution for creating large projects in Lazarus.

Thank you for your attention

[Martin_fr]

Don't misunderstand me when I challenge (question) your input. I am very glad to get any feedback I can.

And you provided some valuable points. And helped with explaining the VS concepts. For that, big thanks.