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

[Jiří Techet]

On Wed, Jun 9, 2010 at 03:40, Lex Trotman <elextr at gmail.com> wrote:
> 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.

I absolutely understand. In fact, I prefer critical voices - it makes
no sense to say each other how good we are (we know that already,
don't we ;-). So please take also my comments in this sense.

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

Was rather joke from my side. On the other hand "removing features"
was the way I developed the plugin - originally I planned many more
features but then ended with a minimal consistent set of features that
play well with the rest of geany.

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

Very true.

(But the coding part applies for reasonably small and simple projects
like geany, not multithreaded, multiprocess, multiserver projects
communicating using CORBA consisting of thousands of source files,
which is something I have to work with at work).

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

Sure.

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

None ;-). Instead of tags I created different branches (described in
my original mail) - if you want to quickly see what's in the branches,
just click the branch name here:

http://gitorious.org/~techy/geany/techys-geany

(branches: changebar fixes gproject-deps all) The first three links
are from the gproject-deps branch and the last one from the fixes
branch. The changebar is, not surprisingly, in the changebar branch.

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

The master branch is equivalent to geany mainline, the branches
contain my patches (quite a standard way how to submit patches with
git). My repo is a clone of the geany project I've created here:

http://gitorious.org/geany

It would be best if this was taken over by the geany developers and
kept up to date with the current mainline.

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

Well, there is no "whole set" there - the individual patches are in
the form of commits.

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

It's true that I've used the workflow typical for a git project - from
geany web page, which offers both git and SVN repository I assumed
that I can chose either of them. If git is not supposed to be used,
then it should be removed from there because this makes things
confusing (or at least there should be a warning saying: "Don't use
the following git repository").

Anyway, no problem for me to provide the changes in the form of
individual patches. I'll just wait for the main developer's opinion on
this before spamming with additional emails.

I can see that there are people here not so much familiar with git, so
I'll just describe in more detail how to get the modified geany and
the plugin (the following gets the "all" branch that contains all the
patches):

For geany, do the following:

git clone git at gitorious.org:~techy/geany/techys-geany.git
cd to the downloaded directory
git checkout remotes/origin/all -b all
build and install geany

For the plugin do the following:

git clone git at gitorious.org:gproject/mainline.git
cd to the downloaded directory
./autogen.sh; make; sudo make install

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

Well, what I dislike is that there is _any_ build dialog like this in
geany. The only thing that should be possible is to:

1. run a user provided command
2. in the user provided (base) directory

(And this is basically what geany used to do before 0.19) Plugins
should be allowed to change these two depending on their needs (not
possible now). Period. Nothing more. For more complex projects you
should use makefiles so the user provided command will be "make"
executed in the base directory of the project.

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

The most important thing is that geany stops accessing GeanyProject
struct directly. It should be the project that requests e.g. setting
the base directory, not geany reading it from the project's data
structures. But this is pretty easy to fix - I can do that (and
possibly convert the current project to plugin) if there is general
interest in that.

>>>
>>>> * 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 :(
>

Sure, the last thing I want is to start a flame war on this topic. I
was just expressing my opinion about the naming - I would still call
the current project "session" (see my response to Dimitar why), but
this is really not that important.

And to be clear, I'm not saying that the way the project support works
now is completely wrong either. I can imagine it works pretty well for
small projects like geany itself. At university I was using SciTE as
the editor for everything and it was just fine (yes, and SciTE calls
the thing "session" ;-). But for projects with thousands of source
files and hundreds of directories it's just no fun, believe me. And
neither eclipse nor codeblocks work well for such big projects because
they do crazy "automatic" things that are supposed to "simplify your
life". I have submitted many patches for codeblocks until I realized
it's just unfixable in principle. And back then I just had no idea
that there is such a nice editor like geany (it really needs better
marketing!).

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

Good to hear it is being worked on (and that it won't have to be me
who implements this ;-).

(I'm pretty curious how you're going to kill the remote builds.)

Cheers,

Jiri

> Cheers
> Lex
>