On Fri, Jul 9, 2010 at 19:49, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Sun, 4 Jul 2010 00:54:17 +0200 Jiří Techet techet@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@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel