From: Peter Husen (phusen_at_sdu.dk)
Date: Fri Dec 11 2015 - 06:55:03 CST

I tried adding the line
> Fl_Window::xclass("VMD");
after the line
> Fl_Window::label(_title);
in VMDFltkMenu::VMDFltkMenu(...) in VMDFltkMenu.C

Now, the class of the main window and some others (Graphical
Representations, Colors, Materials, Labels...) get the WM_CLASS "VMD"
and are grouped under the same icon in the Launcher (and I can e.g.
"spread" these windows by clicking the icon to pick one of them). Using
a .desktop file in ~/.local/share/applications, I can provide it with an
icon, which gets associated with these windows, when VMD is running, and
which I can then "Lock to Launcher" and start VMD from it, when it isn't
running.

Other windows already set the WM_CLASS, e.g. TK Console ("tkcon") and
VMD Preferences ("vmdPrefs"), and these are unchanged with my above
change in the source and still get each their own "?" icon. I am not
sure, if it is possible to specify multiple WM_CLASS'es in a .desktop
file, but the above change (particularly for the main window) is already
a big improvement for me, saving some space in the Launcher and allowing
me to lock VMD to the launcher, provide a recognizable icon and track if
it's running. Other programs also produce "?" icons (e.g. Octave plot
windows), so I can easily get lost in these icons.

Regards,
Peter Husen

On 12/10/2015 03:54 PM, John Stone wrote:
> Hi,
> The VMD GUI (except for Tk windows) are written using FLTK, so
> for most of the key windows, the low-level X calls are made by FLTK
> and not by VMD itself. On Linux, the VMD graphics window is managed
> by VMD itself, so that is the only window where we could add calls to
> set the window properties. A useful experiment would be for you to
> grab the latest version of FLTK and see if it behaves better with
> Ubuntu out-of-the-box (try the sample programs it comes with and
> see how they behave). If it has the same issue, then this should be
> reported to the FLTK maintainers. Similarly, I would recommend checking
> the behavior of the Tcl/Tk toolkit's Tk windows, and see if their code
> needs modification as well.
>
> Cheers,
> John Stone
> vmd_at_ks.uiuc.edu