<br><br><div class="gmail_quote">On 2 March 2010 00:37, Nick Treleaven <span dir="ltr"><<a href="mailto:nick.treleaven@btinternet.com">nick.treleaven@btinternet.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Fri, 26 Feb 2010 17:54:31 +0000<br>
<div class="im">Nick Treleaven <<a href="mailto:nick.treleaven@btinternet.com">nick.treleaven@btinternet.com</a>> wrote:<br>
<br>
</div>> > Makes the plugin much bigger and also requires more of the build<br>
><br>
> Makes the core smaller ;-)<br>
<br>
Probably not by much though.<br></blockquote><div><br>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)<br>
<br>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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
> > functionality to be exposed unless everything is re-implemented in the<br>
> > plugin in which case maintenance is a nightmare to keep them in line. For<br>
> > example the build_command, build_run _cmd, build_replace_placeholder<br>
> > functions.<br>
><br>
> Why keep them in line?<br>
><br>
> Anyway you might be right that it's less work for you if we share<br>
> the build.c functionality. I'm not really convinced that it's necessary<br>
> to have 'delta' level control on each command - I think it would be<br>
> best to improve the core to allow advanced users to do anything they<br>
> want but in a structured way that doesn't confuse basic users.<br>
><br>
> But don't let me stop you, just wanted to air my thoughts ;-)<br>
<br>
Having thought more and feeling a bit less defensive,</blockquote><div><br>Don't worry I understand you are just defending the Geany key feature, ie "fast lightweight" <br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I think for the<br>
core Execute command(s) a checkbox for whether to run without xterm/VTE<br>
per command for GUI programs is good.<br></blockquote><div><br>This gives me an opening to start discussion on what functionality should be exposed by the core configuration dialog, thanks Nick. ;-)<br><br>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:<br>
<br>1. edit each of the "make" commands individually (0.18.1 has single setting shared by all three)<br>2. edit project build settings (don't exist in 0.18.1) for "make" commands only, not filetype<br>
3. edit working directory for each command (doesn't exist in 0.18.1)<br>4. if above, remove "make in base path" since its no longer needed<br>5. for execute commands only, the option to run without terminal, checkbox (new)<br>
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?<br>
<br>Things to not make available (to avoid "dialog shock"):<br><br>1. edit menu item label<br>2. which commands are parsed and which are not<br>3. which commands are stopable and which are not<br>4. extra commands in sections (propose simple dialog allows editing 2 fieltype,3 make,2 execute)<br>
5. change internal command locations (next/prev error, show dialog)<br>6. project filetype commands (just so the dialog is smaller)<br>7. parsing regex per command, source or global<br>8. viewing settings from non-editable sources ie default, system filetypes, plugins/internal<br>
<br>
When I get time I'll see what this make the core configuration look like.<br>
<br>These (and the settings from the core dialog) would all be configurable from the plugin dialog.<br><br>What does everyone think?<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
So at least the core might be able to benefit from your changes.<br></blockquote><div><br>:-)<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
I might have been a bit pessimistic, probably having a competing build<br>
interface will encourage development of both, which would be good for<br>
users.<br></blockquote><div><br>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<br><br>Cheers<br>Lex<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="h5"><br>
Regards,<br>
Nick<br>
_______________________________________________<br>
Geany-devel mailing list<br>
<a href="mailto:Geany-devel@uvena.de">Geany-devel@uvena.de</a><br>
<a href="http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel" target="_blank">http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel</a><br>
</div></div></blockquote></div><br>