Re: [dev] [dwm] about _NET_ACTIVE_WINDOW support

[Andreas Amann]

On Sat, Jan 07, 2012 at 10:20:27PM +0200, Ivan Kanakarakis wrote:
> dwm, when it receives a _NET_ACTIVE_WINDOW message, it transfers focus to
> the client that asked for it, but never sets the root window id to that
> window's id. That is ofcourse a choice - the standard doesn't force one to
> do that, but that makes tools like xdotool and xprop fail on some options
> that people may find usefull. Specifically the following commands:
> 
> $ xprop -root _NET_ACTIVE_WINDOW
> $ xdotool getactivewindow
> 
> To get those working properly, one would need to,
> 
> XChangeProperty(dpy, root, netatom[NetActiveWindow], XA_WINDOW, 32,
> PropModeReplace, (unsigned char *)&c->win, 1);
> 
> everytime a new window is focused. I guess that would go into
> setfocus(Client *c) function or something similar.

I use the attached patch for this. In addition it also maintains a
NetClientList, which exposes the list of managed windows in the ewmh
recommended way.  

Andreas
diff --git a/dwm.c b/dwm.c
--- a/dwm.c
+++ b/dwm.c
@@ -60,7 +60,7 @@
 enum { ColBorder, ColFG, ColBG, ColLast };  /* color */
 enum { NetSupported, NetWMName, NetWMState,
NetWMFullscreen, NetActiveWindow, NetWMWindowType,
-   NetWMWindowTypeDialog, NetLast }; /* EWMH atoms */
+   NetWMWindowTypeDialog, NetClientList, NetLast }; /* EWMH atoms */
 enum { WMProtocols, WMDelete, WMState, WMTakeFocus, WMLast }; /* default atoms 
*/
 enum { ClkTagBar, ClkLtSymbol, ClkStatusText, ClkWinTitle,
ClkClientWin, ClkRootWin, ClkLast }; /* clicks */
@@ -238,6 +238,7 @@
 static Bool updategeom(void);
 static void updatebarpos(Monitor *m);
 static void updatebars(void);
+static void updateclientlist(void);
 static void updatenumlockmask(void);
 static void updatesizehints(Client *c);
 static void updatestatus(void);
@@ -499,6 +500,7 @@
cleanupmon(mons);
XSync(dpy, False);
XSetInputFocus(dpy, PointerRoot, RevertToPointerRoot, CurrentTime);
+   XDeleteProperty(dpy, root, netatom[NetActiveWindow]);
 }
 
 void
@@ -858,8 +860,10 @@
XSetWindowBorder(dpy, c->win, dc.sel[ColBorder]);
setfocus(c);
}
-   else
+   else {
XSetInputFocus(dpy, root, RevertToPointerRoot, CurrentTime);
+   XDeleteProperty(dpy, root, netatom[NetActiveWindow]);
+   }
selmon->sel = c;
drawbars();
 }
@@ -1157,6 +1161,8 @@
XRaiseWindow(dpy, c->win);
attach(c);
attachstack(c);
+   XChangeProperty(dpy, root, netatom[NetClientList], XA_WINDOW, 32, 
PropModeAppend,
+   (unsigned char *) &(c->win), 1);
XMoveResizeWindow(dpy, c->win, c->x + 2 * sw, c->y, c->w, c->h); /* 
some windows require this */
setclientstate(c, NormalState);
if (c->mon == selmon)
@@ -1520,8 +1526,12 @@
 
 void
 setfocus(Client *c) {
-   if(!c->neverfocus)
+   if(!c->neverfocus) {
XSetInputFocus(dpy, c->win, RevertToPointerRoot, CurrentTime);
+   XChangeProperty(dpy, root, netatom[NetActiveWindow],
+   XA_WINDOW, 32, PropModeReplace,
+   (unsigned char *) &(c->win), 1);
+   }
sendevent(c, wmatom[WMTakeFocus]);
 }
 
@@ -1607,6 +1617,7 @@
netatom[NetWMFullscreen] = XInternAtom(dpy, "_NET_WM_STATE_FULLSCREEN", 
False);
netatom[NetWMWindowType] = XInternAtom(dpy, "_NET_WM_WINDOW_TYPE", 
False);
netatom[NetWMWindowTypeDialog] = XInternAtom(dpy, 
"_NET_WM_WINDOW_TYPE_DIALOG", False);
+   netatom[NetClientList] = XInternAtom(dpy, "_NET_CLIENT_LIST", False);
/* init cursors */
cursor[CurNormal] = XCreateFontCursor(dpy, XC_left_ptr);
cursor[CurResize] = XCreateFontCursor(dpy, XC_sizing);
@@ -1629,6 +1640,7 @@
/* EWMH support per view */
XChangeProperty(dpy, root, netatom[NetSupported], XA_ATOM, 32,
PropModeReplace, (unsigned char *) netatom, NetLast);
+   XDeleteProperty(dpy, root, netatom[NetClientList]);
/* select for events */
wa.cursor = cursor[CurNormal];
wa.event_mask = 
SubstructureRedirectMask|SubstructureNotifyMask|ButtonPressMask|PointerMotionMask
@@ -1777,8 +1789,10 @@
return;
grabbuttons(c, False);
XSetWindowBorder(dpy, c->win, dc.norm[ColBorder]);
-   if(setfocus)
+   if(setfocus) {
XSetInputFocus(dpy, root, RevertToPointerRoot, CurrentTime);
+   XDeleteProperty(dpy, root, netatom[NetActiveWindow]);
+   }
 }
 
 void
@@ -1802,6 +1816,7 @@
}
free(c);
focus(NULL);
+   updateclientlist();
arrange(m);
 }
 
@@ -1848,6 +1863,19 @@
m->by = -bh;
 }
 
+void
+updateclientlist() {
+   Client *c;
+   Monitor *m;
+
+   XDeleteProperty(dpy, root, netatom[NetClientList]);
+   for(m = mons; m; m = m->next)
+ 

Re: [dev] [dwm] about _NET_ACTIVE_WINDOW support

[Anselm R Garbe]

On 7 January 2012 21:20, Ivan Kanakarakis  wrote:
> I was going looking through dwm's code cause I've been having problems with
> my own implementation of _NET_ACTIVE_WINDOW support for mosnterwm, and
> noticed some things.
>
> 1) The ewmh standard on _NET_ACTIVE_WINDOW [0] says that:
>
>> [...] This is a read-only property set by the Window Manager. If a Client
>> wants to activate another window, it MUST send a _NET_ACTIVE_WINDOW client
>> message to the root window [...]
>> Depending on the information provided with the message, the Window Manager
>> may decide to refuse the request [...]
>
> dwm, when it receives a _NET_ACTIVE_WINDOW message, it transfers focus to
> the client that asked for it, but never sets the root window id to that
> window's id. That is ofcourse a choice - the standard doesn't force one to
> do that, but that makes tools like xdotool and xprop fail on some options
> that people may find usefull. Specifically the following commands:
>
>     $ xprop -root _NET_ACTIVE_WINDOW
>     $ xdotool getactivewindow
>
> To get those working properly, one would need to,
>
>     XChangeProperty(dpy, root, netatom[NetActiveWindow], XA_WINDOW, 32,
>                     PropModeReplace, (unsigned char *)&c->win, 1);
>
> everytime a new window is focused. I guess that would go into
> setfocus(Client *c) function or something similar.

Good point, I will consider this modification in dwm.

> 2) Apart from that, I get another weird focus(?) problem, that I get with
> dwm and monsterwm too, when I enable the _NET_ACTIVE_WINDOW support. If I go
> back some revisions before _NET_ACTIVE_WINDOW was added to dwm, everything
> seems right.
> It seems some apps (Chromium for me) don't get focused correctly. See
> this[1] to have a picture of what I'm talking about. Chromium, on the left
> and highlighted with the orange border, is supposed to be focused. Although
> it *has* input focus, and all keybinds, actions etc work, it *looks* like
> it's unfocused - the background on top is grey (the color above the green
> area with the tool/mail/bookmarks buttons) - when it should be black (thus
> indicating focus). That makes things like clicking the "star" to save a
> bookmark, not work correctly, as the popup that would ask where to place the
> bookmark, doesn't appear.
>
> Again, this happens on mosnterwm and dwm when _NET_ACTIVE_WINDOW is
> supported. I've tried many different things (eg sending a WM_TAKE_FOCUS
> event explicitly) but nothing seems to work.

Well WM_ shouldn't have any direct effect on the EWMH handling.

I have no idea at this point about your focus issue. My initial
thought when starting dwm development years ago was not supporting
EWMH at all, as it usually leads to all kinds of headaches like the
one you are describing and makes the code base messy. But I will look
into this issue to see if we find a proper solution.

Cheers,
Anselm

Re: [dev] [dwm] about _NET_ACTIVE_WINDOW support

[Anselm R Garbe]

On 8 January 2012 02:03, Andreas Amann  wrote:
> On Sat, Jan 07, 2012 at 10:20:27PM +0200, Ivan Kanakarakis wrote:
>> dwm, when it receives a _NET_ACTIVE_WINDOW message, it transfers focus to
>> the client that asked for it, but never sets the root window id to that
>> window's id. That is ofcourse a choice - the standard doesn't force one to
>> do that, but that makes tools like xdotool and xprop fail on some options
>> that people may find usefull. Specifically the following commands:
>>
>>     $ xprop -root _NET_ACTIVE_WINDOW
>>     $ xdotool getactivewindow
>>
>> To get those working properly, one would need to,
>>
>>     XChangeProperty(dpy, root, netatom[NetActiveWindow], XA_WINDOW, 32,
>>                     PropModeReplace, (unsigned char *)&c->win, 1);
>>
>> everytime a new window is focused. I guess that would go into
>> setfocus(Client *c) function or something similar.
>
> I use the attached patch for this. In addition it also maintains a
> NetClientList, which exposes the list of managed windows in the ewmh
> recommended way.

Which kind of program is using this client list?

Cheers,
Anselm

Re: [dev] [dwm] about _NET_ACTIVE_WINDOW support

[Ivan Kanakarakis]

On 8 January 2012 13:28, Anselm R Garbe  wrote:

> On 7 January 2012 21:20, Ivan Kanakarakis  wrote:
> > I was going looking through dwm's code cause I've been having problems
> with
> > my own implementation of _NET_ACTIVE_WINDOW support for mosnterwm, and
> > noticed some things.
> >
> > 1) The ewmh standard on _NET_ACTIVE_WINDOW [0] says that:
> >
> >> [...] This is a read-only property set by the Window Manager. If a
> Client
> >> wants to activate another window, it MUST send a _NET_ACTIVE_WINDOW
> client
> >> message to the root window [...]
> >> Depending on the information provided with the message, the Window
> Manager
> >> may decide to refuse the request [...]
> >
> > dwm, when it receives a _NET_ACTIVE_WINDOW message, it transfers focus to
> > the client that asked for it, but never sets the root window id to that
> > window's id. That is ofcourse a choice - the standard doesn't force one
> to
> > do that, but that makes tools like xdotool and xprop fail on some options
> > that people may find usefull. Specifically the following commands:
> >
> > $ xprop -root _NET_ACTIVE_WINDOW
> > $ xdotool getactivewindow
> >
> > To get those working properly, one would need to,
> >
> > XChangeProperty(dpy, root, netatom[NetActiveWindow], XA_WINDOW, 32,
> > PropModeReplace, (unsigned char *)&c->win, 1);
> >
> > everytime a new window is focused. I guess that would go into
> > setfocus(Client *c) function or something similar.
>
> Good point, I will consider this modification in dwm.



The patch attached to Andreas responce does that
and also adds support for _NET_CLIENT_LIST

I too do not know where and what uses _NET_CLIENT_LIST




> > 2) Apart from that, I get another weird focus(?) problem, that I get with
> > dwm and monsterwm too, when I enable the _NET_ACTIVE_WINDOW support. If
> I go
> > back some revisions before _NET_ACTIVE_WINDOW was added to dwm,
> everything
> > seems right.
> > It seems some apps (Chromium for me) don't get focused correctly. See
> > this[1] to have a picture of what I'm talking about. Chromium, on the
> left
> > and highlighted with the orange border, is supposed to be focused.
> Although
> > it *has* input focus, and all keybinds, actions etc work, it *looks* like
> > it's unfocused - the background on top is grey (the color above the green
> > area with the tool/mail/bookmarks buttons) - when it should be black
> (thus
> > indicating focus). That makes things like clicking the "star" to save a
> > bookmark, not work correctly, as the popup that would ask where to place
> the
> > bookmark, doesn't appear.
> >
> > Again, this happens on mosnterwm and dwm when _NET_ACTIVE_WINDOW is
> > supported. I've tried many different things (eg sending a WM_TAKE_FOCUS
> > event explicitly) but nothing seems to work.
>
> Well WM_ shouldn't have any direct effect on the EWMH handling.
>
> I have no idea at this point about your focus issue. My initial
> thought when starting dwm development years ago was not supporting
> EWMH at all, as it usually leads to all kinds of headaches like the
> one you are describing and makes the code base messy. But I will look
> into this issue to see if we find a proper solution.
>
>

Thanks, just keep in mind that I've seen this only on chromium (so far)
so it could possibly be something wrong with the app, not the wm.


-- 
*Ivan c00kiemon5ter V Kanakarakis *

Re: [dev] [dwm] about _NET_ACTIVE_WINDOW support

[Andreas Amann]

On Sun, Jan 08, 2012 at 12:29:38PM +0100, Anselm R Garbe wrote:
> On 8 January 2012 02:03, Andreas Amann  wrote:
> >
> > I use the attached patch for this. In addition it also maintains a
> > NetClientList, which exposes the list of managed windows in the ewmh
> > recommended way.
> 
> Which kind of program is using this client list?
> 


The attached shell script for example.  I bind it to Alt-W as a quick and dirty
dmenu based windows selector.  For me the quickest way of finding and
focusing a particular window. 

Google shows quite a couple of other programs which seem to use
NetClientlist, but still I think it is not worth the trouble to support it
in mainline dwm.



Andreas


listwin.sh
Description: Bourne shell script

Re: [dev] [dwm] about _NET_ACTIVE_WINDOW support

[Andreas Amann]

On Sun, Jan 08, 2012 at 01:50:35PM +0200, Ivan Kanakarakis wrote:
> 
> The patch attached to Andreas responce does that
> and also adds support for _NET_CLIENT_LIST

Just to ask, does your other focus problem with Chromium still exist with
that patch applied?

Andreas

Re: [dev] [dwm] about _NET_ACTIVE_WINDOW support

[Ivan Kanakarakis]

On 9 January 2012 01:12, Andreas Amann  wrote:

> On Sun, Jan 08, 2012 at 01:50:35PM +0200, Ivan Kanakarakis wrote:
> >
> > The patch attached to Andreas responce does that
> > and also adds support for _NET_CLIENT_LIST
>
> Just to ask, does your other focus problem with Chromium still exist with
> that patch applied?
>
>
nope, it doesn't



>  Andreas
>
>


-- 
*Ivan c00kiemon5ter V Kanakarakis *
• Personal Blog 

Re: [dev] [dwm] about _NET_ACTIVE_WINDOW support

[Ivan Kanakarakis]

On 9 January 2012 16:34, Ivan Kanakarakis  wrote:

>
>
> On 9 January 2012 01:12, Andreas Amann  wrote:
>
>> On Sun, Jan 08, 2012 at 01:50:35PM +0200, Ivan Kanakarakis wrote:
>> >
>> > The patch attached to Andreas responce does that
>> > and also adds support for _NET_CLIENT_LIST
>>
>> Just to ask, does your other focus problem with Chromium still exist with
>> that patch applied?
>>
>>
> nope, it doesn't
>
>


ow, sorry, cross that out. I misread the question.
Even with the patch applied, the problem is still there.
What I meant was, "nope, it doesn't fix it" .
Sorry for the confusion



>
>
>>  Andreas
>>
>>
>
>
> --
> *Ivan c00kiemon5ter V Kanakarakis *
> • Personal Blog 
>
>


-- 
*Ivan c00kiemon5ter V Kanakarakis *
• Personal Blog 

Re: [dev] [dwm] about _NET_ACTIVE_WINDOW support

[Andreas Amann]

On Mon, Jan 09, 2012 at 04:55:08PM +0200, Ivan Kanakarakis wrote:
> On 9 January 2012 16:34, Ivan Kanakarakis  wrote:
> 
> 
> 
> ow, sorry, cross that out. I misread the question.
> Even with the patch applied, the problem is still there.
> What I meant was, "nope, it doesn't fix it" .
> Sorry for the confusion

just to ask, do you happen to have the command "wmname LG3D" in your startup
script or anything else which changes _NET_WM_NAME?

Apparently that was the culprit in my case.  After taking it out, restarting
X and dwm (with my previous patch applied), the weird focus problem in
chromium has disappeared.

Andreas

Re: [dev] [dwm] about _NET_ACTIVE_WINDOW support

[Ivan Kanakarakis]

On 15 January 2012 00:52, Andreas Amann  wrote:

> On Mon, Jan 09, 2012 at 04:55:08PM +0200, Ivan Kanakarakis wrote:
> > On 9 January 2012 16:34, Ivan Kanakarakis  wrote:
> >
> >
> >
> > ow, sorry, cross that out. I misread the question.
> > Even with the patch applied, the problem is still there.
> > What I meant was, "nope, it doesn't fix it" .
> > Sorry for the confusion
>
> just to ask, do you happen to have the command "wmname LG3D" in your
> startup
> script or anything else which changes _NET_WM_NAME?
>
>
I actually do have "wmname LG3D"
I'm not home right now to test, but I'll report once I'm back

Thanks for the suggestion


> Apparently that was the culprit in my case.  After taking it out,
> restarting
> X and dwm (with my previous patch applied), the weird focus problem in
> chromium has disappeared.
>
> Andreas
>
>
>
>


-- 
*Ivan c00kiemon5ter V Kanakarakis *
• Personal Blog 

Re: [dev] [dwm] about _NET_ACTIVE_WINDOW support

[Anselm R Garbe]

On 15 January 2012 00:26, Ivan Kanakarakis  wrote:
> On 15 January 2012 00:52, Andreas Amann  wrote:
>> just to ask, do you happen to have the command "wmname LG3D" in your
>> startup
>> script or anything else which changes _NET_WM_NAME?
>>
>
> I actually do have "wmname LG3D"
> I'm not home right now to test, but I'll report once I'm back

Bare in mind that the wmname LG3D trick only fixed a bug of the JDK.
It is not related to chromium at all.

Cheers,
Anselm

Re: [dev] [dwm] about _NET_ACTIVE_WINDOW support

[Anselm R Garbe]

On 15 January 2012 07:27, Anselm R Garbe  wrote:
> On 15 January 2012 00:26, Ivan Kanakarakis  wrote:
>> On 15 January 2012 00:52, Andreas Amann  wrote:
>>> just to ask, do you happen to have the command "wmname LG3D" in your
>>> startup
>>> script or anything else which changes _NET_WM_NAME?
>>>
>>
>> I actually do have "wmname LG3D"
>> I'm not home right now to test, but I'll report once I'm back
>
> Bare in mind that the wmname LG3D trick only fixed a bug of the JDK.
> It is not related to chromium at all.

correction: s/fixed/works around/

-Anselm

Re: [dev] [dwm] about _NET_ACTIVE_WINDOW support

[Ivan Kanakarakis]

On 15 January 2012 08:29, Anselm R Garbe  wrote:

> On 15 January 2012 07:27, Anselm R Garbe  wrote:
> > On 15 January 2012 00:26, Ivan Kanakarakis  wrote:
> >> On 15 January 2012 00:52, Andreas Amann 
> wrote:
> >>> just to ask, do you happen to have the command "wmname LG3D" in your
> >>> startup
> >>> script or anything else which changes _NET_WM_NAME?
> >>>
> >>
> >> I actually do have "wmname LG3D"
> >> I'm not home right now to test, but I'll report once I'm back
> >
>


weirdly enough, it worked.
focus seems as it should be and bookmarking works as expected.

Thanks again for the suggestion and everyone taking interest in this.




> > Bare in mind that the wmname LG3D trick only fixed a bug of the JDK.
> > It is not related to chromium at all.
>
> correction: s/fixed/works around/
>
> -Anselm
>
>


-- 
*Ivan c00kiemon5ter V Kanakarakis *
• Personal Blog 

Re: [dev] [dwm] about _NET_ACTIVE_WINDOW support

[Andreas Amann]

On Sun, Jan 15, 2012 at 07:29:13AM +0100, Anselm R Garbe wrote:
> On 15 January 2012 07:27, Anselm R Garbe  wrote:
> > On 15 January 2012 00:26, Ivan Kanakarakis  wrote:
> >> On 15 January 2012 00:52, Andreas Amann  wrote:
> >>> just to ask, do you happen to have the command "wmname LG3D" in your
> >>> startup
> >>> script or anything else which changes _NET_WM_NAME?
> >>>
> >>
> >> I actually do have "wmname LG3D"
> >> I'm not home right now to test, but I'll report once I'm back
> >
> > Bare in mind that the wmname LG3D trick only fixed a bug of the JDK.
> > It is not related to chromium at all.
> 
> correction: s/fixed/works around/

The problem is that Ivan uses wmname to set _NET_WM_NAME to "LG3D". 
Actually chromium does not care about _NET_WM_NAME.  But "wmname" has a
dirty side effect, it sets the _NET_SUPPORTING_WM_CHECK property of the root
window to the window id of the root window.  That is clearly against EWMH
rules and it would be better if wmname would leave _NET_SUPPORTING_WM_CHECK
alone.  I guess Chromium for some reason is smart enough to figure out that
_NET_SUPPORTING_WM_CHECK is not set correctly, and therefore seems to decide
that it cannot trust the wm.  The correct solution is therefore not to use
"wmname".

To address Ivan's other problem with NetActiveWindow, you might consider to
include the attached patch.  It is similar to the patch I sent previously,
but I cut out the NetClientList part.

Andreas

# HG changeset patch
# Parent bbfe55c2f7562ea3e428d4c7cbd1d8da0c32f02f

diff --git a/dwm.c b/dwm.c
--- a/dwm.c
+++ b/dwm.c
@@ -499,6 +500,7 @@
cleanupmon(mons);
XSync(dpy, False);
XSetInputFocus(dpy, PointerRoot, RevertToPointerRoot, CurrentTime);
+   XDeleteProperty(dpy, root, netatom[NetActiveWindow]);
 }
 
 void
@@ -858,8 +860,10 @@
XSetWindowBorder(dpy, c->win, dc.sel[ColBorder]);
setfocus(c);
}
-   else
+   else {
XSetInputFocus(dpy, root, RevertToPointerRoot, CurrentTime);
+   XDeleteProperty(dpy, root, netatom[NetActiveWindow]);
+   }
selmon->sel = c;
drawbars();
 }
@@ -1520,8 +1526,12 @@
 
 void
 setfocus(Client *c) {
-   if(!c->neverfocus)
+   if(!c->neverfocus) {
XSetInputFocus(dpy, c->win, RevertToPointerRoot, CurrentTime);
+   XChangeProperty(dpy, root, netatom[NetActiveWindow],
+   XA_WINDOW, 32, PropModeReplace,
+   (unsigned char *) &(c->win), 1);
+   }
sendevent(c, wmatom[WMTakeFocus]);
 }
 
@@ -1777,8 +1789,10 @@
return;
grabbuttons(c, False);
XSetWindowBorder(dpy, c->win, dc.norm[ColBorder]);
-   if(setfocus)
+   if(setfocus) {
XSetInputFocus(dpy, root, RevertToPointerRoot, CurrentTime);
+   XDeleteProperty(dpy, root, netatom[NetActiveWindow]);
+   }
 }
 
 void

Re: [dev] [dwm] about _NET_ACTIVE_WINDOW support

[Bjartur Thorlacius]

Þann sun 15.jan 2012 18:09, skrifaði Andreas Amann:


The problem is that Ivan uses wmname to set _NET_WM_NAME to "LG3D".
Actually chromium does not care about _NET_WM_NAME.  But "wmname" has a
dirty side effect, it sets the _NET_SUPPORTING_WM_CHECK property of the root
window to the window id of the root window.  That is clearly against EWMH
rules and it would be better if wmname would leave _NET_SUPPORTING_WM_CHECK
alone.  I guess Chromium for some reason is smart enough to figure out that
_NET_SUPPORTING_WM_CHECK is not set correctly, and therefore seems to decide
that it cannot trust the wm.  The correct solution is therefore not to use
"wmname".
   

Should we not patch wmname?

Re: [dev] [dwm] about _NET_ACTIVE_WINDOW support

[Andreas Amann]

On Sun, Jan 15, 2012 at 06:18:03PM +, Bjartur Thorlacius wrote:
> Should we not patch wmname?
> 

As wmname is a hack for broken apps, they will probably break if you
try to fix it. 

If you only need to set _NET_WM_NAME, you can also try
xprop -root -f _NET_WM_NAME 8s -set _NET_WM_NAME "LG3D"