<br><br><div class="gmail_quote">On 25 February 2010 00:17, 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 Sun, 21 Feb 2010 15:03:01 +0100<br>
Enrico Tröger <<a href="mailto:enrico.troeger@uvena.de">enrico.troeger@uvena.de</a>> wrote:<br>
<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<br>
> >plugin, or<br>
> >2. the two plugins approach<br>
> ><br>
> >1. has the advantage that the basic system is always available even if<br>
> >Geany is started without plugins, but then the build-in system needs<br>
> >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<br>
> >available through the plugin API, and thats likely to be a big API,<br>
> >much of which no one else will want to use. This includes interface<br>
> >to the preferences and filetype files for saving and restoring<br>
> >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<br>
> >to 0.18<br>
> >2. By default Geany provides an easy configuration capability that<br>
> >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<br>
> >operation of the build system is, so long as a default user sees<br>
> >functionality as at<br>
> >1. and 2. does not expose that complexity.<br>
> ><br>
> >So I propose that a build-system with full capability but only a simple<br>
> >configuration dialog be in core, and the full configure dialog be in a<br>
> >plugin.<br>
> ><br>
> >This makes the plugin interface much narrower, mostly the capability<br>
> >to set the configuration. That interface would be the interface to<br>
> >the "operation" object I defined in the design spec (I'll get you to<br>
> >read it yet ;-)<br>
><br>
> In the meantime, I realised my idea wasn't the best I ever had...:)<br>
> But I do like your proposal to have it all in the core except the<br>
> "heavy" configuration dialog which could be in a plugin.<br>
><br>
> As long as it works in the end, I'm all for it.<br>
><br>
> Just go to get it, I don't want to hinder new stuff any longer.<br>
<br>
Personally I'm not sure that tying the two implementations together is<br>
a good idea. I haven't really studied Lex's build.c implementation but<br>
I don't want to have to expose all of it to the plugin API. This will<br>
straightjacket any changes we want to make on the core build system.<br></blockquote><div><br>Totally agree, thats why I am proposing to change it so that only the configuration interface be exposed (see attached proposed interface). <br>
<br>This interface is narrow, typesafe, and expandable but exposes little of the internal workings because the BuildOperation type is opaque.<br>It is also ABI safe if extra fields and functions are added and still ABI safe if enums are extended and API safe if no functions/enums are removed.<br>
<br>This API also makes it possible for other plugins to manipulate settings such as Franks proposed plugin that sets build commands based on contents of latex files.<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>
One option would be for a plugin to completely replace the build system<br>
by hiding the build menu and overriding the build keybindings.<br></blockquote><div><br>This would make loading/storing settings messy, the filetypes, project and preferences load/store interface needs to be available to the plugin. And what happens if the plugin isn't loaded when the filetypes etc are loaded? When the plugin is loaded how does it get to re-load these settings? Or does the plugin have to have another set of settings files mirroring the filetype projects and preferences files? And structures mirroring the GeanyFiletype, GeanyProject etc structures or do those structures have fields for a plugin that may not be loaded?<br>
<br>Makes the plugin much bigger and also requires more of the build 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.<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;">
<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>
</blockquote></div><br>