On Tue, 2 Mar 2010 10:21:27 +1100 Lex Trotman elextr@gmail.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)
I was just backtracking on my comment about core size, not complaining ;-)
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.
I'm not worried about size really, just concerned about simplifying things. But it could be good.
...
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:
Hmm, this seems quite complicated. You know we accept current trunk as good, no need to rethink everything.
- 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"):
- edit menu item label
- which commands are parsed and which are not
- which commands are stopable and which are not
- 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
Sorry, I've been thinking about the build system enough already lately :-p I can't really take all this in (but I'm a bit stressed for reasons outside of Geany for the next few months).
Maybe it's better to start a new thread to discuss these things.
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
Haha ;-)
Regards, Nick