[Geany-devel] [ANNOUNCE] gproject - yet another geany project plugin
techet at xxxxx
Wed Jun 9 15:13:24 UTC 2010
>> (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 :)
>> 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.
Of course I can't push to it but the project maintainers could pull
from me and push by themselves (for git projects typically only one
person has push rights, the others just ask the maintainer for pulling
from their tree and if he likes the patches, he pushes them to the
But you are right, I've overlooked that this is just a SVN mirror.
>> 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
>> 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.
And I dislike using non-standard solutions (as standard I consider
autotools, despite all its drawbacks), so we have a nice deadlock here
>> 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? ;-)
Not only one, but only _the_ one the user provides. The dialog should
look this way:
Build command: edit_box
Base directory: edit_box
so if I provide something like
Build command: make
Base directory: /home/techet/projects/geany
it would run:
(+ there should be a possibility to use the variables like %e, %f, ...)
> The update to the build system is to support running any commands,
> make,nmake, waf, scons, cmake, ant, bjam, my_favourite_shell_script
But the current build system (and the one present in 0.18) already
_can_ do that, see above. And yes, at work I use my own script that
based on the current file detects the current subsystem, runs other
necessary scripts and starts the build of the subsystem. Why do we
need the special cases as above?
> 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.
For this I would suggest just a list of build_command/base_directory
pairs that the user can save, load and delete.
>> 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
> 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 :).
Well, I find the way things work now pretty hacky. Geany is interested
in only about two or three members of the structure - the rest is
irrelevant for geany but still the whole structure has to be passed to
geany. If for these members there exist new accessing methods in the
API, the session-project should start using them too and geany should
use its own internal structure where only the needed members are used.
>> 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?
geany + gproject ;-)
What you need is to be able to quickly navigate between the files. For
this reason I had to fix the tab switching bug and introduced
You need to be able to filter out as many extra files as possible
(that's why only the files that match the pattern you provide are
included in the project).
You need fast searches in files. grep is pretty fast when you restrict
it only to the source files. So the plugin uses the patterns you
provide as a definition of the files belonging to the project and
automatically adds the restrictions as an extra potion in the find in
files dialog; e.g.
The first search is always slow, because the project files have to be
read from the disk. But the subsequent searches are pretty fast
because the files are already cached by the OS. So searching for
"torvalds" in the whole linux tree (only *.c and *.h files) takes just
about 3 seconds.
Then you need to be able to quickly find a file by name. In my plugin
you can use an arbitrary glob pattern for that (the leading and
trailing * are inserted for you so you just need to type a part of the
Also building the file tree should be as fast as possible. Again, this
is relatively slow when you open the project for the first time, but
any subsequent project opening is very fast (2 seconds for linux
kernel, from this only about 0.5 second creating the file tree).
Also there is also a feature that the selected file in the file tree
automatically follows the currently opened file - so the tree
automatically expands and locates the current file for you - this
simplifies locating the current subsystem.
And most importantly, the editor should be relatively sane and not to
try to reparse the whole project every time you edit or save something
- 100pct CPU usage is guaranteed all the time in this case.
The current geany attempt to project is not good enough - I can't open
10000 files. On the other hand, geany doesn't provide a good enough
way how to quickly access non-opened files, which is the purpose of my
>> 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
> 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
> 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 :) )
I absolutely don't wish to replace the current system - it's OK for
simple use cases (the reason why I wanted to make it plugin was to
make absolutely sure that the API contains all the required
functionality for whatever project management plugin). I only wish to
create an alternative project management that works well with huge
projects. All I want is that I can do the same things as the current
session-project does - which I can't now (and also if there was just
me, I would rename the current project to "session" and gproject to
And my plugin keeps simple things simple - I hope one day in the
future some brave man will actually test it to see...
>> (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
Like now? There is nothing like that now AFAIK.
More information about the Devel