Graeme Geldenhuys schrieb:
The determination of a closer target (e.g. control) is up to the
application or library, that manages the layout of a window. Every
application or library can freely define their own "handles" for every
Try and implement your own GUI toolkit, and we talk again.
What tools do you have in mind? One of my first GUI libraries
implemented Windows-compatible widgets on the Atari ST, during the beta
test of Turbo-C for ST.
Just some (not all) of the problems Qt had to overcome are as follows:
Can you be a bit more specific with your examples? IMO you confuse
inter-process and cross-process operations.
* XDND protocol requires mouse enter, exit and window properties to
correctly get a source or target of a drag action. X11 Window
handles are required for this.
* Windows OLE drag-n-drop protocol requires window handles for each
window or widget that can do DND.
As mentioned above, *every* dragmanager must have handles for all
involved components. An OS-wide dragmanager can only use OS-wide
handles, e.g. those of the OS-wide window manager.
Dunno about XDND, but sounds to be out-of-process as well.
* Window clipping must now be handled by Qt itself.
In which context? During painting it depends on the screen graphics
library, whether the canvas implements some clipping, or allows to write
on the entire screen.
* Window clipping between non-handle windows and handle-windows.
eg: The form has a handle, but all normal widgets on that form
have no handles. Now through in a OpenGL widget which must have
a window handle. Now you have widgets on the form that has handles,
and some that don't. Now apply all the previous items listed to the
mix.
I don't see the consequences. Controls with an OS-wide window handle are
known to the window manager, others are not.
DoDi
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
