Re: gnuplot, wxWidgets and distributions

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

Ethan A Merritt wrote:
> On Sunday 24 September 2006 11:48 am, Timoth=E9e Lecomte wrote:
>  =20
>>>> - write a plugin interface to gnuplot, so that the wxWidgets is
>>>> dynamically loadable and can be distributed separately
>>>>        =20
>>> That would be the best.
>>>  =20
>>>      =20
>> Technically the best, but arguably not for the user, since he would ha=
ve=20
>> to find it in the distribution package manager...
>>    =20
>
> I don't think that by itself is a problem. People are used to downloadi=
ng
> and installing extension plugins for their web browser, video/audio plu=
gins
> for their media player, filter plugins for their word processor, etc.
> They should be able to handle terminal plugins for gnuplot.
>  =20

Of course, they can, but do they really want ? When you want to do=20
scientific work, you already spend so much time learning languages for=20
computation purposes (whether it is C, C++, Fortran, Python, Octave or=20
whatever) that you are pleased when something works directly. There are=20
few exceptions. The best program is the one that gives 90% of its full=20
power with the default installation.

Octave people are currently implementing a "package manager", because=20
they have so many additional and less tested code in Octave Forge that=20
they need a plugin system to make them easily available.

Firefox as a browser made part of its success with the extensions, but=20
it's because they have a well-thought distribution system for them,=20
because the original application is very good, and because the community=20
is vary active writing those extensions. Ultimately, interesting=20
extensions are cleaned/rewritten and integrated.

That's not really the case for gnuplot. We are currently discussing=20
plugins because of dependencies issues. vlc (a media player) is another=20
example of application based on plugins, and like gnuplot it is to make=20
backend support more flexible. The main one is in wxWidgets by the way.=20
But even if the app is architectured around these plugins, in practise=20
it is simply distributed with the few main backends and that's all.

In our case, I do think wxWidgets is a well-thought dependency. Gtk=20
would have been a good choice too, though, and has the big advantage to=20
be very widely distributed on Linux. That's why I was offering to work=20
on that if needed.

If we choose to implement plugins, we should provide distribution=20
guidelines. For example, we can encourage distributions to install by=20
default the full package, but to allow (if they want) the user to=20
install stripped-down versions. That's what Debian is is doing right=20
now: there's one package with the x11 binary (gnuplot-x11) and one with=20
the gnuplot binary (gnuplot-nox), but the default 'gnuplot' package just=20
installs the two of them. Somebody who only wants the core can install=20
gnuplot-nox manually.

Maybe we can satisfy Fedora that way, maybe not. I'm quite sure the=20
trend is not to multiply packages. And I would like to see full packages=20
distributed anyway.

> I think the bigger hurdle is portability.  Implementing a plugin system
> for linux would be easy.  But we'd have to do it all over again for=20
> Solaris, OSF, Irix, Windows, OSX, etc.  Or perhaps there is a=20
> multi-platform plugin infrastructure that I am unaware of?
>  =20

 From the GModule documentation in GLib=20
(http://developer.gnome.org/doc/API/2.0/glib/glib-Dynamic-Loading-of-Modu=
les.html):

"These functions provide a portable way to dynamically load object files=20
(commonly known as 'plug-ins'). The current implementation supports all=20
systems that provide an implementation of ||dlopen()|| (e.g. Linux/Sun),=20
as well as HP-UX via its ||shl_load()|| mechanism, and Windows platforms=20
via DLLs."

(OSX is just another Unix)

If we had to choose a general-purpose library to depend on, I think GLib=20
would be the best choice (then we also get a lot of other useful=20
cross-platform functions, such as threads).

> We discussed this issue briefly quite a while ago, with regard to patch
> #588805  	  external functions via plugins
>
> I like the idea of plugins, but implementation is non-trivial.
>  =20

Non-trivial, but it can be done cleanly with GLib. See=20
http://blog.eikke.com/index.php/ikke/2005/05/18/gmodules_are_fun for an=20
example.

>
> However, ...
> I can think of one more alternative.  If the wxt terminal code were
> broken out into a separate executable, equivalent to gnuplot_x11,=20
> then the core gnuplot binary would not need to be linked against
> pango/cairo/wxWidgets.   The extreme case of this would be=20
> teaching the wxt code to understand the same piped binary stream
> format that goes between gnuplot <---> gnuplot_x11.  Then we'd
> have a binary pipe API shared by multiple terminal types.
> The library dependencies would not pertain to the core gnuplot
> binary, only to the parallel helper programs.
>  =20

Pipes are probably as specific to the platforms as dynamic libraries=20
are. Moreover, they add an additional bottleneck (not that big if the=20
protocal is binary, I admit). Plugins are probably better. If we decide=20
to implement plugins, the x11 terminal could be a plugin without the=20
need to use pipes...

Anyway, although I see clearly the technical aspects, I'm still as much=20
puzzled about the _choices_ that we should make. Plugins or not ?
(if you have other reasons besides distributions concerns, please speak=20
up !)

Maybe the best is to see how the current implementation choice is=20
handled by distributions. Let's release 4.2 as it is, and give some time=20
to see what distributions do with it. If there's something wrong (if the=20
wxWidgets terminal is _never_ used for example), then we can still=20
address it later. The world won't crash because of it.

Best regards,

Timoth=E9e