[Lazarus] Form position model

[Hans-Peter Diettrich]

After submitting issue #13446, general questions come into mind:

How are form positions treated with projects in a multi-monitor environment?

How should form positions be treated, when the project is not developed 
on the first/primary monitor?

IMO we should distinguish between projects developed *for* single or 
multiple monitors, and handle somehow negative screen/desktop 
coordinates, on systems where the primary monitor is not the leftmost one.

1) A single-monitor project later should run on any (startup) monitor, 
regardless of the number of the monitor it was developed on. Eventually 
all forms should appear on the monitor with the main window on it, and 
should be moved when the main window is moved to another monitor. (kind 
of SDI project, splitted into multiple windows)

2) A desktop-wide project should start on the leftmost monitor, 
regardless of whether this is the primary monitor. What about systems 
with a RTL language?

3) A multi-monitor project should respect the designed monitor number 
for any form - at least when running on a system with so many monitors. 
This is a very special kind of project, almost developed for a dedicated 
target system.

(more?)


Furthermore popup-windows (hints, dialogs, messages) should be 
*designed* properly, i.e. application-wide message boxes should appear 
on the main window monitor, others should appear on the monitor of their 
parent window. IMO exactly this dependency is not always properly 
reflected in the Lazarus IDE. When both the main window and a design 
form is moved to another monitor, the form Save dialog (when the form is 
closed) never should appear on an unrelated monitor. Likewise a hint 
window has to appear on the exact position over its *parent* form; 
adjustments can be made only when the hint window would exceed the 
desktop extent. Eventually a "no-span" attribute should be introduced 
for popup windows, indicating that it should be adjusted to reside 
entirely on a single monitor.


The question is: how many properties, modes and related automatism 
should be built into the LCL? What should be left to the application 
designer, supported by procedures like AdjustToSingleMonitor(AParentForm).

Eventually we should offer a runtime attribute (in the system menu), 
that allows to configure an application to *behave* as a single-monitor 
app (case 1 above), where all windows use the monitor of the main form, 
and allow to switch that monitor on startup or at runtime. This would 
allow to keep multiple instances of the same application (i.e. Lazarus 
itself) running on dedicated monitors. Moving the entire instance to an 
dedicated monitor should be a one-time action, not hindering the user 
from moving or extending specific forms across monitor boundaries later.

Eventually we also should add an "application GUI" designer to the IDE, 
that can reflect and adjust *visually* the runtime placement of all 
windows on target systems with various monitor configurations. Such a 
wizard would help to find and correct the currently misplaced popup 
windows in the Lazarus IDE itself, in detail when a developer only has 
an single monitor on his development system.

Opinions?

DoDi