Issues Linux versie

[jipclaassens]

Map-view:

• raster caret boundary weird colour
• map colours do not match legend colours
• overview map geeft zwart gevuld blok voor locatie
• hoover tooltip werkt niet meer
• plus/min-knop op numpad-toetsenbord werkt niet meer.
• tooltip hoover blijft hangen
• grid kleur wit is niet meer transparant
• layercontrol, below layer title cell value same size as table

Table-view (geldt ook voor table in layercontrol):

• header vetgedrukt maken, zodat de header groter/vetter is dan de tabelwaarden -> intuïtiever.
• cel values niet vetgedrukt gemaakt
• plaatsing van values binnen de cel: nu heeft de onderkant iets meer ruimte dan de bovenkant; liever andersom of centreren.
• plaatsing values binnen cel, voeg een heel klein beetje ruimte toe voordat de waarde begint
• kolom resize probeert de grens naar links te trekken wanneer je met de muis naar rechts trekt
• kolom resize, na resize blijf je verticale strepen zien waar eerder de grens heeft gestaan.

[MaartenHilferink]

Table-view bullets addressed (branch refactor_linux_gui):

• header vetgedrukt — TableHeaderControl::ColumnHeader::Draw wraps the base draw in SetBold(true)/SetBold(false); new pure-virtual DrawContext::SetBold(bool) with GDI (LOGFONT lfWeight swap via CreateFontIndirect) and Qt (QFont::setBold) impls. Commits 2e606a2, 175eed3.

• cel values niet vetgedrukt — DataItemColumn::DrawElement defensively SetBold(false) before the symbol- and text-out paths, so a previous header paint can't leak weight into the cell DC. Commit 175eed3.

• plaatsing values verticaal — GetDefaultFontHeightDIP was returning POINTS but being fed straight to SetRowHeight as if it were DIPs, leaving cells too short. New GetDefaultRowHeightDIP helper does point→DIP (* 96/72) plus 4 DIP padding so top-aligned text clears the row separator with breathing room. Applied in TableControl, TableHeaderControl, TableViewControl, PaletteControl. Commits b4802d3, 7aec376.

• iets ruimte voor de waarde — DataItemColumn::DrawElement adds 1-px left pad on both TextOut and TextOutW paths so the value doesn't sit flush against the column separator. Commit 175eed3.

• kolom resize trekt naar links bij naar rechts slepen — three independent regressions in the Qt port, all with the same user-visible symptom:

  1. VH_GetCursorScreenPos/VH_ScreenToClient/VH_ClientToScreen/VH_SetGlobalCursorPos on Windows route through native ::GetCursorPos / ::ScreenToClient / ::ClientToScreen / ::SetCursorPos against m_DataViewHWnd, instead of through Qt's mapToGlobal/QCursor (whose per-monitor DPI handling on a HiDPI secondary monitor returned screen coordinates ~960 px off, so every SetCursorPos warped the cursor across the screen).
  2. toClientPoint now multiplies the (event - cr.topLeft) delta by devicePixelRatioF() so EventInfo::m_Point carries device-px on the Qt port too — restoring the Win32 lParam contract that the SHV layer (StartResize, ColumnSizerDragger, TieCursorController) was written for.
  3. TieCursorController::Move only calls SetCursorPos when the clamp actually moved the point. Calling it on every MOUSEDRAG was a no-op under native ::SetCursorPos but on Qt the round-trip + event-loop timing turn it into a per-frame "pull" the user perceived as the column border drifting left while the mouse was held still.

  Commit 593137f.

• verticale strepen na resize — combination of three things:

  1. VH_ScrollWindow drops SW_INVALIDATE (Win32ViewHost reference uses 0; double-invalidation was producing the trails) and adds the caller-supplied validRect ValidateRect, plus a force-invalidate of the strip from scrollRect.right/.bottom to clipRect so columns past the scrolled rect (whose m_RelPos was shifted by AutoSizeContainer::GrowHor without a per-sibling ScrollDevice) get repainted.
  2. DataView::ScrollDevice builds the DcHandle on GetHWnd() (= m_DataViewHWnd via VH_GetHWnd) rather than the bare m_hWnd member, which was 0 on the Qt port. With the wrong HWND the CaretHider was hiding/showing carets on a screen DC, so the resize-guide MovableRectCarets never got un-XOR'd before ScrollWindowEx and got blitted along with the cells.
  3. After the scroll, also union rcClippedScroll into drawRgn so OnPaint repaints the whole source area fresh, then the tail ReverseCarets re-applies the XOR cleanly. Surgical caret-region-only invalidation didn't cover FocusCaret/NeedleCaret and selection highlights baked into the cells themselves; the pragmatic full-source invalidate matches the 19.x reference visually at the cost of the scroll-blit's perf advantage on this path.

  Commit 593137f.

Diagnostic logging used to trace #1100 was removed before commit. Residual XOR-caret streaks on a 125% DPI monitor remain (existed in 19.2.0 too, not a regression).

[jipclaassens]

Table-view bullets addressed (branch refactor_linux_gui):

De tekstgrootte is nu ongelijk: table text is groter dan header en groter dan treeview. Layercontrol table text is ook vrij groot. Wellicht zou je value info dan ook iets groter moeten?

[jipclaassens]

Test in Regressie test:
resopen_regressietest_v2025h2_wlb
mapview op:
/SourceData/Grondgebruik/BBG/Dominant/per_100m_Modus/Y2020

map view kleuren matchen niet met de legenda kleuren.

Voorbeeld: woongebied in Almere aangeklikt: rij 6 is oranje in de Legenda, maar blauw getekend door de GridLayer.

[MaartenHilferink]

map view kleuren matchen niet met de legenda kleuren ... rij 6 is oranje in de Legenda, maar blauw getekend door de GridLayer

Fixed on refactor_linux_gui (commit 89947d2).

Root cause: GridColorPalette::m_PaletteColors was storing raw DmsColor bytes (memory layout R,G,B,T from 0xTTBBGGRR), but its only consumer — DrawContext::DrawImage via GridDrawer::CopyToDrawContext — interprets the buffer as RGBQUAD (memory layout B,G,R,Reserved). Both backends apply the same wrong interpretation: GdiDrawContext::DrawImage memcpys into bmi->bmiColors, QtDrawContext::DrawImage casts to struct {b,g,r,reserved}. Net effect: every small-palette lookup swapped R and B, so orange (0xFF8000) renders as blue (0x0080FF).

The 19.x Win32 path didn't hit this because it only consumed m_BitmapInfo->bmiColors, which was going through Convert<RGBQUAD>(...). The cross-platform refactor introduced m_PaletteColors as the new handoff but skipped the conversion in the small-palette branch.

Fix: route every m_PaletteColors[i] = … assignment through DmsColor2RgbQuadFunc, and rebuild that function with explicit byte arithmetic so it produces correct RGBQUAD layout on both Win32 and Linux/Qt (the previous non-Win32 branch was an identity pass-through with a comment incorrectly claiming DmsColor and RGBQUAD already matched).

Two other MapView regressions are also in the same commit:

• +/- zoom keys: qtKeyToVK lacked entries for Qt::Key_Plus/Qt::Key_Minus, so the events were swallowed by QMdiSubWindow instead of reaching ViewPort::OnKeyDown (which already maps VK_ADD/VK_SUBTRACT → TB_ZoomIn1/TB_ZoomOut1).
• Overview-map ROI rectangle (was opaque black, should be semi-transparent pink): GdiDrawContext::FillRect ignored the DmsColor transparency byte and CreateSolidBrush rejects a non-zero high byte. Now strips the high byte for the opaque path and routes partial transparency through ::AlphaBlend with SourceConstantAlpha = 255 - trans, mirroring the 19.x AlphaBlend against a 1×1 source bitmap that was lost during the refactor.