[Geany-devel] GProject - the second attempt
nick.treleaven at xxxxx
Wed Jul 7 16:23:56 UTC 2010
On Sun, 4 Jul 2010 00:54:17 +0200
Jiří Techet <techet at gmail.com> wrote:
> This time I did my best to integrate the plugin to geany as well as
> possible so there are more patches for geany itself than before. Apart
> from patches needed for gproject there are several more patches that
> fix some bugs in geany or are meant to improve the usability. The
Just to mention: I'm not sure if I/we have much time in the next few
weeks, so reviewing (& applying) them might get delayed.
> geany patches are here:
> under the "for_review" branch. Below there is a detailed log of the
> changes. I expect some discussion for some of the patches (they
> represent my view on the problem but you may have a different opinion)
> so when replying to this email it's probably best to take the commit
> title as the email's title and also keep the detailed commit message
> in the body of the email so everybody knows what we're talking about.
> Once there is some agreement about the future of the patches, I can
> resend them by email - I just don't want to spam the mailing list with
> too many messages.
I'll try to give a very brief comment on each/some below without
really reading the code.
> Rewrite tab switching queue
> Remove the "set" button from the project properties dialog
> Unless I miss something the button just adds %d to the corresponding
> fields, but this is already the default settings so I don't see any
> point of doing it.
I think so too.
> Use relative paths in the project files
Hmm, I thought there was something like this already, but haven't
checked, so maybe.
> File name in the project settings dialog shouldn't look it is editable
> Use wider entry for project file path
> When closing tab, return to the document at the top of the MRU list
> Open the file in the msgwindow even if no linenumber is specified
> Make it possible for plugins to change the base directory of msgwindow
> Don't be annoying when not necessary
> When reloading a file with ctrl+R don't display the warning dialog
> that the unsaved changes might be lost when the file has not been
What if you accidentally pressed Ctrl-R? You could lose work.
> Make it possible to change project patterns by plugins
> Plugins can override project patterns. In that case the "file patterns"
> field is made inactive in the Project tab of the project properties
So this patch also shows the currently hidden field too. Maybe OK
> Use project patterns in the FIF dialog
> When "use project patterns" is selected, the project patterns are copied
> to the "files" edit box and it becomes not editable. It should be considered
> whether the "files" checkbox should exist - it may not be clear if the
> edit box is greyed out because "use project patterns" is selected or because
> "files" is unselected. The "use project patterns" checkbox is inactive when
> no project is loaded.
> Make the project menu accessible by plugins
> Not really a hard requirement but since the project plugin settings
> can now be also integrated to the project settings dialog, it
> looks strange when the project-related items are in the Tools menu.
What items do you want the plugin to put in the Project menu?
> Add signals for project options dialog opening and closing
> These signals can be used by plugins to add their settings tab and
> read the settings when the user presses OK. The code had to be
> reorganized slightly because first project-dialog-confirmed has
> to be emitted (so the plugin can read the settings) and project-save
Maybe OK - I think project_dialog_confirmed may be unnecessary as
plugins could connect to the dialog response signal from the
> Prevent -Wmissing-prototypes report warning when compiling a plugin
We discussed this before. A plugin would also need prototypes for the
other functions like plugin_init. So I said we could change the
doc/pluginsymbols.c file into a header to do this.
More information about the Devel