[Xcb] Tiny cleanup patch that removes some code duplication

Henning Sten henning.sten at yahoo.com
Sat Sep 20 05:32:11 PDT 2008


--- On Mon, 9/15/08, Barton C Massey <bart at cs.pdx.edu> wrote:
> Would strongly prefer, though, a patch to util/icccm to
> extend xcb_set_wm_name() to take an optional UTF8 second
> string, and to set both the WM_NAME and _NET_WM_NAME
> properties accordingly.  Any chance we could get that out
> of you instead?  Then we could get flames.c back to just
> calling into util/icccm...
> 
> Others here OK with modifying xcb_set_wm_name() in such a
> fashion?  I don't think there's so much code out
> there using
> it yet...

How about adding a mandatory "char* net_wm_name_utf8" parameter and making the WM_NAME parameter and encoding parameter optional instead?

Are there any currently known users / programs / use cases that require plain WM_NAME instead of _NET_WM_NAME?

Would it be possible to just consider WM_NAME to be a legacy thing and then set only _NET_WM_NAME? Do we know any programs that would break from doing this? As far as I understand almost all window managers implement at least basic EWMH like _NET_WM_NAME?

I also wonder about; isn't WM_NAME a ICCCM thing while _NET_WM_NAME is a EWMH thing? If so, does it really make sense to start to mix EWMH concepts into the xcb-util/icccm directory? Or should this directory be renamed into xcb-util/wmhints or xcb-util/icccm_ewmh or similar? Would it be better to create xcb-util/ewmh directory next to the xcb-util/icccm? This might lead to quasi similar code to two places though.

Even after browsing around the EWMH/ICCCM specs and wikipedia etc, I'm still a little bit confused about these specs. For example:

* Is EWMH only an extension to ICCCM or is it a replacement for ICCCM?
* Currently most programs show duplicate properties in xprop (i.e. both WM_NAME and _NET_WM_NAME etc). Is it planned to stop having duplicate properties eventually? What is holding this back?



HS


      



More information about the Xcb mailing list