Hi all, Sven, thanks for initiating this thread. I support the idea that re-factoring the GUI is useful! Let me just collect some ideas in an unstructured manner -- maybe some items are of help: - Configurable themes -- as the editor already supports -- is very useful. However, currently only the editor field changes towards a different design style but not remaining gretl GUI elements. This looks inconsistent (even though personally I don't really care about it). - At the very beginning, I was annoyed by the separate main and editor windows. But I got used to it, and nowadays I like the flexibility it offers even though most of the time I have a fix arrangements of windows. Personally I am not a big fan of fixed window structures, as the 'optimal' arrangement depends very much on the use case (programming, debugging, visual inspection by clicking through the menu etc.) - Following the idea of Eviews limits flexibility as such that one could not move a separate window to another virtual desktop (which I use heavily) for instance. Some other programs such as Matlab have the option to detach certain elements. But re-attaching can become tedious. - Keep the CLI window optional (I rarely use it as writing a command, highlighting it and executing it through "Ctrl+r" within in the editor window is quickly done). - However, adding a 2nd tab to the CLI window which includes a shell terminal for executing shell commands (git control?) -- as in RStudio or IntelliJ -- would be nice but has no high priority I guess. - I've got the impression that for professional programmers the "IntelliJ" IDE (URL: https://www.jetbrains.com/idea) seems to be _the_ current state-of-the-art editor. I use it for Python projects and it has nice features indeed -- even though the whole package is not really suited for typical data science work. The Spyder IDE (URL: https://www.spyder-ide.org) is another alternative which is similar to RStudio but feels more structured. Maybe it's worth to take a closer look at it. - A list of defined functions at the side of the editor: For larger projects with many functions written down in a single file it becomes quite difficult to locate these quickly. If one could jump directly to a function by clicking at its name, that would be useful I guess. Ok, that's it for now. Best, Artur Am 21.06.19 um 09:31 schrieb Sven Schreiber:

On Sun, 23 Jun 2019, Sven Schreiber wrote: Very true. In fact, we should never forget that what we offer is a rather unique combination of a point-n-click app (nice for basic teaching) and a full-featured programming environment (nice for advanced teaching and research work). Allin and I briefly discussed a few ideas over dinner in Naples, and I believe the following proposal may be a good starting point for keeping together different needs. When you launch the program, TWO windows appear: one is the present GUI main window, which would remain unmodified (bar some marginal adjustments --- see below); I'll call this the "basic" view. The other one is what I'll call the "pro" view. The pro view should typically occupy the full screen, and would look like this (forgive the ASCII rendition) +-------------+-------------+ | left tabs | right tabs | +-------------+-------------+ | left icons | | +-------------+ | | | right pane | | left pane | | | | | +-------------+-------------+ The "left pane" would be what we now have as the script editor, and the "left tabs" areas would show you tabs for all currently open scripts. The "right tabs", instead, contains a fixed set of tabs, which control what you get in the right panel. The list for the right tabs that I have in mind at the moment is: * Console * Script output * Icon view * Command log * Functions list The "Console" tab would give what the console is today, whereas the "Script output" tab would contain the output from running scripts, much like the "script output" window we have now, only it'd become a tab for the left pane. The "Icon view" and "command log" would be what we have today. The "Function list" tab would be what I understand Artur had in mind, that is, a list of currently defined functions (maybe together with return type); perhaps, this could be clickable, in which case you'd get a listing of the function that is currently in memory (but I'm not quite sure about this one). No output would be created in separate windows, with two exceptions: GUI actions behave as they do today (so you still get the "Model" window when you run an estimation command from the GUI, for example), and plots. Plots would still appear in pop-up windows, although possibly, we could have ONE plot output window with tabs, but I'm not sure I like this very much. The general idea is that you use the "basic" view for simple exploratory data analysis, point-n-click actions, stuff that you need when teaching undergrads, or when you load a datafile and you'd like to make sense of what it contains. In fact, the "basic" view could be simplified somewhat, since elements like the console and the command log would be part of the "pro" window. Instead, the "pro" view is the window you'd typically like to have up front when you have a more complex problem, that requires scripting, trial-and-error etc. This arrangement would limit the proliferation of windows you currently have, that Allin and I don't dislike at all, but it seems we're the only ones[*]. Please note that this proposal is by no means rigid, but IMO puts together most ideas that came out during the brainstorming session we had in Naples during the Thursday afternoon session, so comments are very welcome. A final point: as you probably know, my coding skills are very limited when it comes to GUI programming, so all the work (except testing) would be on Allin's shoulders. The present proposal would also have the advantage of reusing quite a lot of the GUI code we currently have. Let the flamefest begin! [*] Although, I must say, it could be an OS thing. I spent some time on a friend's pc yesterday and I must admit that on Windows it's not at all easy to chase all the windows that we open today when we do things. I find this not to be a problem on Linux. ------------------------------------------------------- Riccardo (Jack) Lucchetti Dipartimento di Scienze Economiche e Sociali (DiSES) Università Politecnica delle Marche (formerly known as Università di Ancona) r.lucchetti(a)univpm.it http://www2.econ.univpm.it/servizi/hpp/lucchetti -------------------------------------------------------

On Mon, 24 Jun 2019, Sven Schreiber wrote: That's the point. You use one or the other. When you use the pro view, the basic view is in the background, and vice versa. Glad you like it That's not what I had in mind, but sure, why not. ------------------------------------------------------- Riccardo (Jack) Lucchetti Dipartimento di Scienze Economiche e Sociali (DiSES) Università Politecnica delle Marche (formerly known as Università di Ancona) r.lucchetti(a)univpm.it http://www2.econ.univpm.it/servizi/hpp/lucchetti -------------------------------------------------------

Dear Sven, Artur and Jack, Based on the "pro view" suggested by Jack and on the RStudio/Spyder UI, I did some mockups for a (possible) new Gretl GUI. I'm attaching three images: 1. GretlGUI_JackSuggestion_based_01.png 2. GretlGUI_JackSuggestion_based_02.png 3. Python Tester (elementaryOS).png Images 1 and 2 are slightly different from each other. IMHO they represent a more modern GUI when we take a look at modern IDEs. The thirdone is a screenshot of the software Python Tester for elementaryOS (https://appcenter.elementary.io/com.github.bartzaalberg.python-tester/). (Again) IMHO it would be great to have Console in a separate window for simple coding, but with the output togheter (for me, this simplifies the use of Console) . Additionally, the design used by Python Tester (based on Swift Playground from Apple) look very nice and intuitive. Best regards, Henrique Andrade

On Wed, 26 Jun 2019, Allin Cottrell wrote: I like number 2 very much. ------------------------------------------------------- Riccardo (Jack) Lucchetti Dipartimento di Scienze Economiche e Sociali (DiSES) Università Politecnica delle Marche (formerly known as Università di Ancona) r.lucchetti(a)univpm.it http://www2.econ.univpm.it/servizi/hpp/lucchetti -------------------------------------------------------

Am 26.06.19 um 13:55 schrieb Allin Cottrell: Thanks, Henrique! I also prefer example '02'. However, even though I've already sent you some remarks on Twitter, let me list those and some additionall points here on the mailing list as well: 1) The editor window is huge which is nice. Currently we can create vertical or horizontal panes. This is useful for code comparison in different parts of an inp-file. I plead for having this feature also the new version. 2) I like the style as it looks clearly arranged. I just miss entries for bundles, string arrays and matrix arrays. Maybe string arrays could be in a "Strings" folder and matrix arrays in the "Matrices" folder. 3) Where are bundles stored and accessible? 4) What about putting the CLI also somewhere left bottom? 5) Where would we see whether gretl is currently active? 6) We have to think about the behavior of plots. I prefer individual plots which can be arranged in a flexible manner by the user for comparison and edting or so... Thanks Henrique! Artur

Am 26.06.19 um 22:14 schrieb Henrique Andrade: Hi Henrique, I think we got it that these screenshots are just illustrations. This is very helpful! I was just thinking what kind of information may be "behind" some of the icons I mentioned. Best, Artur

Am 26.06.2019 um 23:00 schrieb Henrique Andrade: Thank you very much, Henrique, for these illustrations. They look great. I think the reactions prove the power of images and of a graphical interface in general, which is why gretl will provide value added even in times of popular data programming languages like Python etc. cheers sven