7:31 a.m.
Hello everybody,
at the conference we decided that we should collect all ideas on a GUI
reform (different window arrangements) in one thread. I thought I'd
start this thread here. Please contribute to the brainstorming, ideally
by naming examples and/or giving links.
1) Have a window a bit like Stata where output goes in one area, you
type commands in another one, and there's a command log (and I'm not
sure what else right now). However, I think Stata also sometimes opens
extra windows.
1b) RStudio: I've named this 1b instead of an extra number, because it
seems this is somewhat similar to the Stata window. Please correct me if
this is inaccurate, and/or explain the differences (pros and cons).
2) Have one big meta window that acts a little lig a virtual desktop
just for gretl. All newly opened gretl windows would go into the meta
window, no extra window outside the meta window would ever show up. The
role model for this would be Eviews.
Feel free to add suggestions, this is a brainstorming thread.
Have a good weekend
Sven
7:55 p.m.
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:
Hello everybody,
at the conference we decided that we should collect all ideas on a GUI
reform (different window arrangements) in one thread. I thought I'd
start this thread here. Please contribute to the brainstorming, ideally
by naming examples and/or giving links.
1) Have a window a bit like Stata where output goes in one area, you
type commands in another one, and there's a command log (and I'm not
sure what else right now). However, I think Stata also sometimes opens
extra windows.
1b) RStudio: I've named this 1b instead of an extra number, because it
seems this is somewhat similar to the Stata window. Please correct me if
this is inaccurate, and/or explain the differences (pros and cons).
2) Have one big meta window that acts a little lig a virtual desktop
just for gretl. All newly opened gretl windows would go into the meta
window, no extra window outside the meta window would ever show up. The
role model for this would be Eviews.
Feel free to add suggestions, this is a brainstorming thread.
Have a good weekend
Sven
_______________________________________________
Gretl-devel mailing list -- gretl-devel(a)gretlml.univpm.it
To unsubscribe send an email to gretl-devel-leave(a)gretlml.univpm.it
Website:
https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/
9:26 p.m.
Am 23.06.2019 um 21:55 schrieb Artur Tarassow:
Sven, thanks for initiating this thread. I support the idea that
re-factoring the GUI is useful!
Although below you partly argue against it....
Anyway, some of your points seem to relate to different aspects than the
_arrangement_ of the windows. To keep this thread focussed I would
suggest to discuss those elsewhere. Below I will quote those bullet
points of yours that I believe belong to this thread in a narrow sense.
- 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.)
This is what I meant with "arguing against" it. But I believe it's a
valid point, and I kind of expect that the traditional arrangement (or
non-arrangement) will always remain as an option - although nobody has
explicitly said so, IIRC.
- 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.
Again, I believe the old way will always remain. (Or am I wrong assuming
this ?)
- 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).
Yes, others have said the same at the conference. Tastes and usages differ.
- The Spyder IDE ...
Some inspiration might be gained from IDEs, but then gretl is more than
a programming language. Please point out which are the concrete GUI
features or design choices that you think would be useful in arranging
gretl windows.
thanks
sven
7:52 a.m.
On Sun, 23 Jun 2019, Sven Schreiber wrote:
> - The Spyder IDE ...
Some inspiration might be gained from IDEs, but then gretl is more than
a programming language. Please point out which are the concrete GUI
features or design choices that you think would be useful in arranging
gretl windows.
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
-------------------------------------------------------
2:25 p.m.
Am 24.06.2019 um 09:52 schrieb Riccardo (Jack) Lucchetti:
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 (
If the pro view is just one window of two, how can it occupy the full
screen (without hiding the other window)?
Apart from that, your arrangement doesn't sound bad. Plus, gluing two
windows together seems relatively easy on many OSes, so as a user one
could even consolidate the two.
[*] 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.
I think that's right and is also related to Artur's point of using
virtual desktops. Emulating that on Windows has lots of devils in the
details. For example, I think nowadays you can put a group of windows on
a different virtual screen in Windows 10 relatively easily, but if the
application opens new windows -as gretl does- they appear somewhere else.
I know the Gnome/GTK movement always had the credo that window
management is for window managers and not for the programs themselves,
but the reality is that MS Windows still follows a different approach there.
cheers
sven
3:37 p.m.
On Mon, 24 Jun 2019, Sven Schreiber wrote:
> 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 (
If the pro view is just one window of two, how can it occupy the full
screen (without hiding the other window)?
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.
Apart from that, your arrangement doesn't sound bad.
Glad you like it
Plus, gluing two windows together seems relatively easy on many OSes,
so
as a user one could even consolidate the two.
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
-------------------------------------------------------
5:10 p.m.
Am 24.06.2019 um 17:37 schrieb Riccardo (Jack) Lucchetti:
On Mon, 24 Jun 2019, Sven Schreiber wrote:
>
> If the pro view is just one window of two, how can it occupy the full
> screen (without hiding the other window)?
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.
OK, then I have to qualify my previous statement a little: So in the pro
view I get (perhaps) a list of defined functions, but not a list of
available series. I'm afraid I always forget the exact spelling of my
series, so I would have to jump back and forth.
But again, I already suggested to glue the windows together as a user...
-s
4:08 p.m.
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
11:55 a.m.
On Tue, 25 Jun 2019, Henrique Andrade wrote:
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.
Thanks, Henrique! It's very helpful to see what some of the
suggestions might actually look like.
If you wouldn't mind sharing with me (on- or off-list, as you wish)
how you made these mock-ups I'd be grateful!
Allin
12:06 p.m.
On Wed, 26 Jun 2019, Allin Cottrell wrote:
On Tue, 25 Jun 2019, Henrique Andrade wrote:
> 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.
Thanks, Henrique! It's very helpful to see what some of the suggestions might
actually look like.
If you wouldn't mind sharing with me (on- or off-list, as you wish) how you
made these mock-ups I'd be grateful!
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
-------------------------------------------------------
6:29 p.m.
Am 26.06.19 um 13:55 schrieb Allin Cottrell:
On Tue, 25 Jun 2019, Henrique Andrade wrote:
> 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.
Thanks, Henrique! It's very helpful to see what some of the
suggestions might actually look like.
If you wouldn't mind sharing with me (on- or off-list, as you wish)
how you made these mock-ups I'd be grateful!
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
8:14 p.m.
Dear team,
If I (correctly) understood your messages, you are thinking that the
screenshots are from a real implementation of the proposed GUI.
Unfortunately they aren't. I made them using the "graphic editor
magic". I'm sorry if I led you to this missunderstanding.
I would love to know how to use some IDE (like Gnome Builder) to
create a real skeleton for Gretl's GUI.
Anyway, thanks a lot for your feedbacks!
Um abraço,
Henrique
8:17 p.m.
Am 26.06.19 um 22:14 schrieb Henrique Andrade:
Dear team,
If I (correctly) understood your messages, you are thinking that the
screenshots are from a real implementation of the proposed GUI.
Unfortunately they aren't. I made them using the "graphic editor
magic". I'm sorry if I led you to this missunderstanding.
I would love to know how to use some IDE (like Gnome Builder) to
create a real skeleton for Gretl's GUI.
Anyway, thanks a lot for your feedbacks!
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
9 p.m.
Em qua, 26 de jun de 2019 às 17:17, Artur Tarassow <atecon(a)posteo.de> escreveu:
Am 26.06.19 um 22:14 schrieb Henrique Andrade:
> Dear team,
>
> If I (correctly) understood your messages, you are thinking that the
> screenshots are from a real implementation of the proposed GUI.
> Unfortunately they aren't. I made them using the "graphic editor
> magic". I'm sorry if I led you to this missunderstanding.
(...)
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.
That's good to know, Artur :-)
I'm far from a fluent English writing/speaking and sometimes I do some
language gaffes :-( But let me try to explain/answer some points:
(1a) @Jack wrote:
I like number 2 very much.
(1b) @Marcin wrote:
The same with me.
(1c) @Artur wrote:
Thanks, Henrique! I also prefer example '02'.
The main difference between 1 and 2 is the menu position. The menu are
associated with the current script window on 1, this design allow the
possibility to add another tabs that are not Hansl sripts in the
future. For example: if we open a Python script we will have another
set of icons. The same goes to all foreign languages that we support
today (R, Julia, etc.)
(2) @Artur wrote:
(...)
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.
I agree with you and also I suggest the possibility of detachment.
With this feature we can work with two separate displays :)
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?
Bundles could be placed on a new tab on up-right pane just like
series, strings, etc.
4) What about putting the CLI also somewhere left bottom?
On my very humble opinion I think we could place CLI/Console on a new
dedicated window (like the one used by Python Tester on the screenshot
I sent). I really don't know if CLI/Console is a very popular feature
and, if that is the case, it could be reformulated to try get
attention from our users.
5) Where would we see whether gretl is currently active?
The blue bar above the tab.
(...)
Best regards,
Henrique
7:02 a.m.
Am 26.06.2019 um 23:00 schrieb Henrique Andrade:
Em qua, 26 de jun de 2019 às 17:17, Artur Tarassow
<atecon(a)posteo.de> escreveu:
>
> 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.
That's good to know, Artur :-)
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
1:57 a.m.
On Wed, 26 Jun 2019, Artur Tarassow wrote:
Am 26.06.19 um 22:14 schrieb Henrique Andrade:
> Dear team,
>
> If I (correctly) understood your messages, you are thinking that the
> screenshots are from a real implementation of the proposed GUI.
> Unfortunately they aren't. I made them using the "graphic editor
> magic". I'm sorry if I led you to this missunderstanding.
>
> I would love to know how to use some IDE (like Gnome Builder) to
> create a real skeleton for Gretl's GUI.
>
> Anyway, thanks a lot for your feedbacks!
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.
Me too. I didn't think you'd actually produced a new gretl GUI but
would be interested to know something about the "graphic editor
magic", and those icons that are not (I think) already included in
gretl.
Allin
1765
days inactive
1771
days old
16 comments
6 participants
participants (6)
-
Allin Cottrell -
Artur Tarassow -
Henrique Andrade -
Marcin Błażejowski -
Riccardo (Jack) Lucchetti -
Sven Schreiber