First, I think limiting the recent colors to just 4 is better.
But not just any four right? The 4 most frequent, or the 4 most recent, or the 4 most saturated. So, someone will ask for an option to control those 4.
if the tooltips for the icons in the toolbar be updated to include the shortcut keys
Doing it the easy way breaks translations. There is probably another more difficult way that requires more code. One can simply look in the view menu now.
I think it would make the most sense to place Markers after Timeline.
Visually, that makes sense except the current order follows the order of the shortcut keys along the keyboard. So, your suggestion would break that unless one perceives Ctrl+Shift+6 as logically before Ctrl+6.
There is nothing in the UI that suggests these are “recent.” You only got that impression by reading the source code or its commit messages. I never got that impression. To me they are simply what I have chosen previously in this project. So, once colors start not appearing, someone will report a bug that a color they chose previously is not in the list. You explain “recent” and they report it as random because when I did X with a marker with color Y, that color was not made more recent. Now, you need to explain all the rules of what updates the recency of a color.
With this specific case, users will pick up on the fact that those are the most recently used colors. It will just come to them with experience. I really don’t believe that anyone will ever misreport this as any kind of bug because they will realize that if the color they want isn’t among the 4 then that’s what the “Other…” choice is for. That’s why I think it’s also important to not bury the “Other” option so that it’s the first thing the user sees.
Also, maybe “Other” can be given a different name like literally “Menu” or something like that? So then the user will read on the context menu “Color” then to the right of it “Menu”.
I kind of agree with Dan’s comments. We should not overthink this or make it overly complicated. I do not know the use case for having so many colors. And it is easy to scroll the menu with the mouse wheel to access the “Other” option.
The search only applies to the text. If you want to group the colors together, click on the header for the color column and all the colors will be grouped together.
Somehow Shotcut has to know when the user is done editing. The options are:
Update the setting with every small change (current behavior)
Update the setting when the control loses focus (tab to move to the next control)
Add an “Apply” button.
I do not want to add an Apply button because that requires extra operations to make a change. I am unsure if requiring to tab out of the control is good. Will people understand that?
Well, there was a user here that literally said he likes having every marker be a different color:
This isn’t overthinking the issue, actually. It’s really about what the main point of putting the Color option in the context menu was about which was to get to the full color menu faster than going through the Edit menu and having to hit Okay twice to get back to the timeline. Picking from recent colors is actually an addition that came from the discussion in the above user’s thread. It can work nicely but quickness and having the least amount of movement to change a marker’s color needs to be kept in mind.
I also suggested limiting the recently used color list to a number like 4 because if the list gets so long that the user needs to start scrolling then at that point they might as well be at the full color menu but then to get there they need to click on “Other” which has been buried.
Is it possible to not have the “Other” option be lowered down and stay on the same line as “Color” while the recently used colors just go on top of it?
@brian, if the issue has to do with not wanting to complicate the coding of the context menu for Markers, the other option is to just ditch the whole “recent colors” submenu list and just have Color option take the user directly to the full colors menu. That was the original suggestion after all.
Ok let’s try to simplify this recent suggestion. When choosing a new marker color and there are already 4, one is to be removed. Which one? Would we need to keep track of every time someone clicks a color menu item as recent relevancy instead of simply removing the one at the top?
If it’s going by the most recent it would follow that the oldest one gets removed when a new color is picked.
I’m not too sure what you’re asking. If you’re asking something like if the order of the recent color list should change every time a color on the recent color list is picked then in my opinion no. I think what colors are on the color list and the order they are in should entirely be according to what’s picked in the full color menu. So if the user has their 4 favorite colors but wants to put blue as the most recent on the list and not the oldest, then they would have to pick that blue in the full color menu to rearrange the recent color list. If they pick blue from the recent color list it just stays where it is already in the list.
See you’re still not defining recent or age or misunderstanding mine. I’m not talking about order of menu items, but that raises another dimension. You are basing age and recency upon choosing OK in the color dialog after choosing Other. Many people will think “recently used” where used can be picking a color menu item or even possibly when choosing a previously used color in the edit dialog/form’s color dialog!.
Or through the Edit menu or the Markers dock. In my mind all those three paths (context menu, Edit Menu, Markers dock) lead to the same full color menu dialog.
You mean picking any color from anywhere? Like picking a color for font or background in Text: Simple and have that show up in the recent colors list for markers? If so, then no. That recent color list is only for Markers so it should just be what the last color for a marker that was chosen was from the full color menu dialog.
I think you are hinting about the difference between “most recently used” and “most frequently used”.
I have been trying to find a way to do this, but the GUI framework does not provide a way. It stubbornly aligns to the top - unless the menu does not fit in the panel in which case it aligns to the center. I can move “Other…” to the top of the menu, but that does not help when the menu does not fit in the panel.
Ah, so you’re pointing out a use case where the most recent color should also be according to what’s been picked in the recent color list. Cause in your scenario, if blue was being used a lot but it was several picks ago that blue was added, then after the limit blue would then be removed even if the user was using it a lot. Yeah, I see that now. I agree then. The recent color list should also go by what’s been picked in the recent color list.
If we choose a 4 color limit, someone will request 5. Then 6. I think we should try it without a limit. The menu scrolls very easily even with many colors in it. When Shotcut is closed and reopened, the list is reloaded only with colors that are currently in use by a marker. So if the user tries many colors and clutters the recent color list, it will be cleaned up when they restart Shotcut.
Picking a color from Recent Color doesn’t update the default color when pressing M. So if blue is set when M is pressed but the user picks red from Recent Color the next time the user presses M the marker will still be blue instead of the expected red.
I think that the order of Recent Color and Other Color should be switched. The Recent Color list is updated according to what’s chosen in Other Color. When a marker is put down for the first time but the user wants to change the color Recent Color will be useless at that time because there is no other color to pick from until the color is changed in either Edit or Other Color. So it would make sense for Other Color to come before Recent Color.
It will be great if ripple edit can apply to the markers.
It’s inconvenience that if you edit the video while there are number of markers, you need to manually adjust each markers after the edited part.
To choose from the complete colors menu if the one the user wants isn’t in the recent colors list.
With that the limit of colors doesn’t have to be just 4. What number limit would you set then?