re: thanks for wine
Copy-paste didn't work between wine and Gnome, but everything else was without a hitch!
Doh! What exactly failed? Could you give me the exact steps to reproduce the problem?
Yes, please do! Let's get a bug filed about this. There are quite a few copy and paste bugs in Wine, e.g. http://bugs.winehq.org/show_bug.cgi?id=633 http://bugs.winehq.org/show_bug.cgi?id=2382 http://bugs.winehq.org/show_bug.cgi?id=3486 http://bugs.winehq.org/show_bug.cgi?id=4523 http://bugs.winehq.org/show_bug.cgi?id=5061 I wonder if just getting copy and paste working well would be a sufficient summer of code project! Too bad submissions are closed. Ah, well, next year :-) - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
On 5/11/06, Dan Kegel <dank(a)kegel.com> wrote:
Copy-paste didn't work between wine and Gnome, but everything else was without a hitch!
Doh! What exactly failed? Could you give me the exact steps to reproduce the problem?
Yes, please do! Let's get a bug filed about this.
There are quite a few copy and paste bugs in Wine, e.g. http://bugs.winehq.org/show_bug.cgi?id=633 http://bugs.winehq.org/show_bug.cgi?id=2382 http://bugs.winehq.org/show_bug.cgi?id=3486 http://bugs.winehq.org/show_bug.cgi?id=4523 http://bugs.winehq.org/show_bug.cgi?id=5061
I wonder if just getting copy and paste working well would be a sufficient summer of code project! Too bad submissions are closed. Ah, well, next year :-)
Good idea.. And then we can rewrite the keyboard code for SoC 2008! The clipboard is quite a bit tricky and AJ I think would be as picky about this as the opengl fixes and WM fixes that go in. Although I would still like to see the keyboard code get fixed soon, I don't think it is going to happen. Of course, I am starting school again this fall (changed majors so I need to start all over), so perhaps this time I can take some programming classes, and by the time that SoC 2008 rolls around I should be familiar enough to be able to understand the things that Peter Astrand was talking about before, and possibly code it myself. Tom
There may be an odd bug here and there but copy and paste should be working just fine between most applications. At least the X11 driver code should be working correctly. The only major issues that I'm aware of are coping and pasting OLE embedded objects. That should be taken care of when Rob is finished his COM work. IMO 633, 2382 and 5061 are not really copy and paste bugs. They are caused by problems translating from windows data formats to linux data formats and vice versa. 3486 is an edit control bug and not a general copy and paste bug. 4523 looks like an OLE bug. Have you tried with native ole32? This bug also suffers from the fact that we don't get notifications when an X app changes its selection. The XFixes extension should help. I've starting looking into this but just haven't found the time to finish it. /Ulrich On Thu, May 11, 2006 at 02:09:41PM -0700, Dan Kegel wrote:
Copy-paste didn't work between wine and Gnome, but everything else was without a hitch!
Doh! What exactly failed? Could you give me the exact steps to reproduce the problem?
Yes, please do! Let's get a bug filed about this.
There are quite a few copy and paste bugs in Wine, e.g. http://bugs.winehq.org/show_bug.cgi?id=633 http://bugs.winehq.org/show_bug.cgi?id=2382 http://bugs.winehq.org/show_bug.cgi?id=3486 http://bugs.winehq.org/show_bug.cgi?id=4523 http://bugs.winehq.org/show_bug.cgi?id=5061
I wonder if just getting copy and paste working well would be a sufficient summer of code project! Too bad submissions are closed. Ah, well, next year :-) - Dan
-- Wine for Windows ISVs: http://kegel.com/wine/isv
The only major issues that I'm aware of are coping and pasting OLE embedded objects. That should be taken care of when Rob is finished his COM work.
IMO 633, 2382 and 5061 are not really copy and paste bugs. They are caused by problems translating from windows data formats to linux data formats and vice versa.
As far as I know, all "complex" objects in the windows clipboard, such as formatted text, images etc. is stored as rtf-object. BTW: There is also a bug #3611 which was marked as dublicate of #633 but its not the exact reason. I recognized that the copy and paste bug #3611 works on some systems. I may have to do with some X11 library/KDE Lib versions. etc. Is there a kind of WINEDEBUG option to track what happens when copy/paste in application? On the other side I saw a lot of applications by which the copy/paste does not work. It seems to be a much bigger issue than assumed. Roland Kaeser
Von: Ulrich Czekalla <ulrich.czekalla(a)utoronto.ca> An: Dan Kegel <dank(a)kegel.com> CC: wine-devel <wine-devel(a)winehq.org>; marius.andreiana(a)gmail.com Gesendet: Freitag, den 12. Mai 2006, 00:47:01 Uhr Betreff: Re: thanks for wine
There may be an odd bug here and there but copy and paste should be working just fine between most applications. At least the X11 driver code should be working correctly.
The only major issues that I'm aware of are coping and pasting OLE embedded objects. That should be taken care of when Rob is finished his COM work.
IMO 633, 2382 and 5061 are not really copy and paste bugs. They are caused by problems translating from windows data formats to linux data formats and vice versa.
3486 is an edit control bug and not a general copy and paste bug.
4523 looks like an OLE bug. Have you tried with native ole32? This bug also suffers from the fact that we don't get notifications when an X app changes its selection. The XFixes extension should help. I've starting looking into this but just haven't found the time to finish it.
/Ulrich
On Thu, May 11, 2006 at 02:09:41PM -0700, Dan Kegel wrote:
Copy-paste didn't work between wine and Gnome, but everything else was without a hitch!
Doh! What exactly failed? Could you give me the exact steps to reproduce the problem?
Yes, please do! Let's get a bug filed about this.
There are quite a few copy and paste bugs in Wine, e.g. http://bugs.winehq.org/show_bug.cgi?id=633 http://bugs.winehq.org/show_bug.cgi?id=2382 http://bugs.winehq.org/show_bug.cgi?id=3486 http://bugs.winehq.org/show_bug.cgi?id=4523 http://bugs.winehq.org/show_bug.cgi?id=5061
I wonder if just getting copy and paste working well would be a sufficient summer of code project! Too bad submissions are closed. Ah, well, next year :-) - Dan
-- Wine for Windows ISVs: http://kegel.com/wine/isv
On Fri, May 12, 2006 at 06:20:13AM +0000, Roland Kaeser wrote:
The only major issues that I'm aware of are coping and pasting OLE embedded objects. That should be taken care of when Rob is finished his COM work.
IMO 633, 2382 and 5061 are not really copy and paste bugs. They are caused by problems translating from windows data formats to linux data formats and vice versa.
As far as I know, all "complex" objects in the windows clipboard, such as formatted text, images etc. is stored as rtf-object. BTW: There is also a bug #3611 which was marked as dublicate of #633 but its not the exact reason.
I recognized that the copy and paste bug #3611 works on some systems. I may have to do with some X11 library/KDE Lib versions. etc. Is there a kind of WINEDEBUG option to track what happens when copy/paste in application? On the other side I saw a lot of applications by which the copy/paste does not work. It seems to be a much bigger issue than assumed.
I agree, they are different bugs. I don't have Corel Draw 9 so if you can send me a +relay,+clipboard,+tid trace I can take a look. /Ulrich
Wine's clipboard implementation is a bit of a mistery to a lot of people :) Ulrich, it would be really great if you can spare a few minutes and do a bit of a write up on it (no matter how small initially) on the wiki: http://wiki.winehq.org/CopyAndPaste I'm sure it would help lots of people understand it better, and it will also provide a place for others to contribute. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.
Yes good idea. Things are a bit hectic around here but I'll try to do that in the next couple of days. /Ulrich On Fri, May 12, 2006 at 09:22:49AM -0400, Dimi Paun wrote:
Wine's clipboard implementation is a bit of a mistery to a lot of people :)
Ulrich, it would be really great if you can spare a few minutes and do a bit of a write up on it (no matter how small initially) on the wiki: http://wiki.winehq.org/CopyAndPaste
I'm sure it would help lots of people understand it better, and it will also provide a place for others to contribute.
-- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.
On 5/12/06, Roland Kaeser <roli8200(a)yahoo.de> wrote:
The only major issues that I'm aware of are coping and pasting OLE embedded objects. That should be taken care of when Rob is finished his COM work.
IMO 633, 2382 and 5061 are not really copy and paste bugs. They are caused by problems translating from windows data formats to linux data formats and vice versa.
As far as I know, all "complex" objects in the windows clipboard, such as formatted text, images etc. is stored as rtf-object. BTW: There is also a bug #3611 which was marked as dublicate of #633 but its not the exact reason.
I recognized that the copy and paste bug #3611 works on some systems. I may have to do with some X11 library/KDE Lib versions. etc. Is there a kind of WINEDEBUG option to track what happens when copy/paste in application?
+clipboard
Now that you brought it up, clipboard in wine does have some limitations. e.g. when a process calls OpenClipboard(hwnd), Windows doesn't seem to care if the hwnd is owned by a thread of the calling process. A process doesn't even have to have a window in order to grab the clipboard and put something on it. It can just use the desktop window. Not so with wine. Although I never fully understood the inner working of Wine's clipboard implementation, I did try messing with it to see if I could overcome the limitation - with very limited success:-) --- Dan Kegel <dank(a)kegel.com> wrote:
Copy-paste didn't work between wine and Gnome, but everything else was without a hitch!
Doh! What exactly failed? Could you give me the exact steps to reproduce the problem?
Yes, please do! Let's get a bug filed about this.
There are quite a few copy and paste bugs in Wine, e.g. http://bugs.winehq.org/show_bug.cgi?id=633 http://bugs.winehq.org/show_bug.cgi?id=2382 http://bugs.winehq.org/show_bug.cgi?id=3486 http://bugs.winehq.org/show_bug.cgi?id=4523 http://bugs.winehq.org/show_bug.cgi?id=5061
I wonder if just getting copy and paste working well would be a sufficient summer of code project! Too bad submissions are closed. Ah, well, next year :-) - Dan
-- Wine for Windows ISVs: http://kegel.com/wine/isv
__________________________________________________ 赶快注册雅虎超大容量免费邮箱? http://cn.mail.yahoo.com
"qingdoa daoo" <qingdao33122(a)yahoo.com> wrote:
Although I never fully understood the inner working of Wine's clipboard implementation, I did try messing with it to see if I could overcome the limitation - with very limited success:-)
Perhaps then you could add the tests showing what's wrong with current implementation to dlls/user/tests/clipboard.c? -- Dmitry.
On Fri, May 12, 2006 at 04:16:28PM +0800, qingdoa daoo wrote:
Now that you brought it up, clipboard in wine does have some limitations. e.g. when a process calls OpenClipboard(hwnd), Windows doesn't seem to care if the hwnd is owned by a thread of the calling process. A process doesn't even have to have a window in order to grab the clipboard and put something on it. It can just use the desktop window. Not so with wine.
This should work in wine as well. Do you have a test case? /Ulrich
A simple test ----------------------------- #include "windows.h" int APIENTRY WinMain(HINSTANCE inst, HINSTANCE prev, LPSTR cmd, int show) { HGLOBAL hmem; LPSTR lpstr; OpenClipboard(GetDesktopWindow()); EmptyClipboard(); hmem = GlobalAlloc(GMEM_MOVEABLE, 6); lpstr = GlobalLock(hmem); lstrcpy(lpstr, "Hello"); GlobalUnlock(hmem); SetClipboardData(CF_TEXT, hmem); CloseClipboard(); return 0; } --- Ulrich Czekalla <ulrich.czekalla(a)utoronto.ca>写道:
On Fri, May 12, 2006 at 04:16:28PM +0800, qingdoa daoo wrote:
Now that you brought it up, clipboard in wine does have some limitations. e.g. when a process calls OpenClipboard(hwnd), Windows doesn't seem to care if the hwnd is owned by a thread of the calling process. A process doesn't even have to have a window in order to grab the clipboard and put something on it. It can just use the desktop window. Not so with wine.
This should work in wine as well. Do you have a test case?
/Ulrich
___________________________________________________________ 抢注雅虎免费邮箱-3.5G容量，20M附件！ http://cn.mail.yahoo.com
It just occurred to me that we don't need a new test case. Current tests don't pass on my box either. Although the result line shows 0 failure. there are error messages during the test. [root(a)localhost wine-0.9.12]# tools/runtest -p dlls/user/tests/user32_test.exe.so dlls/user/tests/clipboard.c clipboard.c:162:# of formats available: 0 err:clipboard:X11DRV_AcquireClipboard Failed to acquire selection clipboard.c:49:hWnd1 = 0x10024 clipboard.c:54:hWnd2 = 0x10026 err:clipboard:CLIPBOARD_CloseClipboard Failed to set clipboard. dlls/user/tests/clipboard.c: 35 tests executed, 2 marked as todo, 0 failures. --- qingdoa daoo <qingdao33122(a)yahoo.com>写道:
A simple test ----------------------------- ...
--- Ulrich Czekalla <ulrich.czekalla(a)utoronto.ca>写道:
This should work in wine as well. Do you have a test case?
/Ulrich
__________________________________________________ 赶快注册雅虎超大容量免费邮箱? http://cn.mail.yahoo.com
On Sat, 13 May 2006 06:57:22 +0800, qingdoa daoo wrote:
It just occurred to me that we don't need a new test case. Current tests don't pass on my box either. Although the result line shows 0 failure. there are error messages during the test.
That doesn't imply a problem, lots of our test cases make Wine spit out errors (as we test error paths too!). thanks -mike
Yes this case is problematic. Now that the desktop window is owned by the explorer process OpenClipboard(GetDesktopWindow()) won't work. The selection owner will become the explorer process but the data will live in the current process. The result will be that no data will be available to external processes. The code currently depends on the window belonging to the current process. Removing this requirement may require moving the clipboard data to the wineserver. I have to think about this some more. Either way I'm not sure this case is that important. One limitation is that we must have a message loop running to handle the X selection events otherwise other processes won't have access to our clipboard data. So even if I fix the issue with the wrong process becoming the selection owner your simple app won't work :-( I don't think it's a major concern though because most windows app have a message loop. /Ulrich On Sat, May 13, 2006 at 06:24:13AM +0800, qingdoa daoo wrote:
A simple test -----------------------------
#include "windows.h"
int APIENTRY WinMain(HINSTANCE inst, HINSTANCE prev, LPSTR cmd, int show)
{
HGLOBAL hmem;
LPSTR lpstr;
OpenClipboard(GetDesktopWindow());
EmptyClipboard();
hmem = GlobalAlloc(GMEM_MOVEABLE, 6);
lpstr = GlobalLock(hmem);
lstrcpy(lpstr, "Hello");
GlobalUnlock(hmem);
SetClipboardData(CF_TEXT, hmem);
CloseClipboard();
return 0;
}
--- Ulrich Czekalla <ulrich.czekalla(a)utoronto.ca>????:
On Fri, May 12, 2006 at 04:16:28PM +0800, qingdoa daoo wrote:
Now that you brought it up, clipboard in wine does have some limitations. e.g. when a process calls OpenClipboard(hwnd), Windows doesn't seem to care if the hwnd is owned by a thread of the calling process. A process doesn't even have to have a window in order to grab the clipboard and put something on it. It can just use the desktop window. Not so with wine.
This should work in wine as well. Do you have a test case?
/Ulrich
___________________________________________________________ ????????????????-3.5G??????20M?????? http://cn.mail.yahoo.com
How about doing something in explorer. We already launch an instance of explorer as systray listener for the first Win32 app. We could make explorer also act as a clipboard server. If that can be done, we no longer rely on any message loop in the process doing clipboard operations. This case *is* important. for example I believe this is why copy/paste doesn't work in MSVC6 under wine. We can also make more improvements on the clipboard implementation once the new framework is done. --- Ulrich Czekalla <ulrich.czekalla(a)utoronto.ca> wrote:
Yes this case is problematic.
Now that the desktop window is owned by the explorer process OpenClipboard(GetDesktopWindow()) won't work. The selection owner will become the explorer process but the data will live in the current process. The result will be that no data will be available to external processes. The code currently depends on the window belonging to the current process. Removing this requirement may require moving the clipboard data to the wineserver. I have to think about this some more. Either way I'm not sure this case is that important.
One limitation is that we must have a message loop running to handle the X selection events otherwise other processes won't have access to our clipboard data. So even if I fix the issue with the wrong process becoming the selection owner your simple app won't work :-( I don't think it's a major concern though because most windows app have a message loop.
/Ulrich
___________________________________________________________ 抢注雅虎免费邮箱-3.5G容量，20M附件！ http://cn.mail.yahoo.com
participants (8)
-
Dan Kegel -
Dimi Paun -
Dmitry Timoshkov -
Mike Hearn -
qingdoa daoo -
Roland Kaeser -
Tom Spear -
Ulrich Czekalla