Hi,
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 :)
NI !
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 main repository).
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 patches):
For geany, do the following:
git clone git@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@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:
- run a user provided command
- 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:
cd /home/techet/projects/geany make
(+ 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 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 :).
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 header/source swapping.
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.
--include=*.c --include=*.h
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 file name).
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 plugin.
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 :) )
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 "project" :-)
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.
Jiri