Re: kernel: updated French translation
There are a few mistakes in your translations : The right translation for Overflow is Dépassement, not Dépacement You often use the word Mauvais as a translation for Bad. Sometimes, it could be better not to translate literally. For example, I think Niveau de pilote incorrect is a better translation for Bad driver level than Mauvais niveau de pilote. You should try to avoid Mauvais anytime you can. Last thing : I'm not sure Sémaphore is a female word in french : http://fr.wikipedia.org/wiki/S%C3%A9maphore_(informatique) Laurent Jonathan Ernst wrote:
Re: kernel: updated French translation
Hi, There is a mistake here : L'acquéreur de le sémaphore est mort The right translation is : L'acquéreur du sémaphore est mort The translation of broken pipe is not good too, but I can't find anything better on the internet. You should maybe try something like Tube indisponible (broken pipe), if you think it is better. Laurent Jonathan Ernst wrote:
Mistakes in my yesterday evening patches
I have send 4 patches yesterday. The 2 first of them are tagged resend. Please do not take those two first patches into account, they have already been merged in the git tree. My proxy played me a trick, i haven't see that before I sent them again. Only the 2 last ones (3/4 and 4/4) are to be merged by now. Sorry for my mistake, Laurent
Re: [1/2] gdiplus: rendering of linecaps [try2]
Why do you use M_PI / 2.0 or M_PI / 4.0 and not directly M_PI_2 and M_PI_4?
Laurent
Evan Stade a écrit :
Hi,
[try2] Removed non-portable constructs.
Changelog:
* added helpers that render line caps
* added end cap drawing for GdipDrawLineI
dlls/gdiplus/graphics.c | 220
++-
dlls/gdiplus/pen.c |5 -
2 files changed, 217 insertions(+), 8 deletions(-)
diff --git a/dlls/gdiplus/graphics.c b/dlls/gdiplus/graphics.c
index 4765e33..6c40aec 100644
--- a/dlls/gdiplus/graphics.c
+++ b/dlls/gdiplus/graphics.c
@@ -27,8 +27,11 @@ #include gdiplus.h
#include gdiplus_private.h
#include wine/debug.h
-/* looks-right constant */
+WINE_DEFAULT_DEBUG_CHANNEL(gdiplus);
+
+/* looks-right constants */
#define TENSION_CONST (0.3)
+#define ANCHOR_WIDTH (2.0)
static inline INT roundr(REAL x)
{
@@ -108,6 +111,212 @@ static void calc_curve_bezier_endp(REAL
*y = roundr(tension * (yadj - yend) + yend);
}
+/* Draws the linecap the specified color and size on the hdc. The linecap is in
+ * direction of the line from x1, y1 to x2, y2 and is anchored on x2, y2. */
+static void draw_cap(HDC hdc, COLORREF color, GpLineCap cap, REAL size,
+REAL x1, REAL y1, REAL x2, REAL y2)
+{
+HGDIOBJ oldbrush, oldpen;
+HBRUSH brush;
+HPEN pen;
+POINT pt[4];
+REAL theta, dsmall, dbig, dx, dy, invert;
+
+if(x2 != x1)
+theta = atan((y2 - y1) / (x2 - x1));
+else if(y2 != y1){
+theta = M_PI / 2.0 * (y2 y1 ? 1.0 : -1.0);
+}
+else
+return;
+
+invert = ((x2 - x1) = 0.0 ? 1.0 : -1.0);
+brush = CreateSolidBrush(color);
+pen = CreatePen(PS_SOLID, 1, color);
+oldbrush = SelectObject(hdc, brush);
+oldpen = SelectObject(hdc, pen);
+
+switch(cap){
+case LineCapFlat:
+break;
+case LineCapSquare:
+case LineCapSquareAnchor:
+case LineCapDiamondAnchor:
+size = size * (cap LineCapNoAnchor ? ANCHOR_WIDTH : 1.0) / 2.0;
+if(cap == LineCapDiamondAnchor){
+dsmall = cos(theta + M_PI / 2.0) * size;
+dbig = sin(theta + M_PI / 2.0) * size;
+}
+else{
+dsmall = cos(theta + M_PI / 4.0) * size;
+dbig = sin(theta + M_PI / 4.0) * size;
+}
+
+/* calculating the latter points from the earlier points makes them
+ * look a little better because of rounding issues */
+pt[0].x = roundr(x2 - dsmall);
+pt[1].x = roundr(((REAL)pt[0].x) + dbig + dsmall);
+
+pt[0].y = roundr(y2 - dbig);
+pt[3].y = roundr(((REAL)pt[0].y) + dsmall + dbig);
+
+pt[1].y = roundr(y2 - dsmall);
+pt[2].y = roundr(dbig + dsmall + ((REAL)pt[1].y));
+
+pt[3].x = roundr(x2 - dbig);
+pt[2].x = roundr(((REAL)pt[3].x) + dsmall + dbig);
+
+Polygon(hdc, pt, 4);
+
+break;
+case LineCapArrowAnchor:
+size = size * 4.0 / sqrt(3.0);
+
+dx = cos(M_PI / 6.0 + theta) * size * invert;
+dy = sin(M_PI / 6.0 + theta) * size * invert;
+
+pt[0].x = roundr(x2 - dx);
+pt[0].y = roundr(y2 - dy);
+
+dx = cos(- M_PI / 6.0 + theta) * size * invert;
+dy = sin(- M_PI / 6.0 + theta) * size * invert;
+
+pt[1].x = roundr(x2 - dx);
+pt[1].y = roundr(y2 - dy);
+
+pt[2].x = roundr(x2);
+pt[2].y = roundr(y2);
+
+Polygon(hdc, pt, 3);
+
+break;
+case LineCapRoundAnchor:
+dx = dy = ANCHOR_WIDTH * size / 2.0;
+
+x2 = (REAL) roundr(x2 - dx);
+y2 = (REAL) roundr(y2 - dy);
+
+Ellipse(hdc, (INT) x2, (INT) y2, roundr(x2 + 2.0 * dx),
+roundr(y2 + 2.0 * dy));
+break;
+case LineCapTriangle:
+size = size / 2.0;
+dx = cos(M_PI / 2.0 + theta) * size;
+dy = sin(M_PI / 2.0 + theta) * size;
+
+/* Using roundr here can make the triangle float off the end of the
+ * line. */
+pt[0].x = ((x2 - x1) = 0 ? floor(x2 - dx) : ceil(x2 - dx));
+pt[0].y = ((y2 - y1) = 0 ? floor(y2 - dy) : ceil(y2 - dy));
+pt[1].x = roundr(pt[0].x + 2.0 * dx);
+pt[1].y = roundr(pt[0].y + 2.0 * dy);
+
+dx = cos(theta) * size * invert;
+dy = sin(theta) * size * invert;
+
+pt[2].x = roundr(x2 + dx);
+pt[2].y = roundr(y2 + dy);
+
+Polygon(hdc, pt, 3);
+
+break;
+case LineCapRound:
+dx = -cos(M_PI / 2.0 + theta) * size * invert;
+dy = -sin(M_PI / 2.0 + theta) * size * invert;
+
+pt[0].x = ((x2 - x1) = 0 ? floor(x2 - dx) : ceil(x2 - dx));
+pt[0].y = ((y2 - y1) = 0 ? floor(y2 - dy) :
Re: GDI+ programs
Evan Stade a écrit : Hi, I want to make some real applications work with the built-in wine GDI+. Does anyone know of some programs that use GDI+ that would be good for guiding my development? thanks, Evan Stade Navigation uses it (see in AppDB or at http://francois.fouchet.free.fr/ ) Laurent
Re: RegDeleteTree [7] [resend]
There is a few tabs in the file : Here (line 92), first blank character : + dwValCount, NULL, NULL, NULL, NULL); Here (line 103) + } Laurent Hello, any comment on the current version of this patch? ChangeLog - added implementation of RegDeleteTreeA/W
Re: RegDeleteTree [7] [resend]
Stefan Leichter a écrit : Am Tuesday 22 May 2007 18:05 schrieb Laurent Vromman: There is a few tabs in the file : Here (line 92), first blank character : + dwValCount, NULL, NULL, NULL, NULL); Here (line 103) + } Laurent Hello Laurent, thank you for the comment. How did you spot the first tab? Rechecking the indentation i can see the second one, but not the first. Bye Stefan If have a software which displays arrows where there are tabs in the file. I opened it and I just saw the two arrows. Laurent
Re: gdi32: check for null-pointer in CreateDIBSection
Hi, I am not sure at all there a link between what I say and a hiding bug somewhere around this patch, but bug 8088 is due to a problem around DIB section and bitmapinfo too. Maybe a cross analysis between those two bugs could help find this hiding bug. I hope this can help, Laurent Jesse Allen a écrit : On 5/19/07, Louis. Lenders [EMAIL PROTECTED] wrote: Hi , this fixes bug 8066, http://bugs.winehq.org/show_bug.cgi?id=8066 See the crash log here: http://bugs.winehq.org/attachment.cgi?id=5800action=view , CreateDIBSection is called with bitmapinfo = null. The program should be passing in a correctly initialized BITMAPINFO. We need to make sure this isn't hiding another bug. Could you provide a test case?
Re: review: add Video Memory text input to winecfg Graphics/Direct3D tab
case CBN_SELCHANGE: {
SendMessage(GetParent(hDlg), PSM_CHANGED, 0, 0);
switch (LOWORD(wParam)) {
- case IDC_D3D_VSHADER_MODE:
on_d3d_vshader_mode_changed(hDlg); break;
- }
+case IDC_D3D_VSHADER_MODE: on_d3d_vshader_mode_changed(hDlg);
break;
+case IDC_VIDEOMEMORY_SIZE_COMBO:
set_from_videomemory_size_changed(hDlg); break;
+}
I believe you should align your indentation method on the one the file already
uses (ie tabs, not spaces).
+// vim:sw=4:expandtab
This has nothing to do with wine
Laurent
On Wed, 16 May 2007 15:03:52 +0200, Vit Hrachovy [EMAIL PROTECTED] wrote:
Hi,
the attached patch adds new editable combobox input 'Video Memory size'
for Graphics/Direct3D tab of winecfg.
I've tried to implement Frank's comments to English language only.
Please consider this patch as a proposal, so if it gets positive review,
I'll propagate the changes to all remaining language resources.
May I kindly ask someone for the patch review?
Regards
Vit
Re: review: add Video Memory text input to winecfg Graphics/Direct3D tab
It is not really as I wish. I have just noticed that there is two different
kind of indentation in the mentioned switch loop, which looked strange on the
moment.
I am really not a wine master, others will maybe fixed us.
Laurent
On Wed, 16 May 2007 15:59:06 +0200, Vit Hrachovy [EMAIL PROTECTED] wrote:
On Wed, May 16, 2007 at 03:18:22PM +0200, Laurent Vromman wrote:
case CBN_SELCHANGE: {
SendMessage(GetParent(hDlg), PSM_CHANGED, 0, 0);
switch (LOWORD(wParam)) {
-case IDC_D3D_VSHADER_MODE:
on_d3d_vshader_mode_changed(hDlg);
break;
-}
+case IDC_D3D_VSHADER_MODE:
on_d3d_vshader_mode_changed(hDlg); break;
+case IDC_VIDEOMEMORY_SIZE_COMBO:
set_from_videomemory_size_changed(hDlg); break;
+}
I believe you should align your indentation method on the one the file
already uses (ie tabs, not spaces).
+// vim:sw=4:expandtab
This has nothing to do with wine
Laurent
Hi Laurent
citing from: http://www.winehq.org/site/docs/winedev-guide/style-notes
Tabs are not forbidden but discouraged. A tab is defined as 8
characters and the usual amount of indentation is 4 characters.
and from: http://www.winehq.org/site/sending_patches
Don't mix tabs and spaces because it makes the diff output
unreadable, use consistent indentation.
The actual file contents breaks both citations above, my code doesn't
conflict with any one of them.
For vim footer, I agree it shall not be present. If the only comment
regards formatting, I'm happy and I can fix the formatting as You wish.
Cheers
Vit
Re: crypt32: fix a wrong test
-ok(info-dwKeySpec == AT_SIGNATURE, +ok(info-dwKeySpec == (AT_SIGNATURE|AT_KEYEXCHANGE), Expected AT_SIGNATURE, got %d\n, info-dwKeySpec); It could be a good idea to correct the error text Expected AT_SIGNATURE to add AT_KEYEXCHANGE in it. Laurent Vromman On Mon, 07 May 2007 16:05:35 +0200, Mounir IDRASSI [EMAIL PROTECTED] wrote: Hi, This patch corrects a test in crypt32 that was incorrectly written to accommodate the bug in rsaenh dll we corrected in our previous patch. Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr
Re: [try2] gdi32 : Completes WidenPath Implementation
I have sent this patch last week with the correction Alexandre asked me to do. It is still not on the repository. Is there anything wrong again ? Any comments are welcomed and will be applied if necessary. Laurent Laurent Vromman a écrit : This second try includes Alexandre comments and removes some obsolete FIXME Changelog : Completes WidenPath implementation. WidenPath recognizes PS_JOINs and PS_ENDCAPs --- dlls/gdi32/path.c | 298 + 1 files changed, 230 insertions(+), 68 deletions(-)
Question using appdb
Hi, When a distribution is absent from the list, we are supposed to add it, as the following message explain : DistributionIf yours is not on the list, please add it using the form below The fact is, there is no form below. Is the message wrong or is the form missing ? Note : The distribution I want to add is the new Debian Lenny Laurent Vromman
Re: Question using appdb
Thank you for that. Finally, what's wrong with the Distribition section in the form ? Laurent On Wed, 18 Apr 2007 10:44:18 +0100, Ben Hodgetts [EMAIL PROTECTED] wrote: Laurent Vromman wrote: So the text If yours is not on the list, please add it using the form below should be considered obsolete ? Laurent On Wed, 18 Apr 2007 10:57:51 +0200, Marcus Meissner [EMAIL PROTECTED] wrote: On Wed, Apr 18, 2007 at 10:41:07AM +0200, Laurent Vromman wrote: Hi, When a distribution is absent from the list, we are supposed to add it, as the following message explain : Distribution If yours is not on the list, please add it using the form below The fact is, there is no form below. Is the message wrong or is the form missing ? Note : The distribution I want to add is the new Debian Lenny Well, the usual way is to just submit a patch against the lostwages CVS module to include it. Ciao, Marcus FYI I've just added Lenny to the list, it lacks a version number at the moment (because it doesn't actually have one) so I'll need to edit that when/if they assign a version number later. Ex.
Re: [try2] kernel32: Add partial stub for NeedCurrentDirectoryForExePath
+/***
+ * NeedCurrentDirectoryForExePathA (KERNEL32.@)
+ */
+BOOL WINAPI NeedCurrentDirectoryForExePathA( LPCSTR name )
+{
+WCHAR *nameW;
+
+if (!(nameW = FILE_name_AtoW( name, FALSE ))) return TRUE;
If FILE_name_AtoW fails, the function fails, so the return value should be
FALSE, shouldn't it ?
Laurent
On Wed, 18 Apr 2007 15:54:42 +0400, Kirill K. Smirnov [EMAIL PROTECTED]
wrote:
Please, ignore my previous attempt.
gdi32 : Questions about SetDIBColorTable and GetDIBColorTable
Hi,
I am looking deeper inside gdi32 in order to continue helping wine after my
first try on WidenPath.
Something looks strange to me in SetDIBColorTable and GetDIBColorTable.
GetDIBColorTable is structured like this :
if (dc-funcs-pGetDIBColorTable)
result = dc-funcs-pGetDIBColorTable;
else
{
result = local implementation;
}
return result;
This looks normal. If dc-funcs-pGetDIBColorTable is available, wine uses it,
else it uses a local implementation.
In both cases, the return value is the result of the chosen operation.
But I have more difficulties with SetDIBColorTable :
result = local implementation;
if (dc-funcs-pGetDIBColorTable)
dc-funcs-pGetDIBColorTable;
return result;
Whatever happen next, the local implementation is used. Then if
pGetDIBColorTable is available, it is used too. I see here a second call for
the same thing, even if the local implementation succeed. Moreover, the result
of dc-funcs-pGetDIBColorTable is not used as a return value.
Is there a mistake here, or is there something I do not understand ?
GetDIBColorTable uses the local implementation only if dc-funcs is not
available. That is not the case for SetDIBColorTable, which runs first the
local implementation.
What is the right policy to apply here ?
I believe the call order of pSetDIBColorTable and the fact its return value is
not used are errors. Am i wrong? If someone can confirm I am not, I will
provide a patch in the next days.
Thank you for your help and time,
Laurent Vromman
re: Which component should I use to create this bug ?
The application homepage is http://francois.fouchet.free.fr/ There is now an entry in AppDB for it. I will try winetricks when home. Thank you for your help. Laurent On Mon, 16 Apr 2007 08:20:47 -0700, Dan Kegel [EMAIL PROTECTED] wrote: lauren wrote: When Navigation is installed, the file DAO350.dll is copied to the Common Files directory and is regsrved. When running Navigation after that, it displays an error message about not finding DAO350.dll. Copying the file to windows/system32 allows Navigation to find the file and use it, but it should be able to find it in Common Files too. Which component should I choose ? If installing native dcom fixes it, use wine-ole. (e.g. winetricks dcom98) If in doubt, use wine-misc. (Native MSI doesn't seem to work right now, so don't try that... see http://bugs.winehq.org/show_bug.cgi?id=5809 ) Navigation is a Visual Basic program, using VB methods to load dlls. Be sure to give the app's home page. If you had mentioned it in this message, I would have tried it out myself... - Dan
Questions about gdi32:WidenPath patch sent on jan. 27
Hi, I've tried to send my first patch on jan. 27. This patch is supposed to add a partial implementation of WidenPath to gdi32.dll. After two weeks, I don't have any news about the patch. Is it still pending ? Is there something wrong with it ? I am ready to improve it if necessary, but I need some advice to now what needs to be improved in it. Thank you for your help. Laurent
Questions about OleLoadPictureEx and SetDIBColorTable
Hi,
I'm still working on the freeware Navigation
(http://francois.fouchet.free.fr/) which will soon be added to AppDB.
I produced a working version of WidenPath (a priliminary patch will come
soon).
Another problem appeared in an other place (which was masked because of
WidenPath at the beginning).
Navigation triggers a problem in SetDIBColorTable. I investigate a
little, but I don't know enough to conclude. I need your help.
In SetDIBColorTable, this particular test failed :
/* Check if currently selected bitmap is a DIB */
if (bitmap-color_table)
Here is the source code (in vb) in Navigation :
Set hDessin = LoadGif(LocFile) '#* (uses LoadPicture in a StdPicture)
ShowErr SelectObject(Plans(plDessin).hdc, hDessin), SelectObject
Dessin:#Here#
ShowErr SetDIBColorTable2(Plans(plDessin).hdc, 0, 256,
PaletteAltitude(0)), SetDIBColorTable:#Here#
Just before the failure, Navigation uses OleLoadPictureEx, which is
partially implemented :
fixme:ole:OleLoadPictureEx
(0xee06ec,343250,1,{00020400---c000-0046},x=0,y=0,f=0,0x33dd48),
partially implemented.
I don't really know what happen, since I don't understand everything in
those differents functions. Can anyone please help me to investigate
more precisely to discover want happen, and try to correct something if
necessary ?
Thank you all,
Laurent
New list subscriber - Question about gdi:widenpath
Hi, My name is Laurent. I'm french, 23 year old, software designer for a huge european company. I'm trying make a french software called Navigation, used by airplane pilots and created using visual basic, work on linux using wine. The point is this software needs gdi:widenpath to work. I'd just like to know if this function is planned for the next release or if I will have to wait a little more. I'd like to provide a patch for this particular function but unfortunatly, my development skills are far to low to do it without any help. Does anyone have informations about this function ? Thank you for your help. Laurent
