Am 29. Februar 2012 00:17 schrieb Roger Davis <r...@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 _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
