re: thanks for wine

[Dan Kegel]

> > 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

thanks for wine

[Tom Spear]

On 5/11/06, 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 :-)

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

thanks for wine

[Ulrich Czekalla]

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

AW: thanks for wine

[Roland Kaeser]

> 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 
> An: Dan Kegel 
> CC: wine-devel ; [e-mail]
> 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

thanks for wine

[Ulrich Czekalla]

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

thanks for wine

[Dimi Paun]

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.

thanks for wine

[Ulrich Czekalla]

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 
> Lattica, Inc.

thanks for wine

[Tom Spear]

On 5/12/06, 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?

+clipboard

thanks for wine

[qingdoa daoo]

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  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

thanks for wine

[Dmitry Timoshkov]

"qingdoa daoo"  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?

thanks for wine

[Ulrich Czekalla]

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

thanks for wine

[qingdoa daoo]

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 写道:
> 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

thanks for wine

[qingdoa daoo]

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@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 写道:
> A simple test

...
> --- Ulrich Czekalla 写道:
> > This should work in wine as well. Do you have a test case?
> >
> > /Ulrich

__________________________________________________
赶快注册雅虎超大容量免费邮箱?
http://cn.mail.yahoo.com

thanks for wine

[Mike Hearn]

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

thanks for wine

[Ulrich Czekalla]

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 ????:
> > 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

thanks for wine

[qingdoa daoo]

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  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