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