Create user defined ToolBar and Menu #64357

troopa81 · 2025-12-19T08:10:21Z

This implements #QEP343 and embeds preliminary work #64325

It allows user to create user defined menu and toolbar.

Funded by Stadt Frankfurt am Main

github-actions · 2025-12-19T09:00:36Z

🪟 Windows Qt6 builds

Download Windows Qt6 builds of this PR for testing.
(Built from commit 45e611b)

🍎 MacOS Qt6 builds

Download MacOS Qt6 builds of this PR for testing.
This installer is not signed, control+click > open the app to avoid the warning
(Built from commit 45e611b)

nyalldawson · 2025-12-19T11:24:14Z

I don't particularly love the two toolbar approach used here. @nirvn have you any thoughts?

uclaros · 2025-12-19T13:52:47Z

I don't particularly love the two toolbar approach used here. @nirvn have you any thoughts?

The plus and trash icons could also be replaced by actions in the context menu.

It would also help with usability if focus was automatically switched to the newly created toolbar/menu entry.

Is the second search box intentionally disabled? I can imagine it being useful when looking for items to add.

02JanDal · 2025-12-29T22:03:15Z

Looking forward to this feature, it's something I've often heard requests for!

I think that from an end-user perspective the UX would be a lot more approachable if the object names (m*) would have less emphasis (at least switching name and label columns, but I think best would to remove the object name column entirely (the object name can still be shown in a tooltip for those who do need it)).

Also, while having D&D is really nice that's sadly a UX that's "invisible" and thus something users might overlook (I just recently had to explain the drag and drop form designer to a user, which even has "drag and drop" in the name...). A common solution is having button(s) between the two lists, like in QgsLayerTreeEmbeddedConfigWidget.

troopa81 · 2026-01-05T16:29:05Z

I don't particularly love the two toolbar approach used here. @nirvn have you any thoughts?

Right, I'm gonna migrate the other buttons in the first one

The plus and trash icons could also be replaced by actions in the context menu.

Why not having both ?

I like buttons because it explicitly indicate to the user how he can add/remove a user menu/action. And the button is greyed out if it's not possible to add/remove which is also a valuable information for the user.

It would also help with usability if focus was automatically switched to the newly created toolbar/menu entry.

👍 will do

Is the second search box intentionally disabled? I can imagine it being useful when looking for items to add.

It's an issue, I will fix it

troopa81 · 2026-01-05T16:33:06Z

I think that from an end-user perspective the UX would be a lot more approachable if the object names (m*) would have less emphasis (at least switching name and label columns, but I think best would to remove the object name column entirely (the object name can still be shown in a tooltip for those who do need it)).

I thought about removing this column and display only label text (and display name when there is no label text), but I didn't want to change too much the actual display. @uclaros @nyalldawson any opinion on that?

Also, while having D&D is really nice that's sadly a UX that's "invisible" and thus something users might overlook (I just recently had to explain the drag and drop form designer to a user, which even has "drag and drop" in the name...). A common solution is having button(s) between the two lists, like in QgsLayerTreeEmbeddedConfigWidget.

Right. Will do it.

Customization is now read from an XML file so we can later keep track of action order in menus and tool bars. This XML file is read on a tree model where every node is an Item. Item is then inherited by any customizable widget item. read() methods reads the XML file into the model. load() update the model with the different graphical element and apply() apply the model to the QGIS main window and the 2 browser widgets.

Instead of tracking down the modification, we just clone the model and restore on reset. On apply, the model is set in the application

Any owned function exists in sFunctions list so we have to remove it from the sFunctions list. If not, when deleting/recreating QgisApp (in tests for instance), cleanRegisteredFunctions() is called and let with dangling expression functions pointer.

troopa81 · 2026-01-07T13:40:32Z

Also, while having D&D is really nice that's sadly a UX that's "invisible" and thus something users might overlook (I just recently had to explain the drag and drop form designer to a user, which even has "drag and drop" in the name...). A common solution is having button(s) between the two lists, like in QgsLayerTreeEmbeddedConfigWidget.

Right. Will do it.

@02JanDal After a second thoughts I don't think button would play nicely here. User would have to:

Select the action(s) he wants to add,
The menu/toolbar he wants to add them into,
And finally click the button.

It seems a little bit convoluted to me. We can maybe print a message in the status bar when user choose to open the action panel to indicate that user can drag'n drop the actions in menu/toolbar.

02JanDal · 2026-01-07T13:49:08Z

It seems a little bit convoluted to me. We can maybe print a message in the status bar when user choose to open the action panel to indicate that user can drag'n drop the actions in menu/toolbar.

Hm, that's indeed true, having multiple "targets" does make that pattern maybe even more confusing...

Maybe just a simple label with some basic instructions could work?

uclaros · 2026-01-07T14:31:52Z

The plus and trash icons could also be replaced by actions in the context menu.

Why not having both ?

To avoid the double toolbar that Nyall mentioned above. I'm not against the buttons, it's just that their location is weird. Maybe if the three new buttons were moved to the master toolbar it would be better.

I think that from an end-user perspective the UX would be a lot more approachable if the object names (m*) would have less emphasis (at least switching name and label columns, but I think best would to remove the object name column entirely (the object name can still be shown in a tooltip for those who do need it)).

I thought about removing this column and display only label text (and display name when there is no label text), but I didn't want to change too much the actual display. @uclaros @nyalldawson any opinion on that?

Since there are both entries without a name and entries without a label, we probably should keep both! Maybe the label could be placed first as it makes more sense to most users.

troopa81 · 2026-01-07T17:29:27Z

Maybe if the three new buttons were moved to the master toolbar it would be better.

Done

Maybe just a simple label with some basic instructions could work?

for now, I just added tooltips on action panel visibility button and on action tree view. I'm not sure about adding an extra label somewhere, I'm afraid it look a bit odd/clumsy.

Since there are both entries without a name and entries without a label, we probably should keep both! Maybe the label could be placed first as it makes more sense to most users.

I failed to find entries without name (and that could be overcome easily by just settings a name) while there are some entries without label. IMHO it would be weird to have a first column empty.

Any other UI comment have been taken care and I updated the screencast

uclaros · 2026-01-07T21:14:43Z

I failed to find entries without name (and that could be overcome easily by just settings a name) while there are some entries without label. IMHO it would be weird to have a first column empty.

troopa81 · 2026-01-08T13:14:10Z

@uclaros Thank you for pointing this out. Action with no name cannot be referenced in user defined menu or toolbar. I'm planning to add a CI test that check that any application action has an objectName to solve the issue. What do you think?

troopa81 added Feature GUI/UX Related to QGIS application GUI or User Experience labels Dec 19, 2025

github-actions bot added this to the 4.0.0 milestone Dec 19, 2025

troopa81 added 8 commits January 6, 2026 09:45

fix(Customization): fix cppcheck and spellcheck

aefe967

fix(Customization): fix CI

38f4909

style(Customization): Make things private, not protected

43d64ba

refactor(Customization): Rewrite the reset/apply mecanisme

5f27044

Instead of tracking down the modification, we just clone the model and restore on reset. On apply, the model is set in the application

fix(Customization) fix missing icons

c98b80d

style(Customization) replace QStringLiteral/QLatinString with _s _L1

aba0fa0

feat(Customization): Implement user defined menu and toolbar

45e611b

troopa81 force-pushed the feat_customize_toolbars branch from 8add6c8 to 45e611b Compare January 7, 2026 15:22

Uh oh!

Create user defined ToolBar and Menu #64357

Are you sure you want to change the base?

Create user defined ToolBar and Menu #64357

Conversation

troopa81 commented Dec 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions bot commented Dec 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🪟 Windows Qt6 builds

🍎 MacOS Qt6 builds

Uh oh!

nyalldawson commented Dec 19, 2025

Uh oh!

uclaros commented Dec 19, 2025

Uh oh!

02JanDal commented Dec 29, 2025

Uh oh!

troopa81 commented Jan 5, 2026

Uh oh!

troopa81 commented Jan 5, 2026

Uh oh!

troopa81 commented Jan 7, 2026

Uh oh!

02JanDal commented Jan 7, 2026

Uh oh!

uclaros commented Jan 7, 2026

Uh oh!

troopa81 commented Jan 7, 2026

Uh oh!

uclaros commented Jan 7, 2026

Uh oh!

troopa81 commented Jan 8, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

troopa81 commented Dec 19, 2025 •

edited

Loading

github-actions bot commented Dec 19, 2025 •

edited

Loading