On Mon, 13 Dec 2004 21:58:07 +0000, Mike Hearn wrote:
- Use freedesktop.org system tray protocol, remove legacy KDE support
- Introduce new Explorer process
- Rewrite system tray handling to be out of process
Hi Alexandre,
What needs doing next for this patch?
thanks -mike
Mike Hearn mike@navi.cx writes:
On Mon, 13 Dec 2004 21:58:07 +0000, Mike Hearn wrote:
- Use freedesktop.org system tray protocol, remove legacy KDE support
- Introduce new Explorer process
- Rewrite system tray handling to be out of process
Hi Alexandre,
What needs doing next for this patch?
I'm still hoping to see a version that doesn't include the xembed stuff, this will have to be done differently anyway. Also the 16-bit calls need to be removed.
On Thu, Dec 23, 2004 at 06:10:50PM +0100, Alexandre Julliard wrote:
I'm still hoping to see a version that doesn't include the xembed stuff, this will have to be done differently anyway.
That's a bit vague, how should it be done? I also don't understand why the XEMBED code has to be split off, that's the standard way to dock tray icons in all modern desktops. If we don't dock the icons, what else can we do with them?
Also the 16-bit calls need to be removed.
I did it that way because when I last asked you how to marshal an HICON you said to use the 16-bit functions to get the data. How can I marshal the HICON without using GlobalLock16 and friends?
thanks -mike
Mike Hearn mike@navi.cx writes:
That's a bit vague, how should it be done? I also don't understand why the XEMBED code has to be split off, that's the standard way to dock tray icons in all modern desktops. If we don't dock the icons, what else can we do with them?
The code has to be split off from the explorer patch because it's independent, you don't need XEMBED to add an explorer process, and you don't need an explorer process to support XEMBED; and the rule is that separate changes should be done as separate patches, for many good reasons.
The other thing that needs to be done differently is that the WS_EX_TRAYWINDOW flag has to go, that's not Windows compatible. We need to define an appropriate interface that doesn't involve overloading Win32 flags.
Also the 16-bit calls need to be removed.
I did it that way because when I last asked you how to marshal an HICON you said to use the 16-bit functions to get the data. How can I marshal the HICON without using GlobalLock16 and friends?
You should be able to do it with GetIconInfo and friends.
On Thu, 23 Dec 2004 19:06:04 +0100, Alexandre Julliard wrote:
The other thing that needs to be done differently is that the WS_EX_TRAYWINDOW flag has to go, that's not Windows compatible. We need to define an appropriate interface that doesn't involve overloading Win32 flags.
OK, would an atom set on the window be appropriate here?
thanks -mike
Mike Hearn mike@navi.cx writes:
On Thu, 23 Dec 2004 19:06:04 +0100, Alexandre Julliard wrote:
The other thing that needs to be done differently is that the WS_EX_TRAYWINDOW flag has to go, that's not Windows compatible. We need to define an appropriate interface that doesn't involve overloading Win32 flags.
OK, would an atom set on the window be appropriate here?
It's not even clear that we want a window at all. I think the right way is to first design a stand-alone systray (which we'll need for desktop mode anyway) and then plug XEMBED into that.
-
Alexandre Julliard -
Mike Hearn