August 2007 - Wine-Devel - list.winehq.org

Re: notepad: Add program icon
by Pedro Araújo Aug. 29, 2007

Aug. 29, 2007

On 8/27/07, Alexander Nicolaysen Sørnes <alex(a)thehandofagony.com> wrote: > notepad: Add program icon > > And now for the usual Wine oath: :) > I swear under pain of treason that the icon is my own work. > > .png attached if anyone wants to look at it. It's really not all that pretty. > > Alexander N. Sørnes I had this quick and dirty (okay, *very* dirty) mockup lying around for a while (not at all a very long while) and thought somebody might find some use for it... just in case. Ah, yeah, I too "swear under pain of treason" that I did it myself. :-) (I still have the original svg here if anyone wants it) - Pedro.

2 1

Re: try2:patch for sysparams.c
by L. Rahyen Aug. 29, 2007

Aug. 29, 2007

On Wednesday August 29 2007 09:15, Ivan Sinitsin wrote: > Has corrected "logpixels=72" to " logpixels = 96 " and has changed the > indentation > > This patch adds an opportunity for fonts of the menu, statusbar and > messages to increase depending on logpixels. > > > Changelog: > This patch does a font for the menu,statusbar and messages dependent from > logpixels. With your patch applied to current GIT head I have too large fonts in all menus even in notepad if for example I have set logpixels to 120 dpi using winecfg. "Too large" means MUCH larger than in, for example, winecfg itself (you need to restart the program to see the effect). See atached snapshot to see how notepad looks like with your patch if I set 120 dpi in winecfg. Font size is ridiculously big! For testing I have used clean WINE with your patch only and clean WINEPREFIX. In Windows and current WINE without your patch in clean WINEPREFIX all fonts are of same size no matter what DPI I set in LogPixels or winecfg and this is correct behavior. What application you are trying to fix?

1 0

Re: winex11.drv[2/2]: Support GdiAlphaBlend with blendfn.AlphaFormat == 0 (fixes bug #9262)
by Alexandre Julliard Aug. 29, 2007

Aug. 29, 2007

"Mikolaj Zalewski" <mikolajz(a)google.com> writes: > @@ -1600,6 +1603,16 @@ #endif > for(; y >= y2; y--) { > memcpy(dstbits, (char *)dib.dsBm.bmBits + y * dib.dsBm.bmWidthBytes + xSrc * 4, > widthSrc * 4); > + if (!(blendfn.AlphaFormat & AC_SRC_ALPHA)) > + { > + int i; > + RGBQUAD *quad = (RGBQUAD *)dstbits; > + for (i = 0; i < widthSrc; i++) > + { > + quad->rgbReserved = blendfn.SourceConstantAlpha; > + quad++; > + } > + } It would be nicer to have a separate loop for that case, and do everything in one go instead of patching up the values after the copy. Also RGBQUAD is meant for color tables, it's not an appropriate type for the bitmap data itself. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: user32: static controls should have a clipping region set while sending the WM_CTLCOLORSTATIC (3rd try, with testcase, fixes bug #9195)
by Alexandre Julliard Aug. 29, 2007

Aug. 29, 2007

"Mikolaj Zalewski" <mikolajz(a)google.com> writes: > Is there something wrong with this patch? You should use IntersectClipRect or ExtSelectClipRgn to avoid intermediate copies. Also GetClipRgn doesn't return a region code so checking it against NULLREGION is wrong. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: patch for sysparam.c
by Paul Vriens Aug. 29, 2007

Aug. 29, 2007

Ivan Sinitsin wrote: > This patch adds an opportunity for fonts of the menu, statusbar and messages > to increase depending on logpixels. > > > Changelog: > This patch does a font for the menu,statusbar and messages dependent from > logpixels. > > > ------------------------------------------------------------------------ > > With the latest release winecfg can set this value. The default there is 96 and the range is 96..120. How does that relate to the 72 in your code? : +if (!RegQueryValueExW( myhKey, log_pixels, NULL, &type, + (LPBYTE) &logpixels, &size )==ERROR_SUCCESS) + logpixels=72; Cheers, Paul.

1 0

Re: patch for sysparam.c
by Robert Shearman Aug. 29, 2007

Aug. 29, 2007

Ivan Sinitsin wrote: > This patch adds an opportunity for fonts of the menu, statusbar and messages > to increase depending on logpixels. > > > +size=sizeof(DWORD); > +RegOpenKeyExW( HKEY_LOCAL_MACHINE, registry_key, > + 0, KEY_QUERY_VALUE, &myhKey ); > +if (!RegQueryValueExW( myhKey, log_pixels, NULL, &type, > + (LPBYTE) &logpixels, &size )==ERROR_SUCCESS) > + logpixels=72; > +ncm.lfMenuFont.lfHeight=-MulDiv(ncm.lfMenuFont.lfHeight,logpixels,72); > +RegCloseKey( myhKey ); You're missing some indentation here. -- Rob Shearman

1 0

Re: [PATCH] Support for animated cursors
by H. Verbeet Aug. 28, 2007

Aug. 28, 2007

On 28/08/07, Trent Waddington <trent.waddington(a)gmail.com> wrote: > On 8/28/07, H. Verbeet <hverbeet(a)gmail.com> wrote: > > You should use the timing and frame sequence info from the .ani. > > Also, Xcursor actually supports proper animated cursors, so it would > > be better to handle the animation in winex11.drv > > Can you please direct me to some example code of defining and using an > animated cursor with Xcursor? > http://repo.or.cz/w/wine/hacks.git?a=blob;f=dlls/winex11.drv/mouse.c;h=b344… should be a decent start. > > As explained in the comment at the top of cursoricon.c, you can't do > > that, because it will break win16 applications. > > Umm.. what comment would that be? This one: > * Cursors and icons are stored in a global heap block, with the > * following layout: > * > * CURSORICONINFO info; > * BYTE[] ANDbits; > * BYTE[] XORbits; > * > * The bits structures are in the format of a device-dependent bitmap. > * > * This layout is very sub-optimal, as the bitmap bits are stored in > * the X client instead of in the server like other bitmaps; however, > * some programs (notably Paint Brush) expect to be able to manipulate > * the bits directly :-( > Should I replace hNext with a CURSORICONINFO *? This is what I had > initially.. or should I be using something else? Or should I just > make it an BYTE bFrames and append multiple data blocks to the end of > the CURSORICONINFO struct? > Well, what it comes down to is that you can't change the cursor memory layout for win16 applications at all, which complicates things a bit.

3 12

[PATCH] the function called is cdecl, not WINAPI
by Juan Lang Aug. 28, 2007

Aug. 28, 2007

Hi Marcus, > the function called is cdecl, not WINAPI No it isn't. It's declared that way, but it's wrong. Calling it that way in Windows crashes. That's why I sent this patch: http://www.winehq.org/pipermail/wine-cvs/2007-August/035682.html --Juan

2 2

Re: winex11.drv: test for out-of-bound src coordinates in GdiAlphaBlend (fixed, with testcase, fixes bug #7428)
by Alexandre Julliard Aug. 28, 2007

Aug. 28, 2007

"Mikolaj Zalewski" <mikolajz(a)google.com> writes: > The previous version didn't take into account that dib.dsBmih.biHeight > can be negative. You should check for negative widthSrc/heightSrc too. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: msvcrt: tests: some values of _mbctype are dependent on the version of Windows
by Alexandre Julliard Aug. 28, 2007

Aug. 28, 2007

"Mikolaj Zalewski" <mikolajz(a)google.com> writes: > @@ -144,10 +144,18 @@ static int result_cp_949_mbctype[] = { 0 > static int result_cp_950_mbctype[] = { 0x0,65, 0x8,1, 0x18,26, 0x8,6, 0x28,26, 0x8,4, > 0x0,2, 0x4,32, 0xc,94, 0,1 }; > > +/* these characters may differ on different Windows versions */ > +static int fuzzy_cp_1252_mbctype[] = {142, 158, 170, 181, 186, -2}; > +static int fuzzy_cp_1250_mbctype[] = {131, 141, 142, 143, 157, 158, 159, 163, 165, 170, 175, 179, 181, 185, 186, 188, 190, 191, -2}; > +static int fuzzy_cp_932_mbctype[] = { -2 }; > +static int fuzzy_cp_936_mbctype[] = { -2 }; > +static int fuzzy_cp_949_mbctype[] = { -2 }; > +static int fuzzy_cp_950_mbctype[] = { -2 }; What this shows is that the exact values don't matter, and that apps are very unlikely to depend on them. This also means that having slightly different tables in Wine is not a problem, so I'd suggest to not try to test every single char, but just pick a few that are the same on all platforms. -- Alexandre Julliard julliard(a)winehq.org

1 0