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
changelog:
> http://www.ks.uiuc.edu/Research/vmd/vmd-1.9/devel.html
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?

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:
> http://www.fltk.org/doc-1.3/classFl__Window.html#a913bb4f81e4627e5b4a860ef78bca1ff
> http://www.fltk.org/doc-1.3/classFl__Window.html#aa5e0b61428d6a4e497b13a5bdde85328
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:
> http://comments.gmane.org/gmane.comp.lib.fltk.devel/10689
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.

Best regards,
Peter Husen

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:
> https://www.mail-archive.com/fltk-dev@easysw.com/msg01470.html
>
> Tcl/Tk and Python/Tkinter have various means of setting the window class string.
> Tcl/Tk has a low-level C API for this:
> https://www.tcl.tk/man/tcl7.5/TkLib/SetClass.3.html
> Doing it from within Tcl scripts looks more like this:
> "toplevel .mytop -class myclass"
> http://computer-programming-forum.com/57-tcl/3dee3d193ac6d22e.htm
> Python/Tkinter:
> https://groups.google.com/forum/#!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
> vmd_at_ks.uiuc.edu
>