* The GUI command log (available via /Tools/Command log) now updates itself in real time: if you keep it open you'll see the CLI equivalent of GUI actions appear line by line. (Thanks to Jack for suggesting this.)

Well, actually, I should say thanks to Allin and Jack for the implementation and they should say thanks to StataCorp for the idea ;-)

I like all these ideas. Can you suggest what might be a good icon for the command log?

On Oct 5, 2014, at 6:16 PM, Riccardo (Jack) Lucchetti <r.lucchetti(a)univpm.it&gt; wrote: > On Sun, 5 Oct 2014, Riccardo (Jack) Lucchetti wrote: > >> On Sun, 5 Oct 2014, Allin Cottrell wrote: >> >> I like all these ideas. Can you suggest what might be a good icon for the command log? > > I don't remember which program it was, but I distintly recall that some software used to have a wooden log for that. Would it be too much of a lame geek in-joke (untranslatable, by the way)? If we could find an alternative, I'd be relieved. But OTOH I can't think of anything suitable. How about a quill? In my mind, it conjures up images of the captain's log. Something like this: http://www.clipartpanda.com/categories/quill-and-paper-clipart ------------------------------------------------------- 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 ------------------------------------------------------- _______________________________________________ Gretl-users mailing list Gretl-users(a)lists.wfu.edu http://lists.wfu.edu/mailman/listinfo/gretl-users

On Mon, 6 Oct 2014, Riccardo (Jack) Lucchetti wrote: > On Sun, 5 Oct 2014, Riccardo (Jack) Lucchetti wrote: > >> On Sun, 5 Oct 2014, Allin Cottrell wrote: >> >>> I like all these ideas. Can you suggest what might be a good icon for the >>> command log? >> >> I don't remember which program it was, but I distintly recall that some >> software used to have a wooden log for that. Would it be too much of a lame >> geek in-joke (untranslatable, by the way)? If we could find an alternative, >> I'd be relieved. But OTOH I can't think of anything suitable. > > How about a quill? In my mind, it conjures up images of the captain's log. > Something like this: > > http://www.clipartpanda.com/categories/quill-and-paper-clipart Ah, that looks like it might work. The "wooden log" icon was used by gnome-logs at one point, but was severely frowned upon by the gnome Human Interface Guidelines people, understandably! (Much as I like Peter's USS Enterprise idea, it seems at too much of a remove: Ship -> Captain -> Captain's log -> log. A bit like Cockney rhyming slang but lacking the shared culture!) Allin _______________________________________________ Gretl-users mailing list Gretl-users(a)lists.wfu.edu http://lists.wfu.edu/mailman/listinfo/gretl-users

On Sun, 5 Oct 2014, Henrique Andrade wrote: > Dear All, > > I would like to suggest something this: > > https://cdn0.iconfinder.com/data/icons/seo-smart-pack/128/grey_new_seo-11... > > >

> > > > Why? Because we are looking to the code ;-) In fact, I quite like that, because it reinforces the "gears" metaphor for hansl scripting. By the way: I have the feeling that, in the era of Android, our current set of icons for the main window looks a bit passé, two-dimensional and, most of all, quite heterogenous in therm of style. I personally don't mind from an aesthetic viewpoint, but I realise that this may be bad marketing for the project. Opinions?

On Mon, 6 Oct 2014, Sven Schreiber wrote: > Am 06.10.2014 um 08:54 schrieb Riccardo (Jack) Lucchetti: >> On Sun, 5 Oct 2014, Henrique Andrade wrote:

> If somebody could provide pointers to webpages full of free and > technically suitable (gnome) icons, then we would have a basis for a > discussion on which to choose. We already have quite a few nice svg icons, thanks to Hélio (they're in CVS for the curious, under the "vectorimages" subdir). However, the technical issues involved with using SVG instead of the venerable xpm format we use were outlined in a post by Allin on the devel list a few months back: http://lists.wfu.edu/pipermail/gretl-devel/2014-March/004920.html

On Mon, 6 Oct 2014, Giuseppe Vittucci wrote: > Dear all, > > a few comments on the ideas that Jack and the others have suggested. > I leave aside the issue of the icons for the moment. > > I really like the suggestion to give gretl users the possibility to open > the log window automatically when they launch the program, or at least > introduce an icon at the bottom of the main window to open the log. I like the latter proposal better than the former. Having the log open automatically may be distracting and a waste of screen space. I, for example, often use the gretl GUI client simply for writing hansl code. The command log would be no use for me whatsoever. > One possible issue associated with this suggestion is that this > increases further the number of open windows in gretl. The need to > constantly move across quite independent windows is something that > sometimes I find really annoying. I appreciate the reasons behind this > strategy and I am not suggesting to switch to a completely different > setting. A possible escape and, according to me, a way to have the best > of both worlds is giving users the possibility to join/divide the > frames. I am thinking about something similar to what you can do in > Blender: > http://wiki.blender.org/index.php/Doc:2.6/Manual/Interface/Window_system/... > If you introduce also the possibility to save a given arrangement, this > will give the possibility to easily customize the workspace in a very > flexible way, without harming users with small screens. This way a user > can also easily recreate any frame arrangement he/she is more familiar > with (rstudio, stata, matlab,eviews...). (Any small change that reduces > switching costs should be welcome if we want to increase the number of > users.) This has been discussed many times. I personally don't want the gretl GUI to become a window manager, and I think Allin feels the same way too. By the way, have you tried Alt-PgUp/Alt-PgDn? > Finally, some thoughts about the suggestion to introduce in the log > windows a "gears icon" to re-run the commands. > I suggest to increase the linkages between the log window and the shell: > instead of automatically re-run a command, by clicking on a command in > the log window this simply appears in the shell (it is not automatically > run), so you can modify it before running it (that's because most of the > time you do not want to re-run exactly the same command, but a slightly > different version of it). > > I know that the previous commands can be recovered using the up arrow in > the shell, but when the command is quite "old" and you do not remember > exactly how far it is in the history, this process can be quite time > consuming. I take it that you use the word "shell" as a synonym of "console". In practice, you're suggesting to Stata-ize gretl. Heresy! ;) More seriously: I think that, from the viewpoint of workflow opimisation, that would be bad. From my limited experience, this is a bad habit I've seen it Stata users: (a) try something (b) see what happens (c) retry with minimal variation and so on, and so forth, until you hit something that you like. Let's leave aside for the moment the fact that this IMHO leads to very bad econometrics: this is very personal judgement, and I'm no David Hendry or Joshua Angrist to force down people's throats my own ideas of what's right and wrong. I suspect this leads to very inefficient workflow. The way I see it, the right place for experimenting isn't the console: it's a hansl script. That's why we're giving you the possibility of running a selection of code, to keep more than one tab open, etcetera. So, a hypothetical scenario close to what I think you have in mind is: (1) run something from the menu (2) copy-n-paste the relevant line(s) ion the command log into a hansl script (3) play with that (4) when you're happy, save the script. > Of course, it goes without saying that: > - these are just a bunch of comments (that I wrote down just because > Jack asked for them), so take them as they are > - these issues might be probably better discussed in the Gretl-devel > list (which I have just subscribed...); > - this is an open source project and the power to decide where to go > should be proportional to the time spent in the project and the capacity > to make things happen, and I lack of both... ;-) This is a community: the strenght of the project comes from the possibility, which is open to everyone, to contribute by doing what they're good at. Some folks are good at translating, some folks are good at finding bugs, one guy is stellarly good at writing C code. ;)

a few comments on the ideas that Jack and the others have suggested.

One possible issue associated with [the suggestion of making the command log window open automatically] is that this increases further the number of open windows in gretl. The need to constantly move across quite independent windows is something that sometimes I find really annoying.