Re: porting Xlib/Motif apps to GTK+

[Bernhard Schuster <schuster bernhard googlemail com>]

Am 29. Februar 2012 00:17 schrieb Roger Davis <rbd soest hawaii edu>:
> Hello all,
>
> I am new to this list, please forgive me if this material has been discussed
> before. I have a substantial body of Xlib/Motif code that I need to port
> to a more modern GUI and have some questions in that regard with respect
> to GTK+ and cousins. This code uses Motif for dialog panels, etc., but uses
> low-level Xlib drawing routines (XDraw*(), XFillRectangle(), etc.) for lots
> of drawing operations onto X11 Pixmap surfaces in memory which are then copied
> to on-screen X11 Window objects as necessary. These Xlib-created drawings
> largely contain imagery being rendered for purposes of scientific data
> processing and analysis together with simple line and text annotations.
>
> Although I have yet to fully examine the GTK+ widget set in any detail, it
> seems likely that it will provide functionality that is roughly equivalent
> to the Motif widget set for purposes of dialog panels, etc. My questions
> here are mostly about the suitability of GDK (and relatives) for support (or
> replacement) of all of my extensive Xlib drawing ops as described above.
>
> My first glance through GDK version 2 docs found numerous parallels with
> Xlib drawing ops, e.g., gdk_draw_line(), etc. On further research, however,
> it appears that all of these Xlib-derived primitives are being deprecated
> and are completely gone from GDK 3, where they have been replaced by
> fundamentally different graphics modules, i.e., Cairo and Pango. My
> current CentOS 6 platforms still have GTK+ v2, but I have no interest
> in undertaking such a major port to a GTK+ v2 API that's already been
> essentially EOL'ed. I also don't see a straightforward way to transform
> thousands of lines of detailed Xlib drawing ops into the radically
> different graphics model of Cairo/Pango.
>
> My one possible ray of hope in this quandary is that I see GDK 3 has a
> small set of X Window System Interaction functions, specifically,
> gdk_x11_display_get_xdisplay() and gdk_x11_window_get_xid(). It seems to me
> that it should be possible for me to create some sort of GTK+ drawing area
> widget with backing store, retrieve that backing store's XDisplay/XID with
> these utility functions, do all of my usual Xlib drawing ops to that XID,
> then use whatever GTK+ functionality exists to copy that backing store to
> an on-screen window. Is there any fundamental problem with this approach?
>
> Along these lines I have a number of related questions:
>
> (1) Is it expected that this family of gdk_x11_*() functions will remain
> part of GDK for the foreseeable future, or is it likely that they too will
> be deprecated in the next few years? I have read elsewhere about Wayland
> supplanting X11 at some point, and although most of what I see indicates
> that X11 is expected to remain available on Linux systems for many years
> to come, I could well imagine a future GDK going directly to Wayland
> and dropping all support for an X11 backend. What is the expected
> direction and timeline here?
Nobody can give a proper answer to that question, it all depends on
vendors and distributions pushing wayland (or not).


> (2) On a closely related point, my software also needs to run on MacOS,
> which it currently does through all of the MacPorts X11 and OpenMotif
> packages. I can well imagine that a GTK+/GDK port for MacOS would run
> directly on Quartz and not use X11 at all. Is this the case right now,
> or will it become so in the near future? Is there, or will there be,
> a way to force GTK+ on MacOS to operate through an X11 backend rather
> than using Quartz?
AFAIK there are/were 2 gtk versions availiable for Mac. One which uses
X11 as wrapper, and one directly using quartz.
Though the direct quartz usage seems to be the recommended
(http://www.gtk.org/download/macos.php)


> (4) My apps have their own X11 event handler routines, called indirectly
> by the Xt dispatching mechanism, so that any XEvent related to a drawing
> area or its top-level parent window gets handled by my own code, which
> typically needs little more than the mouse coordinates, button state
> information, and keyboard key code info. Is this readily available through
> whatever event-handling routines are provided by GTK+?
Availiable, as simple as:
g_signal_connect (G_OBJECT (canvas), "motion-notify-event", G_CALLBACK
(your_callback_event_mouse_move), void_ptr_to_priv_data);


> (5) I can see that moving all of my drawing operations to Cairo/Pango
> would provide the best long-term support on multiple platforms, I'm
> leery of moving this way solely due to the amount of effort required to
> rewrite such a large amount of code. Is there any kind of documentation
> or tutorial available, however, which is specifically targeted at
> adapting relatively simple Xlib drawing ops to Cairo/Pango which might
> be of help to me should I decide to tackle this? Does Cairo have a way
> of mimicking an X11 XOR-op GC for doing low-overhead ephemeral drawing ops
> of rubberband-lines, etc.?
If you really need that high throughput, you can also give goocanvas
or "bare" cogl. But that is up to your application and what kind of
systems you target.

> (6) Am I going in completely the wrong direction, should I be porting
> this code to some other 2D graphics GUI? Or alternatively, should I just
> forget the whole thing and hope that OpenMotif and Xlib stay around for
> a considerably longer period, at least until I retire (another 15 years
> or so) and this becomes somebody else's nightmare? ;->
Gtk+ is one of the widely used toolkits, an alternative would be Qt (a
bit slower, proper windows support, C++, increased abstraction, stupid
preprocessor, sometimes nasty debugging).
If you are used to Motif then I'd go for gtk+

> (7) If I decide to go this route, I need to have a stable GTK+/GDK v3
> environment. This appears to not yet be available within CentOS 6,
> and I'm guessing it might not appear before CentOS 7. Any thoughts here?
> Is it possible for v3 and v2 to safely co-exist on my CentOS 6 system
> along with any other essential stuff (glib?)? Is there any documentation
> available on doing such a dual-version installation?
On Arch Linux gtk2 and gtk3 libraries do co-exist. No problem. Worst
case you can still ship the libraries itself with your application and
add a starter script to set the proper library paths.
If your application license is either GPL or LPGL you are also allowed
to link statically (afaik), so you can deploy a gtk2 and a gtk3
version.


Regards

Bernhard Schuster