[Geany-devel] GProject - the second attempt
nick.treleaven at xxxxx
Mon Jul 12 12:41:47 UTC 2010
On Fri, 9 Jul 2010 22:53:17 +0200
Jiří Techet <techet at 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:
> > 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.
> 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).
> > 2. 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:
> 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.
More information about the Devel