Re: hal: add stub for ExAcquireFastMutex
On Tuesday 09 December 2008 03:52:01 ricardo filipe wrote: this is for http://bugs.winehq.org/show_bug.cgi?id=12628 This is fastcall function. It should be defined like KfAcquireSpinLock.
Re: [3/4]
2008/12/8 Stefan Dösinger [EMAIL PROTECTED]: Does the patch have any other advantages besides making the fixed function state handlers somewhat simpler though? I'm not sure if introducing a dependency on the state tracker in the shader backend is worth this. (I've got a better way to avoid redundant constant loads). The double loading fix was the main intention The other thing I intend with the patch is to move the GLSL shader-constant dependency checks to the GLSL code where it belongs The patch also starts to untie vertex and pixel shaders where we can(read ARB). I think it is wrong that we tie vertex and pixel shaders together in the shader backend interface because one implementation needs it.(On a hypothetical point, we need this for a nvts or atifs shader backend(*)). This might conflict with your intentions with the patch you mentioned above though, in that case we should not do that. The patch essentially adds a version to the constants and throws them in a queue. The disadvantage is that setting a constant becomes a bit more expensive, and cache usage becomes a bit worse if you have to load constants from deeper in the tree, but it still gives me about 10 extra fps in the CSS stress test. I don't see how setting vertex and fragment shaders at the same time hurts us that much, it just gives the shader backend a certain degree of freedom. Please also keep issue 20 from ARB_geometry_shader4 in mind. While it's possible to do crazy stuff like mixing ARB_vertex_program with fragment shaders, you can't mix ARB_vertex_program with a geometry shader. On the other hand, if you really wanted to do that kind of mixing, you could just create two backends and always pass FALSE for usePS to one backend, and always pass FALSE for useVS to the other. It's not impossible, just ugly. Splitting the shader backend doesn't change anything there. That it might not be trivial isn't really an argument against it. Either way, this is pretty much a separate issue from the original patch. The thing is just that this topic comes back every other patch, and I feel like running in a cicrcle having the same arguments over that point again and again... I do have an opinion on how the shader backend should fit in with the rest of the code. So far, I haven't heard anything that would make me change that opinion.
Re: WineHQ redesign
Jeremy Newman [EMAIL PROTECTED] writes: http://wine.codeweavers.com/winehq_new/ Is it possible to add some preload magic for the impressed button images? Otherwise the buttons disappear for a moment when I hover above them the first time. -- Cheers, Feri.
Re: Gecko package
Ok than I will start using the new version when it's ready. It' s a good thing that someone is working on a update. thank you Marco Jacek Caban schreef: Dan Kegel wrote: marco [EMAIL PROTECTED] wrote: And what do we do for now ? Is it still wise to distribute a old version, what are the risk that someone can use a gecko bug and do some harm in linux or is that not very likely with wine ? Either a) wait for Jacek's updated gecko + build procedure or b) coax Jacek into documenting the build procedure for the old gecko, and do an update with the latest security updates using his procedure If you're in a hurry, and have some manpower to throw at it, b) is possible. I should have first new version for testing this week. I will then document build procedure and start some discussion about Gecko releases. Also note that we don't want distributions to build their own Gecko. It often requires changes in Wine and it'd be pain to support. Jacek
Re: WineHQ redesign
I've made a few observations when using an 800x600 viewport: http://www.few.vu.nl/~rkg230/files/winehq-new-800x600.png The text alignment on the left could be improved by having the next line start on the same horizontal position. The thing about the Codeweavers logo is not that important since on a real 800x600 screen, even more would be invisible (the browser window takes some screen estate). Also, big chunk of white space on my native resolution (scaled down for easy viewing): http://www.few.vu.nl/~rkg230/files/winehq-new-1920x1200.png Doesn't look THAT bad, but I could fit some screenshots in there. (Kidding, I'll stop about the screenshots ;-) ) Remco
Re: WineHQ redesign
I still think that the tabs could use a little work - I hacked this together in Photoshop a little while ago: http://stephengentle.com/media/images/wine/tabs.png - ignore the lack of content and most of the layout... As for the rest of the site, the main thing I don't like is that everything is just a little too rounded. Apart from that, it's looking pretty good. Stephen
Re: uxtheme: fix a compiler warning
Am Dienstag, den 09.12.2008, 00:39 -0600 schrieb Austin English:
-MSSTYLES_GetNextInteger(lpValue, lpValueEnd, lpValue, g);
-if(MSSTYLES_GetNextInteger(lpValue, lpValueEnd, lpValue, b)) {
+if(MSSTYLES_GetNextInteger(lpValue, lpValueEnd, lpValue, r)
+MSSTYLES_GetNextInteger(lpValue, lpValueEnd, lpValue, g)
+MSSTYLES_GetNextInteger(lpValue, lpValueEnd, lpValue, b)) {
I would like to see the last two lines indented more than the if line.
Take a look at line 748 in msstyles.c to find a precedence case in the
file you are patching. In short, that would mean
+if(MSSTYLES_GetNextInteger(...)
+MSSTYLES_GetNextInteger(...)
+MSSTYLES_GetNextInteger(...))
+{
Regards,
Michael Karcher
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Re: WineHQ redesign
On Mon, Dec 8, 2008 at 6:57 PM, Jeremy Newman [EMAIL PROTECTED] wrote: http://wine.codeweavers.com/winehq_new/ The images which appear when hovering the main links have some white pixels in the upper left part, between the bright red border and the srinked original image. It would be nice if you could introduce some effect without the shrinking. Thanks, Alex
Re: Gecko package
Dan Kegel wrote: marco [EMAIL PROTECTED] wrote: And what do we do for now ? Is it still wise to distribute a old version, what are the risk that someone can use a gecko bug and do some harm in linux or is that not very likely with wine ? Either a) wait for Jacek's updated gecko + build procedure or b) coax Jacek into documenting the build procedure for the old gecko, and do an update with the latest security updates using his procedure If you're in a hurry, and have some manpower to throw at it, b) is possible. I should have first new version for testing this week. I will then document build procedure and start some discussion about Gecko releases. Also note that we don't want distributions to build their own Gecko. It often requires changes in Wine and it'd be pain to support. Jacek
RE: [3/4]
The patch essentially adds a version to the constants and throws them in a queue. The disadvantage is that setting a constant becomes a bit more expensive, and cache usage becomes a bit worse if you have to load constants from deeper in the tree, but it still gives me about 10 extra fps in the CSS stress test. Whoa, that's an impressive improvement! I didn't see that much room for improvement in the CS:S performance at all. How expensive is a shader_glsl_load_constant call if no constant was changed? I assume that no GL call is made in that case, I don't see how setting vertex and fragment shaders at the same time hurts us that much, it just gives the shader backend a certain degree of freedom. I'd argue that my patch gives the shader backend more freedom. A backend implementation is free to use the same function for vertexshader_select and fragmentshader_select, as we use the same prototype. All it has to do(or better, should do) is checking wether it will be called again via a isStateDirty check. However, this check is done in the current code already, just outside of the shader backend(ie, it is forced onto the backend even if it is not needed) Please also keep issue 20 from ARB_geometry_shader4 in mind. While it's possible to do crazy stuff like mixing ARB_vertex_program with fragment shaders, you can't mix ARB_vertex_program with a geometry shader. I don't care too much about mixing ARB with GLSL. It might be a neat trick for MacOS, but it doesn't work in the way we need it in the current architecture anyway. To work around those MacOS GLSL bugs we'd have to select the backend based on the concrete shader. Having a ARBvp+GLSLfrag shader backend selected at library load isn't any better than what we have now in terms of MacOS bugdodgeability. On the other hand, if you really wanted to do that kind of mixing, you could just create two backends and always pass FALSE for usePS to one backend, and always pass FALSE for useVS to the other. It's not impossible, just ugly. Splitting the shader backend doesn't change anything there. I'll come back to this should I ever send in an ATIfs or NVTS shader backend :-) . That solution is fine with me. I do have an opinion on how the shader backend should fit in with the rest of the code. So far, I haven't heard anything that would make me change that opinion. I think we have a different understanding of what the gobal state table infrastructure is supposed to be. I didn't intend it as a fixed function state table, but rather a tool for managing all sorts of states. It includes things like blending, the scissor test or even the index buffer, which are not affected by shaders at all(since they're neither part of the vertex, fragment or geometry pipeline). So I don't think limiting the state table to the fixed function pipeline would be correct, even if shaders sat on top of it. (yes, there are many fixed function states and just a few shader states, but that's due to the nature of the two pipelines) I don't think that the vertex shader bypasses the fixed function vertex pipeline argument works here either. We have such a relationship between states elsewhere, e.g. D3DRS_LIGHTING overrides the lights, D3DRS_ALPHABLENDENABLE overrides various alpha states etc. I'm not convinced that shaders are special in any way. There's also the point about skipping applying fixed function states when the shader is active. I really think this should be up to the fragment pipeline implementation. The ARB fragment pipeline replacement skips the states(because it has to), the fixed function GL pipeline doesn't. Functionally it doesn't make any difference for the ffp pipeline. Performance wise you can argue both. If we apply the states it makes switching the shader on and off cheaper, if we do not apply them it helps broken games.
Regression in 'Environment Bump Mapping' test (3DMark2001SE) with wine-1.1.10
Console says: fixme:d3d_shader:register_for_arg Unknown source argument 255 And picture is odd with 1.1.10, in 1.1.9= it was good i think. I don't know exactly, but this regression can be due changes in ati_fragment_shader.c. http://i263.photobucket.com/albums/ii149/smokidungeon/wine-1110.jpg http://i263.photobucket.com/albums/ii149/smokidungeon/wine-119.jpg Xorg-1.5.3 Mesa-7.2 (r200) ATI 9250
Re: Regression in 'Environment Bump Mapping' test (3DMark2001SE) with wine-1.1.10
Milan Kostić [EMAIL PROTECTED] at Dec 9, 2008 7:27 AM (MST) wrote about: Regression in 'Environment Bump Mapping' test (3DMark2001SE) withwine-1.1.10 Console says: fixme:d3d_shader:register_for_arg Unknown source argument 255 And picture is odd with 1.1.10, in 1.1.9= it was good i think. I don't know exactly, but this regression can be due changes in ati_fragment_shader.c. Xorg-1.5.3 Mesa-7.2 (r200) ATI 9250 Can you run a regression test to discover where Wine broke this? James McKenzie
Re: Huw Davies : opengl/tests: Skip tests if we can't find a pixel format.
On Mon, Dec 08, 2008 at 01:44:41PM +0100, Alexandre Julliard wrote: Huw Davies [EMAIL PROTECTED] writes: Hi Alexandre, This wasn't what I intended my patch to do. The problem is that Wine's ChoosePixelFormat() rets 0 on XServers without glX. The win_skip results in a test failure. My patch was intended to mark this as a todo_wine. We could have a todo_wine around the win_skip, though I'm not quite convinced that having the opengl32 test succeed without opengl support is the right thing to do. Ok, I'll send in a patch with todo_wine and let you decide. My feeling was that without opengl support we should skip the opengl32 tests, hence the skip in the original patch. The todo_wine was to flag Wine's ChoosePixelFormat bug. Huw. -- [EMAIL PROTECTED]
Re: Huw Davies : opengl/tests: Skip tests if we can't find a pixel format.
Huw Davies [EMAIL PROTECTED] writes: Ok, I'll send in a patch with todo_wine and let you decide. My feeling was that without opengl support we should skip the opengl32 tests, hence the skip in the original patch. The todo_wine was to flag Wine's ChoosePixelFormat bug. My concern is that my OpenGL setup gets regularly broken by Debian updates, and I notice it when tests start failing. If all the tests just skip, I may end up committing patches that haven't been regression tested. So I'd like to have at least one test failure when OpenGL is compiled in but not working. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Regression in 'Environment Bump Mapping' test (3DMark2001SE) with wine-1.1.10
I've attached a patch to bug 16412 (http://bugs.winehq.org/show_bug.cgi?id=16412) that might help.
Re: [msi/tests] Run tests again on Win9x and NT4
On Tue, Dec 9, 2008 at 9:32 AM, Paul Vriens [EMAIL PROTECTED] wrote: Hi, MsiEnumPatchesExA is not implemented below NT4. Changelog Run tests again on Win9x and NT4 -r = MsiEnumPatchesExA(, usersid, MSIINSTALLCONTEXT_USERUNMANAGED, +r = pMsiEnumPatchesExA(, usersid, MSIINSTALLCONTEXT_USERUNMANAGED, MSIPATCHSTATE_ALL, 0, patchcode, targetprod, context, targetsid, size); Please align the extra parameter lines with the extra character in the first line. -- James Hawkins
Re: [msi/tests] Run tests again on Win9x and NT4
James Hawkins wrote: On Tue, Dec 9, 2008 at 9:32 AM, Paul Vriens [EMAIL PROTECTED] wrote: Hi, MsiEnumPatchesExA is not implemented below NT4. Changelog Run tests again on Win9x and NT4 -r = MsiEnumPatchesExA(, usersid, MSIINSTALLCONTEXT_USERUNMANAGED, +r = pMsiEnumPatchesExA(, usersid, MSIINSTALLCONTEXT_USERUNMANAGED, MSIPATCHSTATE_ALL, 0, patchcode, targetprod, context, targetsid, size); Please align the extra parameter lines with the extra character in the first line. Sorry, did it again. Will resend. -- Cheers, Paul.
Re: WineHQ redesign
I prefer the rounded tabs. -Newman Stephen Gentle wrote: I still think that the tabs could use a little work - I hacked this together in Photoshop a little while ago: http://stephengentle.com/media/images/wine/tabs.png - ignore the lack of content and most of the layout... As for the rest of the site, the main thing I don't like is that everything is just a little too rounded. Apart from that, it's looking pretty good. Stephen
Re: WineHQ redesign
It's possible. -Newman Ferenc Wagner wrote: Jeremy Newman [EMAIL PROTECTED] writes: http://wine.codeweavers.com/winehq_new/ Is it possible to add some preload magic for the impressed button images? Otherwise the buttons disappear for a moment when I hover above them the first time.
Re: Alexandre Julliard : include: Added some definitions for x86_64 exception handling.
On Tue, Dec 9, 2008 at 7:23 AM, Alexandre Julliard [EMAIL PROTECTED] wrote: Author: Alexandre Julliard [EMAIL PROTECTED] Date: Mon Dec 8 19:27:59 2008 +0100 include: Added some definitions for x86_64 exception handling. was this a typo? You also added ia64/itanium stuff on this commit. -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo
Re: oleaut32: add PICTYPE_NONE and PICTYPE_UNINITIALIZED to IPicture::Render
On Tue, 9 Dec 2008, Nikolay Sivov wrote: + case PICTYPE_NONE: + case PICTYPE_UNINITIALIZED: + /* undocumented code */ + return 0x800A017C; This code looks suspiciously like CTL_E_INVALIDPROPERTYVALUE (from olectl.h) to me...
Re: WineHQ redesign
On Tue, 09 Dec 2008 10:08:56 -0600 The background on the forum is now entirely black. Links are red, but messages are completely unreadable. -- Rosanne DiMesio [EMAIL PROTECTED]
Re: Alexandre Julliard : include: Added some definitions for x86_64 exception handling.
Steven Edwards [EMAIL PROTECTED] writes: On Tue, Dec 9, 2008 at 7:23 AM, Alexandre Julliard [EMAIL PROTECTED] wrote: Author: Alexandre Julliard [EMAIL PROTECTED] Date: Mon Dec 8 19:27:59 2008 +0100 include: Added some definitions for x86_64 exception handling. was this a typo? You also added ia64/itanium stuff on this commit. A couple, yes, but I don't have any plans to implement ia64 exception handling if that's what you are wondering... -- Alexandre Julliard [EMAIL PROTECTED]
Re: uxtheme: fix a compiler warning
On Tue, Dec 9, 2008 at 2:35 AM, Michael Karcher
[EMAIL PROTECTED] wrote:
Am Dienstag, den 09.12.2008, 00:39 -0600 schrieb Austin English:
-MSSTYLES_GetNextInteger(lpValue, lpValueEnd, lpValue, g);
-if(MSSTYLES_GetNextInteger(lpValue, lpValueEnd, lpValue, b)) {
+if(MSSTYLES_GetNextInteger(lpValue, lpValueEnd, lpValue, r)
+MSSTYLES_GetNextInteger(lpValue, lpValueEnd, lpValue, g)
+MSSTYLES_GetNextInteger(lpValue, lpValueEnd, lpValue, b)) {
I would like to see the last two lines indented more than the if line.
Take a look at line 748 in msstyles.c to find a precedence case in the
file you are patching. In short, that would mean
+if(MSSTYLES_GetNextInteger(...)
+MSSTYLES_GetNextInteger(...)
+MSSTYLES_GetNextInteger(...))
+{
Regards,
Michael Karcher
Patch was already committed. If I fix something else in this file,
I'll update this as well. Otherwise, feel free to do so.
--
-Austin
Re: WineHQ redesign
Some issues: 1. The wiki is not using the new layout. 2. In the forums top-level page, the navigation is displayed in one big list that pushes the forum content to the bottom of the screen. 3. The WineHQ link on the forums page links back to the forums page and not the main website. Looking good, otherwise. - Reece
Re: WineHQ redesign
Hi, I've been looking at the new WineHQ webiste and it looks really nice, but it doesn't support older browsers. Today I tried to test it at my computer at work and the website doesn't work properly on IE6: http://alarm-clock.54.pl/winehq.png IE6 doesn't support transparency in PNG's. If WINE is to attract Windows users to Linux, it needs to display the website properly, or at least show a message to upgrade to a newer browser. Cheers Dnia 2008-12-09, wto o godzinie 10:08 -0600, Jeremy Newman pisze: It's possible. -Newman Ferenc Wagner wrote: Jeremy Newman [EMAIL PROTECTED] writes: http://wine.codeweavers.com/winehq_new/ Is it possible to add some preload magic for the impressed button images? Otherwise the buttons disappear for a moment when I hover above them the first time.
Re: WineHQ redesign
Do you have javascript disabled? I have a javascript workaround that makes PNGs load the alpha correctly under IE6. -Newman Tomasz Sałaciński wrote: Hi, I've been looking at the new WineHQ webiste and it looks really nice, but it doesn't support older browsers. Today I tried to test it at my computer at work and the website doesn't work properly on IE6: http://alarm-clock.54.pl/winehq.png IE6 doesn't support transparency in PNG's. If WINE is to attract Windows users to Linux, it needs to display the website properly, or at least show a message to upgrade to a newer browser. Cheers Dnia 2008-12-09, wto o godzinie 10:08 -0600, Jeremy Newman pisze: It's possible. -Newman Ferenc Wagner wrote: Jeremy Newman [EMAIL PROTECTED] writes: http://wine.codeweavers.com/winehq_new/ Is it possible to add some preload magic for the impressed button images? Otherwise the buttons disappear for a moment when I hover above them the first time.
Re: WineHQ redesign
2008/12/9 Reece Dunn [EMAIL PROTECTED]: Some issues: 1. The wiki is not using the new layout. 2. In the forums top-level page, the navigation is displayed in one big list that pushes the forum content to the bottom of the screen. 3. The WineHQ link on the forums page links back to the forums page and not the main website. Other issues: 1. the navigation links at the top produce the rollover hover correctly when the mouse is over the button, but you can only click on the text area; this is confusing, as the whole tab should be the link. 2. the mini-navigation panes -- these also only display the link sections on the text, their hit area does not span the entire width (missing a display: block; ??) and there is no hover colour. Great work, - Reece
Re: WineHQ redesign
Honestly - I am never using IE, I even don't know how to enable Javascript. I've changed the security level from Custom to Medium - it fixed the problem. But since the images are not moving, why someone can't draw the correct background onto them, so people in corporate networks when taking decision whatever to use LinuxWine or not won't have bad first impression when looking at WINE's website. These people don't know that IE doesn't support alpha in PNG's. Dnia 2008-12-09, wto o godzinie 11:44 -0600, Jeremy Newman pisze: Do you have javascript disabled? I have a javascript workaround that makes PNGs load the alpha correctly under IE6. -Newman Tomasz Sałaciński wrote: Hi, I've been looking at the new WineHQ webiste and it looks really nice, but it doesn't support older browsers. Today I tried to test it at my computer at work and the website doesn't work properly on IE6: http://alarm-clock.54.pl/winehq.png IE6 doesn't support transparency in PNG's. If WINE is to attract Windows users to Linux, it needs to display the website properly, or at least show a message to upgrade to a newer browser. Cheers Dnia 2008-12-09, wto o godzinie 10:08 -0600, Jeremy Newman pisze: It's possible. -Newman Ferenc Wagner wrote: Jeremy Newman [EMAIL PROTECTED] writes: http://wine.codeweavers.com/winehq_new/ Is it possible to add some preload magic for the impressed button images? Otherwise the buttons disappear for a moment when I hover above them the first time.
Re: WineHQ redesign
Reece Dunn wrote: Some issues: 1. The wiki is not using the new layout. Dimi is currently updating the Wiki. 2. In the forums top-level page, the navigation is displayed in one big list that pushes the forum content to the bottom of the screen. 3. The WineHQ link on the forums page links back to the forums page and not the main website. Side effects of you loading the page while I was still editing it. Should be good now. -Newman
new web design takes too much space on left
When working on a notebook computer, I find myself resenting the amount of real estate taken by the left hand navbar in bugzilla. I bet we could shave 20% of that space without bothering anyone...
Re: [PATCH] gdi32: Use font substitution for source font when linking fonts.
On Fri, Dec 5, 2008 at 4:46 PM, Lei Zhang [EMAIL PROTECTED] wrote: Hi, This is sort of related to bug 16325. I've noticed some applications use the MS Shell Dlg font to display CJK text and fails. In HKLM\Software\Microsoft\Windows NT\CurrentVersion\FontSubstitutes, MS Shell Dlg is set to Tahoma. I tried adding a font link for Tahoma in HKLM\Software\Microsoft\Windows NT\CurrentVersion\FontLink\Systemlink, but that didn't seem to help. I then tried adding a font link for MS Shell Dlg, but that didn't have any effect either. Taking a closer look, in init_system_links(), both the Tahoma and MS Shell Dlg entries in Systemlink create a Tahoma entry in memory, due to the MS Shell Dlg - Tahoma font substitution. However, in create_child_font_list(), we check the in-memory list for MS Shell Dlg, which can never be found. With this additional font substitution, create_child_font_list() looks for Tahoma instead, and the CJK text gets displayed properly. Anything wrong with this patch?
Re: WineHQ redesign
On Mon, Dec 8, 2008 at 10:40 AM, Jeremy Newman [EMAIL PROTECTED]wrote: I have committed my work for the WineHQ redesign. I've also updated the AppDB and Bugzilla codebases with the new theme. By the way, the new site looks great on a Blackberry using Opera Mini or even the regular Blackberry browser. Great work! -Brian
Re: new web design takes too much space on left
On Tue, Dec 9, 2008 at 10:38 AM, Dan Kegel [EMAIL PROTECTED] wrote: When working on a notebook computer, I find myself resenting the amount of real estate taken by the left hand navbar in bugzilla. I bet we could shave 20% of that space without bothering anyone... The images in the background are big enough such that if you increase your browser font size up to a certain point, it would still fit. It would be nice if the bg image can extend outwards according to the text size. I've seen it on some sites, but not sure what the css magic is.
Re: new web design takes too much space on left
I'm done, this design has taken enough of my time. You will need to generate patches for ALL the sites if you want to change it now. -Newman Dan Kegel wrote: When working on a notebook computer, I find myself resenting the amount of real estate taken by the left hand navbar in bugzilla. I bet we could shave 20% of that space without bothering anyone...
Re: WineHQ redesign
On Monday 08 December 2008 22:49:15 Jeremy Newman wrote: I tweaked the font sizes a bit. -Newman Tijl Coosemans wrote: On Monday 08 December 2008 20:42:30 Jeremy Newman wrote: This is because of the font-size: medium. IE Renders medium text much larger than Gecko and Webkit. I prefer to use font-size: 12px;, but that disables IEs ability to change the text size via the page drop down. I will revert back to my method as this gives me the fine grain control over font size that I desire. That makes it unreadable on high DPI screens. What about 10pt or something? I have some issues with the side bar of AppDB because the style for mouse hover changes the font weight. This should be avoided on any web site. Depending on browser and settings this can cause insane flickering - changing the layout of the text in frame leaves the mouse pointer outside the text so text changes to non-hover then back to hover ad infinitum. Paul Chitescu
Re: defwnd: implement handling of WM_INPUTLANGCHANGE
doh! good catch! thanks, i will correct that and resend. -aric Paul Chitescu wrote: On Tuesday 09 December 2008 21:17:32 Aric Stewart wrote: [...] +while (win_array[count]) +SendMessageA( win_array[count], WM_INPUTLANGCHANGE, wParam, lParam); Missing a ++ here ?
Re: Одговор: Regressio n in 'Environment Bump Mapping' test (3DMark2001SE) with wine-1.1.10
2008/12/9 Milan Kostić [EMAIL PROTECTED]: Henry, with this patch 'Environment Bump Mapping' test is looking good, but 'fixme:d3d_shader:register_for_arg Unknown source argument 255' is still there - continous in many cases, not just in 3DMark2001SE... Is this fixme useless, when this works? Stefan has a fix for that.
Re: WineHQ redesign
Jeremy Newman wrote: I have committed my work for the WineHQ redesign. I've also updated the AppDB and Bugzilla codebases with the new theme. The font on bugzilla looks 2x bigger then it's used to. The strange part it's only the bugzilla part that looks big. Menus are fine. Vitaliy
Re: appdb sidebar has issues
What browser are you using? For me the sidebar text is displayed within the intended confinement, however it is smaller than the rest of the AppDB text and thus a tiny bit harder to read than it should be. Firefox 3 Alexander On Tuesday 09 December 2008 20:47:10 ricardo filipe wrote: http://img186.imageshack.us/my.php?image=semttulojh9.jpg some links do not fit the appdb sidebar and there are blank spaces o.0 also, shouldn't the background extend to all site? now it's confined to the homepage size _ Conheça o Windows Live Spaces, a rede de relacionamentos do Messenger! http://www.amigosdomessenger.com.br/
Re: WineHQ redesign
It is in sync with the rest of the site(s). It is now using 10pt font instead of 10px. Fix it for someone, break it for someone else. -Newman Vitaliy Margolen wrote: Jeremy Newman wrote: I have committed my work for the WineHQ redesign. I've also updated the AppDB and Bugzilla codebases with the new theme. The font on bugzilla looks 2x bigger then it's used to. The strange part it's only the bugzilla part that looks big. Menus are fine. Vitaliy
Re: appdb sidebar has issues
Fixed the blank spaces thing that logged in users were seeing. Been a long time since I played with the appdb codebase. -Newman Alexander Nicolaysen Sørnes wrote: What browser are you using? For me the sidebar text is displayed within the intended confinement, however it is smaller than the rest of the AppDB text and thus a tiny bit harder to read than it should be. Firefox 3 Alexander On Tuesday 09 December 2008 20:47:10 ricardo filipe wrote: http://img186.imageshack.us/my.php?image=semttulojh9.jpg some links do not fit the appdb sidebar and there are blank spaces o.0 also, shouldn't the background extend to all site? now it's confined to the homepage size _ Conheça o Windows Live Spaces, a rede de relacionamentos do Messenger! http://www.amigosdomessenger.com.br/
RE: appdb sidebar has issues
i'm on firefox 3 too, but it's fixed now :) thx jeremy. From: [EMAIL PROTECTED] To: wine-devel@winehq.org; [EMAIL PROTECTED] Subject: Re: appdb sidebar has issues Date: Tue, 9 Dec 2008 21:40:54 +0100 What browser are you using? For me the sidebar text is displayed within the intended confinement, however it is smaller than the rest of the AppDB text and thus a tiny bit harder to read than it should be. Firefox 3 Alexander On Tuesday 09 December 2008 20:47:10 ricardo filipe wrote: http://img186.imageshack.us/my.php?image=semttulojh9.jpg some links do not fit the appdb sidebar and there are blank spaces o.0 also, shouldn't the background extend to all site? now it's confined to the homepage size _ Conheça o Windows Live Spaces, a rede de relacionamentos do Messenger! http://www.amigosdomessenger.com.br/ _ Confira vídeos com notícias do NY Times, gols direto do Lance, videocassetadas e muito mais no MSN Video! http://video.msn.com/?mkt=pt-br
Re: oleaut32: add PICTYPE_NONE and PICTYPE_UNINITIALIZED to IPicture::Render
Jeremy Drake wrote: On Tue, 9 Dec 2008, Nikolay Sivov wrote: + case PICTYPE_NONE: + case PICTYPE_UNINITIALIZED: + /* undocumented code */ + return 0x800A017C; This code looks suspiciously like CTL_E_INVALIDPROPERTYVALUE (from olectl.h) to me... You're right. It returns CTL_E_INVALIDPROPERTYVALUE when at least one of dimensions is zero. I'll update a patch.
RE: Одговор: Regression in 'Environment Bump Mapping' test (3DMark2001SE) with wine-1.1.10
Henry, with this patch 'Environment Bump Mapping' test is looking good, but 'fixme:d3d_shader:register_for_arg Unknown source argument 255' is still there - continous in many cases, not just in 3DMark2001SE... Is this fixme useless, when this works? Stefan has a fix for that. Milan, the arguments that the FIXME warns about are all unused. Known unused arguments are marked with a special value(ARG_UNUSED) to suppress this fixme. A code elsewhere incorrectly sets a different value accidentally, so the FIXME isn't suppressed properly. It is harmless though. The value is indeed unknown, but it isn't used anywhere either.
Re: App hang on creating modal dialog
Dan Kegel wrote:
Jeff wrote:
I'm trying to solve my bug 16346
http://bugs.winehq.org/show_bug.cgi?id=16346
...
I'm trying to figure out where in the wine code I should look for a
system that might be eating all of the messages intended for my
application. Can anyone point me in the right direction?
I dunno, but that test case is nice and small. Can you
turn it into a wine conformance test? That will make it
even more likely somebody helps find a solution...
- Dan
I'm not sure how to create a non-interactive unit test case for this,
since it involves interplay with the window manager and results in a
hang. If someone could point out a similar test case I could pattern
mine on, that would be great.
On the solution end of things, I have discovered that the following
patch resolves the problem. The issue is that the MessageBox is created
from within a WM_ACTIVATEAPP message which initiated from the X11
driver. The X11 driver is coded to prevent nested events from being
handled.
Is there a good reason to prevent nested X11 events from being handled?
Jeff
From: Jeff Miller [EMAIL PROTECTED]
Date: Tue, 9 Dec 2008 18:33:20 -0800
Subject: Fix bug #16346 by allowing nested X11 events to be handled.
---
dlls/winex11.drv/event.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/dlls/winex11.drv/event.c b/dlls/winex11.drv/event.c
index 5f7ebef..83a4a82 100644
--- a/dlls/winex11.drv/event.c
+++ b/dlls/winex11.drv/event.c
@@ -403,8 +403,6 @@ DWORD X11DRV_MsgWaitForMultipleObjectsEx( DWORD
count, const HANDLE *handles,
timeout, flags MWMO_ALERTABLE );
}
-if (data-current_event) mask = 0; /* don't process nested events */
-
if (process_events( data-display, filter_event, mask )) ret =
count - 1;
else if (count || timeout)
{
--
1.6.0.3
Re: App hang on creating modal dialog
On Tue, Dec 9, 2008 at 6:48 PM, Jeff Miller [EMAIL PROTECTED] wrote: http://bugs.winehq.org/show_bug.cgi?id=16346 I'm not sure how to create a non-interactive unit test case for this, since it involves interplay with the window manager and results in a hang. Does it hang all of wine? If not, maybe you could have a second thread doing a timeout. If it *does* hang all of wine, that's an argument for adding timeouts to make test.
Patchwatcher status: offline
My house is being rewired, so Patchwatcher is offline for a day.
Re: winetest: fix a compiler warning
These are addressing some very weird cases. They should be an
improvement, but I wonder if we can't do better.
void xprintf (const char *fmt, ...)
{
va_list ap;
-size_t size;
+size_t size = 0;
DWORD written;
It would make more sense, IMO, to update the vstrfmtmake function to
also set *lenp to 0, if lenp is set, when it runs out of memory.
Winetest uses that function indirectly in other places, and one has a
similar problem. (Of course, if we did run out of memory, it's a
pretty dismal situation, and the returned string will be NULL, but at
least xprintf will silently fail instead of crashing.)
extract_test (struct wine_test *test, const char *dir, LPTSTR res_name)
{
BYTE* code;
-DWORD size;
+DWORD size = 0;
For this to matter, the extract_rcdata call has to fail. This is,
again, a pretty dismal situation. In this case, we'll later be writing
data starting at NULL, and of an undefined, or with this change 0,
length. I don't know if that actually works, and it may be better to
give up early.
Vincent Povirk
