Re: [3/5] widl: Add tests for encapsulated unions
On Thu, Jun 14, 2007 at 06:28:41PM -0700, Dan Hipschman wrote: > > This adds a test for encapsulated unions, but it crashes wine. The exact Hmm, now that I reread this, I think I said this wrong. The test does crash wine, but I wrote my patch so that it doesn't run on wine. So, doing "make check" in dlls/rpcrt4/tests will *not* crash wine, it just won't run the encapsulated union tests. The encapsulated union tests *will* run, and succeed, on windows, however. I felt this was best because that way all of widl's output can still continue to be tested on windows, and everything that can be tested in wine without crashing still will be.
Re: Uninstaller
> On 6/14/07, Misha Koshelev wrote: > > Actually that brings up a good point, does anything ever get written to > > Software\Microsoft\Windows\CurrentVersion in HKEY_CURRENT_USER in windows? > > I have no such > > key on my (rather plain) XP install, and from what I can tell wine MSI > > never writes > > to this key (see dlls/msi/registry.c, function MSIREG_OpenUninstallKey line > > 378) in > > HKEY_CURRENT_USER. > > > > Is this done by some specific application, or if not what was the original > > motivation > > for the patches? From what I can tell this was not in the emails you linked. > > Btw, I think it would be a good idea to include this kind of info when you > > submit the patches. > > The original try of the emails (I think towards the end of May), had > it. There is a bug filed for it on bugzilla (search for IMVU). Some > applications (IMVU instant messenger, for one) do use current user by > default, and some installers ask where you want start menu entries and > application settings stored, all users, or current user, where all > users as far as the registry is concerned would be HKLM.. It was > brought up in private after I sent the linked emails, that I should > include that info in every try, so I will do so in the future. > > As for the currentversion key not being there in your xp install, it > may be just because it's a plain xp install. I use XP on a daily > basis and frequently access the registry, and I've never noticed a > time when it was not there with something under it, although I never > checked immediately after a clean install. Well in that case, my recommendation would be to include the bug # in your patch email with each try, and just to submit one patch with the proper spacing. And if you still don't see it committed, I would try to get in touch with Alexandre and see if he has specific comments. As far as I can tell, there aren't any unit/conformance tests for the uninstaller program (or even anything in the programs folder period???) so I wouldn't think that should hold up its adoption... Misha
Re: Uninstaller
On 6/14/07, Misha Koshelev <[EMAIL PROTECTED]> wrote: Actually that brings up a good point, does anything ever get written to Software\Microsoft\Windows\CurrentVersion in HKEY_CURRENT_USER in windows? I have no such key on my (rather plain) XP install, and from what I can tell wine MSI never writes to this key (see dlls/msi/registry.c, function MSIREG_OpenUninstallKey line 378) in HKEY_CURRENT_USER. Is this done by some specific application, or if not what was the original motivation for the patches? From what I can tell this was not in the emails you linked. Btw, I think it would be a good idea to include this kind of info when you submit the patches. The original try of the emails (I think towards the end of May), had it. There is a bug filed for it on bugzilla (search for IMVU). Some applications (IMVU instant messenger, for one) do use current user by default, and some installers ask where you want start menu entries and application settings stored, all users, or current user, where all users as far as the registry is concerned would be HKLM.. It was brought up in private after I sent the linked emails, that I should include that info in every try, so I will do so in the future. As for the currentversion key not being there in your xp install, it may be just because it's a plain xp install. I use XP on a daily basis and frequently access the registry, and I've never noticed a time when it was not there with something under it, although I never checked immediately after a clean install. -- Thanks Tom
Re: Uninstaller
On Thu, 2007-06-14 at 10:50 -0400, Chris Morgan wrote: > On 6/14/07, Misha Koshelev <[EMAIL PROTECTED]> wrote: > > First of all, of course I am not Alexandre. > > > > But I have to say I think I agree with James on this, with regards to > > submitting just one patch with the correct spacing. I can see how seeing > > one patch without any spacing changes keeps the diff very simple (I am > > assuming this is why you submitted your patches in this way), but at the > > same time I would assume that if Alexandre really wants to see what > > changed in this way after applying the one patch you will send with > > correct spacing, he can just type: > > > > git-diff -b > > > > and see something very similar to your patch #1 (ignores whitespace, > > same effect). > > > > Other than that, I did not see anything obviously wrong with the patch > > upon a quick look. If you don't hear from anyone else on wine-devel, I > > would suggest resubmitting as one patch with correct indentation as > > James suggested. If you don't see it committed after a while (maybe a > > week or so, maybe longer) I would either get in touch with the list > > again or try to get in touch with Alexandre to see if he has any > > specific comments. > > > > Hope that helps. > > > > Misha > Also, there are no changes to tests that show that the uninstaller > changes are adding/correcting behavior so it matches windows. Unit > tests would make the change more compelling. > > Chris > Actually that brings up a good point, does anything ever get written to Software\Microsoft\Windows\CurrentVersion in HKEY_CURRENT_USER in windows? I have no such key on my (rather plain) XP install, and from what I can tell wine MSI never writes to this key (see dlls/msi/registry.c, function MSIREG_OpenUninstallKey line 378) in HKEY_CURRENT_USER. Is this done by some specific application, or if not what was the original motivation for the patches? From what I can tell this was not in the emails you linked. Btw, I think it would be a good idea to include this kind of info when you submit the patches. Misha
Liberation
Hi, this is mainly a follow up to the thread here http://www.winehq.org/pipermail/wine-devel/2007-May/057092.html , to give it a new boost Question is, are there any plans to include Liberation fonts in wine? I gave it a good testing last two weeks, that is, i converted the fonts with Hans' Leidekkers script , from link above, and tested the "Arial-compatible" font quite a bit, with several applications. It all seems to work great, no issues / problems found. Several applications would be very happy , if this were to be included in wine. Any comments? Some of the tested apps: xchat --> just aborts silently without arial font Book worms adventures --> pops up a crash window without arial font d3d9-samples from DirectX 9.0 SDK --> Don't show any text without arial font + a lot more that just look prettier with arial font. - Yahoo! Mail is the world's favourite email. Don't settle for less, sign up for your freeaccount today.
Re: include/uxtheme.h : enum THEMESIZE
Nicolas (dyalog.com) wrote:
according to MSDN, include/uxtheme.h should define an "enum THEMESIZE",
which is typedefed to "THEME_SIZE",
rather than typedef the enum {} to "THEMESIZE" as it is currently.
http://msdn2.microsoft.com/en-us/library/ms649970.aspx
note that dlls/uxtheme/draw.c uses this definition so must also be patched.
Please merge those 2 changes into one patch as one without the other
make the Wine source to not compile anymore. And please use unified diff
format; the draw.c.patch isn't a unified diff.
bye
michael
--
Michael Stefaniuc Tel.: +49-711-96437-199
Sr. Network EngineerFax.: +49-711-96437-111
Red Hat GmbHEmail: [EMAIL PROTECTED]
Hauptstaetterstr. 58http://www.redhat.de/
D-70178 Stuttgart
Re: Uninstaller
Also, there are no changes to tests that show that the uninstaller changes are adding/correcting behavior so it matches windows. Unit tests would make the change more compelling. Chris On 6/14/07, Misha Koshelev <[EMAIL PROTECTED]> wrote: First of all, of course I am not Alexandre. But I have to say I think I agree with James on this, with regards to submitting just one patch with the correct spacing. I can see how seeing one patch without any spacing changes keeps the diff very simple (I am assuming this is why you submitted your patches in this way), but at the same time I would assume that if Alexandre really wants to see what changed in this way after applying the one patch you will send with correct spacing, he can just type: git-diff -b and see something very similar to your patch #1 (ignores whitespace, same effect). Other than that, I did not see anything obviously wrong with the patch upon a quick look. If you don't hear from anyone else on wine-devel, I would suggest resubmitting as one patch with correct indentation as James suggested. If you don't see it committed after a while (maybe a week or so, maybe longer) I would either get in touch with the list again or try to get in touch with Alexandre to see if he has any specific comments. Hope that helps. Misha
Re: user32: improve cut/copy/paste behavior of password edit boxes
On 6/14/07, Vitaly Lipatov <[EMAIL PROTECTED]> wrote: В сообщении от 14 июня 2007 Lei Zhang написал(a): > Hi, > > This patch prevents cutting/copying text from edit boxes with the > ES_PASSWORD style. It also corrects the paste behavior of password Why we need prevent it? > edit boxes when the clipboard is empty. -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru Because that's the proper behavior on Windows.
Re: Juan Lang : comdlg32: Initialize file dialog controls before creating dialog.
On 6/13/07, Juan Lang <[EMAIL PROTECTED]> wrote: > With this patch, the bottom of file dialogs are cut off such that the > file type dropdown and the cancel button can barely be seen. In which apps? I just looked at notepad and it looks fine to me. Also, this does correct a crash, so I'm pretty sure it's (mostly) correct. --Juan Password Safe, http://passwordsafe.sourceforge.net/ is one such program. It looks like a section of FILEDLG95_InitControls() checks fodInfos->DlgInfos.hwndCustomDlg. When you switched the two statements, fodInfos->DlgInfos.hwndCustomDlg always came up NULL in FILEDLG95_InitControls(). I'll send in a patch.
Re: [3/5] WineD3D: Present does not clear the depth stencil
On 14/06/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote: > It sounds a bit questionable to have different behaviour depending on > the debug channel. My idea is that such a clear is not needed, but costly, and I left it there for debugging. Microsoft says that the debug runtime does that too. We don't have a debug runtime, but our debug channels are closest to that. If you really want to use a debugchannel for that, I don't think you should use an existing one.
Re: [3/5] WineD3D: Present does not clear the depth stencil
> It sounds a bit questionable to have different behaviour depending on > the debug channel. My idea is that such a clear is not needed, but costly, and I left it there for debugging. Microsoft says that the debug runtime does that too. We don't have a debug runtime, but our debug channels are closest to that.
Re: [3/5] WineD3D: Present does not clear the depth stencil
On 14/06/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote: The patch removes the clearing from Present, except for the DISCARD swap effect if the d3d trace channel is on. It sounds a bit questionable to have different behaviour depending on the debug channel.
Re: user32: improve cut/copy/paste behavior of password edit boxes
В сообщении от 14 июня 2007 Lei Zhang написал(a): > Hi, > > This patch prevents cutting/copying text from edit boxes with the > ES_PASSWORD style. It also corrects the paste behavior of password Why we need prevent it? > edit boxes when the clipboard is empty. -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru
