On Wed, 15 Sep 2010 08:43:24 -0400
Brad Jorsch <[email protected]> wrote:
> On Wed, Sep 15, 2010 at 08:35:29AM +0200, Gilbert wrote:
> >
> > Note that all mine which need it get patched when building so that
> > they properly identify themselves as DockApps instead of using the
> > 'class' property which usually gets set to the app name.
>
> What exactly does making this change do, though? As far as I can tell in
> a quick grep through the source code, the only thing it does is use the
> res_name instead of res_class when the res_class is "DockApp". Which is
> effectively the same as the normal behavior in the common case where
> res_name and res_class are the same.
>
It's slightly complicated to explain, but here goes. As I mentioned, I like to
use wmaker without the dock or clip because I want the desktop very clean. This
means that I also like to disable app icons for everything. In order to do that
I put this:
"." = {NoAppIcon = Yes;};
"*" = {NoAppIcon = Yes;};
in WMWindowAttributes so that it applies to everything. But, once that is done,
DockApps which identify themselves tihe 'class' propert set to the app name
don't show when you run them. Internally, wmaker respects them as DockApps and
lety them show their icon(window) only if they have class set to DockApp.
> That said, detecting res_class set to DockApp could be useful to avoid
> issues with toolkits that refuse to let you set initial_state to
> WithdrawnState,[1] although in my experience those issues seem to be more
> with other window managers (e.g. openbox and fluxbox) that support
> Window Maker-style dockapps than with wmaker itself.[2]
>
>
> [1] For example, gtk+. See
> https://bugzilla.gnome.org/show_bug.cgi?id=139322 and
> https://bugzilla.gnome.org/show_bug.cgi?id=609202
> [2] The only issue I've found with wmaker is that it causes "Kill"
> option in the right-click menu to not work. In openbox and fluxbox,
> it makes them refuse to pull the dockapp into their "slit" at all.
>
Exactly, having 'DockApp' as the class name makes them behave more consistently
internally. This might be fixed in some other way internally, but I couldn't
figure it out...
Meanwhile, I've done the hard work (LOL) of patching every one that needed it.
I dare say that many of the apps will need other fixups for modern systems, so
throwing the fixup for 'class' should be a small matter.
I suggest we patch and maintain every DockApp we can -perhaps with a 'crm' in
the source name. I'd rather see tarballs of the app sources, but having them in
git would be fine, as well -just harder(perhaps) to distinguish the sources
from the originals.
Gilbert
--
To unsubscribe, send mail to [email protected].
