Hi everybody,
here's my second attempt to create a project management plugin for big projects:
http://gitorious.org/gproject/gproject
and here's a screenshot for those who are scared to compile and install it ;-) :
http://dl.dropbox.com/u/2554438/gproject.png
The main change since the first version is that now it extends the current project management rather than trying to replace it. One consequence is that now only a single project can be open at a time but the rest of the functionality is preserved (header/source swapping, finding project file, tag generation for all project files, search in only those files that satisfy the given pattern). One more change is that the project base path is used to define the directory that should be scanned for project files.
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 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.
Finally, I have renamed the original gproject to "multiproject" and it's available together with the geany patches here:
http://gitorious.org/gproject/multiproject http://gitorious.org/~techy/geany/multiproject-geany
I probably won't maintain it any longer since the new version of the plugin is much more compatible with the geany handling of projects. If anyone wishes to take over the old plugin, feel free to do so.
Cheers,
Jiri
commit 8b9e9c923197180a6ebc592b3f6f5c7205b0338a Author: Jiří Techet techet@gmail.com Date: Sat Jul 3 23:49:03 2010 +0200
Rewrite tab switching queue
There was one more bug related to the tab switching. When we switch so many times that we return back to the original document (so we actually don't switch at all) then the following switch attempt doesn't switch immediately to the next document.
After spending two hours thinking what is wrong, I gave up and rewrote the whole thing in a different way. The problem with the previous implementation was that before you couldn't just look what's in the queue "now" - you had to imagine what will be inserted there in the next step because the switch_in_progress variable was set after the first switch (this is also why I put the long comment why mru_pos = 2 - that is not clear at all when you first look at it). Also there were some not very nice "workarounds" like the idle function that was executed after the switch and removed the double entry on top of the queue.
So with the new implementation things are much simpler IMO. The queue starts with the current document and the previously opened documments follow. It's *always* like that, no exceptions. The idle function is gone and cb_func_switch_tablastused() is simplified too. The rest of the functionality should be clear from the code.
Signed-off-by: Jiří Techet techet@gmail.com
src/keybindings.c | 61 +++++++++++++++++++++------------------------------- 1 files changed, 25 insertions(+), 36 deletions(-)
commit 430c3409fbbd47816ddce95f6c055143683d9ecc Author: Jiří Techet techet@gmail.com Date: Sat Jul 3 01:27:10 2010 +0200
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.
src/build.c | 12 ------------ src/build.h | 2 -- src/project.c | 30 +++--------------------------- 3 files changed, 3 insertions(+), 41 deletions(-)
commit 61d21ddfbdb84b2da2e1b11f7aae15ae1fb7a4dc Author: Jiří Techet techet@gmail.com Date: Fri Jul 2 00:03:56 2010 +0200
Use relative paths in the project files
Right now projects cannot be moved to other directories without losing the base directory setting of the project and the list of open files. This makes the project totally unportable to different machines because even if the directory structure under your home is identical, the user name can be different so the path is different too.
The paths should be relative to the project file, which is what every other IDE I know does. If you keep the project file in the same relative path to the project files, you can move it wherever you want.
This patch does this in a backwards-compatible way - when the path in the project settings file is absolute, it uses the absoulte path. However, when the project is saved, all paths are converted to relative. This means that all new applications will be able to read the old project definition files but the old applications won't read the new files (or more precisely, the paths in them).
For the global session file absolute paths are still used mainly because in Windows you cannot create a relative path to a different volume and the global settings file can be at a volume different from the project dir. (I don't expect anyone has the project definition file at different volume than the project files so this shouldn't be an issue for projects).
Signed-off-by: Jiří Techet techet@gmail.com
src/keyfile.c | 39 ++++++++++++++++++++++++++++++++++----- src/keyfile.h | 2 +- src/project.c | 26 +++++++++++++++++++++++--- 3 files changed, 58 insertions(+), 9 deletions(-)
commit 54946954e282768e1a03493804fd6b1f9c8aa4ff Author: Jiří Techet techet@gmail.com Date: Thu Jul 1 22:55:15 2010 +0200
File name in the project settings dialog shouldn't look it is editable
Use selectable GtkLabel so it's possible to copy the file name but it is immediatelly clear that it cannot be edited.
Signed-off-by: Jiří Techet techet@gmail.com
src/project.c | 28 ++++++++++++++++------------ 1 files changed, 16 insertions(+), 12 deletions(-)
commit 73e0e38dc348fcba0d5860d824a367c2b3ebb712 Author: Jiří Techet techet@gmail.com Date: Thu Jul 1 22:46:46 2010 +0200
New utils function to get relative path from one directory to another
This is used by the patch that writes relative paths to the project file. I put it to utils because I use it in gproject as well and might be useful for others.
Signed-off-by: Jiří Techet techet@gmail.com
plugins/geanyfunctions.h | 2 ++ src/plugindata.h | 2 +- src/plugins.c | 3 ++- src/utils.c | 41 +++++++++++++++++++++++++++++++++++++++++ src/utils.h | 2 ++ 5 files changed, 48 insertions(+), 2 deletions(-)
commit b708498f0fe312d4b7eed2674ea27732a9d00c75 Author: Jiří Techet techet@gmail.com Date: Thu Jul 1 01:51:18 2010 +0200
Use wider entry for project file path
30 is too little. For instance
/home/techet/projects/geany/geany.geany
is 39 characters long and this is really short path. I find 50 characters to be about minimal usable size so users do not have to scroll inside the edit box too often.
src/project.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
commit 590b694964a6441c1e0e1aa75baaf341919d4146 Author: Jiří Techet techet@gmail.com Date: Thu Jul 1 01:50:49 2010 +0200
When closing tab, return to the document at the top of the MRU list
This is a pretty frequent work pattern of mine:
1. Editing file A 2. Searching for function and opening file B 3. Closing file B because I just wanted to look at the function definition 4. Without this patch I get to the file following the B's tab (which is just a random file) but my brain expects that I get to A
I know it's possible to kind of simulate the behaviour I want with the "next to current" placement option but I really don't see a single advantage of having tabs closed in sequential order. This is also why I didn't make this behaviour optional. But maybe I miss some use case of tabs being closed sequentially - just tell me.
Signed-off-by: Jiří Techet techet@gmail.com
src/keybindings.c | 10 ++++++++++ src/notebook.c | 9 --------- 2 files changed, 10 insertions(+), 9 deletions(-)
commit 3c93a352849736f8da89b3bdd3f6ac00ec2bc006 Author: Jiří Techet techet@gmail.com Date: Mon Jun 28 23:22:26 2010 +0200
Open the file in the msgwindow even if no linenumber is specified
Plugins may need to open a file from the message window without specifying the line number (e.g. gproject has the feature "find project file"). In addition to the original behaviour this patch makes it possible to open files when the message is of the form
filename(:[whatever])*
so for instance
/home/techet/geany/foo.c /home/techet/geany/foo.c: this the file you were searching for
are both valid and the file is opened when the message is clicked.
Signed-off-by: Jiří Techet techet@gmail.com
src/msgwindow.c | 33 +++++++++++++++++++++++++++++++++ 1 files changed, 33 insertions(+), 0 deletions(-)
commit 9f3fdbb165ecbcad938785090f8d594a74d97960 Author: Jiří Techet techet@gmail.com Date: Wed Jun 30 00:02:13 2010 +0200
Make it possible for plugins to change the base directory of msgwindow
Plugins might want to open file relatively to certain directory so make it possible by this patch.
Signed-off-by: Jiří Techet techet@gmail.com
plugins/geanyfunctions.h | 2 ++ src/msgwindow.c | 23 +++++++++++++++++++---- src/msgwindow.h | 4 +++- src/plugindata.h | 1 + src/plugins.c | 3 ++- src/search.c | 3 +-- 6 files changed, 28 insertions(+), 8 deletions(-)
commit f5085f2264fa83cd2f074667a6359be2ffff9f19 Author: Jiří Techet techet@gmail.com Date: Tue Jun 29 23:54:52 2010 +0200
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.
Signed-off-by: Jiří Techet techet@gmail.com
src/callbacks.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)
commit 0a1bfd3e8a9367a8f1fe15d4048d923ebb0630c2 Author: Jiří Techet techet@gmail.com Date: Mon Jun 28 23:19:37 2010 +0200
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.
Signed-off-by: Jiří Techet techet@gmail.com
plugins/geanyfunctions.h | 2 + src/plugindata.h | 9 +++++++ src/plugins.c | 8 +++++- src/project.c | 57 +++++++++++++++++++++++++++++---------------- src/project.h | 1 + 5 files changed, 56 insertions(+), 21 deletions(-)
commit 5bc03552353655f45af696b14792ed987be81680 Author: Jiří Techet techet@gmail.com Date: Mon Jun 28 23:18:12 2010 +0200
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.
Signed-off-by: Jiří Techet techet@gmail.com
src/search.c | 57 ++++++++++++++++++++++++++++++++++++++++++++++++++++----- 1 files changed, 52 insertions(+), 5 deletions(-)
commit a2094786952d1b5a3a6eac8ecf965a245ec97668 Author: Jiří Techet techet@gmail.com Date: Sun Jun 27 22:53:27 2010 +0200
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.
Signed-off-by: Jiří Techet techet@gmail.com
src/main.c | 1 + src/ui_utils.h | 1 + 2 files changed, 2 insertions(+), 0 deletions(-)
commit 7695f16a2a57e0dd973a3f0bd441fb1717c1cbfa Author: Jiří Techet techet@gmail.com Date: Sun Jun 27 22:52:54 2010 +0200
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.
Signed-off-by: Jiří Techet techet@gmail.com
doc/pluginsignals.c | 19 +++++++++++++++++++ src/geanyobject.c | 18 ++++++++++++++++++ src/geanyobject.h | 4 ++++ src/project.c | 14 +++++++++----- 4 files changed, 50 insertions(+), 5 deletions(-)
commit 923259ca214403ada159749aa838c9e34d37c154 Author: Jiří Techet techet@gmail.com Date: Sat Jun 5 14:24:06 2010 +0200
Prevent -Wmissing-prototypes report warning when compiling a plugin
Signed-off-by: Jiří Techet techet@gmail.com
src/plugindata.h | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)
On Sun, 4 Jul 2010 00:54:17 +0200 Jiří Techet techet@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
Hi Nick,
thanks for looking at the patches. Let me know if I should re-send them by email or modify them in some way.
Further comments below.
On Wed, Jul 7, 2010 at 18:23, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Sun, 4 Jul 2010 00:54:17 +0200 Jiří Techet techet@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.
No problem, take your time.
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.
I was wrong about %d being default (it was set this way in my global settings) but I still don't like the button much. First it takes too much time for my brain to understand what the long label says, second it's no problem to set the %d manually. But I don't care too much about this particular patch.
Use relative paths in the project files
Hmm, I thought there was something like this already, but haven't checked, so maybe.
No, there's nothing like that. I understand that using full paths may be useful in some special cases to move the project file separately from the project files to a completely different place without breaking things, but in my opinion being able to move a project together with the project file to a different directory (PC) without breaking the paths is much more useful.
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.
No, what the patch does is that it checks whether the file is modified (and not saved) and pops up the dialog if and only if it is modified. So there should be no danger that you lose your work in progress.
(The patch (mis)uses short evaluation of boolean expressions in C so this is probably what you have overlooked.)
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
Right. The field is made insensitive when the patterns are overridden by plugins. Also what I changed is that the patterns are space-separated like in the FIF dialog (and not newline-separated) to be consistent.
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?
http://dl.dropbox.com/u/2554438/project-menu.png
The "find in project files" item is identical to "find in files" but always using the project's base directory no matter what file is active.
The reason why I think it's better to put these entries into the project menu is that when the user uses my gproject plugin, it is completely invisible for him that it's some kind of extension of geany - everything is integrated to the current project handling and it would look a bit strange if some entries related to the project would be under the project menu and some under the tools menu.
(The "generate tags" entry is related to my other plugin, which is currently a work in progress. With this plugin you can generate the ctags file using this entry (all files under the base path satisfying the patterns are included) and then, use the editor's context menu to find the given tag. You can find the result of such a search in the message window in the screenshot. The tag manager that geany uses is too slow for big projects so I can't use it for this purpose.)
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.
Well, I emit this signal only if the dialog was successfully validated by geany. So for instance if you specify an invalid project name in the dialog, the signal is not emitted until you correct it and press OK again. In what you propose it would be emitted every time I guess. Apart from that, I pass only the notebook as the signal's argument so I cannot connect to anything that's outside of it (like the buttons).
One more thing that might be needed by plugins (but which isn't needed by gproject so I haven't added the API methods) is the ability to add their own validators of the dialog entries the given plugins added. There could be something like register_validator() and unregister_validator() whose argument would be a pointer to the validator function. Geany would keep a list of these pointers and run all the functions to see if everything is valid before it sends the above signal. The functions could also return some error string used by a pop up error dialog. As I said, I don't need it but could be added when some plugin requires such a functionality.
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.
I know, this is a complete set of patches I use against geany.
But I don't understand why the plugins would need doc/pluginsymbols.c to be changed to doc/pluginsymbols.h - I thought this was needed if geany itself was compiled with the flag (I haven't tried it myself so I don't know what's needed for that). plugin_init() has to be implemented by the plugin so all the plugin has to do is to declare the function as well before it implements it. At least for gproject this patch is all I need to compile it without warnings.
Cheers,
Jiri
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Hi Jiri
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.
I was wrong about %d being default (it was set this way in my global settings) but I still don't like the button much. First it takes too much time for my brain to understand what the long label says, second it's no problem to set the %d manually. But I don't care too much about this particular patch.
It actually sets them to %p not %d, but I agree that it should go, someone wanted it to give a single click replacement for the checkbox that was there (in 0.18 and before) but I think its confusing.
Use relative paths in the project files
Hmm, I thought there was something like this already, but haven't checked, so maybe.
No, there's nothing like that. I understand that using full paths may be useful in some special cases to move the project file separately from the project files to a completely different place without breaking things, but in my opinion being able to move a project together with the project file to a different directory (PC) without breaking the paths is much more useful.
I'd find that very useful, second the motion
(The patch (mis)uses short evaluation of boolean expressions in C so this is probably what you have overlooked.)
Its a perfectly valid use and a widely used idiom, don't apologise for it.
The "find in project files" item is identical to "find in files" but always using the project's base directory no matter what file is active.
The reason why I think it's better to put these entries into the project menu is that when the user uses my gproject plugin, it is completely invisible for him that it's some kind of extension of geany
- everything is integrated to the current project handling and it
would look a bit strange if some entries related to the project would be under the project menu and some under the tools menu.
Totally agree, Geany doesn't (yet) support plugins integrating themselves fully into Geany, but its something that needs thinking about as a general capability to allow a more seamless user experience, maybe we can look at how tools like Firefox do it.
The problem with the current approach is that each time someone comes along with a good idea they have to request access to parts of Geany from the primary developers and then there is a discussion of what is right to make available or add to the core. All of which wastes the core developers time and reduces what else they can do. A more general plugin system would save them having to do that.
One more thing that might be needed by plugins (but which isn't needed by gproject so I haven't added the API methods) is the ability to add their own validators of the dialog entries the given plugins added. There could be something like register_validator() and unregister_validator() whose argument would be a pointer to the validator function. Geany would keep a list of these pointers and run all the functions to see if everything is valid before it sends the above signal. The functions could also return some error string used by a pop up error dialog. As I said, I don't need it but could be added when some plugin requires such a functionality.
This is a good idea that needs to be addressed as part of an overall discussion of how plugins integrate with Geany. I guess when everyone gets some time :-(.
Cheers Lex
On Fri, Jul 9, 2010 at 03:37, Lex Trotman elextr@gmail.com wrote:
Hi Jiri
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.
I was wrong about %d being default (it was set this way in my global settings) but I still don't like the button much. First it takes too much time for my brain to understand what the long label says, second it's no problem to set the %d manually. But I don't care too much about this particular patch.
It actually sets them to %p not %d, but I agree that it should go, someone wanted it to give a single click replacement for the checkbox that was there (in 0.18 and before) but I think its confusing.
Use relative paths in the project files
Hmm, I thought there was something like this already, but haven't checked, so maybe.
No, there's nothing like that. I understand that using full paths may be useful in some special cases to move the project file separately from the project files to a completely different place without breaking things, but in my opinion being able to move a project together with the project file to a different directory (PC) without breaking the paths is much more useful.
I'd find that very useful, second the motion
(The patch (mis)uses short evaluation of boolean expressions in C so this is probably what you have overlooked.)
Its a perfectly valid use and a widely used idiom, don't apologise for it.
The "find in project files" item is identical to "find in files" but always using the project's base directory no matter what file is active.
The reason why I think it's better to put these entries into the project menu is that when the user uses my gproject plugin, it is completely invisible for him that it's some kind of extension of geany
- everything is integrated to the current project handling and it
would look a bit strange if some entries related to the project would be under the project menu and some under the tools menu.
Totally agree, Geany doesn't (yet) support plugins integrating themselves fully into Geany, but its something that needs thinking about as a general capability to allow a more seamless user experience, maybe we can look at how tools like Firefox do it.
The problem with the current approach is that each time someone comes along with a good idea they have to request access to parts of Geany from the primary developers and then there is a discussion of what is right to make available or add to the core. All of which wastes the core developers time and reduces what else they can do. A more general plugin system would save them having to do that.
On the other hand, we could easily overdo it with plugin API generality. Geany should definitely not become Eclipse written in C. In my opinion the current approach of introducing API functions on demand is alright. The amount of things the plugins can already do is satisfactory for most of the plugins I guess. My plugin is a bit exceptional in being the first plugin that extends the project management of geany and therefore needs some extra functions and signals for that (not so many though, most of the patches are just general geany improvements). And talking about every single additional API function with geany developers is good in the sense that the given function is considered from more viewpoints and sufficient brain time is spent before introducing a possibly nonsense function into the API. Also introducing API functions in advance can cause that these functions are poorly tested because there's nothing that uses them. I also like that the API is restrictive a bit - plugins shouldn't be able to modify geany completely so it becomes a different editor - they should just extend it in a certain way.
But I don't have anything against looking at how others do it - there are surely good (and bad) lessons we can learn. If I should say a single thing I dislike about how plugins are implemented in geany (and there's actually only this single complaint), it is the fact that by including geanyplugin.h I also include lots of function prototypes that don't belong to the API. It happened to me several times that I copied some code from geany into my plugin, compiled it without any problem, but then the plugin didn't load because the function I used was not a part of the API. Some macros or whatever should be used to prevent non-API functions and data structures from being included by the plugins.
Cheers,
Jiri
One more thing that might be needed by plugins (but which isn't needed by gproject so I haven't added the API methods) is the ability to add their own validators of the dialog entries the given plugins added. There could be something like register_validator() and unregister_validator() whose argument would be a pointer to the validator function. Geany would keep a list of these pointers and run all the functions to see if everything is valid before it sends the above signal. The functions could also return some error string used by a pop up error dialog. As I said, I don't need it but could be added when some plugin requires such a functionality.
This is a good idea that needs to be addressed as part of an overall discussion of how plugins integrate with Geany. I guess when everyone gets some time :-(.
Cheers Lex _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Totally agree, Geany doesn't (yet) support plugins integrating themselves fully into Geany, but its something that needs thinking about as a general capability to allow a more seamless user experience, maybe we can look at how tools like Firefox do it.
The problem with the current approach is that each time someone comes along with a good idea they have to request access to parts of Geany from the primary developers and then there is a discussion of what is right to make available or add to the core. All of which wastes the core developers time and reduces what else they can do. A more general plugin system would save them having to do that.
On the other hand, we could easily overdo it with plugin API generality. Geany should definitely not become Eclipse written in C.
Definitely not
In my opinion the current approach of introducing API functions on demand is alright. The amount of things the plugins can already do is satisfactory for most of the plugins I guess.
Yes you and I are pushing the edges with project and build plugins because we are not adding new functionality but improving something that already exists so need to integrate with it.
My plugin is a bit
exceptional in being the first plugin that extends the project management of geany and therefore needs some extra functions and signals for that (not so many though, most of the patches are just general geany improvements). And talking about every single additional API function with geany developers is good in the sense that the given function is considered from more viewpoints and sufficient brain time is spent before introducing a possibly nonsense function into the API.
Yes, but it tends to be a specific function for a specific plugin, not general capability, there seems to be some resistance to thinking about them as general capabilities.
Also introducing API functions in advance can cause that these functions are poorly tested because there's nothing that uses them.
Yes, I agree, I was more thinking about providing general capabilities rather than a wide API. It may mean some re factoring of Geany because at the moment many of the restrictions are hard coded in low level functions.
I
also like that the API is restrictive a bit - plugins shouldn't be able to modify geany completely so it becomes a different editor - they should just extend it in a certain way.
Well, really why not? I someone wants to make it work differently because they like it that way, why can't they. If you don't like what a particular plugin does, just don't use it. :-)
Cheers Lex
But I don't have anything against looking at how others do it - there are surely good (and bad) lessons we can learn. If I should say a single thing I dislike about how plugins are implemented in geany (and there's actually only this single complaint), it is the fact that by including geanyplugin.h I also include lots of function prototypes that don't belong to the API. It happened to me several times that I copied some code from geany into my plugin, compiled it without any problem, but then the plugin didn't load because the function I used was not a part of the API. Some macros or whatever should be used to prevent non-API functions and data structures from being included by the plugins.
Cheers,
Jiri
One more thing that might be needed by plugins (but which isn't needed by gproject so I haven't added the API methods) is the ability to add their own validators of the dialog entries the given plugins added. There could be something like register_validator() and unregister_validator() whose argument would be a pointer to the validator function. Geany would keep a list of these pointers and run all the functions to see if everything is valid before it sends the above signal. The functions could also return some error string used by a pop up error dialog. As I said, I don't need it but could be added when some plugin requires such a functionality.
This is a good idea that needs to be addressed as part of an overall discussion of how plugins integrate with Geany. I guess when everyone gets some time :-(.
Cheers Lex _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Thu, 8 Jul 2010 23:59:04 +0200 Jiří Techet techet@gmail.com wrote:
Hi Nick,
thanks for looking at the patches. Let me know if I should re-send them by email or modify them in some way.
Can you send the patches by email please - my git-fu is not yet good enough (slowly improving though).
I'll try to give a very brief comment on each/some below without really reading the code.
That's why some of my comments were vague - I mostly didn't look at the code changes.
Use relative paths in the project files
Hmm, I thought there was something like this already, but haven't checked, so maybe.
No, there's nothing like that. I understand that using full paths may be useful in some special cases to move the project file separately from the project files to a completely different place without breaking things, but in my opinion being able to move a project together with the project file to a different directory (PC) without breaking the paths is much more useful.
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.
No, what the patch does is that it checks whether the file is modified (and not saved) and pops up the dialog if and only if it is modified. So there should be no danger that you lose your work in progress.
OK, I didn't realise.
(The patch (mis)uses short evaluation of boolean expressions in C so this is probably what you have overlooked.)
Looks fine to me, I didn't check the code change before.
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
Right. The field is made insensitive when the patterns are overridden by plugins. Also what I changed is that the patterns are space-separated like in the FIF dialog (and not newline-separated) to be consistent.
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
Hmm, I still need to check the code properly, but I'm having second thoughts about this. Simpler alternatives would be:
1. Always append project patterns to the Files drop-down list on showing the dialog (if it's not already there), it's up to the user to choose it.
2. An API function to show the dialog with an argument for file patterns.
The advantage would be that the dialog is simpler - less controls & complexity.
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?
OK.
(The "generate tags" entry is related to my other plugin, which is currently a work in progress. With this plugin you can generate the ctags file using this entry (all files under the base path satisfying the patterns are included) and then, use the editor's context menu to find the given tag. You can find the result of such a search in the message window in the screenshot. The tag manager that geany uses is too slow for big projects so I can't use it for this purpose.)
I'm not sure that could integrate with Geany's tag functionality, but it's up to you.
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.
Well, I emit this signal only if the dialog was successfully validated by geany. So for instance if you specify an invalid project name in the dialog, the signal is not emitted until you correct it and press OK again. In what you propose it would be emitted every time I guess.
OK, good point, and it allows the validator API to be added later if we decide to.
Connecting to the dialog response signal is what the plugin_configure symbol currently does, so probably we should add a plugin_configured symbol and encourage users to use that instead, for the same reason (validators).
http://www.geany.org/manual/reference/pluginsymbols_8c.html#a5d574ade6576014...
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.
I know, this is a complete set of patches I use against geany.
But I don't understand why the plugins would need doc/pluginsymbols.c to be changed to doc/pluginsymbols.h - I thought this was needed if geany itself was compiled with the flag (I haven't tried it myself so I don't know what's needed for that).
It's currently just for generating documentation.
plugin_init() has to be implemented by the plugin so all the plugin has to do is to declare the function as well before it implements it. At least for gproject this patch is all I need to compile it without warnings.
I thought it would be easier to avoid having to declare e.g. plugin_init and other function symbols.
But I might apply the patch.
Regards, Nick
On Fri, Jul 9, 2010 at 13:57, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Thu, 8 Jul 2010 23:59:04 +0200 Jiří Techet techet@gmail.com wrote:
Hi Nick,
thanks for looking at the patches. Let me know if I should re-send them by email or modify them in some way.
Can you send the patches by email please - my git-fu is not yet good enough (slowly improving though).
OK, will do (maybe I'll wait for a while to collect everyone else's comments and possibly modify the patches).
I'll try to give a very brief comment on each/some below without really reading the code.
That's why some of my comments were vague - I mostly didn't look at the code changes.
Use relative paths in the project files
Hmm, I thought there was something like this already, but haven't checked, so maybe.
No, there's nothing like that. I understand that using full paths may be useful in some special cases to move the project file separately from the project files to a completely different place without breaking things, but in my opinion being able to move a project together with the project file to a different directory (PC) without breaking the paths is much more useful.
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.
No, what the patch does is that it checks whether the file is modified (and not saved) and pops up the dialog if and only if it is modified. So there should be no danger that you lose your work in progress.
OK, I didn't realise.
(The patch (mis)uses short evaluation of boolean expressions in C so this is probably what you have overlooked.)
Looks fine to me, I didn't check the code change before.
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
Right. The field is made insensitive when the patterns are overridden by plugins. Also what I changed is that the patterns are space-separated like in the FIF dialog (and not newline-separated) to be consistent.
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
Hmm, I still need to check the code properly, but I'm having second thoughts about this. Simpler alternatives would be:
- Always append project patterns to the Files drop-down list on
showing the dialog (if it's not already there), it's up to the user to choose it.
But this also means that every time a project is opened, the patterns have to be selected manually from the list (easy to forget to do so and it also won't be clear to the user which patterns in the list belong to the project).
- An API function to show the dialog with an argument for file
patterns.
I think it wouldn't be a good idea to force the patterns every time the dialog is opened (neither by default nor by any plugin). The user may have customized the patterns and this would just reset them.
The advantage would be that the dialog is simpler - less controls & complexity.
OK, I have one more idea how the dialog might look like, see the mockups below:
http://dl.dropbox.com/u/2554438/fif1.png http://dl.dropbox.com/u/2554438/fif2.png
For "all" and "project" the patterns entry would be disabled (for project it would display the project's patterns). I think this solution doesn't add much complexity - the two-state check button just changes to three-state combo box.
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?
OK.
(The "generate tags" entry is related to my other plugin, which is currently a work in progress. With this plugin you can generate the ctags file using this entry (all files under the base path satisfying the patterns are included) and then, use the editor's context menu to find the given tag. You can find the result of such a search in the message window in the screenshot. The tag manager that geany uses is too slow for big projects so I can't use it for this purpose.)
I'm not sure that could integrate with Geany's tag functionality, but it's up to you.
The reason is simplicity. This plugin was one afternoon work for me. I used readtags.[ch] from ctags to read the tags file, then took the code from geany's build subsystem to run the tags generation asynchronously, then added some code to read the code under the cursor and after finding the tag I put the output to the message window. So the work can be characterized as stealing someone else's work, slightly modifying it and putting it together.
I spent very limited time looking at the tag manager so the following can be quite wrong. From what I have seen it creates some object hierarchy by going through the objects and for every object finding the related object (quadratic complexity at least). Probably this could be improved by using hash tables instead of lists but I would really have to dig into the code deeply to understand it and find where the bottlenecks are. In contrast, ctags tag generation is mostly (apart from sorting the tag file) linear. Just for illustration, for linux kernel the generation of the 140MB tag file containing about 1.6 million entries from all *.c and *.h files takes less than 20s.
In fact I think the best way to develop the tag manager would be _outside_ of geany so all other editors could benefit from it. Unfortunately from what I can see both tag manager and slightly less ctags are rather dead.
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.
Well, I emit this signal only if the dialog was successfully validated by geany. So for instance if you specify an invalid project name in the dialog, the signal is not emitted until you correct it and press OK again. In what you propose it would be emitted every time I guess.
OK, good point, and it allows the validator API to be added later if we decide to.
Connecting to the dialog response signal is what the plugin_configure symbol currently does, so probably we should add a plugin_configured symbol and encourage users to use that instead, for the same reason (validators).
Yep, sounds reasonable.
http://www.geany.org/manual/reference/pluginsymbols_8c.html#a5d574ade6576014...
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.
I know, this is a complete set of patches I use against geany.
But I don't understand why the plugins would need doc/pluginsymbols.c to be changed to doc/pluginsymbols.h - I thought this was needed if geany itself was compiled with the flag (I haven't tried it myself so I don't know what's needed for that).
It's currently just for generating documentation.
plugin_init() has to be implemented by the plugin so all the plugin has to do is to declare the function as well before it implements it. At least for gproject this patch is all I need to compile it without warnings.
I thought it would be easier to avoid having to declare e.g. plugin_init and other function symbols.
I'll leave it up to you - if you decide for changing the source file into a header, it's better when it's done by you as I might break some things I'm not aware of.
Regards,
Jiri
But I might apply the patch.
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Fri, 9 Jul 2010 22:53:17 +0200 Jiří Techet techet@gmail.com wrote:
Can you send the patches by email please - my git-fu is not yet good enough (slowly improving though).
OK, will do (maybe I'll wait for a while to collect everyone else's comments and possibly modify the patches).
Suits me :)
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
Hmm, I still need to check the code properly, but I'm having second thoughts about this. Simpler alternatives would be:
- Always append project patterns to the Files drop-down list on
showing the dialog (if it's not already there), it's up to the user to choose it.
But this also means that every time a project is opened, the patterns have to be selected manually from the list (easy to forget to do so and it also won't be clear to the user which patterns in the list belong to the project).
- An API function to show the dialog with an argument for file
patterns.
I think it wouldn't be a good idea to force the patterns every time the dialog is opened (neither by default nor by any plugin). The user may have customized the patterns and this would just reset them.
The advantage would be that the dialog is simpler - less controls & complexity.
OK, I have one more idea how the dialog might look like, see the mockups below:
http://dl.dropbox.com/u/2554438/fif1.png http://dl.dropbox.com/u/2554438/fif2.png
For "all" and "project" the patterns entry would be disabled (for project it would display the project's patterns). I think this solution doesn't add much complexity - the two-state check button just changes to three-state combo box.
This looks good to me.
(The "generate tags" entry is related to my other plugin, which is currently a work in progress. With this plugin you can generate the ctags file using this entry (all files under the base path satisfying the patterns are included) and then, use the editor's context menu to find the given tag. You can find the result of such a search in the message window in the screenshot. The tag manager that geany uses is too slow for big projects so I can't use it for this purpose.)
I'm not sure that could integrate with Geany's tag functionality, but it's up to you.
The reason is simplicity. This plugin was one afternoon work for me. I
OK, just wanted to mention it. E.g. Go to Tag commands, etc.
I spent very limited time looking at the tag manager so the following can be quite wrong. From what I have seen it creates some object hierarchy by going through the objects and for every object finding the related object (quadratic complexity at least). Probably this could be improved by using hash tables instead of lists but I would really have to dig into the code deeply to understand it and find where the bottlenecks are. In contrast, ctags tag generation is mostly (apart from sorting the tag file) linear. Just for illustration, for linux kernel the generation of the 140MB tag file containing about 1.6 million entries from all *.c and *.h files takes less than 20s.
In fact I think the best way to develop the tag manager would be _outside_ of geany so all other editors could benefit from it. Unfortunately from what I can see both tag manager and slightly less ctags are rather dead.
Anjuta used to use tagmanager but IIUC they now use a GtkTreeModel to store CTags-parsed info, I haven't looked at it.
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.
I know, this is a complete set of patches I use against geany.
But I don't understand why the plugins would need doc/pluginsymbols.c to be changed to doc/pluginsymbols.h - I thought this was needed if geany itself was compiled with the flag (I haven't tried it myself so I don't know what's needed for that).
It's currently just for generating documentation.
plugin_init() has to be implemented by the plugin so all the plugin has to do is to declare the function as well before it implements it. At least for gproject this patch is all I need to compile it without warnings.
I thought it would be easier to avoid having to declare e.g. plugin_init and other function symbols.
I'll leave it up to you - if you decide for changing the source file into a header, it's better when it's done by you as I might break some things I'm not aware of.
OK.
Regards, Nick
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 different directory on the same machine, it's quite possble that all ../ names will become invalid, while absolute names would have been OK.
The reasonable compromise, IMHO, will be to use relative names for the files under the project directory only.
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.
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 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?..
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?
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."
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.
(BTW, when you check Files, and don't enter anything in the patterns field, nothing will be found. Which is formally correct. :)
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
On Fri, 9 Jul 2010 23:36:06 +0200 Jiří Techet techet@gmail.com wrote:
On Fri, Jul 9, 2010 at 19:49, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Sun, 4 Jul 2010 00:54:17 +0200
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.
The renaming of the main projects directory should be rare. But with alls path relative, any movement of the project up or down in the directory hierarhy will break all non-project paths, and movement at the same level can break some of them (for example moving the project directory from projects/ to backups/ will make the external files from other project invalid).
The reason to use relative paths is to preserve the project file names. What happens to the non-project files, we can not tell, and should not try to guess IMHO.
(and it's just against my aesthetical sense to have paths like "../../../../../usr/include/gtk-2.0/gdk/gdkevents.h":)
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.
Of course not, and not to me either, since I'm a very recent member of the list. Enrico / Nick / Frank should decide on that - and the thread suggests that Nick is willing to allow some more integration.
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.
I remember the fields from gproject one, but something was bugging me...
- 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.
...and it finally came out at the top of my mind.
Why have per-project source / header list, instead of global? No matter the project, it's quite unlikely that a .c file will ever become a header, or .h will be source. You can move Source and Header files at plugin level, put there long lists of well-known source and header files, and let the user edit them.
In short:
gproject plugin - global list of source and header types, for swapping and icons
geany project - all patterns for the current project; most of them will match some source or header type
gproject project - ignore dirs patterns
And so, the Geany project patterns will be used, instead of being overriden and locked (effectively disabled). As a side effect, the user types will only need to be classified as source / header once.
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.
I think someone already suggested it, but how about a single push button, with the Copy icon for example, that'll copy the project patterns in the edit field? Even make it "autoclick" when a project is loaded. Switching forth to Project and back to Custom seems a bit clumsy.
("All" should be "All files" IMO - it took me a few seconds to understand what it means, and a regular used will probably wounder.)
On Sun, Jul 11, 2010 at 15:19, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Fri, 9 Jul 2010 23:36:06 +0200 Jiří Techet techet@gmail.com wrote:
On Fri, Jul 9, 2010 at 19:49, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Sun, 4 Jul 2010 00:54:17 +0200
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.
The renaming of the main projects directory should be rare. But with alls path relative, any movement of the project up or down in the directory hierarhy will break all non-project paths, and movement at the same level can break some of them (for example moving the project directory from projects/ to backups/ will make the external files from other project invalid).
The reason to use relative paths is to preserve the project file names. What happens to the non-project files, we can not tell, and should not try to guess IMHO.
(and it's just against my aesthetical sense to have paths like "../../../../../usr/include/gtk-2.0/gdk/gdkevents.h":)
I wasn't against your idea - I just meant that all the possible problems should be considered in advance before doing any change.
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.
Of course not, and not to me either, since I'm a very recent member of the list.
Four months ago I actually didn't know there is Geany. Considering how good IDE it is, it's a real shame that it's not much more widespread - in my opinion it's because people just don't know about it. Geany definitely needs better marketing - maybe Enrico and Nick could start selling coffee mugs and T-shirts with Geany icon :-).
Enrico / Nick / Frank should decide on that - and the thread suggests that Nick is willing to allow some more integration.
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.
I remember the fields from gproject one, but something was bugging me...
- 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.
...and it finally came out at the top of my mind.
Why have per-project source / header list, instead of global? No matter the project, it's quite unlikely that a .c file will ever become a header, or .h will be source. You can move Source and Header files at plugin level, put there long lists of well-known source and header files, and let the user edit them.
In short:
gproject plugin - global list of source and header types, for swapping and icons
geany project - all patterns for the current project; most of them will match some source or header type
gproject project - ignore dirs patterns
This won't work. The main reason why the patterns are present is not to include as many files to the project as possible (one could use * then), but to get rid of as many uninteresting files as possible. In what you suggest all the source files would be visible in the project - but I don't want that. What I need is to see only those that I'm going to edit/search. A few examples:
1. At work with the project I'm working on all the source files have one of the following extensions: C, H, idl. From the CORBA idl files, headers with the h extension are generated. But I'll never want to search/edit these files so they shouldn't be included in this particular project. And of course there are other projects where I want to see files with the h extension.
2. Let's say you use automake for your project - in this case you want to see and edit only the Makefile.am files, not Makefile.in and Makefile. On the other hand, in a different project you don't use automake and want to edit Makefile directly.
3. For web applications the developers may want to see all .py .php files while web page designers want to see .html and .css for the very same project. And for a different project the developers may want to see all the files.
So in short, I won't implement it this way because it wouldn't fulfill my and other people's needs. (The default set of patterns could be made per-plugin configurable though.)
And so, the Geany project patterns will be used, instead of being overriden and locked (effectively disabled). As a side effect, the
Direct editing is disabled but they are editable by gproject - the resulting set of patterns is the union of the three fields in gproject. These (geany project) patterns are also saved in the project file so you won't lose them if you create a project by geany with gproject and open it later with geany without gproject installed.
user types will only need to be classified as source / header once.
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.
I think someone already suggested it, but how about a single push button, with the Copy icon for example, that'll copy the project patterns in the edit field? Even make it "autoclick" when a project is loaded. Switching forth to Project and back to Custom seems a bit clumsy.
The reason why I would prefer it the way I suggested is that if you select project, the patterns will be updated automatically whenever you load a project. I'm afraid that the "autoclick" feature would be more confusing/annoying if you specify your custom patterns and they get overwritten every time you load a project. On the other hand, when you select "project" in the combo box, you explicitly say that you want it this way.
("All" should be "All files" IMO - it took me a few seconds to understand what it means, and a regular used will probably wounder.)
Yes, whatever - this was just a quick idea how it might look like (I wanted to make the combo box as small as possible to have more space for the patterns).
Cheers,
Jiri
-- E-gards: Jimmy _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Mon, 12 Jul 2010 13:21:03 +0200 Jiří Techet techet@gmail.com wrote:
On Sun, Jul 11, 2010 at 15:19, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Fri, 9 Jul 2010 23:36:06 +0200
Why have per-project source / header list, instead of global? No matter the project, it's quite unlikely that a .c file will ever become a header, or .h will be source. You can move Source and Header files at plugin level, put there long lists of well-known source and header files, and let the user edit them.
This won't work. The main reason why the patterns are present is not to include as many files to the project as possible (one could use * then), but to get rid of as many uninteresting files as possible. In what you suggest all the source files would be visible in the project
- but I don't want that. [...]
Ah, my explanation wasn't clear enough. The global gproject pattern settings should _only_ be used to classify what files are source and what are header, since gproject needs this data. These settings are _not_ the project patterns. I'll refer to them as "extensions" (they should be probably implemented as patterns for flexibility).
The project patterns, OHOH, are entered as a single list in the Geany project patterns field (currently not displayed). gproject reads them, searches the project directory, and for each file found looks in the gproject h/s settings to classify it as "source", "header" or "other".
For example:
gproject sources - "*.c *.cpp *.s *.idl...", whatever list of well-known source extensions you come with.
gproject headers - "*.h *.hpp ...", personally I'll add "*.def *.dgl".
Geany patterns for a particular project: "*.c *.h Makefile.*".
Techically, in a such scheme Geany will fully support/control the project patterns which can be also be used by Geany FIF and and other plugins; while gproject will contain the file type classification, which is only used by gproject.
From users POV, I won't need to create 3 patterns for each project,
always specifying that "*.h" is header, "*.c" is source, and "Makefile.*" is other. The last pattern does not match any gproject directly; when using a separate build directory, I can even specify a single "*", and gproject will still classify the files properly. :)
The limitation of the global classification is, of course, that it's global. So you won't be able to specify "*.h" as header files for the normal projects, and as "source" for a specific project, like your first example (.idl -> .h). But in the example, you don't want to see them, and they are not real "source" files anywas. In fact, I know not of any "questionable" extensions, and my guess (which can of course be wrong) is that they are uncommon enough not to pose a problem for a single user.
I think someone already suggested it, but how about a single push button, with the Copy icon for example, that'll copy the project patterns in the edit field? Even make it "autoclick" when a project is loaded. Switching forth to Project and back to Custom seems a bit clumsy.
The reason why I would prefer it the way I suggested is that if you select project, the patterns will be updated automatically whenever you load a project. I'm afraid that the "autoclick" feature would be more confusing/annoying if you specify your custom patterns and they get overwritten every time you load a project.
The custom patterns will be saved in the history; when switching to another project, chances are that I'll want it's patterns, at least as a starting point for customization.
On the other hand, when you select "project" in the combo box, you explicitly say that you want it this way.
Yes. But to remove a single pattern, you need to select "Project" to fill the text entry, then "Custom", and only then edit the list.
Well, the 3-state combo is a bit clumsy and unusual, but I can live with that.
On Wed, Jul 14, 2010 at 21:11, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Mon, 12 Jul 2010 13:21:03 +0200 Jiří Techet techet@gmail.com wrote:
On Sun, Jul 11, 2010 at 15:19, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Fri, 9 Jul 2010 23:36:06 +0200
Why have per-project source / header list, instead of global? No matter the project, it's quite unlikely that a .c file will ever become a header, or .h will be source. You can move Source and Header files at plugin level, put there long lists of well-known source and header files, and let the user edit them.
This won't work. The main reason why the patterns are present is not to include as many files to the project as possible (one could use * then), but to get rid of as many uninteresting files as possible. In what you suggest all the source files would be visible in the project
- but I don't want that. [...]
Ah, my explanation wasn't clear enough. The global gproject pattern settings should _only_ be used to classify what files are source and what are header, since gproject needs this data. These settings are _not_ the project patterns. I'll refer to them as "extensions" (they should be probably implemented as patterns for flexibility).
The project patterns, OHOH, are entered as a single list in the Geany project patterns field (currently not displayed). gproject reads them, searches the project directory, and for each file found looks in the gproject h/s settings to classify it as "source", "header" or "other".
For example:
gproject sources - "*.c *.cpp *.s *.idl...", whatever list of well-known source extensions you come with.
gproject headers - "*.h *.hpp ...", personally I'll add "*.def *.dgl".
Geany patterns for a particular project: "*.c *.h Makefile.*".
Techically, in a such scheme Geany will fully support/control the project patterns which can be also be used by Geany FIF and and other plugins; while gproject will contain the file type classification, which is only used by gproject.
From users POV, I won't need to create 3 patterns for each project, always specifying that "*.h" is header, "*.c" is source, and "Makefile.*" is other. The last pattern does not match any gproject directly; when using a separate build directory, I can even specify a single "*", and gproject will still classify the files properly. :)
The limitation of the global classification is, of course, that it's global. So you won't be able to specify "*.h" as header files for the normal projects, and as "source" for a specific project, like your first example (.idl -> .h). But in the example, you don't want to see them, and they are not real "source" files anywas. In fact, I know not of any "questionable" extensions, and my guess (which can of course be wrong) is that they are uncommon enough not to pose a problem for a single user.
OK, I understand now. This would kind of work but I'm afraid there are some usability problems:
1. The list of known source extensions would have to be long. This isn't such a big problem for headers because there is a limited set of extensions used for headers, but there are lots of source file extensions. At least there should be all the extensions from filetype_extensions.conf and possibly others. Such a list makes it very hard to find whether the given extension is present so the user may easily re-introduce the same patterns several times making the list even longer.
2. Instead of one place where the user configures patterns there would be three different places now - the plugin configuration, and two tabs in the project properties dialog. It would be much easier for the user to get lost.
3. For human brain it is easier to understand union than intersection. With current gproject the list of project patterns is headers AND sources AND others. You clearly see what headers, sources others are. In what you propose it's not so clear:
headers = global_headers INTERSECT project_patterns, sources = global_sources INTERSECT project_patterns, others = project_patterns - global_sources - global_headers
4. From the above you can see you have very little control over the others patterns. Even though it's not the most important feature of the plugin, I like to keep the others list minimal to easily see some special files in the sidebar - these can be makefiles, installation scripts, documentation files - basically whatever the user considers special for the given project - and these can be different for different projects.
5. I still have some feeling that the global list might cause problems in certain situations. I can't give you any example though so maybe the feeling is just irrational...
So unless I get NACK from Nick, I would still prefer to be able to override the list of patterns from a plugin. But I'll keep your idea in mind as a backup solution.
I think someone already suggested it, but how about a single push button, with the Copy icon for example, that'll copy the project patterns in the edit field? Even make it "autoclick" when a project is loaded. Switching forth to Project and back to Custom seems a bit clumsy.
The reason why I would prefer it the way I suggested is that if you select project, the patterns will be updated automatically whenever you load a project. I'm afraid that the "autoclick" feature would be more confusing/annoying if you specify your custom patterns and they get overwritten every time you load a project.
The custom patterns will be saved in the history; when switching to another project, chances are that I'll want it's patterns, at least as a starting point for customization.
On the other hand, when you select "project" in the combo box, you explicitly say that you want it this way.
Yes. But to remove a single pattern, you need to select "Project" to fill the text entry, then "Custom", and only then edit the list.
Well, for a project you should specify those patterns that you want to use for searching most frequently. Manual overriding the patterns should not be common. On the other hand with the "project" option selected, you can be sure that whenever you load a project, the pattern list will correspond to the project and you don't have to think about updating patterns for the project. When no project is loaded, the "project" option does the same like "all" (the pattern entry becomes empty - I have fixed the "formally correct" feature so empty entry means "all").
I have the "project" option selected almost all the time - I don't have to care about updating patterns when a new project is loaded, it does a sane thing when no project is loaded and I search in customized patterns only rarely (e.g. when I want to search headers only) so it's no problem to switch from "project" to "custom" in these cases.
Well, the 3-state combo is a bit clumsy and unusual, but I can live with that.
Is it so unusual? I find it quite standard. I used the combo instead of radio button because it occupies less vertical space, but conceptually they are almost equivalent IMO.
Regards,
Jiri
-- E-gards: Jimmy _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Fri, 16 Jul 2010 15:14:04 +0200 Jiří Techet techet@gmail.com wrote:
On Wed, Jul 14, 2010 at 21:11, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Mon, 12 Jul 2010 13:21:03 +0200
The global gproject pattern settings should _only_ be used to classify what files are source and what are header, since gproject needs this data. These settings are _not_ the project patterns. I'll refer to them as "extensions" (they should be probably implemented as patterns for flexibility).
The project patterns, OHOH, are entered as a single list in the Geany project patterns field (currently not displayed). gproject reads them, searches the project directory, and for each file found looks in the gproject h/s settings to classify it as "source", "header" or "other".
OK, I understand now. This would kind of work but I'm afraid there are some usability problems:
- The list of known source extensions would have to be long. This
isn't such a big problem for headers because there is a limited set of extensions used for headers, but there are lots of source file extensions. At least there should be all the extensions from filetype_extensions.conf and possibly others. Such a list makes it very hard to find whether the given extension is present so the user may easily re-introduce the same patterns several times making the list even longer.
Yes, that's why a proposed a buildin list at first. That is, the plugin source contains the lots of well-known source/header extensions, and the edit fields are only used for appending (or overriding, for example .h in the sources field).
- Instead of one place where the user configures patterns there would
be three different places now - the plugin configuration, and two tabs in the project properties dialog. It would be much easier for the user to get lost.
The file type configuration should be rare. With buildin types, edit fields should suffice, if that's what you mean by two tabs.
- For human brain it is easier to understand union than intersection.
With current gproject the list of project patterns is headers AND sources AND others. You clearly see what headers, sources others are. In what you propose it's not so clear:
headers = global_headers INTERSECT project_patterns, sources = global_sources INTERSECT project_patterns, others = project_patterns - global_sources - global_headers
Yes. However, once the exotic extensions are entered in the gproject s/h fields, which is likely to happen with the first few projects, the user will only care about a single flat list. With per-project patterns, the s/h/o will have to be repeated for each new project.
- From the above you can see you have very little control over the
others patterns. Even though it's not the most important feature of the plugin, I like to keep the others list minimal to easily see some special files in the sidebar - these can be makefiles, installation scripts, documentation files - basically whatever the user considers special for the given project - and these can be different for different projects.
What is the problem? Just cut the project patterns to what you want for the project, others = _project_ - sources - headers. I gave an example with "*" only to signify that separating inclusion and classification adds some flexibility (like *.r* instead of *.rc *.rh)
So unless I get NACK from Nick, I would still prefer to be able to override the list of patterns from a plugin. But I'll keep your idea in mind as a backup solution.
We agree to disagree (always wanted to say that:) Needless to say, as the plugin author, the decision is yours.
Well, the 3-state combo is a bit clumsy and unusual, but I can live with that.
Is it so unusual? I find it quite standard. I used the combo instead of radio button because it occupies less vertical space, but conceptually they are almost equivalent IMO.
Unusual for a Find in files function, not by itself.
I quote like the current implementation and find Dimitar's suggestion confusing as well (I'm not sure I completely understood it even after reading the whole thread).
The current implementation however seems straight forward and intuitive to me.
Best regards.
On Sat, 17 Jul 2010 13:11:22 +0200 Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
I quote like the current implementation and find Dimitar's suggestion confusing as well (I'm not sure I completely understood it even after reading the whole thread).
You enter a single list of patterns.
gproject searches for these patterns, and automatically recognizes the files found as source, header or other.
If something is not recognized, you go to gproject settings and add it to sources or headers.
On Fri, Jul 16, 2010 at 19:49, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Fri, 16 Jul 2010 15:14:04 +0200 Jiří Techet techet@gmail.com wrote:
On Wed, Jul 14, 2010 at 21:11, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Mon, 12 Jul 2010 13:21:03 +0200
The global gproject pattern settings should _only_ be used to classify what files are source and what are header, since gproject needs this data. These settings are _not_ the project patterns. I'll refer to them as "extensions" (they should be probably implemented as patterns for flexibility).
The project patterns, OHOH, are entered as a single list in the Geany project patterns field (currently not displayed). gproject reads them, searches the project directory, and for each file found looks in the gproject h/s settings to classify it as "source", "header" or "other".
OK, I understand now. This would kind of work but I'm afraid there are some usability problems:
- The list of known source extensions would have to be long. This
isn't such a big problem for headers because there is a limited set of extensions used for headers, but there are lots of source file extensions. At least there should be all the extensions from filetype_extensions.conf and possibly others. Such a list makes it very hard to find whether the given extension is present so the user may easily re-introduce the same patterns several times making the list even longer.
Yes, that's why a proposed a buildin list at first. That is, the plugin source contains the lots of well-known source/header extensions, and the edit fields are only used for appending (or overriding, for example .h in the sources field).
- Instead of one place where the user configures patterns there would
be three different places now - the plugin configuration, and two tabs in the project properties dialog. It would be much easier for the user to get lost.
The file type configuration should be rare. With buildin types, edit fields should suffice, if that's what you mean by two tabs.
- For human brain it is easier to understand union than intersection.
With current gproject the list of project patterns is headers AND sources AND others. You clearly see what headers, sources others are. In what you propose it's not so clear:
headers = global_headers INTERSECT project_patterns, sources = global_sources INTERSECT project_patterns, others = project_patterns - global_sources - global_headers
Yes. However, once the exotic extensions are entered in the gproject s/h fields, which is likely to happen with the first few projects, the user will only care about a single flat list. With per-project patterns, the s/h/o will have to be repeated for each new project.
The problem is that you still have to remember that there are some global options and what patterns are set there and possibly have to update the other settings too. Also this would make your project settings unportable - if you move your project file somewhere (or to someone) else, you'll have to re-set the global options on the other machine too to see the same.
- From the above you can see you have very little control over the
others patterns. Even though it's not the most important feature of the plugin, I like to keep the others list minimal to easily see some special files in the sidebar - these can be makefiles, installation scripts, documentation files - basically whatever the user considers special for the given project - and these can be different for different projects.
What is the problem? Just cut the project patterns to what you want for the project, others = _project_ - sources - headers. I gave an example with "*" only to signify that separating inclusion and classification adds some flexibility (like *.r* instead of *.rc *.rh)
No, what I'm talking about is when you want to see some files, but want to see them as others instead of sources/headers. For instance, the pattern *.sh will be stored in the global options in the sources field. In some projects you want to see these files really as sources, but in others these will be just some auxiliary scripts used for e.g. setting up the build environment and you'll want to see them as "others". No problem with gproject, but would be a problem with what you propose.
So unless I get NACK from Nick, I would still prefer to be able to override the list of patterns from a plugin. But I'll keep your idea in mind as a backup solution.
We agree to disagree (always wanted to say that:) Needless to say, as the plugin author, the decision is yours.
I understand what you have in mind but when thinking about it I'm afraid that it might bring more confusion/inflexibility than the current state.
When talking about bad news, I'm afraid I have also discarded your idea with bookmark folders. I want to keep the plugin simple and straightforward and again I'm afraid the "virtual" folders might bring more bad than good. Now the sidebar displays just the filtered list of project files and I want to keep it as simple as that without any extra settings.
Cheers,
Jiri
Well, the 3-state combo is a bit clumsy and unusual, but I can live with that.
Is it so unusual? I find it quite standard. I used the combo instead of radio button because it occupies less vertical space, but conceptually they are almost equivalent IMO.
Unusual for a Find in files function, not by itself.
-- E-gards: Jimmy _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel