Re: gtk_window wmclass_name

On Tue, 2003-03-25 at 18:02, Havoc Pennington wrote:
> On Tue, Mar 25, 2003 at 05:47:24PM -0500, Christopher James Lahey wrote:
> > I noticed that gtk_window initializes wmclass_name to g_get_prgname.  I
> > noticed the new API g_get_application_name and was wondering if
> > gtk_window should be using that instead.
> No, the difference between prgname and application_name is that the
> app name is translated. The window class should not be localized.
> See the ICCCM for what the window class should be set to.

Okay.  I looked up this string in the ICCCM and it does actually specify
what value to use for wmclass_name.  Changing wmclass_name is probably
not the right thing to do.

> > This is an issue because that field is what appears to be used in
> > tasklist when doing grouping.  (At least in 2.2.)
> The tasklist is grouping on the basis of the group leader window,
> which is a concept not exposed in the GTK API that ends up
> corresponding to "a single process" for GTK.  Traditionally (Motif
> etc.), I think it was more like "one toplevel window plus transients"
> and really GTK is probably broken here.

I'm not concerned with how it decides grouping.  I'm concerned with what
label gets displayed for the group.

I'm fine with it using wmclass to do grouping.  The problem is when this
string gets displayed to the user.

Perhaps we need to add a property that specifies the user visible name
of the group.  We would use g_get_application_name to set the value and
tasklist could use it if it was there and fall back to wmclass_name if
it's not.

In any case, the bug is that galeon 1.3.3 shows up in the task list as
galeon-bin.  I just want to display the right thing for the user.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]