Hi all,
I opened bug 30255 [1](which, unfortunately, was just marked duplicate as bug 19263 [2]), which I believe is a long-standing issue. Simply put, uxthemes has some performance problems, and consequently UI rendering with theming enabled would lag a lot. Since I'm also planning for GSoC, I would like make that my GSoC proposal and fix the bug myself. Also, there are failing tests regarding dlls/uxtheme - running dlls/uxtheme/tests/uxtheme_test.exe.so gives 11 failures out of a total of 56 executed tests. I can try to fix that too. With all of these, this may still be a trivial proposal. To make it less trivial :), I would also like to work on the gtk+ theming bridge [3], once the performance issue is fixed.
I also have another alternative proposal, i.e. to implement full IME support so that Windows IMEs can be used on Linux. That would consists of basically two parts - the Win32 API (which, after a brief inspection, seems to be at least partly implemented) to handle the Windows part and a daemon to handle the Linux part (half like win32's ctfmon.exe and half like ibus-daemon). But I haven't investigated much into that yet, so I don't have much to say. Still, your suggestions are very welcome.
And a few words about myself: I have been one of the primary maintainers of simplified Chinese translation of Wine during the past few years - so I have already got my name into AUTHORS ;-). I know quite some C - read K&R thoroughly, plus experience in a few small projects; I also know the Git workflow well. I'd love to help fix bug 10000 so that Unix can take over the world ;-).
Your suggestions and ideas are very welcome.
1. http://bugs.winehq.org/show_bug.cgi?id=30255 2. http://bugs.winehq.org/show_bug.cgi?id=19263 3. http://wiki.winehq.org/ThemingSupport
On Sat, Mar 24, 2012 at 5:06 PM, Cheer Xiao xiaqqaix@gmail.com wrote:
Hi all,
I opened bug 30255 [1](which, unfortunately, was just marked duplicate as bug 19263 [2]), which I believe is a long-standing issue. Simply put, uxthemes has some performance problems, and consequently UI rendering with theming enabled would lag a lot. Since I'm also planning for GSoC, I would like make that my GSoC proposal and fix the bug myself. Also, there are failing tests regarding dlls/uxtheme - running dlls/uxtheme/tests/uxtheme_test.exe.so gives 11 failures out of a total of 56 executed tests. I can try to fix that too. With all of these, this may still be a trivial proposal. To make it less trivial :), I would also like to work on the gtk+ theming bridge [3], once the performance issue is fixed.
I also have another alternative proposal, i.e. to implement full IME support so that Windows IMEs can be used on Linux. That would consists of basically two parts - the Win32 API (which, after a brief inspection, seems to be at least partly implemented) to handle the Windows part and a daemon to handle the Linux part (half like win32's ctfmon.exe and half like ibus-daemon). But I haven't investigated much into that yet, so I don't have much to say. Still, your suggestions are very welcome.
And a few words about myself: I have been one of the primary maintainers of simplified Chinese translation of Wine during the past few years - so I have already got my name into AUTHORS ;-). I know quite some C - read K&R thoroughly, plus experience in a few small projects; I also know the Git workflow well. I'd love to help fix bug 10000 so that Unix can take over the world ;-).
Your suggestions and ideas are very welcome.
- http://bugs.winehq.org/show_bug.cgi?id=30255
- http://bugs.winehq.org/show_bug.cgi?id=19263
- http://wiki.winehq.org/ThemingSupport
-- Regards, Cheer Xiao aka. xiaq
Welcome, hope to see you in gsoc :)
UXTheme came up in another thread recently. While I'm not familiar with the code, I don't think Wine is anywhere near ready to have a theming bridge. Work on theming in general gets an immense +1 from me though, but my vote won't matter here :)
J. Leclanche
On 3/24/2012 20:06, Cheer Xiao wrote:
Hi all,
I opened bug 30255 [1](which, unfortunately, was just marked duplicate as bug 19263 [2]), which I believe is a long-standing issue. Simply put, uxthemes has some performance problems, and consequently UI rendering with theming enabled would lag a lot. Since I'm also planning for GSoC, I would like make that my GSoC proposal and fix the bug myself. Also, there are failing tests regarding dlls/uxtheme - running dlls/uxtheme/tests/uxtheme_test.exe.so gives 11 failures out of a total of 56 executed tests. I can try to fix that too. With all of these, this may still be a trivial proposal. To make it less trivial :), I would also like to work on the gtk+ theming bridge [3], once the performance issue is fixed.
Well, fixing performance problems with enabled themes doesn't sound like a project to me, it's more like general bug fixing, writing test applications/tests etc., and it's not necessary that it's only uxtheme being a problem here.
As I said in another thread regarding this, first step is to implement comctl32/user32 model that is live since Win XP, that is a real task and performance issues are also important of course but fixing them before doesn't make much sense.
Regarding GTK+ integration, it's probably possible to get some key parts of current theme and use that data for a kind of Windows theme created on startup or something like that. The problem could be in different GTK+ versions for example. And again, what about Qt-based DEs or any others?
I think that first of all we need a proper theme implementation plus some themes shipped by distro maintainers to mimic default distro DE theme or some more or less neutral version of it.
2012/3/25 Nikolay Sivov bunglehead@gmail.com:
On 3/24/2012 20:06, Cheer Xiao wrote:
Hi all,
I opened bug 30255 [1](which, unfortunately, was just marked duplicate as bug 19263 [2]), which I believe is a long-standing issue. Simply put, uxthemes has some performance problems, and consequently UI rendering with theming enabled would lag a lot. Since I'm also planning for GSoC, I would like make that my GSoC proposal and fix the bug myself. Also, there are failing tests regarding dlls/uxtheme - running dlls/uxtheme/tests/uxtheme_test.exe.so gives 11 failures out of a total of 56 executed tests. I can try to fix that too. With all of these, this may still be a trivial proposal. To make it less trivial :), I would also like to work on the gtk+ theming bridge [3], once the performance issue is fixed.
Well, fixing performance problems with enabled themes doesn't sound like a project to me, it's more like general bug fixing, writing test applications/tests etc., and it's not necessary that it's only uxtheme being a problem here.
As I said in another thread regarding this, first step is to implement comctl32/user32 model that is live since Win XP, that is a real task and performance issues are also important of course but fixing them before doesn't make much sense.
Regarding GTK+ integration, it's probably possible to get some key parts of current theme and use that data for a kind of Windows theme created on startup or something like that. The problem could be in different GTK+ versions for example. And again, what about Qt-based DEs or any others?
I think that first of all we need a proper theme implementation plus some themes shipped by distro maintainers to mimic default distro DE theme or some more or less neutral version of it.
So according to you and the thread Jerome mentioned, uxtheme is one of the more tricky and less rewarding areas; so I will set it aside for the moment and work on the IME proposal instead.
I'll study the code before asking more about it, but I'd also like to hear your ideas and suggestions, like the status of wine's IME API, an estimation of difficulty of the task, etc. If this again is not ideal for a GSoC project, I'll turn to other areas (I have more alternative proposals).
--- On Sun, 25/3/12, Cheer Xiao xiaqqaix@gmail.com wrote:
<snipped>
So according to you and the thread Jerome mentioned, uxtheme is one of the more tricky and less rewarding areas; so I will set it aside for the moment and work on the IME proposal instead.
<snipped>
There is no reason why you cannot submit two proposals, if you are interested in two areas. You do not get penalized for doing that, other than your own time of preparing two proposals, which is twice the preparation work.
In fact it is quite common for GSoC students to apply for more than one project under different/same organization.
From the organization's point of view, it may be a good decision to give the project to the strongest candidate if there are multiple students applying to the same area; or not to take up any student for lack of interests (from mentors); in which case you might be still be taken up and assigned to your "2nd" choice project.
(poor applications - showing no understandings of the background technology, etc - are rejected, so in that sense you are penalized if you cannot devote enough time to your proposal(s), if you divide your efforts).
Hi,
As a developer who has done a lot of work in the IME/XIM areas of wine I thought I would chime in.
The IME/XIM stuff sounds interesting but I am really not sure how useful it is going to be. I will have to review what the GSoC outline is like but it feels like something that would not really get into wine not would regularly get used by people outside of wine. If you want to flesh it out a bit more I could maybe see where you are going with it but it feels more like a project "Making use of Wine" instead of "Improving Wine"
This is not a discouragement, just an invitation to sell it to me more. Make me see why you think this would be good for IME in Wine.
-aric
On 3/24/12 9:51 PM, Cheer Xiao wrote:
2012/3/25 Nikolay Sivovbunglehead@gmail.com:
On 3/24/2012 20:06, Cheer Xiao wrote:
Hi all,
I opened bug 30255 [1](which, unfortunately, was just marked duplicate as bug 19263 [2]), which I believe is a long-standing issue. Simply put, uxthemes has some performance problems, and consequently UI rendering with theming enabled would lag a lot. Since I'm also planning for GSoC, I would like make that my GSoC proposal and fix the bug myself. Also, there are failing tests regarding dlls/uxtheme - running dlls/uxtheme/tests/uxtheme_test.exe.so gives 11 failures out of a total of 56 executed tests. I can try to fix that too. With all of these, this may still be a trivial proposal. To make it less trivial :), I would also like to work on the gtk+ theming bridge [3], once the performance issue is fixed.
Well, fixing performance problems with enabled themes doesn't sound like a project to me, it's more like general bug fixing, writing test applications/tests etc., and it's not necessary that it's only uxtheme being a problem here.
As I said in another thread regarding this, first step is to implement comctl32/user32 model that is live since Win XP, that is a real task and performance issues are also important of course but fixing them before doesn't make much sense.
Regarding GTK+ integration, it's probably possible to get some key parts of current theme and use that data for a kind of Windows theme created on startup or something like that. The problem could be in different GTK+ versions for example. And again, what about Qt-based DEs or any others?
I think that first of all we need a proper theme implementation plus some themes shipped by distro maintainers to mimic default distro DE theme or some more or less neutral version of it.
So according to you and the thread Jerome mentioned, uxtheme is one of the more tricky and less rewarding areas; so I will set it aside for the moment and work on the IME proposal instead.
I'll study the code before asking more about it, but I'd also like to hear your ideas and suggestions, like the status of wine's IME API, an estimation of difficulty of the task, etc. If this again is not ideal for a GSoC project, I'll turn to other areas (I have more alternative proposals).
Hi,
On Sun, Mar 25, 2012 at 10:30 PM, Aric Stewart aric@codeweavers.com wrote:
Hi,
As a developer who has done a lot of work in the IME/XIM areas of wine I thought I would chime in.
The IME/XIM stuff sounds interesting but I am really not sure how useful it is going to be. I will have to review what the GSoC outline is like but it feels like something that would not really get into wine not would regularly get used by people outside of wine. If you want to flesh it out a bit more I could maybe see where you are going with it but it feels more like a project "Making use of Wine" instead of "Improving Wine"
This is not a discouragement, just an invitation to sell it to me more. Make me see why you think this would be good for IME in Wine.
IMO using win32 IME on Linux is necessary for some people. In fact even most Chinese users don't know how many Chinese IMEs there exist, some of them have no alternative at all. Also, some handwriting input method editors and some speech-to-text input method editors have no alternative on Linux. Another reason to implement win32 IME bridge is, some win32 IME, such as sogou pinyin, google pinyin, are much better than there alternative on Linux ( ibus-pinyin, sunpinyin), maybe it is hard to understanded by non Chinese users...
On 25 March 2012 16:49, Qian Hong fracting@gmail.com wrote:
IMO using win32 IME on Linux is necessary for some people. In fact even most Chinese users don't know how many Chinese IMEs there exist, some of them have no alternative at all. Also, some handwriting input method editors and some speech-to-text input method editors have no alternative on Linux. Another reason to implement win32 IME bridge is, some win32 IME, such as sogou pinyin, google pinyin, are much better than there alternative on Linux ( ibus-pinyin, sunpinyin), maybe it is hard to understanded by non Chinese users...
I'm sure that's all true, but why would making Win32 input methods run through Wine be a better (or even easier) solution than improving the Linux/X11 input methods?
On Sun, Mar 25, 2012 at 11:02 PM, Henri Verbeet hverbeet@gmail.com wrote:
On 25 March 2012 16:49, Qian Hong fracting@gmail.com wrote:
IMO using win32 IME on Linux is necessary for some people. In fact even most Chinese users don't know how many Chinese IMEs there exist, some of them have no alternative at all. Also, some handwriting input method editors and some speech-to-text input method editors have no alternative on Linux. Another reason to implement win32 IME bridge is, some win32 IME, such as sogou pinyin, google pinyin, are much better than there alternative on Linux ( ibus-pinyin, sunpinyin), maybe it is hard to understanded by non Chinese users...
I'm sure that's all true, but why would making Win32 input methods run through Wine be a better (or even easier) solution than improving the Linux/X11 input methods?
Yeah, good question :)
Some reasons I know: - Some win32 input method using copyrighted input method tables, for those IME, we can't develop an alternative until the copyright is expired. - For speech-to-text input method, there are many different dialects in China, some of them are already pretty well handled by some commercial software, in theoretic we can develop alternative for them, but it takes some time, maybe that will not happen in near feature, before the chicken-and-egg problem is solved :) - For sogou pinyin and other IMEs using "Statistical language model", the quality of the IME depends on not only the algorithm but also the thesaurus and corpus, currently the best open source SLM input method -- sunpinyin, has a good algorithm, but we have no any good thesaurus at all. Google and sogou use there web search engine as a source of thesaurus and corpus, new words are generated day by day, sogou and google collect them to there input method frequently. It is really hard to do the same thing for a non-profit open source project.
2012/3/25 Henri Verbeet hverbeet@gmail.com:
On 25 March 2012 16:49, Qian Hong fracting@gmail.com wrote:
IMO using win32 IME on Linux is necessary for some people. In fact even most Chinese users don't know how many Chinese IMEs there exist, some of them have no alternative at all. Also, some handwriting input method editors and some speech-to-text input method editors have no alternative on Linux. Another reason to implement win32 IME bridge is, some win32 IME, such as sogou pinyin, google pinyin, are much better than there alternative on Linux ( ibus-pinyin, sunpinyin), maybe it is hard to understanded by non Chinese users...
I'm sure that's all true, but why would making Win32 input methods run through Wine be a better (or even easier) solution than improving the Linux/X11 input methods?
(I'm talking about Chinese, but the same is true for Japanese.)
Because developing a decent pinyin (it's a romanization scheme of Chinese; see my previous mail) IME is very hard. Yes, there are alternative input methods that is easier to implement, but the majority of the population won't bother to learn. Determined by the complexity of Chinese grammar, a decent pinyin IME would require a large corpse of vocabulary, driven by some statistical algorithm. There is ongoing efforts like open-phrase[1] to create an open source corpse database, but so far the commercial ones shipped with freeware Windows IMEs are still considerably better. To make things even harder for free software IME developers, contemporary Chinese is characterized by a rapidly changing vocabulary, thus phrase libraries become quickly outdated; freeware Windows IMEs typically updates their databases on a daily basis. The updates to databases are authored manually; data mining technology hasn't gone so far yet.
The large corpse and the frequent manual updates to databases would require commercial* support, and there hasn't been any companies willing to fund the development of a pinyin IME on Unix-like platforms.
I won't be able to come up with a bunch of citations to convince you - that will be all Chinese. If you can read Chinese, you most likely already understand the situation.
1. http://code.google.com/p/open-phrase/
* Or academia. But situation there is even worse - Chinese academies are almost stuck with Windows.
Cheer Xiao wrote: <snipped>
I'm sure that's all true, but why would making Win32 input methods run through Wine be a better (or even easier) solution than improving the Linux/X11 input methods?
(I'm talking about Chinese, but the same is true for Japanese.)
Because developing a decent pinyin (it's a romanization scheme of Chinese; see my previous mail) IME is very hard. Yes, there are alternative input methods that is easier to implement, but the majority of the population won't bother to learn. Determined by the complexity of Chinese grammar, a decent pinyin IME would require a large corpse of vocabulary, driven by some statistical algorithm.
<snipped>
I think you are describing the situation wrongly, in quite a few ways. Implementing pinyin *itself* is trivial - there is a standard-ish pronounciation, etc, and is completely table-driven. That's how most of Linux/X11's Chinese input method, especially pinyin, works.
What you are describing is the desirability of predictive and phrasal input methods in general, where the computer can anticipate and guess your intention as you type.
For what it is worth, you are forgetting two entire "areas" of people. Taiwan/Hong Kong had always been far more computer-literate than Mainland, so your "80% won't bother to learn another" is a gross mis-statement in both quantity and quality. Due to different dialects and other reasons, Cangjie (rather than Pinyin) had been far more popular with Chinese users. But even with Cangjie (which is shape/writing-based, rather than sound-based, thus getting around the dialect problem), predictive and phrasal input methods are desirable.
Over 10 years ago, I had some on-line discussion on emacs-devel, with Mr RMS no less, about my continued interests and compiler problems with emacs 19 (?) despite emacs 21 being around, which had mule [multi-lingual extension] newly added (or some issue of that vintage). The reason was that I could run emacs 19 inside cxterm (a chinese x terminal). Now the curious thing is that emacs actually took *all* the input methods from cxterm! So Pinyin/Cangjie themselves worked 10+ years ago identically under emacs 19 + cxterm, and emacs 21 mule.
What emacs did not, and still does not, implement, which cxterm did even almost 20 years ago, was predictive and phrasal inputs and also fuzzy inputs. i.e. you can type "a?b", and get the list of "a[a-z]b". That was something done almost 20 years ago which is still missing in many of the modern Chinese X11 input mechanisms.
(I have a confession to make - cxterm was orphaned for many years, and I and a few others are who kept it going-ish, in recent years, for what little needs to be done).
2012/3/26 Hin-Tak Leung htl10@users.sourceforge.net:
Cheer Xiao wrote:
<snipped>
I'm sure that's all true, but why would making Win32 input methods run through Wine be a better (or even easier) solution than improving the Linux/X11 input methods?
(I'm talking about Chinese, but the same is true for Japanese.)
Because developing a decent pinyin (it's a romanization scheme of Chinese; see my previous mail) IME is very hard. Yes, there are alternative input methods that is easier to implement, but the majority of the population won't bother to learn. Determined by the complexity of Chinese grammar, a decent pinyin IME would require a large corpse of vocabulary, driven by some statistical algorithm.
<snipped>
I think you are describing the situation wrongly, in quite a few ways. Implementing pinyin *itself* is trivial - there is a standard-ish pronounciation, etc, and is completely table-driven. That's how most of Linux/X11's Chinese input method, especially pinyin, works.
What you are describing is the desirability of predictive and phrasal input methods in general, where the computer can anticipate and guess your intention as you type.
We only disagree in the definition of what a "decent" IME is. By decent I meant a decent phrasal or sentence IME. Because given the large amount of homophones in Chinese a bare pinyin IME is barely usable.
For what it is worth, you are forgetting two entire "areas" of people. Taiwan/Hong Kong had always been far more computer-literate than Mainland, so your "80% won't bother to learn another" is a gross mis-statement in both quantity and quality. Due to different dialects and other reasons, Cangjie (rather than Pinyin) had been far more popular with Chinese users. But even with Cangjie (which is shape/writing-based, rather than sound-based, thus getting around the dialect problem), predictive and phrasal input methods are desirable.
I declared that I was talking about the situation in mainland China in the beginning - I should have emphasized that along the way. But by declaring Cangjie is far more popular, you are ignoring the mass majority of people in mainland China. Again, I won't be able to convince you that the majority won't bother to learn another IME, even in highly computer-literate places like CS departments in universities. Arguing about facts is plainly meaningless.
Over 10 years ago, I had some on-line discussion on emacs-devel, with Mr RMS no less, about my continued interests and compiler problems with emacs 19 (?) despite emacs 21 being around, which had mule [multi-lingual extension] newly added (or some issue of that vintage). The reason was that I could run emacs 19 inside cxterm (a chinese x terminal). Now the curious thing is that emacs actually took *all* the input methods from cxterm! So Pinyin/Cangjie themselves worked 10+ years ago identically under emacs 19 + cxterm, and emacs 21 mule.
Yes, but "just works" is not the same thing as "usable".
What emacs did not, and still does not, implement, which cxterm did even almost 20 years ago, was predictive and phrasal inputs and also fuzzy inputs. i.e. you can type "a?b", and get the list of "a[a-z]b". That was something done almost 20 years ago which is still missing in many of the modern Chinese X11 input mechanisms.
(I have a confession to make - cxterm was orphaned for many years, and I and a few others are who kept it going-ish, in recent years, for what little needs to be done).
Hi,
Not to argue if it will be useful or not, as I do not know. I think this will be technically very hard. You will have to be able to get the keystrokes for a native linux applications feed them into WINE, have wine do the IME processing and then get the resulting characters and feed them back into the native linux application. This pipeline is not trivial.
Additionally, you have not explained how this will benefit WINE. I can forsee none of the above pipeline being accepted into or applicable to WINE presently, at lest in theory, i have done work that allows native XIM clients to be able to work in wines IME framework, so if a user really wants to use windows XIM in wine they should work. The setup is tricky but in all my years of working on wine IME i have never heard of a user wanting that. Almost all requests are to make the Linux/Mac Input Methods work better in WINE.
I would love to have you work on improving IME and XIM integration in WINE, but i think the main goal of the project is pretty tangential to wine.
-aric
On 3/25/12 10:48 PM, Cheer Xiao wrote:
2012/3/26 Hin-Tak Leunghtl10@users.sourceforge.net:
Cheer Xiao wrote:
<snipped>
I'm sure that's all true, but why would making Win32 input methods run through Wine be a better (or even easier) solution than improving the Linux/X11 input methods?
(I'm talking about Chinese, but the same is true for Japanese.)
Because developing a decent pinyin (it's a romanization scheme of Chinese; see my previous mail) IME is very hard. Yes, there are alternative input methods that is easier to implement, but the majority of the population won't bother to learn. Determined by the complexity of Chinese grammar, a decent pinyin IME would require a large corpse of vocabulary, driven by some statistical algorithm.
<snipped>
I think you are describing the situation wrongly, in quite a few ways. Implementing pinyin *itself* is trivial - there is a standard-ish pronounciation, etc, and is completely table-driven. That's how most of Linux/X11's Chinese input method, especially pinyin, works.
What you are describing is the desirability of predictive and phrasal input methods in general, where the computer can anticipate and guess your intention as you type.
We only disagree in the definition of what a "decent" IME is. By decent I meant a decent phrasal or sentence IME. Because given the large amount of homophones in Chinese a bare pinyin IME is barely usable.
For what it is worth, you are forgetting two entire "areas" of people. Taiwan/Hong Kong had always been far more computer-literate than Mainland, so your "80% won't bother to learn another" is a gross mis-statement in both quantity and quality. Due to different dialects and other reasons, Cangjie (rather than Pinyin) had been far more popular with Chinese users. But even with Cangjie (which is shape/writing-based, rather than sound-based, thus getting around the dialect problem), predictive and phrasal input methods are desirable.
I declared that I was talking about the situation in mainland China in the beginning - I should have emphasized that along the way. But by declaring Cangjie is far more popular, you are ignoring the mass majority of people in mainland China. Again, I won't be able to convince you that the majority won't bother to learn another IME, even in highly computer-literate places like CS departments in universities. Arguing about facts is plainly meaningless.
Over 10 years ago, I had some on-line discussion on emacs-devel, with Mr RMS no less, about my continued interests and compiler problems with emacs 19 (?) despite emacs 21 being around, which had mule [multi-lingual extension] newly added (or some issue of that vintage). The reason was that I could run emacs 19 inside cxterm (a chinese x terminal). Now the curious thing is that emacs actually took *all* the input methods from cxterm! So Pinyin/Cangjie themselves worked 10+ years ago identically under emacs 19 + cxterm, and emacs 21 mule.
Yes, but "just works" is not the same thing as "usable".
What emacs did not, and still does not, implement, which cxterm did even almost 20 years ago, was predictive and phrasal inputs and also fuzzy inputs. i.e. you can type "a?b", and get the list of "a[a-z]b". That was something done almost 20 years ago which is still missing in many of the modern Chinese X11 input mechanisms.
(I have a confession to make - cxterm was orphaned for many years, and I and a few others are who kept it going-ish, in recent years, for what little needs to be done).
--- On Mon, 26/3/12, Aric Stewart aric@codeweavers.com wrote:
Hi,
Not to argue if it will be useful or not, as I do not know. I think this will be technically very hard. You will have to be able to get the keystrokes for a native linux applications feed them into WINE, have wine do the IME processing and then get the resulting characters and feed them back into the native linux application. This pipeline is not trivial.
Getting arbitrary microsoft or 3rd-party input methods to work with Wine (for windows application under wine) would be an interesting project. Getting arbitrary microsoft or 3rd-party windows input methods to be useable by native [unix] applications would be less useful - and as you wrote, rather troublesome for the sake of it.
I would have to say, the perceived problem with ibus/fcitx/whatever's pinyin implementation is simply failing to naming the issue correctly: it is not that the pinyin implementation on Linux/X11 is poor, but that an entire generic input mechanism (which applies to both pronounciation/pinyin-based methods, as well as shape-decomposition-based methoids like Cangjie) that of predictive/anticipatory/auto-completion, is missing. If you cannot name and describe the issue correctly, you are simply "barking up the wrong tree", as the saying goes.
Also, it is not true that such feature is entirely missing. The Japanese had done some very interesting work in anticipatory XIM inputs based on dictionaries (the typical linux installation actually ships several, from time to time), and I believe that the Taiwan people had done similar as well (these are available more under niche localized linux distributions); one problem is that those technical development has so far largely stayed localized - native-speaking linux/X11 people know where to find them, but have very little incentive or patience of pushing those technical developments back and integrating them into the western/English-speaking world.
Additionally, you have not explained how this will benefit WINE. I can forsee none of the above pipeline being accepted into or applicable to WINE presently, at lest in theory, i have done work that allows native XIM clients to be able to work in wines IME framework, so if a user really wants to use windows XIM in wine they should work. The setup is tricky but in all my years of working on wine IME i have never heard of a user wanting that. Almost all requests are to make the Linux/Mac Input Methods work better in WINE.
I would love to have you work on improving IME and XIM integration in WINE, but i think the main goal of the project is pretty tangential to wine.
Yes, I agree "make the Linux/Mac Input Methods work better in WINE", or just "make the Linux/Mac Input Methods work better" are desired. Actually an ibus<->google-chinese bridge would be interesting, but that's completely othorgonal and unrelated to wine. (except in the sense that wine itself is one X11 application among many).
--- On Mon, 26/3/12, Cheer Xiao xiaqqaix@gmail.com wrote:
What you are describing is the desirability of
predictive and phrasal input
methods in general, where the computer can anticipate
and guess your
intention as you type.
We only disagree in the definition of what a "decent" IME is. By decent I meant a decent phrasal or sentence IME. Because given the large amount of homophones in Chinese a bare pinyin IME is barely usable.
The first step of addressing a problem is to name and describe it correctly. Since predictive and phrasal input algorithms (and allowing fuzzy input) is not specific to pinyin - or pronounciation-based input methods, which the Japanese is also mostly based on - but also applies to shape-decomposition-based input methods like Cangjie.
The majority of pinyin-based input methods are "correct" and complete for what they claim to do, namely translating from sound to words, but not useable.
For what it is worth, you are forgetting two entire
"areas" of people.
Taiwan/Hong Kong had always been far more
computer-literate than Mainland,
so your "80% won't bother to learn another" is a gross
mis-statement in both
quantity and quality. Due to different dialects and
other reasons, Cangjie
(rather than Pinyin) had been far more popular with
Chinese users. But even
with Cangjie (which is shape/writing-based, rather than
sound-based, thus
getting around the dialect problem), predictive and
phrasal input methods
are desirable.
I declared that I was talking about the situation in mainland China in the beginning - I should have emphasized that along the way. But by declaring Cangjie is far more popular, you are ignoring the mass majority of people in mainland China. Again, I won't be able to convince you that the majority won't bother to learn another IME, even in highly computer-literate places like CS departments in universities. Arguing about facts is plainly meaningless.
You have completely ignore the historical context. Cangjie was the first input method which had a majority usage among ethnic Chinese users. That was in the 80's. It is a known fact that at that time, Mainland had just gotten out of the cultural revolution, and not in the best shape in general education, let alone technical areas, or access to computers or the internet. (in fact it is arguable about the last point even now, but I'll let that pass).
Since reliable statistics does not exist - and the Chinese government won't allow it - any claims on majority or percentage of usage is null and void, honestly. You only speak for your own preference.
Yes, but "just works" is not the same thing as "usable".
You have again lost my point: pinyin is not the missing part in Linux/X11's chinese input support. Predictive/anticipative/auto-completion phrasal input algorithm is. And predictive/anticipative/auto-completion phrasal input algorithm can be used in combination with non-pronounciation-based (i.e. non-pinyin-based) mechanism, such as Cangjie, which is shape-decomposition-based.
2012/3/25 Aric Stewart aric@codeweavers.com:
Hi,
As a developer who has done a lot of work in the IME/XIM areas of wine I thought I would chime in.
The IME/XIM stuff sounds interesting but I am really not sure how useful it is going to be. I will have to review what the GSoC outline is like but it feels like something that would not really get into wine not would regularly get used by people outside of wine. If you want to flesh it out a bit more I could maybe see where you are going with it but it feels more like a project "Making use of Wine" instead of "Improving Wine"
I'm a Chinese speaker. More specifically, I write simplified Chinese, and I use the most popular Chinese input method - pinyin[1], which in turn is the official Chinese romanization scheme in mainland China. Over 80% of Chinese users won't bother to learn another input method - the estimation may still be conservative.
In the Unix world side - it's a shame, but fair to say, developers have failed to ship a decent pinyin IME. There has been various efforts, that is ibus-pinyin[2], fcitx[3], sunpinyin[4], google-pinyin[5], and most lately libpinyin[6], but they still suffer from a lack of manpower and developer interest. In fact, lack of a decent pinyin IME has been a major blocker to Linux adoption in mainland China.
Therefore Wine IME, if realized, is not only going to be useful; it's going to be *really* useful. According to me, part of Wine's spirit is to resolve bug 10000 and get Microsoft out of business :) but the other part ought to be to bring the best of Windows world into Unix world. I'm following _that_ aim, precisely.
This is not a discouragement, just an invitation to sell it to me more. Make me see why you think this would be good for IME in Wine.
-aric
1. http://en.wikipedia.org/wiki/Pinyin 2. http://code.google.com/p/ibus/ and https://github.com/phuang/ibus-pinyin 3. http://code.google.com/p/fcitx/ 4. http://code.google.com/p/sunpinyin/ 5. http://en.wikipedia.org/wiki/Google_Pinyin 6. https://github.com/libpinyin/libpinyin/wiki
-
Aric Stewart -
Cheer Xiao -
Henri Verbeet -
Hin-Tak Leung -
Hin-Tak Leung -
Jerome Leclanche -
Nikolay Sivov -
Qian Hong