From: John Stone (
Date: Mon Dec 14 2015 - 09:51:37 CST

Hi Peter,

On Mon, Dec 14, 2015 at 02:25:27PM +0100, Peter Husen wrote:
> I looked a bit into the changes between FLTK versions. First, from this
> changelog:
> >
> and in particular the line
> >Rolled our FLTK libs forward to 1.1.10, so the Mac builds no longer
> >need special treatment here.
> I gather that the FLTK version used for the pre-compiled VMD binaries is
> 1.1.10 (or at least 1.1.x). Correct? And I suppose, it gets statically
> linked?

The particular rev of FLTK depends on the platform VMD is compiled on, but
on Linux, we have been using FLTK 1.1.10 for some time due to bugs and
incompatibilities that cropped up during testing of the FLTK 1.3.x series.
Until now, the issue has been that some of the features in the latest FLTK
caused compatibility problems with the older revs of X11 on RHEL 4.x which
we continued supporting until recently. At this point, I plan to support
only RHEL 5.x or later, and some VMD builds for Linux will only work on
RHEL 6.x or later due to compiler/runtime limitations with older revs.
This may make it feasible to use FLTK 1.3.x on at least some builds,
I will have to see how it works out. We statically link most libs where
possible as it simplifies binary distribution somewhat.

> When I compiled VMD with my modification (which I found to be a bit
> complicated w.r.t. dependencies), I used FLTK 1.3, as that is what I had
> on my Ubuntu. So I guess, I made two changes at once:
> - Switch from FLTK 1.1 to 1.3
> - Add the call to Fl_Window::xclass(const char *)

[... chopped details of docs and tests ...]
> Thus, the WM_CLASS would be set "just" by upgrading to FLTK 1.3, but it
> will be set to "FLTK". I tried, and I can still use my .desktop file and
> icon, but I have to set "StartupWMClass=FLTK" in the .desktop file, and
> this will also match windows from other FLTK applications with the
> default xclass / WM_CLASS (and group them together with VMD under the
> VMD icon). So I believe it would still be better to set it to something
> including "VMD", right?

Yes, the app name should be used to disambiguate VMD from other apps.
Also, we need to do the same thing to all of the Tcl/Tk-managed windows,
which are done via completely unrelated APIs, and we want them to use
the same string as the FLTK windows do.

> I don't understand why you consider it "heavy-handed" to use the
> Fl_Window::xclass function. It exists in both FLTK 1.1 and 1.3, and I
> believe it's the toolkit's api to control the WM_CLASS property.

I prefer setting the FLTK default xclass during startup rather than
having to edit the code for every GUI window creation routine if possible.

> Are you
> saying, you would prefer to use Fl_Window::default_xclass once, when on
> FLTK 1.3, rather than setting the property on each window?


> I should
> mention, though, that the docs say FLTK 1.1 does not duplicate the
> argument to Fl_Window::xclass, as opposed to FLTK 1.3, so the string
> must not be destroyed after calling the function.

Good catch, we'll have to watch out for this.

We still have to chase after the equivalent Tcl/Tk and Python/Tkinter code to
get this completely sorted out, otherwise the improved window grouping
you need for Ubuntu's window manager would only apply to the
FLTK-based windows, and I'll have to add code to do matching things
for the low-level X11/Xlib based OpenGL graphics window also. That being
said, I think that using FLTK 1.3.x with the default_class() API looks
promising for the FLTK parts.


> On 12/11/2015 04:02 PM, John Stone wrote:
> >Hi,
> > I agree that it can be annoying to end up with zillions of icons
> >intermixed among multiple apps with window managers that behave more or
> >less
> >like the Ubuntu dock does.
> >
> >It appears that the issue of WM_CLASS being unset by default
> >goes back a ways in FLTK itself and affects code (like the VMD menus)
> >originally written using Fluid, where the class hasn't been manually
> >set overridden using an approach akin to what you've just reported on:
> >
> >
> >Tcl/Tk and Python/Tkinter have various means of setting the window class
> >string.
> >Tcl/Tk has a low-level C API for this:
> >
> >Doing it from within Tcl scripts looks more like this:
> > "toplevel .mytop -class myclass"
> >
> >Python/Tkinter:
> >!topic/comp.lang.python/3gyotU_Gpgw
> >
> >The need to set WM_CLASS in order to be able to set X resources to
> >override various properties is a pretty good argument for attempting to
> >address this. I think this is going to be something we need to attack
> >in a version post-VMD-1.9.3 however, since there's not sufficient time
> >to really test/debug all of the potential issues before VMD 1.9.3 goes out.
> >
> >That said, I think we can look at a couple of things as approaches to
> >improving this for the next rev after 1.9.3:
> > 1) check behavior with old vs. current FLTK revs
> > 2) manually set WM_CLASS for FLTK revs that don't do this automatically,
> > possibly using ifdefs so we only do heavy-handed approaches like that
> > when dealing with older FLTK revs that don't have improved default
> > behavior.
> > 3) look at whether or not it is practical to force the VMD Tk windows
> > to set their WM_CLASS the same way that VMD does for its FLTK
> > windows,
> > so that they all get grouped together etc.
> >
> >I'm happy to hear other suggestions/comments...
> >
> >Cheers,
> > John Stone
> >
> >

NIH Center for Macromolecular Modeling and Bioinformatics
Beckman Institute for Advanced Science and Technology
University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801           Phone: 217-244-3349