] >Date Index
Re: [wmx] antialiased fonts, Subversion, etcChris Cannam
- Mon Feb 18 16:50:32 2008
At the moment I'm using Gmail as a mail aggregator and client, but this list
actually rejects email from it ("Client host [188.8.131.52] 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 <email@example.com> 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:
> 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