Re: implement PS_USERSTYLE handling - obviously not correct ;)
On Sat, Apr 4, 2009 at 4:49 PM, Hans Breuer wrote: > Hi, > just read again http://www.winehq.org/sending_patches and noticed that my > first wine patch may fall in the category of not deserving an answer at all > (to your standards). > Not always the case. It could be just that no one is familiar enough with that exact part of the code to provide feed back at a glance. > But before resending it, I would appreciate some feedback if something else > is 'obviously' wrong with it. To me it seems to be very difficult for the > issue at hand to fall into the category of being "Obvious(ly) Correct". > > What can I do to increase the probability of the patch being accepted? > Adding test cases goes along way towards being obviously correct and getting accepted into mainstream wine. --John Klehm
implement PS_USERSTYLE handling - obviously not correct ;)
Hi,
just read again http://www.winehq.org/sending_patches and noticed that my
first wine patch may fall in the category of not deserving an answer at all
(to your standards).
The one thing I noticed is my mail client putting line-wrapping into the
patch, which should be easy to correct.
But before resending it, I would appreciate some feedback if something else
is 'obviously' wrong with it. To me it seems to be very difficult for the
issue at hand to fall into the category of being "Obvious(ly) Correct".
Although the X11 and win32 concepts of extended line styles are very
similar, at least I did not know the scaling issues involved without trying
it out.
One thing which may be considered critical is my selection of the test
program. As noted it is Dia for win32 (ported by me [1]) through
gdk-win32-drawing code (PS_USERSTYLE usage implemented by me [2]).
So if I have misunderstood something there seven years ago, that two bugs
could compensate each other ;)
Another issue might be the unconditional implementation of PS_USERSTYLE.
After all it is only available with NT-based windows. Should x11drv check
for the version being emulated to also reproduce the failing behaviour? Or
would that be too much compatibility?
What can I do to increase the probability of the patch being accepted?
Thanks,
Hans
[1] http://hans.breuer.org/dia/
[2] http://svn.gnome.org/viewvc/gtk%2B?view=revision&revision=6330
[3] http://hans.breuer.org/dia/dia-wine.htm
Original-Nachricht
Betreff: implement PS_USERSTYLE handling, tested with Dia(win32)
Datum: Sun, 29 Mar 2009 19:45:05 +0200
Von: Hans Breuer
An: wine-patc...@winehq.org
From b89af7d06fc8cbf5210c61fd58ed62caeddad968 Mon Sep 17 00:00:00 2001
From: Hans Breuer
Date: Sun, 29 Mar 2009 18:27:29 +0200
Subject: implement PS_USERSTYLE handling, tested with Dia(win32) - see
http://hans.breuer.org/dia/dia-wine.htm
---
dlls/winex11.drv/pen.c | 31 +++
1 files changed, 27 insertions(+), 4 deletions(-)
diff --git a/dlls/winex11.drv/pen.c b/dlls/winex11.drv/pen.c
index 49fe74c..039798e 100644
--- a/dlls/winex11.drv/pen.c
+++ b/dlls/winex11.drv/pen.c
@@ -54,12 +54,33 @@ HPEN CDECL X11DRV_SelectPen( X11DRV_PDEVICE *physDev,
HPEN hpen )
elp = HeapAlloc( GetProcessHeap(), 0, size );
GetObjectW( hpen, size, elp );
-/* FIXME: add support for user style pens */
logpen.lopnStyle = elp->elpPenStyle;
logpen.lopnWidth.x = elp->elpWidth;
logpen.lopnWidth.y = 0;
logpen.lopnColor = elp->elpColor;
-
+/* support for user style pens */
+if (MAX_DASHLEN < elp->elpNumEntries)
+{
+FIXME("PS_USERSTYLE: len(dashes)>MAX_DASHLEN %d,%d\n",
elp->elpNumEntries, MAX_DASHLEN);
+physDev->pen.dash_len = 0;
+}
+else
+{
+BOOL overflow = FALSE;
+physDev->pen.dash_len = elp->elpNumEntries;
+for (i = 0; i < elp->elpNumEntries; ++i)
+{
+if (elp->elpStyleEntry[i] > 255)
+{
+overflow = TRUE; /* can't fit the type */
+physDev->pen.dashes[i] = 255;
+}
+else
+physDev->pen.dashes[i] = (char)elp->elpStyleEntry[i];
+}
+if (overflow)
+FIXME("PS_USERSTYLE: dashes clipped (type overflow)\n");
+}
HeapFree( GetProcessHeap(), 0, elp );
}
else
@@ -108,14 +129,16 @@ HPEN CDECL X11DRV_SelectPen( X11DRV_PDEVICE *physDev,
HPEN hpen )
memcpy(physDev->pen.dashes, PEN_alternate,
physDev->pen.dash_len);
break;
case PS_USERSTYLE:
-FIXME("PS_USERSTYLE is not supported\n");
+/* handled above */
+break;
/* fall through */
default:
physDev->pen.dash_len = 0;
break;
}
if(physDev->pen.ext && physDev->pen.dash_len &&
-(logpen.lopnStyle & PS_STYLE_MASK) != PS_ALTERNATE)
+(logpen.lopnStyle & PS_STYLE_MASK) != PS_ALTERNATE &&
+(logpen.lopnStyle & PS_STYLE_MASK) != PS_USERSTYLE)
for(i = 0; i < physDev->pen.dash_len; i++)
physDev->pen.dashes[i] *= (physDev->pen.width ?
physDev->pen.width : 1);
--
1.6.0.6
Hans "at" Breuer "dot" Org ---
Tell me what you need, and I'll tell you how to
get along without it.-- Dilbert
Re: winemenubuilder: disable debug output for .desktop files
On Sat, Apr 4, 2009 at 1:37 PM, Warren Dumortier wrote: > I just responded to my previous mail, nice to see you care about that issue! > > I just want to say that nobody uses the desktop file to launch a program to > debug, i think, in response to previous messages. That would be very nice. > > Is it difficult to implement? Why not simply add WINEDEBUG-all to generated > desktop files? Maybe i didn't understand the discussion... This would add WINEDEBUG="-all" to all .desktop files. Vincent is saying that stderr may not be lost when someone runs from a .desktop file, e.g., that information may be captured/redirected somewhere. -- -Austin
Re: winemenubuilder: disable debug output for .desktop files
I just responded to my previous mail, nice to see you care about that issue!
I just want to say that nobody uses the desktop file to launch a program to
debug, i think, in response to previous messages. That would be very nice.
Is it difficult to implement? Why not simply add WINEDEBUG-all to generated
desktop files? Maybe i didn't understand the discussion...
2009/4/4 Vincent Povirk
>
> On Fri, Apr 3, 2009 at 4:05 PM, Vincent Povirk
> > wrote:
> > I'll work on a patch for the FIXME thing.
>
> Turns out this is not "fairly easy" but actually "incredibly
> difficult". We have a fallback case at
> http://source.winehq.org/source/include/wine/debug.h#L133 with a macro
> that returns a statement that ends in a function call, omitting the
> arguments and semicolon. This allows us to do
> FIXME_(channel)("message\n");. I can handle this in the other cases
> (where the macro result ends in a macro that takes arguments), but I
> can't see a way to create a static variable in a statement that ends
> in a function call that we only execute sometimes.
>
> Vincent Povirk
>
>
>
Re: urlmon/misc test and the use of URLZONEREG_DEFAULT
Detlef Riekenberg wrote: On Fr, 2009-04-03 at 20:49 +0200, Paul Vriens wrote: urlmon:misc misc.c:884: Test failed: (1400) policy=3, expected 0 misc.c:884: Test failed: (1e05) policy=1, expected 2 So the question is, does somebody now what URLZONEREG_DEFAULT defaults to? HKCR or HKLM and is this always the same or are there circumstances that make the default different. I guess I could write a test that checks both HKLM and HKCR and directly modifies the registry values in both hives to see what IInternetZoneManager_GetZoneActionPolicy() is using. Ok, I see on test.winehq.org that I'm not the only one: http://test.winehq.org/data/30041c283a77903a1439bef65f96eebbdf90e461/2000_dr-asus/urlmon:misc.html http://test.winehq.org/data/6b6d18d766893ff10a38a4efbbe5ef4ef8e9828b/xp_dr-asus/urlmon:misc.html When I install a system, I change some IE security settings with the internet control panel. Independant from this thread, I found this description yesterday; http://support.microsoft.com/kb/182569 From the kb page, the settings are stored in HKCU and read from there, unless forced to HKLM by Group Policy or the DWORD Security_HKLM_only I was actually looking at that page yesterday but for something else, duh. I guess for now we should be save to change the tests to check for HKCU instead of HKLM (our implementation uses HKCU for default as well). If there is need we can extend the tests to cover the rules mentioned on that page (which is a lot). -- Cheers, Paul.
Re: [2/2] shell32: Define PT_FOLDERW.
2009/4/4 Austin English : > On Sat, Apr 4, 2009 at 11:55 AM, Nicolas Le Cam wrote: >> 2009/4/4 Austin English : >>> On Sat, Apr 4, 2009 at 6:59 AM, Nicolas Le Cam wrote: Define PT_FOLDERW in pidl.h to complete this series. >>> >>> You're changing the indent of some of the defines. If you're going to >>> change some, change them all to make them consistent (PT_COMP has two >>> tabs). >>> >>> >>> >>> -- >>> -Austin >>> >> Hi Austin, >> >> PT_COMP has two tabs to be aligned with other defines (TAB is defined >> as 8 chars large as I read it multiple times on this list). >> I just wanted to uniformise this part of the file, if needed I can >> resend this series without them. > > Whoops, my editor's fault, sorry. The other areas of the define aren't > uniform, but it's not a terribly big deal. I only mention it in case > you resend the patch set. > > -- > -Austin > Strange, it's uniform on mine ... at least for the #define PT_.. part -- Nicolas Le Cam
Re: [2/2] shell32: Define PT_FOLDERW.
On Sat, Apr 4, 2009 at 11:55 AM, Nicolas Le Cam wrote: > 2009/4/4 Austin English : >> On Sat, Apr 4, 2009 at 6:59 AM, Nicolas Le Cam wrote: >>> Define PT_FOLDERW in pidl.h to complete this series. >> >> You're changing the indent of some of the defines. If you're going to >> change some, change them all to make them consistent (PT_COMP has two >> tabs). >> >> >> >> -- >> -Austin >> > Hi Austin, > > PT_COMP has two tabs to be aligned with other defines (TAB is defined > as 8 chars large as I read it multiple times on this list). > I just wanted to uniformise this part of the file, if needed I can > resend this series without them. Whoops, my editor's fault, sorry. The other areas of the define aren't uniform, but it's not a terribly big deal. I only mention it in case you resend the patch set. -- -Austin
Re: [2/2] shell32: Define PT_FOLDERW.
2009/4/4 Austin English : > On Sat, Apr 4, 2009 at 6:59 AM, Nicolas Le Cam wrote: >> Define PT_FOLDERW in pidl.h to complete this series. > > You're changing the indent of some of the defines. If you're going to > change some, change them all to make them consistent (PT_COMP has two > tabs). > > > > -- > -Austin > Hi Austin, PT_COMP has two tabs to be aligned with other defines (TAB is defined as 8 chars large as I read it multiple times on this list). I just wanted to uniformise this part of the file, if needed I can resend this series without them. Thanks for the review -- Nicolas Le Cam
Re: [2/2] shell32: Define PT_FOLDERW.
On Sat, Apr 4, 2009 at 6:59 AM, Nicolas Le Cam wrote: > Define PT_FOLDERW in pidl.h to complete this series. You're changing the indent of some of the defines. If you're going to change some, change them all to make them consistent (PT_COMP has two tabs). -- -Austin
Re: urlmon/misc test and the use of URLZONEREG_DEFAULT
On Fr, 2009-04-03 at 20:49 +0200, Paul Vriens wrote: > >> urlmon:misc > >> misc.c:884: Test failed: (1400) policy=3, expected 0 > >> misc.c:884: Test failed: (1e05) policy=1, expected 2 > >> So the question is, does somebody now what URLZONEREG_DEFAULT defaults > >> to? HKCR or HKLM and is this always the same or are there > >> circumstances that make the default different. > >> > >> I guess I could write a test that checks both HKLM and HKCR and > >> directly modifies the registry values in both hives to see what > >> IInternetZoneManager_GetZoneActionPolicy() is using. > Ok, I see on test.winehq.org that I'm not the only one: > > http://test.winehq.org/data/30041c283a77903a1439bef65f96eebbdf90e461/2000_dr-asus/urlmon:misc.html > http://test.winehq.org/data/6b6d18d766893ff10a38a4efbbe5ef4ef8e9828b/xp_dr-asus/urlmon:misc.html When I install a system, I change some IE security settings with the internet control panel. Independant from this thread, I found this description yesterday; http://support.microsoft.com/kb/182569 >From the kb page, the settings are stored in HKCU and read from there, unless forced to HKLM by Group Policy or the DWORD Security_HKLM_only -- By by ... Detlef
Re: 'Interactive' tests on Windows 2003
From: "James Hawkins" > On Fri, Jun 13, 2008 at 8:40 AM, Francois Gouget wrote: > > > > Someone asked to check which tests require interaction when running in > > my Windows 2003 VM. However I cannot find the corresponding email (it > > might have been on irc), so I'm sending this data to the list. > > > > So the only interaction that was needed was caused by this IE > > security dialog: > > > >Content within this application coming from the Web site listed > >below is being blocked by Internet Explorer Enhanced Security > >Configuration. > > > > > > Only three tests were impacted: > > * mshtml_test dom > > -> 1508 tests run but 0 failures happened when just closing the > > dialog. > > > > * mshtml_test script (about:security_mshtml_test.exe) > > -> 21 tests run and 13 failures if the dialog is just closed, and 0 > > failures if mshtml_test is manually added to the 'allowed' list. > > > > * urlmon_test misc > > -> 923 tests run but 0 failures if the dialog is just closed. > > > > > > When run by winetest these tests just time out though. > > > > Thanks Francois (I asked on IRC a while back). I get these dialogs in > 2k3 as well. Do you think we should add a check for > winetest_interactive before the calls that bring up the permission > dialog? If anyone else knows of a better way, let us know. Actually, the interactive test is already there: http://www.winehq.org/pipermail/wine-cvs/2009-January/051706.html http://www.winehq.org/pipermail/wine-cvs/2009-January/051707.html Ge.
Re: 'Interactive' tests on Windows 2003
ClamAV 0.93 Status: RO X-Status: X-Keywords: X-UID: 129496 On Fri, Jun 13, 2008 at 8:40 AM, Francois Gouget wrote: > > Someone asked to check which tests require interaction when running in > my Windows 2003 VM. However I cannot find the corresponding email (it > might have been on irc), so I'm sending this data to the list. > > So the only interaction that was needed was caused by this IE > security dialog: > >Content within this application coming from the Web site listed >below is being blocked by Internet Explorer Enhanced Security >Configuration. > > > Only three tests were impacted: > * mshtml_test dom > -> 1508 tests run but 0 failures happened when just closing the > dialog. > > * mshtml_test script (about:security_mshtml_test.exe) > -> 21 tests run and 13 failures if the dialog is just closed, and 0 > failures if mshtml_test is manually added to the 'allowed' list. > > * urlmon_test misc > -> 923 tests run but 0 failures if the dialog is just closed. > > > When run by winetest these tests just time out though. > Thanks Francois (I asked on IRC a while back). I get these dialogs in 2k3 as well. Do you think we should add a check for winetest_interactive before the calls that bring up the permission dialog? If anyone else knows of a better way, let us know. -- James Hawkins
Re: gdi32/enhmfdrv: Actaully save the state in SaveDC and RestoreDCin the metafile
Hi Dmitry, Yeah, Alexandre did not like any of my patches and feels that duplicating the GDI code would be incorrect (it would result in too many SelectObject records and such) so he had me write up patch with a bunch of tests as wine_todos that demonstrate the problem so he could think about how to make it work. -aric Dmitry Timoshkov wrote: It would be cleaner to check for GDI_NO_MORE_WORK in SaveDC/RestoreDC instead of duplicating their code.
Re: gdi32/enhmfdrv: Actaully save the state in SaveDC and RestoreDCin the metafile
It would be cleaner to check for GDI_NO_MORE_WORK in SaveDC/RestoreDC instead of duplicating their code. -- Dmitry.
