On Fri, 9 Jul 2010 22:53:17 +0200 Jiří Techet <tec...@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: > > 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 _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel