Hi, thanks for the response. A few comments of mine below:
On Tue, Jun 8, 2010 at 03:03, Lex Trotman elextr@gmail.com wrote:
On 8 June 2010 07:38, Jiří Techet techet@gmail.com wrote:
Hi,
Hi, havn't had time to look at your code but a couple of comments below.
I would like to announce yet another project management plugin for geany. The main reason behind its creation is that I work with thousands of source files and the session-based "project" geany uses isn't sufficient for my purpose. I also had a look at geanyprj and while I like some of the ideas behind it, there are some things that don't fit my needs so I decided to create a new plugin (even though I took geanyprj as a base of the plugin, it has been completely rewritten). The things similar to geanyprj are:
- the location of the configuration file determines the root path of the project
- glob-like patterns are used to determine the files belonging to the
project (contrary to geanyprj this is the only way to set the files belonging to the project)
On the other hand, there are quite many differences:
- the project files are displayed in the form of a tree in the sidebar
(absolutely necessary for big projects)
- several projects can be opened simultaneously (one of them is the
active project, depending on the current document)
Geany is working towards proper multiple instance support which will allow you to have a different project in each instance, basic capability is in 0.19 and X session support (shutdown and restore the state of multiple instances on logout/login) in the future. Also gets you multiple windows on multiple screens.
OK, I understand. Still in certain situations it's better to have several different projects (here I mean project in the sense I understand it) opened in the single instance. Won't remove this feature ;-)
- you can specify patterns for source and header files separately -
there is a "swap header/source" functionality that finds the corresponding header/source to the currently opened document (same base name matching header/source pattern)
Nice, I'd like to add that to the filetype config to have it available in the base Geany, sometime :).
Should be pretty easy.
- in addition, you can specify "other" project files - headers,
sources and other files have different icons in the sidebar, which makes them easier to distinguish
- patterns can also be used to ignore some directories you don't want
to belong to the project (CVS, .git, ...)
- all the project files can be scanned for tags, but this can also be
disabled for big projects.
- there is a possibility to find a project file by name
- search in project files - the project file patterns are passed to
grep, which speeds up things considerably by not having to search the binaries
- many minor usability improvements
- works well for huge projects (I used linux kernel for testing it and
it works quite well if tag generation is disabled)
The sidebar has its own toolbar so most of the actions are available directly from there. The first item in the menu, Reload all, is probably the most important one - it automatically opens the corresponding project for all the opened files
Sorry, I'm not sure what you mean, do you mean, for a specified project, open all the files that were open last time you worked on the project??
No - what you say is done already by geany (it automatically opens the files that were open when you closed geany). What my plugin does (and actually what geanyprj does too) is that for each of the opened files it tries to find the project configuration file and load the project. If it doesn't find the project file in the directory where the source file is located, it tries the same in all its parent directories (the project configuration file has always the same name). Of course if the project is already opened, it doesn't reopen it again. It's the same way how git works - in whatever project directory you run git, it goes up in the directory structure and tries to find the .git directory.
(geanyprj does this
automatically, but for big projects this is rather annoying). In addition, there is a menu under Tools; however, the items in the menu are not supposed to be used from the menu - you should rather assign a keybinding for them as these are used frequently (header/source swapping, searching in project files, finding project file). Also there is a context menu for the items in the sidebar - the menu differs for different elements - projects, folders, files.
You can get the sources here:
Unfortunately, I had to make a few modifications to geany itself because its API just didn't provide the functionality I needed in several cases. I created a new geany project at gitorious:
(you may want to take it over and keep it up-to-date - it's better than your html-accessed git repository and allows external developers create their own clones [you may also want to switch to git completely
- it's so much better than svn
Personally I agree with this, but it depends on the developers preferences, how much control they have of their environments (one may still be on SVN 1.4), for example corporate Red Hat Enterprise environments can be a long way behind the bleeding edge, and depends on what capabilities their hosting system has.
Of course this is a matter of personal preference. Being an open source project maintainer myself, I find git a real help and I prefer if the contributors submit their patches by using git. And I don't think that there are really any technical reasons for not using git - I use SLES 9 at work and git compiles there just fine.
]). This is just a clone of the
mainline. Then there is my personal clone with the modifications:
http://gitorious.org/~techy/geany/techys-geany
There are four branches:
- gproject-deps - API additions required by gproject
- fixes - fixes that should be applied regardless of gproject
- changebar - this is just for those interested - I've ported the
changebar from codeblocks - something I can't live without. This however means to maintain a branch of scintilla and I'm not sure if this is something you want.
- all - all the above branches combined
(For those less familiar with git - these are remote branches and you have to create a remote tracking branch; type something like this after cloning the repository:
git checkout remotes/origin/all -b all
to checkout the "all" branch)
The sources aren't yet in the state I would normally require before making a release but I can see that geany release 0.19 is coming and it would be nice if it could include the API changes I've made.
Speaking for the main developers, its unlikely. There will not be time as the release is last weekend :) Ok, delayed to this weekend. And of course there can be no string impacts and I doubt that API changes will be accepted either.
Ah, OK, didn't know it was so close. On the other hand these are really just few-liners so might be worth considering. These are the requirements for gproject to work:
http://gitorious.org/~techy/geany/techys-geany/commit/6806f193b475e24dee649d...
http://gitorious.org/~techy/geany/techys-geany/commit/0b25a1225a7425ab7d726c...
http://gitorious.org/~techy/geany/techys-geany/commit/f11ab5f59cf4201d08f04f...
And this fix should definitely go to 0.19:
http://gitorious.org/~techy/geany/techys-geany/commit/62deb4ec5c2b8de4d0979c...
I think I didn't properly describe this one in the commit log - there is a 600ms interval in which the panel displaying the current file name isn't displayed. If you switch tabs with a keybinding and do it too quickly (press it twice in the 600ms period), the wrong file is put on top of the stack. The patch could be smaller but I found the code a little confusing so I tried to make it clearer a bit.
The few more patches are trivial ones. The changebar patch is meant just for testing and not for integration to 0.19.
Again, unless contradicted, you should submit your changes as individual patches, one per change with explanation, so they can be reviewed one at a time. Having to grab them all from your repository makes the job too big and less likely to happen.
Huh, really? What makes the job "too big" exactly? The reason why I submitted the patches this way is just the opposite - to make them easier to merge. You just "git pull" and that's it. As I said, as a maintainer of an open source project I prefer patches submitted this way but it's no problem for me to submit them in the traditional way (after all, anyone can do that by runing git format-patch after cloning the repository - I still don't see your point).
So
here are a few things which I feel would deserve some more attention:
- there are possibly some minor leaks - I have to go through the
sources carefully to make sure that I deallocate everything. There shouldn't be any dramatic leaks though.
- during the implementation I was just lazy to convert utf8 to locale
and back - it's present somewhere but there are places where I don't do that so if you have your sources with some locale characters, some things may not work
- no support for windows - this is something that someone else has to
do - I don't use windows myself
- no localization support yet - TODO
- for big projects I'd like to create some basic ctags support. The
tag manager used by geany is totally unusable for big projects because building the object hierarchy has quadratic to exponential complexity. I need a simple tag support that works in linear time.
Feel free to build it, and please make C++ template support work better :)
I'm absolutely not interested in improving the parsing - especially with C++ - you are almost guaranteed to fail - C++ is just too terrible language (which I use daily at work). maybe you could use LLVM's clang parser, but that might be too slow. I just want something that works in most cases and which is fast enough to handle about 10000 C++ source files. Tag manager used by geany isn't the one.
Comments and feature requests are welcome. However, beware that I want to keep the project management simple - I've spent quite a lot of time thinking how to keep it minimal. So while I'm sure there are many usability improvements possible, don't be too disappointed if I refuse your feature suggestion because I feel it complicates things too much. I really don't want to create Eclipse v2.
True!!
Finally, there are a few things I dislike about geany and that I'd wish to be addressed in some way:
- I'd like to have the same "rights" as the session-based project
support has. However, there are things I just can't do - I can't set the base directory where build is performed,
In 0.19 the working directory of a build can be set by the user, after that release it is intended that the next version of the build system will have a plugin API so that the plugin can set commands, other users want to do things like setting commands based on file contents and other "interesting" things. ;-S In fact because of the apparent complexity that the "set build commands" dialog will have, Geany will contain only a cut down version and the full dialog will be in a plugin.
To be honest, I find the new build dialog in 0.19 (and how it interacts with the session-project) pretty confusing - when you use it for the first time, you have no idea what it does (I had to look at the sources to be sure). It's quite against the overall geany spirit, where you just know immediately how things work. And "Non-Filetype Commands" belongs among the most absurd settings names I've ever seen.
I can't set per-project
indentation options and so on. (It's totally unclear to me how I'm supposed to use the GeanyProject structure - apparently it's meant to be read-only, but then what is it good for?)
It has to be read only because the code in Geany assumes that it meets certain invariants, if you could modify it you could break it. Same for build info for now. The guys are happy to consider requests for additions to the API, such as setting indentations, but please submit them early in the release cycle.
The best thing would be to make the current session-based project just an ordinary plugin - this way it would be guaranteed that all it uses is available for other plugins too.
- I find the session-based project conceptually wrong - having several
files opened doesn't mean that they belong to the same project - for instance I often work on several projects in parallel and have their files opened in parallel. Briefly, session != project
Depends on your definition of "project", for Geany a project is just a set of files that you are working on at one time, whether they reside in one tree or not. IIUC your definition is "files in one tree". Neither is "correct" just different.
I understand the semantics, but I don't understand why it isn't called "session". Of course you can call it project, but the rest of the world uses the the word project for something different. I would just use the same naming as everybody else does.
- Is there any technical reason why searches and builds cannot be
interrupted?
The short answer is yes.
The longer answer is that since the user can run any build tool it is generally not possible to guarantee safe killing of builds, so it isn't allowed in 0.19. Also just killing the head process isn't guaranteed to stop builds using remotes.
I don't really need that it's guaranteed that the program stops, but it would be good if geany at least tried. Sending SIGINT and SIGKILL two seconds later if the program does not stop would be fine with me.
It is understood that for large systems this is an annoyance, so in the next version of the build system it is intended to be configurable, off by default, but if you know what you are doing you can turn it on and define the action required, kill the process and/or run some command eg to stop the build farm.
Then geany should provide a way to tell me the PID of the process.
Jiri