On Wed, Jul 12, 2006 at 01:13:17PM -0400, Talha Yalta wrote: Ok, I'll jump in, I'll try to summarize the whole menu debate and I'll add my suggestions. (Allin, if we decide to do substantial changes I'll be glad to help you tracking the necessary changes in documentation) * File - Allin: [...] 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?). - Cri: this could be one solution, but some people (like me :) tend to view the "File" menu as the place where all "disk I/O" operations take place, so I'd leave there all the "load/create/save" commands pertaining to data files, session files, command files, databases, and now also function package files. Of course all these items should be properly grouped and arranged in submenus: first I'd group together the items related to data files (so that they are immediately accessible), and I'd arrange the others into submenus: File->Session, File->Commands, File->Databases, File->Functions (yes I'd move here the "Function package editor" from Utilities, so that one has all the function packaging commands handy) It would look like this: File Open data Append data Save data Save data as Export data Send to Clear dataset ------------- Commands Open command file New command file ----------------- Sessions Open session file Save session file Save session file as -------------------- Databases Browse databases -------------------- Functions Load Package editor -------------------- Exit * Utilities - Allin: rename as Tools, put the items moved out of File under Tools. Also Preferences should go here - Cri: I agree. Something like this could do? Tools Statistical tables p-value finder Test statistics calculator -------------------------- Gretl console View command log Icon View -------------------------- Start GNU R -------------------------- NIST test suite -------------------------- Preferences * Session - Sven: maybe move it under File - Jack: maybe move it under Utilities - Allin: let's move it under File - Cri: let's move it under File * Data - Allin: basically contains "things you might want to do with more than one variable" -- other than constructing a model, which has its own menu branch. Examples: graphing, summary statistics, etc. Plus some things pertaining to the data set as a whole -- other than setting the sample range, which again has its own branch. Examples: edit values, read informative text, if any - Sven: I would at least suggest to group the commands together that are related to dataset-management. (Right now there are some at the top and some at the bottom.) As a result the "data" menu would have two main blocks, one for management commands, and one for descriptive statistics (loosely speaking) - Cri: I agree with Sven: I'd group together commands that modify the data (values, observations, info), separating them from graphing commands and commands for descriptive stats. I'd also suggest to move here from the Sample menu all the commands which irreversibly modify the dataset (not just the current sample): Dataset structure, Compact/Expand data, Transpose data, Add/Remove case markers. Thus, under "Sample" we'd only have reversible commands (seems more user-friendly to me). Data Display values Edit values Add observations Remove extra observations ------------------------- Dataset structure Compact data Expand data Transpose data ------------------------- Read info Edit info Print description Add case markers Remove case markers ------------------------- (graphs...) ------------------------- (descriptive statistics...) * Add - Cri: here again I'd just re-group items in three groups: - Transformations of existing variables (lags, logs, squares, diffs, logdiffs, seasdiffs) - New "special" variables (index, normal, uniform, trend, define new variable) - New dummy variables (discrete, periodic, unit, time) * Sample - Allin: The core functionality here is setting the sample range in various ways. Some other functions have been added here (e.g. set dataset structure, transpose data), and the location of these extra items may be debatable. - Cri: as I said in "Data", I'd move away all commands which permanently modify the dataset * Variable Everything's fine here? :-) * Model - Jack: let's re-arrange commands like this: Model Ordinary Least Squares ---------------------- Other linear models WLS Heteroskedasticity corrected 2SLS High precision OLS ---------------------- Time series GLS Cochrane-Orcutt Hildreth-Lu Prais-Winsten Autoregressive estimation ARIMA GARCH Multiple VAR VAR lag selection VECM Johansen cointegration test Cointegration test/Engle-Granger ---------------------- Panel ---------------------- Nonlinear models Logit Probit Tobit Poisson Logistic NLS ---------------------- Robust estimation LAD Rank correlation ---------------------- Maximum likelihood ---------------------- Simultaneous equations - Cri: I agree with Jack and (as you might have noticed) I think this grouping/submenus style should be extendend also to other menus -- GPG/PGP Key-Id 0x943A5F0E - http://www.linux.it/~cri/cri.asc Free software, free society - http://www.fsfeurope.org

On Thu, 13 Jul 2006, Riccardo Jack Lucchetti wrote: Amen. Here's the deal: Someone has to design a data structure to hold all the information on the preferences in gretl's libset.c. This structure should be flexible enough to make it fairly easy to add new "set" elements (something we've done a fair amount lately), yet explicit and uniform enough to permit a simple, algorithmic formulation of the GUI elements that compose an "Advanced" Preferences dialog box. The GUI code has to be able to interface with libset and say something like: "How many things should I provide for the setting of?". "OK, got it. Now, for the i'th thing to be set, should it be a boolean, an int, a matrix, a structure with (how many did you say?) elements." "Ah, and what are the limits to the thing to be set: does it have to be positive (e.g. if an int or a double)? And what string should I present to the user as the label of this thing?" The GUI has to be able to figure out, for each settable thing (or sub-thing), what is the appropriate interface: a spinner (with what range/limits?), a drop-down selector (from what domain of selection?), a textual entry field (of what maximum length?), ... GUI design 101: A dialog box should, ideally, be constructed such that it's simply impossible for the user to create invalid input. Failing that -- if the data entry "just has to be" relatively free-form -- the input should be checked immediately for validity, and if it's bad the GUI should come back with an informative error message and take the user back to the particular step where something went wrong (with an option to Cancel if the user can't be bothered to figure it out). The last time I used Eviews I found that it egregiously violated this principle. I would get to step N in something fairly complicated then get a box saying something like "Error: invalid input" and be dumped back to square 1, with no indication of what was wrong with the input. This is a bad user experience. I don't want to create a GUI for libset until we're reaady to do it right. It's not brain surgery, but it is quite time consuming. Any volunteers? Allin.

On Fri, 14 Jul 2006, Ignacio Díaz-Emparanza wrote: Actually, changing the layout of the GUI menus (while not changing the substance of what the menu items do) is a pretty safe operation -- rather unlikely to introduce bugs. *IF* we have agreement that the current trial setup for the menus is an improvement, and that it's a setup we can live with for a while (we don't want to make such changes too often), I'd be inclined to go ahead with it. The costs are * Translators have to do a certain amount of cutting and pasting in the .po files (after I put out a new .pot). * The relevant section of the User's Guide has to be rewritten. Do we think this is worth it? That's good to hear. Allin.

On Fri, 14 Jul 2006, Cristian Rigamonti wrote: Yes, let's "sleep on it" for a couple of days. I have to say that I rather like the new layout already. The main thing that still seems a bit illogical or clunky is to do with the Data and Sample menus: * As Cri said, the dataset-restructuring items really shouldn't be under "Sample"; "Data" would be more appropriate. * But, as I've said, putting them there overburdens "Data". * This could be got around if we had a separate menu tree dedicated to "descriptive statistics and graphs", but people seemed to like the idea of reducing the number of menu trees, and I'm not sure what a snappy title for the notional added tree would be ("View"?). Allin.

I find that having followed Cri's suggestions on the menus, some other things seem to be "falling into place". I've done a little more tidying of menu entries, and have seriously cleaned up the mechanism for creating a new data set (now under /File/New data set). Hope you like the results! There's a new Windows snapshot available. Allin.

On Fri, 14 Jul 2006, Talha Yalta wrote: Good, thanks. Yes, I plan to put the "seed" setting into the dialog box where a random variable is defined. It's not really a "Preference", but a one-time choice. I think you misunderstand the deal with the missing value code. It's not a "preference" at all. It's there to handle the case where you import a data set in which the missing value code is -333 or something weird, and you want to tell gretl to set all instances of -333 to NA. It's under the Variable menu too in case you've appended a particular variable that has a non-standard missing value code. But since gretl can handle most sane NAs, there's a case for saying that these items are too arcane to be in the GUI menus at all. I disagree. "New data" is a little-used item (one is much more likely to open or import data than to construct a data set from zero), so it shouldn't be at the top of the menu. And I like Cri's idea that all the "data set" items should be together, thus "clear data" belongs where it is, IMO. The Variable menu is, I think, fairly clear once you get used to it: it has all sorts of things you can do with just one, single variable. (Notice that it goes disabled whenever you select more than one variable in the main window.) The business of handling multiple selection of variables is not totally consistent (though I've made some improvements lately). In most cases, when you have more than one variable selected in the main window, that selection is "respected" when you execute a multi-variable command. For example, select 3 variable in the main window and go to Data/Correlation matrix/selected variables -- or go to /Add/logs of selected variables. On the other hand, selecting a bunch of variables in the main window is not sufficient to provide the structure needed for some commands (e.g. a model -- which one is the dependent variable? -- or multiple scatter plots -- which one goes on the Y axis?) In these cases you have to use a specific selection dialog. But if you spot any cases where the main window selection should be sufficient, yet you're forced through a selection dialog, then let me know -- that is probably a design bug. Well, yes, it's supposed to be readily usable! IMO the Eviews interface is a real piece of obfuscation. I suppose it makes people feel very clever when they figure out how to use it. 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. I'd say about the size and shape of the gnumeric splash. I can probably find a reasonably high resolution Gretel image for you to mash on. OK, it's getting late, and this one is quite complex. I'll respond tomorrow... How about, in the Windows version, a scroll-by of all the DLLs, OCXs, COM objects and .NET components we're initializing? Allin.

On Sat, 15 Jul 2006, Cristian Rigamonti wrote: I'm going to try another mock-up along the lines you suggest. I think this would finally give us a very logical set of main-window menus. Allin.

If I can add something, there is smal suggestion to move "Create data set" function from Tools -> Create data set to File -> Databases -> Create data set. Best regards, Pawel Tadeusz -- qfel(a)mat.uni.torun.pl http://www.mat.uni.torun.pl/~qfel

I wish I was better at programming but I know there is a package called r-commander. I wonder if it would be possible to use some code from it for this type of job. Also, it might be worth looking at how those guys decided on the menu structure. Might give an idea or two. -- 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) --

On Fri, 14 Jul 2006, Riccardo Jack Lucchetti wrote: Thanks, a very useful start. Allin.

On Wed, July 12, 2006 19:13, Talha Yalta wrote: 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? 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". This is very interesting. I didn't know of the ELV program. Apparently, its source is not available, which is a shame, because we could have ripped at least some algorithms from it. Anyway, as you say, the inaccuracies in gretl seem unlikely to have any impact on real applied work, but still it'd be nice to set them right (but maybe not for 1.6.0). Riccardo "Jack" Lucchetti Dipartimento di Economia Facoltà di Economia "G. Fuà" Ancona

On Thu, 13 Jul 2006, Sven Schreiber wrote: Let's give this some more thought, but not for 1.6.0. The idea of the session icon window is not fully developed, I admit. As Sven says, it has some elements of an additional toolbar (e.g. the generic "edit notes" and "edit dataset" icons). But it's also a sort of arena where the user can take stock of models estimated, and graphs created, and manipulate them in various ways. How exactly this arena best fits with the rest of the app, I'm not sure yet. An alternative design which some people like (but I'm not sure I like it, and it's not encouraged by GTK) is MDI, Multiple Document Interface. On that model, gretl would be a bigger window, and things like models, data spreadsheet, graphs and what-have-you would "minimize" or "iconize" not onto the main, background desktop but onto the "gretl desktop". The principal element of the current gretl window -- that is, the frame showing the variables in the dataset -- would itself be a resizable, iconizable window within the grand gretl window. Very Windowsish. Personally I find it quite annoying when an app tries to play at being a desktop: I already have a perfectly good desktop, thank you. I raise this because (a) it's an approach that is familiar to MS Windows users, and (b) if we were re-designing the main gretl window substantially, we'd have to think carefully about how it relates to this model. We don't want something which is "sort of like MDI but confusingly different", I don't think. More pointedly, I suspect that putting the icon view into the main window would create an expectation on the part of Windows users (at least) that the program has an MDI design, in which case they'd find it broken unless it conforms to the usual MDI conventions. Allin.