Re: [Geany-devel] saving plugin settings in a project file
On Fri, 23 Sep 2011 19:52:24 +0200 Thomas Martitz thomas.mart...@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. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] saving plugin settings in a project file
Am 21.09.2011 18:01, schrieb Dimitar Zhekov: On Wed, 21 Sep 2011 17:18:14 +0400 Alexander Petukhovde...@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. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] saving plugin settings in a project file
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 ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] saving plugin settings in a project file
On Wed, 21 Sep 2011 17:18:14 +0400 Alexander Petukhov de...@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. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] saving plugin settings in a project file
Am 19.09.2011 11:13, schrieb Lex Trotman: On 19 September 2011 18:38, Alexander Petukhovde...@apetukhov.ru wrote: I would like to store debugger settings such as watches, breaks, target etc in a project file. These are not the settings that apply to a plugin in a whole but look like being related to files user is working with, i.e. a project. The files a user is working with are not necessarily a project. Especially for something as general as debugging it is important that you also support workflows that don't involve having a project file open (as well as ones that do of course). Doesn't that mean another type of session is needed? a debug session? I think it makes sense to tie debug stuff to projects. Doing it any other way probably means lots of extra work and maintainance effort, for a use-case the author doesn't even have. Best regards. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] saving plugin settings in a project file
On 19 September 2011 18:38, Alexander Petukhov de...@apetukhov.ru wrote: I would like to store debugger settings such as watches, breaks, target etc in a project file. These are not the settings that apply to a plugin in a whole but look like being related to files user is working with, i.e. a project. The files a user is working with are not necessarily a project. Especially for something as general as debugging it is important that you also support workflows that don't involve having a project file open (as well as ones that do of course). After looking at project signals I was 100% sure that they are intended to give a plugin a place to store its settings that apply to a project. Not necessarily, there are also plugins that provide extended project functionality but still use standard settings, so they need to know about when those change. Yesterday on IRC we talked about it and Matthew said that it's better to have a distinct file. As much as I hate to agree with Matthew :) he's probably right on this one. Having your own file allows you to support both operation with a project and operation without one. Just store your sets of settings separated by project name and a set which are general for non-project use. As for me, I'd better keep all session related settings in one file, i.e. in a project and would like to ask you here what do you think about? Again, you should also support non-project operation. One more question is about project signals, looks like to save settings in a project a plugin is encouraged to add a notebook tab in project_dialog_create signal handler and to save setting when this dialog is closed when processing a project_save signal. Well no, plugins normally create a tab in the plugin preferences dialog. The GKeyFile that is passed in project_open signal is closed right after sending a signal, so plugins can't use it for saving data. Which sort of answers the question :) What if I want to write settings not using project settings dialog that looks unsuitable for a debugger, is it correct to initialize and the save a new GKeyFile to geany_data-app-project-file_name? Personally I don't think that individual programmer information like this should be in a project file, it should be in the user prefs. I believe it was a mistake to have session settings in a file called the project file, a project file is something that I have seen shared, and having individual user settings in it is a problem. Perhaps one day there will be time to separate sessions and project settings. Cheers Lex ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
