Re: GSoC proposal
--- On Mon, 26/3/12, Aric Stewart a...@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).
Re: [PATCH] cmd/tests: If we rewind to the beginning of the line, don't increment line number.
On Mon, Mar 26, 2012 at 10:13, Christian Costa titan.co...@gmail.com wrote: If some particular cases, a bias is introduced in the line number which make error message mismatch the content of the .exp file. This patch fixes that. --- programs/cmd/tests/batch.c | 4 I guess this should be marked as a prerequisite to/included in your new attrib patches list Frédéric
Re: [PATCH] cmd/tests: If we rewind to the beginning of the line, don't increment line number.
Le 27/03/2012 08:32, Frédéric Delanoy a écrit : On Mon, Mar 26, 2012 at 10:13, Christian Costatitan.co...@gmail.com wrote: If some particular cases, a bias is introduced in the line number which make error message mismatch the content of the .exp file. This patch fixes that. --- programs/cmd/tests/batch.c |4 I guess this should be marked as a prerequisite to/included in your new attrib patches list Frédéric All cmd tests benefit from this patch but yes it could be part of the attrib patches set. Christian
Re: Need suggestion to choose a GSoC idea
Hi Holy, On Tue, Mar 27, 2012 at 12:38 PM, HolyCause holy.ca...@gmail.com wrote: I already asked Austin about that for my GSoC proposal: in short, I think this effort is best spent somewhere else. GUI testing is really hard to get right, and very expensive(time, effort, disk space, cpu power, etc.). Thanks for reminder, I agree GUI testing is expensive, but I think manpower is more expensive :) However I've no idea how hard is it to get GUI testing right yet, maybe you are right, but from my view it is worth to try. I've since decided against GSoC for this year, but my idea revolved around improving cmd's parser, notably getting Firefox/Chromium and/or other software to build under wine (or at least, isolate potential/existing issues to non-cmd parts). I was partway through fixing http://bugs.winehq.org/show_bug.cgi?id=21174 Dan Kegel seemed pretty interested in the project. If you're interested you could e-mail him. Thanks, if this idea is not suitable for GSoC, I'll push it in my todo list. I'll contact to Dan and Austin once I'm going to do this. Thank you for your suggestion and good luck to your GSoC project! -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/
Re: winex11.drv: Do not trash existing clip rectangle if XInput2 is not available.
Vitaliy Margolen wine-de...@kievinfo.com writes: If Dmitry fixes a real bug that means dinput shouldn't depend on broken behavior. And I'm questioning that exact behavior which shouldn't have been there in the first place. Dinput's exclusive mode works regardless of what ClipCursor is set to. Of course the behavior is not identical to Windows, but that's because we can't intercept mouse events under X11 at the level where dinput would have to do it. If you have suggestions on how to do this differently please explain them. Just claiming it's wrong because it's not like Windows is not helpful in this case. -- Alexandre Julliard julli...@winehq.org
Re: [3/8] scrrun: Add IFileSystem3 support
Hi Alistair,
On 03/27/12 11:41, Alistair Leslie-Hughes wrote:
+typedef struct FileSystem
+{
+IFileSystem3 IFileSystem3_iface;
+LONG ref;
+} FileSystem;
+
+static inline FileSystem *impl_from_IFileSystem3( IFileSystem3 *iface )
+{
+return CONTAINING_RECORD(iface, FileSystem, IFileSystem3_iface);
+}
Is there any reason for this to be heap-based object? It looks to me like it
would better be a static object (AFAICS you don't even need FileSystem struct
since you're not going to store anything in it).
Cheers,
Jacek
Re: [5/8] scrrun: Implement IFileSystem3 FileExists
Hi Alistair,
On 03/27/12 11:42, Alistair Leslie-Hughes wrote:
+static const WCHAR existing_fileW[] = {
+'c', ':', '\\', 'W', 'i', 'n', 'd', 'o', 'w', 's', '\\', 's', 'y',
's', 't', 'e', 'm', '3',
+'2', '\\', 'n', 't', 'd', 'l', 'l', '.', 'd', 'l', 'l', 0};
Hardcoding even such paths is not a god idea.
Cheers,
Jacek
Re: [4/8] scrrun: Add scrrun tests
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=17491 Your paranoid android. === WINEBUILD (build) === Make failed
Re: [5/8] scrrun: Implement IFileSystem3 FileExists
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=17492 Your paranoid android. === WINEBUILD (build) === Make failed
Re: [6/8] scrrun: Implement IFileSystem3 FolderExists
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=17493 Your paranoid android. === WINEBUILD (build) === Make failed
Re: [3/8] scrrun: Add IFileSystem3 support
Hi Jacek, Is there any reason for this to be heap-based object? It looks to me like it would better be a static object (AFAICS you don't even need FileSystem struct since you're not going to store anything in it). No, Just habit to create them like this. Best Regards Alistair Leslie-Hughes
Re: Need suggestion to choose a GSoC idea
Hi, On 3/26/12 10:29 PM, Qian Hong wrote: - Improve Wine CJK font support The main idea is fix Bug 16325 [11], Aric and others have done a lot of work on it, and I'm glad to participating too. I think the main blocker for Wine CJK font support is Font Association now, is it suitable for a GSoC project? Also I've filed some other Wine font bugs [12],[13],[14],[15],[16], I'm happy to working on them. Oh, I would love this. However speaking from experience font code is very hard. You would need to directly specify what you wanted to try to do and what needs improvement. The code there is very messy and fragile but also critical so it gets tricky to make any sweeping modifications. - Improve Wine font test case This idea is similar with the above one, however, instead of fixing real bugs, this idea is to prevent new bugs(regression). As having filed 100+ bugs I know the pain of doing regression test if we can't script the test, this happens on font related bugs. The main idea is to integrate an OCR engine to wine testcase, use ORC method to detect whether the fonts display correctly. We already have very good open source ORC engine [17] which is in Apache License. However tesseract-ocr is written in C++ an I am worring that will not be integrated to Wine code tree. I dont know if we need OCR. With the dib engine if we have a known font we can probably just do bitmap compares. I am not an expert here but it sounds interesting. -aric
Re: winex11.drv: Do not trash existing clip rectangle if XInput2 is not available.
On 03/27/2012 02:29 AM, Alexandre Julliard wrote: Vitaliy Margolenwine-de...@kievinfo.com writes: If you have suggestions on how to do this differently please explain them. Dinput needs to talk to x11drv directly to get xi2 events. Same for requests to clip cursor in exclusive mode. The current method of using hooks can stay for backwards compatibility. This can also apply to keyboard events for dinput as well. They main issue here is that you need a thread not directly attached to any window pulling all X's events. Dinput already have one such thread. You just need to let it talk to X. Vitaliy.
Re: winex11.drv: Do not trash existing clip rectangle if XInput2 is not available.
Vitaliy Margolen wine-de...@kievinfo.com writes: Dinput needs to talk to x11drv directly to get xi2 events. Same for requests to clip cursor in exclusive mode. The current method of using hooks can stay for backwards compatibility. I'm not at all convinced that this would be an improvement, particularly since you still need the events to follow the normal path for apps that don't use dinput. -- Alexandre Julliard julli...@winehq.org
Re: Need suggestion to choose a GSoC idea
Hi Aric, Thanks for reply. On Tue, Mar 27, 2012 at 7:56 PM, Aric Stewart a...@codeweavers.com wrote: Hi, Oh, I would love this. However speaking from experience font code is very hard. You would need to directly specify what you wanted to try to do and what needs improvement. The code there is very messy and fragile but also critical so it gets tricky to make any sweeping modifications. My favorite is to implement Font Association support, since currently we have no workaround for it without recompile source code. However, before investigate on font issue deeply, could I ask here for other wine developers' work plan? Just half day after I post my previous email, Huw and Kusanagi have sent their patches regarding font support to wine-patch. we have multiple developers working on this area, to prevent duplicate work, could you tell me is anyone working on Font Association support? Thanks a lot! I dont know if we need OCR. With the dib engine if we have a known font we can probably just do bitmap compares. I am not an expert here but it sounds interesting. I didn't known we can just do bitmap compares, if that's possible I think the OCR plan could be schedule low priority, maybe I'll investigate it in the future. Is it a good GSoC idea to improve font related testcase base on bitmap compares? Thank you! -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/
Re: winex11.drv: Do not trash existing clip rectangle if XInput2 is not available.
On 03/27/2012 08:04 AM, Alexandre Julliard wrote: Vitaliy Margolenwine-de...@kievinfo.com writes: Dinput needs to talk to x11drv directly to get xi2 events. Same for requests to clip cursor in exclusive mode. The current method of using hooks can stay for backwards compatibility. I'm not at all convinced that this would be an improvement, particularly since you still need the events to follow the normal path for apps that don't use dinput. In exclusive mode dinput consumes those events - they should not be making it to the actual application. So it's not a problem there. In background mode they are duplicated - again not an issue. It's a separate data feed into dinput of key press/releases and relative position changes - gets rid of all the complexity related to absolute - relative calculations. And it's a possible source for RawInput whenever it will be implemented. It can receive background kbd mouse events as well. Vitaliy.
Re: [PATCH] mciqtz: Actually assign result to the output structure
Hi Joerg, Cool, but what I could use is concrete test cases with reported failures. Could you give me some example scripts, maybe with accompanying media files, with the issues pointed out. You could give me where the expected behavior does not match the existing behavior. clear tests and procedures like that will allow me to really focus in on what is going wrong. thanks! -aric On 12/03/23 13:18, joerg-cyril.hoe...@t-systems.com wrote: Hi, Aric Stewart wrote: If you know about specifically quartz issues I am happy to start looking at them. I find the following very specific: Mciqtz is nothing but a pass-through to quartz' IVideoWindow_* IMediaSeeking_* IMediaControl_ and IGraphBuilder_QueryInterface. So using mciqtz is like using quartz directly. The nice thing is: every bug you find is a bug in Wine, since only Wine source is involved, without third-party app. That's why I find working with the MCI very rewarding. The MCI shell is at http://bugs.winehq.org/show_bug.cgi?id=20232#c10 Here are basic scenarios that do not work correctly now -- in the following, replace foo.xyz with your choice of .wav (embedding linear pcm, adpcm and esp. mp3), .avi (with whatever RLL/iccvid/msvidc1/etc. video format), use .avi with and without audio tracks, .mp3 or .mpg audio/video (if you feel like stressing winegstreamer) (even .wma if you feel like using codec outside Wine) You may even try .mid files, but perhaps that would use DirectMusic in native. Open foo.xyz type mpegvideo alias q Window q state show Status q time format # optional, yields frames with .avi Set q time format milliseconds # optional Status q length Set q time format frames # restore default for .avi Status q length Seek q to start Play q notify # or alternatively Play q from 0 notify Play q from 5 to 10 Play q from 0 repeat notify # repeat flag not yet implemented Status q position Status q mode # should yield stopped or playing Set q time format bytes # expect MCIERR_UNSUPPORTED_FUNCTION == refused # presumably, quartz does not work with bytes (or would mciqtz intercept that?) Stop q Close q IIRC, Wine's DirectSoundRenderer would not stop and regularly throw errors to the console. I just noticed that play X from 5 repeat behaves differently between native mciavi32 and mciqtz (xp). Mciqtz repeats from 0 while mciavi repeats from 5. Also their window refresh modes are very different, mciqtz is mostly unresponsive while mciavi refreshes even when not playing. So it is not the case that MS made mciavi and mciqtz equal. Actually, I don't know where the default time format originates from. A typical .avi yields frames, using a .wav yields milliseconds. So it is not a constant for mciqtz. So I think there's plenty of room for improvement in quartz, and you need not wade through obscure logs produced by binary-only apps. And once mciqtz/quartz behaviour becomes undistinguishable from native's as witnessed by the MCI shell with type mpegvideo, many bugzilla quartz items will appear fixed automagically, I'm sure. Thank you, Jörg Höhle
Re: winex11.drv: Do not trash existing clip rectangle if XInput2 is not available.
Vitaliy Margolen wine-de...@kievinfo.com writes: On 03/27/2012 08:04 AM, Alexandre Julliard wrote: Vitaliy Margolenwine-de...@kievinfo.com writes: Dinput needs to talk to x11drv directly to get xi2 events. Same for requests to clip cursor in exclusive mode. The current method of using hooks can stay for backwards compatibility. I'm not at all convinced that this would be an improvement, particularly since you still need the events to follow the normal path for apps that don't use dinput. In exclusive mode dinput consumes those events - they should not be making it to the actual application. So it's not a problem there. In background mode they are duplicated - again not an issue. The point is that we need to send the events to the server and to the hooks anyway, so dinput might as well get them from there instead of having its own back channel. -- Alexandre Julliard julli...@winehq.org
RFC: Duplicate in/out device naming
I'm working on Bug 14559 and have run into an interesting UI problem. In WinMM, there are three classes of devices: waveIn, waveOut, and mixer. Windows 7's WinMM implementation provides one mixer for each waveIn and waveOut device. The WCHAR caps.szPname[32] field for the matching mixer and waveIn/Out device are the same. Some applications, in this case Rosetta Stone 3, use the matching szPname fields to determine which mixer to associate with which device. The problem turns up when we have duplicate input and output device names. Consider: waveOut: 0: default 1: HDA Intel Analog 2: HDA Intel Digital waveIn: 0: default 1: HDA Intel Analog mixer: 0: default 1: HDA Intel Analog 2: HDA Intel Digital 3: default 4: HDA Intel Analog Rosetta Stone chooses waveIn[0] and starts iterating over the mixers' szPname fields, finding that mixer[0] matches. But, mixer[0] is actually associated with the waveOut default, not the waveIn default. Bad things happen. Windows 7 solves this problem implicitly by providing unique device names at the MMDevAPI level. For instance, the input device is Microphone and the output devices are Stereo and Headphones. Hacking the registry to force duplicate MMDevAPI device names actually does result in duplicate mixer names. But Wine's backends don't provide this kind of information, so we simply provide the ALSA device name as the device's name. As an attempt to solve this in Wine, I added a prefix to each MMDevice indicating its flow direction. The unique identifier must be a prefix, as WinMM's szPname field truncates at 31 characters. This gives WinMM device names like: waveOut: 0: Out: default 1: Out: HDA Intel Analog 2: Out: HDA Intel Digital This solves the Rosetta Stone issue, as you can see in the bug. But when testing this in other applications, it quickly becomes silly. Audacity 1.3 adds its own Out: prefix to WinMM device names, creating Out: Out: default in the UI. Dynamically adding prefixes only if a duplicate device is present causes issues with duplicates appearing/disappearing. Trying to remember if a duplicate has ever been present is quite ugly in code, requiring storing that kind of information in the registry. So I don't know what to do. Have ugly, redundant device names? Leave Rosetta Stone broken, as it is arguably an application bug? Try to guess at the device type, and insert names like Speakers and Microphone into the MMDevAPI device name, even if that might be wrong? Thoughts? Andrew
Would like to get some feedback on GSOC idea
Hi everyone, My name is Marek Chmiel, I am a student a NEIU. I am studying computer science and network security related topics. This semester I had spent a fair amount of time writing crypt related functions with java, and became very interested in Cryptography. After looking over the suggested ideas on SOC official wine wiki I was pleasantly surprised to see that there was already a crypt related idea suggested. I have a great understanding of c++ and java, and though I know c I have not worked with it as much as the other languages. Implementing a DSS provider sounds like an awesome task to tackle, if someone has never written code for Linux, can they take on such a task? Are there any significant issues implementing a DSS that you guys know about? Any crypt GSOC ideas would you suggest for someone who has wrote limited amount of code for Linux? What I would also like to do, besides implementing a DSS provider, is to fix most if not all of the crypt related bugs that remain in Wine. This might seem like more than most people can chew, but viewing the Bug Tracking database it appears that there aren't that many crypt related bugs and might even be caused by a lack of a DSS provider (Hopefully this wouldn't create a entire new series of bugs). Thanks for any input I might receive, and look forward to speaking with you all. I can also be found on the irc for development with the nick MarcoVonChmiel. Marek K Chmiel.
Re: [PATCH 1/2] winmm: Support DRVM_MAPPER_PREFERRED_GET in waveXxxMessage
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=17495 Your paranoid android. === WNT4WSSP6 (32 bit capture) === capture.c:648: Test failed: waveInMessage(DRVM_MAPPER_PREFERRED_GET) failed: 6 capture.c:653: Test failed: Got invalid preferred device: 0x22fe5c === W2KPROSP4 (32 bit capture) === capture.c:648: Test failed: waveInMessage(DRVM_MAPPER_PREFERRED_GET) failed: 6 capture.c:653: Test failed: Got invalid preferred device: 0x235370 === WNT4WSSP6 (32 bit wave) === wave.c:1386: Test failed: waveOutMessage(DRVM_MAPPER_PREFERRED_GET) failed: 6 wave.c:1391: Test failed: Got invalid preferred device: 0x234098 === W2KPROSP4 (32 bit wave) === wave.c:1386: Test failed: waveOutMessage(DRVM_MAPPER_PREFERRED_GET) failed: 6 wave.c:1391: Test failed: Got invalid preferred device: 0x41
Re: Web based translation tool
Hi Dne Tue, 27 Mar 2012 00:00:04 +0200 Frédéric Delanoy frederic.dela...@gmail.com napsal(a): On Mon, Mar 26, 2012 at 16:23, Michal Čihař mic...@cihar.com wrote: It turned out such feature seems to be important for more projects, so I will end up implementing some way of merging of commits for 1.0. Details can be found at https://github.com/nijel/weblate/issues/16 I don't know how your tool/system exactly works, so my comment may be a bit naive/wrong, but instead of merging commits, couldn't there be instead (or as a complement) some kind of session/transaction system where a user translates a number of msgids, then sort of commits its changes to close the session/transaction, which would trigger the git commit creation? You've basically described what I've outlined in issue referenced above and implemented just now in Git, so yes I think this is better approach than merging :-). -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Re: [PATCH] devenum: Add tests for devenum.
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=17507 Your paranoid android. === WNT4WSSP6 (32 bit devenum) === devenum.c:59: Test failed: Cannot create CLSID_SystemDeviceEnum object (res = 80040154)
Re: [PATCH] devenum: Add tests for devenum. (try 2)
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=17512 Your paranoid android. === WINEBUILD (build) === Make failed
Re: po: Update German translation
Hi André, Am Dienstag, den 27.03.2012, 21:43 +0200 schrieb André Hentschel: --- po/de.po |7 +++ 1 files changed, 3 insertions(+), 4 deletions(-) #: jscript.rc:37 -#, fuzzy #| msgid Invalid parameter.\n msgid Invalid character -msgstr Ungültiger Parameter.\n +msgstr Ungültiges Zeichen du solltest die alte msgid auch entfernen. (Ist ein neues Feature, wurden schon andere drauf hingewiesen ;) Viele Grüsse, Julian
'Pending' patches state
Hello, http://source.winehq.org/patches has the following legend for the Pending patch status: Pending * The patch is not obviously correct at first glance. Making a more convincing argument, preferably in the form of a test case, may help. * Waiting for feedback from the main developer in that area. It's very confusing, and absolutely not clear what is required from the patch submitter, especially since *there is no any feedback on the patch*. 'Rejected' at least requies some sort of feedback, while 'Pending' doesn't. To me 'Pending' looks like a silent case of 'Reject', but without any obligation to explain why. I find myself on somewhat shaky ground when I see a bunch of my patches in the pending state, especially if they already contain the tests and main developer in the area I'm changing is Alexandre :). Is it possible to get at least some feedback for pending patches? Pretty please? -- Dmitry.
Re: [PATCH 1/5] winex11: Use GLX_DONT_CARE instead of ~0 in ConvertAttribWGLtoGLX().
On Tuesday, March 27, 2012 8:35:49 PM Henri Verbeet wrote: - int pixelattrib = ~0; + int pixelattrib = GLX_DONT_CARE; I want to say there's a reason we used ~0 instead of GLX_DONT_CARE, but it's been too long that I can't remember. I think it was because GLX_DONT_CARE didn't include all possibilities that ~0 would, like what WGL wanted.
