Re: [Plplot-devel] xwin.c is now split

[<jc...@fe...>]

On Friday 26 July 2002 08:58, Alan W. Irwin wrote:
|  On Fri, 26 Jul 2002, [iso-8859-1] Jo=E3o Cardoso wrote:
|  > On Thursday 25 July 2002 21:37, Alan W. Irwin wrote:
|  > |  If everybody is happy with this splitting, the next step is to
|  > | do exactly the same to tkwin.c.
|  >
|  > I agree with the splitting of the xwin into another auxiliary
|  > driver to be used by xwin_drv and tk_drv. That is the obvious
|  > solution, other than just replicate the needed code into tk_drv.
|  >
|  > But I disagree in putting the common parts in libpltcl.
|  >
|  > Let's see, the tk driver is a driver that uses infrastructures
|  > from the tcl/tk bindings and also happens to use the xwin
|  > driver.....
|
|  Joao, your argument is based on the assumption that the code in
| tk.c (the strict definition of what is meant by the tk driver)
| happens to use the xwin driver, and that assumption is not correct
| at all!  Certainly, the tcl/tk bindings (as opposed to the tk
| driver) used functions defined in the old xwin driver, but even that
| is now no longer the case.

No. It does not matter where the code that makes tk_drv is.

The tk driver uses a plframe, wich is a tk plot widget built=20
specifically for plplot. The plframe should be considered part of the=20
tcl/tk bindings, as it is just one more tk widget. The plframe is=20
created in plframe.c, and in plframe.c:plFrameCmd() the xwin driver is=20
deliberatily opened:
 /* Partially initialize X driver. */
    plD_open_xw(plFramePtr->pls);

Further, plframe.c says:
    This module implements "plframe" widgets for the Tk toolkit.=20
    These are frames that have extra logic to allow them to be
     interfaced with the PLplot X driver.  These are then drawn into
     and respond to keyboard and mouse events.

To say it another way: the gnome driver uses a gnome plot widget that=20
Rafael did not have to write it, as Maurice did with the tk plframe.
The gnome driver links with gnome libraries, the tk driver has to link =20
with the library where the plframe is and with tcl/tk libs.

Of course there is not a clear cut distintion in the tk case, as the=20
bindings make no sense without the tk driver and vice-versa.

|  To clarify the actual situation, the old problem was that libplplot
| itself contained the tcl/tk bindings (in particular plframe.c) that
| had symbols that were resolved by xwin.c.  If you look at the 3
| symbols you found by your ingenious bash line; plX_setBGFG,
| PLColor_from_XColor, and plD_open_xw; in every case it was plframe.c
| (not tk.c!) that had calls to those 3 functions defined in the old
| xwin.c, and this was the source of all the previous linking trouble.
|  That linking trouble is now cured by splitting out xwin_common.c.
|
|  Note my goal was *not* to redesign the tk driver.  Instead my goal
| was something much simpler; to make sure that no library would
| depend on functions defined in driver code.  The side benefit of
| this cross-dependency elimination was that the tcl/tk *binding*
| would be better organized.  I have now achieved these goals by
| removing xwin_common.c from xwin.c.  The point is the functions
| defined in xwin_common.c are referred to *both* by the new xwin.c
| and plframe.c.
|
|  So the simple solution that breaks the prior cross-dependency
| between the plplot libraries and xwin is to put xwin_common.o and
| the plframe.o code that refers to it in the same library.

As I said before, I agree with the splitting, but I do not agree in=20
puting xwin_common in libtcltk. It *is not* and *should not* be part=20
of a tcl/tk library! xwin_common functions has nothing to do (only by=20
accident, not design) with tcl/tk nor the tk driver. The reverse is=20
true, the tk driver was designed as is.

And what happens if someone does not want/has tck/tk but still wants=20
the xwin driver? Do we have to build a libtcltk with only=20
xwin_common.o as the only object file? No, you can't convince me.

The right track is to put

       if (!dlopen ("<path?>/xwin_common_drv.so", RTLD_LAZY))
                      exit(1);

in both xwin.c and tk.c at plD_init_xx, and to put xwin_commo_drv.so in=20
the same directory as the other drivers.


|  I don't
| care what that library is called, but it made sense to me to put
| everything else in there that was concerned with the tcl/tk binding.

Yes, but not what was not been written/designed to be there.

| Once I get the linking reorganized into my new scheme that library
| (lets call it libpltcltk for now) will be linked to both libplplot
| and libtclmatrix. Thus, loading libpltcltk from wish should just
| work. The load command under wish dlopens libpltcltk and because of
| the way that library will be linked in the new scheme, that dlopen
| should drag in libplplot and libtclmatrix as well. That wish
| situation is exactly parallel to what happens in the python case so
| my simple goal of making sure no library code called functions
| defined in driver code and the soon to be implement change to the
| new linking scheme should satisfy concerns we have both expressed
| before about the way the tcl/tk bindings were organized.
|
|  Dropping the topic of the tcl/tk binding and moving back to the tk
| driver topic, in the proposed new linking scheme, the tk driver
| simply links to libplplot and libpltcltk just like the xwin driver,

Ah! the xwin driver links with libtcltk! doesn't that sounds strange to=20
you?

| *but completely independent of that driver* contrary to what you
| seemed to say above.

I was not talking on linking requirements but on design considerations.

| Under that scenario when the libplplot dynamic
| driver code dlopens the tk driver, libplplot will already be loaded,
| libpltcltk will be automatically loaded because of the way that the
| tk driver was linked, and beyond that libtclmatrix will be
| automatically loaded because of the way that libpltcltk was linked.=20
| I think this is a very nice way to do things in Linux.  Looking
| beyond that if we keep this basic organization for libtool and its
| dlopen handler, we can get the same functionality cross-platform.

And what about this? at plinit() the driver is ldopened() in=20
plLoadDriver(), and at plD_init_tk() the driver=20
dlopen("xwin_common.so",...)?

Both libplplot and libtcltk where specified in the link command, and=20
thus are available, and libtclmatrix was specified as a requirement=20
when libtcltk was built, and as such will be loaded.

|  If there are no further objections I would like to split tkwin.c
| and move to the new linking scenario (which is not that different
| from the present chain linking scenario) early tomorrow and then
| give you guys the weekend (when I will be largely out of e-mail
| contact) to hammer it to make sure it all works for your various
| Linux distributions.

It will work. But it is not a good design. As a matter of fact it was=20
not designed, it just works.

|
|  Alan