From: John Stone (johns_at_ks.uiuc.edu)
Date: Fri Dec 11 2015 - 09:02:23 CST

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

On Fri, Dec 11, 2015 at 01:55:03PM +0100, Peter Husen wrote:
> 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

-- 
NIH Center for Macromolecular Modeling and Bioinformatics
Beckman Institute for Advanced Science and Technology
University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
http://www.ks.uiuc.edu/~johns/           Phone: 217-244-3349
http://www.ks.uiuc.edu/Research/vmd/