I would like to know if it is possible to integrate the GtkSocket mechanism in wine. (To embed activex component in a gtk application.)
I do not know exactly how to proceed, I need more informations:
- do I must embed GtkSocket code in wine? - do I must synchronize GtkWidget and HWND?
For the ActiveX, I use, with a dynamic link, the atl.dll to embed components. It is easy and It works with HTML editor and others stuffs... But I dont know if this is the right way to embed components?
Olivier
------------------ www.programmers.ch
On Thu, 2003-08-28 at 01:26, Evalet Olivier wrote:
I would like to know if it is possible to integrate the GtkSocket mechanism in wine. (To embed activex component in a gtk application.)
I've thought about this before. The primary problem is that you'd need some custom IPC mechanism, as simply instantiating an ActiveX control and embedding it in a window isn't terribly useful, you generally want to call its methods and set its properties.
I've pondered using DBUS for that. A simple DBUS<->COM bridge would be handy, though COM doesn't really map to DBUS very well, so it wouldn't be quite the same as using normal COM/DCOM.
I do not know exactly how to proceed, I need more informations:
I already put some basic support for processing XEMBED messages into Wine with my system tray patch, that isn't merged yet. You might want to take a look at that first.
- do I must embed GtkSocket code in wine?
No, there's no need for that, XEMBED is well documented and can be implemented in Wine directly.
- do I must synchronize GtkWidget and HWND?
You don't need to link against GTK to do what you want.
For the ActiveX, I use, with a dynamic link, the atl.dll to embed components. It is easy and It works with HTML editor and others stuffs... But I dont know if this is the right way to embed components?
The ATL is a C++ toolkit, beyond that I know little about it. The easiest way to embed an ActiveX control is to turn a program into a WineLib app. At that point the problem becomes one of internally using XEMBED to synchronize the Wine toolkit and GTK. That sort of thing shouldn't be very hard, I expect a simple Wine extension to Win32 would work here (setting an extended window style or something).
thanks -mike
Hello mike,
I've thought about this before. The primary problem is that you'd need some custom IPC mechanism, as simply instantiating an ActiveX control and embedding it in a window isn't terribly useful, you generally want to call its methods and set its properties.
Yes, and for this I have a done something, see attach. (I have to test the properties and methods access)
I've pondered using DBUS for that. A simple DBUS<->COM bridge would be handy, though COM doesn't really map to DBUS very well, so it wouldn't be quite the same as using normal COM/DCOM.
if I make DBUS bridge with my attach will be not efficient?
I already put some basic support for processing XEMBED messages into Wine with my system tray patch, that isn't merged yet. You might want to take a look at that first.
I have patched your work in my wine src, it works very well :). But for the moment, it's too abstract. I don't understand how to simulate a GtkSocket creation, how to send the windows handle to another process window??? This part is very strange, like magical, hahaha. but maybe I just need to send the same messages as Gtksocket to GtkPlug?
The ATL is a C++ toolkit, beyond that I know little about it. The
easiest way to embed an ActiveX control is to turn a program into a WineLib app. At that point the problem becomes one of internally using XEMBED to synchronize the Wine toolkit and GTK. That sort of thing shouldn't be very hard, I expect a simple Wine extension to Win32 would work here (setting an extended window style or something).
For my tests I try all in wine application (embed activex and to use methods). After this, I will work for the magical xembed mechanism and at the end I will implement DBUS bridge.
thank you very much for your help. Olivier
------------------ www.programmers.ch
On Thu, 2003-08-28 at 17:30, Evalet Olivier wrote:
if I make DBUS bridge with my attach will be not efficient?
DBUS would only be needed if you wanted to embed an ActiveX control into a native non-WineLib Linux app. If you stay within Wine-land then you can forget about it.
I already put some basic support for processing XEMBED messages into Wine with my system tray patch, that isn't merged yet. You might want to take a look at that first.
I have patched your work in my wine src, it works very well :). But for the moment, it's too abstract. I don't understand how to simulate a GtkSocket creation,
A GtkSocket implements the embedder side of the XEMBED protocol, I suggest you read it. There is no implementation of this in Wine.
A GtkPlug implements the embeddee side. This is what the tray icon patch does. The only XEMBED "support" it adds really, is handling XEMBED client messages and printing them out. It also has code for initiating a dock. To fully support XEMBED client, you'd need to introduce a new window message, handled by the default wndproc, that starts a dock with the given XID. To allow other things to embed within Wine, you'd need to do more work.
how to send the windows handle to another process window???
Well, if the other process is a win32 process, there are several options. You can just send it a window message, for instance.
For my tests I try all in wine application (embed activex and to use methods).
That should work without XEMBED then.
After this, I will work for the magical xembed mechanism and at the end I will implement DBUS bridge.
Cool, let me know how it goes :)
thanks -mike
-
Evalet Olivier -
Mike Hearn