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

Lex Trotman elextr at xxxxx
Wed Jun 9 01:40:04 UTC 2010

Hi again,

Note I wasn't criticising your plugin, but wanted to make sure you
knew about some potential upcoming capabilities that might also be
useful in combination.

On 9 June 2010 02:59, Jiří Techet <techet at gmail.com> wrote:
> Hi, thanks for the response. A few comments of mine below:
> On Tue, Jun 8, 2010 at 03:03, Lex Trotman <elextr at gmail.com> wrote:
>> 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.
> 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 ;-)

Oh sure, I wasn't suggesting you should.

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

Coding is easy, time is hard

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

Ok, I see, I don't use Geanyprj so comparing to it didn't help :)

>>  (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.
> 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/6806f193b475e24dee649dfad854731342b30ebd
> http://gitorious.org/~techy/geany/techys-geany/commit/0b25a1225a7425ab7d726c80a93476694dee230b
> http://gitorious.org/~techy/geany/techys-geany/commit/f11ab5f59cf4201d08f04fef8cba40b54843625f
> And this fix should definitely go to 0.19:
> http://gitorious.org/~techy/geany/techys-geany/commit/62deb4ec5c2b8de4d0979c55f853f529efde223f
> 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.

Ok, up to the guys if they have time.

> The few more patches are trivial ones. The changebar patch is meant
> just for testing and not for integration to 0.19.

I'd like to suggest you tag commits you are going to refer to, not
leave them as hashes, which of the links above is this one?

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

The point is you are forcing people to clone your repo to get the patch.

Then, which commits are meant to be individual patches?

Since as I said above, treating the whole set as one change is less
acceptable than smaller individual patches, harder to review. Thats
what I meant by too big.

Sure its easier if everyone is using git, but ATM this is an SVN project.

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

Oh well, it was worth asking :D, if you don't ask you don't get.

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

As I said there is more of build-system changes to come after 0.19,
please provide input for how the dialog and the documentation (so you
don't have to read the source) can be improved (on another thread as
OT for this one).  Note the intention is that there will be a simple
and a full featured dialog, I doubt the full featured one will be
automatically usable without RTFM, but the simple one should be, so
all inputs that help getting to that situation are welcome.

 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.

Please explain why and alternatives, obviously I knew what I meant and
no one else criticised it (so far) so I need to understand why it
confuses you to be able to fix it.

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

If it was being added today, maybe it would be done that way, but now
it would be too much work for too little gain IMHO.

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

But session is also an overloaded term :), used to refer to the window
manager functionality, see also the sm branch which isn't related to
the Geany project functionality.

No one is going to win this argument, we have overloaded terms
throughout programming and will just have to live with them :(

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

Killing head process may not kill build, especially remote ones.  When
we last had discussions on this I happened to be consulting to a
company whose build servers had just this annoying characteristic so
can speak with sad authority.

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

Won't be needed when you can configure the kill into Geany, patience :D


> Jiri
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

More information about the Devel mailing list