On 2 March 2010 00:37, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Fri, 26 Feb 2010 17:54:31 +0000 Nick Treleaven nick.treleaven@btinternet.com wrote:
Makes the plugin much bigger and also requires more of the build
Makes the core smaller ;-)
Probably not by much though.
The build.c in SVN is 500 lines longer than build.c in 0.18.1, which is not bad given the increase in functionality (see below for an indication of some of the things missing)
A rough check says the extra lines are mostly in the dialog, load/save and some of the logic sections. I'd hope that much of that will be clawed back when the complex dialog goes to a plugin and the logic is simplified.
functionality to be exposed unless everything is re-implemented in the plugin in which case maintenance is a nightmare to keep them in line.
For
example the build_command, build_run _cmd, build_replace_placeholder functions.
Why keep them in line?
Anyway you might be right that it's less work for you if we share the build.c functionality. I'm not really convinced that it's necessary to have 'delta' level control on each command - I think it would be best to improve the core to allow advanced users to do anything they want but in a structured way that doesn't confuse basic users.
But don't let me stop you, just wanted to air my thoughts ;-)
Having thought more and feeling a bit less defensive,
Don't worry I understand you are just defending the Geany key feature, ie "fast lightweight"
I think for the core Execute command(s) a checkbox for whether to run without xterm/VTE per command for GUI programs is good.
This gives me an opening to start discussion on what functionality should be exposed by the core configuration dialog, thanks Nick. ;-)
I actually went back to 0.18.1 and looked at what is available there, and I think that the following need to be added, but I'm open to suggestions:
1. edit each of the "make" commands individually (0.18.1 has single setting shared by all three) 2. edit project build settings (don't exist in 0.18.1) for "make" commands only, not filetype 3. edit working directory for each command (doesn't exist in 0.18.1) 4. if above, remove "make in base path" since its no longer needed 5. for execute commands only, the option to run without terminal, checkbox (new) 6. single shared parsing regex per filetype (hidden setting, not in GUI in 0.18.1, this is used for make commands as well based on current document) It might be less confusing to have another regex for the make commands as well?
Things to not make available (to avoid "dialog shock"):
1. edit menu item label 2. which commands are parsed and which are not 3. which commands are stopable and which are not 4. extra commands in sections (propose simple dialog allows editing 2 fieltype,3 make,2 execute) 5. change internal command locations (next/prev error, show dialog) 6. project filetype commands (just so the dialog is smaller) 7. parsing regex per command, source or global 8. viewing settings from non-editable sources ie default, system filetypes, plugins/internal
When I get time I'll see what this make the core configuration look like.
These (and the settings from the core dialog) would all be configurable from the plugin dialog.
What does everyone think?
So at least the core might be able to benefit from your changes.
:-)
I might have been a bit pessimistic, probably having a competing build interface will encourage development of both, which would be good for users.
Yes, but it will take a great deal of firm control to prevent more and more functionality from the plugin configuration dialog from migrating into the core dialog :-D
Cheers Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel