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

Re: [try 3] systray patches
by Kirill K. Smirnov Jan. 9, 2007

Jan. 9, 2007

> > Or I miss something really important? If so, just provide a use-case, > > please!! > > Well, for instance if the parent is a Wine window, which would be the > case when someone implements systray handling in desktop mode, it > would break since Wine windows are not painted with the background > pixmap. This case assumes absolutely other mechanism of embedding, not XEMBED. _Wine_ cannot be XEMBED-master for _wine_ application. (May it? Reasons?) My patches are to fix annoying background situation caused by _XEMBED_ usage. Only for xembed. Other way (as you supposed, native wine's tray in desktop mode) may be implemented (interesting idea, I though about it, but is there anybody who needs this?). Then XEMBED and the new mechanism MUST be mutually excluse. So, my patch does not hurt anything. > Anyway, I'm not necessarily opposed to doing pseudo-transparency, if > you can find a way to do it cleanly, i.e. without adding special cases > for systray windows all over the place. Heh, I intend to add cases as less as possible! BUT! For any "output-only-transparency, not input" mechanism for XEMBED I choose, I have to play around with background pixmap. When application changes icon, the window background must be repainted to remove previous junk. As you say, Wine windows are not painted with the background pixmap (I do not know details), so we must do it explicitly by calling XClearWindow. This is reason for at least one special case handling. And I add one special case in SetWindowIcon(a)winex11.drv/window.c!!! Other case I added in user32/defwnd.c looks like hack. You were right - I should investigate SetWindowPos problem. -- Kirill

1 0

Re: [try 3] systray patches
by Kirill K. Smirnov Jan. 9, 2007

Jan. 9, 2007

> It's not transparent, Hm... Yes, it is not transparent. It is pseudo-transparent. Just for us. > it's painted with what you hope is the same > background as the parent, but there's no guarantee of that. Xlib thinks opposite. The window will be painted with the same background as the parent (not a copy of parent pixmap, but the same pixmap). It will be even correctly tiled to provide 'pseudo-transparency'! Xlib programming manual guarentee that: http://www.cptec.inpe.br/sx4/sx4man2/g1ae02e/chap3.html chapter 3.2.1. The main ideas I based upon: 1) the parent window does not paint anything under our window. If there will be smth, then pseudo-transparency will be broken. 2) Any sane systray implementation satisfies 1). 3) KDE/fluxbox/other systrays are sane. The link: http://www.nabble.com/-Gaim-gtk-bugs----gaim-gtk-bugs-1370422---Tray-icon-n… provides some information (KDE): [quote] "The code of those applications needs to be changed to perform XSetWindowBackgroundPixmap( dpy, window, ParentRelative ) on the X window that is used as the systray icon. There's nothing KDE can do about this, you need to ask the app developers to support this fake transparency." [/quote] Or I miss something really important? If so, just provide a use-case, please!! -- Kirill

2 1

Re: [try 3] systray patches + SetWindowPos in WM_SETICON
by Kirill K. Smirnov Jan. 9, 2007

Jan. 9, 2007

> "Kirill K. Smirnov" <lich(a)math.spbu.ru> writes: > > Please, explain me, what is wrong with this serie of patches? > > What to do to improve them? > > As I said, making the background pixmap ParentRelative is just a hack, > it's not real transparency. Why is it not a real transparency? This is the easiest way to provide only output transparency, not input. Exactly what we need. > You don't know how the parent will paint > itself, so you can't rely on that. wine doesn't know that, but does not need to know too. That's why I use ParentRelative, because when I change KDE (e.g.) panel background it is handled correct. > Also, your patch adds special > handling for the tray window in user32, that's a violation of the > driver abstraction. Hm... The core problem here is to notify WM systray to be repainted when wine changes icon. To achieve this, I call XClearWindow in setwindowicon(a)winex11.drv/window.c. This is ideological correct (IMO) - perform X operation in setwindowicon function when application changes icon. But!!! defwndproc(a)user32.defwnd calls SetWindowPos. This breaks everything concerning wine tray. Tray window should not be reposed. It is done once (while docking) and forever. So, my patch for user32 is a 'bugfix' for a 'bug' caused by wine systray embedding idea. Maybe, there is other way to achieve this, but I cannot imagine. Any ideas? -- Kirill

2 1

Re: add tests to odbccp32
by Alexandre Julliard Jan. 9, 2007

Jan. 9, 2007

Bill Medland <billmedland(a)shaw.ca> writes: > + /* MSDN states that the error number should be between 1 and 8. Passing 0 is an error */ > + sql_ret = SQLInstallerError(0, NULL, NULL, 0, NULL); > + todo_wine(sql_ret == SQL_ERROR, "SQLInstallerError(0...) failed with %d instead of SQL_ERROR\n", sql_ret); That's not how todo_wine is used, this won't do anything useful. -- Alexandre Julliard julliard(a)winehq.org

1 0

Humus Water demo vs FBOs
by Ivan Gyurdiev Jan. 9, 2007

Jan. 9, 2007

Here's a demo that breaks FBOs: http://www.humus.ca/3D/Water.zip Also download: http://www.humus.ca/3D/Framework2.zip You'll notice all the glClear calls fail [ or at least a lot of them ]. That's because the framebuffer is incomplete at that point - checkFBOstatus() should be called before glClear, as well as drawprim to see that this is FRAMEBUFFER_INCOMPLETE_DIMENSIONS_EXT (0x8cd9). I think the call that fails is the clear call in the drawFrame() function of the app - the others set a 0 depth stencil buffer immediately prior, while this one is probably using wined3d's initial depth fbo. I think the Framework sets EnableAutoDepthStencil, so that an fbo is created. It probably ends up being a different size from the color fbo, which breaks a framebuffer completeness requirement.

2 1

memory corruption in dlls/oleaut32/olepicture.c?
by Damjan Jovanovic Jan. 9, 2007

Jan. 9, 2007

Hi In dlls/oleaut32/olepicture.c, there are several places where memory is allocated and then used immediately, without checking whether allocation succeeded. For example: 1479 xbuf = HeapAlloc (GetProcessHeap(), HEAP_ZERO_MEMORY, origsize); 1480 if (headerisdata) 1481 memcpy (xbuf, &header, 8); Is there something I'm missing, or does that sort of code lead to memory corruption / segmentation faults when allocating memory fails? >From what I see on http://people.redhat.com/mstefani/wine/smatch/bugs_all.html, smatch doesn't detect this as an error. What should we do? Damjan

2 1

RawInput
by Michał Majchrowicz Jan. 9, 2007

Jan. 9, 2007

Hi. I am trying to write functions for RawInput in wine. If understand correctly GetRawInputDeviceList function gives us an array of rawinputdevice's registered with function RegisterRawInputDevices. So implementing it would be just geting and setting data in array. But I have two question: 1) Where should i put this array? In which file? 2) How can I get data to fill the begining of the array (according to my tests when Windows has only mouse and keyboard connected there are 4 input devices) Regards Michael.

2 1

Re: Proposed patch for "fonts.c"
by Marcus Meissner Jan. 9, 2007

Jan. 9, 2007

On Mon, Jan 08, 2007 at 11:49:49PM +0100, Bernard Choppy wrote: > Good day, > > online(a)noteworthysoftware.com sent a patch covering bug 7040 I've initiated. > > The problem is that wine doesn't handle properly Symbol-encoded fonts, > which makes rendering of special fonts (in this case, music notation for > the NoteWorthy version 2 softwares) inaccurate. > > I suppose he will sent this patch too, but to make sure, please find it > here. > > 352c352 > < static LPWSTR FONT_mbtowc(LPCSTR str, INT count, INT *plenW) > --- > > static LPWSTR FONT_mbtowc(HDC hdc, LPCSTR str, INT count, INT *plenW) Please use "diff -u". Ciao, Marcus

1 0

Re: appdb/ ./account.php ./addcomment.php ./appbro ...
by Tony Lambregts Jan. 9, 2007

Jan. 9, 2007

WineHQ wrote: > ChangeSet ID: 30851 > CVSROOT: /opt/cvs-commit > Module name: appdb > Changes by: wineowner(a)winehq.org 2007/01/03 20:35:02 > > Modified files: > . : account.php addcomment.php appbrowse.php > appimage.php appsubmit.php appview.php > browse_by_rating.php browse_newest_apps.php > commentview.php deletecomment.php > distributionView.php maintainerdelete.php > maintainersubmit.php preferences.php > screenshots.php search.php testResults.php > vendorview.php viewScreenshots.php viewbugs.php > votestats.php > admin : addAppNote.php addCategory.php > adminAppDataQueue.php adminAppQueue.php > adminBugs.php adminCommentView.php > adminMaintainerQueue.php adminMaintainers.php > adminScreenshots.php adminTestResults.php > adminUsers.php deleteAny.php editAppFamily.php > editAppNote.php editAppVersion.php > editBundle.php editDistribution.php > editVendor.php moveAppVersion.php > help : index.php > include : application.php bugs.php comment.php > distribution.php filter.php form_edit.php > form_login.php form_new.php incl.php note.php > screenshot.php sidebar.php testData.php url.php > util.php version.php vote.php > > Log message: > Chris Morgan <cmorgan(a)alum.wpi.edu> > Fix and enable input filtering through include/filter.php > > Patch: http://cvs.winehq.org/patch.py?id=30851 > > Old revision New revision Changes Path > 1.34 1.35 +0 -1 appdb/account.php > 1.33 1.34 +0 -1 appdb/addcomment.php > 1.22 1.23 +0 -1 appdb/appbrowse.php > 1.28 1.29 +0 -1 appdb/appimage.php > 1.57 1.58 +6 -20 appdb/appsubmit.php > 1.96 1.97 +0 -8 appdb/appview.php > 1.1 1.2 +0 -1 appdb/browse_by_rating.php > 1.2 1.3 +0 -1 appdb/browse_newest_apps.php > 1.15 1.16 +0 -1 appdb/commentview.php > 1.30 1.31 +0 -1 appdb/deletecomment.php > 1.22 1.23 +0 -1 appdb/distributionView.php > 1.24 1.25 +0 -7 appdb/maintainerdelete.php > 1.33 1.34 +0 -7 appdb/maintainersubmit.php > 1.33 1.34 +3 -25 appdb/preferences.php > 1.41 1.42 +0 -1 appdb/screenshots.php > 1.21 1.22 +0 -1 appdb/search.php > 1.22 1.23 +2 -10 appdb/testResults.php > 1.23 1.24 +0 -1 appdb/vendorview.php > 1.7 1.8 +0 -1 appdb/viewScreenshots.php > 1.10 1.11 +0 -1 appdb/viewbugs.php > 1.27 1.28 +0 -1 appdb/votestats.php > 1.30 1.31 +1 -8 appdb/admin/addAppNote.php > 1.15 1.16 +0 -8 appdb/admin/addCategory.php > 1.30 1.31 +0 -9 appdb/admin/adminAppDataQueue.php > 1.69 1.70 +6 -21 appdb/admin/adminAppQueue.php > 1.14 1.15 +0 -9 appdb/admin/adminBugs.php > 1.16 1.17 +0 -5 appdb/admin/adminCommentView.php > 1.35 1.36 +0 -8 appdb/admin/adminMaintainerQueue.php > 1.28 1.29 +0 -5 appdb/admin/adminMaintainers.php > 1.16 1.17 +0 -9 appdb/admin/adminScreenshots.php > 1.17 1.18 +1 -6 appdb/admin/adminTestResults.php > 1.13 1.14 +0 -9 appdb/admin/adminUsers.php > 1.22 1.23 +0 -8 appdb/admin/deleteAny.php > 1.43 1.44 +0 -5 appdb/admin/editAppFamily.php > 1.29 1.30 +2 -9 appdb/admin/editAppNote.php > 1.41 1.42 +0 -6 appdb/admin/editAppVersion.php > 1.15 1.16 +10 -10 appdb/admin/editBundle.php > 1.11 1.12 +1 -7 appdb/admin/editDistribution.php > 1.15 1.16 +0 -6 appdb/admin/editVendor.php > 1.11 1.12 +0 -6 appdb/admin/moveAppVersion.php > 1.10 1.11 +5 -5 appdb/help/index.php > 1.82 1.83 +5 -11 appdb/include/application.php > 1.19 1.20 +4 -6 appdb/include/bugs.php > 1.31 1.32 +1 -4 appdb/include/comment.php > 1.3 1.4 +2 -6 appdb/include/distribution.php > 1.8 1.9 +13 -8 appdb/include/filter.php > 1.10 1.11 +0 -3 appdb/include/form_edit.php > 1.8 1.9 +0 -4 appdb/include/form_login.php > 1.10 1.11 +0 -6 appdb/include/form_new.php > 1.38 1.39 +8 -1 appdb/include/incl.php > 1.20 1.21 +1 -7 appdb/include/note.php > 1.53 1.54 +1 -3 appdb/include/screenshot.php > 1.24 1.25 +3 -5 appdb/include/sidebar.php > 1.15 1.16 +6 -12 appdb/include/testData.php > 1.10 1.11 +2 -6 appdb/include/url.php > 1.77 1.78 +40 -38 appdb/include/util.php > 1.90 1.91 +5 -9 appdb/include/version.php > 1.23 1.24 +1 -5 appdb/include/vote.php > > This patch breaks xinha editing... -- Tony Lambregts

3 4

Re: comctl32: Rewrite the up-down control tests to add message checking
by Dmitry Timoshkov Jan. 9, 2007

Jan. 9, 2007

"James Hawkins" <truiken(a)gmail.com> wrote: > + if ((expected->flags & defwinproc) != (actual->flags & defwinproc) && todo) > + { > + todo_wine > + { > + failcount++; > + ok_(file, line) (FALSE, > + "%s: in msg 0x%04x expecting lParam 0x%lx got 0x%lx\n", > + context, expected->message, expected->lParam, actual->lParam); > + } > + } This is an old typo/misleading message that I've fixed in the original msg.c code. -- Dmitry.

1 0