[Geany-devel] GProject - the second attempt

[Nick Treleaven]

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:
> 
> http://gitorious.org/~techy/geany/gproject-geany
> 
> 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

maybe OK

>     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

OK.

>     Use wider entry for project file path

OK.

>     When closing tab, return to the document at the top of the MRU list

maybe OK

>     Open the file in the msgwindow even if no linenumber is specified

OK

>     Make it possible for plugins to change the base directory of msgwindow

OK

>     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
>     modified.

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
>     dialog.

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.

Maybe

>     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
>     afterwards.

Maybe OK - I think project_dialog_confirmed may be unnecessary as
plugins could connect to the dialog response signal from the
project_dialog_create callback.

>     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.

Regards,
Nick