Hi Enrico,<br><br><div class="gmail_quote">2010/2/14 Enrico Tröger <span dir="ltr"><<a href="mailto:enrico.troeger@uvena.de">enrico.troeger@uvena.de</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Sat, 6 Feb 2010 21:21:03 +1100, Lex wrote:<br>
<br>
Heya guys,<br>
<br>
since we have quite different ideas of the future of the whole build<br>
systems features and in particular about its configuration using GUI<br>
dialogs, I got a weird idea:<br>
<br>
Why not moving the build system code into a plugin?<br>
<br>
This isn't completely new, I think to remember we discussed this before<br>
Lex' first rewrite of the build system and decided to not do this to<br>
keep it in the core and so always available.<br></blockquote><div><br>As I said I don't care, so long as it can do what is needed.<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>
Though having the build system as a plugin has some advantages, IMO.<br>
<br>
First, Lex could realise it as he wants, as complex and flexible as<br>
necessary giving users all the powers they want to and don't limit them<br>
with any hardcoded defaults (I completely understand this wish).<br></blockquote><div><br>Yes, provided that the plugin has sufficient control over the core to do what it wants, see 4.<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>
And alternatively, we could implement a very basic, limited and easy to<br>
use(KISS) build system alternatively, similar to the old one(as in 0.18<br>
and before) alternatively to the advanced one.<br>
<br></blockquote><div><br>Unless the basic plugin installs and loads fully automatically it might be a problem for new/beginner users. However its implemented it must be automatically available as soon as Geany is installed.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Then users can choose which build system plugin they want to use and so<br>
have even more flexibility.<br>
<br>
<br>
This would probably make things a bit harder and would require some<br>
additions to the plugin API, especially to get project support properly<br>
involved but I think it might be worth in the long term.<br>
<br></blockquote><div><br>I have had a think about it and I'd say it will be a lot of additions to the plugin API. Not that thats necessarily bad, just effort someone has to do... in addition to the implementation of the build system capabilities in the plugin.<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>
Any ideas?<br></blockquote><div><br>As I see it there area couple of ways of implementing your suggestion:<br><br>1. a basic build system in the core and the advanced one in the plugin, or<br>2. the two plugins approach<br>
<br>1. has the advantage that the basic system is always available even if Geany is started without plugins, but then the build-in system needs to be able to be completely disabled when the plugin takes over<br>2. makes the takeover problem simpler,<br>
<br>But both require that everything that the build system needs to do is available through the plugin API, and thats likely to be a big API, much of which no one else will want to use. This includes interface to the preferences and filetype files for saving and restoring settings.<br>
<br>Now as I understand it, what we are trying to achieve is:<br><br>1. By default Geany provides a set of capabilities roughly equivalent to 0.18<br>2. By default Geany provides an easy configuration capability that hides complex capability<br>
3. An alternative that allows "configure everything" control<br><br>Now it seems to me that it doesn't matter how complex the internal operation of the build system is, so long as a default user sees functionality as at 1. and 2. does not expose that complexity.<br>
<br>So I propose that a build-system with full capability but only a simple configuration dialog be in core, and the full configure dialog be in a plugin.<br><br>This makes the plugin interface much narrower, mostly the capability to set the configuration. That interface would be the interface to the "operation" object I defined in the design spec (I'll get you to read it yet ;-)<br>
<br>Also there is no "changeover" of control, just which dialog is opened when the "Set Build Configuration" menu item is selected.<br><br>And the same interface still allows Frank to hook into the process to control building dependent on file contents irrespective of which configure dialog is being used..<br>
<br>Any thoughts?<br><br>Cheers<br>Lex<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>
Enrico<br>
<br>
--<br>
Get my GPG key from <a href="http://www.uvena.de/pub.asc" target="_blank">http://www.uvena.de/pub.asc</a><br>
</div></div><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>
<br></blockquote></div><br>