Some thoughts on doing breakpoints persistent

[oBFusCATed]

Two questions:
what will we do with a project opened in a workspace and outside a workspace or in two different workspaces?
Also what about the inactive projects in a workspace?

I'm more in favour of a .user directory next to the workspace file, if there is a workspace of course, else place it next to the project file.

[MortenMacFly]

I'm more in favour of a .user directory next to the workspace file

Why a directory? Isn't a descriptive file (maybe more) enough?

A general question: We have the project file where we can save stuff in it, right? So what we want to save here is something which is user-dependent and shall not be e.g. committed, right? What about using the concept of the project layout file, rename it to *.user.settings ("user" replaced with the actual user so you can have multiple in parallel) and extend it with the other stuff we want?

[oBFusCATed]

I want to make it directory in order to make the project/workspace directory a bit more clear.
My idea is to move all useless to the user files there, like the layout, depend, bmarks, etc.
If we choose a single file we will have to redo all current code, which saves user files.

[MortenMacFly]

If we choose a single file we will have to redo all current code, which saves user files.

We don't have such code yet to my knowledge. My proposal was not to add new files, but to use/tweak what we have. And using ignore patterns for version control avoids the (already) visible clutter. In the end it would be a 1:1 relation between project files and files with meta-data. Having an API in place could also allow plugins to make use of it... How does that sound?

[oBFusCATed]

We don't have such code yet to my knowledge.

What about the code used to save .depend, .layout, .bmarks files?

All of them use different format. I was thinking of providing a function like GetUserFilePath(...) which returns a proper folder.
But I've not tried to implement it, yet, because of the workspace problem.

[MortenMacFly]

What about the code used to save .depend, .layout, .bmarks files?

Al-right... now I know what you mean. I thought you only think about the .layout stuff and additional stuff.

I was thinking of providing a function like GetUserFilePath(...)

Well what about if you return a proper file instead and simply change the the methods to create its own node in this fiel instead of creating an new one? The file would look then like:

Code

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<CodeBlocks_project_meta_data_file>
  <debugger>
    <bmarks>
    </bmarks>
    <connectivity>
    </connectivity>
  </debugger>
  <core>
    <layout>
    </layout>
    <stuff_from_core_like_project_settings>
    </stuff_from_core_like_project_settings>
  </core>
</CodeBlocks_project_meta_data_file>

Note that with the .depend file it is different: It comes from a 3rd party lib and we cannot change it to something else, nor integrate it,not even move it most likely without changing the depends lib.

...whatever we choose it requires some refactoring, for sure.

[oBFusCATed]

This is another option, but it is more limiting, because all files should be saved in xml format.

And yes, some refactoring will be required anyway.

[ollydbg]

Well what about if you return a proper file instead and simply change the the methods to create its own node in this fiel instead of creating an new one? The file would look then like:

Code

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<CodeBlocks_project_meta_data_file>
  <debugger>
    <bmarks>
    </bmarks>
    <connectivity>
    </connectivity>
  </debugger>
  <core>
    <layout>
    </layout>
    <stuff_from_core_like_project_settings>
    </stuff_from_core_like_project_settings>
  </core>
</CodeBlocks_project_meta_data_file>

The sdk can have a interface like:

Code

Manager::Get()->GetProjectMetaDataManager(_T("core"))         //Get the "core" Node.

which return a Node pointer, then the client plugins can write and wrote on these Node/blocks.

[oBFusCATed]

The sdk can have a interface like:

Code

Manager::Get()->GetProjectMetaDataManager(_T("core"))         //Get the "core" Node.

which return a Node pointer, then the client plugins can write and wrote on these Node/blocks.

Doesn't like.

[ollydbg]

The sdk can have a interface like:

Code

Manager::Get()->GetProjectMetaDataManager(_T("core"))         //Get the "core" Node.

which return a Node pointer, then the client plugins can write and wrote on these Node/blocks.

Doesn't like.

, I'm not good at design interface, so can you give a good way? How can the interface like?

[MortenMacFly]

This is another option, but it is more limiting, because all files should be saved in xml format.

Yes, that is a limitation. I understand that this wouldn't be needed for the .user folder. However, the .user folder may not work, too because plugins may require relative files or simply not make use of the API (like the cscope plugin). So you still (most likely will) have clutter. Another case that won't work with XML on the other hand are the build logs in HTML...

Aaargh... we have so many cases... And btw: Talking about the debugger raises another one: What, if we want to have target related temporary settings, like connectivity options per target - that does make sense you know...

[oBFusCATed]

Aaargh... we have so many cases... And btw: Talking about the debugger raises another one: What, if we want to have target related temporary settings, like connectivity options per target - that does make sense you know...

It could be saved per target in the file.

About cscope, I suppose the plugin can be modified to generate its files in .user.
The valgrind plugin also generates a xml file, which could be save in .user.
Another benefit of using a directory is that files could be shared/backuped and so on (even if not supported by us )