gtk interfaces status

[Janne Blomqvist]

On Tue, Feb 8, 2011 at 04:17, Jerry DeLisle <jvdelisle@frontier.com> wrote:
> On 02/06/2011 09:51 PM, Paul Richard Thomas wrote:
>>> consider adding an intrinsic module to gfortran (4.7) for this stuff. We
>>
>> Hmmm! I am not convinced about this.  Why gtk, rather than
>> iso_varying_string or any other library that you might care to think
>> of?
>>
>
> Quite a few of the more popular programming languages have bindings for
> gtk+. Along with QT it is one of the leading tool-kits for gnome/kde apps
> which covers most linux windowing tools. gtk+ is mature, well established,
> easy to use, and getting better.

I don't think anyone is faulting you for choosing to make an interface
to Gtk+ rather than some other GUI toolkit. IMHO Gtk+ and Qt are the
two GUI toolkits that matter (as in, makes sense to start a new
project in) on Unix or for Unix/Windows/OSX cross-platform
development, and Qt is C++ so it's trickier to interface to it from
other languages. So I think you made the right choice with Gtk+.

Rather the point is should this be part of the official gcc
distribution. I would argue not, and I suspect this was also the
argument Paul was making. GCC itself does not contain external
libraries that people just think are useful but are not per se related
to the operation of the compiler. Neither does it contain interfaces
to external libraries that don't supply such bindings themselves, such
as C headers for LAPACK (yes, the latest lapack 3.3 does finally
include official C bindings, but for most of its existence it didn't).

> I also think iso_varying_strings should be an intrinsic module for gfortran.
> This will be especially good if we reimplement it using gfortran's automatic
> allocation/reallocation features. Some might argue that iso_varying_strings
> is not needed, but it really has a nice interface and functionality.

I suppose this can be argued, as iso_varying_string is part of the
standard. However, with the allocatable characters and
realloc-on-assignment, I don't think there is much need for it, and
AFAICS there is little if any use of it. Similar applies for COCO, I
suppose.

> By intrinsic module, I mean packaging it somehow with gfortran so that all a
> user does is "use gtk'. I am not sure how we would do that specifically, but
> this would be an extension obviously.

I don't think it needs to be an intrinsic module for that. For
instance, on my ubuntu machine I have installed a package
libnetcdf-dev which contains the static netcdf library, header files,
and a /usr/include/netcdf.mod file which is the F90 interface. In the
Fortran code I can just do "use netcdf" and it works. Or well, for
some reason /usr/include is not in the standard include path for
gfortran (was there some reason for that, or is it just oversight?),
so one needs to add "-I/usr/include" to the command line. Secondly,
that .mod file is made with the system compiler (4.4) whose .mod files
are not compatible with 4.6. But in principle all the mechanisms are
there so that gfortran can easily use 3rd party libraries with module
interfaces.

I imagine one could make an "install" target in the Makefile of the
gtk-fortran project which installs the mod file and static/shared
libraries in some include directory (depending on some user specific
prefix setting). Or if one wants to be fancy, one could make rpm/deb
packages that the user can install.

That being said, I see no problem with including the gtk+ interface in
the binary builds we provide in an unofficial manner.

Another potential benefit of not being an official part of gcc is that
you don't need to require copyright assignment to FSF, which might
discourage external contributors. But that is up to you, of course.

-- 
Janne Blomqvist