Dear Dmitry,
Dmitry Timoshkov wrote:
"Timothy Lee" timothy.lee@siriushk.com wrote:
I'm struggling to imagine a case where the behaviour you've implemented is useful.
I'm actually using this code as the basis of a PowerPoint plugin under Linux.
I little bit more information won't hurt. For instance why your plugin needs to re-route the whole desktop window, and not just its own one.
The patch was used in a browser plugin that uses PowerPoint Viewer (97/2003/2007) and WINE to display PowerPoint slideshows.
It's still now clear to me what kind of plugin it is, and what it is doing. You call it once "a PowerPoint plugin", and next time "a browser plugin".
It's a PowerPoint plugin for Mozilla-based browsers, which can be used to embed a PowerPoint slideshow inside a web page. So yes, both references were valid (though, as you have indicated, no crystal clear).
While developing the plugin, I've found that PowerPoint Viewer always playback slides inside a window that covers the whole desktop. Hence the idea was born to embed the desktop inside a native X11 window.
An application plugin usually has access to the application internals in some fashion, so I don't understand how that idea jumped from an application window (where the plugin lives) to the whole desktop window (a separate process).
No, I don't have the "internal" of the PowerPoint Viewer, as it's written by Microsoft. However, the plugin code does know about the X11 window supplied by the browser for embedding purpose, and this is passed via the newly defined environmental variable to Wine.
I thought this patch might be useful to others with similar requirements, namely, to embed full-screen win32 applications inside a native X11 window.
That kind of hack has nothing to do with Wine desktop window if what it targets is just an application window.
Um. How about if the scope of the patch is repharsed as "embedding the Wine desktop inside an X11 window"?
Regards, Timothy