Hi again,
<snip>
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 :-).
Your prerogative, but it means that I won't test your plugin.
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
Ummmm, thats what the command and working directory columns are
so if I provide something like
Build command: make Base directory: /home/techet/projects/geany
it would run:
cd /home/techet/projects/geany
Unix only, not portable, thats why the working directory isn't done that way.
make
So you don't want make object or make target???
If you do have them then you need to be able to define where the arguments and options go on each of these build commands.
Builders other than make require options and arguments in different orders, thats what started the whole build system update in the first place, the arguments Geany 0.18 pasted didn't work for some builders.
So the dialog allows the whole command to be configured, and since you are not running make any more, it allows the menu label to be changed to say what you are doing.
(+ 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?
See 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.
Thats exactly what the project preferences build tab is.
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 ;-)
As we say here, this has been a paid political advertisement :-)
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.
As I said before, I'm not saying there is anything wrong with your plugin, I can see the need.
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...
See why not above.
(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.
Sorry to confuse, I meant like the execute menu items do now.
Cheers Lex
Jiri _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel