Re: [wintrust/tests] Add some basic CryptCATOpen tests
Detlef Riekenberg wrote:
On Mo, 2009-05-18 at 16:07 +0200, Paul Vriens wrote:
+hcat = pCryptCATOpen(emptyW, 0, 0, 0, 0);
+todo_wine
+{
+ok(hcat != NULL && hcat != INVALID_HANDLE_VALUE, "Expected a
correct handle\n");
+ok(GetLastError() == ERROR_SUCCESS,
+ "Expected ERROR_SUCCESS, got %08x\n", GetLastError());
+}
MSDN documents INVALID_HANDLE_VALUE on failure.
When NULL is valid result, then a comment about the MSDN error would be
nice.
NULL is not supposed to be valid it was just to show that hcat changed.
I guess just checking for INVALID_HANDLE_VALUE will do.
Did you have an application, that need ERROR_SUCCESS?
The result of GetLastError() should only be tested, when the function
failed,
or when GetLastError is documented to be valid on success.
Well, I actually don't know. Our implementation is wrong so this one is
hard to check. I will remove it from the test.
--
Cheers,
Paul.
Re: [Article] WINE and the importance of application compatibility
2009/5/19 Austin English :
> On Mon, May 18, 2009 at 3:48 PM, David Gerard wrote:
>> 1. Find apps that work pretty much perfectly in Wine.
>> 2. Ask them to declare Wine officially supported.
>> 3. Add them to http://wiki.winehq.org/AppsThatSupportWine
>> 4. Use 3. to add more to 2.
>
> You forgot:
> 5.
> 6. Profit!
Off-topic, but that only works with 3-stage plans, thus:
1. Find apps that work pretty much perfectly in Wine
2. ?
3. Profit!
"Time to go to work, work on Wine, work on opensource today! We won't
stop until we've got opensource, yum yum yummy yum yay!"
Back on topic, do we really take such strongly biased blog crap from
zdnet seriously? The author has done little to no research:
"Which brings us to today. Linux desktops have reached a point of
maturity, polish and sophistication which rivals that found in Windows
2000. Yes, it's not as integrated as XP nor as glittering as Mac OS X.
But it's Good Enough™. What Linux cannot offer to most potential
users, that critical attribute which presently holds Linux back from
much broader adoption on the desktop, is that magical ingredient which
Windows offered to DOS users; being able to all your important
applications within the new environment."
^^ missing a word here ("being able to all your important
applications"). Note that MacOSX also fails to bring this
functionality, but it's not being hammered like Linux is.
I've recently seen the OpenSUSE 11.1 installer in action and, although
Debian is still my preferred distro, I am very impressed. It's all
pretty and snazzy, and YAST has come a long way since I first tried
SUSE. Maybe this is just because Novell bought it, but it's certainly
way beyond the "Windows 2000" level he's claiming.
"Wine is still a work-in-progress and a pain to configure. It
therefore pays to purchase a nicely-packaged form of this open source
technology from one of two vendors: for business apps, CrossOver
Office from Codeweavers, and for gamers, WineX from Transgaming, Cost
is maybe $50, but it will make installing and managing all those
Windows apps under Linux a snap."
For a start, *Cedega* is a subscription service ...
"How to make the vineyard bloom? There are four major industry players
(IBM, Sun, Red Hat and Novell) who have a vested interest in desktop
Linux's success, and therefore much to gain by cultivating the open
source developer community which produces Wine. At the moment Wine is
growing organically; slow and steady. With some well directed nutrient
booster, say in the form of $10 million apiece, Wine will be running
99% of all those thousands of Windows apps within a year."
This makes me LOL. Somehow I don't think money is the problem.
First comment too, only way to go forward is for someone to buy
Codeweavers (and potentially taint Crossover/Wine for the purposes of
getting things to work).
Re: [Article] WINE and the importance of application compatibility
David Gerard wrote: 2009/5/18 Brian Vincent : Which leads me to my $.02: I wonder if there's a sweet spot for Wine adoption somewhere in the middle-tier of the software application popularity contest. For instance, rather than going after Photoshop or Photoshop Elements (which is still a noble goal), what about approaching Paintshop Pro about their Photo x2 product. Or, what about approaching the ISV that created Home Depot's freeware CD for laying out your home design? Specifically, I think there's a lot of proprietary applications without a good alternative (think more of the Home Depot or Sysco's "Rio", etc ). I think there's $$$ to be made for someone who can QA apps with Wine, fix minor issues, package Wine alongside the app, and finally deliver the product to an ISV. I don't think this is something the Wine community itself would be interested in, but I suspect there's someone in the Wine community who's capable of pulling it off. I think there's a lot of angles to the idea that could work. 1. Find apps that work pretty much perfectly in Wine. 2. Ask them to declare Wine officially supported. 3. Add them to http://wiki.winehq.org/AppsThatSupportWine 4. Use 3. to add more to 2. I don't think we'll get much traction with this unless we can reasonably tell them they only need to test the stable Wine release. But 1.0 is pretty old these days, so they probably won't bother. I'll add it to my list of evangelism to do after Wine 1.2 hits. And also not-so-subtly suggest this is another reason Wine 1.2 needs to happen sooner ;) Thanks, Scott Ritchie
Re: gdiplus: implement GdipTransformPoints
Vincent Povirk wrote: It's odd, but it seems like the simplest way to write this. I've tried what I think was your suggestion, and that's attached. I don't think it's an improvement. Vincent Povirk Could be a single switch maybe. Don't know, looks better for me. Comparisons were really ugly here - a strict comparison should be used instead if you don't like switches. Anyway it's just my thoughts.
Re: gdiplus: implement GdipTransformPoints
It's odd, but it seems like the simplest way to write this.
I've tried what I think was your suggestion, and that's attached. I
don't think it's an improvement.
Vincent Povirk
On Mon, May 18, 2009 at 5:17 PM, Nikolay Sivov wrote:
> Vincent Povirk wrote:
>
> From 1de9b2291bf9a5617ca1e3b0cba5f1260889c259 Mon Sep 17 00:00:00 2001
> From: Vincent Povirk
> Date: Mon, 23 Mar 2009 16:34:12 -0500
> Subject: [PATCH] gdiplus: implement GdipTransformPoints
>
>
> It's a strange way to check enumeration with integer comparison, isn't it?
> And not clear in this particular case.
>
>> + if (stat == Ok)
>> + {
>> + unitscale = convert_unit(graphics->hdc, graphics->unit);
>> +
>> + if(graphics->unit != UnitDisplay)
>> + unitscale *= graphics->scale;
>> +
>> + if (src_space <= CoordinateSpaceWorld && dst_space >=
>> CoordinateSpacePage)
>> + GdipMultiplyMatrix(matrix, graphics->worldtrans,
>> MatrixOrderAppend);
>> + if (src_space <= CoordinateSpacePage && dst_space >=
>> CoordinateSpaceDevice)
>> + GdipScaleMatrix(matrix, unitscale, unitscale,
>> MatrixOrderAppend);
>> +
>> + if (dst_space <= CoordinateSpacePage && src_space >=
>> CoordinateSpaceDevice)
>> + GdipScaleMatrix(matrix, 1.0/unitscale, 1.0/unitscale,
>> MatrixOrderAppend);
>> + if (dst_space <= CoordinateSpaceWorld && src_space >=
>> CoordinateSpacePage)
>> + {
>> + GpMatrix *inverted_transform;
>> + stat = GdipCloneMatrix(graphics->worldtrans,
>> &inverted_transform);
>> + if (stat == Ok)
>> + {
>> + GdipInvertMatrix(inverted_transform);
>> + GdipMultiplyMatrix(matrix, inverted_transform,
>> MatrixOrderAppend);
>> + GdipDeleteMatrix(inverted_transform);
>> + }
>> +
>
> Maybe it's better to use 'switch' for source coords with falling and ifs
> inside cases for destination.
>
> <= CoordinateSpaceWorld is just CoordinateSpaceWorld
>>= CoordinateSpaceDevice - is CoordinateSpaceDevice.
>
>
>
>
diff --git a/dlls/gdiplus/graphics.c b/dlls/gdiplus/graphics.c
index 5e5883f..0ade037 100644
--- a/dlls/gdiplus/graphics.c
+++ b/dlls/gdiplus/graphics.c
@@ -3592,15 +3592,66 @@ GpStatus WINGDIPAPI GdipGetClip(GpGraphics *graphics,
GpRegion *region)
GpStatus WINGDIPAPI GdipTransformPoints(GpGraphics *graphics,
GpCoordinateSpace dst_space,
GpCoordinateSpace src_space, GpPointF
*points, INT count)
{
+GpMatrix *matrix;
+GpStatus stat;
+REAL unitscale;
+
if(!graphics || !points || count <= 0)
return InvalidParameter;
if(graphics->busy)
return ObjectBusy;
-FIXME("(%p, %d, %d, %p, %d): stub\n", graphics, dst_space, src_space,
points, count);
+TRACE("(%p, %d, %d, %p, %d)\n", graphics, dst_space, src_space, points,
count);
-return NotImplemented;
+stat = GdipCreateMatrix(&matrix);
+if (stat == Ok)
+{
+unitscale = convert_unit(graphics->hdc, graphics->unit);
+
+if(graphics->unit != UnitDisplay)
+unitscale *= graphics->scale;
+
+switch (src_space)
+{
+case CoordinateSpaceWorld:
+if (dst_space == CoordinateSpaceWorld)
+break;
+GdipMultiplyMatrix(matrix, graphics->worldtrans,
MatrixOrderAppend);
+case CoordinateSpacePage:
+if (dst_space == CoordinateSpaceDevice)
+GdipScaleMatrix(matrix, unitscale, unitscale,
MatrixOrderAppend);
+default: break;
+}
+
+switch (src_space)
+{
+case CoordinateSpaceDevice:
+if (dst_space == CoordinateSpaceDevice)
+break;
+GdipScaleMatrix(matrix, 1.0/unitscale, 1.0/unitscale,
MatrixOrderAppend);
+case CoordinateSpacePage:
+if (dst_space == CoordinateSpaceWorld)
+{
+GpMatrix *inverted_transform;
+stat = GdipCloneMatrix(graphics->worldtrans,
&inverted_transform);
+if (stat == Ok)
+{
+GdipInvertMatrix(inverted_transform);
+GdipMultiplyMatrix(matrix, inverted_transform,
MatrixOrderAppend);
+GdipDeleteMatrix(inverted_transform);
+}
+}
+default: break;
+}
+
+if (stat == Ok)
+stat = GdipTransformMatrixPoints(matrix, points, count);
+
+GdipDeleteMatrix(matrix);
+}
+
+return stat;
}
GpStatus WINGDIPAPI GdipTransformPointsI(GpGraphics *graphics,
GpCoordinateSpace dst_space,
diff --git a/dlls/gdiplus/tests/graphics.c b/dlls/gdiplus/tests/graphics.c
index 7199151..510a148 100644
--- a/dlls/gdiplus/tests/graphics.c
+++ b/dlls/gdiplus/tests/graphics.c
@@ -22,8 +22,10 @@
#include "gdiplus.h"
#include "wingdi.h"
#include "wine/test.h"
+#include
#define expect(expected, got) ok(got == expected, "Expected %.8x,
Re: gdiplus: implement GdipTransformPoints
Vincent Povirk wrote:
From 1de9b2291bf9a5617ca1e3b0cba5f1260889c259 Mon Sep 17 00:00:00 2001
From: Vincent Povirk
Date: Mon, 23 Mar 2009 16:34:12 -0500
Subject: [PATCH] gdiplus: implement GdipTransformPoints
It's a strange way to check enumeration with integer comparison, isn't it?
And not clear in this particular case.
+if (stat == Ok)
+{
+unitscale = convert_unit(graphics->hdc, graphics->unit);
+
+if(graphics->unit != UnitDisplay)
+unitscale *= graphics->scale;
+
+if (src_space <= CoordinateSpaceWorld && dst_space >=
CoordinateSpacePage)
+GdipMultiplyMatrix(matrix, graphics->worldtrans,
MatrixOrderAppend);
+if (src_space <= CoordinateSpacePage && dst_space >=
CoordinateSpaceDevice)
+GdipScaleMatrix(matrix, unitscale, unitscale, MatrixOrderAppend);
+
+if (dst_space <= CoordinateSpacePage && src_space >=
CoordinateSpaceDevice)
+GdipScaleMatrix(matrix, 1.0/unitscale, 1.0/unitscale,
MatrixOrderAppend);
+if (dst_space <= CoordinateSpaceWorld && src_space >=
CoordinateSpacePage)
+{
+GpMatrix *inverted_transform;
+stat = GdipCloneMatrix(graphics->worldtrans, &inverted_transform);
+if (stat == Ok)
+{
+GdipInvertMatrix(inverted_transform);
+GdipMultiplyMatrix(matrix, inverted_transform,
MatrixOrderAppend);
+GdipDeleteMatrix(inverted_transform);
+}
+
Maybe it's better to use 'switch' for source coords with falling and ifs
inside cases for destination.
<= CoordinateSpaceWorld is just CoordinateSpaceWorld
>= CoordinateSpaceDevice - is CoordinateSpaceDevice.
Re: [wintrust/tests] Add some basic CryptCATOpen tests
On Mo, 2009-05-18 at 16:07 +0200, Paul Vriens wrote:
> +hcat = pCryptCATOpen(emptyW, 0, 0, 0, 0);
> +todo_wine
> +{
> +ok(hcat != NULL && hcat != INVALID_HANDLE_VALUE, "Expected a
> correct handle\n");
> +ok(GetLastError() == ERROR_SUCCESS,
> + "Expected ERROR_SUCCESS, got %08x\n", GetLastError());
> +}
MSDN documents INVALID_HANDLE_VALUE on failure.
When NULL is valid result, then a comment about the MSDN error would be
nice.
Did you have an application, that need ERROR_SUCCESS?
The result of GetLastError() should only be tested, when the function
failed,
or when GetLastError is documented to be valid on success.
--
By by ... Detlef
Re: [Article] WINE and the importance of application compatibility
On Mon, May 18, 2009 at 3:48 PM, David Gerard wrote: > 1. Find apps that work pretty much perfectly in Wine. > 2. Ask them to declare Wine officially supported. > 3. Add them to http://wiki.winehq.org/AppsThatSupportWine > 4. Use 3. to add more to 2. You forgot: 5. 6. Profit! :-) -- -Austin
Re: [Article] WINE and the importance of application compatibility
2009/5/18 Brian Vincent : > Which leads me to my $.02: I wonder if there's a sweet spot for Wine > adoption somewhere in the middle-tier of the software application popularity > contest. For instance, rather than going after Photoshop or Photoshop > Elements (which is still a noble goal), what about approaching Paintshop Pro > about their Photo x2 product. Or, what about approaching the ISV that > created Home Depot's freeware CD for laying out your home design? > Specifically, I think there's a lot of proprietary applications without a > good alternative (think more of the Home Depot or Sysco's "Rio", etc ). I > think there's $$$ to be made for someone who can QA apps with Wine, fix > minor issues, package Wine alongside the app, and finally deliver the > product to an ISV. I don't think this is something the Wine community > itself would be interested in, but I suspect there's someone in the Wine > community who's capable of pulling it off. I think there's a lot of angles > to the idea that could work. 1. Find apps that work pretty much perfectly in Wine. 2. Ask them to declare Wine officially supported. 3. Add them to http://wiki.winehq.org/AppsThatSupportWine 4. Use 3. to add more to 2. - d.
Re: Gecko installation broken?
On Mon, May 18, 2009 at 12:29 PM, Nikolay Sivov wrote: > Lei Zhang wrote: >> >> On Mon, May 18, 2009 at 11:20 AM, Lei Zhang wrote: >> >>> >>> On Mon, May 18, 2009 at 10:57 AM, Stefan Dösinger >>> wrote: >>> Hi, Is my setup broken, or does the gecko installation fail? In a new wine prefix, when I open builtin iexplore, I get the installation dialog. The download runs successfully, but after installation iexplore still says that HTML rendering is currently disabled. When I run iexplore again, I again see the Wine Gecko installer dialog box. My hacky nightly game tests ran into this problem. The last successfull Team Fotress 2 test run is from May 14, 2009. After that my Gecko setup script failed and did not even try to start up Steam. >>> >>> Same problem here. Grr. Time for a regression test. >>> >>> >> >> Regression test says: >> >> commit 24d6c88d16c46f00d99fd8529196590aca88b0f4 >> Author: Nikolay Sivov >> Date: Wed May 13 23:23:57 2009 +0400 >> >> comctl32/tab: Fix TabCtrl_* macros. >> >> Will file bug after lunch. >> >> > > Only Oleview and Taskmanager use these macros in Wine tree. So can't be a > cause I suppose. > It didn't think so either, so I even double checked. Upon further investigation, it seems the problem is simply the gecko cab download is failing. Either one of the Sourceforge servers is down/flaky, or source.winehq.org is taking too long to do the redirect and wininet doesn't handle that well.
Re: [Article] WINE and the importance of application compatibility
On Sun, May 17, 2009 at 6:55 PM, Steven Edwards wrote: > doubt it. The situation I face with my day job, is that we can't even > get support for certain applications in VMware. As soon as we say "we > have a virtualized cluster" they balk. And we are talking about > situations where we are spending millions of dollars on our software > and are going to be supporting it in house. With that sort of > reaction, it leads me to think we are never going to make major > inroads except for the end users at home or the people buying Linux > netbooks. Kind of a tangent.. but I've thought for a long time Google did something really right with Picasa: they packaged a canned version of Wine alongside a canned version of their app. These days, hard drives space is cheap and no one notices an extra 20MB of Wine libraries with a set up program. Which leads me to my $.02: I wonder if there's a sweet spot for Wine adoption somewhere in the middle-tier of the software application popularity contest. For instance, rather than going after Photoshop or Photoshop Elements (which is still a noble goal), what about approaching Paintshop Pro about their Photo x2 product. Or, what about approaching the ISV that created Home Depot's freeware CD for laying out your home design? Specifically, I think there's a lot of proprietary applications without a good alternative (think more of the Home Depot or Sysco's "Rio", etc ). I think there's $$$ to be made for someone who can QA apps with Wine, fix minor issues, package Wine alongside the app, and finally deliver the product to an ISV. I don't think this is something the Wine community itself would be interested in, but I suspect there's someone in the Wine community who's capable of pulling it off. I think there's a lot of angles to the idea that could work. -Brian
Re: winspool.drv: implement semi-stub of EnumJobsW
On Mo, 2009-05-18 at 19:30 +0400, Vitaly Perov wrote: > --- > dlls/winspool.drv/info.c | 36 +++- > 1 files changed, 35 insertions(+), 1 deletions(-) The correct location for an implementation is localspl.dll For which Application did you changed the stub? The important thing to decide first, what Wine is allowed to return: a) Informations from Wine and from Host-OS b) Informations from Wine only (will be empty most of the time) The current code is using "b", but your Patch added: c) Informations from the Host-OS only which is not correct. I'm fine to migrate from "b" to "a". Thanks for working on printing. -- By by ... Detlef
Re: Gecko installation broken?
Lei Zhang wrote: On Mon, May 18, 2009 at 11:20 AM, Lei Zhang wrote: On Mon, May 18, 2009 at 10:57 AM, Stefan Dösinger wrote: Hi, Is my setup broken, or does the gecko installation fail? In a new wine prefix, when I open builtin iexplore, I get the installation dialog. The download runs successfully, but after installation iexplore still says that HTML rendering is currently disabled. When I run iexplore again, I again see the Wine Gecko installer dialog box. My hacky nightly game tests ran into this problem. The last successfull Team Fotress 2 test run is from May 14, 2009. After that my Gecko setup script failed and did not even try to start up Steam. Same problem here. Grr. Time for a regression test. Regression test says: commit 24d6c88d16c46f00d99fd8529196590aca88b0f4 Author: Nikolay Sivov Date: Wed May 13 23:23:57 2009 +0400 comctl32/tab: Fix TabCtrl_* macros. Will file bug after lunch. Only Oleview and Taskmanager use these macros in Wine tree. So can't be a cause I suppose.
Re: Gecko installation broken?
On Mon, May 18, 2009 at 11:20 AM, Lei Zhang wrote: > On Mon, May 18, 2009 at 10:57 AM, Stefan Dösinger > wrote: >> Hi, >> Is my setup broken, or does the gecko installation fail? In a new wine >> prefix, >> when I open builtin iexplore, I get the installation dialog. The download >> runs successfully, but after installation iexplore still says that HTML >> rendering is currently disabled. When I run iexplore again, I again see the >> Wine Gecko installer dialog box. >> >> My hacky nightly game tests ran into this problem. The last successfull Team >> Fotress 2 test run is from May 14, 2009. After that my Gecko setup script >> failed and did not even try to start up Steam. > > Same problem here. Grr. Time for a regression test. > Regression test says: commit 24d6c88d16c46f00d99fd8529196590aca88b0f4 Author: Nikolay Sivov Date: Wed May 13 23:23:57 2009 +0400 comctl32/tab: Fix TabCtrl_* macros. Will file bug after lunch.
Re: Gecko installation broken?
On Mon, May 18, 2009 at 10:57 AM, Stefan Dösinger wrote: > Hi, > Is my setup broken, or does the gecko installation fail? In a new wine prefix, > when I open builtin iexplore, I get the installation dialog. The download > runs successfully, but after installation iexplore still says that HTML > rendering is currently disabled. When I run iexplore again, I again see the > Wine Gecko installer dialog box. > > My hacky nightly game tests ran into this problem. The last successfull Team > Fotress 2 test run is from May 14, 2009. After that my Gecko setup script > failed and did not even try to start up Steam. Same problem here. Grr. Time for a regression test.
Gecko installation broken?
Hi, Is my setup broken, or does the gecko installation fail? In a new wine prefix, when I open builtin iexplore, I get the installation dialog. The download runs successfully, but after installation iexplore still says that HTML rendering is currently disabled. When I run iexplore again, I again see the Wine Gecko installer dialog box. My hacky nightly game tests ran into this problem. The last successfull Team Fotress 2 test run is from May 14, 2009. After that my Gecko setup script failed and did not even try to start up Steam. Cheers, Stefan
Re: [2/3] d3dx9: Add utility functions for loading files and resources into memory
Am Montag, 18. Mai 2009 17:44:17 schrieb Tony Wasserka: > +HRESULT LoadFileIntoMemoryA(LPCSTR filename, LPVOID *buffer, DWORD *length) Do you need this function? Woudn't it be better to wrap A->W at the API level and have all internal functions W only? > +handle = CreateFileW(filename, GENERIC_READ, FILE_SHARE_READ, 0, OPEN_EXISTING, 0, 0); > +if(handle == INVALID_HANDLE_VALUE) return D3DERR_INVALIDCALL; > + > +*length = GetFileSize(handle, NULL); >+if(*length == INVALID_FILE_SIZE) return D3DERR_INVALIDCALL; > + > +*buffer = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, *length); Is there a particular reason not to use mmap, or whatever the Windows equivalent is?
Re: [PATCH 2/2] ole32/tests: Add tests to show the WdtpInterfacePointer marshal data looks like the result of CoMarshalInterface.
Huw Davies wrote: --- dlls/ole32/tests/usrmarshal.c | 38 +- 1 files changed, 21 insertions(+), 17 deletions(-) Hi Huw, Could you have a look at the test results are test.winehq.org> This patch and the other one against usrmarshall.c introduced some test failures on several platforms. -- Cheers, Paul.
Re: [shell32] Improve the Dutch 'about' message box
2009/5/18 Francois Gouget : > On Mon, 18 May 2009, Reece Dunn wrote: > [...] >> I was thinking of some sort of auto-layout logic, using bounding box >> calculations and metric information fed from Windows guidelines. The >> idea here is to give a consistent layout and make it easier to add new >> controls. >> >> I am aware that this is very complex, and I don't yet know how to >> transform the flat layout to a hierarchical layout that contains the >> box information necessary to do the reflow calculations. > > If we go that route, we should probably start from a bounding box-based > description of the dialogs, and then generate both the English and the > localized dialogs. > > For instance the glade format seems to be bounding-box based. It also > probably already has tools to handle localization. So we could probably > start from a English glade file describing a dialog, generate localized > versions of that file, and then, for each language, pass the dialog > through our bounding-box calculator to convert that to coordinates and > generate the corresponding rc files. Yes. That would be a better way for storing the information. The advantage of choosing something like the Glade format is that we could then take advantage of the editors for the format, so the Wine developers can edit the dialogs visually. A similar thing for the menus. The question here (which applies to any direction that is taken) is whether the format that is chosen can represent all the information in the RC file. The first step would be getting the RC <==> Box format conversion working reliably. Then adding the translation on top of that using the PO/gettext framework. - Reece
Re: DIB Engine - Mostly fixed against test suite
Am Montag, den 18.05.2009, 13:41 +0200 schrieb Massimo Del Fedele: > > Be careful with such statements. Look at bug 6519 for example. > Yep, I've seen the bug :-) > Anyways, most failures are fixed by now, also for monochrome bitmaps. > Did you test it on bug's 6519 app ? No, I don't really care. I just fixed that bug and your statement: "Color on monochrome bitmap is seldomly used anyway" sounded an alarming bell in my head. This mail was just a warning to not disregard the issue and no specific problem report. Regards, Michael Karcher
Re: [4/4]msctf: starting implementation of ITfContext::RequestEditSession and ITextStoreACPSink::OnLockGranted
Aric Stewart writes: > --- > dlls/msctf/context.c | 68 > ++-- > dlls/msctf/tests/inputprocessor.c | 29 +++- > include/textstor.idl |2 + > 3 files changed, 86 insertions(+), 13 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -M msctf.dll -T ../../.. -p msctf_test.exe.so inputprocessor.c && touch inputprocessor.ok inputprocessor.c:155: Test succeeded inside todo block: GetStatus called too many times make[2]: *** [inputprocessor.ok] Error 1 -- Alexandre Julliard julli...@winehq.org
Re: DIB Engine - Mostly fixed against test suite
Michael Karcher ha scritto: Am Sonntag, den 17.05.2009, 17:35 +0200 schrieb Massimo Del Fedele: 1) Some color on monochrome bitmaps here I guess nobody knows how to do it right. I fixed some todo wine (most) but have 2 failures which wine does right. Seldom used anyways, and happens only on weird palettes. I guess not ever Microsoft knows what they did on this respect :-) Be careful with such statements. Look at bug 6519 for example. Regards, Michael Karcher Yep, I've seen the bug :-) Anyways, most failures are fixed by now, also for monochrome bitmaps. Did you test it on bug's 6519 app ? Ciao Max
Re: DIB Engine - Mostly fixed against test suite
Austin English ha scritto: On Sun, May 17, 2009 at 10:35 AM, Massimo Del Fedele wrote: Austin, could you please retest it against test suite ? I've ran it, but it doesn't appear to be showing up on test.winehq.org. I'll investigate why when I get a bit more time. P.S., there's now a crash in user32/cursoricon. Crash "fixed" on latest post. The fix is partial, as it depends on getting the right color table of a DIB from inside GetDIBits. That can't be done using GetDIBColorTable() as it requires the DIB to be selected into a DC, which is exactly the opposite requirement og GetDIBits. I guess I have to resort to a list of DIB <---> physical bitmaps to do it reliably, as windows doesn't bring any reliable other way to do it. Concluding : crash fixed but a couple of failures in tests/bitmap.c in addition to remaining 4. Total, 6, which is not bad :-) Ciao Max
Re: [PATCH] winhttp: avoid NULL ptr dereference (Coverity 927)
Marcus Meissner writes: > Not sure if we need to set these values in all error paths, > but definitely not in the NULL lpwhr. (lpwhdr?) There's no reason to have NULL checks in internal functions. -- Alexandre Julliard julli...@winehq.org
Re: [shell32] Improve the Dutch 'about' message box
On Mon, 18 May 2009, Reece Dunn wrote: [...] > I was thinking of some sort of auto-layout logic, using bounding box > calculations and metric information fed from Windows guidelines. The > idea here is to give a consistent layout and make it easier to add new > controls. > > I am aware that this is very complex, and I don't yet know how to > transform the flat layout to a hierarchical layout that contains the > box information necessary to do the reflow calculations. If we go that route, we should probably start from a bounding box-based description of the dialogs, and then generate both the English and the localized dialogs. For instance the glade format seems to be bounding-box based. It also probably already has tools to handle localization. So we could probably start from a English glade file describing a dialog, generate localized versions of that file, and then, for each language, pass the dialog through our bounding-box calculator to convert that to coordinates and generate the corresponding rc files. -- Francois Gouget http://fgouget.free.fr/ 1 + e ^ ( i * pi ) = 0
Re: [shell32] Improve the Dutch 'about' message box
2009/5/16 Francois Gouget : > On Tue, 12 May 2009, Reece Dunn wrote: > [...] >> What I would like to do is get an automated (or semi-automated) tool, >> ideally with a GUI interface to it. That would ultimately put the >> designer in charge. Hopefully, this would also mean that you have a >> base resource file that produces the English resources and generate >> the others using the standard po files - thus making it easier to >> translate. > > Yes, handling the translation of Wine's resource files would be really > nice. It would let us leverage a lot of the po tools, especially the > website based ones. This would make it much easier for users to > contribute to the translations (right now it's pretty intimidating). I'm > not sure how to handle the widget layout though. I was thinking of some sort of auto-layout logic, using bounding box calculations and metric information fed from Windows guidelines. The idea here is to give a consistent layout and make it easier to add new controls. I am aware that this is very complex, and I don't yet know how to transform the flat layout to a hierarchical layout that contains the box information necessary to do the reflow calculations. > But I have just stumbled on this pair of tools from the > translate-toolkit packag (on Debian) that seem to be made just for this > purpose: > > * po2rc > convert Gettext PO localization files to Windows Resource (.rc) files > http://translate.sourceforge.net/wiki/toolkit/rc2po > > * rc2po > convert .rc files to Gettext PO localization files > http://translate.sourceforge.net/wiki/toolkit/rc2po > > > I don't have time to play with them but with luck someone else does. > Getting it going with Wine would be really great. Nor do I, and others are probably better qualified than me to answer. - Reece
Re: [shell32] Improve the Dutch 'about' message box
Mikołaj Zalewski wrote: > >> Yes, handling the translation of Wine's resource files would be really >> nice. It would let us leverage a lot of the po tools, especially the >> website based ones. This would make it much easier for users to >> contribute to the translations (right now it's pretty intimidating). >> I'm not sure how to handle the widget layout though. >> > I also think I would be better to use po files (without them, our > translations get out-of-sync - e.g. in start a new /Unix switch was > intruduced, but only 7 out of 16 languages has it in the help message. > For the users of the other 9 languages, we are providing an incorrect > help message. This is adding a new line to an existing message, so wrc > --verify-translation won't notice it). > I was thinking about the widget layout that may need to be different in > a translation and I think this can be solved by adding a possibility to > add some transformations of controls relative to the English ones. > Something like: > > msgid "transform.dialog.133" > msgstr "" > "control 12 resize by (10, 10)" > "control 13 move by (10, 10)" > > Making the transformations relative should make updating such resources > not very common (and in most cases there will be even no need for this). > There may still be cases when it looks ugly if e.g. one adds a new > button to the English dialog while the localized ones are enlarged and > takes a place where the new button is added, but we could be solved by > adding to msgid e.g. a hash of the English resource with localizable > stirngs removed, so that the translation will be fuzzy after a merge. > I could try to look into po2rc and rc2po if they work and can be They work, sort of. I tried them out (though not the latest version) and run into a problem where the MENUs where ignored. That is a known problem with complex MENUs according to the description of the tools on their web page. > augmented with such a functionality, but I'm not sure if I will have > time soon. bye michael
Re: DIB Engine - Mostly fixed against test suite
Am Sonntag, den 17.05.2009, 17:35 +0200 schrieb Massimo Del Fedele: > 1) Some color on monochrome bitmaps here I guess nobody knows how to do > it right. I fixed some todo wine (most) but have 2 failures which wine does > right. > Seldom used anyways, and happens only on weird palettes. I guess not ever > Microsoft knows what they did on this respect :-) Be careful with such statements. Look at bug 6519 for example. Regards, Michael Karcher signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
