On Fri, 30 Nov 2018, Sven Schreiber wrote:
this is about the issue of having more than one menu entry for a
function
package, or (related but slightly different) having one menu entry but
wanting to offer two or more GUI interfaces when calling the package from the
package listing window.
(Currently, if I'm not very much mistaken, either a package has no gui-main
function and thus no menu entry either, and then all public functions are
offered for a choice in the GUI; or when there's a gui-main function as
required for a menu entry, then the other public functions are
scripting-only.)
The whole thought is prompted by the renewed demand for a SVEC(M) GUI access
with the SVAR addon. Extending the current SVAR GUI would not be good because
it is already a little overloaded.
I see two solutions:
1: Using the fact that recently function packages can depend on each other,
simply introduce a formally separate package, say guiSVEC, which gets its own
menu entry and a single public function. When called and executed, it pulls
in the SVAR addon on which it depends, and calls the appropriate functions
from SVAR in the background.
This solution wouldn't require changes in core gretl, AFAICS.
2: Extend gretl's function package apparatus by allowing designated gui-2,
gui-3 etc. public functions with corresponding menu-attachment-2
menu-attachment-3...
Not sure how disruptive such a change would be.
What do you think?
My first reaction: I doubt whether many packages will require more
than one GUI entry point, and it would be quite complicated to
extend the function-package apparatus (which is already quite
complicated) to support that. So I'd favour the option you mention
first, a small "parasitic" GUI-oriented package which depends on
SVAR. I think you're right in saying that wouldn't require changes
in core gretl; anyway, running the experiment would be worthwhile.
Allin