[Lazarus] Generate "app" in Mac OS X

[John Coarsey]

Martin schrieb:
> Try the following,
> 
> - open one or 2 sources in the main window (just to make sure you have 
> some tabs)
> - show object inspector (or messages...) and dock to the main window
>  ( it must be docked to the main win, or it will not happen)
> 
> - now grab the OI at it's top left corner and start dragging
> 
> You should see the dragging rectangle for the OI. The mouse should touch 
> (or be within pixel distance of) the corner of the rectangle
> Move the mouse over the remaining tabs (and keep moving / move from one 
> tab to the other and back, possible with a simultaneous up/down move).
> 
> Because the mouse and the drag border are over the tabs at the same 
> time, the border leaves ghost images of itslef (windows)
> The reason is that the tabs redraw themself if the mouse goes over (in 
> order to show a bit of highlight indication) [ so the whole thing is 
> theme dependent ]

Since the mouse is captured while dragging, no other control should 
react on mouse moves itself. If this will happen, it's a flaw in the 
widgetset or dragging model itself[1]. At least I could not get such 
unwanted visible component feedback on Linux/gtk2.

I admit that the tabs react on Win32, and that consequentially artefacts 
may be possible, even if I could not produce any.

Artefacts may come from other events, e.g. when a OnDockOver event 
handler updates the statusbar, and the dragging frame moves over the 
statusbar, but that then is a bug in the application.


> Since the frame draws deletes by inverting the screen, any changes to 
> the screen (as the redraw of the tab) causes frame-fragment to be left 
> behind.

AFAIK Paul implemented the dragging frame on gtk2 by a transparent (top 
level) window, that should be clipped or repainted properly in any case. 
The same may be implemented for other widgetsets as well.

> 
> ------------------------
> I haven't looked at your code.

No need to do so. The sample application shall demonstrate *both* the 
possible and impossible features, feasable with the existing docking 
model. All bug reports and suggestions are welcome, and I'll either try 
to reflect them in the demo program, or leave them for the docking 
redesign discussion.

> but the IDE does "setCapture" (same as MouseCapture := true) to the 
> control that is going to be dragged. That way all mouse events go there, 
> and the tabs don't get them.

That's part of the DragManager LCL logic, that cannot be changed by any 
application. What you see is an effect from one of the many flaws in the 
Delphi drag-dock model, and should be remembered for the discussion of a 
general docking redesign.

[1] One of my older suggestions addresses exactly the improper handling 
of the mouse capture, where all mouse events should be filtered 
immediately (TApplication.ProcessMesssages?), when a mouse capture is 
active. This will eliminate according tests within the further message 
handling, and will eliminate any chance that other components will fail 
to handle a mouse capture properly. Such a filter would not (adversely) 
affect the performance of the message handling system, when it checks 
for an active mouse capture first, before any filter logic (tests...) is 
applied.

DoDi