[GRASS5] Grass 5.0.0 TclTk 8.4 on Jaguar

GRASS GRASS developer
1

Greetings,

I have built Grass 5.0.0 with almost all of the options enabled along with all the dependencies (full report and binaries to follow soon) on Mac OS X 10.2.1 (Jaguar) with gcc 3.1. This is exciting because the binaries will be at least 20% faster than my previous binaries running on the same system. And on my jaguar system it seems like at least 300% faster than the same system when it was running 10.1 - VERY SNAPY. Hooray!

After a little bit of hacking around I was able to get the tcltk interface to work with the Mac OS X native (Cocoa) port of tcltk 8.4.0. A half size screen shot is available at:

    <http://OpenOSX.com/grass/tcltk8.4.screen.jpg&gt;

For the most part It mostly just needs some minor cosmetic improvements. Here are some issues with the interface:

A. The menu bar is currently more than 1200 pixels wide. Wider than the average monitor, I suppose.

B. The buttons of the modules are slightly too small to be completely legible, see:
    <http://OpenOSX.com/grass/tcltk8.4.module.jpg&gt;

C. If you tear off a menu it appears above the top menu bar see:
    <http://OpenOSX.com/grass/tcltk8.4.tear.jpg&gt;

D. Using the X0 (X1, etc.) monitor still uses the non native XFree library to display. I plan on eventually eliminating XFree altogether - any comments and ideas are appreciated.

Any advice on the best way to accomplish these objectives would be appreciated.

Cheers,

Jeshua Lacock __________________________
Programmer/Owner Phone: 760.935.4736
http://OpenOSX.com Fax: 760.935.4845
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_

2

Jeshua Lacock wrote:

D. Using the X0 (X1, etc.) monitor still uses the non native XFree
library to display. I plan on eventually eliminating XFree altogether -
any comments and ideas are appreciated.

This was done for Windows by using a library which emulates the X11
calls. Mapping the various graphics "commands" to API calls was the
simple part. The biggest problems were:

1. The way in which the monitor puts itself into the background. The
technique which is used in src/display/devices/lib/main.c relies upon
the fact that child process will be able to use the window which was
created by the parent in Graph_Set(). This works for X due to its
client-server architecture, but it won't work for other platforms.

The fix used for Windows was to modify mon.start so that:

a) the monitor is spawn()ed as a child process, rather than exec()ed
in the current process, and

b) the monitor is passed the "-" switch, which prevents it from
fork()ing.

The downside is that the first attempt to select the monitor with
mon.select fails (as the monitor hasn't started listen()ing for
connections at that point), producing a warning message. The second
attempt normally succeeds, but it could fail if the monitor's startup
takes too long.

A cleaner solution would involve the parent fork()ing, the child
initialising the GUI aspects (i.e. Graph_Set()), and using e.g.
semaphores so that the parent can exit at the point that the child
finishes the initialisation.

2. The monitor needs to interleave input from the client with GUI
events. On X, both forms of input are sockets, so it can use select().
Ideally, you will need to find some way of waiting until either input
is available on the socket, or an event is received. Otherwise you
would need to poll, which requires some care to avoid consuming 100%
CPU.

--
Glynn Clements <glynn.clements@virgin.net>

3

Hello,

As long as I'm not a programmer, I've any good idea about eliminating XFree
and display grass on a cocoized monitor. However I'm also interested on this
topic and I've found a web that can be useful to you:

http://aquaterm.sourceforge.net/

From this web:
-----
About AquaTerm

AquaTerm is a viewer app that displays vector graphics.
Other apps connect to AquaTerm using a simple remote object messaging
protocol.
By adding "adapters" to legacy code very little coding is needed to bring it
to OS X.

Usage examples include:

* eliminates need for XWindows with command line gnuplot
* support for libraries like PGPLOT under OS X/Aqua
* front end for legacy apps
* graphics output from C and FORTRAN code
* serve as code example showing off cool features of Obj-C/Cocoa
* your ideas here;-)

----

Have you ever heard about this utility? Maybe it could help...

And you wrote,

I have built Grass 5.0.0 with almost all of the options enabled along
with all the dependencies (full report and binaries to follow soon) on
Mac OS X 10.2.1 (Jaguar) with gcc 3.1. This is exciting because the
binaries will be at least 20% faster than my previous binaries running
on the same system. And on my jaguar system it seems like at least 300%
faster than the same system when it was running 10.1 - VERY SNAPY.

I think the binaries are also smaller than the ones built with 10.1. For
exemple, in my 10.1 G4 d.3d hat a size of 1.4 Mbytes and now it's 364 K. And
the same for the other modules. I don't know why...

Bye,
Quim