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

[Lex Trotman]

On 9 June 2010 21:06, Jiří Techet <techet at gmail.com> wrote:
> 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:
>

My misunderstanding

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

That seems a bit confusing, maybe we should call them all Bruce (Monty
Python reference :)

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

It does say read only, I'd take that as meaning you can't push to this.

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

Good idea.

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

Sigh, this isn't your fault, but I have problems with installing
unknown software to system directories and plugins autofools is broken
WRT installing to a non-standard prefix, waf build works if your
plugin had a wscript.

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

As I said coming, patience :-)

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

In another post on this thread you complain about IDEs that limit how
projects work (agree completely BTW), but you would restrict Geany to
only one build tool? ;-)

The update to the build system is to support running any commands,
make,nmake,  waf, scons, cmake, ant, bjam, my_favourite_shell_script
etc so the "Non-filetype commands" can't be called "make commands"
anymore, and unfortunately the name "Build" has been appropriated for
link, other suggestions welcome though, but there aren't many commonly
understood terms about.

It is also to allow the commands to be configured differently for
different projects, since, if you use software from lots of sources,
you get lots of build systems.

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

I'm not quite sure what you mean, sure your plugin needs to be able to
set the project base directory and API is needed for that.  So you
will be requesting a change to the setting.  That anything in Geany
that uses this info reads it from a structure called a GeanyProject
seems irrelevant, it has to be somewhere :).

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.

Yes its good at this.

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.

I can believe its not good at this. Is anything?

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

Yes, its the usual problem of the developers having one use case in
mind, but because its good, finding that their tool gets used in much
wider set of use cases.  Therefore no-one has thought of making some
parts of the system open for plugins, its not poor design, just
progress.

OTOH I don't see why you want to take out the current project system,
it shouldn't get in your way, but if it does ask about changes, and
having a built in simple system for simple uses is important.  Keeping
simple things simple is a reason for further work on the build system
so your simple needs are met by default, but my complicated ones are
possible with a plugin. (oh and your complicated one for killing
builds :) )

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

Only on *ix, on windows a "Pid" is an opaque pointer.

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

I won't, the default will be to kill the head process like now, but
the user can select to run a command instead. Which, of course, they
can configure to run whatever command stops their build servers, after
all they had to configure the command or build script that started
them.

Keeps Geany lightweight and not dependent on anything.  And should
work on windows.

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