SDL apps behaving nicely in Wmaker?

Bill_Kendrick · August 3, 2002, 2:10am

I’ve gotten a report that TuxPaint doesn’t behave well in WindowMaker
(I forget the exact symptoms, unfortunately).

Today I got a screenshot of some ‘inspector’ wmaker app showing the
window specifications. Instead of showing up as “TuxPaint”, it lists
the app as “SDL_App.SDL_App”. (The WM_CLASS, I think)

He also included a dump from “xwininfo” which showed the window
as being labelled “Tux Paint” (what shows up in the titlebar for me
under KDE and sawfish)

Is there some other WM-related function call I forgot to call to make this
app behave well?

Thx!

-bill!
(sorry if I’m incoherent… really tired )

Matthew_Miller · August 3, 2002, 9:12am

I’ve gotten a report that TuxPaint doesn’t behave well in WindowMaker
(I forget the exact symptoms, unfortunately).
Today I got a screenshot of some ‘inspector’ wmaker app showing the
window specifications. Instead of showing up as “TuxPaint”, it lists
the app as “SDL_App.SDL_App”. (The WM_CLASS, I think)

This is the way all SDL apps seem to get labelled in Window Maker, yeah.

He also included a dump from “xwininfo” which showed the window
as being labelled “Tux Paint” (what shows up in the titlebar for me
under KDE and sawfish)

The titlebar is okay – it’s the actual window specification that’s
SDL_App.SDL_App. This makes it hard to tell a specific SDL game to always
open on a given desktop, etc.On Sat, Aug 03, 2002 at 02:09:09AM -0700, nbs wrote:

–
Matthew Miller @Matthew_Miller http://www.mattdm.org/
Boston University Linux ------> http://linux.bu.edu/

slouken · August 3, 2002, 3:48pm

The titlebar is okay – it’s the actual window specification that’s
SDL_App.SDL_App. This makes it hard to tell a specific SDL game to always
open on a given desktop, etc.

Hmm, I’m not sure what to do about that, except maybe use another environment
variable. It’s definitely a platform-specific thing.

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment

Grzegorz_Jaskiewicz · August 4, 2002, 6:38am

The titlebar is okay – it’s the actual window specification that’s
SDL_App.SDL_App. This makes it hard to tell a specific SDL game to
always

open on a given desktop, etc.

Hmm, I’m not sure what to do about that, except maybe use another
environment
variable. It’s definitely a platform-specific thing.

Under windows we can have also many desktops, fe. login screen in w2k is
seperate desktop.
App with administrative rights (!) can create as many as it wants to have.

GJ.

Ben_Armstrong · August 6, 2002, 6:42pm

I’ve gotten a report that TuxPaint doesn’t behave well in WindowMaker
(I forget the exact symptoms, unfortunately).

The exact symptoms are:

you don’t get an application icon, so the application is not “dockable”
all “Attributes” set on the application get associated with all SDL
apps, not just the one you are trying to change the Attributes for

Today I got a screenshot of some ‘inspector’ wmaker app showing the
window specifications. Instead of showing up as “TuxPaint”, it lists
the app as “SDL_App.SDL_App”. (The WM_CLASS, I think)

This is the way all SDL apps seem to get labelled in Window Maker, yeah.

Which comes down to this:

./video/x11/SDL_x11video.c:353: classhints->res_name = “SDL_App”;
./video/x11/SDL_x11video.c:354: classhints->res_class = “SDL_App”;

In context, the code is:

/* Set the class hints so we can get an icon (AfterStep) */
{
    XClassHint *classhints;
    classhints = XAllocClassHint();
    if(classhints != NULL) {
        classhints->res_name = "SDL_App";
        classhints->res_class = "SDL_App";
        XSetClassHint(SDL_Display, WMwindow, classhints);
        XFree(classhints);
    }
}

Interestingly, WindowMaker was originally a fork from AfterStep, if memory
serves me. They both, therefore, are similar in that they both examine
WM_CLASS, which XSetClassHint manipulates. Unfortunately, the above
code is only a partial solution due to the hardwired value.

Is there any way to fix this so something more reasonable is used instead?
WindowMaker rightly doesn’t rely on the title or icon name for associating
application settings, as those can be changed willy-nilly (take the classic
case of a web browser, which will manipulate both to reflect the title of
the currently viewed page).

Unfortunately, I can’t see anything in the 1.2 API that would help.
SDL_WM_SetCaption is not an appropriate place to set the class because
neither the title nor the icon labels need to bear any relation whatsoever
to WM_CLASS, and in some cases it is desirable for them not to match.
(Also, consider an application with multiple windows, each with a different
name. What then?) It seems the API needs to be extended here, perhaps with
a companion to SDL_GetWMInfo called SDL_SetWMInfo where some platform
dependent window manager info can be set.

He also included a dump from “xwininfo” which showed the window
as being labelled “Tux Paint” (what shows up in the titlebar for me
under KDE and sawfish)

The titlebar is okay – it’s the actual window specification that’s
SDL_App.SDL_App. This makes it hard to tell a specific SDL game to always
open on a given desktop, etc.

Exactly. And it is therefore not specific to WindowMaker. SDL applications
running under any window manager that makes use of WM_CLASS will have
similar problems.

BenOn Sat, Aug 03, 2002 at 01:12:00PM +0000, Matthew Miller wrote:

On Sat, Aug 03, 2002 at 02:09:09AM -0700, nbs wrote:
–
nSLUG http://www.nslug.ns.ca @Ben_Armstrong
Debian http://www.debian.org synrg at debian.org
[ pgp key fingerprint = 7F DA 09 4B BA 2C 0D E0 1B B1 31 ED C6 A9 39 4F ]
[ gpg key fingerprint = 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ]

slouken · August 6, 2002, 10:52pm

This is the way all SDL apps seem to get labelled in Window Maker, yeah.

Which comes down to this:

./video/x11/SDL_x11video.c:353: classhints->res_name = “SDL_App”;
./video/x11/SDL_x11video.c:354: classhints->res_class = “SDL_App”;

Yes, at this point I think the only thing I can do is change those to
an environment variable. I’ll implement it this weekend and add it to
CVS.

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment

slouken · August 18, 2002, 8:42pm

Okay, there is now an environment variable “SDL_VIDEO_X11_WMCLASS”, which
can be used to specify the X11 window’s WM_CLASS. The default value is the
previously used string “SDL_App”.

See ya!
-Sam Lantinga, Software Engineer, Blizzard Entertainment

Ben_Armstrong · August 19, 2002, 3:45am

Great. Thanks!

BenOn Sun, Aug 18, 2002 at 08:41:41PM -0700, Sam Lantinga wrote:

Okay, there is now an environment variable “SDL_VIDEO_X11_WMCLASS”, which
can be used to specify the X11 window’s WM_CLASS. The default value is the
previously used string “SDL_App”.

–
nSLUG http://www.nslug.ns.ca @Ben_Armstrong
Debian http://www.debian.org synrg at debian.org
[ pgp key fingerprint = 7F DA 09 4B BA 2C 0D E0 1B B1 31 ED C6 A9 39 4F ]
[ gpg key fingerprint = 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ]

Ben_Armstrong · August 28, 2002, 7:31am

Hm, apparently I didn’t read far enough in the wmaker docs. The
SDL_VIDEO_X11_WMCLASS hack is sufficient to assign an icon to each SDL app
that sets it, but the app still won’t produce an appicon without a couple
of extra steps. The FAQ says:

6.1 How do I get a normal X application to produce an appicon?On Mon, Aug 19, 2002 at 07:44:54AM -0300, Ben Armstrong wrote:

On Sun, Aug 18, 2002 at 08:41:41PM -0700, Sam Lantinga wrote:

Okay, there is now an environment variable “SDL_VIDEO_X11_WMCLASS”, which
can be used to specify the X11 window’s WM_CLASS. The default value is the
previously used string “SDL_App”.

Great. Thanks!

You must define the WM_CLASS (XSetClassHint()) and the
CLIENT_LEADER or XWMHints.window_group properties, which are
automatically set by most applications that use Xt (Motif, Athena …),
but if you use plain Xlib you must set them by hand.

Also you must make a call to XSetCommand(dpy, leader, argv, argc);

Take a look at Window Maker-0.1x.x/test/test.c that is an example for
writing such an app (which also have an app menu).

Sigh. So, to make SDL apps to behave properly in wmaker, SDL_x11wm.c would
need in the appropriate places:

XWMHints.window_group = WMwindow;

and:

XSetCommand(SDL_Display, WMwindow, argv, argc);

Though where the heck argv and argc will come from, I don’t know Won’t
the app itself need to do this? Or can this be resolved with more
setenv/getenv hackery?

Ben

nSLUG       http://www.nslug.ns.ca      @Ben_Armstrong
Debian      http://www.debian.org       synrg at debian.org

[ pgp key fingerprint = 7F DA 09 4B BA 2C 0D E0 1B B1 31 ED C6 A9 39 4F ]
[ gpg key fingerprint = 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ]