VMD-L Mailing List
From: Peter Husen (phusen_at_sdu.dk)
Date: Mon Dec 14 2015 - 07:25:27 CST
I looked a bit into the changes between FLTK versions. First, from this
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
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 *)
From these docs (Fl_Window::xclass(const char *) and
Fl_Window::default_xclass(const char *) in FLTK 1.3:
it would seem that in FLTK 1.3:
- There is such a thing as a "default xclass", which you can set using
Fl_Window::default_xclass(const char *)
- If not set, this defaults to "FLTK"
- If not manually set, Fl_Window::xclass(const char *) (on any window)
also sets the default xclass, i.e. the first time it's called
In the FLTK 1.1 docs, the default_xclass function does not exist, nor is
the concept of a default xclass or its default value of "FLTK"
mentioned. From this and also this discussion:
I gather that FLTK 1.1 doesn't set any WM_CLASS, unless you set the
xclass for each window individually, while FLTK 1.3 sets it as "FLTK",
unless you called the default_xclass or xclass function.
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?
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. 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.
On 12/11/2015 04:02 PM, John Stone wrote:
> 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"
> 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
> 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...
> John Stone