|
From: | Daniel J Sebald |
Subject: | Re: [patch #7847] Make gnuplot Qt terminal default for GUI/IDE via environment variable |
Date: | Sun, 23 Sep 2012 04:27:07 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16 |
On 09/22/2012 09:55 AM, Mike Miller wrote:
On Sat, Sep 22, 2012 at 10:18 AM, Ben Abbott<address@hidden> wrote:On Sep 22, 2012, at 3:30 AM, Daniel J Sebald wrote:I wanted to get a small survey of how people feel the GUI/IDE should behave with regard to the gnuplot terminal which includes Qt support in its latest version. Mike submitted an addendum to a small patch that attempts to use gnuplot "qt" terminal by setting environment variable GNUTERM and falls back on the default if the version of gnuplot doesn't have "qt" support: http://savannah.gnu.org/patch/?7847 If the latter happens then a message from gnuplot:Unknown or ambiguous terminal name 'qt'appears on the screen. Mike is proposing that if the user has GNUTERM variable already defined in their environment, then that should take precedent. I'll give my feelings on this, but I'm open to any behavior.I'm pretty open to any behavior as well. My main concern is when I see code that unconditionally sets an environment variable without considering that it may be wiping out a user's preferences.
I understand that.
Definitions: console -- the system console that octave/GUIDE+O is launched from terminal window -- the window in the GUIDE+O having the redirected octave output First, I think the preference is going to be that GUIDE+O use Qt terminal. It is a nice looking terminal using the Qt icons giving it a look and feel that match GUIDE+O. It has a couple more features than X11 terminal and is more robust in terms of aliasing, alpha-scaling, print buttons, etc. It will be ostensibly the same figure window on all three (four?) major platforms. There is the option to customize a figure window and place just the plot within the figure window (i.e., forward looking).Dan, is your intent here that only Qt GUI users get the Qt gnuplot while console users get the X11 gnuplot?
No, that wasn't my intention. Someone using the console should be able to select Qt gnuplot if they like. I was thinking X11 should remain the default (i.e., the current defaults). I think there is some library that needs to be present to use Qt. If the GUI is running, we all the Qt support is present. If running from the console, that is not assured.
If the Qt gnuplot is preferred, and it sounds like it may be based on this list of features,
I must say, I think the alpha scaling of Qt is going to win out eventually if that is made accessible to users somehow.
should it not be the default for everyone on every system (if available) regardless of whether Octave is running in terminal or Qt mode?
Not sure. I'm wondering if we should just leave octave-cli figures as they are, at least for the next major rev. It might be too discombobulating for the user running the console to see a new type of window, then run GUIDE+O and see the similar look and feel. S/he might wonder if that were a mistake. It will be a contrast of the previous Octave (i.e., non-GUI octave) and the new interface.
Of course, after a short while users will posting messages "Can't we have that Qt window for the console version?" So, maybe in a later version.
The other thing is that I'm not real familiar with the Apple figure window. Maybe there are some who prefer that over Qt.
To avoid the gnuplot error, I suggest not defining GNUTERM=qt before checking that gnuplot supports the qt terminal. The gnuplot toolkit includes a private function __gnuplot_has_terminal__.m which will detect if gnuplot includes support for the qt terminal. .../scripts/plot/private/__gnuplot_has_terminal__.m To make use of this for the gui, we may need to make the function public. In any event, if it is in your path, all you need to do is ... has_qt = __gnuplot_has_terminal__ ("qt");Ben, good point, I made the following change locally and this brings up either the X11 or Qt gnuplot, depending on which variant I have installed. Is this reasonable to test for and prefer Qt on all systems over the current system-dependent defaults?
Feel free to investigate a suitable behavior. Probably get insight that way.
Dan
[Prev in Thread] | Current Thread | [Next in Thread] |