Workspace: Refactor complete code to use a QStyledItemDelegate for the list

[kiozen]

Here we go! What adds more fun to a QStyledItemDelegate in the map and DEM lists? Right! Adding another one in the workspace list aka CGisListWks. This is already a huge code change just to produce a mockup!

It's again on the testing_stuff branch of my development fork (https://github.com/kiozen/qmapshack/tree/testing_stuff).

Warning! This messes up your workspace data base. Either wipe the workspace when switching between dev and this branch or make a safety copy of your workspace.db.

Despite the complete pain in the ass to convert the code to a delegate and finding a lot of crude stuff that crept in and has to get fixed before proceeding, the charm of the whole exercise is to have quite some freedom in how to design each item. And yes, yes, drag-n-drop and the whole shit is working better to.

So, what's the result? A lot of broken stuff for sure. Some bugs fixed, a lot more introduced 😁 .But we got rid of columns not fitting the view and that horizontal scrollbar 🎉 . Having more freedom to place tool buttons wherever I want I added 4! Crazy! The one with the eye is replacing the former checkbox.

The other three add functions from the context menu right into the UI. Probable most of you are not aware of these functions or simply forgot about them or ignoring them. Which is a pity as they are real cool features of QMapShack deserving a bit more attention. These are: auto save, auto sync. with GPS devices and active project. Active project is a very useful feature when planning stuff. If an active project is selected everything that usually requires the user to select a project simply use that project without asking.

Right now the items are quite large in terms of their height. This is because there will be extra information like rating and tags. And you will notice that with a delegate it's quite easy to highlight text for items in focus or to gray out stuff that's not visible. Even with it's limited functionality the mockup is already a gain in my eyes.

If you test please be selective with bug reports. Cross check if the same bug is in the dev branch -> bug ticket please. If not differentiate between missing feature and the feature behaves really buggy. The later is of interest.

Looking forward to your feedback!

[JFritzle]

Geosearch not yet working and usable with testing_stuff. Switching it on and off results in
[QMS] 2026-01-31 10:03:48.516 [warning] QObject::connect(QLineEdit, CGeoSearch): invalid nullptr parameter
and may make QMS crash.

Screenshot ...

... is showing following issues:

1. Geosearch neither ported to new design nor currently usable at all
2. White text on a light grey background is really hard to read
3. In my opinion, vertical distance between track/route/waypoint items too large and is wasting precious space

[JFritzle]

Program crashing immediately at start, obviously due to geosearch enabled before closing previous session:

Qt6Core!QObjectPrivate::connectImpl+0x2f4   
Qt6Core!QObject::connectImpl+0x2bb   
qmapshack!QObject::connect+0x69   
qmapshack!CGeoSearch::CGeoSearch+0x18a   
qmapshack!CGisListWks::slotGeoSearch+0xf4   
qmapshack!CGisListWks::slotLoadWorkspace+0x6d8   
qmapshack!QtPrivate::FunctorCall<std::integer_sequence<unsigned __int64>,QtPrivate::List<>,void,void (__cdecl CGisListWks::*)(void)>::call::__l2::<lambda_1>::operator()+0x10   
qmapshack!QtPrivate::FunctorCallBase::call_internal+0x10   
qmapshack!QtPrivate::FunctorCall<std::integer_sequence<unsigned __int64>,QtPrivate::List<>,void,void (__cdecl CGisListWks::*)(void)>::call+0x10   
qmapshack!QtPrivate::FunctionPointer<void (__cdecl CGisListWks::*)(void)>::call+0x10   
qmapshack!QtPrivate::QCallableObject<void (__cdecl CGisListWks::*)(void),QtPrivate::List<>,void>::impl+0x66   
Qt6Core!QObject::qt_static_metacall+0x15bf   
Qt6Core!QMetaObject::activate+0x84   
Qt6Core!QSignalMapper::tr+0x61f   
Qt6Core!QObject::event+0x68   
Qt6Widgets!QApplicationPrivate::notify_helper+0x151   
Qt6Widgets!QApplication::notify+0x156e   
Qt6Core!QCoreApplication::notifyInternal2+0x101   
Qt6Core!QEventDispatcherWin32::event+0x157   
Qt6Widgets!QApplicationPrivate::notify_helper+0x151   
Qt6Widgets!QApplication::notify+0x156e   
Qt6Core!QCoreApplication::notifyInternal2+0x101   
Qt6Core!QCoreApplicationPrivate::sendPostedEvents+0x203   
Qt6Gui!QWindowsGuiEventDispatcher::sendPostedEvents+0xf   
Qt6Core!QEventDispatcherWin32::processEvents+0x90   
Qt6Gui!QWindowsGuiEventDispatcher::processEvents+0x19   
Qt6Core!QEventLoop::exec+0x1c4   
Qt6Core!QCoreApplication::exec+0x16a   
qmapshack!main+0x85b   
qmapshack!qtEntryPoint+0x30   
qmapshack!invoke_main+0x21   
qmapshack!__scrt_common_main_seh+0x106   
KERNEL32!BaseThreadInitThunk+0x17   
ntdll!RtlUserThreadStart+0x2c   

[kiozen]

yes, yes, this is known. It's a mockup not a PR ready for complete deep testing and review.

So far project and GIS items are implemented by their basic information and functions.

[kiozen]

Now tags and rating for GIS items visible again:

[kiozen]

Next step: Devices

Here is something new. All projects on devices are loaded as invisible by default. You can make them all visible with the visibility button of the device or one by one with the visibility button of each project. If you have many recordings on a device the canvas gets really crowded. It's easier to enable the one track of interest manually.

[kiozen]

Project keywords & GIS item statistics:

[JFritzle]

First mark project:.

Project gets highlighted blue with white text.

Then click somewhere on the map:

Project gets highlighted light grey with white text. Intention?
Project stays grey with white text when clicked anywhere outside from project explorer.

[kiozen]

It should be the same as for any other tree widget e.g. database. At least on my setup it is. If not we need to find out how to get the correct values from the pallet.

[kiozen]

I need some feedback on this. The tool buttons of the project items can be placed in the name or in the status line.

Placing them into the status line has the advantage that they do not collide with very long project names. On the other hand side if you have many keywords they collide with the status line. Personally I would like to have them in the same line as the name as this creates a natural border to the project above:

As I like my project names short and crisp this is not a problem for me but there will be this one user...

Anyways it's a matter of personal taste. You can try it yourself. In CWksItemDelegate.cpp line 33 you can define OPTION to be 1 or 2.

@mitxel-m @kkarsten62 @wthaem @JFritzle and everyone else I would appreciate your feedback.

[JFritzle]

As long as a long project name becomes fully shown in tooltip when hovering over project item, I see no problem with solution 2nd screenshot. Behavior would be comparable to long map/dem names.

In my opinion, it is not a real gain in information to see number of tracks/routes/waypoints in status line, as project's tooltip already contains that information. This would allow more or longer keywords to be visible. Maybe keywords should be included in tooltip too, solving problem long keyword list not being fully visible?

[kkarsten62]

My five cents:

• Very nice feature, makes it more user friendly :-)
• Beside to the workspace.de I need to delete the QMapShack.conf in ~/.conf/QLandkarte as well. Otherwise there was directly a crash after start. I did not debug in detail. Root cause can be in my more or less complex conf, grown over the last years
• I would like to set the buttons in the upper row as @kiozen prefer as well, but I can live with 2nd row as well, as @JFritzle already stated, it should be consistent to maps/dem
• Ordering of the shown buttons from left to right should follow the order from the context menu from top to down
• Buttons should have the same icons then in context menu
• Each button needs a well explaining tooltip
• As @JFritzle already mentioned I need no information to see number of tracks/routes/waypoints in status line as long it is shown in tooltip

@kiozen : Many thanks for the feature and go ahead :-)

[mitxel-m]

Here are my comments:

• It's very useful now with the most frequently used actions available with a single click. :-)
• I agree that it also helps to make some features more visible. (Active Project is a must for me.)
• I think it's necessary to make the new buttons larger, although I know this will conflict with the text of the project name, but for now I have trouble seeing the A and the S, and the Active Project star (once activated) is much less visible than before. I find also strange that the icon that warns about saving a track is larger than the icon for the project.
• I would also keep the yellow color for the active project icon. If I were to change any color, I would change the rating stars (better not too vibrant), so that yellow can be used to keep more visible the Active Project icon (as it is an important feature).
• The second line with the item count is not a must for me, since it can be seen in the tooltip. Too much text makes the panel less clear.
• A little more separation between projects would also help, both in terms of visual clarity and when dragging and dropping to sort projects.

Icons
Since this task is about improving the visual appearance and usability of the UI I have created some new icons for the projects, following the style of the icons on the map and DEM panels to give a more consistent look. Here is a screenshot with the new ones on the left and the current ones on the right:

So

• The main idea is that an icon that takes up the entire space helps to make it look tidier, emphasizing the hierarchy and also the idea that a project is a container.
• The text specifying the format is displayed more clearly, which will be helpful now when the icon turns gray when disabled.
• I have also tried to follow the same color scheme that already existed for each format (new ones above, current ones below):

I'm now giving the .svg files a final review and I can share them here if you like them, or even better, as they are also valid for the current dev branch, I could also make a PR to the current dev branch with the new icons (.svg and .png).

[JFritzle]

@mitxel-m
I prefer your icons. Very nice 👍.

[JFritzle]

What about ...

1. Arrange buttons square ?
   
   (Buttons composed by image editing, therefore blurry)
   Benefit:
   • Project name and keyword strings are cut off at same position
   • More characters from long project names are visbible
2. Make square as large as project icon, i.e. 31 pixels like icons from @mitxel-m ?
   Benefit:
   • Uniform appearance like project icon
   • Allow larger buttons inside square, 15 pixels = (31-1)/2 in contrast to the 13 pixel icons,
     making button icons better readable, e.g. characters "A" and "S" and
     making buttons easier to hit

[wthaem]

• Why not move the new icons to the typically shorter keyword line (with my QMS version, they are already there)? Then, there are fewer cut project names.
• I'm in favor of mitxel-m's icons, too.
• I don't like the square icon layout. My opinion: it is easier to find an icon if all are in one row.

[JFritzle]

Even if in one row, I would prefer larger buttons.

On a 27" monitor with 2560x1440 resolution, measured dimension of buttons in mm
is about 15% less than on a 24" monitor with 1920x1080 resolution.
Size in mm of 13 pixel icon on this 27" monitor is about equal to size of 11 pixel icon on that 24" monitor.
Letters A and S become more difficult to recognize, as @mitxel-m already mentioned.

[kiozen]

@mitxel-m I am always in favor of nice icons. And to make nicer ones than I do is easy. I am an engineer not an artist 😁 PR is the way to go (ticket, change log, etc)! If you want to add better icons in batches simply reuse the ticket in that case.

Placing the tool buttons 😃 I already tried all the stuff you suggested. The initial one was ordering them in a 2x2 square. I don't like it because your eye could not follow columns. With several projects in a row it was a wild mosaic of buttons. That's why I switched to all buttons in a row.

To make these buttons full tool button size is a problem for smaller screens where the workspace docker's size should be as small as possible. Plus this collides with the name and the status line.

Placing them into the status line was my next try. Reasoning: better limit the status than the name. However this does not look nice with several projects in a row (column). The items are not really distinguished from each other by a clear UI design.

That's why I placed them into the upper line of the name. In this line there is more space as the font is larger. Therefore the buttons can be a tiny bit larger, too. And probably the status line (2nd line) will get more crowded in future.

The buttons have the same height and width as the font of the name. I would assume if you can read the name the buttons should be large enough to. Of course the icons have to be more simple. That why I changed them . Maybe it's a good idea to change the ones in the context menu, too.

And, btw, the geo search is back:

[kiozen]

And the project filter is up and running again:

Don't ask me why it's not spanning the full column width. I don't know how to fix that. It's still an item widget because the same widget is used to filter the workspace. And somehow with a delegate sizing seems to be different. I tried everything with layout stretching size hints etc. No effect. I will leave it like that.

All the former function should be back again. Now is a good time for in depth testing.

[kiozen]

Philosophical question: Should a read-only project become active project? It can serve as a bucket for new items. No question. But you will never be able to save it.

Why I ask: Should the active project button be hidden just like the save button for read only projects. And just to move on with the reasoning: Same applies to auto sync to device?

[kiozen]

Any opinions on that?

[kkarsten62]

Philosophical question: Should a read-only project become active project? It can serve as a bucket for new items. No question. But you will never be able to save it.

Read-only Project ==> If I understand right, you mean when a project is locked by using the lock button in Edit/Project in upper right corner?! Or do you mean when the related file is read-only in the OS file system?

Currently you can store new objects (tracks, waypoints) in a locked project. For me it is irritating. For me a locked project means: Keep the project as it is.

• No add, delete or edit of project objects
• No edit of the project properties
• But project can be deleted or copied

In the case that a project is read-only, because related file on OS file system is read-only:
For me it is irritating. When you can not save at the end it makes no sense for me to store objects first. If I need a temp project as a kind of bucket then I will create it and name it accordingly Temp Project.
Same as locked: Keep the project as it is.

Why I ask: Should the active project button be hidden just like the save button for read only projects.

For me yes.

And just to move on with the reasoning: Same applies to auto sync to device?

For me also yes.

And a well explaining tooltip for the lock button in Edit/Project should be added to indicate what are the consequences when pushing the button. Right now there is no tooltip.

I hope it helps.

[kiozen]

Ok, should have specified it a bit more precise. Read only projects are file types we just have a decoder not an encoder, e.g. FIT

The infamous "lock" and "ink spot" is a total different story. And probably a good subject for another UX discussion. It started with a mechanism to detect if an item recorded by a devices was tempered with. Today it's more an indicator how to present an item. locked: in a nice textual way, unlocked with all the edit links active.

But back to the real topic. I also tend to hide the buttons "auto sync", "active project" and "auto save" for file types we can not write like the FIT format.

[kiozen]

Reasoning a bit more all these functions (auto sync, active project and save) make sense even for a FIT project. Just the auto save does not make sense. Save will open a file dialog to get a file name to save to.

I think I leave it as is. After all this is not carved in stone.

[kkarsten62]

I just tested my use cases with the latest commits from branch testing_stuff

• Load a Project from remote MYSQL database
• Remove some tracks and waypoints
• Sync with database
• Create some tracks and waypoints
• Connect my GARMIN Edge 1050 GPS device
• Use Auto-Sync with device
• Edit some Tracks and Waypoints
• Sync with data base
• Use Auto-Save
• ...

==> All is working fine for me :-)

Two suggestions:

1. The upper section of the workspace appears somewhat cramped vertically.
   The Opacity section, Geosearch, and the first project should be visible somewhat more independently. The buttons appear cluttered and too close together.
   If necessary, insert more space vertically between the sections or a horizontal line between them, or use different background colors.

2. The "View All/None" button for the device is smaller than the track buttons. If feasible, adjust it to match their size or make it larger.

[kiozen]

If necessary, insert more space vertically between the sections or a horizontal line between them, or use different background colors.

I donated some extra pixel between items. But in general I would like to keep the condensed layout

The "View All/None" button for the device is smaller than the track buttons. If feasible, adjust it to match their size or make it larger.

Ooops and it's in the status line. Moved it up to the upper line. By that the size should fit the name and thus all other items.

[kiozen]

To keep stuff a bit more consistent the geo search item is now the same size as a project

[kkarsten62]

I tested again - Funcs works as expected with the new icons - I like the new icons from @mitxel-m :-)

Please have a look at Copy to ... feature of Project and Track etc. I do not know if this correlate to the new widget or icons:

1. The window appears in witdh to small, name of the window is cutted
2. Is it a feature to copy to the Search project? Make this sense?

[kkarsten62]

Ohh - sorry ...
I juts see that the OK button is non-active (greyed out) when the GeoSearch project is selected ==> ok for me ...

[kiozen]

On the other hand side it's a good question why the search is added to the list when the ok button is grayed out. But this is an issue we have in dev, too. --> add a ticket and maybe a PR if you like

[mitxel-m]

I've just done a quick test, and I've noticed that the project filter box is not the right height on my screen:

I'd like to take a closer look, but I won't be able to do so for the next 2-3 days.

Other things:

• I also find the space for writing in the geo search a little narrow. Personally, I would make it bigger to make it more readable and comfortable. Perhaps this could be done at the expense of the status line, and the service name could be shown with a tooltip.

• I still think it would be better to keep the active project icon as a yellow star, rather than a red one, For me, it's not a question of aesthetics but of ease of use.

Let me explain: I think you should be able to see at a glance which project is active, and that's easier with the yellow star, as it's a unique icon, ( even better if it is in the most left position).

However, with the red star, we'll have a red icon next to other icons with red marks (if synchronization and the automatic function are disabled) and they're not very big either. First of all, this forces you to pay more attention, but there is also a contradiction: in most cases, red means disabled, and in the active project, red means enabled...

I know that the active project also has bold letters, but that doesn't change the above.
If the reason is to avoid clashing with the yellow rating stars, I would change the rating stars; any color that is not vibrant would work well.

If you want, I can take a look at those icons next week.

These last things are not about functionality but about making the UI more comfortable.

[kiozen]

The project filter is already fixed. Event in it's width. I found the culprit.

The GeoSearch line edit I can make a bit larger. Will do.

The red star ⭐ 😄 I changed it because the yellow is so close to the gray of the inactive projects. The red is more visible for me. Maybe a star is a bad choice. Maybe a circle is better. I will give it a try.

[kiozen]

It's a circle now. After all you can change it by replacing the icons Focus.svg and UnFocus.svg.

Line edit is now a bit larger.

[kiozen]

Still think red is the better choice.

[kiozen]

I added the mitigation code to migrate "old" workspace to new one. Other way around is not possible - as usual.

[mitxel-m]

Ok, I will take a look too. I think that #ffff00 should look well even over gray. If needed the trick is to draw the star with a 1px black border and #ffff00 fill. This is fine tailoring :-) 2026(e)ko otsailaren 6(a) 16:54:23 (CET)-(e)an, Kiozen ***@***.***>-(e)k hau idatzi zuen:

…

The project filter is already fixed. Event in it's width. I found the culprit. The GeoSearch line edit I can make a bit larger. Will do. The red star ⭐ 😄 I changed it because the yellow is so close to the gray of the inactive projects. The red is more visible for me. Maybe a star is a bad choice. Maybe a circle is better. I will give it a try. -- Reply to this email directly or view it on GitHub: #943 (reply in thread) You are receiving this because you were mentioned. Message ID: ***@***.***>

[kiozen]

I pushed another change hiding most of the buttons for projects when not selected.

With all these buttons the UI gets a bit overloaded. Sure it's nice because you have all the functions by a single click. On the other hand side there are so many buttons, you hardly know where to click.

Now you have to click on the project first to get all buttons. Following the design rules of the canvas: "click on an item to get information and available functions". I left the "Visibility" button as a static one.

Con:

• You need one more click to get the choice. But imho better than cruising the context menu

Pro:

• Less noise on the UI
• We can add more buttons! And more is always good. 😝

@mitxel-m your yellow star is back! ⭐ twinkle, twinkle. Because without all this visual noise it's easy to see what project is the active one. Regardless what color the star is. So I do not mind if I can't really tell the difference between a yellow and a grey star in a button 😎

[kiozen]

Ok, the code is more or less ready to be merged. Last call for bugs 🐛

[kkarsten62]

I tested this afternoon. For me ok to merge. Great job - many thanks for this nice feature ...

[mitxel-m]

After a few days away, I have managed to try out the latest changes and they work well for me. In my opinion, the latest change, where the buttons are only displayed when you select a project, is a good idea, because it makes the workspace look lighter and less cluttered.

The only downside for me is that I still have trouble reading the A and S buttons on my screen because they are too small, but this is an issue with my computer that does not affect their function :-). I will try to take a look at the corresponding icons to see if I can improve anything, but there is not much margin for adjustment at this size.

Next, I am going to test the PR regarding the database panel too.

Thanks for all your work!

[kiozen]

Increase the font :)