I agree that user doesn't have to open a project to be able to use debugging and settings are better be saved between geany startups.
What I wanted was to have debug settings loaded at the same time I open files I worked with last time. And I kept in mind that there can be several sessions/projects that a user would like to save debug settings for.
I also decided to use project file because there is no API to store plugin data in a session, but now I realize that I can store debug settings for a session in plugins own config, where all other plugin level stuff reside and if a user works with a project - store debug settings in a project, therefore supporting both project and session modes.
I believe it's the right way.
Regards, Alexander
On Wed, 21 Sep 2011 17:18:14 +0400 Alexander Petukhov devel@apetukhov.ru wrote:
What I wanted was to have debug settings loaded at the same time I open files I worked with last time. [...] but now I realize that I can store debug settings for a session in plugins own config, where all other plugin level stuff reside and if a user works with a project - store debug settings in a project, [...]
What you need is debug sessions, and they depend on the executable being debugged. It doesn't make sense to use the same breakpoints, watches etc. for more than one program, or two sets of these for the same program.
I think you can store the debug session settings in the plugin main and only configuration file, with section names dependent on the full executable name, for example it's md5 sum:
/home/build/projects/testing/geany -> [945b93c3fe68a0fe63ac6e8e528c59a5] ...settings...
/home/build/source/fnatools/fnstofna -> [1b216f36ac78dd903085214692c821cc] ...settings...
etc. Note that the projects sessions do not necessarily match the debug sessions - for example, a project may produce several executable files, and they will not share the same debugging session.
On 22 September 2011 02:01, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Wed, 21 Sep 2011 17:18:14 +0400 Alexander Petukhov devel@apetukhov.ru wrote:
What I wanted was to have debug settings loaded at the same time I open files I worked with last time. [...] but now I realize that I can store debug settings for a session in plugins own config, where all other plugin level stuff reside and if a user works with a project - store debug settings in a project, [...]
What you need is debug sessions, and they depend on the executable being debugged. It doesn't make sense to use the same breakpoints, watches etc. for more than one program, or two sets of these for the same program.
I think you can store the debug session settings in the plugin main and only configuration file, with section names dependent on the full executable name, for example it's md5 sum:
/home/build/projects/testing/geany -> [945b93c3fe68a0fe63ac6e8e528c59a5] ...settings...
/home/build/source/fnatools/fnstofna -> [1b216f36ac78dd903085214692c821cc] ...settings...
etc. Note that the projects sessions do not necessarily match the debug sessions - for example, a project may produce several executable files, and they will not share the same debugging session.
You are correct that debugging settings relate to the executable a *user* is debugging and so should be saved in a file in the user config directory, not in a project file.
The little problem with your implementation is that there is no indication when you have finished with that executable and the settings can be deleted.
I suggest like the "recent files" list it would need to be limited in number, so the section names should be [debug1] to [debugn] and the path be one of the settings.
Cheers Lex
-- E-gards: Jimmy _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Am 21.09.2011 18:01, schrieb Dimitar Zhekov:
On Wed, 21 Sep 2011 17:18:14 +0400 Alexander Petukhovdevel@apetukhov.ru wrote:
What I wanted was to have debug settings loaded at the same time I open files I worked with last time. [...] but now I realize that I can store debug settings for a session in plugins own config, where all other plugin level stuff reside and if a user works with a project - store debug settings in a project, [...]
What you need is debug sessions, and they depend on the executable being debugged. It doesn't make sense to use the same breakpoints, watches etc. for more than one program, or two sets of these for the same program.
I disagree with the very last statement. If you're working at the same project in different branches you might want to debug different parts. And if you have a project/session file per branch then it even matches with "debug sessions".
I think you can store the debug session settings in the plugin main and only configuration file, with section names dependent on the full executable name, for example it's md5 sum:
/home/build/projects/testing/geany -> [945b93c3fe68a0fe63ac6e8e528c59a5] ...settings...
/home/build/source/fnatools/fnstofna -> [1b216f36ac78dd903085214692c821cc] ...settings...
etc. Note that the projects sessions do not necessarily match the debug sessions - for example, a project may produce several executable files, and they will not share the same debugging session.
That's what I said in the other mail. I think "debug sessions" is overengineering it, adding complexity for little value.
Bes regards.
On Fri, 23 Sep 2011 19:52:24 +0200 Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
Am 21.09.2011 18:01, schrieb Dimitar Zhekov:
What you need is debug sessions, and they depend on the executable being debugged. It doesn't make sense to use the same breakpoints, watches etc. for more than one program, or two sets of these for the same program.
I disagree with the very last statement. If you're working at the same project in different branches you might want to debug different parts.
Are you using several branches with a single executable name? I prefer to keep my source directories clean and generate the object and executable files outside them, but at least each branch has it's own output directory.