Re: About WineHQ Wiki
2012/8/26 André Hentschel n...@dawncrow.de: Am 26.08.2012 07:16, schrieb Cheer Xiao: 2012/8/26 Cheer Xiao xiaqq...@gmail.com: ... snip ... Try out MoinMoin 2.0 at this minefield[5]. The last Summer of Code[6] saw a few interesting enhancements like greatly improved themes, support for blog and ticket system (disclaimer: ticket system is my project), but the test site has not been updated yet. I have talked to the admin on #moin-dev, and I'll report back when it has been updated. The test site [1] was just updated, please give it a try :) After registering you may want to try out the new foobar theme. The theme setting can be accessed by clicking settings at top and then Wiki Appearance Settings tab, or directly via this URL[2]. Looks good (i also like the foobar theme), but sometimes weird. To add a new page i had to click through some sites first, to confirm it i had to click OK at the top(!?) and there were no preview option... Then i copied the source of a wiki entry from wine into it and viewed the result, all listings and tables work fine but links like: [http://source.winehq.org/git/wine.git/?a=searchh=HEADst=commits=+ARM ARM commits] are not recognized, so i'm rather scared of upgrading or did i missed something? (http://test.moinmo.in/ARM) The markup syntax has changed a bit, and now you have to say [[http://www.example.com|example]] (double brackets, required bar). Single brackets are gone since some 1.x version I think. And yes, as I noted in a previous post moin2 is *not* production-ready yet and I don't suggest you jump ship now. :) What I do strongly suggest, however, is that you upgrade to moin1.9 first, since 1) there has been many security fixes[1] which are not backported to old versions, and 2) upgrade to moin2 will only be supported from moin1.9. Instructions on upgrading are available in the moin1.9 source tree[2]; also check out the moin1.9 installation doc[3]. If you encounter any problem during the upgrade, feel free to ask on #moin channel on freenode. Further it seems a bit more complicated with Wine, the moinmoin wiki is sponsored by http://lattica.com/ (whatever sponsored means, didn't find further information) and the code is not accessable via a wine git repo (maybe it should be in tools.git, website.git or its own). This also leads to the fact that we still have no new wiki theme years after the theme change on the website. Now that we upgraded the Forum engine we (we as in laxdragon xD) could maybe do something about the wiki, it needs love. It seems Kyle is doing a good job at the content, but the content is not everything. Looking forward to good news. 1. http://moinmo.in/SecurityFixes 2. http://hg.moinmo.in/moin/1.9/file/0e58d9bcd3bd/docs/ 3. http://master19.moinmo.in/InstallDocs -- Regards, Cheer Xiao
Re: About WineHQ Wiki
Hi all, I'm a MoinMoin contributor, one of MoinMoin's participating students in this year's Summer of Code. 2012/8/26 Kyle Auble randomidma...@yahoo.com: Sat, 25 Aug 2012 14:44, Oleg Yarigin wrote: When I edited pages in the WineHQ Wiki, I notised, its markup lankuage isn`t so good as MediaWiki`s one. How do you think about moving the Wiki into MediaWiki engine? Besides, moving each language section of the Wiki into separated subdomain (like in Wikipedia) would be a good idea too. I've been working a lot on the wiki recently, and I actually brought up something similar in this thread: http://www.winehq.org/pipermail/wine-devel/2012-July/096198.html While I'm busy with other things right now, I wanted to discuss this in more detail in the near future, particularly how it ties into possibly migrating the entire site over to a CMS. The Moinmoin syntax was new to me too, but after using it a little, I don't mind it too much. There are definitely a few missing features and rough edges compared to MediaWiki. However, and this is just my impression, I think MediaWiki has really evolved to fit Wikipedia's needs. I'm not sure how well it integrates (style-wise at least) if you don't run your entire site off of it, and while I haven't actually looked at MediaWiki's code, I've heard that it can be really tricky to setup, maintain, and reprogram. There are some pluggable parsers for Moinmoin, and there may be one that allows MediaWiki syntax. After going through and checking, categorizing, and editing so many pages, I definitely agree with your suggestion that each language be given a domain, instead of one flat namespace. Then maybe just add a single common translation menu to the side toolbar? Indeed there is a MediaWiki parser[1]. Also, take a look at MoinMoin 2.0[2]. It has multiple markups support out of the box (including mediawiki of course). You can even mix them in a single wiki instance - this is not necessarily a good idea, but it helps when you have to migrate some content from another wiki by hand. A namespace branch is also under development. [3] Another enhancement that might intereset you: the storage layer has been greatly enhanced, you can now use almost arbitrary databases as the storage in case you are worried about possible performance issue with the directory-based storage; [4] It's not production-ready yet, but it's definitely worth waiting for. :) I've come to the opinion that we should probably stick with Moinmoin, and migrate to a new engine other than MediaWiki only if there are strong reasons. What might be best is if we actually got in touch with some of the Moinmoin developers and put in some feature requests. Helping with the wiki's engine is on my list so I'd like to hear some more opinions. Feel free to join #moin and #moin-dev channels on freenode. Feature requests are welcome, but be noted that MoinMoin 2.0 is the current development version (it's not a development branch since the codebase is almost a total rewrite) and quite likely the feature you want is already there (or a TODO). :) Try out MoinMoin 2.0 at this minefield[5]. The last Summer of Code[6] saw a few interesting enhancements like greatly improved themes, support for blog and ticket system (disclaimer: ticket system is my project), but the test site has not been updated yet. I have talked to the admin on #moin-dev, and I'll report back when it has been updated. 1. http://www.moinmo.in/MediaWiki 2. http://www.moinmo.in/MoinMoin2.0 3. http://www.moinmo.in/MoinMoin2.0/Namespaces 4. http://www.moinmo.in/MoinMoin2.0#Storage_Layers:_stores.2C_backends.2C_middlewares 5. http://test.moinmo.in/ 6. http://www.moinmo.in/GoogleSoc2012 -- Regards, Cheer Xiao
Re: About WineHQ Wiki
2012/8/26 Cheer Xiao xiaqq...@gmail.com: ... snip ... Try out MoinMoin 2.0 at this minefield[5]. The last Summer of Code[6] saw a few interesting enhancements like greatly improved themes, support for blog and ticket system (disclaimer: ticket system is my project), but the test site has not been updated yet. I have talked to the admin on #moin-dev, and I'll report back when it has been updated. The test site [1] was just updated, please give it a try :) After registering you may want to try out the new foobar theme. The theme setting can be accessed by clicking settings at top and then Wiki Appearance Settings tab, or directly via this URL[2]. Your are welcome to report bugs at the issue tracker[3], but the obvious bugs should be already there. PS. Currently the hashed password is publicly accessible, so be sure to use a weak password.) 1. http://test.moinmo.in/ 2. http://test.moinmo.in/%2Busersettings#ui 3. https://bitbucket.org/thomaswaldmann/moin-2.0/issues -- Regards, Cheer Xiao
Re: GSoC proposal
2012/3/25 Aric Stewart a...@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 1 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 -- Regards, Cheer Xiao aka. xiaq
Re: GSoC proposal
2012/3/25 Henri Verbeet hverb...@gmail.com: On 25 March 2012 16:49, Qian Hong fract...@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. -- Regards, Cheer Xiao aka. xiaq
Re: GSoC proposal
2012/3/26 Hin-Tak Leung ht...@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). -- Regards, Cheer Xiao aka. xiaq
GSoC proposal
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 KR thoroughly, plus experience in a few small projects; I also know the Git workflow well. I'd love to help fix bug 1 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 -- Regards, Cheer Xiao aka. xiaq
Re: GSoC proposal
2012/3/25 Nikolay Sivov bungleh...@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). -- Regards, Cheer Xiao aka. xiaq
Re: Translators wanted!
2012/2/17 Qian Hong fract...@gmail.com: Hello, On Fri, Feb 17, 2012 at 2:13 AM, Francois Gouget fgou...@free.fr wrote: I feel that we should put out a call for translators to the wider community. In preparation for that I updated the Wiki's Translating page and added a winepo script to help translators who don't want to check out the whole Wine source: http://wiki.winehq.org/Translating I would like to help to update the Simplified Chinese translation, but most likely I have no enouth time to complete it before wine-1.4 final release. Could anyone give a deadline? If anyone would like to translate Simplified Chinese please post a reply here to prevent duplication work. I had maintained zh_CN translation for quite some time, but haven't touched it for about a year (since Wine switched to po files). I might get down to cleaning up zh_CN.po in the near future, but I'll contact you before that. Also I'll forward this mail to Traditional Chinese community, since as a native Simplified Chinese speaker I can't use Traditional Chinese correctly every time. Thanks Francois and the Wine community :) -- Regards, Cheer Xiao aka. xiaq
