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.
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.
Yesterday on IRC we talked about it and Matthew said that it's better to have a distinct file. 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?
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.
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.
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?
Regards, Alexander
On 19 September 2011 18:38, Alexander Petukhov devel@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
Am 19.09.2011 11:13, schrieb Lex Trotman:
On 19 September 2011 18:38, Alexander Petukhovdevel@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.