Hi
I think current project management is really suck. It annoy more then help at least for my needs.
Why do I need project management in the first place: 1) Ability to run build commands aka make from base project path 2) Ability to use custom run command for project 3) Ability to have tags for files in project (make Go to Tag Definition/Declaration works) 4) Ability to share project with other people who also work on project
I belive current project manager fails completely on 3, 4
Also it is just me but I have to work with a lot of small projects and all this "Open/Close" commands are annoying.
That is the problem.
Now about solution:
For example we have 2 projects "a", "c" and file without project plans.txt:
~/projects/a/a.c ~/projects/a/.geanyprj ~/projects/a/nested/b.c ~/projects/c/c.c ~/projects/c/.geanyprj ~/plans.txt
If you try to open ~/projects/a/nested/b.c geany will find ~/projects/a/.geanyprj and load it as currebt project since file b.c belong to project.
.geanyprj should contains information about project base dir, and files that in project for example for "a":
[project] base_dir=./ run_cmd=./a [files] file0=./*.c:recursive file1=./*.h:recursive
if you open or change current tab to ~/projects/c/c.c geany will close project "a" and open ~/projects/c/.geanyprj as current project.
if you open plans.txt it should just close current project.
Switching projects should regenerate and load TAGS for all project files. (killer feature "Go to Tag" should work for all files in project not for just opened ones)
I am going to implement this as plugin. Any comments?
Best regards, Yura Siamashka
Hi
sources for new project plugin are here:
git clone git://repo.or.cz/geanyprj.git
or
git clone http://repo.or.cz/r/geanyprj.git
Plugin is in early development stage, but it is already can be used to provide custom build dir.
To geany devs: Please, apply attached patch, it adds few utils functions needed by this plugin to api.
Best regards, Yura Siamashka
On Sun, 23 Dec 2007 14:00:20 +0200, Yura Siamashka yurand2@gmail.com wrote:
Hi,
Also it is just me but I have to work with a lot of small projects and all this "Open/Close" commands are annoying.
That is the problem.
Now about solution:
For example we have 2 projects "a", "c" and file without project plans.txt:
~/projects/a/a.c ~/projects/a/.geanyprj ~/projects/a/nested/b.c ~/projects/c/c.c ~/projects/c/.geanyprj ~/plans.txt
If you try to open ~/projects/a/nested/b.c geany will find ~/projects/a/.geanyprj and load it as currebt project since file b.c belong to project.
.geanyprj should contains information about project base dir, and files that in project for example for "a":
[project] base_dir=./ run_cmd=./a [files] file0=./*.c:recursive file1=./*.h:recursive
if you open or change current tab to ~/projects/c/c.c geany will close project "a" and open ~/projects/c/.geanyprj as current project.
if you open plans.txt it should just close current project.
IMO this shouldn't happen because then a project is closed everytime the user loads a file which doesn't belong to the project. This would probably more confuse than help.
Switching projects should regenerate and load TAGS for all project files. (killer feature "Go to Tag" should work for all files in project not for just opened ones)
This would be cool.
I am going to implement this as plugin. Any comments?
Why doing this against us? Why implementing it improved porject support with us? Whether as a plugin which extends current features or by adding new features directly in Geany(by patches and/or svn write access). I think an "alternate project support" like in the GIT repo description isn't the best idea.
Regards, Enrico
Hi
On Tue, Dec 25, 2007 at 03:09:00PM +0100, Enrico Tröger wrote:
On Sun, 23 Dec 2007 14:00:20 +0200, Yura Siamashka yurand2@gmail.com wrote:
Hi,
Also it is just me but I have to work with a lot of small projects and all this "Open/Close" commands are annoying.
That is the problem.
Now about solution:
For example we have 2 projects "a", "c" and file without project plans.txt:
~/projects/a/a.c ~/projects/a/.geanyprj ~/projects/a/nested/b.c ~/projects/c/c.c ~/projects/c/.geanyprj ~/plans.txt
if you open or change current tab to ~/projects/c/c.c geany will close project "a" and open ~/projects/c/.geanyprj as current project.
if you open plans.txt it should just close current project.
IMO this shouldn't happen because then a project is closed everytime the user loads a file which doesn't belong to the project. This would probably more confuse than help.
Here is why I need it.
At work I develop custom linux distributive, it have a lot of packages:
./scripts/unittests.sh ./scripts/build-image.sh ./packages/a/src/a.c ./packages/a/makefile ./packages/b/src/b.c ./packages/b/makefile
Usually after changing something in package "a", I want to run scripts that doesn't belong to "a" (unittests.sh).
So the idea is: While I change something in package "a", I execute "a" on F5, run makefile from ./packages/a (enjoy all good stuff project manager provide), when I edit something in "b" F5 will run "b". But when I switch to ./scripts/unittests.sh, I expect F5 to run unit tests for all projects. And I want it all without manually open/close projects.
I am going to implement this as plugin. Any comments?
Why doing this against us? Why implementing it improved porject support with us? Whether as a plugin which extends current features or by adding new features directly in Geany(by patches and/or svn write access).
I do not do this against you and in fact I really can't. "go to tag" feature surelly will require a lot of geany changes. The reasons why I don't want to mess with project manager code in geany tree are:
1) My view of project manager is different from yours. I don't want to argue or try to convince anyone that my view is better until I have something working to show. 2) If I just send patches to you it takes too much time to get them in geany tree. (I expect a lot of them, and since 1) you probably will not want to apply some of them) 3) I can't just extend current proj management because some of it's the features conflict with my view. (For example I don't think close tabs on project close is good idea).
I don't say my project view is necessery better then current for anyone, it is just different. That is why "alternative project support".
I think an "alternate project support" like in the GIT repo description isn't the best idea.
This is the first idea that come to my head ;-)
Best regards, Yura Siamashka
On Wed, 26 Dec 2007 00:56:28 +0200, Yura Siamashka yurand2@gmail.com wrote:
Hi
On Tue, Dec 25, 2007 at 03:09:00PM +0100, Enrico Tröger wrote:
On Sun, 23 Dec 2007 14:00:20 +0200, Yura Siamashka yurand2@gmail.com wrote:
Hi,
Also it is just me but I have to work with a lot of small projects and all this "Open/Close" commands are annoying.
That is the problem.
Now about solution:
For example we have 2 projects "a", "c" and file without project plans.txt:
~/projects/a/a.c ~/projects/a/.geanyprj ~/projects/a/nested/b.c ~/projects/c/c.c ~/projects/c/.geanyprj ~/plans.txt
if you open or change current tab to ~/projects/c/c.c geany will close project "a" and open ~/projects/c/.geanyprj as current project.
if you open plans.txt it should just close current project.
IMO this shouldn't happen because then a project is closed everytime the user loads a file which doesn't belong to the project. This would probably more confuse than help.
Here is why I need it.
At work I develop custom linux distributive, it have a lot of packages:
./scripts/unittests.sh ./scripts/build-image.sh ./packages/a/src/a.c ./packages/a/makefile ./packages/b/src/b.c ./packages/b/makefile
Usually after changing something in package "a", I want to run scripts that doesn't belong to "a" (unittests.sh).
So the idea is: While I change something in package "a", I execute "a" on F5, run makefile from ./packages/a (enjoy all good stuff project manager provide), when I edit something in "b" F5 will run "b". But when I switch to ./scripts/unittests.sh, I expect F5 to run unit tests for all projects. And I want it all without manually open/close projects.
Ok, this would indeed need some changes in the current implementation. Maybe we could add a separate run command just for projects. But not sure whether this is commonly needed.
I am going to implement this as plugin. Any comments?
Why doing this against us? Why implementing it improved porject support with us? Whether as a plugin which extends current features or by adding new features directly in Geany(by patches and/or svn write access).
I do not do this against you and in fact I really can't. "go to tag" feature surelly will require a lot of geany changes. The reasons why I don't want to mess with project manager code in geany tree are:
- My view of project manager is different from yours. I don't want
to argue or try to convince anyone that my view is better until I have something working to show. 2) If I just send patches to you it takes too much time to get them in geany tree. (I expect a lot of them, and since 1) you probably will not want to apply some of them) 3) I can't just extend current proj management because some of it's the features conflict with my view. (For example I don't think close tabs on project close is good idea).
I don't say my project view is necessery better then current for anyone, it is just different. That is why "alternative project support".
Ok, I'm getting convinced and I'm excited how it will be. Maybe we can move parts from it later to back into Geany or whatever.
Regards, Enrico