[Geany-devel] [ANNOUNCE] gproject - yet another geany project plugin

[Lex Trotman]

On 8 June 2010 07:38, Jiří Techet <techet at 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.

> * 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 :).

> * 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??

 (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:
>
> http://gitorious.org/gproject
>
> 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:
>
> http://gitorious.org/geany
>
> (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.

]). 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.

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.

 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 :)

>
> 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.

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.

> * 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.

> * 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.

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.

 It's pretty annoying because the build of some of the
> subsystems of the project I'm working on takes half an hour and I want
> to be able to interrupt it when I start the build by accident.
>
> And there are lots of things I _like_ about geany - especially that
> it's so lightweight, yet powerful

Agree, thats also why I contribute.

 - this is why I found it worth
> spending my time creating the plugin. Thanks for the nice editor and
> tell me your opinion about my plugin!
>
> Cheers,
>
> Jiri
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>