gnuplot-beta — Developers and beta testers of new gnuplot code

Re: Simplified processing of image and rgbimage plots

[Daniel J S. <dan...@ie...>]

Ethan A Merritt wrote:

>>But does the PDF library support translation matrices?
> 
> 
> Yes. Exactly the same as PostScript:
> 
> void PDF_concat(PDF *p, double a, double b, double c, double d, double e, double f)
>   Concatenate a matrix to the current transformation matrix.
>   a, b, c, d, e, f Elements of a transformation matrix. 
>   The six values make up a matrix in the same way as in PostScript and PDF 
>   (see references). In order to avoid degenerate transformations, 
>   a*d must not be equal to b*c.

Ah!  I didn't see that:

http://us2.php.net/manual/en/function.pdf-concat.php

I was looking for something that might be part of an image command.

Dan

Re: Simplified processing of image and rgbimage plots

[Ethan A M. <merritt@u.washington.edu>]

On Sunday 19 November 2006 09:11 pm, Daniel J Sebald wrote:
> Ethan A Merritt wrote:
> 
> > We could do better.
> > 
> > PostScript supports the specification of a general transformation
> > matrix.  Rather than using individual filled_polygons
> > to draw a rgbimage in 3D, we could simply include a projection of
> > the 3x3 rotation matrix.
> 
> > I believe that PDF and SVG also benefit from this approach, but
> > I have not investigated fully.
> 
> But does the PDF library support translation matrices?

Yes. Exactly the same as PostScript:

void PDF_concat(PDF *p, double a, double b, double c, double d, double e, double f)
  Concatenate a matrix to the current transformation matrix.
  a, b, c, d, e, f Elements of a transformation matrix. 
  The six values make up a matrix in the same way as in PostScript and PDF 
  (see references). In order to avoid degenerate transformations, 
  a*d must not be equal to b*c.



-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: Simplified processing of image and rgbimage plots

[Daniel J S. <dan...@ie...>]

Ethan A Merritt wrote:

> We could do better.
> 
> PostScript supports the specification of a general transformation
> matrix.  Rather than using individual filled_polygons
> to draw a rgbimage in 3D, we could simply include a projection of
> the 3x3 rotation matrix.  This would drastically reduce the 
> PostScript file size for such plots.

And rendering speed.  gv is very slow with the filled polygons.  (The aliasing effect would probably go away too with the proper translation matrix.)

   We already calculate this
> same matrix in the core code in order to place the polygons; in
> the case of PostScript it would be sufficient to provide the matrix
> to the driver along with the original 2D array of rgb pixels.
> 
> Anyone want to have a go a coding this?

Not too difficult.  First step would be to add the necessary translation matrix info to the terminal image routine.

> I believe that PDF and SVG also benefit from this approach, but
> I have not investigated fully.

But does the PDF library support translation matrices?

Dan

Re: Simplified processing of image and rgbimage plots

[Ethan A M. <merritt@u.washington.edu>]

On Sunday 19 November 2006 05:47 am, Petr Mikulik wrote:
> 
> However, your generic fall-back is OK.

I want to clarify something.  This is not just a fall-back.
It is currently the only way to place rgb data in 3D.  

So not only does it allow additional drivers (svg, fig, emf) to 
handle rgbimage in 2D, it also extends the capability of ALL drivers
to work in 3D.

However, as you noted it is rather expensive to describe an image
this way, which causes slow data transfer in x11 and large file
size in PostScript and PDF.

We could do better.

PostScript supports the specification of a general transformation
matrix.  Rather than using individual filled_polygons
to draw a rgbimage in 3D, we could simply include a projection of
the 3x3 rotation matrix.  This would drastically reduce the 
PostScript file size for such plots.   We already calculate this
same matrix in the core code in order to place the polygons; in
the case of PostScript it would be sufficient to provide the matrix
to the driver along with the original 2D array of rgb pixels.

Anyone want to have a go a coding this?

I believe that PDF and SVG also benefit from this approach, but
I have not investigated fully.


Hand-worke example:

Here is the start of the PostScript image code produced by the
first plot in "image.dem".  I have added one line that inserts
a transformation matrix.  Try it yourself.

 %%%%BeginImage
InterpretLevel1 { ...
} {
  gsave
  1149 3738 translate
  5490 -3219 scale
  [1 -.05 0.1 0.7 0.05 -0.15] concat %%% general transformation matrix %%%
  128 128 8
  [ 128 0 0 128 0 0 ]
  currentfile /ASCII85Decode filter
  false 3
  colorimage
} ifelse





-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: compiling gnuplot on Windows & mac/linux

[<HBB...@t-...>]

Petr Mikulik wrote:

> By what? Isn't there some way to know whether that dir should be called 
> "Program Files", "Programy", "Programme", etc?

On the more modern systems (Win2K and up, I think), there is an 
environment variable %ProgramFiles%.  The problem with that would be 
that it reads something like "c:\Program Files" (backslash, drive 
letter), whereas MSYS (nowadays to be assumed as the underlying Unix 
substitution layer for MinGW) would want "/c/Program Files", and Cygwin 
"/cygdrive/c/Program Files".  And it's not really clear that getting 
'make install' fully right is even worth trying on Windows.

> Do you really need it? I "crosscompile" gnuplot for Windows on Linux by 
> means of MingW: I run the wine console (wcmd), and then do what is written 
> for mingw: go to src/, type "make -f ../config/makefile.mgw", and it is 
> done.

That's not really cross-compiling.  Cross-compiling would mean you build 
a version of GCC running directly on Linux that builds Win32 executables 
based on the MinGW libraries and headers.

Re: compiling gnuplot on Windows & mac/linux

[Ethan A M. <merritt@u.washington.edu>]

On Sunday 19 November 2006 05:34 am, Petr Mikulik wrote:
> > makefile.mgw
> > #DESTDIR = /c/Progra~1/Gnuplot4.1
> >
> > any many other places still contain old strings. Can anyone grep for
> > them and replace them?
> 
> By what? 

I thought the point was to replace '4.1' by '4.2'


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

[Fwd: Re: Reversed X axis breaks "with image" for some drivers]

[Daniel J S. <dan...@ie...>]

Petr Mikulik wrote:
>     Hello Daniel,
> 
> could you please find out a fix for this bug? A solution that does not 
> need to use rectangles. I think that a local "flip" option reversal 
> before/during
> term->image would be enough.

Actually, I have a patch for this Petr.  I just haven't had time to thoroughly test it.  Maybe later this weekend I will find some time.

Dan

Re: Simplified processing of image and rgbimage plots

[Ethan A M. <merritt@u.washington.edu>]

On Sunday 19 November 2006 05:47 am, Petr Mikulik wrote:
> >> This extends the capabilities of svg, xfig, and maybe other terminals.
> >>
> >> The specialized code for image handling could be removed from gd.trm, for
> >> instance. Also x11. Is this worth doing?
> 
> Do you really mean to remove the term->image() routine??? Definitely no, the 
> processing is several orders of magnitude slower ... try to draw a 1024x1024 
> image with pm3d and with image. Terminal-specific term->image() is the 
> proper way.

It may seem counter-intuitive, but in fact the RGB polygon processing is
just as fast as the term->image() processing, at least for gd.trm.
Here is a timed benchmark run using a 800x600 image for the test script

  set term png truecolor size 1024,768
  set output 'junk.png'
  plot 'bench.avs' binary filetype=avs with rgbimage
  replot
  [... 10 plots total]
  replot

time ./gnuplot bench.gnu  (average of 5 runs)
  16.785u 0.509s 0:17.31 99.9%    0+0k 0+0io 0pf+0w

same thing except "with rgbimage generic"
  16.672u 0.572s 0:17.18 99.4%    0+0k 0+0io 0pf+0w



The generic code is significantly slower (4-5X) for x11, but I think that
is a matter of the transfer time through the pipe for a description that is
less compact (30MB vs 2.9 MB).  This difference could be reduced by switching
to a binary protocol for transmitting RGB color + polygon down the pipe.




x11 with rgbimage
  6.331u 0.675s 0:07.05 99.2%     0+0k 0+0io 0pf+0w
x11 with rgbimage generic
  28.418u 17.907s 6:37.59 11.6%   0+0k 0+0io 0pf+0w


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: Simplified processing of image and rgbimage plots

[Petr M. <mi...@ph...>]

>> This extends the capabilities of svg, xfig, and maybe other terminals.
>>
>> The specialized code for image handling could be removed from gd.trm, for
>> instance. Also x11. Is this worth doing?

Do you really mean to remove the term->image() routine??? Definitely no, the 
processing is several orders of magnitude slower ... try to draw a 1024x1024 
image with pm3d and with image. Terminal-specific term->image() is the 
proper way.

However, your generic fall-back is OK.

---
PM

Re: Re: compiling gnuplot on Windows & mac/linux

[Petr M. <mi...@ph...>]

>> I'd rather you remove the stupid compiler that emits them.
> makefile.mgw
> #DESTDIR = /c/Progra~1/Gnuplot4.1
>
> any many other places still contain old strings. Can anyone grep for
> them and replace them?

By what? Isn't there some way to know whether that dir should be called 
"Program Files", "Programy", "Programme", etc?

> Now a question: is anyone ready to help me to write a clean makefile
> for MinGW for cross-compiling (which would be suitable to add to CVS)
> or does that exist already?

Do you really need it? I "crosscompile" gnuplot for Windows on Linux by 
means of MingW: I run the wine console (wcmd), and then do what is written 
for mingw: go to src/, type "make -f ../config/makefile.mgw", and it is 
done.

Isn't there a Wine for MacOSX on Intel?

> It would be extremely useful if developers wouldn't only put source
> files on the web, but also binaries, at least for windows.

I did so, see
 	http://gnuplot.sourceforge.net/development/binaries/

>> But it would help a lot if those warnings would be removed with the
>> three switches mentioned above,

I think that cleaned makefile could be put into cvs, if you prepare it. 
Check also config.xxx.

>> Microsoft has made it clear that they don't care about providing a
>> working compiler, why should we care about supporting their broken product?
>
> OK, I accept that.

There could be a message in that makefile that the 
compilation/binary/pgnuplot/... may not work for which version of the 
compiler.

---
PM

Re: Building wxt terminal for OS X

[Joe K. <jko...@co...>]

on 11/18/06 5:26 PM, Ethan A Merritt at merritt@u.washington.edu wrote:

> On Friday 17 November 2006 01:33 pm, Joe Koski wrote:
>> I think Per's assessment is correct. The problem is not with wxt, but with
>> the necessity for "bundling" wxWidget applications for native use on the
>> Mac. 
> 
> Bizarre O/S design.
> 
>> That requires either extensive modifications to the gnuplot make files,
>> or a special separate make file approach for the Mac.
> 
> I don't think that's true. From what I have found via Googling, nothing
> special should be required in building the application (gnuplot).
> Creating the bundle is a separate step, and could have its own Makefile
> or installation script.
> 
> I am hampered by never having had to install anything like this on a Mac,
> but it sounds to me from all your descriptions that the problem is that if
> you bundle gnuplot, its controlling terminal is not the one you launched
> it from.  Rather, it must have a controlling terminal app as part of the
> bundle.  I guess this is the iTerm approach that someone mentioned.
> Furthermore, I suspect that the info.Plist file must contain one or more
> lines that establishes that the gnuplot plot window gets the focus in
> parallel to, or instead of, the controlling terminal app.  How one does
> any of that is beyond me.
> 
> I found only one similar complaint about lack of focus via Googling.
> In that case the problem was that the application name in info.Plist
> did not precisely match the directory tree name in which the app had
> been placed. Just a thought.
> 
> Anyhow, it sounds to me like this needn't hold up a 4.2 release, because
> it is a post-build installation problem, and probably doesn't require
> changes to the gnuplot code per se.  If it turns out that minor changes
> are required in the wxt code, that can be a follow-on patch of relevance
> only to Mac users.  Maybe fink or Darwin will bundle it with gnuplot
> (in the normal sense of the word, not this strange Mac-ish meaning of
> "bundle") and provide an easy installation source for general users.

Ethan,

You are correct that this problem should not stop a gnuplot release. This is
a Mac specific issue, and if the Apple folks want to ride with their "we're
the best horse" attitude, that's OK. Without cairo/pango installed,
gnuplot-4.2.rc1 builds without problems, and works with both X11 and
AquaTerm.

Neither MacPorts (formerly DarwinPorts) nor Fink do bundling. They basically
modify open source make files and install into their own version of
/usr/local/ that they call /sw or /opt for the "unstable" branch. For older
"stable" stuff, they basically "make install" binary builds into /sw or
/opt. To the new Mac user, this looks like magic, and they don't need to
learn UNIX or navigate in /usr.

As you suggested, I tried renaming the org.gnuplot.app to gnuplot.app in
Info.plist. That did not solve the problem. We need a Mac "developer" to
examine that file. Incidentally, there are literally thousands of .plist
files on any Mac. There are some other things I can try like dragging the
application into /Applications and changing the name to
/Applications/gnuplot.app, but I'm just trying to out guess Apple about
that.

As to the terminal, keep in mind that the standard way to start any Mac
application is via a double click of the icon. No terminal is assumed. For
some other applications that I run in X11 (GMV and Geomview), I have simple
AppleScript files that first start X11, and then invoke the application. We
probably need a Mac native version of that with terminal.app or iTerm.app.
On my old pre-OSX Mac, we had the "Macintosh Programmers Workshop" which was
basically a terminal window into the OS. That was the only way to do command
line stuff. I think that this problem is a legacy of that. No Mac user
should ever be bothered with the need to use of a command line, or something
like that.

I'll keep trying, and if anything develops, I'll let folks know.

Joe

Re: Building wxt terminal for OS X

[Ethan A M. <merritt@u.washington.edu>]

On Friday 17 November 2006 01:33 pm, Joe Koski wrote:
> I think Per's assessment is correct. The problem is not with wxt, but with
> the necessity for "bundling" wxWidget applications for native use on the
> Mac. 

Bizarre O/S design.

> That requires either extensive modifications to the gnuplot make files, 
> or a special separate make file approach for the Mac.

I don't think that's true. From what I have found via Googling, nothing
special should be required in building the application (gnuplot).
Creating the bundle is a separate step, and could have its own Makefile
or installation script.

I am hampered by never having had to install anything like this on a Mac,
but it sounds to me from all your descriptions that the problem is that if
you bundle gnuplot, its controlling terminal is not the one you launched
it from.  Rather, it must have a controlling terminal app as part of the
bundle.  I guess this is the iTerm approach that someone mentioned.
Furthermore, I suspect that the info.Plist file must contain one or more
lines that establishes that the gnuplot plot window gets the focus in
parallel to, or instead of, the controlling terminal app.  How one does
any of that is beyond me.

I found only one similar complaint about lack of focus via Googling.
In that case the problem was that the application name in info.Plist 
did not precisely match the directory tree name in which the app had 
been placed. Just a thought.

Anyhow, it sounds to me like this needn't hold up a 4.2 release, because
it is a post-build installation problem, and probably doesn't require 
changes to the gnuplot code per se.  If it turns out that minor changes
are required in the wxt code, that can be a follow-on patch of relevance
only to Mac users.  Maybe fink or Darwin will bundle it with gnuplot
(in the normal sense of the word, not this strange Mac-ish meaning of
"bundle") and provide an easy installation source for general users.

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: Building wxt terminal for OS X

[<tim...@en...>]

Joe Koski wrote:
> on 11/18/06 10:09 AM, Mojca Miklavec at moj...@gm...
> wrote:
>
>  =20
>> On 11/18/06, Timoth=E9e Lecomte wrote:
>>    =20
>>> Mojca Miklavec wrote:
>>>      =20
>>>> However, there remain some problems. It seems to run OK, but when I
>>>> click on the window with plot an icon appears (as if there was some
>>>> action in the background which has to be finished first - an
>>>> equivalent to "sand-watch" in windows or linux), so there are proble=
ms
>>>> with "interactivity" of that window. Plotting works OK.
>>>>
>>>>        =20
>>> I am sorry to ask but, as you are not giving any precision about it :
>>> Have you bundled it ?
>>>      =20
>> Sorry, I should have replied to that as well. I "bundled" it in a way
>> that it looks like a nice application on desktop with a nice icon, and
>> running ./gnuplot.app/[whatever is here]/gnuplot from terminal works
>> OK, but when I click on it or call "open gnuplot.app" nothing happens
>> (I would expect that a terminal window would open automatically just
>> as it does under windows).
>>
>> Apart from that: someone would have to build it in a way that would
>> work on both types of processors and not in such a way that one would
>> need to have fink installed in order to have a working application
>> etc.
>>
>>    =20
>>> If no, then you need to do it.
>>> If yes, then it would mean bundling is not enough and we need to
>>> investigate further.
>>>      =20
>> I doubt that proper bundling would resolve that problem.
>>
>> (I'm probably way too green to be of any help anyway. I just came from
>> "Windows word".)
>>
>> Mojca
>>    =20
>
> Mojca,
>
> I had the same concern about the lack of a terminal window for gnuplot.=
 I
> haven't bundled mine yet, but when I do, I'll try to build an AppleScri=
pt
> that starts something like iTerm (http://iterm.sourceforge.net/), and t=
hen
> starts gnuplot within the iTerm window. Something like that is probably
> necessary on a Mac. For other applications like maxima and octave, the
> ./gnuplot approach is probably OK.
>
> Joe
>
>  =20
Again, I'm not a Mac expert since I don't have any, but the way I=20
understand things, you need to start gnuplot from a terminal, iTerm or=20
whatever terminal it is. That's independent from the backend that=20
gnuplot uses to plot, which can wxWidgets, aquaterm, or whatever=20
graphics system (correct me if I'm wrong).

Isn't there a default terminal with MacOS ? How do you start octave or=20
maxima on MacOS for example ?

The wxWidgets guys told me repeateadly that bundling is absolutely=20
needed when you build a wxMac application on MacOS, otherwise you=20
precisely don't get the focus. There must be some MacOS-magic that=20
recognises the directory structure and the Info.plist file and handles=20
that as a GUI application.

Best regards,

Timoth=E9e

Re: Building wxt terminal for OS X

[Joe K. <jko...@co...>]

on 11/17/06 5:07 PM, Timoth=E9e Lecomte at tim...@en... wrote:

> Timoth=E9e Lecomte wrote:
>> Ethan Merritt wrote:
>>  =20
>>> On Friday 17 November 2006 01:33 pm, Joe Koski wrote:
>>>  =20
>>>    =20
>>>> on 11/17/06 1:48 PM, Per Persson at per...@ma... wrote:
>>>>    =20
>>>>      =20
>>>>> I still maintain my opinions that
>>>>> 1) building an X11 based wxt  terminal should be straightforward
>>>>> 2) a "native" wxt terminal is going to take a lot of work.
>>>>>      =20
>>>>>        =20
>>>> I think Per's assessment is correct. The problem is not with wxt, but
>>>> with the necessity for "bundling" wxWidget applications for native
>>>> use on the Mac.
>>>>    =20
>>>>      =20
>>> You call it a necessity, where Per implies that it is simply a
>>> matter of choice between X11 and "native".  Which is it?
>>>  =20
>>>    =20
>> A native one is for sure better since X11 is not installed by default on
>> MacOS. The *only* problem we seem to get is this "no-input" issue, which
>> is supposed to be related to bundling, as Joe mentioned.
>>  =20
>=20
> I went back to #wxwidgets on IRC, and got confirmed again that bundling
> should be enough. Let's try to get it right this time.
>=20
> To sum up:
> *get 4.2rc1 from gnuplot.sf.net
> *apply wxmac.diff to src/wxterminal
> *run ./prepare, then ./configure with your favorite options, 'make',
> 'make install'
> You get a working gnuplot with the wxt terminal (assuming you have
> cairo, pango and wxMac installed), but the plot windows don't get the foc=
us
>=20
> Then the bundling stuff:
> *download the attached Icon.plist and wxmac.icns files
> *run the following commands to create the bundle tree:
>     mkdir -p ./gnuplot.app/Contents/MacOS/
>     mkdir -p ./gnuplot.app/Contents/Resources/
>     mkdir -p ./gnuplot.app/Contents/Frameworks/
>     cp ../src/gnuplot ./gnuplot.app/Contents/MacOS/gnuplot
>     echo -n 'APPL????' >  ./gnuplot.app/Contents/PkgInfo
> * retrieve the attached Icon.plist and wxmac.icns files, put them in the
> current directory, and put them at their respective locations in the
> bundle with the following commands:
>     cp ./Info.plist ./gnuplot.app/Contents/
>     cp ./wxmac.icns ./gnuplot.app/Contents/Resources/
>=20
> Then, you're supposed to be all set. To launch gnuplot, do:
>     open gnuplot.app
> or
>     ./gnuplot.app/Contents/MacOS/gnuplot
>=20
> ... and it should be fine now, according to what I've been told on IRC.
>=20
> Joe, could you try again with these instructions ? Thank you very much.
>=20
> Best regards,
>=20
> Timoth=E9e Lecomte

Timoth=E9e,

We're close to a solution, but no cigar yet. I followed your bundle
instructions, and I think I have the correct bundle structure created and
filled. I was a bit confused about which directory I should use to enter th=
e
command

  cp ../src/gnuplot ./gnuplot.app/Contents/MacOS/gnuplot

The ../src indicates that I am in a subdirectory within the 4.2.rc1 build
directory where the directory ./gnuplot.app exists. So I created a director=
y
called Mac_app in the 4.2.rc1 build directory. Correct? At least all your
bundling commands then worked without complaint.

When I try ./gnuplot.app/Contents/MacOS/gnuplot within Mac_app, gnuplot doe=
s
start, and I can plot, but I have the same lack of focus as before.

One more problem. A while back you sent me a second patch to try:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
diff -Naur old/wxt_gui.cpp new/wxt_gui.cpp
--- old/wxt_gui.cpp    2006-10-20 23:36:56.000000000 +0200
+++ new/wxt_gui.cpp    2006-10-20 23:39:36.000000000 +0200
@@ -1330,6 +1330,14 @@
         wxApp::m_nCmdShow =3D SW_SHOW;
 #endif
=20
+#ifdef __WXMAC__
+        /* allow to get focus even if the app is not bundled */
+        ProcessSerialNumber psn;
+        GetCurrentProcess( &psn );
+        CPSEnableForegroundOperation( &psn );
+        SetFrontProcess( &psn );
+#endif
+
         if (!wxInitialize()) {
             fprintf(stderr,"Failed to initialize wxWidgets.\n");
             wxt_abort_init =3D true;
diff -Naur old/wxt_gui.h new/wxt_gui.h
--- old/wxt_gui.h    2006-10-20 23:36:58.000000000 +0200
+++ new/wxt_gui.h    2006-10-20 23:39:32.000000000 +0200
@@ -159,6 +159,12 @@
 #  include "win/winmain.h"
 # endif
=20
+#ifdef __WXMAC__
+/* focus hack */
+# include <Carbon/Carbon.h>
+void CPSEnableForegroundOperation(ProcessSerialNumber* psn);
+#endif
+
 /* for cairo_t */
 # include <cairo.h>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Do I need to rebuild my gnuplot without the second "focus hack" patch? Is
that my problem?

Joe

Re: Building wxt terminal for OS X

[Joe K. <jko...@co...>]

on 11/18/06 10:09 AM, Mojca Miklavec at moj...@gm...
wrote:

> On 11/18/06, Timoth=E9e Lecomte wrote:
>> Mojca Miklavec wrote:
>>>=20
>>> However, there remain some problems. It seems to run OK, but when I
>>> click on the window with plot an icon appears (as if there was some
>>> action in the background which has to be finished first - an
>>> equivalent to "sand-watch" in windows or linux), so there are problems
>>> with "interactivity" of that window. Plotting works OK.
>>>=20
>> I am sorry to ask but, as you are not giving any precision about it :
>> Have you bundled it ?
>=20
> Sorry, I should have replied to that as well. I "bundled" it in a way
> that it looks like a nice application on desktop with a nice icon, and
> running ./gnuplot.app/[whatever is here]/gnuplot from terminal works
> OK, but when I click on it or call "open gnuplot.app" nothing happens
> (I would expect that a terminal window would open automatically just
> as it does under windows).
>=20
> Apart from that: someone would have to build it in a way that would
> work on both types of processors and not in such a way that one would
> need to have fink installed in order to have a working application
> etc.
>=20
>> If no, then you need to do it.
>> If yes, then it would mean bundling is not enough and we need to
>> investigate further.
>=20
> I doubt that proper bundling would resolve that problem.
>=20
> (I'm probably way too green to be of any help anyway. I just came from
> "Windows word".)
>=20
> Mojca

Mojca,

I had the same concern about the lack of a terminal window for gnuplot. I
haven't bundled mine yet, but when I do, I'll try to build an AppleScript
that starts something like iTerm (http://iterm.sourceforge.net/), and then
starts gnuplot within the iTerm window. Something like that is probably
necessary on a Mac. For other applications like maxima and octave, the
./gnuplot approach is probably OK.

Joe

Re: Re: Building wxt terminal for OS X

[Mojca M. <moj...@gm...>]

On 11/18/06, Timoth=E9e Lecomte wrote:
> Mojca Miklavec wrote:
> >
> > However, there remain some problems. It seems to run OK, but when I
> > click on the window with plot an icon appears (as if there was some
> > action in the background which has to be finished first - an
> > equivalent to "sand-watch" in windows or linux), so there are problems
> > with "interactivity" of that window. Plotting works OK.
> >
> I am sorry to ask but, as you are not giving any precision about it :
> Have you bundled it ?

Sorry, I should have replied to that as well. I "bundled" it in a way
that it looks like a nice application on desktop with a nice icon, and
running ./gnuplot.app/[whatever is here]/gnuplot from terminal works
OK, but when I click on it or call "open gnuplot.app" nothing happens
(I would expect that a terminal window would open automatically just
as it does under windows).

Apart from that: someone would have to build it in a way that would
work on both types of processors and not in such a way that one would
need to have fink installed in order to have a working application
etc.

> If no, then you need to do it.
> If yes, then it would mean bundling is not enough and we need to
> investigate further.

I doubt that proper bundling would resolve that problem.

(I'm probably way too green to be of any help anyway. I just came from
"Windows word".)

Mojca

Re: Building wxt terminal for OS X

[<tim...@en...>]

Mojca Miklavec wrote:
>
> After manually applying Timoth=E9e's patch I got it working with
> (native) wxMAC (I'm using fink for just about everything except
> pangocairo: I had to install pango manually to get pangocairo, all the
> other necessary libraries came with fink already).
>  =20
That's a good point that I also got from IRC: "fink" on MacOS gives you=20
binary packages for everything needed for the wxt terminal, apart from a=20
recent pango.

> However, there remain some problems. It seems to run OK, but when I
> click on the window with plot an icon appears (as if there was some
> action in the background which has to be finished first - an
> equivalent to "sand-watch" in windows or linux), so there are problems
> with "interactivity" of that window. Plotting works OK.
>  =20
I am sorry to ask but, as you are not giving any precision about it :=20
Have you bundled it ?

If no, then you need to do it.
If yes, then it would mean bundling is not enough and we need to=20
investigate further.

Best regards,

Timoth=E9e

Re: Re: Building wxt terminal for OS X

[Mojca M. <moj...@gm...>]

On 11/18/06, Joe Koski <jko...@co...> wrote:
> on 11/17/06 2:57 PM, Ethan Merritt at merritt@u.washington.edu wrote:
>
> > You call it a necessity, where Per implies that it is simply a
> > matter of choice between X11 and "native".  Which is it?
>
> Ethan,
>
> We already have X11 available on Macs, so building wxt with X11 as a basi=
s
> is a workaround solution. The problem is that you would still need to
> install and start X11 before you start gnuplot with wxt. It is just a
> choice, but a choice with consequences. The appearance of X11 graphics, w=
hen
> compared to Mac graphics is inferior, in my (Mac user) opinion, anyway.
>
> It would still take someone familiar with the Mac's idiosyncrasies to get
> wxt working with X11 on a Mac.

After manually applying Timoth=E9e's patch I got it working with
(native) wxMAC (I'm using fink for just about everything except
pangocairo: I had to install pango manually to get pangocairo, all the
other necessary libraries came with fink already).

However, there remain some problems. It seems to run OK, but when I
click on the window with plot an icon appears (as if there was some
action in the background which has to be finished first - an
equivalent to "sand-watch" in windows or linux), so there are problems
with "interactivity" of that window. Plotting works OK.

I have to find out how to get rid of this warning (triggered when I
click on the window with plot):
(process:10862): Pango-WARNING **: Error loading GDEF table 85
(process:10862): Pango-WARNING **: Error loading GPOS table 85
(process:10862): Pango-WARNING **: Error loading GSUB table 85

Mojca

Re: Building wxt terminal for OS X

[<tim...@en...>]

Ethan A Merritt wrote:
> On Friday 17 November 2006 04:07 pm, Timoth=C3=A9e Lecomte wrote:
>  =20
>> To sum up:
>> *get 4.2rc1 from gnuplot.sf.net
>> *apply wxmac.diff to src/wxterminal
>>    =20
>
> Most of wxmac.diff looks like an obvious accommodation to=20
> Mac build options.
>  =20
Exact.
> However the bit below doesn't look like it has anything to
> do with the Mac, but rather Windows.  Is this something that needs
> to go into the general code regardless of this Mac discussion?
> =20
>
> diff -Naur old/wxt_gui.h new/wxt_gui.h
> --- old/wxt_gui.h	2006-10-08 22:37:53.000000000 +0200
> +++ new/wxt_gui.h	2006-10-08 22:48:38.000000000 +0200
> @@ -127,6 +127,11 @@
>  # define IMAGE_SURFACE
>  #endif
> =20
> +/* by default, enable IMAGE_SURFACE */
> +#if !defined(GTK_SURFACE)&&!defined(IMAGE_SURFACE)&&!defined(__WXMSW__=
)
> +# define IMAGE_SURFACE
> +#endif
> +
>  /* temporarly undef GTK_SURFACE for two reasons :
>   * - because of a CAIRO_OPERATOR_SATURATE bug,
>   * - because as for now, it is slower than the pure image surface,
>
>  =20
It is needed for Mac. Think about the '!defined(__WXMSW__)' as a=20
'!defined(__WINDOWS_SURFACE__)'.
I think this patch can go to CVS.

Best regards,

Timoth=C3=A9e

Re: Change in syntax OK for binary data?

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:

> Don't we already have a documented syntax for that?
> 
> If you need to treat the separate data sets in the file
> differently, I think the syntax should be
> 
>   splot 'image.foo' index 0 binary center=(50,50), \
>                  '' index 1 binary center=(150,50)

Possibly.  I've not used index too much although I'm aware of it.  The "binary" is somewhat redundant since there is only one file.  (I think ruling out combined binary and ascii in a file is fine.)

Dan

Re: Building wxt terminal for OS X

[Ethan A M. <merritt@u.washington.edu>]

On Friday 17 November 2006 04:07 pm, Timoth=C3=A9e Lecomte wrote:
> To sum up:
> *get 4.2rc1 from gnuplot.sf.net
> *apply wxmac.diff to src/wxterminal

Most of wxmac.diff looks like an obvious accommodation to=20
Mac build options.

However the bit below doesn't look like it has anything to
do with the Mac, but rather Windows.  Is this something that needs
to go into the general code regardless of this Mac discussion?
=20

diff -Naur old/wxt_gui.h new/wxt_gui.h
=2D-- old/wxt_gui.h	2006-10-08 22:37:53.000000000 +0200
+++ new/wxt_gui.h	2006-10-08 22:48:38.000000000 +0200
@@ -127,6 +127,11 @@
 # define IMAGE_SURFACE
 #endif
=20
+/* by default, enable IMAGE_SURFACE */
+#if !defined(GTK_SURFACE)&&!defined(IMAGE_SURFACE)&&!defined(__WXMSW__)
+# define IMAGE_SURFACE
+#endif
+
 /* temporarly undef GTK_SURFACE for two reasons :
  * - because of a CAIRO_OPERATOR_SATURATE bug,
  * - because as for now, it is slower than the pure image surface,


> *run ./prepare, then ./configure with your favorite options, 'make',=20
> 'make install'
> You get a working gnuplot with the wxt terminal (assuming you have=20
> cairo, pango and wxMac installed), but the plot windows don't get the foc=
us
>=20
> Then the bundling stuff:
> *download the attached Icon.plist and wxmac.icns files
> *run the following commands to create the bundle tree:
>     mkdir -p ./gnuplot.app/Contents/MacOS/
>     mkdir -p ./gnuplot.app/Contents/Resources/
>     mkdir -p ./gnuplot.app/Contents/Frameworks/
>     cp ../src/gnuplot ./gnuplot.app/Contents/MacOS/gnuplot
>     echo -n 'APPL????' >  ./gnuplot.app/Contents/PkgInfo
> * retrieve the attached Icon.plist and wxmac.icns files, put them in the=
=20
> current directory, and put them at their respective locations in the=20
> bundle with the following commands:
>     cp ./Info.plist ./gnuplot.app/Contents/
>     cp ./wxmac.icns ./gnuplot.app/Contents/Resources/
>=20
> Then, you're supposed to be all set. To launch gnuplot, do:
>     open gnuplot.app
> or
>     ./gnuplot.app/Contents/MacOS/gnuplot
>=20
> ... and it should be fine now, according to what I've been told on IRC.
>=20
> Joe, could you try again with these instructions ? Thank you very much.
>=20
> Best regards,
>=20
> Timoth=C3=A9e Lecomte
>=20
>=20

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: Building wxt terminal for OS X

[Joe K. <jko...@co...>]

on 11/17/06 6:35 PM, Ethan Merritt at merritt@u.washington.edu wrote:

> On Friday 17 November 2006 04:12 pm, Joe Koski wrote:
>> The appearance of X11 graphics, when compared to Mac graphics
>> is inferior, in my (Mac user) opinion, anyway.
>=20
> I think you are missing the point, or I am, or we're talking past
> each other.
>=20
> The appearance of x11 graphics is vastly inferior to the appearance
> of the wxt/cairo/pango graphics also.  That's why we are pushing
> the wxt terminal.  Unless I am fundamentally misunderstanding
> something, the visual effect of using the wxt terminal is going to
> be the same no matter which path you take to get it running on
> the Mac.
>=20
> Ethan (not a Mac user)

Ethan, Timoth=E9e, Per, et al,

OK, give me a bit of time, and I will try to follow Timoth=E9e's instructions
on my G5 Mac to see what happens. Most of the steps that he suggests are
steps that I've already done anyway. Yes, I think the messages are flying
too fast here, but that's good, because maybe we'll get somewhere. If my
results are good, then the results on an Intel Mac should also be good.

I'll need to do some man page review and study. I like to know what I'm
doing, not just following instructions. Although I have used UNIX for about
15 years in various versions, I'm mostly a user, not a developer.

If this is stopping the show on the issue of gnuplot-4.3, I would proceed
because this is an extra, not a necessity, for gnuplot use on a Mac. Per's
AquaTerm has us covered in the interim.

Joe
=20

Re: Building wxt terminal for OS X

[Ethan M. <merritt@u.washington.edu>]

On Friday 17 November 2006 04:12 pm, Joe Koski wrote:
> The appearance of X11 graphics, when compared to Mac graphics
> is inferior, in my (Mac user) opinion, anyway.

I think you are missing the point, or I am, or we're talking past
each other.

The appearance of x11 graphics is vastly inferior to the appearance
of the wxt/cairo/pango graphics also.  That's why we are pushing
the wxt terminal.  Unless I am fundamentally misunderstanding
something, the visual effect of using the wxt terminal is going to
be the same no matter which path you take to get it running on
the Mac.

	Ethan (not a Mac user) 

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: Building wxt terminal for OS X

[Joe K. <jko...@co...>]

on 11/17/06 2:57 PM, Ethan Merritt at merritt@u.washington.edu wrote:

> You call it a necessity, where Per implies that it is simply a
> matter of choice between X11 and "native".  Which is it?

Ethan,

We already have X11 available on Macs, so building wxt with X11 as a basis
is a workaround solution. The problem is that you would still need to
install and start X11 before you start gnuplot with wxt. It is just a
choice, but a choice with consequences. The appearance of X11 graphics, when
compared to Mac graphics is inferior, in my (Mac user) opinion, anyway.

It would still take someone familiar with the Mac's idiosyncrasies to get
wxt working with X11 on a Mac.

Joe

Re: Building wxt terminal for OS X

[<tim...@en...>]

Timoth=E9e Lecomte wrote:
> Ethan Merritt wrote:
>  =20
>> On Friday 17 November 2006 01:33 pm, Joe Koski wrote:
>>  =20
>>    =20
>>> on 11/17/06 1:48 PM, Per Persson at per...@ma... wrote:
>>>    =20
>>>      =20
>>>> I still maintain my opinions that=20
>>>> 1) building an X11 based wxt  terminal should be straightforward
>>>> 2) a "native" wxt terminal is going to take a lot of work.
>>>>      =20
>>>>        =20
>>> I think Per's assessment is correct. The problem is not with wxt, but
>>> with the necessity for "bundling" wxWidget applications for native
>>> use on the Mac.=20
>>>    =20
>>>      =20
>> You call it a necessity, where Per implies that it is simply a
>> matter of choice between X11 and "native".  Which is it?
>>  =20
>>    =20
> A native one is for sure better since X11 is not installed by default o=
n=20
> MacOS. The *only* problem we seem to get is this "no-input" issue, whic=
h=20
> is supposed to be related to bundling, as Joe mentioned.
>  =20

I went back to #wxwidgets on IRC, and got confirmed again that bundling=20
should be enough. Let's try to get it right this time.

To sum up:
*get 4.2rc1 from gnuplot.sf.net
*apply wxmac.diff to src/wxterminal
*run ./prepare, then ./configure with your favorite options, 'make',=20
'make install'
You get a working gnuplot with the wxt terminal (assuming you have=20
cairo, pango and wxMac installed), but the plot windows don't get the foc=
us

Then the bundling stuff:
*download the attached Icon.plist and wxmac.icns files
*run the following commands to create the bundle tree:
    mkdir -p ./gnuplot.app/Contents/MacOS/
    mkdir -p ./gnuplot.app/Contents/Resources/
    mkdir -p ./gnuplot.app/Contents/Frameworks/
    cp ../src/gnuplot ./gnuplot.app/Contents/MacOS/gnuplot
    echo -n 'APPL????' >  ./gnuplot.app/Contents/PkgInfo
* retrieve the attached Icon.plist and wxmac.icns files, put them in the=20
current directory, and put them at their respective locations in the=20
bundle with the following commands:
    cp ./Info.plist ./gnuplot.app/Contents/
    cp ./wxmac.icns ./gnuplot.app/Contents/Resources/

Then, you're supposed to be all set. To launch gnuplot, do:
    open gnuplot.app
or
    ./gnuplot.app/Contents/MacOS/gnuplot

... and it should be fine now, according to what I've been told on IRC.

Joe, could you try again with these instructions ? Thank you very much.

Best regards,

Timoth=E9e Lecomte