[QMS-903] Convert CMapItemWidget into CMapItemDelegate

[kiozen]

What is the linked issue for this pull request:

QMS-#903

What you have done:

This is a house keeping PR. It does not change any functionality. It changes the code to (hopefully) something better.

@mitxel-m @wthaem @JFritzle and all others: Please test!

I introduced CMapItemWidget to have a better UI for the map and DEM items. Qt does not recommend using item widgets for reasons. Those reasons are biting and as I would like to extend the UI pattern to GIS projects etc. a proper solutions needs to be established.

The proper solution is called QStyledItemDelegate. It has several advantages:

• drag-n-drop is working without a headache and the visual representation is 100% the item in the list.
• Styled coloring is consistent for the complete item
• No crash-boom-bang to workaround as the item widget gets lost in all kinds of situations.
• Faster to handle

Drawback:

• You have to code everything on your own.

Anyways QStyledItemDelegate is the way to go. Functional wise there should be no difference. Visually there are some small differences.

Steps to perform a simple smoke test:

Use maps and dems as you always do.

Does the code comply to the coding rules and naming conventions Coding Guidelines:

• yes

Is every user facing string in a tr() macro?

• yes

Did you add the ticket number and title into the changelog? Keep the numeric order in each release block.

• yes, I didn't forget to change changelog.txt (this is housekeeping, no change)

[wthaem]

My visual impressions with Windows 11, Qt6.10.0, GDAL 3.11.5, proj 9.6.2:

• Compiling slightly different and slightly faster (but I don't know how many results of the previous compiler run could be re-used)
• Test with several views and various mainly online maps: slightly faster loading of maps (especially when loading a map from a PDF file)
• Test with several views and various DEM data of various types: seems to be significantly faster
• From time to time, there are strange relatively long waiting times when switching from one map or DEM view to the next one
• In one case, a crash when switching from one view to the next - couldn't be repeated

What else has been changed with this PR?

and (most likely not related to this commit/PR): long waiting times before the splash screen disappears (seems to be caused by the relatively large number of views in the configuration and/or the Routino initialisation with several routing databases). The main GUI is visible for quite some time below the splash screen.

[kiozen]

Only change is how map and dem list items are displayed.

The stall of the UI (splash and while switching maps/dem) is due to most stuff is handled in the UI thread, some in other threads and mutex protecting the complete stuff. The moment the UI tries to lock one of the mutex and the mutex is owned by another thread everything has to wait for that thread. It would be much better to do most stuff in threads and signalling the UI when done. However this not trivial and I do not see a solution without rewriting large portions of code.

The crash is very likely not related to that PR. This is really just affecting the map and dem lists.

But the rest is promising. The main advantage is the proper visual selection and drag-n-drop behavior.

[JFritzle]

There is a difference of visibility in dem and map Windows.

Dev branch ...

... where dem height and the green bar obscurely overlay dem's name and activated state.

testing_stuff ...

... where dem height and the green bar transparently overlay dem's name and activated state,
... where maps's green bar transparently overlays map's name and activated state.

Beside of that, I did not notice any difference, neither in window's presentation nor in windows's handling.

For me, the former is looking better.

[JFritzle]

If possible, it were nice to see map's and/or dem's full string as a tooltip when hovering over item.
Maybe tooltip could contain additional useful information about map or dem?

[eyzdh]

I also tested.
The Map, DEM on / off is on my arm Mac smaller but I like it.

dev branch

testing_stuff

[kiozen]

If possible, it were nice to see map's and/or dem's full string as a tooltip when hovering over item. Maybe tooltip could contain additional useful information about map or dem?

Good catch. Added cropping. And tool tip if name is not fully visible.

[kiozen]

I also tested. The Map, DEM on / off is on my arm Mac smaller but I like it.

dev branch

testing_stuff

That looks peculiar. Why are the tool buttons not square? It should be 24x24 pixel and the icon should be 16x16. Everything fitting nicely in the item's 32 pixel height.

[eyzdh]

That looks peculiar. Why are the tool buttons not square? It should be 24x24 pixel and the icon should be 16x16. Everything fitting nicely in the item's 32 pixel height.

If I know where I can look so that you have the necessary information, then I will gladly do that.

[JFritzle]

In screenshots from @eyzdh. activation buttons not only do not looking square but they are missing the white square background surrounded by gray edges.

[JFritzle]

If of interest: With Windows build, buttons are square! Everything ok.

[kiozen]

That looks peculiar. Why are the tool buttons not square? It should be 24x24 pixel and the icon should be 16x16. Everything fitting nicely in the item's 32 pixel height.

If I know where I can look so that you have the necessary information, then I will gladly do that.

Get latest code. In CMapItemDelegate.cpp line 240 you will find:

auto [fontName, rectIcon, rectButton, rectIndicator, rectName, rectStatus] = getRectangles(opt, isActive);

you can print the rectangles to the debug output :

qDebug() << rectIcon << rectButton << rectIndicator << rectName << rectStatus;

and check if the out matches the expectations. You will get a lot of lines like:

2026-01-20 17:33:35.638 [debug] QRect(20,96 30x32) QRect(234,100 24x24) QRect(224,102 6x20) QRect(54,98 167x14) QRect(54,112 167x14)
2026-01-20 17:33:35.638 [debug] QRect(20,128 30x32) QRect(234,132 24x24) QRect(224,134 6x20) QRect(54,130 167x14) QRect(54,144 167x14)
2026-01-20 17:33:35.639 [debug] QRect(20,160 30x32) QRect(234,164 24x24) QRect(224,166 6x20) QRect(54,162 167x14) QRect(54,176 167x14)
2026-01-20 17:33:35.639 [debug] QRect(20,192 30x32) QRect(234,196 24x24) QRect(224,198 6x20) QRect(54,194 167x14) QRect(54,208 167x14)
2026-01-20 17:33:35.640 [debug] QRect(20,224 30x32) QRect(234,228 24x24) QRect(224,230 6x20) QRect(54,226 167x14) QRect(54,240 167x14)
2026-01-20 17:33:35.656 [debug] QRect(20,128 30x32) QRect(234,132 24x24) QRect(224,134 6x20) QRect(54,130 167x14) QRect(54,144 167x14)

The x/y offset is not of interest but the sizes like QRect(234,132 24x24) which is the 24x24 rectangle for the button.

If that does not fit you have to find out why. Placing qDebug() in the code or use a debugger.

[eyzdh]

I did it with you latest code - its the same size like my screenshot
[debug.txt](https://github.com/user-attachments/files/24748408/

and I played with terminal a bit more, in this file more information what qt does, maybe it helps
debug_w.qt .txt

[kiozen]

The link to the first file is dead. And I lack the time to work myself thru the 19MB of text garbage of the second link. Please, keep debug information as short and precise as possible.

[JFritzle]

QRect extract of 19 MB data:
extract.txt

[kiozen]

Ok, thanks! 😄 The math seems to be ok. This reduces the problem to QStyleOptionButton used in the delegates paint method.

// draw tool button to activate
  QStyleOptionButton btnOpt;
  btnOpt.state = (item->getStatus() != IMapItem::eStatus::Missing ? QStyle::State_Enabled : QStyle::State_None) |
                 (isActive ? QStyle::State_On : QStyle::State_Off);
  btnOpt.rect = rectButton;
  btnOpt.icon = isActive ? QIcon(":/icons/32x32/ShowAll.png") : QIcon(":/icons/32x32/ShowNone.png");
  btnOpt.iconSize = rectButton.adjusted(2 * kMargin, 2 * kMargin, 2 * -kMargin, 2 * -kMargin).size();
  btnOpt.features &= QStyleOptionViewItem::HasDecoration;

  QApplication::style()->drawControl(QStyle::CE_PushButtonBevel, &btnOpt, p);
  QApplication::style()->drawControl(QStyle::CE_PushButtonLabel, &btnOpt, p);

Maybe this lacks some flag or call. The only way to find out is to go thru the docs and examples and try to add stuff. But please do not throw in everything. Try to single out the real root cause.

My first try would be:

  QStyleOptionButton btnOpt;
  btnOpt.initFrom(treeWidget);
 ....

[eyzdh]

The link to the first file is dead. And I lack the time to work myself thru the 19MB of text garbage of the second link. Please, keep debug information as short and precise as possible.

ok for the next time I will do that.

Thanks @JFritzle

[JFritzle]

Cause of issue - it is Qt's style!

Square buttons with Qt style "Fusion" (command line arguments --style Fusion) ...

Square buttons with with Qt style "Windows" (command line arguments --style Windows) ...

Non-square buttons with Qt's built-in default style (no command line arguments) ...

Same non-square buttons happen not only with testing_stuff but also with development branch.
Non-square buttons do not happen with Qt's built-in default style and development branch. ...

[kiozen]

Good work!. Does it make sense to set style Fusion if no --style is provided? Can you please provide a patch?

[kiozen]

I asked our new friend Copilot and it is suggesting, too, might be the missing call to btnOpt.initFrom(...) next to some other little things . I reviewed and copied the suggested code and pushed it. Please test.

[JFritzle]

Sorry, buttons still not square.

Built-in style is "macOS".

We could certainly force style "Fusion" when no style gets passed by command line.
But I think this no good solution. As we have learned in discussion about restructuring waypoint icons setup and assigning, serveral Linux distributions have customized styles for example suitable to KDE plasma desktop, and customized style is default style. If we internally force style "Fusion", then we force users to override style by command line to keep look-and-feel.

[eyzdh]

I know I'm a coder nob that's why ai warning, I played with the QStyleOptionButton code

i have this Version:

or an other one:

[mitxel-m]

With actual deb, when moving an item in the list, the line indicating where it will be placed is only visible between the map icons, making it very difficult to see and not very helpful. This change has come with a recent commit, but I don't know which one.

with this PR: the line takes up the entire width, as usual, and is better.

vertical green visibility indicator:
With this PR, when moving an item in the list, the green visibility indicator on the visible maps does not show the correct status.

It seems that when drawing up the list, it is does not look at the visibility range to paint the correct status, but once you move the map or zoom in, they refresh and show the correct status.

It seems that it only fails for those that change order in the list. That is, if I have three active items and I move 3rd to 1st, then all will fail, but if I move 1st to 2nd, 3rd remains fine. And if, after a first move, I return the map to its original position in the list, it shows correctly again.

[kiozen]

@mitxel-m good catch! Needs to be fixed.

[kiozen]

@eyzdh can you provide code for the first one? Copy-n-paste the changed code into a text file and attach.

[eyzdh]

replace code line 242 until 276 with:
code.txt

[eyzdh]

Sorry wrong code, this is the right one
code.txt

[kiozen]

Sorry wrong code, this is the right one code.txt

Ok, but here we have the problem that this does not take any style into account. This is why a styled button is used. The buttons must match all the other buttons in the application. In colors as well as in how it's drawn. Look at all the screenshots in this PR for examples.

That's why we need to get the styled button to work.

[kiozen]

@mitxel-m fixed your catch.

[eyzdh]

Sorry wrong code, this is the right one code.txt

Ok, but here we have the problem that this does not take any style into account. This is why a styled button is used. The buttons must match all the other buttons in the application. In colors as well as in how it's drawn. Look at all the screenshots in this PR for examples.

That's why we need to get the styled button to work.

Make sense, I will also try to get the styled button to work

[JFritzle]

Buttons still not square:

[kiozen]

Buttons still not square:
none expected 😉

I would tend to merge this PR. If there is a fix for the MacOS style stuff it can be fixed by a bug PR.