COMPOUND_TEXT versus UTF8_STRING

[Havoc Pennington]

On Wed, 2004-09-22 at 23:47 +0200, Roland Mainz wrote:
> Keith Packard wrote:
> > > This will likely require at least to depreciate some libX11 API, add new
> > > ones which accept UTF-8 and a bump of the major shared library version
> > > number of libX11... ;-(
> > 
> > No.  Nothing needs to change in libX11 -- the EWMH are well supported in
> > existing toolkits and window managers.
> 
> There are functions in libX11 and extensions libraries which cannot be
> changed. That's why you have to bump libX11's shared library version
> number and those of the extensions - and maybe even a new revision of
> the wire protocol of the extensions is required, too.

That's crazy. Everything already works today. Why would you cause all
this pain?

Apps using Xlib directly without a modern toolkit are legacy apps, and
expecting them to have modern features is wrong. The priority is to keep
them from breaking, and that means minimal change to the semantics of
the underlying library.

For modern apps, Xlib is just a backend to the relatively small number
of full-featured toolkits (Swing, Qt, GTK+ more or less). So expecting a
fair bit of intelligence in the toolkit outside of Xlib is just fine.
For example gtk_window_set_title() is quite capable of setting both
WM_NAME and _NET_WM_NAME, and it already does. That means that GTK+ apps
work great with both twm and modern window managers.

Apps using Xlib only also still work with both old and new window
managers with the WM_NAME/_NET_WM_NAME scheme. So what problem is solved
by changing this scheme? Everything works just fine as it is.

The trend for Xlib should be shrinking it and dumbing it down to just a
protocol wrapper. The toolkits have higher-level context and are the
place most intelligence should live.

Havoc