Re: [Oorexx-devel] ooRexx and GTK+

[Rony G. F. <Ron...@wu...>]

Hi David,
>
> I have been doing some research on GUIs for cross platform development
> using ooRexx. When I looked at this some months ago I thought that
> using a library like wxWidgets would be the key to solving this
> problem. But I have since discovered something about GTK+ which makes
> me lean toward it as a cross platform solution.
>
> The basic problem in dealing with GUIs in ooRexx is that the GUIs
> usually take control away from ooRexx when you start the event loop
> and do not return control until the event loop is over. Thus objects
> created using ooRexx have now way to process events. This is not very
> useful. One of the reasons no work has been done in this area is that
> the 4.0 version of ooRexx will expose objects at the C/C++ level and
> thus the callback functions could manipulate those objects.
>
AFAIK, this is the main reason why Regina has a RexxCallBack() function,
such that it became feasible to create and use an external function
library for a portable GUI, named Rexx/DW (cf.
<http://rexxdw.sourceforge.net/index.html>).

> But I have found a way using GTK+ that will allow a Rexx script to
> process events. GTK+ actually has two functions for controlling event
> processing, gtk+main() and gtk_main_iteration(). gtk_main() is the one
> normally used to start event processing and it does not return until
> the gtk_main_quit() function is called. However, the
> gtk_main_iteration() function is quit different, it procces one event
> and then returns back to the caller. Thus, with the proper control
> mechanisms, an ooRexx script could continually call
> gtk_main_iteration() until an external event caused the loop to end.
> This would give the application a chance to process an event after
> gtk_main_iteration() returns and then call it again.
>
Interesting!

> I have not tested this yet but I am about 95% sure I can get the
> proper control mechanisms in place to make event processing happen
> without a lot of user programming in the application. Most of the
> event processing could happen automatically and the user would only
> have to override events they are interested in.
>
> At this time, I would like to know if the possibility os using GTK+ as
> a cross platform GUI for ooRexx is interesting enough that other might
> help with the effort. There are GTK+ binaries available for Windows
> and most Linux distributions have GTK+ available already. You can get
> the Windows binary at
>
> http://www.gimp.org/~tml/gimp/win32/downloads.html
> <http://www.gimp.org/%7Etml/gimp/win32/downloads.html>
>
> I have already done a lot of the hard work with the GtkRxDlg package I
> maintain on SourceForge (http://sourceforge.net/projects/gtkrxdlg/).
> Most od the GTK widgets are already modeled in the provided ooRexx
> class library and the of course the shared function library (DLL) is
> already written to handle those objects from ooRexx.
>
> So speak up and let me know what you think of this idea. I have no
> plans in place yet so please speak up and let me know if this solution
> would be acceptable to both Linux and Windows developers. Offers of
> help in implementing, documenting and creating examples for this
> solution would obviously be very helpful.
>
First of all: any initiative to add portable GUI support to/for ooRexx
is interesting and helpful. It should be done in a way that allows such
programs to be run unchanged on all platforms, ooRexx runs on, at least
Linux, MacOSX and Windows. If there is not a lot to be done to make your
GTK+ external function library usable for ooRexx for the purpose of
demonstrating a few proof-of-concept programs, then please do so. There
are GUI-builders for GTK around which might be applicable eventually for
ooRexx as well.

One other question would be whether it is necessary for new GTK widgets
to program explicitly support in the external Rexx function library
("maintenance burden") or whether a generic interface in the external
function library would allow for using any new functionality that may be
introduced with newer versions of GTK+.

---

My personal opinion:

    * GUI applications should be openplatform, i.e. an ooRexx
      application using a GUI should be executable on any of the
      supported platforms
          o this allows to escape any operating system "lockin", such
            that companies can eventually freely decide to switch (or
            stay) with a certain operating system platform,
    * as one will always have to supply an external function library and
      the respective GUI-libraries to be able to take advantage of such
      openplatfrom GUI programming, I would strongyl suggest to use Java
      instead for that purpose
          o the Java runtime environment (JRE) is available on all
            platforms (and could be distributed optionally for systems
            not having a JRE installed),
          o the Java awt, swing and swt have everything available that
            one might ever want to use,
          o there is now even Qt available for Java (cf. "Qt Jambi",
            have never tried it)

So I would suggest to employ BSF4Rexx for openplatform GUI needs. The
interface is generic, such that all Java classes can be used and taken
advantage from. (In addition it allows for taking advantage of any Java
classes there are. It also allows to interface ooRexx with any
application that offers a Java interface, e.g. even C++ written
applications like StarOffice/OpenOffice.)

This would be easily realizable *today* by supplying BSF4Rexx as an
optional installation item for ooRexx with an appropriate installer. As
the Symposiae have shown, such GUI applications run unchanged on Linux,
MacOSX and Linux.

There is one concept in Java that cannot be really mapped with ooRexx,
that's synchroneous processing of events. Rather, the current
implementation collects all events in a FIFO queue, which then need to
be retrieved in an event loop from ooRexx at which point in time they
can be processed. This is a problem for event-handling needs, where the
event handler is supposed to be able to return a veto (not to carry on
the event) as a result of communicating the event. For this particular
use-case a call-back mechanism into ooRexx is a must, something that
only a future ooRexx 4.x can supply.

-

For those people/companies that have Windows installed and want to keep
it as a strategic investment for the foreseeable future, Java might
still be an option, but most likely this group would want to go on with
ooDialog which carries the connotation for "truly Window'ish". However,
support on par with the Java-support via BSF4Rexx for Microsoft's .Net
for that clientel would be another, important development.

Regards,

---rony