Re: [wmx] antialiased fonts, Subversion, etc

At the moment I'm using Gmail as a mail aggregator and client, but this list 
actually rejects email from it ("Client host [64.233.166.177] blocked using 
spam.dnsbl.sorbs.net").  That's a bit annoying; I can work around it, but it 
does explain why this mail will look like a new thread instead of having the 
proper reply headers.

Since my last post I've done a little work on the netwm (formerly GNOME) 
compliance branch -- available via Subversion at

 svn co http://wm2.svn.sourceforge.net/svnroot/wm2/branches/wmx-netwm

I am actually running this daily now, using the KDE panel and desktop at work 
and GNOME panel and desktop at home, so if you want to try it out you can 
probably expect it not to fail too hard, too often.  There are many bugs and 
infelicities, but I hope it'll improve at a reasonable rate now.  There's a 
TODO file in the root directory which I make notes in.  At this stage it 
might not be worth reporting bugs in this branch unless they are crashes or 
regressions -- as I am only using the wm with fancy desktop accessories at 
the moment, I might not notice regressions that happen when using it without.

I wonder whether I should also configure the SourceForge Subversion repository 
to send commit notices to this list?  Would that be appreciated, or would it 
disturb the pleasantly close-to-zero traffic level of this list too much?

On 15/12/2007, Alexandros Diamantidis <adia@hellug.gr> wrote:
> I thought this would allow non-ascii window titles and menu items, and
> indeed non-ascii menu items appear fine, but window titles still appear
> as "incognito" if they contain greek characters. If they only have
> latin-1 characters, they are cut-off at the first non-ascii character.

Yes, it's not quite clear to me yet why this is happening -- I'd like to take 
the time to look into it properly, but I haven't yet.

For Latin-1 names, on this machine the property from the window appears to be 
an XA_STRING 8-bit with Latin-1 in it, even though my system is natively 
UTF-8, so mapping from UTF-8 isn't the answer -- seems you do need to know 
what the original encoding is, not just work with UTF-8 throughout.

> I've found the patches by Richard Sharman and Roland Renaud described
> here very useful:
>
> http://ml.42.org/wmx/msg00705.html
>
> Would it be easy to integrate them? The link in the message above
> doesn't seem to work any more, but I have the patches in case the
> developers are no longer here.

I don't have copies of these patches and there doesn't seem to have been any 
other response to your post, so if you can send me copies I could take a 
look.


Chris