Re: Wine and Window Management
On Sat, Mar 24, 2012 at 07:12:14PM -0700, Roger Cruz wrote: Could someone tell me if Wine has a built-in Window Manager of its own or does it count on the host's window manager for such things as window hierarchy (parent-child relationships), clipping, move, resize, iconify, etc? I want to run Wine on an environment which lacks X and I have been told conflicting information on whether I need to write my own window manager. It has always been my impression that Wine does all the window management so it must have a Windows window manager built-in. In Desktop Mode Wine does its own window management. You can test it by setting desktop mode in winecfg. ;) I'm interested in knowing that if I remove the X11 driver from Wine, whether I will have to also provide my own window manager or whether what is in Wine is sufficient. If there is a window manager in Wine, what type of functionality does it require from whatever I chose to replace X11 with? Then you will need to write your own display engine first, which will be a bit harder than the window manager part. (Not sure how much additional work you will need to get the desktop managed mode in.) ciao, Marcus
Re: My Idea for GSOC
Hi again, so I've been messing around with this a bit and have some questions. However I'm not able to properly set up lighting/materials, I think I want a function like SetMaterial in d3d7 to activate a material with some emissive color. As for now I'm only able to get D3DVT_VERTEX and D3DVT_LVERTEX to render all black. Also is there some documentation available for early versions of directx available I can not seem to find any? On Fri, Mar 23, 2012 at 13:22, Daniel Oom daoo...@gmail.com wrote: I think I accidentally dropped wine-devel, I have re-added and hope it does not create any trouble. And thanks for the explanation, but I'm not sure I fully understand how the different versions of direct3d interact within wine's implementation. I will probably figure it out in time. Also I will try to come up with a better test that compares lighting-settings as this was fun and fine introduction to wine. On Wed, Mar 21, 2012 at 15:18, Stefan Dösinger stefandoesin...@gmx.atwrote: Hi, Did you run the test on Windows? The purpose of the tests is not do document what we think should happen, but figure out how Windows behaves, and then replicate the same behavior. Is suspect your test fails on Windows because you're verifying that lighting is on or off in the wrong way. IDirect3DDevice2_GetRenderState(device, D3DRENDERSTATE_LIGHTING, value) will most likely not work in this way because D3DRENDERSTATE_LIGHTING does not exist in IDirect3DDevice2. You have to set up the d3d states in a way that rendering produces a different result with lighting on vs lighting off, then read back the rendering result(there's already a get_pixel_color function for that) and verify that you get the correct color. A basic recipie for that: With lighting off, you get the diffuse color in the vertex as final color(well, assuming that stuff like texturing, fog, etc. are off too). With lighting on it runs through the d3d lighting calculations[1]. If you disable all lights(d3d default), set the global ambient light to black(in later d3d there's a renderstate for that, in d3d2 I suspect that's part of D3DLIGHT and IDirect3DLight*), and set the emissive material property to a color != black, your emissive color will be the final color(since the ambient, diffuse and specular components of the equation are zero). By setting the vertex color and emissive material color to different colors you can tell if lighting is on or off. Cheers, Stefan PS: It's prefered to keep such discussions in public, ie with wine-devel CCed. I haven't CCed wine-devel yet, and I'm not sure if you dropped it or if I dropped it accidentally. 1: http://msdn.microsoft.com/en- us/library/windows/desktop/bb147178(v=vs.85).aspx Am Mittwoch, 21. März 2012, 09:25:40 schrieb Daniel Oom: I have poked around a bit with the source and managed to add tests that checks if lighting is disabled/enabled in device2 and device7. I also added SetRenderState in IDirect3DDeviceImpl_2_DrawPrimitive. The tests works but I have not checked what effect the change has in other circumstances. I attached a patch in hopefully the preferred format. On Sat, Mar 10, 2012 at 22:04, Stefan Dösinger stefandoesin...@gmx.atwrote: Am Samstag, 10. März 2012, 17:22:51 schrieb Daniel Oom: Hi, Writing tests, or implementing the command line tools seems like something I could do. I'm kinda leaning towards the command line tools, since it would offer a chance to thoroughly learn the shading languages. For learning purposes writing tests and fixing bugs uncovered by them will be better. The command line tools are mostly about parsing parameters and forwarding them to d3dx9 functions(*). If you want to look a little bit in either proposal(we recommend that in general): For the test stuff, take a look at IDirect3DDeviceImpl_2_DrawPrimitive in dlls/ddraw/device.c. It thunks IDirect3DDevice2::DrawPrimitive to IDirect3DDevice7::DrawPrimitive. The main difference is the VertexType parameter. It is a D3DVERTEXTYPE in the IDirect3DDevice2 method, and a DWORD with D3DFVF_* flags in Device7. Our thunk simply converts between these two, but a deeper difference a user noticed is that D3DVT_LVERTEX in Device2 disables lighting calculations, whereas the equivalent D3DFVF flag collection in Device3 and Device7 does not. Device3 and newer have D3DRENDERSTATE_LIGHTING to enable / disable lighting, but this render state does not exist in Device2. Fixing this is fairly straightforward, just call SetRenderState(LIGHTING, ...) in the thunk, but it needs some tests to answer / show the following: * Show that D3DVT_LVERTEX indeed disables lighting, and D3DVT_VERTEX enables it * Show that D3DFVF_LVERTEX does not influence lighting in Device2 and Device7(D3DFVF_TLVERTEX disables all vertex processing in all d3d versions, this is
re: GSoC proposal
submitting multiple proposals are explicitly allowed. True, but be careful, for two reasons: 1) there may have been cases where people who submit applications to two orgs fall through the cracks, with each org thinking the other was going to take him. 2) passion generally drives success, and unless you're like my friend who didn't sleep and got a triple major in four years (and now heads chip development for a major game console), splitting your passion between multiple applications could reduce the chances of either one being accepted. Going a bit further with a single application, e.g. by including [more] working patches, seems the better choice... assuming you pick a project that the organization really likes, anyway.
re: PDB format documentation.
Svyatoslav wrote: I've found that Wine dbghelp.dll includes PDB file parser. Does anyone know where I can find documentation of PDB internal structure? I think you've found it :-) As you probably know, PDB is an undocumented format. I suspect the best you can find are scattered posts like http://moyix.blogspot.com/2007/08/pdb-stream-decomposition.html http://www.godevtool.com/Other/pdb.htm from people who reverse engineer bits of it. Although http://moyix.blogspot.com/2007/08/pdb-stream-decomposition.html claims http://ccimetadata.codeplex.com/ has some interesting bits from the horse's mouth, and http://code.google.com/p/pdbparse/ http://code.google.com/p/pdbparser/ http://pdbparser.codeplex.com might be interesting.
Re: GSoC proposal
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 Sivovbungleh...@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).
Re: My Idea for GSOC
On 25 March 2012 15:36, Daniel Oom daoo...@gmail.com wrote: Hi again, so I've been messing around with this a bit and have some questions. However I'm not able to properly set up lighting/materials, I think I want a function like SetMaterial in d3d7 to activate a material with some emissive color. You're probably looking for IDirect3DDevice2::SetLightState() with D3DLIGHTSTATE_MATERIAL. Also is there some documentation available for early versions of directx available I can not seem to find any? You pretty much need need the DirectX SDKs for those early ddraw versions. They may still be archived somewhere, but yes, this is somewhat of a problem when working on ddraw. In some cases the existing ddraw code is also a good reference for how things roughly work, but especially the early versions are probably not quite correct.
Re: GSoC proposal
Hi, On Sun, Mar 25, 2012 at 10:30 PM, Aric Stewart a...@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... -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/
Re: GSoC proposal
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?
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
On Sun, Mar 25, 2012 at 11:02 PM, Henri Verbeet hverb...@gmail.com wrote: 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? 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. -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/
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
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).
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
