[Geany-devel] GProject - the second attempt

[Jiří Techet]

On Fri, Jul 9, 2010 at 19:49, Dimitar Zhekov <dimitar.zhekov at gmail.com> wrote:
> On Sun, 4 Jul 2010 00:54:17 +0200
> Jiří Techet <techet at gmail.com> wrote:
>
>> Hi everybody,
>
> Hi. I finally had the time to read the long list of suggested gproject
> changes and the discussion on them.
>
>>     Rewrite tab switching queue
>
> About time.
>
>>     Remove the "set" button from the project properties dialog
>
> All hail, it's confusing. I press "Set", and it looks like nothing
> happened. After switching to the "Build" tab, some of the entries are
> changed, but colored as default. And %p is set even for the empty
> commands, which are colored as non-default...
>
>>     Use relative paths in the project files
>>
>>     However, when the project is saved, all paths are converted to relative.
>
> I haven't tested, so correct me if I'm wrong, but it looks like it'll
> convert even paths outside the project directory, resulting in names
> like "../../testing/gsm/CHANGES". So if I move the project in a

Right.

> different directory on the same machine, it's quite possble that
> all ../ names will become invalid, while absolute names would have
> been OK.

Precisely, I'm aware of that. Both absolute and relative paths have
some advantages and some disadvantages, but in my opinion the relative
paths are more useful.

>
> The reasonable compromise, IMHO, will be to use relative names for the
> files under the project directory only.

Good idea, should be possible. On the other hand there are some cases
where this wouldn't work. E.g. when you rename your projects
directory, where you keep all your projects and the referenced
external files are from other project in that directory.

>
>>     Make it possible to change project patterns by plugins
>>     Add signals for project options dialog opening and closing
>
> Generally, you want gproject integrated seamlessly in Geany. However,
> in 0.19, the plugins are even less integrated than before, with a
> separate "Plugin preferences" function.
>
> Without changing the Geany core, you can make the gproject preferences
> available in Edit -> Plugin Preferences, or with a button in the panel,
> and define whatever validators you need. Then, you can use the project
> name from the plugin data and save the preferences.

You should distinguish two kinds of preferences:

1. Per-project preferences - different for every project.
2. Per-plugin preferences - different for every plugin

What you propose is to put the per-project preferences under the
per-plugin preferences dialog. The preferences can be different for
every project (and stored in the project file) and putting them to a
different place than the project properties dialog will be very
inconvenient and confusing for the user.

>
>>     Make the project menu accessible by plugins
>
> The project menu is probably easy to find, with something like
> g_object_get_data((gpointer) geany->main_widgets->window, "project1").

But this is hacky. There is no guarantee that it will be called
"project1" forever and that the widget will be stored in such a
structure.

> But the real question, as pointed out by Lex, is about the ammount of
> plugin intergation. I see that you got an "OK" from Nick for this -
> perhaps I should request access to the Edit menu, which contains all
> the Insert-Some-Text functions, and put the Insert Numbers [from
> geanyinsertnum] there?..

Not a question to me I guess. Myself I was considering leaving the
menu items under the tools menu but really felt that the plugin is no
"tool" and that the very natural place for the items is the project
menu.

>
>>     Plugins can override project patterns. In that case the "file patterns"
>>     field is made inactive in the Project tab of the project properties
>>     dialog.
>
> Can you please remind me what was the reason for that?

Have a look at the screenshot I posted in the first email of this thread.

1. The file icons in the sidebar differ for different pattern groups
(headers, sources, others). I find it very useful to distinguish
quickly between different kinds of files.
2. Header/sources patterns are used for the "swap header/source"
feature (others files are skipped from that)
3. All the patterns combined are used for the FIF dialog.

So the user specifies the individual pattern groups in my plugin
settings and the plugin uses the union of these patterns to override
the project patterns (mainly for the FIF dialog).

>
>>     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.
>
> Not editable - but what if I want to add/remove a pattern for this
> particular search? I'd prefer the Nick's suggestion, "Always append
> project patterns to the Files drop-down list [...], it's up to the user
> to choose it."

You can uncheck the "use project patterns" checkbox (the project
patterns remain in the edit box) and add or remove whatever you want.
Unless you re-check the checkbox again, you'll use these patterns. See
the screenshots I sent as a response to Nick's email to see one more
alternative to this.

>
>>     It should be considered whether the "files" checkbox should exist
>
> Indeed. If patterns are entered in the edit field, there are patterns.
> If the field is empty, there are no patterns. FIF may (and probably
> does) work in a different way with patterns, but there's no such
> tooltip or any other suggestion related to the Files checkbox. And if
> there was, it could be have been displayed directly for the edit field.

Again, the screenshots of FIF I sent to Nick are one more way how how
the dialog could look like.

Regards,

Jiri

>
> (BTW, when you check Files, and don't enter anything in the patterns
> field, nothing will be found. Which is formally correct. :)
>
> --
> E-gards: Jimmy
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>