This ebuild disables unicode support in wxGTK-2.4.0 so that lmule-1.2.x can be compiled with GTK2. Ebuild found on www.lmule.org Reproducible: Always Steps to Reproduce:
Created attachment 11259 [details] wxGTK-2.4.0 without unicode This ebuild install wxGTK-2.4.0 without (the buggy) unicode support to let lmule 1.2.x install in a GTK2 environment (as GNOME2).
Created attachment 11260 [details] wxGTK-2.4.0 without unicode This ebuild install wxGTK-2.4.0 without (the buggy) unicode support to let lmule 1.2.x install in a GTK2 environment (as GNOME2).
Created attachment 11261 [details] wxGTK-2.4.0 without unicode This ebuild install wxGTK-2.4.0 without (the buggy) unicode support to let lmule 1.2.x install in a GTK2 environment (as GNOME2). Ebuild found on www.lmule.org
Sorry for the triple post.
i'm pondering whether this is a good thing or not. gtk2 natively uses utf-8, which is unicode. so if we disable unicode support, then some other things might break like accented characters or cjk.
This is a good point. The problem is that at this moment lmule gives an error in compilation if there is GTK2 installed, and the only solution is to disable unicode support in wxGTK. I would leave this ebuild here for everyone who wants to use lmule with GNOME2, hoping that next releases of either lmule and wxGTK will address this incompatibility.
alright. i've finally caved in to disabling unicode on wxGTK. the ebuild in portage now has it disabled. i've also fixed up the lmule ebuild to actually not barf on gtk2 ..
Is the broken Unicode support in lmule still an issue? www.lmule.org redirects to http://www.bit-torrent.org/ and the Portage tree does not contain an lmule ebuild either. On the other hand, wxPython breaks in a UTF-8 locale if wxWindows is compiled without unicode support.
lmule has changed name and it's in the portage tree as xMule: http:///www.xmule.org And yes, the UTF-8 issue isn't resolved yet. You can add UTF-8 support in wxWindows passing a local configure option when emerging it.
Is this serious ????? Come on. this is a problem with the programs not with wxWindows. Some people actually like to use unicode. It's the future. If apps don't support it than either they should support it, or they have to go. It's developers not spending the effort to fix their application. As a developer i know you don't always have time to do stuff like that, but that's their problem hardly gentoo's. I like unicode. I use it in my apps. and it should be standard troughout gentoo.
If you need unicode support in wxGTK you can simply pass --enable-unicode to "emerge wxGTK" (or edit the ebuild and uncomment the line where the option is enabled). This option is disabled by default because there are too many wxWindows apps that don't support unicode and don't work with it. I like unicode too and you are perfectly right when you say that the problem is in the programs, but I suppose that, as users, we prefer more working applications than a GUI toolkit with all its functions enabled by default.
the unicode useflag is available as an option on the wxGTK ebuild. it works well with poedit and vlc, and also allegedly with audacity. but there are still many packages that don't have the support for unicode. nevertheless, it is up to users to enable/disable unicode support. by default, it is off.
