Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

customizable toolbars #3259

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from
Open

customizable toolbars #3259

wants to merge 1 commit into from

Conversation

adipose
Copy link

@adipose adipose commented Feb 1, 2025

This implements toolbars that can have dynamic elements between the first three "static" toolbar elements, and the volume button at the end.

The SVG is based off my old idea of 4 rows active/inactive/active dark/inactive dark (I forget the exact order). However, the svg is designed to support up to 32 buttons eventually, and is sized accordingly.

The customization works by using the CToolbar drag and drop. It's pretty basic, but you can drag a button off the toolbar to delete it, and drag it left and right to drop it elsewhere. I need to see about the newer (mfc) toolbar capabilities, but given that it always used CToolbar, I thought this would be simplest.

The save and load of the toolbar sequence is implemented.

Adding buttons back to the toolbar can currently only be done through the double click customize dialog. That dialog is not themed and also allows adding separators back (we don't want this). If that can't be fixed we can have an simple dialog to adjust the toolbar.

See what you think. This does not merge due to being designed prior to recent toolbar changes.

@clsid2
Copy link
Owner

clsid2 commented Feb 1, 2025

Can you make a test build?

Since the reserved buttons are in the middle of the image, we can't use the image width as an indicator of how many buttons are valid. But perhaps that info could be passed through filename/foldername of an external toolbar. Like "button_bc15.svg" where bc15 means button count 15.
But I think it is better to just avoid all that extra complexity by having designers make a large list of buttons, even ones that we might not actually use yet in short term, but might possibly in more distant future.
For exotic actions users will need to use the generic buttons anyway, and new buttons for common stuff can be determined beforehand.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants