Coordinate systems

[qPCR4vir]

Thinking about how to fix the DPI scaling problem and after reviewing a lot of code I would like to discuss here how we can really fix all of this: DPI, scaling, multi-monitors, screens, windows, client areas... float, int, size_t, UINT... (See #698 , specially Where to put the frontier original/scaled coordinates for PER_MONITOR_AWARE_V2 ?)
I think the core problem is much more general: coordinates are just meaningless numbers if we don't have an explicit reference to a coordinate system. We can take the speed in km/h of a car, with respect to the surface of the Earth. But if we launch ourselves to the Moon, the reference will work only at the beginning. Then we will want to measure the velocity with respect to a system that involves both the Earth and the Moon and that also allows us to calculate the escape velocity from Earth's gravity. At the time of dawn we will again prefer a reference to some point on the surface of the Moon. We will need that clear reference to the coordinate system all the time and know how to go from one system to another.
Here we have a similar problem: each position/size or rectangle need an explicit reference to a coordinate system. We need to define each coordinate system only once, but each coordinate need a reference to that. Then, we will need a simple and efficient way to convert from one to any other system: this will be a kind of small function object that efficiently make the conversion on both directions.
We have many 'coordinate system': the system coordinates of the whole screen, including all monitors (the origin or 0 point is on the left/top point of the principal monitor), that same but with a system scaling - system DPI. The system af each monitor with a 0 at left/top. That scaled (like in DPI_awareness). Each window have own system (client), and non-client, and the parent system, Each scaled too. Etc. It is very easy to make mistakes if not using some systematic approach, like the function objects for conversion, at run-time.

I have some similar experience transforming physical units at run time.
See: github qPCR4vir ProgParam Units.hpp
There we have a CUnit object (Conversion of Units) that take two units and make a conversion of quantities between then. This uses a conversion object that can be lineal or not. The lineal conversion take a Coefficient and a Summand. The non-lineal an std:function.
CUnit keep a map to find how two units are converted. The first time a program invoke one conversion it is generated combining all the intermediary units and saved into that map for efficient use the next time. We convert from inches to meters by first combining the conversion inch/cm and then cm/m in one new inch/m wich is then used for the repeated calculations.

Similarly, instead of Units (or apart from units) we may work with different 'windows-coordinate system', each atached to one widget_base, monitor or screen with the associated scaling or DPI. In extreme situations that conversion objects will include not only changing origin and scale (dpi) independently for each direction, but also rotation and even 3D. All in one general solution and a lot less error prone. nana could add the possibility of easy scaling and even rotation each widget separately or in combination.

[qPCR4vir]

By the way... it could be cold to add CUnit to nana and the corresponding widget NumUnitUpDown which combine a number and a unit with automatic conversions.

see how the concentrations are easily expresed in nM, µM, mM, and the temperature including °F

[qPCR4vir]

The coordinates and all related problems: multimonitors, DPI, scaling..

all posible coordinate-system ( CoordSys ). The scaling is part of the definition of the CoordSys. There could be arbitrary scaling, but we will fix two special cases:

• User-side scale (US): where each unit is a pixel when the windows user has not scaled the monitor. If the windows user has not set any scaling (100% is set) we have access to a monitor screen size equal to the resolution set for the monitor. The units are in pixels (for that fixed scenary). Independiently of the real physical dimensions of each pixel. In this scale an small 4k laptop monitor will be 4 times bigger than a physically giant HD TV screen. Instead of using the numerical scaling factor (here 1 or 100%), internally, MS Window said it is 96 DPI. This means that those inches are NOT real inches, and that those inches are NOT even equals for different monitors. The internal DPI has no physical meaning, only says the scaling: scale = DPI/96, fixed by rule of will. MS Windows chose this weird terminology because it made possible to continue to design all screens in the same 'scale' (using the same numbers in the coordinates/sizes), as it used for 'clasical' small 640x480 monitors. In fact, it is common for 'reasonable' HD monitors to have a DPI near 96, and all the design will be aproximately equal to the physical result. The problem is that by using pixels as unit, in real high DPI monitors, with many pixel per real inch, all the drawing is very small. Users will want to scale the drawing to make it bigger - from 100% to 200% for example.
• System-side scale (SS): after including the scale the windows user has set for the monitor
• Custom Scaling (CS): additionally, we may think on a potential scaling applied after US and before SS.

The CoordSys is also defined by the Origin (where the (0,0) point, or O point, is with respect to some other CoordSys). In many cases it may be usefull to include the dimensions or size, to define an area. Examples of positions+Area are:

• the Whole-System-Screen (WSS): a virtual screen that included all monitors placed in the relative positions specified by the user. Some parts of this WSS are not occupied by any monitor. May use User-side (WSS_US) or System-side (WSS_SS) scaling. The O is in the left/top point of the main monitor.
• Monitor screen (MS), MS_US or MS_SS. We need to specify what monitor it refer. The O is in the left/top point of the monitor. Example: we use MS_SS in api::make_center(size)
• Widows area or Windows Rectangle (WR): WR_US or WR_SS. WE need to specify what window it refer. The O is in the left/top point of the external part of the window.
• Widows Client area - WC: WC_US or WC_SS. We need to specify what window it refer. The O is in the left/top point of the internal part of the window, where the program usually draw. WC is include inside the WR of the same window.
• Widget-Area? This is always a 'client' area: WA: WA_US or WA_SD. We need to specify what widget it refer. The O is in left/top point of the widget.
• Owner (or Parent) Area (OA): this is the same as WC or WA but when it is used by a child widget. May be OA_US or OA_SS.
  For example, the coordinates of the member point basic_window.pos_owner uses the OA, that is, the same WC (or WA?) of the window of the owner of the current basic_window, because pos_owner define the position of the window with respect to the owner. On the other hand member point basic_window.pos_root uses the CoordSyS of the monitor MS_US (or WSS_US?). See:

void basic_window::_m_init_pos_and_size(basic_window* parent, const rectangle& r)
{
	pos_owner = pos_root = r.position();
	dimension = r.dimension();

	if (parent)	pos_root += parent->pos_root;
}

or this:

	// Copy the graphics of the parent widget to the glass buffer
	glass_buffer.bitblt(::nana::rectangle{ wd->dimension }, 
                    		wd->parent->drawer.graphics, 
				wd->pos_owner);

In a more general situation we may need to include rotations of one CoordSys with respect tp other. Simple 90°/-90° or even 'free angle' rotation.