Hi, I've committed Lex Trotman's geany.txt changes in the build-system branch, slightly edited.
https://geany.svn.sourceforge.net/svnroot/geany/branches/build-system
I made some formatting changes: .. note:: syntax (space after ..) break lines - I used the 'Format->Send selection to command' with the fmt command.
On to the changes - in general I agree with them, but some points:
1. 'Make Commands' is mentioned, perhaps this should be renamed 'Global Commands', as these may well be nothing to do with 'make'.
2. +* From the user preferences if the user has make commands defined. +* From the global preferences/defaults.
Not sure about this - currently we only have user prefs for geany.conf. Maybe global prefs too, but would it be confusing?
3. Do we need the table of default filetype build commands? If so, IMO it should be autogenerated and included/referenced from geany.txt rather than writing by hand.
4. I think 'Project Make' should be configured from the Project Properties dialog. In this case the global Make command could be grayed out in the Configure Commands dialog.
5. +Remember that menu item two (default the 'Make Custom Target' item) +will pop up a dialog to ask for additional targets/options when invoked +allowing you to add to the command you define here.
Should this just be the 'Make Custom Target' item? (not menu item two)
Regards, Nick
On Sat, Oct 11, 2008 at 4:24 AM, Nick Treleaven < nick.treleaven@btinternet.com> wrote:
Hi, I've committed Lex Trotman's geany.txt changes in the build-system branch, slightly edited.
https://geany.svn.sourceforge.net/svnroot/geany/branches/build-system
I made some formatting changes: .. note:: syntax (space after ..) break lines - I used the 'Format->Send selection to command' with the fmt command.
Thanks
On to the changes - in general I agree with them, but some points:
- 'Make Commands' is mentioned, perhaps this should be renamed 'Global
Commands', as these may well be nothing to do with 'make'.
I agree it should be changed from 'Make' but I had trouble getting a term I was happy with. This was a general issue throughout the document, what group term to use for the builder commands? Builder itself I thought was too close to the 'build' command which doesn't use the builder ;-) "Global" I felt could be taken as a reference to storing them globally and what is being implemented is actually storing them in the Project file or user prefs. Unless the build command is changed allowing the use of builder as the group name for the make commands?
Looking at the prototype dialog attached, it doesn't look like so much a problem for the software, just to avoid confusion in the manual.
+* From the user preferences if the user has make commands defined. +* From the global preferences/defaults.
Not sure about this - currently we only have user prefs for geany.conf. Maybe global prefs too, but would it be confusing?
Ok, its user preferences or Defaults.
- Do we need the table of default filetype build commands? If so, IMO
it should be autogenerated and included/referenced from geany.txt rather than writing by hand.
I think it is useful to let the user know what the defaults are so they don't need to go look. But it probably should be in an appendix and referenced from here. Autogenerating I like, you can see how far I got manually.
- I think 'Project Make' should be configured from the Project
Properties dialog. In this case the global Make command could be grayed out in the Configure Commands dialog.
IMO its better UI practice to have all the build menu commands configured from the one dialog box activated from the build menu. Attached is a quick mockup of the dialog, Note that the label "Commands for filetype C" will change to the type of the current file, eg "Commands for filetype Python". Note also that the label "Project Builder Commands" will be "Preferred Builder Commands" if no project is open.
+Remember that menu item two (default the 'Make Custom Target' item) +will pop up a dialog to ask for additional targets/options when invoked +allowing you to add to the command you define here.
Should this just be the 'Make Custom Target' item? (not menu item two)
Well the section was talking about changing the menu labels and commands so it might not say "Make Custom Target", hence my hedging it by putting it in brackets and noting it as default. Menu item two is somewhat ugly maybe "the second menu item" but any better suggestions for referring to a menu item independently of its label will be gratefully received.
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Regards Lex
On Sat, 11 Oct 2008 17:47:31 +1100 "Lex Trotman" elextr@gmail.com wrote:
- 'Make Commands' is mentioned, perhaps this should be renamed
'Global Commands', as these may well be nothing to do with 'make'.
I agree it should be changed from 'Make' but I had trouble getting a term I was happy with. This was a general issue throughout the document, what group term to use for the builder commands? Builder itself I thought was too close to the 'build' command which doesn't use the builder ;-) "Global" I felt could be taken as a reference to storing them globally and what is being implemented is actually storing them in the Project file or user prefs. Unless the build command is changed allowing the use of builder as the group name for the make commands?
Hmm, personally I thought global could just mean for all documents. Maybe if a project is open, change the group name to 'Project Commands'.
What does everyone else think?
...
- Do we need the table of default filetype build commands? If so,
IMO it should be autogenerated and included/referenced from geany.txt rather than writing by hand.
I think it is useful to let the user know what the defaults are so they don't need to go look. But it probably should be in an appendix and referenced from here. Autogenerating I like, you can see how far I got manually.
Yes, an autogenerated appendix would be good. (BTW don't feel you need to implement everything I/we suggest, just work on what you want.)
- I think 'Project Make' should be configured from the Project
Properties dialog. In this case the global Make command could be grayed out in the Configure Commands dialog.
IMO its better UI practice to have all the build menu commands configured from the one dialog box activated from the build menu. Attached is a quick mockup of the dialog, Note that the label "Commands for filetype C" will change to the type of the current file, eg "Commands for filetype Python". Note also that the label "Project Builder Commands" will be "Preferred Builder Commands" if no project is open.
OK. Maybe 'project builder' suggests a build system, perhaps just 'project commands'? I know that for now they will all be build commands for the project, but maybe in future we will extend it for other commands.
But the syntax doesn't matter much at this stage, just adding my thoughts. Sometimes it's hard to design by committee ;-)
+Remember that menu item two (default the 'Make Custom Target' item) +will pop up a dialog to ask for additional targets/options when invoked +allowing you to add to the command you define here.
Should this just be the 'Make Custom Target' item? (not menu item two)
Well the section was talking about changing the menu labels and commands so it might not say "Make Custom Target", hence my hedging it by putting it in brackets and noting it as default. Menu item two is somewhat ugly maybe "the second menu item" but any better suggestions for referring to a menu item independently of its label will be gratefully received.
Maybe the 'Make Custom Target' could be a more generic 'Custom command' but with a configurable starting string. The default label could still be 'Make Custom Target' but we could refer to it as the 'Custom command' item.
Regards, Nick
On Mon, 13 Oct 2008 13:07:19 +0100, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Sat, 11 Oct 2008 17:47:31 +1100 "Lex Trotman" elextr@gmail.com wrote:
- 'Make Commands' is mentioned, perhaps this should be renamed
'Global Commands', as these may well be nothing to do with 'make'.
I agree it should be changed from 'Make' but I had trouble getting a term I was happy with. This was a general issue throughout the document, what group term to use for the builder commands? Builder itself I thought was too close to the 'build' command which doesn't use the builder ;-) "Global" I felt could be taken as a reference to storing them globally and what is being implemented is actually storing them in the Project file or user prefs. Unless the build command is changed allowing the use of builder as the group name for the make commands?
Hmm, personally I thought global could just mean for all documents. Maybe if a project is open, change the group name to 'Project Commands'.
What does everyone else think?
I'm not sure. IMO 'Build commands' would be fine or also 'Global commands', But as we all know, I'm not a native English speaker :).
+Remember that menu item two (default the 'Make Custom Target' item) +will pop up a dialog to ask for additional targets/options when invoked +allowing you to add to the command you define here.
Should this just be the 'Make Custom Target' item? (not menu item two)
Well the section was talking about changing the menu labels and commands so it might not say "Make Custom Target", hence my hedging it by putting it in brackets and noting it as default. Menu item two is somewhat ugly maybe "the second menu item" but any better suggestions for referring to a menu item independently of its label will be gratefully received.
Maybe the 'Make Custom Target' could be a more generic 'Custom command' but with a configurable starting string. The default label could still be 'Make Custom Target' but we could refer to it as the 'Custom command' item.
Not sure about this. A 'generic custom command' with a configurable starting string? Sounds a bit long-winded. Why don't we just skip it? I mean when we already have configurable commands we probably don't need to keep another kind of configurable command.
Regards, Enrico
On Wed, 15 Oct 2008 14:30:35 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
Maybe the 'Make Custom Target' could be a more generic 'Custom command' but with a configurable starting string. The default label could still be 'Make Custom Target' but we could refer to it as the 'Custom command' item.
Not sure about this. A 'generic custom command' with a configurable starting string? Sounds a bit long-winded. Why don't we just skip it? I mean when we already have configurable commands we probably don't need to keep another kind of configurable command.
For now it's fine calling it the 'Make Custom Target' command. But we were discussing how to refer to it in a more general way, because the command doesn't even have to use 'make' at all. E.g, in the configuration dialog:
Filetype Commands ... General Commands ... Custom: "./waf build "
When the user clicks on the 'Build->Custom Command' menu item, a dialog appears with "./waf build " as the contents, but they can still edit it - e.g. for adding arguments.
Regards, Nick
On Wed, 15 Oct 2008 13:44:48 +0100, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Wed, 15 Oct 2008 14:30:35 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
Maybe the 'Make Custom Target' could be a more generic 'Custom command' but with a configurable starting string. The default label could still be 'Make Custom Target' but we could refer to it as the 'Custom command' item.
Not sure about this. A 'generic custom command' with a configurable starting string? Sounds a bit long-winded. Why don't we just skip it? I mean when we already have configurable commands we probably don't need to keep another kind of configurable command.
For now it's fine calling it the 'Make Custom Target' command. But we were discussing how to refer to it in a more general way, because the command doesn't even have to use 'make' at all. E.g, in the configuration dialog:
Filetype Commands ... General Commands ... Custom: "./waf build "
When the user clicks on the 'Build->Custom Command' menu item, a dialog appears with "./waf build " as the contents, but they can still edit it
- e.g. for adding arguments.
I still understand this. Lex wants to implement general build commands which can be completely configured by the user, why then add a command which pops up a dialog box? For convenience for something like one time shots?
Regards, Enrico
On Wed, 15 Oct 2008 14:50:15 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
Lex wants to implement general build commands which can be completely configured by the user, why then add a command which pops up a dialog box? For convenience for something like one time shots?
Sometimes the user wants to run unusual commands - e.g. sometimes I run "make -C .." with the 'Make Custom Target'. Or "make -k".
When/if we implement unlimited configurable commands, I could add a menu item (if I thought it was worth it), but it would even then still be useful to be able to run different commands occasionally.
Regards, Nick
On Wed, 15 Oct 2008 14:18:46 +0100, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Wed, 15 Oct 2008 14:50:15 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
Lex wants to implement general build commands which can be completely configured by the user, why then add a command which pops up a dialog box? For convenience for something like one time shots?
Sometimes the user wants to run unusual commands - e.g. sometimes I run "make -C .." with the 'Make Custom Target'. Or "make -k".
When/if we implement unlimited configurable commands, I could add a menu item (if I thought it was worth it), but it would even then still be useful to be able to run different commands occasionally.
Ah ok. Slowly I get the point and I should accept that not everyone does such things in a console like me :).
Regards, Enrico
Enrico Tröger wrote:
Ah ok. Slowly I get the point and I should accept that not everyone does such things in a console like me :).
Regards, Enrico
Sorry to butt in on the conversation and going off-topic, but I do my building from the terminal, too. :P Don't get me wrong; just hitting F5 (for example) is a really great little feature, and I've used it in the past when I was playing with PyGTK.
Anyway, keep up the good work, guys!
Jay
On Thu, Oct 16, 2008 at 12:33 AM, Enrico Tröger enrico.troeger@uvena.dewrote:
On Wed, 15 Oct 2008 14:18:46 +0100, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Wed, 15 Oct 2008 14:50:15 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
Lex wants to implement general build commands which can be completely configured by the user, why then add a command which pops up a dialog box? For convenience for something like one time shots?
Sometimes the user wants to run unusual commands - e.g. sometimes I run "make -C .." with the 'Make Custom Target'. Or "make -k".
When/if we implement unlimited configurable commands, I could add a menu item (if I thought it was worth it), but it would even then still be useful to be able to run different commands occasionally.
Ah ok. Slowly I get the point and I should accept that not everyone does such things in a console like me :).
Maybe I'm getting old and lazy ;), but I like Geany to parse the error messages from the build and take me to the line in the source file, so I want to run all builds from Geany. Thats why I'm proposing the changes.
It is very difficult to design a UI in text like this, I'll produce a prototype and we can see how it looks and works. We can always change strings later.
Regards Lex
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Wed, 15 Oct 2008 14:30:35 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
- 'Make Commands' is mentioned, perhaps this should be renamed
'Global Commands', as these may well be nothing to do with 'make'.
I agree it should be changed from 'Make' but I had trouble getting a term I was happy with. This was a general issue throughout the document, what group term to use for the builder commands? Builder itself I thought was too close to the 'build' command which doesn't use the builder ;-) "Global" I felt could be taken as a reference to storing them globally and what is being implemented is actually storing them in the Project file or user prefs. Unless the build command is changed allowing the use of builder as the group name for the make commands?
Hmm, personally I thought global could just mean for all documents. Maybe if a project is open, change the group name to 'Project Commands'.
What does everyone else think?
I'm not sure. IMO 'Build commands' would be fine or also 'Global commands', But as we all know, I'm not a native English speaker :).
Maybe 'General Commands'?
So:
Commands for filetype 'Foo' ... General Commands Make Make Object Make Custom Target
And when a project is open, 'General Commands' should read 'Project Commands'.
Regards, Nick
On Sat, 11 Oct 2008 17:47:31 +1100 "Lex Trotman" elextr@gmail.com wrote:
- 'Make Commands' is mentioned, perhaps this should be renamed
'Global Commands', as these may well be nothing to do with 'make'.
I agree it should be changed from 'Make' but I had trouble getting a term I was happy with.
Anyway for now Make Commands is OK, we can change it later if we want.
Regards, Nick
