Suggesting a new look for gretl.
by Talha Yalta
Hi everybody:
I have a few suggestions that I think has the potential to improve
gretl significantly. But, first of all, as a newcomer, I hope you
don't consider my continously suggesting things in a negative way. I
just do my own thinking about how the program can be better and speak
my mind about it. In the end, it is you who will decide what will be
implemented because you guys are doing all the hard work. Anyway, here
goes:
1- My first and most important suggeston is to make the gretl main
window the icon view. The list of variables will be removed and turned
into an icon itself. When the user double clicks on the "variables"
icon, a new window will be opened with the usual vertical list of
variables. Various reasons and advantages for doing this is as
follows:
a)- The icon view is a particularly important and intuitive
feature of gretl and I think most people agree that it should be more
central.
b)- The list of variables, on the other hand, is not as central
to devote the whole program window for. True, one can do various
things by right clicking on each variable (boxplot, gini, spectrum
etc.) but these can easily done using the pull-down menus. For many
tasks such as modeling, graphing etc., the user already has to use
devoted "dialog boxes" such as the "specify model" window or the
"define graph" window anyway. Maybe there will be a need for some
additional dialogs for some items but I think it is totally worth it.
Besides, the existing functionlity can be kept in the new framework as
well. That is, the user can still highlight a variable within the
"variables" window and do certain tasks using the variables menu. The
only difference is that now variables is a seperate window that can be
opened and closed from the default icon view.
c)- And, you don't even have to call it the "icon view" because
if you think about it, there is no other view. The regression results
are saved into the session as icons and there is no other view such as
a list view or a console view to retreive the previous results. (of
course results can be saved seperately as csv, txt, word etc. but that
is something else).
2- My second suggestion is: the "file" menu can be modified so that
the first items are "new session" "open session", "save session",
"save session as" "close session" etc. This is because the main mode
of working is through "sessions". There is no need for the "open data"
item. After starting the program, the user is expected to select "new
session" or "open session". If he or she selects "new session", a
selection diaog can provide the options to create "null data" or open
or import various existing data files. This will both simplify the
file menu and keep things intuitive and logical IMHO.
3- I think splash screens are important. They have some usefulness and
also give a nice and professional touch to the program. Most programs
have them so it is something users expect to see. Allin says:
>I'm not averse to a splash screen, so long as you can turn it
>off quite easily! By all means give it a go.
IMO the splash screen can stay on the screen for just 2 seconds and
can even be made disappear sooner with a single mouse click. I am
happy to try a few desings so that you can select the one that you
like the most. I can get started when I have the high resolution
Gretel image. By the way where does this image come from? Can we get
into trouble for using it? You guys are positive that should be the
theme in the splash screen?
4- The new prefences screen that was proposed is a tedious task ti
implement (as I understand it) but it is also very important because
this way you are taking a good deal of functionality and make it
accessible in the GUI not just the console. This is a way to make sure
gretl not only becomes more powerful but also looks powerful and acts
powerful since GUI is the main mode of working by design.
5- Related to (4), is there a way to make matrix functionality also
accessible from the menus? This is also an important and powerful
feature. I am not sure about know how to do this but as I see it, you
guys are naturals for GUI design and I am sure you would come up with
a very intuitive way for implementing this also.
That is all I had in my mind. I would be very happy to hear what
everybody thinks of these sugestions. They certainly make alot of
sense to me and I think most of them can be implemented relatively
easily. Finally I would like to share the good news that the review of
the upcoming gretl 1.6.0 and its numerical accuracy that I coauthored
with my wife is accepted to JAE for publication in the software
section. Have a great day everyone...
Sincerely,
Talha
--
A positive attitude may not solve all your problems, but it will annoy
enough people to make it worth the effort. - Herm Allbright
(1876-1944)
--
17 years, 9 months
note to translators
by Allin Cottrell
I didn't really intend to remake the gretl.pot file and the
po's just yet, but that happened with my latest build.
Sorry for any inconvenience, but actually we're now close to
a final version of the menu text adjustments.
--
Allin Cottrell
Department of Economics
Wake Forest University, NC
17 years, 9 months
settable variables
by Allin Cottrell
Thanks again to Jack for his very helpful analysis of the
variables in gretl's libset.c.
These variables seem to fall into 3 groups:
* Vars that are already settable via the GUI.
* Vars that are irrelevant to the GUI.
* Vars that are (at least potentially) relevant but
that can't currently be set via the GUI.
The last group includes the PRNG seed, the parameters associated
with time-series filters, and the parameters associated with
iterative estimation (tolerance, max iterations).
Here's how I think these elements should be dealt with; comments
are welcome.
1. The PRNG seed should be visible and settable in the dialog
for defining a random variable.
2. Filters: There's no GUI mechanism for invoking these at
present, so putting the parameters into a GUI preferences dialog
seems odd. What we should have is an item in the time series
portion of the Variable menu, "Filters", which includes
Hodrick-Prescott and Baxter-King (and maybe for good measure
some simpler ones too, e.g. moving average and centered moving
average). When you select one of these items you get a little
dialog where the parameters are configurable. User-selected
parameter values are saved for the duration of the current
session with the current data set, not permanently.
3. Iteration parameters: all estimators that use iteration, and
where convergence is a potential issue, should have a little
Options dialog associated with the model specification dialog
(not sure of the best GUI design yet) where you can set
tolerance and max iterations.
Thus, my general idea is that these variables should be settable
"in situ", rather than in a dialog under /Tools/Preferences.
Allin.
17 years, 9 months
Menu re-structuring
by Talha Yalta
> * Make the File menu more focused, with Open and Save for data
> files, scripts, and session files. Take out "View command log",
> "Browse databases", "Additional functions", "Create data set"
> (and maybe Preferences too?).
>
> * That gets rid of the Session menu, by consolidating it into a
> slimmed-down File menu.
>
> * "Tools" is probably a more standard designation than
> "Utilities", so rename Utilities as Tools. Put the items moved
> out of File under Tools. (Should Preferences go under Tools?)
I agree that this looks tidier and also feels natural. Preferences
under tools makes sense too. Re-structuring the model menu also looks
nice (it would be great to be able to see it in action first before
the final decision though).
While we are at it, I also would like to make a few suggestions
regarding the user interface. It may not be possible to implement them
in this version but what does everybody think of these?
1- How about dividing the main window vertically so that icon view is
available and visible by
default next to the vertical list of variables. This would be nice
because I think the icon view is one of the particularly novel and
useful features of the program and it is not very visible with the
current setting.
2- Multiple UIs! It is known that econometric software can be
intimidating for the uninitiated. The students are often lost within
the myriad of tools and options. With the user friendliness in mind,
how about gretl having 2 different user interfaces (full and lite for
undergrads) which have different set of options visible in the menus.
Once the students master more basic tools, they will be able to move
on to the higher level, which can be easily set in the options menu.
This might be a nice idea to consider for the next versions as gretl
becomes more and more powerful.
3- Finally, I would like to submit my testing of the p-value finder in
gretl in terms of numerical accuracy. Looks like gretl has some
problems with calculating the correct values for the left tails for
several distributions. Some may find the inaccuracies insignificant.
Still, it might be worth to take a look into it. The results are
attached as a ods spreadsheet.
Cheers,
Talha
--
A positive attitude may not solve all your problems, but it will annoy
enough people to make it worth the effort. - Herm Allbright
(1876-1944)
--
17 years, 9 months
Re: [Gretl-users] Menu re-structuring
by Talha Yalta
> > 1- How about dividing the main window vertically so that icon view is
> > available and visible by
> > default next to the vertical list of variables. This would be nice
> > because I think the icon view is one of the particularly novel and
> > useful features of the program and it is not very visible with the
> > current setting.
>
> Hmm, I don't know. I feel the window might become a little crammed. Would it
> be hard for you to produce a mockup screenshot of what you aven in mind?
Here is a screenshot that I came up with tweaking the existing look
with gimp. Of course the two vertical scroll bars will be visible only
when there are too many variables or icons.
Also, about the small icons on the bottom. Does anyone use them? I
feel that it only serves to launch the icon view and the rest of the
icons next to it are just there to add some spice. If the icon view is
buit-in, then maybe those icons will not be needed anymore. Or it can
become a toolbar that can be turned on or off from the menu.
By the way, in many applications "view" and "edit" menus are common.
Does anyone think this might be a good way to organize the
functionality? I suggest something like this:
File ------------ Tools ---------------- View --------------- Edit
All disk ----- Tables, p-value --- View whole --- sample range,
functions NIST suit, data or select data structure
+ session test statistics vars. Graph transpose
operations + spreadsheet specified vars +all adding
+settings +fn pack editor multiple graph
+start R + console Sumry stats
+exit +find freq. plots
corr matrix
+refresh win
--Test ------------------------ Model
KPSS, runs, hurst Model menu is
x12, tramo as proposed.
+all other relevant
+new ones in time
Also, set missing value code goes to preferences.
> >> 2- Multiple UIs! It is known that econometric software can be
> >> intimidating for the uninitiated. The students are often lost within
> >> the myriad of tools and options. With the user friendliness in mind,
> >> how about gretl having 2 different user interfaces (full and lite for
> >> undergrads) which have different set of options visible in the menus.
> >> Once the students master more basic tools, they will be able to move
> >> on to the higher level, which can be easily set in the options menu.
> >> This might be a nice idea to consider for the next versions as gretl
> >> becomes more and more powerful.
> >
> > Sorry, but I'm against this. IMHO, the perception that some people of gretl as
> > a toy package, barely good for teaching introductory econometrics is our worst
> > enemy. I fear that a "trimmed" version of the menu could increase the risk of
> > peing perceived as "not really suitable for serious use".
>
> I'm also against it. From my experience, it's easy to teach only some
> features and the students will just ignore the rest. The only UI
> difference that matters imho is between command line (say, like R) and
> menus (like gretl).
>
I agree now. On second thought, this was not a good idea. Multiple IOs
will be confusing also. So how about gretl the game? This is for the
young students. You are the little girl Gretl and you try to save your
brother by performing certain econometric tasks beginning from the
easier ones like plotting. You get points for each tasks and use the
points to unlock new functions. You kill the witch once you are able
to do say, some serious panel analysis. Just kidding Jack :)
Talha
--
A positive attitude may not solve all your problems, but it will annoy
enough people to make it worth the effort. - Herm Allbright
(1876-1944)
--
17 years, 9 months
Testing the current CVS version
by Cristian Rigamonti
Hi, I'm testing the current CVS version, and I found some small bugs:
- /doc/tex/panel.tex: gretl 1.5.2 is mentioned, but AFAIK next version will be
1.6.0
- The strings in the QLR test window results are not i18n-ed
- I can't install package function files from the gretl server; I can
successfully browse them and retrieve information, but when I click on
"Install" I get "Error retrieving data from server" (and in the xterm window
from which I ran gretl: "Couldn't open local file
'/home/cri/.gretl/functions/HEGY.gfn'", so it seems that the file is searched
locally, not on the server). I know this is work in progress so maybe you're
already aware of that.
Cri
--
GPG/PGP Key-Id 0x943A5F0E - http://www.linux.it/~cri/cri.asc
Free software, free society - http://www.fsfeurope.org
17 years, 9 months
Re: [Gretl-users] small bug
by Riccardo Jack Lucchetti
On Thu, July 6, 2006 11:58, Sven Schreiber wrote:
> Unfortunately I don't have time in the next couple of days, but I was
> thinking that maybe a more formalized testing period would be useful to
> make sure that no existing things were broken by the internal
> restructuring. I have in mind things like the histogram bug (continuous
> vs. discrete) that appeared in 1.5.1. (No offense intended, Jack, it's
> just an example ;-)
Oh, no, you're 100% right: that was a last-minute addition. Exactly what I was
talking about.
As far as I'm concerned, testing can start NOW. Apart from fixes that go in at
the last minute of extra time (pun intended, Sven :-)), we don't foresee any
code change before release.
> So maybe put out a 1.6 release candidate for two or three weeks? It
> would also help if Allin and Jack could tell us what areas have been
> rewritten and that are therefore most likely to contain new bugs.
Well, arima for a start. The new default is now to estimate with full ML
through the Kalman filter. We ran as many benchmarks as we could find, and I'm
now convinced the arma code is pretty good, but I may be wrong. In some cases,
you have a few discrepancies against x-12; in all those cases, reasonably
accurate scrutiny convinced me that native estimates are better (this occurs
especially when the MA part is nearly non-invertible).
Panel data: test the new mechanism for importing data; the statistics should
be ok (again, we ran quite a few benchmarks, but it's never enough). This is
especially important as we plan to implement Arellano-Bond after 1.6.0.
The new function setup: you may have noticed, there's a new mechanism in place
for accessing user-written functions from the GUI. This needs to be tested.
Besides, writing functions is one of the best way to uncover bugs.
The manual has been restructured, with some bit rewritten in large part (arma
& panel), and a few bits added: for example, there's a new chapter entitled
"Discrete variables". The features that we talk about in there have not been
tested a lot, so please have a go at it.
Multiple precision: Talha has already beaten the cr*p out of it, so it should
be in good shape, but have a look at it if you can.
Matrices: a few corner cases were fixed, but there may be still bugs lurking
around. People with decent gauss/matlab/ox experience may want to convert some
of their programs to our own matrix syntax to check if it works ok.
You'll also notice random bits here and there, like multiple time-series
graphs and a partially chnged menu structure: comments on usability are very
welcome too.
> Btw, I'm very happy with gretl's progress!
Glad to hear that. Thanks!
Riccardo "Jack" Lucchetti
Dipartimento di Economia
Facoltà di Economia "G. Fuà"
Ancona
17 years, 9 months
Re: Bug in the Spanish version and ..
by Allin Cottrell
On Thu, 6 Jul 2006, Ignacio Díaz-Emparanza wrote:
> there is a bug in the spanish version of the current Windows
> snapshot. When I launch gretl ita appears a window saying
> "The help file c:\userdata\gretl\gretlcmd_hlp_es.txt is not accesible"
Somehow the help file is not being fully updated; I'll work on
that.
> Apart from this, I am running some Monte Carlo simulations
> with gretl, and I would like to note that, although I put "set
> echo off" at the beginnig of my script file, there are some
> sentences that are being written to the screen...
Thanks for the report. Since this is an issue that other people
are likely to run into as well, let me explain:
* "set echo off" suppresses the echoing of the commands in the
script; that is, you should just see the output from those
commands.
* If you don't want to see status messages such as "Replaced
matrix 'E'", then in addition you should do
set messages off
* Finally, if you want a loop to run quietly, without reporting
the number of iterations completed, add the "--quiet" flag to
the loop command, e.g.
loop i=1..10 --quiet
Perhaps there should be one global command to achieve all this,
but that's how things stand at present.
Allin.
17 years, 9 months
translations and gretl.pot
by Allin Cottrell
Hello all translators,
I'm about to generate a new version of gretl.pot for the next
gretl release. The several .po files will be updated
accordingly. So if you have any uncommitted changes, please go
ahead and commit them.
(To clarify: usually I don't touch the .po files for those
languages where the translator has gretl CVS write permission.
The exception is this point in the release cycle, when the .pot
template needs updating.)
--
Allin Cottrell
Department of Economics
Wake Forest University, NC
17 years, 9 months
