Hi Enrico/Nick et al
I have a question regarding the project management facility in geany. I already apologize for asking questions that probably have been answered already and suggesting features that are already implemented...
So far, the project management seems to simply let you define the base path of your project, and the svndiff plugin now seems to honour this (works great, thanks).
But I'm not sure where else in geany the project definition is used.
If I open a project, create a new file and want to save it, the save dialog seems not to make use of the project base and sets the default path to the invocation directory. Wouldn't it be fabulous if geany would use the active project's base path as default? Unless of course if the current directory is a subdirectory of the project's default.
Some more great ideas I have:
It would be nice if the project definition would let you override certain defaults of the configuration, so when you open the project, they would be used instead. I'm thinking of stuff like: - Default characterset for new files - Tab width - Tabs/Spaces intendation - Line wrapping - Folding/autocompletion settings
Is stuff like this planned?
Bye and thanks once more for geany, I can't even think back to the time I had to do programming with another editor.
Tim
On 26/10/07 13:27:59, Tim Tassonis wrote:
Hi Enrico/Nick et al
I have a question regarding the project management facility in geany. I already apologize for asking questions that probably have been answered already and suggesting features that are already implemented...
No need, that's what the ML is for ;-) If the same questions come up a lot, it's often a sign that we can improve things, when we have time.
So far, the project management seems to simply let you define the base path of your project, and the svndiff plugin now seems to honour this (works great, thanks).
But I'm not sure where else in geany the project definition is used.
The base path is currently used for the make directory and run command directory.
If I open a project, create a new file and want to save it, the save dialog seems not to make use of the project base and sets the default path to the invocation directory. Wouldn't it be fabulous if geany would use the active project's base path as default? Unless of course if the current directory is a subdirectory of the project's default.
Good idea, I'll add this sometime.
Some more great ideas I have:
It would be nice if the project definition would let you override certain defaults of the configuration, so when you open the project, they would be used instead. I'm thinking of stuff like:
- Default characterset for new files
- Tab width
- Tabs/Spaces intendation
These ones probably will be added sometime. For existing files, you might like the new 'Detect from file' tabs/spaces setting in SVN.
- Line wrapping
I'm not sure about this one. I see that if you had a project that was all plain text files it might be useful, but it's not a 'standard'-type project issue. Perhaps it would be better if there was a different feature, e.g. setting line wrapping if too many long lines are detected.
- Folding/autocompletion settings
Not sure about folding settings - what do you mean?
For autocompletion, wouldn't the keynames still be useful for the whole filetype, not just a project? Maybe you could give an example.
Is stuff like this planned?
Yes, but (at least from my point of view) there are other things I want to work on first.
Regards, Nick
On 10/26/07, Nick Treleaven nick.treleaven@btinternet.com wrote:
On 26/10/07 13:27:59, Tim Tassonis wrote:
So far, the project management seems to simply let you define the base path of your project, and the svndiff plugin now seems to honour this (works great, thanks).
But I'm not sure where else in geany the project definition is used.
The base path is currently used for the make directory and run command directory.
If I open a project, create a new file and want to save it, the save dialog seems not to make use of the project base and sets the default path to the invocation directory. Wouldn't it be fabulous if geany would use the active project's base path as default? Unless of course if the current directory is a subdirectory of the project's default.
Good idea, I'll add this sometime.
Although I'm generally not big a fan of IDE's, in the past when I've set up "projects" with them, it worked differently than with Geany. In other IDE's, often a .proj file is used in a given directory to signify to the IDE that that directory contains a "project".
The .proj file contained information about what files were in the project, along with other special project-specific settings. Because it's got the list of files for a given project, it also opens the possibility of displaying a logical "project browser" (showing a logical layout of all the modules/classes/functions in the project). What's very handy is that you can make any source directory into a "project" without having to group all projects into the same top-level project directory. This seems to make projects quite portable, and also allows you to easily version the .proj file along with your other source code.
Just curious: why does Geany use its more centralized model? It seems less convenient, but maybe I'm not seeing other reasons it's the way it is.
---John
On Fri, 26 Oct 2007 13:44:42 -0400, "John Gabriele" jmg3000@gmail.com wrote:
On 10/26/07, Nick Treleaven nick.treleaven@btinternet.com wrote:
On 26/10/07 13:27:59, Tim Tassonis wrote:
So far, the project management seems to simply let you define the base path of your project, and the svndiff plugin now seems to honour this (works great, thanks).
But I'm not sure where else in geany the project definition is used.
The base path is currently used for the make directory and run command directory.
If I open a project, create a new file and want to save it, the save dialog seems not to make use of the project base and sets the default path to the invocation directory. Wouldn't it be fabulous if geany would use the active project's base path as default? Unless of course if the current directory is a subdirectory of the project's default.
Good idea, I'll add this sometime.
Although I'm generally not big a fan of IDE's, in the past when I've set up "projects" with them, it worked differently than with Geany. In other IDE's, often a .proj file is used in a given directory to signify to the IDE that that directory contains a "project".
The .proj file contained information about what files were in the project, along with other special project-specific settings. Because it's got the list of files for a given project, it also opens the possibility of displaying a logical "project browser" (showing a logical layout of all the modules/classes/functions in the project). What's very handy is that you can make any source directory into a "project" without having to group all projects into the same top-level project directory. This seems to make projects quite portable, and also allows you to easily version the .proj file along with your other source code.
Just curious: why does Geany use its more centralized model? It seems less convenient, but maybe I'm not seeing other reasons it's the way it is.
Geany's way isn't that different. We don't store a concrete list of files belonging to the project. Once we decided to not do it. Some of the reasons: - no real need to - easier use for the user who don't have to maintain another file list for his project(besides file lists of other tools like autotools or the like) - easier implementation
But the location of the project file itself is only by default in a centralised directory(~/projects). This is only a suggestion and can be changed by the user as needed. Furthermore, there is no need to keep the project file outside of the project base path.
Since SVN r1984, you can also set base path relative to the project's file name and so it's quite easy to use the generated project file (file extension: .geany) among different systems.
Regards, Enrico
Nick Treleaven wrote:
On 26/10/07 13:27:59, Tim Tassonis wrote:
Hi Enrico/Nick et al
So far, the project management seems to simply let you define the base path of your project, and the svndiff plugin now seems to honour this (works great, thanks).
- Line wrapping
I'm not sure about this one. I see that if you had a project that was all plain text files it might be useful, but it's not a 'standard'-type project issue. Perhaps it would be better if there was a different feature, e.g. setting line wrapping if too many long lines are detected.
- Folding/autocompletion settings
Not sure about folding settings - what do you mean?
Just whether to enable/disable folding.
For autocompletion, wouldn't the keynames still be useful for the whole filetype, not just a project? Maybe you could give an example.
Same here, just whether to do it or not.
I was basically just going over the Properties settings and picked the ones that I thought could be dependable on different projects.
My idea was that you could just override some default settings if in a project you want geany to behave differently, not more.
Like when you do ruby, you use two spaces for indentation, while in C you use tabs and so on.
Tim
On Fri, 26 Oct 2007 21:13:32 +0200, Tim Tassonis timtas@cubic.ch wrote:
Nick Treleaven wrote:
On 26/10/07 13:27:59, Tim Tassonis wrote:
Hi Enrico/Nick et al
So far, the project management seems to simply let you define the base path of your project, and the svndiff plugin now seems to honour this (works great, thanks).
- Line wrapping
I'm not sure about this one. I see that if you had a project that was all plain text files it might be useful, but it's not a 'standard'-type project issue. Perhaps it would be better if there was a different feature, e.g. setting line wrapping if too many long lines are detected.
- Folding/autocompletion settings
Not sure about folding settings - what do you mean?
Just whether to enable/disable folding.
Is it really necessary on a per-project base? I think folding is a code-independent feature which is mainly dependent on the user and whether he likes it or not,.
For autocompletion, wouldn't the keynames still be useful for the whole filetype, not just a project? Maybe you could give an example.
Same here, just whether to do it or not.
Similar as above, I don't think this is really necessary to be changeable for each project.
My idea was that you could just override some default settings if in a project you want geany to behave differently, not more.
Yes, we will add some settings this way at some time.
Regards, Enrico
Hi Enrico
- Line wrapping
I'm not sure about this one. I see that if you had a project that was all plain text files it might be useful, but it's not a 'standard'-type project issue. Perhaps it would be better if there was a different feature, e.g. setting line wrapping if too many long lines are detected.
- Folding/autocompletion settings
Not sure about folding settings - what do you mean?
Just whether to enable/disable folding.
Is it really necessary on a per-project base? I think folding is a code-independent feature which is mainly dependent on the user and whether he likes it or not,.
True, I really was basically picking settings at random...
I might be totally wrong, but I thought with the preferences settings already in place, it would be relatively easy to just copy the code over to project settings and then overload the default settings with the project ones once a user has chosen a project. I might be totally wrong of course.
Bye Tim
On Sun, 28 Oct 2007 20:57:09 +0100, Tim Tassonis timtas@cubic.ch wrote:
Hi Enrico
- Line wrapping
I'm not sure about this one. I see that if you had a project that was all plain text files it might be useful, but it's not a 'standard'-type project issue. Perhaps it would be better if there was a different feature, e.g. setting line wrapping if too many long lines are detected.
- Folding/autocompletion settings
Not sure about folding settings - what do you mean?
Just whether to enable/disable folding.
Is it really necessary on a per-project base? I think folding is a code-independent feature which is mainly dependent on the user and whether he likes it or not,.
True, I really was basically picking settings at random...
I might be totally wrong, but I thought with the preferences settings already in place, it would be relatively easy to just copy the code over to project settings and then overload the default settings with the project ones once a user has chosen a project. I might be totally wrong of course.
It is not that difficult but why should we add things which nobody will use.
Regards, Enrico
Enrico Tröger wrote:
On Sun, 28 Oct 2007 20:57:09 +0100, Tim Tassonis timtas@cubic.ch wrote:
I might be totally wrong, but I thought with the preferences settings already in place, it would be relatively easy to just copy the code over to project settings and then overload the default settings with the project ones once a user has chosen a project. I might be totally wrong of course.
It is not that difficult but why should we add things which nobody will use.
Of course you are right and I didn't want to suggest offering the whole lot of settings in the project preferences. Also agreed, some of the ones I suggested were quite bad choices...
Generally I think the useful ones would be those that really can change between projects due to different coding style policies. Maybe:
- Indentation Type - Tab Width - Newline strip trainling spaces - Default encoding - Strip training spaces - Replace tabs by spaces - maybe make command
But I think I should stop now, I don't want to go down in this list's history as an unproductive other-people-might-do-this contributor.
Bye Tim
Regards, Enrico
Geany mailing list Geany@uvena.de http://uvena.de/cgi-bin/mailman/listinfo/geany
On Sun, 28 Oct 2007 22:59:54 +0100, Tim Tassonis timtas@cubic.ch wrote:
Enrico Tröger wrote:
On Sun, 28 Oct 2007 20:57:09 +0100, Tim Tassonis timtas@cubic.ch wrote:
I might be totally wrong, but I thought with the preferences settings already in place, it would be relatively easy to just copy the code over to project settings and then overload the default settings with the project ones once a user has chosen a project. I might be totally wrong of course.
It is not that difficult but why should we add things which nobody will use.
Of course you are right and I didn't want to suggest offering the whole lot of settings in the project preferences. Also agreed, some of the ones I suggested were quite bad choices...
Generally I think the useful ones would be those that really can change between projects due to different coding style policies. Maybe:
- Indentation Type
- Tab Width
- Newline strip trainling spaces
- Default encoding
- Strip training spaces
- Replace tabs by spaces
- maybe make command
But I think I should stop now, I don't want to go down in this list's history as an unproductive other-people-might-do-this contributor.
Yes the above options sound good. But don't hesitate to post your wishes and comments. It is in any case better than to not say what you think ;-).
Regards, Enrico
On Oct 30 2007, Enrico [UTF-8] Tröger wrote:
On Sun, 28 Oct 2007 22:59:54 +0100, Tim Tassonis timtas@cubic.ch wrote:
Enrico Tröger wrote:
On Sun, 28 Oct 2007 20:57:09 +0100, Tim Tassonis timtas@cubic.ch wrote:
I might be totally wrong, but I thought with the preferences settings already in place, it would be relatively easy to just copy the code over to project settings and then overload the default settings with the project ones once a user has chosen a project. I might be totally wrong of course.
It is not that difficult but why should we add things which nobody will use.
Of course you are right and I didn't want to suggest offering the whole lot of settings in the project preferences. Also agreed, some of the ones I suggested were quite bad choices...
Generally I think the useful ones would be those that really can change between projects due to different coding style policies. Maybe:
- Indentation Type
- Tab Width
- Newline strip trainling spaces
- Default encoding
- Strip training spaces
- Replace tabs by spaces
- maybe make command
But I think I should stop now, I don't want to go down in this list's history as an unproductive other-people-might-do-this contributor.
Yes the above options sound good. But don't hesitate to post your wishes and comments. It is in any case better than to not say what you think ;-).
As partially indicated before we have a requirement to allow students to work with multiple versions of code they are developing for running on embedded micros. Thus it would be nice to
a) Have a project that by default compiles all files within a directory, but does allow the user to deselect check boxes when there are more than one variant of a source file, e.g. to select between a number of different sources inputX.cc a menu as below is automatically generated and the user is able to deselect inpout2.cc and input3.cc say
x test.cc x input1.cc input2.cc input3.cc x output.cc
b) Allows a project to select default compiler options and possibly have selectable options, e.g. in our case we normally develop on a i386 box, but then cross compile to a ARM based micro. Thus it would be nice to be able to select different destinations for the output. This could be within one project or two projects using the same source, but different subdirectories for the object files, e.g
Project | ----------------------------------- | | | Source i386 output ARM output
Regards