#199 wxWidgets terminal
This patch implements a wxWidgets terminal. It provides
all the basic functionnality, but also mouse+hotkeys
support and enhanced text mode.
It is designed to be cross-platform (really few lines
to tweak, apart from the makefiles), and it will
provide other benefits such as text anti-aliasing, and
even line anti-aliasing depending on the platform port
of the library itself (for example, with recent gtk+
and cario).
Moreover, it is easy to add gui facilities, through
menus and toolbars, as it is already done by OS/2 and
windows implementations.
Note : this is really a work-in-progress, and it can
affect gnuplot's general behaviour as it modifies the
main loop to process the terminal events. In
particular, it adds some overhead by initializing the
wxwidgets library.
Logged In: YES
user_id=1333817
>> 'set term wxt persist' is not persistent after 'quit'
from gnuplot
I thought it was logical to quit when the user asks for it
on interactive mode. But if it is not the intended
behaviour, I will change it.
>> please organize that it accepts this option from the
command line as well (as x11, pm and windows are doing)
Ok, I will look at it.
>> please get the 'spacebar' hotkey working
I have no motivation to do it for now. It it completely
platform-dependant, and even more than that. It has to be
implemented once for Windows, and multiple times for Unix,
as it depends wether gnuplot is lauched from rxvt,
gnome-terminal, konsole, or embedded in a text editor, etc.
Moreover, it heavily depends on the behaviour of the window
manager. For example, look at the raise/lower commands :
they work perfectly under Windows, but under kde you may
find that they don't always work as expected. On the other
hand, it would probably take you less than one minute to set
up a shortcut for such a behaviour with your window manager.
>> now the menu is completely missing -- was this intended?
The menu did contain a 'quit' entry which is already
provided by the window manager, by gnuplot via 'quit' and by
the shortcut 'q'. It alos contained an 'about' entry, which
has been tranformed to the '?' in the toolbar.
>> wgnuplot-wxt-20060207.zip cannot be unzipped; for plenty
of files, Info-ZIP's unzip is reporting `(null)' method not
supported
Ok, it's because I used 7-zip with a bzip2 method instead of
the traditionnal one I guess. I will correct it soon.
Logged In: YES
user_id=31505
>> please get the 'spacebar' hotkey working
> I have no motivation to do it for now. It it completely
platform-dependant
Yes, of course. But please implement it. I cannot live
without it. Having opened 4 gnuplot graphs (from terminals,
from octave, ...), the <space> is the only way to know where
they were opened from.
> kde you may find that they don't always work as expected
You must set "control center => windows behaviour =>
advanced => protection level against stealing (??? or
somehow like that) => None".
Should this info go into "help mouse"?
> On the other hand, it would probably take you less
> than one minute to set up a shortcut for such
> a behaviour with your window manager.
Can you demonstrate this please?
Logged In: YES
user_id=1333817
>> kde you may find that they don't always work as
>>expected
>You must set "control center => windows behaviour =>
>advanced => protection level against stealing (??? or
>somehow like that) => None".
>Should this info go into "help mouse"?
Indeed it's better with this setting. However, when I type
'raise 0' whith gnuplot launched in konsole, I have to hit
another key, ctrl for example, to make the plot window
actually appear. Do you see the same behaviour ?
It should go to "help mouse" I think.
>> On the other hand, it would probably take you less
>> than one minute to set up a shortcut for such
>> a behaviour with your window manager.
>Can you demonstrate this please?
I am a little optimistic when I say 'less than one minute',
but for example when gnuplot is launched in konsole, you can
write a shell script that does the following :
- ps aux | grep gnuplot
- extract the TTY where gnuplot runs
- extract the PID of the corresponding shell instance
- loop over konsole instances :
dcop konsole-*
- then loop over konsole sessions of each instance to find
the correct one :
dcop konsole-XXXX session-Y sessionPID
- activate (=raise it it konsole) the good session :
dcop konsole-XXXX konsole activateSession session-Y
- and finally raise konsole :
dcop konsole-XXXX konsole-mainwindow#1 raise
And once you have the shell script working, you can set a
shortcut to it with the kde control center :
control center -> accessibility -> input actions -> new
action -> command
I would have prefered to have this and the other raise/lower
functions implemented as shell scripts and then distributed
with gnuplot, but not implemented directly inside gnuplot
(apart from the windows implementation maybe, where we
already have the whole terminal-like gui).
Logged In: YES
user_id=31505
> Indeed it's better with this setting. However, when I type
> 'raise 0' whith gnuplot launched in konsole, I have to
> hit another key, ctrl for example, to make the plot window
> actually appear. Do you see the same behaviour ?
No, never.
> - ps aux | grep gnuplot
That's impossible of there are 2 or more gnuplot instances
running (e.g. gnuplot for experimental data, gnuplot for
fitting, and once again from octave).
> I would have prefered to have this and the other raise/lower
> functions implemented as shell scripts and then distributed
> with gnuplot, but not implemented directly inside gnuplot
> (apart from the windows implementation maybe, where we
> already have the whole terminal-like gui).
Yes, there is a unique and easy implementation for OS/2 and
Windows, while there is a mess under X11. But we have to
live with that -- gnuplot should provide similar
functionality under leading platforms. (On X11, it works (=I
have implemented it) under single-window xterm, KDE/konsole,
while nobody cares about multiple cards under gnome-terminal
-- I don't use/know its "dcop" -- any volunteer?) So, it
depends on the terminal gnuplot was run from, not from
window manager -- there are troubles only with
multiple-card terminals.
Logged In: YES
user_id=1333817
>> it's better with this setting. However, when I type
>> 'raise 0' whith gnuplot launched in konsole, I
>> have to hit another key, ctrl for example,
>> to make the plot window
>> actually appear.
>> Do you see the same behaviour ?
> No, never.
Just to be sure, are you talking about the x11 terminal or
the wxWidgets one ? Indeed, I don't experience it with the
x11 terminal.
>> - ps aux | grep gnuplot
>That's impossible of there are 2 or more gnuplot instances
>running (e.g. gnuplot for experimental data, gnuplot for
>fitting, and once again from octave).
You're right.
>there is a unique and easy implementation for OS/2 and
>Windows, while there is a mess under X11. But we have to
>live with that -- gnuplot should provide similar
>functionality under leading platforms.
>(On X11, it works (=I have implemented it)
> under single-window xterm, KDE/konsole,
> while nobody cares about multiple cards under
> gnome-terminal
> -- I don't use/know its "dcop" -- any
> volunteer?) So, it depends on the terminal
> gnuplot was run from, not from
> window manager -- there are troubles only with
> multiple-card terminals.
Ok. So if it's alreaded implemented for windows, os/2 and at
least partially for x11, I guess I can reuse these functions
(at least windows and x11, as I don't even know if my
terminal will work on os/2) and maybe make them live in a
separate file/header . Can I ?
Logged In: YES
user_id=31505
> Just to be sure, are you talking about the x11 terminal
about set term x11
> at least partially for x11
Actually, this is correct: it is fully implemented for x11
(considering windows), but some special consoles (konsole,
gnome-terminal) can have multiple text terminals in itself,
so gnuplot_x11 correctly focuses to them, but a special
trick is needed if you want to change e.g. cards in konsole.
Try it.
> I can reuse these functions
> and maybe make them live in a
> separate file/header. Can I?
Sure.
Logged In: YES
user_id=1333817
Here is a new patch which corrects & implements most of the
previous remarks :
General :
* display a default harcoded xpm icon and an error message
on stderr when the toolbar cannot find one of the PNG icons
* 'persist' from command-line (export argc and argv, may be
reused for other terminals, to clean up main() )
* 'persist' also in interactive mode
* implementation of <spacebar> for X11 and Windows, based on
gplt_x11.c and wgraph.c (please note that I was reluctant to
implement such a functionnality, because it makes me work
directly with Xlib and Windows functions, so it is out of
the spirit of the wxWidgets terminal which I wanted to be
cross-platform. Possible suggestion : instead of a key for
raising gnuplot windows, maybe a key for lowering all plot
windows would be satisfying - this solution can be
implemented with wxWidgets only )
* and several small fixes and cleanups
Unix :
* wxt_waitforinput() rewritten to use select() with a
timeout instead of launching a new thread, avoids segfaults
caused by LONGJMP
* avoids the GUI thread to receive SIGINTs (avoids LONGJMP
and the associated segfaults or freezes with C++)
* handle pipe-is-a-file and paused_for_mouse in
wxt_waitforinput()
* fix problem for finding PNG icons (export the installation
prefix)
The Windows snapshot is here :
http://tipote.free.fr/wgnuplot-wxt-20060228.zip
Logged In: YES
user_id=31505
Some new comments:
* Message "Can't load one of the PNG icons of the toolbar."
Write this message once only somehow like:
Can't load PNG icon(s) of the toolbar.
* "raise" command does not work properly (KDE): its effect
gets executed only after I move mouse cursor over the plot
window.
* I wish when "plot x", then the wx window does not get
focus, so that I can continue typing in gnuplot command
line. As x11 is doing.
* -persist does not work
gnuplot -persist
gnuplot> plot x
gnuplot> quit
persist handled
gnuplot> quit
Segmentation fault
*
> the spirit of the wxWidgets terminal which I wanted to be
> cross-platform. Possible suggestion : instead of a key for
> raising gnuplot windows, maybe a key for lowering all plot
> windows would be satisfying - this solution can be
> implemented with wxWidgets only )
gnuplot window can be below any other window of your desktop,
so you would need platform specific tricks anyway. The
current solution works best.
* in docs, use {} instead of []
set terminal wx... {<n>}
{title "<string>"}
{{no}enhanced}
* Options
[fname "<font>"]
[fsize <fontsize>]
I propose wx font selection is same as in some other
terminal(s).
(It's not same for all terminals, but don't develop a new
syntax again.)
Logged In: YES
user_id=1333817
> * Options
> [fname "<font>"]
> [fsize <fontsize>]
> I propose wx font selection is same as in
> some other terminal(s).
> (It's not same for all terminals,
> but don't develop a new
> syntax again.)
Actually it is the current syntax of the svg terminal. If I
change it, what syntax do you want ? gd ? x11 ? win ?
I like the syntax of the svg terminal because it makes a
clear distinction between font name and size.
(postscript syntax asks for a font file, it doesn't apply here)
Logged In: YES
user_id=235620
The term->set_font() routines have all been standardized to
accept the form "FontFace,FontSize" i.e. the face and
the size are comma-separated in a single string. I have
been gradually updating the various "set term <foo> font
<baz>" routines to accept the same form, but in all cases
have left the previous syntax active for backwards
compatibility.
This uniformity is needed for the enhanced text mode and for
"set termoptions font <foo>" to work. Both need to send
font specs to the current terminal independent of what that
terminal is.
> (postscript syntax asks for a font file,
> it doesn't apply here)
Not sure what you are saying here. Postscript asks for a
font face name, not a file name. You can request a font by
name even if you have no such font on your system. After
all, the printer you send the output to may support that
font even if you don't have it installed on your computer.
Logged In: YES
user_id=1333817
> The term->set_font() routines have all been standardized
> to accept the form "FontFace,FontSize"
> i.e. the face and the size are
> comma-separated in a single string.
Ok, I have not known that.
> Not sure what you are saying here.
> Postscript asks for a font face name, not a file name.
Right, I read "help post" too quickly.
Logged In: YES
user_id=1333817
Here is a new patch with the requested changes :
* {} instead of [] in 'help wxt'
* Error message for toolbar icons only written once.
* 'quit'- ctrl-c - 'quit' in persist mode will exit cleanly
instead of issuing a segfault
* "raise" command now works properly on KDE : its effect
gets executed immediately
* when "plot x", then the wxt window is raised but does not
get focus
* cleanup of DEFINEs logic and configure.in
* font is to be chosen with 'set term font "FontFace,FontSize"'
* cleanups, code factorization where it is
platform-dependant, etc.
Windows snapshot :
http://tipote.free.fr/wgnuplot-wxt-20060305.zip
Logged In: YES
user_id=235620
> with the requested changes :
> * when "plot x", then the wxt window is raised but
> does not get focus
Is this properly disabled by the "noraise" flag or X-resource?
Surely I'm not the only one who believes that programs have
no business changing the layout or focus of my desktop.
I don't want *any* program, ever, moving my windows around,
raising or lowering them, or changing the mouse focus.
Things should stay where I put them, unconditionally.
Also, I remember the answer to an earlier question, so I'll
ask again: Does the wxwidgets terminal honor all the normal
X resources? For example, if I have:
gnuplot*raise: no
gnuplot*ctrlq: true
is that sufficient to control the raise/noraise behaviour
and change the "quit" hotkey from "q" to "ctrl-q"?
Logged In: YES
user_id=1333817
>> when "plot x", then the wxt window is raised but
>> does not get focus
> Is this properly disabled by the "noraise" flag or
> X-resource?
I have not implemented the 'noraise' option, but I surely can.
> Surely I'm not the only one who
> believes that programs have
> no business changing the layout
> or focus of my desktop.
> I don't want *any* program, ever,
> moving my windows around,
> raising or lowering them,
> or changing the mouse focus.
> Things should stay where I put them,
> unconditionally.
I have the same point of view. Until now, I have tried to
mimic the behaviour of the x11 terminal. I hope that this
terminal behaves like you want.
> Also, I remember the answer to an earlier question,
> so I'll ask again:
> Does the wxwidgets terminal honor all the normal
> X resources?
No, it doesn't. Thanks to the recent discussion about X
ressources on the mailing list, I understand better what it
is about.
The idea to put options for the terminal in a separate file
is interesting, but if I implement it, I don't want to use
the X ressources as they are specific to X.
What about a XML file (usually called an XML ressource file)
where you could put such options ? It would be
cross-platform, and wxWidgets provides the facility to
handle these XML files.
Logged In: YES
user_id=235620
I've just made a quick run test of the current patchset.
1) Please fix -noraise, and also provide some way of making
this the global default. I cannot/will not use a program
that keeps popping windows to the top of a stack.
2) I still don't get any button icons on the toolbar, just
your exclamation-mark-error defaults. After running "make
install", the icons are in directory /usr/local/gnuplot/ and
they are readable. But the program doesn't read them. So
far as I can tell, it doesn't even *try* to read them. For
example, doing 'strace ./gnuplot |& grep grid.png' shows no
open() or other system call is ever made for this file.
Putting a trap in LoadPngIcon so I can see what's gone wrong
produces this state from inside gdb:
(gdb) print icon_path
$1 = {<wxStringBase> = {static npos = 4294967295,
m_pchData = 0x824bbc4
"NONE/share/gnuplot/clipboard.png"}, <No data fields>}
So something has gone wrong in the path-construction
process. By the way, that should probably be set as
"$pkgdatadir/$VERSION_MAJOR"
in configure.in, and end up as
/usr/local/share/gnuplot/4.1/...
on a default linux install
3) I notice that 3D rotation is much slower than in the x11
terminal. Is this an inevitable cost to using wxWidgets, or
can we hope for more optimized code?
Logged In: YES
user_id=27517
I currently don't have wx installed anywhere, so I only
tested the win32 binary package.
One thing jumped at me almost immediately: the anti-aliased
line drawing seems not work out all that well. Two main
issues there are:
1) the usual "plot x" line at default settings is terribly
wobbly. Yes, the windows terminal does that, too. But with
anti-aliasing it looks even worse, somehow.
2) the diagonal line of 'plot x' looks considerably fatter
than the key sample.
Both effects appear even more striking in
set polar
set size ratio -1
plot 2.23
So: may I be so bold as to ask for a terminal switch that
turns anti-aliasing off? Maybe it's only my LCD screen
that's acting up here, but frankly, I don't think
anti-aliasing is doing gnuplot all that much good. At least
here on my screen it seems to make typical aliasing
artefacts (like the wobble on both the diagonal line and the
circle) stand out even more, instead of working against them.
Logged In: YES
user_id=1333817
New version today, with a lot of underlying work :
Bug fixing :
* make font handling work correctly (_set_font was not correct)
* correct PREFIX handling when installing to the default
/usr/local
Changes :
* corrected the way of handling endianess of cairo buffers
* simplify the scaling functions (small speed gain expected)
* change the way polygons are drawn, make it hugely faster
* rework of wxWidgets initialisation and clean-up (still
need some more work here, but my understanding is in progress)
* more code factorisation
New features :
* implement option raise/noraise
* implement persistent options handled by wxWidgets, through
a simple configuration dialog.
The dialog is accessible via a 'tool' icon in the toolbar.
These options are stored in a file under Unix, and in the
registry under Windows. They are overriden by command-line
options (for 'persist') and 'set term wxt' (for 'raise' &
'persist').
* draw with oversampling : gnuplot coordinates are 20 times
bigger than the actual screen coordinates,
so that we really profit from cairo double API and its
antialiasing
Direct advantage : rendering is much less "wobbly", and this
is really visible on most plots
Drawback : blur the horizontal and vertical lines, so a
simple "hinting" algorithm is also implemented to avoid
this. It detects these lines and shifts them properly
(approach already used for font hinting algorithm in font
layout libraries).
In the configuration dialog, you can choose the way you want
cairo to render the plot : without antialiasing, with
aliasing but without oversampling, with antialiasing and
oversampling. Fot the last option, you can choose to
activate the hinting or not. Hit 'replot' to see the effects
of your changes.
On my TODO list :
* finish the work on wxWidgets initialization and cleanup on
exit
* modify the behaviour on window resizing according to the
discussion on the mailing-list gnuplot-beta (in the current
patch, everything is rescaled when the window is resized -
font size and linewidths included)
Usual Windows snapshot :
http://tipote.free.fr/wgnuplot-wxt-20060327.zip
Enjoy !
Logged In: YES
user_id=923756
First of all: Great work! There is no doubt on that.
The only thing I'm missing personally is the command history
that the "default" Gnuplot saves accross Gnuplot sessions.
If you didn't disable this on purpose you might want to
enable it in a future release? Again: Thank you very much
for all the work!
Logged In: YES
user_id=1333817
>The only thing I'm missing personally is the
>command history that the "default"
> Gnuplot saves accross Gnuplot sessions.
>
>If you didn't disable this on purpose you might
>want to enable it in a future release?
> Again: Thank you very much for all the work!
I suppose you are talking about the Windows snapshot, right
? I will take care of it for the next snapshot.
Logged In: YES
user_id=1333817
Again, a new patch :
* I had to gzip the patch, as it is over 250ko, and
Sourceforge refuses it.
* wxWidgets initialisation and clean-up reviewed. In
particular, properly use the already existing gui message
loop under Windows
* make the configuration dialog "modeless", so that you
don't have to close it to replot and see what your settings
change
* also "hint" the points to avoid blur, i.e. snaps them on
the pixel grid (I think I'll have to add a configuration
option for that : sometimes it's better to have them hinted,
sometimes not)
* wxWidgets initialisation and clean-up reviewed. In
particular, properly use the already existing gui message loop
* make the configuration dialog "modeless", so that you
don't have to close it to replot and see your changes
* also hint the points (I think I'll have to add a
configuration option for that : sometimes it's better to
have them hinted, sometimes not)
* keep the 1:1 aspect ratio of the plot when the window is
resized : the plot will be aligned in the top left hand
corner (font size and linewidths are scaled)
* two bugs fixed concerning polygons (whole contiguous set
not drawn, y-axis reflexion sometimes wrong)
Usual windows snapshot (which remembers the history this time) :
http://tipote.free.fr/wgnuplot-wxt-20060330.zip
Logged In: YES
user_id=923756
> I suppose you are talking about the Windows snapshot, right?
> I will take care of it for the next snapshot.
I'm sorry, I read your answer just today - so yes, I was
talking about the Windows snapshot. Anyway - I saw that
you've come up very (!) quickly with a new release that has
the history implemented and working. Thanks a lot!
16th version, SIGINT-proof, fixes & cleanups
Logged In: YES
user_id=1333817
Here is a new patch, with the following changes :
* SIGINT-proof (thanks to Ethan for putting the emphasis on
this)
* fix bug with zoombox reset
* fix bug in color handling with polygon (Ethan, it's the
bug raised by rectangle.dem')
* fix a compiler warning (%lf/int in fprintf)
* cairo code factorization
* comments & style cleanups
This one is a candidate for cvs.
Screenshot :
http://tipote.free.fr/wxt18.png
Usual snapshot for Windows :
http://tipote.free.fr/wgnuplot-wxt-20060405.zip
Logged In: NO
Some thoughs:
- for the patch: there are some changes (e.g. in
term_api.h) independent of the wxt patch, so they should
be applied as an independent
patch before wxt
- please add support for:
set term wxt title 'hello gnuplot'
set term wxt close
- trying gnuplot.exe (the win32 version) under Linux:
While "normal" gnuplot.exe with the "windows" terminal
works in wine and
Cross-Over Office wine, the wxterminal not:
-- all font are very big, e.g. 'test' fails (wine)
-- pm3d and image drawings are not shown (cross-over
office wine)
Of course we can blame wine, but maybe you can figure
something from the messages...
Logged In: YES
user_id=1333817
I have attached a serie of four patches which are somewhat
independant of the wxt patch, as requested. These affects
the following :
enhanced_extern.diff : make enhanced text variables and
routines extern, and declare them in term_api.h, so that
they can be used outside from term.c
pkg_major.diff : replace PKG_MAJOR by VERSION_MAJOR, because
pkg-config (used to retrieve cflags for cairo/pango) forbids
any words containing "PKG_" in autoconf/automake files
windows_waitforinput.diff : make the getc() wrapper call
term->waitforinput on Windows as on Unix
yes_no_unset.diff : move an already existing enumeration to
term_api.h, so that wxt.trm can use it to process options
(which fixes a FIXME by the way)