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