December 2008 - Wine-Devel - list.winehq.org

Re: WineHQ redesign

by Stephen Gentle

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

Dec. 9, 2008

Re: WineHQ redesign

by Remco

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

Dec. 9, 2008

Re: Gecko package

by Marco Meijer

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 <marco(a)mandrivaclub.nl> 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 >

Dec. 9, 2008

Re: Gecko package

by Jacek Caban

Dan Kegel wrote: > marco <marco(a)mandrivaclub.nl> 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

Dec. 9, 2008

Re: WineHQ redesign

by Ferenc Wagner

Jeremy Newman <jnewman(a)codeweavers.com> 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.

Dec. 9, 2008

Re: [3/4]

by Henri Verbeet

2008/12/8 Stefan Dösinger <stefan(a)codeweavers.com>: >> 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.

Dec. 9, 2008

Re: hal: add stub for ExAcquireFastMutex

by Alexander Morozov

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.

Dec. 9, 2008

Re: uxtheme: fix a compiler warning

by Michael Karcher

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

Dec. 9, 2008

Re: WineHQ redesign

by Paul Vriens

Jeremy Newman wrote: > Screenshot please. I have not seen that myself in my testing. > > Paul Vriens wrote: >> Jeremy Newman wrote: >>> I have posted a working copy of the new website here: >>> >>> http://wine.codeweavers.com/winehq_new/ >>> >>> -Newman >>> >> >> Hi Jer, >> >> The big icons are cut off at the bottom (at least on my Firefox 3.0.4). >> >> I also see that the news is up-to-date as it mentions 1.1.10 but the >> "Latest releases" section show 1.1.9. >> > Things look fine now (I see you added height to ul.winehq_menu li). -- Cheers, Paul.

Dec. 9, 2008

Re: Gecko package

by Dan Kegel

marco <marco(a)mandrivaclub.nl> 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.

Dec. 8, 2008

RE: comdlg32: includeobject needs to notify window with CDN_INCLUDEITEM

by ricardo filipe

so i just saw this insightful comment in filedlg.c: * FIXME: CDN_FILEOK is wrong implemented, other CDN_ messages likely too must be why it doesn't really notify the window :\ send_message() needs to be fixed for this. > From: ricardo_barbano(a)hotmail.com > To: wine-devel(a)winehq.org > Subject: comdlg32: includeobject needs to notify window with CDN_INCLUDEITEM > Date: Sun, 7 Dec 2008 20:48:50 +0000 > > > this is related to http://bugs.winehq.org/show_bug.cgi?id=8072 > > so... i decided to investigate why didn't media player classic show the files when browsing... > i've been debugging this for some days but found the problem, although it's not > quite solved, so if anyone has any idea please share. > > the good thing was that mpc source code is available so i could see how it was > implemented. > i found out that includeObject is supposed to notify the browsing window with > CDN_INCLUDEITEM that wasn't yet declared in wine. > the problem is that i get: > > err:pidl:_ILSimpleGetTextW -- no text > err:pidl:_ILSimpleGetTextW -- no text > trace:commdlg:SendCustomDlgNotificationMessage RET NOTIFY > trace:commdlg:SendCustomDlgNotificationMessage Retval: 0x00000000 > > and the notify isn't successful :\ > any ideas? > > patch in attachment... > > _________________________________________________________________ > 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

Dec. 8, 2008

Re: Gecko package

by marco

Ok thank you, 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 ? marco Dan Kegel schreef: > marco meijer wrote: > >> I have a question about wine_gecko-0.1.0.cab >> This package is from 2007-05-30 11:42 and in the mean time firefox >> had a lot of security updates. >> Is it still save to distribute wine_gecko-0.1.0.cab ? >> > > We'd like to move to a newer one. > See http://bugs.winehq.org/show_bug.cgi?id=16198 > - Dan > >

Dec. 8, 2008

Re: WineHQ redesign

by Jeremy Newman

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? > >

Dec. 8, 2008

Re: WineHQ redesign

by Tijl Coosemans

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?

Dec. 8, 2008

Re: WineHQ redesign

by Jeremy Newman

That link predates the move to our own forums. I will change that. -Newman Rosanne DiMesio wrote: > On Mon, 08 Dec 2008 11:57:59 -0600 > Jeremy Newman <jnewman(a)codeweavers.com> wrote: > >> I have posted a working copy of the new website here: >> >> http://wine.codeweavers.com/winehq_new/ >> > > Why does the forum link on http://wine.codeweavers.com/winehq_new/help/ lead to http://groups.google.com/group/comp.emulators.ms-windows.wine/topics and not the actual forum on WineHQ? >

Dec. 8, 2008

Re: WineHQ redesign

by Jeremy Newman

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. -Newman Branan Riley wrote: > On Mon, Dec 8, 2008 at 9:57 AM, Jeremy Newman <jnewman(a)codeweavers.com> wrote: >> I have posted a working copy of the new website here: >> >> http://wine.codeweavers.com/winehq_new/ >> >> -Newman > > I've got lots of vertical space, but the page is using short white > boxes with scrollbars. This is IE7 on Windows Vista. Looks like there > a few layout issues with IE, actually: > > * Google box is below the search label, overlapping releases box > * Releases box isn't tall enough to show both releases. (intentional?) > * Text for buttons along top is much larger than the button boxes > > I'd expect many people looking to switch to Linux might be looking at > how well Wine works before doing so, so having good IE support is > important. (I never thought I'd advocate fixing a page to work with > broken IE *sighs*) > > screenshot: http://img152.imageshack.us/my.php?image=winehqtr4.jpg > > -Branan > >

Dec. 8, 2008

Re: WineHQ redesign

by Jeremy Newman

Screenshot please. I have not seen that myself in my testing. Paul Vriens wrote: > Jeremy Newman wrote: >> I have posted a working copy of the new website here: >> >> http://wine.codeweavers.com/winehq_new/ >> >> -Newman >> > > Hi Jer, > > The big icons are cut off at the bottom (at least on my Firefox 3.0.4). > > I also see that the news is up-to-date as it mentions 1.1.10 but the "Latest > releases" section show 1.1.9. >

Dec. 8, 2008

Re: WineHQ redesign

by Jeremy Newman

Submit a patch if you want to revise the text. -Newman Juan Lang wrote: >> I have posted a working copy of the new website here: >> >> http://wine.codeweavers.com/winehq_new/ > > The About page says, "Wine is still under development, and it is not > yet suitable for general use. Nevertheless, many people find it useful > in running a growing number of Windows programs." Surely this is out > of date since at least version 1.0? > --Juan > >

Dec. 8, 2008

winex11.drv: Remove unneeded address-of operators from array names

by Andrew Talbot

Please do not apply this patch, it is wrong. -- Andy.

Dec. 8, 2008

Re: shell32.dll: Return SE_ERR_FNF if file not found before checking for associations

by Paul Chitescu

On Monday 08 December 2008 20:41:10 Paul Vriens wrote: > Paul Chitescu wrote: > > Changelog: > > shell32.dll: Return SE_ERR_FNF if file not found before checking for > > associations (which will fail anyway but with SE_ERR_NOASSOC). > > > > This fixes 6 out of the 12 shlexec test failures. > > > > > > ------------------------------------------------------------------------ > > Hi Paul. > > Not sure if Patchwatcher has sent you an email: > > http://kegel.com/wine/patchwatcher/results/971/1.log > > You have to fix the tests if you fix something in wine that removes the > need for a todo_wine in those tests. Uhh... if someone would just decode the todo flags in filename_tests[]... If I understand correctly todo = 0x0 when the problem is fixed? Paul

Dec. 8, 2008

Re: shell32.dll: Return SE_ERR_FNF if file not found before checking for associations

by Paul Vriens

Paul Chitescu wrote: > Changelog: > shell32.dll: Return SE_ERR_FNF if file not found before checking for > associations (which will fail anyway but with SE_ERR_NOASSOC). > > This fixes 6 out of the 12 shlexec test failures. > > > ------------------------------------------------------------------------ > > Hi Paul. Not sure if Patchwatcher has sent you an email: http://kegel.com/wine/patchwatcher/results/971/1.log You have to fix the tests if you fix something in wine that removes the need for a todo_wine in those tests. -- Cheers, Paul.

Dec. 8, 2008

Re: WineHQ redesign

by Rosanne DiMesio

On Mon, 08 Dec 2008 11:57:59 -0600 Jeremy Newman <jnewman(a)codeweavers.com> wrote: > I have posted a working copy of the new website here: > > http://wine.codeweavers.com/winehq_new/ > Why does the forum link on http://wine.codeweavers.com/winehq_new/help/ lead to http://groups.google.com/group/comp.emulators.ms-windows.wine/topics and not the actual forum on WineHQ? -- Rosanne DiMesio <dimesio(a)earthlink.net>

Dec. 8, 2008

Re: WineHQ redesign

by Branan Riley

On Mon, Dec 8, 2008 at 9:57 AM, Jeremy Newman <jnewman(a)codeweavers.com> wrote: > I have posted a working copy of the new website here: > > http://wine.codeweavers.com/winehq_new/ > > -Newman I've got lots of vertical space, but the page is using short white boxes with scrollbars. This is IE7 on Windows Vista. Looks like there a few layout issues with IE, actually: * Google box is below the search label, overlapping releases box * Releases box isn't tall enough to show both releases. (intentional?) * Text for buttons along top is much larger than the button boxes I'd expect many people looking to switch to Linux might be looking at how well Wine works before doing so, so having good IE support is important. (I never thought I'd advocate fixing a page to work with broken IE *sighs*) screenshot: http://img152.imageshack.us/my.php?image=winehqtr4.jpg -Branan

Dec. 8, 2008

Re: WineHQ redesign

by Paul Vriens

Jeremy Newman wrote: > I have posted a working copy of the new website here: > > http://wine.codeweavers.com/winehq_new/ > > -Newman > Hi Jer, The big icons are cut off at the bottom (at least on my Firefox 3.0.4). I also see that the news is up-to-date as it mentions 1.1.10 but the "Latest releases" section show 1.1.9. -- Cheers, Paul.

Dec. 8, 2008

Re: WineHQ redesign

by Juan Lang

> I have posted a working copy of the new website here: > > http://wine.codeweavers.com/winehq_new/ The About page says, "Wine is still under development, and it is not yet suitable for general use. Nevertheless, many people find it useful in running a growing number of Windows programs." Surely this is out of date since at least version 1.0? --Juan

Dec. 8, 2008

Re: WineHQ redesign

by Jeremy Newman

I have posted a working copy of the new website here: http://wine.codeweavers.com/winehq_new/ -Newman 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 site still has not gone live at this time. I wanted to allow a bit > more time for the community to review the changes before I cut them live. > > Other than the skin itself, the other big change is the new URL scheme. > The URLs will no longer have /site in them. I will have redirects so the > old URLs still work. But, I would appreciate help updating all external > links. > > WineHQ.org can be translated. If you want to translate WineHQ it is > pretty straight forward. Simply copy the templates in templates/en to > templates/<lang code>, and then build a patch. We have a start on the > Spanish translation. > > -Newman > > Jeremy Newman wrote: >> Module: website >> Branch: master >> Commit: eab5cc1e6dc6f36339018b11d97e47135b3dde45 >> URL: http://source.winehq.org/git/website.git/?a=commit;h=eab5cc1e6dc6f36339018b… >> >> Author: Jeremy Newman <jnewman(a)codeweavers.com> >> Date: Fri Dec 5 16:21:48 2008 -0600 >> >> WineHQ redesign >> * new skin for the webite >> * updated website template engine for new URL stucture >> * moved wwn,news,interviews to plugins >> * dropped sidebar navigation code, no longer used on main site >> * other cleanup and removal of dead code >> >> --- >> >> favicon.ico | Bin 3638 -> 1406 bytes >> images/classic_top_logo.png | Bin 15430 -> 0 bytes >> images/ppdonate.gif | Bin 2700 -> 0 bytes >> images/ppdonate.png | Bin 2498 -> 0 bytes >> images/top_logo.xcf | Bin 39690 -> 0 bytes >> images/winehq_border_bottom_left.gif | Bin 125 -> 0 bytes >> images/winehq_border_bottom_right.gif | Bin 105 -> 0 bytes >> images/winehq_border_dot_left.gif | Bin 114 -> 0 bytes >> images/winehq_border_dot_right.gif | Bin 114 -> 0 bytes >> images/winehq_border_top_left.gif | Bin 125 -> 0 bytes >> images/winehq_border_top_right.gif | Bin 105 -> 0 bytes >> images/winehq_top_logo.gif | Bin 6679 -> 0 bytes >> images/winehq_top_logo.png | Bin 5934 -> 0 bytes >> include/XMLToArray.php | 96 -- >> include/config.php | 102 +- >> include/globals.conf.sample | 7 +- >> include/html.php | 1401 +++++++++++++------- >> include/incl.php | 54 +- >> include/menu.php | 193 --- >> include/plugin.php | 16 +- >> include/themes/winehq/box.template | 10 - >> include/themes/winehq/box_title.template | 37 - >> include/themes/winehq/content.template | 112 +- >> include/themes/winehq/content_nobox.template | 72 + >> include/themes/winehq/home_page.template | 18 - >> include/themes/winehq/menu.template | 9 - >> include/themes/winehq/menu_item_row.template | 10 - >> include/themes/winehq/menu_lang_row.template | 12 - >> include/themes/winehq/menu_search_row.template | 21 - >> include/themes/winehq/menu_spacer_row.template | 7 - >> include/themes/winehq/menu_top_row.template | 17 - >> include/utils.php | 172 +++- >> include/winehq.php | 18 - >> include/wwn.php | 153 ++- >> jquery.js | 32 + >> jquery.pngfix.js | 126 ++ >> site | 442 +------ >> styles.css | 332 +++++ >> templates/en/404.template | 24 - >> templates/en/about.template | 27 +- >> templates/en/acknowledgement.template | 17 +- >> templates/en/ads.template | 13 - >> templates/en/contributing.template | 5 +- >> templates/en/cvs.template | 3 +- >> templates/en/devel.template | 143 ++ >> templates/en/developer-cheatsheet.template | 3 +- >> templates/en/download.template | 96 +- >> .../deb.template} | 3 +- >> .../deblenny.template} | 3 +- >> templates/en/forums.template | 7 +- >> templates/en/fun_projects.template | 15 +- >> templates/en/global/404.template | 18 + >> .../en/{getting_help.template => help.template} | 29 +- >> templates/en/help_wanted.template | 7 - >> templates/en/history.template | 7 +- >> templates/en/home_about.template | 30 - >> templates/en/howto.template | 168 --- >> templates/en/irc.template | 3 +- >> templates/en/license.template | 4 +- >> templates/en/menu.xml | 58 - >> templates/en/myths.template | 7 +- >> templates/en/news_row.template | 8 +- >> templates/en/pr-09betarelease.template | 76 -- >> templates/en/press.template | 212 --- >> templates/en/quotes.template | 6 - >> templates/en/resources.template | 3 +- >> templates/en/screenshots.template | 76 -- >> templates/en/search.template | 3 +- >> templates/en/sponsor.template | 27 - >> templates/en/status.template | 35 +- >> .../changelog.template} | 3 +- >> .../directx.template} | 135 +- >> .../{status_dlls.template => status/dlls.template} | 291 ++-- >> .../multimedia.template} | 73 +- >> .../options.template} | 3 + >> .../porting.template} | 3 + >> .../{status_todo.template => status/todo.template} | 3 +- >> .../en/{status_ui.template => status/ui.template} | 3 +- >> templates/en/status/wine.template | 624 +++++++++ >> templates/en/status_wine.template | 622 --------- >> templates/en/supported_applications.template | 11 - >> templates/en/who.template | 643 --------- >> templates/en/why.template | 7 +- >> templates/en/wine_features.template | 7 +- >> templates/en/wine_release.template | 11 - >> templates/en/winelib.template | 3 +- >> templates/en/wwn.template | 42 +- >> templates/en/wwn_content.template | 24 + >> templates/en/wwn_interview.template | 38 +- >> templates/es/download-deb.template | 3 +- >> templates/es/{ => global}/404.template | 12 +- >> templates/es/help_wanted.template | 7 - >> templates/es/home_about.template | 33 - >> templates/es/irc.template | 4 +- >> templates/es/menu.xml | 58 - >> templates/es/news_row.template | 5 - >> templates/es/quotes.template | 6 - >> templates/es/sending_patches.template | 9 +- >> templates/es/supported_applications.template | 13 - >> templates/es/wine_release.template | 11 - >> templates/es/wwn_interview.template | 29 - >> utils.js | 23 + >> 102 files changed, 3217 insertions(+), 4147 deletions(-) >> >> Diff: http://source.winehq.org/git/website.git/?a=commitdiff;h=eab5cc1e6dc6f36339… >> >> > >

Dec. 8, 2008

Re: WineHQ redesign

by Jeremy Newman

I have committed my work for the WineHQ redesign. I've also updated the AppDB and Bugzilla codebases with the new theme. The site still has not gone live at this time. I wanted to allow a bit more time for the community to review the changes before I cut them live. Other than the skin itself, the other big change is the new URL scheme. The URLs will no longer have /site in them. I will have redirects so the old URLs still work. But, I would appreciate help updating all external links. WineHQ.org can be translated. If you want to translate WineHQ it is pretty straight forward. Simply copy the templates in templates/en to templates/<lang code>, and then build a patch. We have a start on the Spanish translation. -Newman Jeremy Newman wrote: > Module: website > Branch: master > Commit: eab5cc1e6dc6f36339018b11d97e47135b3dde45 > URL: http://source.winehq.org/git/website.git/?a=commit;h=eab5cc1e6dc6f36339018b… > > Author: Jeremy Newman <jnewman(a)codeweavers.com> > Date: Fri Dec 5 16:21:48 2008 -0600 > > WineHQ redesign > * new skin for the webite > * updated website template engine for new URL stucture > * moved wwn,news,interviews to plugins > * dropped sidebar navigation code, no longer used on main site > * other cleanup and removal of dead code > > --- > > favicon.ico | Bin 3638 -> 1406 bytes > images/classic_top_logo.png | Bin 15430 -> 0 bytes > images/ppdonate.gif | Bin 2700 -> 0 bytes > images/ppdonate.png | Bin 2498 -> 0 bytes > images/top_logo.xcf | Bin 39690 -> 0 bytes > images/winehq_border_bottom_left.gif | Bin 125 -> 0 bytes > images/winehq_border_bottom_right.gif | Bin 105 -> 0 bytes > images/winehq_border_dot_left.gif | Bin 114 -> 0 bytes > images/winehq_border_dot_right.gif | Bin 114 -> 0 bytes > images/winehq_border_top_left.gif | Bin 125 -> 0 bytes > images/winehq_border_top_right.gif | Bin 105 -> 0 bytes > images/winehq_top_logo.gif | Bin 6679 -> 0 bytes > images/winehq_top_logo.png | Bin 5934 -> 0 bytes > include/XMLToArray.php | 96 -- > include/config.php | 102 +- > include/globals.conf.sample | 7 +- > include/html.php | 1401 +++++++++++++------- > include/incl.php | 54 +- > include/menu.php | 193 --- > include/plugin.php | 16 +- > include/themes/winehq/box.template | 10 - > include/themes/winehq/box_title.template | 37 - > include/themes/winehq/content.template | 112 +- > include/themes/winehq/content_nobox.template | 72 + > include/themes/winehq/home_page.template | 18 - > include/themes/winehq/menu.template | 9 - > include/themes/winehq/menu_item_row.template | 10 - > include/themes/winehq/menu_lang_row.template | 12 - > include/themes/winehq/menu_search_row.template | 21 - > include/themes/winehq/menu_spacer_row.template | 7 - > include/themes/winehq/menu_top_row.template | 17 - > include/utils.php | 172 +++- > include/winehq.php | 18 - > include/wwn.php | 153 ++- > jquery.js | 32 + > jquery.pngfix.js | 126 ++ > site | 442 +------ > styles.css | 332 +++++ > templates/en/404.template | 24 - > templates/en/about.template | 27 +- > templates/en/acknowledgement.template | 17 +- > templates/en/ads.template | 13 - > templates/en/contributing.template | 5 +- > templates/en/cvs.template | 3 +- > templates/en/devel.template | 143 ++ > templates/en/developer-cheatsheet.template | 3 +- > templates/en/download.template | 96 +- > .../deb.template} | 3 +- > .../deblenny.template} | 3 +- > templates/en/forums.template | 7 +- > templates/en/fun_projects.template | 15 +- > templates/en/global/404.template | 18 + > .../en/{getting_help.template => help.template} | 29 +- > templates/en/help_wanted.template | 7 - > templates/en/history.template | 7 +- > templates/en/home_about.template | 30 - > templates/en/howto.template | 168 --- > templates/en/irc.template | 3 +- > templates/en/license.template | 4 +- > templates/en/menu.xml | 58 - > templates/en/myths.template | 7 +- > templates/en/news_row.template | 8 +- > templates/en/pr-09betarelease.template | 76 -- > templates/en/press.template | 212 --- > templates/en/quotes.template | 6 - > templates/en/resources.template | 3 +- > templates/en/screenshots.template | 76 -- > templates/en/search.template | 3 +- > templates/en/sponsor.template | 27 - > templates/en/status.template | 35 +- > .../changelog.template} | 3 +- > .../directx.template} | 135 +- > .../{status_dlls.template => status/dlls.template} | 291 ++-- > .../multimedia.template} | 73 +- > .../options.template} | 3 + > .../porting.template} | 3 + > .../{status_todo.template => status/todo.template} | 3 +- > .../en/{status_ui.template => status/ui.template} | 3 +- > templates/en/status/wine.template | 624 +++++++++ > templates/en/status_wine.template | 622 --------- > templates/en/supported_applications.template | 11 - > templates/en/who.template | 643 --------- > templates/en/why.template | 7 +- > templates/en/wine_features.template | 7 +- > templates/en/wine_release.template | 11 - > templates/en/winelib.template | 3 +- > templates/en/wwn.template | 42 +- > templates/en/wwn_content.template | 24 + > templates/en/wwn_interview.template | 38 +- > templates/es/download-deb.template | 3 +- > templates/es/{ => global}/404.template | 12 +- > templates/es/help_wanted.template | 7 - > templates/es/home_about.template | 33 - > templates/es/irc.template | 4 +- > templates/es/menu.xml | 58 - > templates/es/news_row.template | 5 - > templates/es/quotes.template | 6 - > templates/es/sending_patches.template | 9 +- > templates/es/supported_applications.template | 13 - > templates/es/wine_release.template | 11 - > templates/es/wwn_interview.template | 29 - > utils.js | 23 + > 102 files changed, 3217 insertions(+), 4147 deletions(-) > > Diff: http://source.winehq.org/git/website.git/?a=commitdiff;h=eab5cc1e6dc6f36339… > >

Dec. 8, 2008

re: Gecko package

by Dan Kegel

marco meijer wrote: > I have a question about wine_gecko-0.1.0.cab >This package is from 2007-05-30 11:42 and in the mean time firefox > had a lot of security updates. > Is it still save to distribute wine_gecko-0.1.0.cab ? We'd like to move to a newer one. See http://bugs.winehq.org/show_bug.cgi?id=16198 - Dan

Dec. 8, 2008

RE: [3/4]

by Stefan Dösinger

> 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. > It would be up to the shader backend to determine what to apply. That > might imply storing the current vertex and fragment shader id's in the > context, but considering we also store those in the d3d vertex and > pixel shaders I think that's acceptable for now. Agreed, I can live with it. I however think that having this instead of the dirty state checks(which aren't completely nice either) moots the point. > 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 may need pixel shader support on my old laptop for personal reasons in a few weeks, so maybe I invest a rainy weekend of my time into it. Otoh just installing Windows may be an easier fix

Dec. 8, 2008

Re: kernel32/tests: Added some tests for behavior of 64-bit kernel handles.

by Paul Vriens

Hi Alexandre, This new test fails on Win9x as GetCurrentProcess() returns 7FFFFFFF on those platforms. I'm not sure how to fix/change/adjust the test. -- Cheers, Paul.

Dec. 8, 2008

Re: [PATCH 5/5] msi: Add tests for MsiEnumPatchesEx.

by Alexandre Julliard

"James Hawkins" <jhawkins(a)codeweavers.com> writes: > --- > dlls/msi/tests/msi.c | 1672 ++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 1672 insertions(+), 0 deletions(-) The test fails here: ../../../tools/runtest -q -P wine -M msi.dll -T ../../.. -p msi_test.exe.so msi.c && touch msi.ok msi.c:8027: Test failed: Expected ERROR_NO_MORE_ITEMS, got 0 msi.c:8028: Test failed: Expected patchcode to be unchanged, got {77687AD2-C53D-11DD-5D85-001A923592CB} msi.c:8030: Test failed: Expected targetprod to be unchanged, got {77687A96-C53D-11DD-5D85-001A923592CB} msi.c:8032: Test failed: Expected context to be unchanged, got 1 msi.c:8034: Test failed: Expected targetsid to be unchanged, got S-1-5-4 msi.c:8036: Test failed: Expected size to be unchanged, got 7 msi.c:8050: Test failed: Expected ERROR_NO_MORE_ITEMS, got 0 msi.c:8051: Test failed: Expected patchcode to be unchanged, got {77687AD2-C53D-11DD-5D85-001A923592CB} msi.c:8053: Test failed: Expected targetprod to be unchanged, got {77687A96-C53D-11DD-5D85-001A923592CB} msi.c:8055: Test failed: Expected context to be unchanged, got 1 msi.c:8057: Test failed: Expected targetsid to be unchanged, got S-1-5-4 msi.c:8059: Test failed: Expected size to be unchanged, got 7 msi.c:8456: Test failed: Expected ERROR_NO_MORE_ITEMS, got 0 msi.c:8457: Test failed: Expected patchcode to be unchanged, got {77687AD2-C53D-11DD-5D85-001A923592CB} msi.c:8459: Test failed: Expected targetprod to be unchanged, got {77687A96-C53D-11DD-5D85-001A923592CB} msi.c:8461: Test failed: Expected context to be unchanged, got 2 msi.c:8463: Test failed: Expected targetsid to be unchanged, got S-1-5-4 msi.c:8465: Test failed: Expected size to be unchanged, got 7 msi.c:8479: Test failed: Expected ERROR_NO_MORE_ITEMS, got 0 msi.c:8480: Test failed: Expected patchcode to be unchanged, got {77687AD2-C53D-11DD-5D85-001A923592CB} msi.c:8482: Test failed: Expected targetprod to be unchanged, got {77687A96-C53D-11DD-5D85-001A923592CB} msi.c:8484: Test failed: Expected context to be unchanged, got 2 msi.c:8486: Test failed: Expected targetsid to be unchanged, got S-1-5-4 msi.c:8488: Test failed: Expected size to be unchanged, got 7 make: *** [msi.ok] Error 24 -- Alexandre Julliard julliard(a)winehq.org

Dec. 8, 2008

Re: [3/4]

by Henri Verbeet

2008/12/8 Stefan Dösinger <stefan(a)codeweavers.com>: >> I would expect the relevant state to be dirty, but you say this >> depends on where the function is called from? > States are marked clean before the application function is called. This is needed to handle e.g. the relationship between the vertex declaration and the lighting enable state. > > What I mean is this: > pixelshader(bla bla bla) { > /* I know I have to apply the pixelshader */ > shader_backend->shader_select(); > } > > pixelshader(bla bla bla) { > /* I know I have to apply the vertex shader */ > shader_backend->shader_select(); > } > > shader_whatever_select() { > /* What do I have to do? Apply pixel shader? Or the vertex shader? or both? */ > } > It would be up to the shader backend to determine what to apply. That might imply storing the current vertex and fragment shader id's in the context, but considering we also store those in the d3d vertex and pixel shaders I think that's acceptable for now. 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). >> Well, you can hardly argue that eg. vertex shader enable is a proper >> vertex state to begin with. > The vertex shader enable doesn't have any say without the vertex declaration. And the vertex declaration has a similar effect on e.g. D3DRS_FOGVERTEXMODE. This state is treated differently in different shader model versions and different GL pipeline implementations on the fragment side. Is FOGVERTEXMODE a proper state or not? > Fog is not a pure vertex or fragment state, no (neither is the vertex declaration, strictly speaking, since a large part of what it does is about resource loading rather than how vertices are rendered). state_fog() makes this obvious in a rather painful way. > What I want to say is: We open a can of worms if we try to separate first class(programmable/ffp switch) states and second class states(ffp states) in the general state manager. This should really be left up to the actual pipeline implementation. > 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.

Dec. 8, 2008

Re: winebrowser: Educated guess if the DDE data is CHAR or WCHAR (try2)

by Dmitry Timoshkov

"Paul Chitescu" <paulc(a)voip.null.ro> wrote: > Windows doesn't implement it the simplified way wine's shell32.dll does so a > test doesn't make sense. Windows DDE clients can send A or W strings over DDE > and convert them as desired in the DDE server. Wine's DDE just sends the data > in the buffer with no indication on how to interpret it - that's why the code > guesses. Then the fix should be in DDE code instead, but in any case you need to write a test case for that. -- Dmitry.

Dec. 8, 2008

Gecko package

by marco meijer

Hi All, I'm the packager of the Mandriva package. And I have a question about wine_gecko-0.1.0.cab This package is from 2007-05-30 11:42 and in the mean time firefox had a lot of security updates. Is it still save to distribute wine_gecko-0.1.0.cab ? Kind regards, Marco

Dec. 8, 2008

RE: [3/4]

by Stefan Dösinger

> I would expect the relevant state to be dirty, but you say this > depends on where the function is called from? States are marked clean before the application function is called. This is needed to handle e.g. the relationship between the vertex declaration and the lighting enable state. What I mean is this: pixelshader(bla bla bla) { /* I know I have to apply the pixelshader */ shader_backend->shader_select(); } pixelshader(bla bla bla) { /* I know I have to apply the vertex shader */ shader_backend->shader_select(); } shader_whatever_select() { /* What do I have to do? Apply pixel shader? Or the vertex shader? or both? */ } > Well, you can hardly argue that eg. vertex shader enable is a proper > vertex state to begin with. The vertex shader enable doesn't have any say without the vertex declaration. And the vertex declaration has a similar effect on e.g. D3DRS_FOGVERTEXMODE. This state is treated differently in different shader model versions and different GL pipeline implementations on the fragment side. Is FOGVERTEXMODE a proper state or not? What I want to say is: We open a can of worms if we try to separate first class(programmable/ffp switch) states and second class states(ffp states) in the general state manager. This should really be left up to the actual pipeline implementation. (sidenote: The current fog code is a mess)

Dec. 8, 2008

Re: winebrowser: Educated guess if the DDE data is CHAR or WCHAR (try 2)

by Paul Chitescu

On Monday 08 December 2008 15:06:32 you wrote: > "Paul Chitescu" <paulc(a)voip.null.ro> wrote: > > Changelog: > > winebrowser: Educated guess if the DDE data is CHAR or WCHAR > > > > Our shell32 dde_connect implementation sends a CHAR buffer for if > > operating system version is set to ANSI based and WCHAR if the system is > > set for Unicode. > > > > This patch makes winebrowser assume the same about the data it receives > > via XTYP_EXECUTE. However, if the string starts with a quote (which > > normally always happens) an extra effort is made to detect if the data is > > UTF-16 by checking if the upper byte of the 1st WCHAR is zero. > > > > This should fix bug #13891 for good (bugzilla describes a workaround that > > avoids using DDE). > > You should add a test case to find out what NT based/Win9x do in that case. Windows doesn't implement it the simplified way wine's shell32.dll does so a test doesn't make sense. Windows DDE clients can send A or W strings over DDE and convert them as desired in the DDE server. Wine's DDE just sends the data in the buffer with no indication on how to interpret it - that's why the code guesses. Paul

Dec. 8, 2008

Re: winebrowser: Educated guess if the DDE data is CHAR or WCHAR (try 2)

by Dmitry Timoshkov

"Paul Chitescu" <paulc(a)voip.null.ro> wrote: > Changelog: > winebrowser: Educated guess if the DDE data is CHAR or WCHAR > > Our shell32 dde_connect implementation sends a CHAR buffer for if operating > system version is set to ANSI based and WCHAR if the system is set for > Unicode. > > This patch makes winebrowser assume the same about the data it receives via > XTYP_EXECUTE. However, if the string starts with a quote (which normally > always happens) an extra effort is made to detect if the data is UTF-16 by > checking if the upper byte of the 1st WCHAR is zero. > > This should fix bug #13891 for good (bugzilla describes a workaround that > avoids using DDE). You should add a test case to find out what NT based/Win9x do in that case. -- Dmitry.

Dec. 8, 2008

Re: [3/4]

by Henri Verbeet

2008/12/8 Stefan Dösinger <stefan(a)codeweavers.com>: >> > I don't think that would work well. We would need some shader model >> specific private data in each context(e.g. last vertexshader and last >> vertexdeclaration) to allow the shader backend to find out what to do, >> since the dirty state information won't suffice if the shader backend >> doesn't know where it was called from. >> > >> Why not? > How does e.g. ARB find out wether it has to reapply the pixelshader? Or how does GLSL find out if it has to apply a new GLSL program. > I would expect the relevant state to be dirty, but you say this depends on where the function is called from? >> I would argue that since shaders replace vertex and/or fragment >> states, we shouldn't have to go through the state management for >> replaced pipeline stages in the first place. > And I argue that this should be the implementation's decision. (Read: The state manager and context.c should not treat some states specially) > Well, you can hardly argue that eg. vertex shader enable is a proper vertex state to begin with.

Dec. 8, 2008

RE: [3/4]

by Stefan Dösinger

> > I don't think that would work well. We would need some shader model > specific private data in each context(e.g. last vertexshader and last > vertexdeclaration) to allow the shader backend to find out what to do, > since the dirty state information won't suffice if the shader backend > doesn't know where it was called from. > > > Why not? How does e.g. ARB find out wether it has to reapply the pixelshader? Or how does GLSL find out if it has to apply a new GLSL program. > I would argue that since shaders replace vertex and/or fragment > states, we shouldn't have to go through the state management for > replaced pipeline stages in the first place. And I argue that this should be the implementation's decision. (Read: The state manager and context.c should not treat some states specially)

Dec. 8, 2008

Re: Huw Davies : opengl/tests: Skip tests if we can't find a pixel format.

by Alexandre Julliard

Huw Davies <huw(a)codeweavers.com> 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. -- Alexandre Julliard julliard(a)winehq.org

Dec. 8, 2008

Re: [kernel32/tests] Kill a debug process to make sure we can cleanup

by Paul Vriens

Paul Vriens wrote: > Hi, > > For some reason (yet to find out what) one of the tests keeps a > kernel32.exe process running on W2K and below. This prevents cleanup at > the end of winetest. > > Changelog > Kill a debug process to make sure we can cleanup > Ignore this one. -- Cheers, Paul.

Dec. 8, 2008

Re: Huw Davies : opengl/tests: Skip tests if we can't find a pixel format.

by Huw Davies

On Fri, Dec 05, 2008 at 11:04:07AM -0600, Alexandre Julliard wrote: > Module: wine > Branch: master > Commit: e86ff2a3128f4a0157ecfa10fee31d1416312c71 > URL: http://source.winehq.org/git/wine.git/?a=commit;h=e86ff2a3128f4a0157ecfa10f… > > Author: Huw Davies <huw(a)codeweavers.com> > Date: Fri Dec 5 14:19:25 2008 +0000 > > opengl/tests: Skip tests if we can't find a pixel format. > > --- > > dlls/opengl32/tests/opengl.c | 9 ++++++++- > 1 files changed, 8 insertions(+), 1 deletions(-) > > diff --git a/dlls/opengl32/tests/opengl.c b/dlls/opengl32/tests/opengl.c > index 35eb8ae..a3ac3af 100644 > --- a/dlls/opengl32/tests/opengl.c > +++ b/dlls/opengl32/tests/opengl.c > @@ -555,7 +555,12 @@ START_TEST(opengl) > hdc = GetDC(hwnd); > > iPixelFormat = ChoosePixelFormat(hdc, &pfd); > - ok(iPixelFormat > 0, "No pixelformat found!\n"); /* This should never happen as ChoosePixelFormat always returns a closest match */ > + if(iPixelFormat == 0) > + { > + /* This should never happen as ChoosePixelFormat always returns a closest match, but currently this fails in Wine if we don't have glX */ > + win_skip("Unable to find pixel format.\n"); > + goto cleanup; > + } > > /* We shouldn't be able to create a context from a hdc which doesn't have a pixel format set */ > hglrc = wglCreateContext(hdc); 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. Huw. -- huw(a)codeweavers.com

Dec. 8, 2008

Re: [3/4]

by Henri Verbeet

2008/12/8 Stefan Dösinger <stefan(a)codeweavers.com>: >> If you're going to introduce a dependency on state management in the >> shader backends anyway, you don't need to export constant loading >> functions from the shader backends at all. You might as well just call >> shader_select(), and let that figure out if it needs to change the >> shader or load any constants. That would also avoid this not-so-pretty >> code here. > I don't think that would work well. We would need some shader model specific private data in each context(e.g. last vertexshader and last vertexdeclaration) to allow the shader backend to find out what to do, since the dirty state information won't suffice if the shader backend doesn't know where it was called from. > Why not? > It would also tie shader and shader constants, as well as different shader types and constant types together in ARB. > That's an issue of course, but we should only reload dirty constants anyway. I've got some patches I could cleanup that do this. > There are however two follow-up ideas of this patch I am toying with: > > 1: Make the load_constant and shader_select prototypes the same, so GLSL can use one call for all and ARB remains flexible > > 2: Make the shader backend provide a pipeline template instead of shader_select and shader_load_constant. That would move shader selection out of the fixed function pipeline code and allow the shader to use the state management linking facilities for these sorts of dependencies > I would argue that since shaders replace vertex and/or fragment states, we shouldn't have to go through the state management for replaced pipeline stages in the first place.

Dec. 8, 2008

RE: [3/4]

by Stefan Dösinger

> If you're going to introduce a dependency on state management in the > shader backends anyway, you don't need to export constant loading > functions from the shader backends at all. You might as well just call > shader_select(), and let that figure out if it needs to change the > shader or load any constants. That would also avoid this not-so-pretty > code here. I don't think that would work well. We would need some shader model specific private data in each context(e.g. last vertexshader and last vertexdeclaration) to allow the shader backend to find out what to do, since the dirty state information won't suffice if the shader backend doesn't know where it was called from. It would also tie shader and shader constants, as well as different shader types and constant types together in ARB. There are however two follow-up ideas of this patch I am toying with: 1: Make the load_constant and shader_select prototypes the same, so GLSL can use one call for all and ARB remains flexible 2: Make the shader backend provide a pipeline template instead of shader_select and shader_load_constant. That would move shader selection out of the fixed function pipeline code and allow the shader to use the state management linking facilities for these sorts of dependencies

Dec. 8, 2008

RE: [1/4] D3D9: Document a Microsoft header bug

by Stefan Dösinger

> -----Original Message----- > From: wine-devel-bounces(a)winehq.org [mailto:wine-devel- > bounces(a)winehq.org] On Behalf Of Henri Verbeet > Sent: Monday, December 08, 2008 9:24 AM > To: wine-devel(a)winehq.org > Subject: Re: [1/4] D3D9: Document a Microsoft header bug > > 2008/12/8 Stefan Dösinger <stefan(a)codeweavers.com>: > > > This patch was already applied. Humm strange. my git tree missed it....

Dec. 8, 2008

Re: [4/4] ntdll: print the SYSTEM_PERFORMANCE_INFORMATION only once

by Henri Verbeet

The actual patch is missing.

Dec. 8, 2008

Re: [3/4]

by Henri Verbeet

2008/12/8 Stefan Dösinger <stefan(a)codeweavers.com>: > + /* TODO: If we're called by shader_glsl_select, we know that both we get past both checks. > + * is it cheaper to have a wrapper function check those? Inline some common code? Extra > + * parameter? > + */ > if (!prog) { > /* No GLSL program set - nothing to do. */ > return; > + } else if(isStateDirty(context, STATE_PIXELSHADER) || > + isStateDirty(context, STATE_VDECL) || > + isStateDirty(context, STATE_PIXELSHADERCONSTANT) || > + isStateDirty(context, STATE_VERTEXSHADERCONSTANT)) { > + /* Will be called again later */ > + return; If you're going to introduce a dependency on state management in the shader backends anyway, you don't need to export constant loading functions from the shader backends at all. You might as well just call shader_select(), and let that figure out if it needs to change the shader or load any constants. That would also avoid this not-so-pretty code here.

Dec. 8, 2008

Re: [1/4] D3D9: Document a Microsoft header bug

by Henri Verbeet

2008/12/8 Stefan Dösinger <stefan(a)codeweavers.com>: > This patch was already applied.

Dec. 8, 2008

Re: explorer: improve ABM_GETTASKBARPOS stub

by Vincent Povirk

This doesn't have to be so hard. As far as I know, all any real application needs here is a stub. The stub has to claim success, but the values it gives do not have to be meaningful. If a real implementation were trivial, I would go ahead and write one anyway. It isn't so I won't. I'm not going to find some magical "success, but there isn't a taskbar" value I can return by testing old operating systems and shell replacements. The API is defined by developer expectations, when they happen to be matched by what Windows does. Developers expect, and get, a system that always has a taskbar. If a real application actually needs to know where the taskbar is, I'll take another look at this. Until then, I say we return something plausible and wrong, as that keeps programs happy. Vincent Povirk

Dec. 8, 2008

Re: explorer: improve ABM_GETTASKBARPOS stub

by James Hawkins

On Sun, Dec 7, 2008 at 11:50 PM, Vincent Povirk <madewokherd+8cd9(a)gmail.com> wrote: >> You know, there is the only one way to figure it out: write a test case. > > That's not the answer to everything, you know. > > If I have a windows machine that does not have a taskbar, I can call > SHAppBarMessage to see how I should report this to the app. But how do > I get a windows machine without a taskbar? > In, at least, the wine community, we have images of most known versions of windows. And like you said, you can also figure out how to replace the shell as an alternative. -- James Hawkins

Dec. 8, 2008