Re: [Gretl-devel] Menu attachment of package not working for me
On Wed, 29 May 2013, Sven Schreiber wrote:
Am 28.05.2013 18:24, schrieb Allin Cottrell:
> On Tue, 28 May 2013, Sven Schreiber wrote:
>
>> for the first time ever I tried to attach a function package to the menus,
>> but I couldn't get it to appear. I never got an error, just no effect.
>
> Ah, I introduced a new bug that disabled that effect when I
> was fixing the other problems you mentioned. But that in turn
> was fixed in CVS and snapshots a few hours ago.
It's working now, very cool.
>
>> I have noticed that in the dialog where the menu path is
>> chosen, the "model -> limited dependent" submenu is
>> expandable, whereas the "model -> time series" submenu
>> isn't. (There is the 3rd-level submenu cointegration tests
>> there.)
>
> OK, I suppose in principle it ought to be possible to add an
> item to the Cointegration test submenu; I'll look into that.
Yes that would be the most logical place.
In fact, the only place. (I mean, that's the sole submenu
under /Model/Time series; and until further notice packages
cannot themselves add submenus, only items under existing
menus or submenus.)
On a related note: I've noticed by trial-and-error that for
"bundle-print" etc. the corresponding defined function must be declared
public instead of helper. (Otherwise the dialog items were greyed out.)
That logic wasn't obvious.
The thinking here is that "helper" (private) functions are
callable only by public functions in the given package, while
bundle-print and so on have to be callable by third parties,
even if only gretl itself. But this should be documented,
agreed.
And actually, the printing via that function isn't working
for me. Also the bundle that's returned never shows up
anyway -- at least since I have added the package to the
menu it's also not possible anymore to specify a return
bundle name/container.
Another thing that needs to be documented (and I plan to
document it in my paper for GC 2013). If you specify a
"gui-main" function, and this function returns a bundle, then
the handling of the returned bundle is done by gretl. The user
is not given the option of assigning the returned bundle in
advance, because it's assumed that the bundle will be
displayed in a GUI window, from where it can be saved (if the
user wants) in the same sort of way that a gretl model can be
saved.
If your returned bundle is not showing up in a window that
could be a bug in gretl, or possibly in your package (though
in the latter case you should get an error message, and it
would be a gretl bug if you don't). I'll try constructing a
minimal test of this functionality and report back.
One further suggestion for the packages: It would be nice if the
bundle-print function (and friends) could get automatic access to the
arguments with which gui-main was called. I know I can stuff all the
arguments inside the bundle and read them out in bundle-print, but that
seems redundant and clunky.
Not redundant, surely: if the information is to be used
subsequently it has to be stored somewhere. And I can't see a
superior alternative to storing it inside the package's
bundle. From gretl's point of view function arguments are
transient data. And consider the case where the bundle is
stored as part of a saved session file: how else could we save
the argument info other than in the bundle?
Allin