Re: porting Xlib/Motif apps to GTK+
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
Re: porting Xlib/Motif apps to GTK+
Edit ... so you can deploy a shared and statically linked application binary. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: porting Xlib/Motif apps to GTK+
Hi Roger, I moved a medium-sized (100k lines) application from Motif/X11 to gtk+ a while ago. As you say, gdk_ is a thin layer over the X11 drawing system, so converting that is pretty easy. Gdk has quite a few helpers too, eg. stuff for rendering a 24-bit image to whatever visual the server has, so you can save some code there. It shouldn't be a huge effort to port. A quick port of your GUI code should be fairly easy too. You'll end up with a not-very-gtk-ish program but, as long as it works, perhaps that's OK. Prettying it up could be a long-term, low-priority effort. Gtk has a nice GUI builder which could save you some effort, it'd be worth experimenting with. You could also consider using Python, JavaScript or equivalent for the top-level GUI and only using C for the low-level stuff. Gtk3 seems to be heading very rapidly in this direction. I make Windows binaries for my program with a cross-compiler on Linux. It works really well, I can get a nightly build, including a setup.exe installer, uploaded automatically to my server. The Windows backend does not implement all of gdk (the stippling modes are missing, for example) which can be annoying. I make an OS X binary on OS X with the Quartz backend. It also works well, though you end up with a program that looks rather out of place on the Mac desktop unless you do quite a bit of platform-specific stuff. Again, it's easy to package automatically as a .dmg containing a .app. I used to try to make binaries for the various *nix platforms, but it's a huge effort and not very reliable. IMO a tarball plus build-it-yourself instructions is best. If your program is useful the distributions will pick it up and package it for you. You could support one distribution (eg. centos6) yourself I guess. Once you have the thing basically working you could think about more dramatic rewriting. As you say, switching to Cairo is going to be necessary at some point. Good luck! John ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: porting Xlib/Motif apps to GTK+
On 02/29/2012 02:50 AM, Bernhard Schuster wrote: 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. Edit ... so you can deploy a shared and statically linked application binary. Just to be clear, if you use and ship GTK as a shared library, the library remains LPGL, but your app can be licensed however you want it to be without worries of a license conflict. If you use GTK in a statically-linked manner, that might cause some licensing restrictions. However I don't think GTK+ will even function properly when statically-linked to your program. This is especially true on Windows. Products like VMWare's VMPlayer and Desktop ship with their own versions of GTK+ libraries, in case the system libraries are inadequate or incompatible. This works pretty well. The entire GTK+ runtime is well under 8 MB compressed, depending on how much you remove (image loaders, etc). I'm not sure how they figure out compatibility, but launcher wrappers can easily set linker environment variables to force their shipped versions of certain shared libraries to load. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: porting Xlib/Motif apps to GTK+
On Wed, Feb 29, 2012 at 01:17, Roger Davis r...@soest.hawaii.edu wrote: [stuff deleted] Does Cairo have a way of mimicking an X11 XOR-op GC for doing low-overhead ephemeral drawing ops of rubberband-lines, etc.? I have over the years been intrigued of how to do flicker free rubberband selection with gtk/cairo. My current solution may be seen here: https://github.com/dov/dovtk-lasso Feel free to poke me if you need more explanations and more documentation of how it works. Regards, Dov ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: porting Xlib/Motif apps to GTK+
Hi Dov, Thanks very much for that interesting code example. I built it and it seems to work fine, so there is apparently a solution to my problem, however complicated it may turn out to be. I assume since no one has given me a short 'yes' answer to my question of whether you can easily do an XOR line draw in Cairo that the answer is in fact 'no'. That's really too bad, XOR is such a nice, easy solution to quickly drawing a visible overlay line (when one is not particular about its actual color) and then rapidly restoring the original underlying drawing with an XOR erase. A few of my rubberbanding operations are unfortunately a lot more complicated than just a single line or box. I will definitely save this very useful demo code, and probably bug you about it sometime in the future when I get to the point of rewriting all of my Xlib drawing ops. (Lucky you! ;- ) Thanks again! Roger On Wed, 29 Feb 2012, Dov Grobgeld wrote: On Wed, Feb 29, 2012 at 01:17, Roger Davis r...@soest.hawaii.edu wrote: [stuff deleted] Does Cairo have a way of mimicking an X11 XOR-op GC for doing low-overhead ephemeral drawing ops of rubberband-lines, etc.? I have over the years been intrigued of how to do flicker free rubberband selection with gtk/cairo. My current solution may be seen here: https://github.com/dov/dovtk-lasso Feel free to poke me if you need more explanations and more documentation of how it works. Regards, Dov ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: porting Xlib/Motif apps to GTK+
Hi Bernhard, Thanks for your thoughts! I will look further at GooCanvas and COGL to see what's there, although my existing app set doesn't really require any explicit object-oriented support. Roger ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: porting Xlib/Motif apps to GTK+
Hi John, thanks for your comments! As you say, gdk_ is a thin layer over the X11 drawing system, so converting that is pretty easy. Gdk has quite a few helpers too, eg. stuff for rendering a 24-bit image to whatever visual the server has, so you can save some code there. It shouldn't be a huge effort to port. Too bad all of the GDK Xlib wrapper functions appear to be completely removed from GTK 3, it would have been a much easier port! Oh well. Roger ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: porting Xlib/Motif apps to GTK+
On Wed, 29 Feb 2012, jcup...@gmail.com wrote: You need a compositing model instead. Your draw window should be a stack of 2D layers. In your expose callback, paint that part of the window back to front. Do rubberbanding by creating a temporary top layer with the rubber band in and queueing refresh events for the pixels it touches as it moves. Very simple, reasonably efficient, easy to make flicker-free with gtk's automatic double-buffering. Hi John, thanks for the followup. Excuse my deep ignorance on the topic but I'm just beginning to look into GTK/GDK/Cairo. Does the v2 release of this whole bundle include explicit support for the layering approach you describe, or are you talking about my code having to maintain this knowledge on its own (presumably by maintaining two separate drawing surfaces, with the primary image in one and my quasi-rubberband overlays in another), and explicitly overlaying them myself? What about the v3 release? Thanks! Roger ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: porting Xlib/Motif apps to GTK+
On 03/01/2012 04:07 AM, Roger Davis wrote: Hi Dov, Thanks very much for that interesting code example. I built it and it seems to work fine, so there is apparently a solution to my problem, however complicated it may turn out to be. I assume since no one has given me a short 'yes' answer to my question of whether you can easily do an XOR line draw in Cairo that the answer is in fact 'no'. That's really too bad, XOR is such a nice, easy solution to quickly drawing a visible overlay line (when one is not particular about its actual color) and then rapidly restoring the original underlying drawing with an XOR erase. A few of my rubberbanding operations are unfortunately a lot more complicated than just a single line or box. I will definitely save this very useful demo code, and probably bug you about it sometime in the future when I get to the point of rewriting all of my Xlib drawing ops. (Lucky you! ;- ) If it is in cairo operators, it can be done. Else, no. http://cairographics.org/manual/cairo-cairo-t.html#cairo-operator-t ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
porting Xlib/Motif apps to GTK+
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? (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? (3) Although 99% of my Xlib draw ops are targeted at X11 memory Pixmaps, I do occasionally need to draw things like ephemeral rubber-band lines, etc., directly on-screen, frequently with some sort of XOR-op GC. Any reason this could not also be done using the X11 Display/XID discovery routines to target GTK+'s on-screen drawing area widget instead of an in-memory backing store? (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+? (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.? (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
