gnuplot-beta

Re: Building wxt terminal for OS X

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

on 10/8/06 2:54 PM, Timoth=E9e Lecomte at tim...@en... wrote:

> Hi Joe !
>=20
> I'm sorry you did not succeed, but those errors are normal: wxWidgets
> comes in different flavours depending on the platform: wxGTK (as Ethan
> told you), wxMSW for Windows, wxMAC which you logically installed, and
> others. There are a couple of places where it is necessary to choose
> between two possible behaviours (two threads or one) in the terminal
> code. Since I only have access to Linux (wxGTK) and Windows (wxMSW), I
> have chosen to enable the compilation for those two only.
>=20
> However, attached is a patch that enables the compilation for wxMAC. I
> will be very glad to see you try it. Apply it in src/wxterminal and try
> to build again. Hopefully it will work. Don't hesitate to report any issu=
e.
>=20
> Thank you very much for your efforts.
>=20
> Best regards,
>=20
> Timoth=E9e

Timoth=E9e,

I applied the patch, borrowed fontconfig from X11 with an export
PKG_CONFIG_PATH, and successfully built gnuplot-4.2.rc1 with a wxt terminal=
.
(I'll send you a screen shot separately.)

To test, I started gnuplot, set term wxt, and did a plot [-4:4] sin(x) to
see what would happen.

I got the plot, but I could not get "focus" or whatever you call it for the
plot window. When I placed the cursor in the plot window area, all I get wa=
s
a twirling icon telling me to wait. This happens any time the cursor crosse=
s
the wxt window. When I quit gnuplot, the plot window also disappeared.

During the build I saw

if gcc -DHAVE_CONFIG_H -I. -I. -I..  -I../term -I../term
-DBINDIR=3D\"/Tools/gnuplot-4.2/usr/local/bin\"
-DX11_DRIVER_DIR=3D\"/Tools/gnuplot-4.2/usr/local/libexec/gnuplot/4.2\"
-DGNUPLOT_PS_DIR=3D\"/Tools/gnuplot-4.2/usr/local/share/gnuplot/4.2/PostScrip=
t
\" -DCONTACT=3D\"gnu...@li...\"
-DHELPFILE=3D\"/Tools/gnuplot-4.2/usr/local/share/gnuplot/4.2/gnuplot.gih\"
-I/usr/X11R6/include -I/usr/local/include/cairo
-I/usr/local/include/freetype2 -I/usr/local/include
-I/usr/local/include/libpng12 -I/usr/local/include/pango-1.0
-I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include    -g -O2
-ObjC -MT set.o -MD -MP -MF ".deps/set.Tpo" -c -o set.o set.c; \
then mv -f ".deps/set.Tpo" ".deps/set.Po"; else rm -f ".deps/set.Tpo"; exit
1; fi
set.c: In function 'set_mouse':
set.c:2309: warning: pointer targets in passing argument 2 of 'map_position=
'
differ in signedness
set.c:2309: warning: pointer targets in passing argument 3 of 'map_position=
'
differ in signedness

But I don't know if this is significant. What should I be looking for?

I think that this is remarkable progress for a first attempt. I still need
to get a full build of fontconfig to work independently from X11, and I hav=
e
a question submitted to the fontconfig help list to try to get that "make
install" problem resolved.

I'm available for further builds and testing. Let me know what to try next.

Joe

Re: Building wxt terminal for OS X

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

Joe Koski wrote:
> Per,
>
> I'm both ahead of you, and way behind you on this. I have a working cop=
y of
> wxt on my Mac, but it doesn't respond to get focus via the mouse. The
> diagnosis relayed by Timoth=E9e of bundling sounds like the correct pro=
blem
> solution.
>  =20

"Bundling" is probably the right solution.
Alternatively, you can try the attached patch that is documented=20
elsewhere to fix the same problem (apply to src/wxterminal, in addition=20
to the previous patch).


> First, from a Mac user's perspective, wxt uses an entire boat load of
> dependencies that are not normally seen on the Mac. To build wxt, I had=
 to
> install (and sometimes in a specific order) wxMac, atk, pkg-config, gli=
b,
> gettext, freetype, fontconfig, pango, cairo, and gtk+.
gtk+ is absolutely not necessary when you use wxMac (it is if you use=20
wxGTK, though gnuplot does not absolutely depend on it - only for soem=20
tweaks). atk is a gtk+ dependency, so it's not needed either. freetype=20
isn't supposed to be needed, since cairo is capable of using native Mac=20
fonts system (so-called "atsui" system). Fontconfig is only necessary=20
for the cairo freetype backend, so you don't need it either.

> I never did get fontconfig to install completely. The fontconfig Makefi=
le
> works ok for the make part of the build if you add -framework CoreServi=
ces
> to the link line via export LDFLAGS, but make install does not use LDFL=
AGS,
> and I haven't been able to "break the code" on how to add the framework=
 for
> the make install part of the Makefile. My two separate requests to the
> fontconfig mail list have been unanswered. They either think I'm anothe=
r
> idiot Mac user, or I'm a spammer, because I get strange echoes of my
> messages, as if they are being filtered. My ISP (COMCAST) is a notoriou=
s
> source of spam e-mails, so they may simply be filtering me out and igno=
ring
> me. Have you had any experience with that list? Incidentally, wxt does =
not
> work without the incomplete installation of fontconfig. I found that th=
e
> hard way when I removed the partial installation.
>  =20
Again, you should be able not to use fontconfig at all.

> The only part of X11 that I'm using now is the fontconfig that's instal=
led
> in X11R6. By pointing an environment variable at the fontconfig that's
> included with X11, I can get cairo to build and install. I would like t=
o
> avoid X11 entirely, since that's the principal aim of the exercise.
>  =20
Idem.
> I'll report when I make some progress. Let me know if you have any bril=
liant
> flashes of insight.
>  =20
We'll make our best !

Best regards,

Timoth=E9e

Re: Building wxt terminal for OS X

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

on 10/20/06 3:53 PM, Timoth=E9e Lecomte at tim...@en... wrote:

>> First, from a Mac user's perspective, wxt uses an entire boat load of
>> dependencies that are not normally seen on the Mac. To build wxt, I had =
to
>> install (and sometimes in a specific order) wxMac, atk, pkg-config, glib=
,
>> gettext, freetype, fontconfig, pango, cairo, and gtk+.
> gtk+ is absolutely not necessary when you use wxMac (it is if you use
> wxGTK, though gnuplot does not absolutely depend on it - only for soem
> tweaks). atk is a gtk+ dependency, so it's not needed either. freetype
> isn't supposed to be needed, since cairo is capable of using native Mac
> fonts system (so-called "atsui" system). Fontconfig is only necessary
> for the cairo freetype backend, so you don't need it either.

Timoth=E9e,

I went back and removed fontconfig, freetype, pango, and atk. I got
cairo-1.2.4 to build and install successfully with

  ./configure --enable-atsui --enable-quartz --enable-freetype=3Dno
--enable-xlib=3Dno

Question: Do I need xlib for wxt on a Mac?

I then went back and rebuilt and reinstalled wxMac-2.6.3 in case it was
dependent on cairo for headers, libraries, etc.

Then I attempted a rebuild of gnuplot-4.2.rc1. The ./configure is still
looking for pango:

<snip>
checking pkg-config is at least version 0.9.0... yes
checking for CAIROPANGO... configure: WARNING: Package requirements (cairo
>=3D 0.9.0 pango >=3D 1.10 pangocairo >=3D 1.10) for the
wxWidgets terminal were not met:

No package 'pango' found
No package 'pangocairo' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you can avoid the need to call pkg-config if you set the
environment variables CAIROPANGO_CFLAGS and CAIROPANGO_LIBS to the
corresponding flags for cairo, pango, and pangocairo.
See the pkg-config man page for more details.
<snip>

As a result, no wxt terminal was built. Is there a way to not use pango and
still build a wxt terminal?

The apparent pango dependency is what led me down the primrose path to
fontconfig, freetype, etc., on my last build attempt. Maybe the make file
needs some changes for the Mac?

Joe

Re: Building wxt terminal for OS X

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

Joe Koski a =E9crit :
> on 10/20/06 3:53 PM, Timoth=E9e Lecomte at tim...@en... wrot=
e:
>
>  =20
>>> First, from a Mac user's perspective, wxt uses an entire boat load of
>>> dependencies that are not normally seen on the Mac. To build wxt, I h=
ad to
>>> install (and sometimes in a specific order) wxMac, atk, pkg-config, g=
lib,
>>> gettext, freetype, fontconfig, pango, cairo, and gtk+.
>>>      =20
>> gtk+ is absolutely not necessary when you use wxMac (it is if you use
>> wxGTK, though gnuplot does not absolutely depend on it - only for soem
>> tweaks). atk is a gtk+ dependency, so it's not needed either. freetype
>> isn't supposed to be needed, since cairo is capable of using native Ma=
c
>> fonts system (so-called "atsui" system). Fontconfig is only necessary
>> for the cairo freetype backend, so you don't need it either.
>>    =20
>
> Timoth=E9e,
>
> I went back and removed fontconfig, freetype, pango, and atk. I got
> cairo-1.2.4 to build and install successfully with
>
>   ./configure --enable-atsui --enable-quartz --enable-freetype=3Dno
> --enable-xlib=3Dno
>
> Question: Do I need xlib for wxt on a Mac?
>  =20
No, you don't.

> I then went back and rebuilt and reinstalled wxMac-2.6.3 in case it was
> dependent on cairo for headers, libraries, etc.
>
> Then I attempted a rebuild of gnuplot-4.2.rc1. The ./configure is still
> looking for pango:
> <snip>
>
> As a result, no wxt terminal was built. Is there a way to not use pango=
 and
> still build a wxt terminal?
>  =20
No, there isn't. Pango is needed, it's a direct dependency for the wxt=20
terminal. However you can build it without freetype and without fontconfi=
g.

Thanks again for your efforts.

Best regards,

Timoth=E9e

Re: Building wxt terminal for OS X

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

on 10/23/06 2:23 PM, Timoth=E9e Lecomte at tim...@en... wrote:

> Joe Koski a =E9crit :
>> on 10/20/06 3:53 PM, Timoth=E9e Lecomte at tim...@en... wrote:
>>=20
>>  =20
>>>> First, from a Mac user's perspective, wxt uses an entire boat load of
>>>> dependencies that are not normally seen on the Mac. To build wxt, I ha=
d to
>>>> install (and sometimes in a specific order) wxMac, atk, pkg-config, gl=
ib,
>>>> gettext, freetype, fontconfig, pango, cairo, and gtk+.
>>>>      =20
>>> gtk+ is absolutely not necessary when you use wxMac (it is if you use
>>> wxGTK, though gnuplot does not absolutely depend on it - only for soem
>>> tweaks). atk is a gtk+ dependency, so it's not needed either. freetype
>>> isn't supposed to be needed, since cairo is capable of using native Mac
>>> fonts system (so-called "atsui" system). Fontconfig is only necessary
>>> for the cairo freetype backend, so you don't need it either.
>>>    =20
>>=20
>> Timoth=E9e,
>>=20
>> I went back and removed fontconfig, freetype, pango, and atk. I got
>> cairo-1.2.4 to build and install successfully with
>>=20
>>   ./configure --enable-atsui --enable-quartz --enable-freetype=3Dno
>> --enable-xlib=3Dno
>>=20
>> Question: Do I need xlib for wxt on a Mac?
>>  =20
> No, you don't.
>=20
>> I then went back and rebuilt and reinstalled wxMac-2.6.3 in case it was
>> dependent on cairo for headers, libraries, etc.
>>=20
>> Then I attempted a rebuild of gnuplot-4.2.rc1. The ./configure is still
>> looking for pango:
>> <snip>
>>=20
>> As a result, no wxt terminal was built. Is there a way to not use pango =
and
>> still build a wxt terminal?
>>  =20
> No, there isn't. Pango is needed, it's a direct dependency for the wxt
> terminal. However you can build it without freetype and without fontconfi=
g.
>=20
> Thanks again for your efforts.
>=20
> Best regards,
>=20
> Timoth=E9e

Timoth=E9e, Per,

We're now back to the focus issue in with the wxt terminal, but more on tha=
t
later.

To summarize my progress so far:

I now have installed on my Mac: cairo, pango, gettext, wxMac, and pkg-confi=
g
above and beyond the usual Xcode-2.4 tools. Are any of these unnecessary fo=
r
building wxt on the Mac?

To build cairo, I did

 ./configure --enable-atsui --enable-quartz --enable-freetype=3Dno
--enable-xlib=3Dno

After two minor corrections to the pango build (thanks to Behdad on the
gtk-i18n Mail List), I built pango with

  ./configure --with-x=3Dno

Then I went back and rebuilt gnuplot-4.2.rc1, including wxt, with the new
pango and cairo. The wxt plot window again appears with gnuplot, but I stil=
l
can't get focus inside the plot window. I do see Mac fonts, however. The
cursor behavior has changed. When the plot appears, my arrow cursor changes
to crosshairs similar to X11, which is a step forward. When I place the
crosshairs over the plot window, the cursor changes to a spinning color
pinwheel. If I click back to the finder, I get my arrow cursor back.

I'm with Per. I'm surprised that the wxWidget folks don't have a way of
getting focus without bundling. Should I post the question there?

All suggestions are welcome.

Joe
=20

Re: Building wxt terminal for OS X

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

On Tuesday 24 October 2006 03:25 pm, Joe Koski wrote:
> I'm with Per. I'm surprised that the wxWidget folks don't have a way
> of getting focus without bundling. Should I post the question there?

Could someone please enlighten me as to what "bundling" means
in this context?   

The historical meaning of the word as used in my part of the world does
not seem to pertain :-)

  http://www.eyewitnesstohistory.com/bundling.htm


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

Re: Building wxt terminal for OS X

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

on 10/24/06 4:49 PM, Ethan Merritt at merritt@u.washington.edu wrote:

> On Tuesday 24 October 2006 03:25 pm, Joe Koski wrote:
>> I'm with Per. I'm surprised that the wxWidget folks don't have a way
>> of getting focus without bundling. Should I post the question there?
> 
> Could someone please enlighten me as to what "bundling" means
> in this context? 
> 
> The historical meaning of the word as used in my part of the world does
> not seem to pertain :-)
> 
>   http://www.eyewitnesstohistory.com/bundling.htm
> 

Ethan,

I'm just learning also, but I can see bundles in the Applications folder on
my Mac. All dependencies necessary to run an application are included in a
single structure that you can often "drag and drop" from the installer
window to (for example) the Applications folder. To start the application,
you double-click it. In other cases a disk image installer (.dmg) is used to
place the application (.app) into the correct folder, and also place other
files into other Mac locations such as /Library.

Per sent us a link to the wikipedia

  http://en.wikipedia.org/wiki/Bundle_%28Mac_OS_X%29

which is a much better explanation.

Actually, I much prefer the definition of bundling that you found.

Joe

Re: Building wxt terminal for OS X

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

Joe Koski wrote:
> <snip>
> Timoth=E9e, Per,
>
> We're now back to the focus issue in with the wxt terminal, but more on=
 that
> later.
>
> To summarize my progress so far:
>
> I now have installed on my Mac: cairo, pango, gettext, wxMac, and pkg-c=
onfig
> above and beyond the usual Xcode-2.4 tools. Are any of these unnecessar=
y for
> building wxt on the Mac?
>  =20
I am not sure about gettext, but I guess it's a dependency of glib,=20
right ? If it's the case, you're all set.
> To build cairo, I did
>
>  ./configure --enable-atsui --enable-quartz --enable-freetype=3Dno
> --enable-xlib=3Dno
>
> After two minor corrections to the pango build (thanks to Behdad on the
> gtk-i18n Mail List), I built pango with
>
>   ./configure --with-x=3Dno
>  =20
Ok. Good to know.

> Then I went back and rebuilt gnuplot-4.2.rc1, including wxt, with the n=
ew
> pango and cairo. The wxt plot window again appears with gnuplot, but I =
still
> can't get focus inside the plot window. I do see Mac fonts, however. Th=
e
> cursor behavior has changed. When the plot appears, my arrow cursor cha=
nges
> to crosshairs similar to X11, which is a step forward. When I place the
> crosshairs over the plot window, the cursor changes to a spinning color
> pinwheel. If I click back to the finder, I get my arrow cursor back.
>
> I'm with Per. I'm surprised that the wxWidget folks don't have a way of
> getting focus without bundling. Should I post the question there?
>  =20

It doesn't seem to be a rare question, since the wxWidgets wiki is quite=20
lengthy about it. We should have looked at it earlier. Below are a=20
couple of interesting links:

http://www.wxwidgets.org/wiki/index.php/App_Not_Getting_Input_When_Run

"You _must_ create a bundle for Carbon and Cocoa apps on OS X.

If your binary is named "foo" then this works for testing purposes=20
(don't ship like this): mkdir -p foo.app/Contents/MacOS mv foo=20
foo.app/Contents/MacOS

When you get things working you can eventually tweak your build system=20
to make the bundle before the final link step and pass -o=20
foo.app/Contents/MacOS/foo to the linker rather than plain -o foo."

Some more details:
http://www.wxwidgets.org/wiki/index.php/Distributing_WxWidgets_Applicatio=
ns-Distributing_WxMac_Programs
http://www.wxwidgets.org/wiki/index.php/Installing_WxMac#Executables_.28.=
27Bundles.27.29
http://www.wxwidgets.org/wiki/index.php/WxMac_Issues#Building_a_MacOSX_ap=
plication_bundle

Could you try the mkdir suggestion above ? (Don't use my second patch,=20
it should be useless.) It seems quite straightforward.


I also asked on irc again, and was redirected to the following page:
http://wxforum.shadonet.com/viewtopic.php?t=3D9146

The alternative to "bundling" is the "resource fork", that can be done wi=
th:

/Developer/Tools/Rez -d __DARWIN__ -t APPL -d __WXMAC__ -i=20
<insert_app_name> -d WXUSINGDLL -o <insert_app_name> Carbon.r

where <insert_app_name> is the name of the executable (gnuplot here). On=20
http://wxforum.shadonet.com/viewtopic.php?t=3D6045&highlight=3Dmacos, it =
is=20
said that this is only for test purposes.


I hope you'll finally get it working !

Best regards,

Timoth=E9e

Re: Building wxt terminal for OS X

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

on 10/25/06 11:28 AM, Timoth=E9e Lecomte at tim...@en... wrote:

> Joe Koski wrote:
>> <snip>
>> Timoth=E9e, Per,
>>=20
>> We're now back to the focus issue in with the wxt terminal, but more on =
that
>> later.
>>=20
>> To summarize my progress so far:
>>=20
>> I now have installed on my Mac: cairo, pango, gettext, wxMac, and pkg-co=
nfig
>> above and beyond the usual Xcode-2.4 tools. Are any of these unnecessary=
 for
>> building wxt on the Mac?
>>  =20
> I am not sure about gettext, but I guess it's a dependency of glib,
> right ? If it's the case, you're all set.
>> To build cairo, I did
>>=20
>>  ./configure --enable-atsui --enable-quartz --enable-freetype=3Dno
>> --enable-xlib=3Dno
>>=20
>> After two minor corrections to the pango build (thanks to Behdad on the
>> gtk-i18n Mail List), I built pango with
>>=20
>>   ./configure --with-x=3Dno
>>  =20
> Ok. Good to know.
>=20
>> Then I went back and rebuilt gnuplot-4.2.rc1, including wxt, with the ne=
w
>> pango and cairo. The wxt plot window again appears with gnuplot, but I s=
till
>> can't get focus inside the plot window. I do see Mac fonts, however. The
>> cursor behavior has changed. When the plot appears, my arrow cursor chan=
ges
>> to crosshairs similar to X11, which is a step forward. When I place the
>> crosshairs over the plot window, the cursor changes to a spinning color
>> pinwheel. If I click back to the finder, I get my arrow cursor back.
>>=20
>> I'm with Per. I'm surprised that the wxWidget folks don't have a way of
>> getting focus without bundling. Should I post the question there?
>>  =20
>=20
> It doesn't seem to be a rare question, since the wxWidgets wiki is quite
> lengthy about it. We should have looked at it earlier. Below are a
> couple of interesting links:
>=20
> http://www.wxwidgets.org/wiki/index.php/App_Not_Getting_Input_When_Run
>=20
> "You _must_ create a bundle for Carbon and Cocoa apps on OS X.
>=20
> If your binary is named "foo" then this works for testing purposes
> (don't ship like this): mkdir -p foo.app/Contents/MacOS mv foo
> foo.app/Contents/MacOS
>=20
> When you get things working you can eventually tweak your build system
> to make the bundle before the final link step and pass -o
> foo.app/Contents/MacOS/foo to the linker rather than plain -o foo."
>=20
> Some more details:
> http://www.wxwidgets.org/wiki/index.php/Distributing_WxWidgets_Applicatio=
ns-Di
> stributing_WxMac_Programs
> http://www.wxwidgets.org/wiki/index.php/Installing_WxMac#Executables_.28.=
27Bun
> dles.27.29
> http://www.wxwidgets.org/wiki/index.php/WxMac_Issues#Building_a_MacOSX_ap=
plica
> tion_bundle
>=20
> Could you try the mkdir suggestion above ? (Don't use my second patch,
> it should be useless.) It seems quite straightforward.
>=20
>=20
> I also asked on irc again, and was redirected to the following page:
> http://wxforum.shadonet.com/viewtopic.php?t=3D9146
>=20
> The alternative to "bundling" is the "resource fork", that can be done wi=
th:
>=20
> /Developer/Tools/Rez -d __DARWIN__ -t APPL -d __WXMAC__ -i
> <insert_app_name> -d WXUSINGDLL -o <insert_app_name> Carbon.r
>=20
> where <insert_app_name> is the name of the executable (gnuplot here). On
> http://wxforum.shadonet.com/viewtopic.php?t=3D6045&highlight=3Dmacos, it is
> said that this is only for test purposes.
>=20
>=20
> I hope you'll finally get it working !
>=20
> Best regards,
>=20
> Timoth=E9e
>=20
Timoth=E9e, Per,

I tried both approaches to resolve the focus problem with my gnuplot binary=
,
but the problem persists. Thanks to Timoth=E9e for finding the links that
clearly state the problem, and also state the solutions.

First I tried making a simple gnuplot.app structure like the one in the web
page

  http://www.wxwidgets.org/wiki/index.php/App_Not_Getting_Input_When_Run

but, if you try to execute gnuplot, it probably needs to launch a terminal
application like iTerm.app, then gnuplot via a script so you can communicat=
e
with the gnuplot. (I think that's what Per was hinting to me a year or more
back when he suggested iTerm.app, while we were trying to figure out how to
bundle octave). When I double-clicked gnuplot.app, the hard disk made a
noise, but nothing happened.

Then I tried the Rez incantation

jakoski$ /Developer/Tools/Rez -d __DARWIN__ -t APPL -d __WXMAC__ -i gnuplot
-d WXUSINGDLL -o gnuplot Carbon.r

and, indeed, something happened to gnuplot, as there was a delay of a secon=
d
or two at the command line while the hard disk made noise, and no errors
were reported. When I tried the resulting Rez modified binary, it worked,
but the focus problem remained. Do we need a separate wxt.app, or is that
called AquaTerm?

Unless we can get the Rez modification to work, there are some important
implications for gnuplot here, and I think Per can give us some insight
based on his experience with gnuplot and AquaTerm.

If I am interpreting this correctly, the only sensible way to distribute
gnuplot-4.2 for Macs, with the wxt terminal included, is via a bundled
application. This is great for the end user (easy installation), but
requires significantly more work on the Mac development end to pull things
together.=20

A Mac .dmg installer is probably indicated to also install header files,
etc. so that octave and other open source applications can find gnuplot
during builds. Fortunately, gnuplot doesn't change every five minutes like
octave does, so this is probably doable without too much burden on the
developers in the long run, once the approach is perfected.

We could sure use a knowledgeable Mac developer about now. I do not claim t=
o
be one, so any and all advice will be given careful consideration.
Meanwhile, I'll be reading the other links that Timoth=E9e found.

Joe

Re: Building wxt terminal for OS X

[Per P. <per...@ma...>]

On Oct 26, 2006, at 01:32, Joe Koski wrote:

>>
> Timoth=E9e, Per,
>
> I tried both approaches to resolve the focus problem with my =20
> gnuplot binary,
> but the problem persists. Thanks to Timoth=E9e for finding the links =20=

> that
> clearly state the problem, and also state the solutions.
>
> First I tried making a simple gnuplot.app structure like the one in =20=

> the web
> page
>
>   http://www.wxwidgets.org/wiki/index.php/=20
> App_Not_Getting_Input_When_Run
>
> but, if you try to execute gnuplot, it probably needs to launch a =20
> terminal
> application like iTerm.app, then gnuplot via a script so you can =20
> communicate
> with the gnuplot. (I think that's what Per was hinting to me a year =20=

> or more
> back when he suggested iTerm.app, while we were trying to figure =20
> out how to
> bundle octave). When I double-clicked gnuplot.app, the hard disk =20
> made a
> noise, but nothing happened.
>
> Then I tried the Rez incantation
>
> jakoski$ /Developer/Tools/Rez -d __DARWIN__ -t APPL -d __WXMAC__ -i =20=

> gnuplot
> -d WXUSINGDLL -o gnuplot Carbon.r
>
> and, indeed, something happened to gnuplot, as there was a delay of =20=

> a second
> or two at the command line while the hard disk made noise, and no =20
> errors
> were reported. When I tried the resulting Rez modified binary, it =20
> worked,
> but the focus problem remained. Do we need a separate wxt.app, or =20
> is that
> called AquaTerm?
>
> Unless we can get the Rez modification to work, there are some =20
> important
> implications for gnuplot here, and I think Per can give us some =20
> insight
> based on his experience with gnuplot and AquaTerm.
>
> If I am interpreting this correctly, the only sensible way to =20
> distribute
> gnuplot-4.2 for Macs, with the wxt terminal included, is via a bundled
> application.

Yes. I wasn't sure whether Timoth=E9e's addition was in fact a complete =20=

wxGnuplot or just a terminal (see older mail). The point here is that =20=

with wxMac/wxCocoa *everything* must be wrapped up in a single wx-=20
application.
As you guessed, AquaTerm is simply a mechanism to (seamlessly) detach =20=

the process doing the drawing (e.g. gnuplot) and the process doing =20
the rendering (AquaTerm) in a controlled manner.

As an experiment, pull out the wxWhatever.app/Contents/MacOS/whatever =20=

execuatable from any wxMac demo and start it at the prompt, and =20
you'll see the can't-get-any-events behaviour.

*However*, X11 on Mac OS X is the same as on any other platform, so =20
the focus problem shouldn't arise if you used wxWidgets for X11.


> This is great for the end user (easy installation), but
> requires significantly more work on the Mac development end to pull =20=

> things
> together.

A guesstimate is that a proper[1] port to make gnuplot a self-=20
contained Cocoa application is about the same amount of work as a =20
wxMac port. It all comes down to how familiar you are with the =20
respective class libraries etc.

[1] With proper I don't mean to imply that other ways aren't any =20
good, just that *on the Mac* Cocoa provides the richest application =20
environment, enjoys full benefit from systemwide improvements, =20
adheres automatically to look-and-feel, well supported etc. Someone =20
would still have to maintain it though.

>
> A Mac .dmg installer is probably indicated to also install header =20
> files,
> etc. so that octave and other open source applications can find =20
> gnuplot
> during builds. Fortunately, gnuplot doesn't change every five =20
> minutes like
> octave does, so this is probably doable without too much burden on the
> developers in the long run, once the approach is perfected.
>
> We could sure use a knowledgeable Mac developer about now. I do not =20=

> claim to
> be one, so any and all advice will be given careful consideration.

While I wouldn't mind to be considered for the above category, I have =20=

even less time than usual at my disposal.
In fact, we should try to find someone (preferrably with an Intel =20
based Mac) willing to help out with Mac development since:
1) it is not likely that I will have more time to spend on open =20
source project in the near future
2) I can't test/fix problems related to Intel Macs

/Per

Re: Building wxt terminal for OS X

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

Joe Koski wrote:
> on 10/25/06 11:28 AM, Timoth=E9e Lecomte at tim...@en... wro=
te:
>
>  =20
>> <...>
>>> Then I went back and rebuilt gnuplot-4.2.rc1, including wxt, with the=
 new
>>> pango and cairo. The wxt plot window again appears with gnuplot, but =
I still
>>> can't get focus inside the plot window. I do see Mac fonts, however. =
The
>>> cursor behavior has changed. When the plot appears, my arrow cursor c=
hanges
>>> to crosshairs similar to X11, which is a step forward. When I place t=
he
>>> crosshairs over the plot window, the cursor changes to a spinning col=
or
>>> pinwheel. If I click back to the finder, I get my arrow cursor back.
>>>
>>> I'm with Per. I'm surprised that the wxWidget folks don't have a way =
of
>>> getting focus without bundling. Should I post the question there?
>>>  =20
>>>      =20
>> It doesn't seem to be a rare question, since the wxWidgets wiki is qui=
te
>> lengthy about it. We should have looked at it earlier. Below are a
>> couple of interesting links:
>>
>> http://www.wxwidgets.org/wiki/index.php/App_Not_Getting_Input_When_Run
>>
>> "You _must_ create a bundle for Carbon and Cocoa apps on OS X.
>>
>> If your binary is named "foo" then this works for testing purposes
>> (don't ship like this): mkdir -p foo.app/Contents/MacOS mv foo
>> foo.app/Contents/MacOS
>>
>> When you get things working you can eventually tweak your build system
>> to make the bundle before the final link step and pass -o
>> foo.app/Contents/MacOS/foo to the linker rather than plain -o foo."
>>
>> Some more details:
>> http://www.wxwidgets.org/wiki/index.php/Distributing_WxWidgets_Applica=
tions-Di
>> stributing_WxMac_Programs
>> http://www.wxwidgets.org/wiki/index.php/Installing_WxMac#Executables_.=
28.27Bun
>> dles.27.29
>> http://www.wxwidgets.org/wiki/index.php/WxMac_Issues#Building_a_MacOSX=
_applica
>> tion_bundle
>>
>> Could you try the mkdir suggestion above ? (Don't use my second patch,
>> it should be useless.) It seems quite straightforward.
>>
>>
>> I also asked on irc again, and was redirected to the following page:
>> http://wxforum.shadonet.com/viewtopic.php?t=3D9146
>>
>> The alternative to "bundling" is the "resource fork", that can be done=
 with:
>>
>> /Developer/Tools/Rez -d __DARWIN__ -t APPL -d __WXMAC__ -i
>> <insert_app_name> -d WXUSINGDLL -o <insert_app_name> Carbon.r
>>
>> where <insert_app_name> is the name of the executable (gnuplot here). =
On
>> http://wxforum.shadonet.com/viewtopic.php?t=3D6045&highlight=3Dmacos, =
it is
>> said that this is only for test purposes.
>>
>>
>> I hope you'll finally get it working !
>>
>> Best regards,
>>
>> Timoth=E9e
>>
>>    =20
> Timoth=E9e, Per,
>
> I tried both approaches to resolve the focus problem with my gnuplot bi=
nary,
> but the problem persists. Thanks to Timoth=E9e for finding the links th=
at
> clearly state the problem, and also state the solutions.
>
> First I tried making a simple gnuplot.app structure like the one in the=
 web
> page
>
>   http://www.wxwidgets.org/wiki/index.php/App_Not_Getting_Input_When_Ru=
n
>
> but, if you try to execute gnuplot, it probably needs to launch a termi=
nal
> application like iTerm.app, then gnuplot via a script so you can commun=
icate
> with the gnuplot. (I think that's what Per was hinting to me a year or =
more
> back when he suggested iTerm.app, while we were trying to figure out ho=
w to
> bundle octave). When I double-clicked gnuplot.app, the hard disk made a
> noise, but nothing happened.
>  =20

I have two things to say about that:
First, it looks like you can use the "open" command to start the bundled=20
application from the command line. Since gnuplot is a command-line=20
application, it may help. ('open gnuplot.app' or 'open -b gnuplot.app'=20
may do the trick)

Second, what is said on the above page may not be enough. From another=20
discussion on irc and reading of the other pages I mentioned, it looks=20
like you also need a file called gnuplot.app/Contents/Info.plist that=20
describes the content of the bundle. Below is an example adapted from=20
http://www.wxwidgets.org/wiki/index.php/Mac_OS_X_And_Xcode_For_Beginners =
:

<?xml version=3D"1.0" encoding=3D"UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www=
.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version=3D"1.0">
<dict>
	<key>CFBundleDevelopmentRegion</key>
	<string>English</string>
	<key>CFBundleExecutable</key>
	<string>gnuplot</string>
	<key>CFBundleGetInfoString</key>
	<string>gnuplot 4.2, (c) 2006 Thomas Williams and others</string>
	<key>CFBundleIconFile</key>
	<string>wxmac.icns</string>
	<key>CFBundleIdentifier</key>
	<string>org.gnuplot.app</string>
	<key>CFBundleInfoDictionaryVersion</key>
	<string>6.0</string>
	<key>CFBundleLongVersionString</key>
	<string>4.2, (c) 2006 Code::gnuplot</string>
	<key>CFBundleName</key>
	<string>gnuplot</string>
	<key>CFBundlePackageType</key>
	<string>APPL</string>
	<key>CFBundleShortVersionString</key>
	<string>4.2</string>
	<key>CFBundleSignature</key>
	<string>????</string>
	<key>CFBundleVersion</key>
	<string>4.2</string>
	<key>LSRequiresCarbon</key>
	<true/>
	<key>NSHumanReadableCopyright</key>
	<string>Copyright 2006 me</string>
</dict>
</plist>



> Then I tried the Rez incantation
>
> jakoski$ /Developer/Tools/Rez -d __DARWIN__ -t APPL -d __WXMAC__ -i gnu=
plot
> -d WXUSINGDLL -o gnuplot Carbon.r
>
> and, indeed, something happened to gnuplot, as there was a delay of a s=
econd
> or two at the command line while the hard disk made noise, and no error=
s
> were reported. When I tried the resulting Rez modified binary, it worke=
d,
> but the focus problem remained.
I'm sorry, but I can't help here.

>  Do we need a separate wxt.app, or is that
> called AquaTerm?
>  =20
No, the wxt terminal is built inside the gnuplot executable. There is=20
nothing more than the gnuplot executable and the other libraries that=20
you compiled before, and I guess those are loaded at run-time and don't=20
need to be in the bundle or anything.
> Unless we can get the Rez modification to work, there are some importan=
t
> implications for gnuplot here, and I think Per can give us some insight
> based on his experience with gnuplot and AquaTerm.
>
> If I am interpreting this correctly, the only sensible way to distribut=
e
> gnuplot-4.2 for Macs, with the wxt terminal included, is via a bundled
> application. This is great for the end user (easy installation), but
> requires significantly more work on the Mac development end to pull thi=
ngs
> together.
>  =20
Ultimately, it will be a matter of a makefile, nothing extraordinary. We=20
just need to get it working by hand first ;) I'm sorry not to have a Mac=20
to help more here.

Best regards,

Timoth=E9e

Re: Building wxt terminal for OS X

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

Was there any resolution to the issue of building wxt terminal
support for OSX?

I would like to put out a second release candidate for 4.2,
and would like to add a note to the INSTALL file about known
platform-specific problems.

The most important thing to establish is whether this is going to 
require further code changes in gnuplot, which might hold up a
final release of 4.2, or whether it is a matter of installation
instructions only. 

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

Re: Building wxt terminal for OS X

[Per P. <per...@ma...>]

On Nov 17, 2006, at 20:27, Ethan Merritt wrote:

> Was there any resolution to the issue of building wxt terminal
> support for OSX?

Not that I know of.

I still maintain my opinions that 1) building an X11 based wxt  
terminal should be straightforward, and 2) a "native" wxt terminal is  
going to take a lot of work.

I feel a little uneasy to make a statement like the above without  
actually getting my hands dirty, but for the time being it's the best  
I can do...

>
> I would like to put out a second release candidate for 4.2,
> and would like to add a note to the INSTALL file about known
> platform-specific problems.
>
> The most important thing to establish is whether this is going to
> require further code changes in gnuplot, which might hold up a
> final release of 4.2, or whether it is a matter of installation
> instructions only.
>
> -- 
> 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 1:48 PM, Per Persson at per...@ma... wrote:

> 
> On Nov 17, 2006, at 20:27, Ethan Merritt wrote:
> 
>> Was there any resolution to the issue of building wxt terminal
>> support for OSX?
> 
> Not that I know of.
> 
> I still maintain my opinions that 1) building an X11 based wxt
> terminal should be straightforward, and 2) a "native" wxt terminal is
> going to take a lot of work.
> 
> I feel a little uneasy to make a statement like the above without
> actually getting my hands dirty, but for the time being it's the best
> I can do...
> 
>> 
>> I would like to put out a second release candidate for 4.2,
>> and would like to add a note to the INSTALL file about known
>> platform-specific problems.
>> 
>> The most important thing to establish is whether this is going to
>> require further code changes in gnuplot, which might hold up a
>> final release of 4.2, or whether it is a matter of installation
>> instructions only.
>> 
>> -- 
>> Ethan A Merritt
>> Biomolecular Structure Center
>> University of Washington, Seattle WA
> 

Ethan,

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. That requires either extensive modifications to the gnuplot make files,
or a special separate make file approach for the Mac. Neither choice is very
pretty. This is compounded by the necessity for "Universal" binaries for PPC
and Intel Macs. In a year or so, that need will decrease. I have the time,
but not the knowledge to do the work. We need someone who has been through
Mac's developer "boot camp" recently. Got any scholarships laying around?
I'll be happy to spend a week or two in San Francisco at someone else's
expense.

Would making the gnuplot build into an Xcode project help? Just a thought.

Over on the octave list, John Eaton is currently tearing his hair out over
some octave/gnuplot interface issues. It sounds to me like he needs some
sort of a gnuplot device independent file for storing and later recalling
plot commands and options that were sent to gnuplot. His problems centers
around an octave routine called legend.m, which has always been somewhat
problematic.

The current gnuplot-4.2.rc1 continues to work well on my Mac, with Per's
AquaTerm doing the job for .eps and .pdf output.

Joe
 

Re: Building wxt terminal for OS X

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

On Friday 17 November 2006 01:33 pm, Joe Koski wrote:
> on 11/17/06 1:48 PM, Per Persson at per...@ma... wrote:
> >
> > 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.
>
> 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. 

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

If it's just a matter of choice, it would be nice to provide
a concise statement of what is needed to build an X11-based
wxt terminal under OSX.  And of course since that is the only
working option, it should be made the default.

In this scenario, can the code in .../term/wxt.trm and 
 .../src/wxterminal/*  be used with no change from the 
state in 4.2-rc1?

> The current gnuplot-4.2.rc1 continues to work well on my Mac, with
> Per's AquaTerm doing the job for .eps and .pdf output.

Much as I appreciate Per's work on aquaterm, it remains
short on features compared to either x11 or wxt. I'm sure that
beefing up aquaterm is possible, but it's clearly not going to
happen for version 4.2.  The wxt terminal, on the other hand,
is all ready to go except for installation instructions.


-- 
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

[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 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: 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...>]

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, 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

[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: 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

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

Ethan Merritt wrote:
> On Friday 17 November 2006 01:33 pm, Joe Koski wrote:
>  =20
>> on 11/17/06 1:48 PM, Per Persson at per...@ma... wrote:
>>    =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
>> 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
A native one is for sure better since X11 is not installed by default on=20
MacOS. The *only* problem we seem to get is this "no-input" issue, which=20
is supposed to be related to bundling, as Joe mentioned.


> If it's just a matter of choice, it would be nice to provide
> a concise statement of what is needed to build an X11-based
> wxt terminal under OSX.  And of course since that is the only
> working option, it should be made the default.
>
> In this scenario, can the code in .../term/wxt.trm and=20
>  .../src/wxterminal/*  be used with no change from the=20
> state in 4.2-rc1?
>  =20
Building for X11 (i.e. wxGTK, as you're doing on Linux) should be=20
working right now on MacOS, without modifications, with the usual=20
'configure; make; make install' routine.
Building for wxMAC needs the patch that makes the code in=20
src/wxterminal/wxt_gui.* files recognize the __WXMAC__ preprocessor=20
variable in addition to __WXMSW__ and __WXGTK__. We also need to figure=20
out why the window is not getting input. I'd love to see it working, but=20
I don't have a Mac to test it...

Maybe Mojca can help, since she is now trying to build gnuplot on a Mac=20
too ?

Best regards,

Timoth=E9e

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