This is not a new problem and is intermittent. I need to spend more time on this, but fixing may require changing every filter UI, and this might not be done for the next release, which has some much more critical bug fixes to get out.
I do not reproduce this, and there might be something about your OS display or text size that is affecting this. Qt Quick, which is used for the UI is supposed to account for these sort of OS settings to prevent this, but this filter integrates some custom C++ widgets that may be affecting things.
That’s why I’m using the workaround I mentioned in another post.
The problem with this workaround is that it simply adds 150 to every filter UI’s (ui.qml) declared width. That is what we call a “fudge factor” and is not acceptable because then developers unknowingly start to configure the declared width with this constant in place and not remembering about it. Suddenly, you are back in the same place because, for example, something that should have been 450 is now configured as 300.
The problem with simply increasing the width and height of this filter is that it simply makes the custom circular control larger and require more space.
In qml/filters/color/ui.qml , can you please experiment with the lines that set implicitWidth for each ColorWheelItem? Maybe it needs something like -20 appended to each one because the current expression does not factor in scrollbars that might be showing.
--- src/qml/filters/color/ui.qml
+++ src/qml/filters/color/ui.qml
@@ -235,9 +235,9 @@ Item {
// Row 3
ColorWheelItem {
id: liftwheel
Layout.columnSpan: 3
- implicitWidth: parent.width / 3 - parent.columnSpacing
+ implicitWidth: parent.width / 3 - parent.columnSpacing - 20
implicitHeight: implicitWidth / 1.1
Layout.alignment : Qt.AlignCenter | Qt.AlignTop
Layout.minimumHeight: 75
Layout.maximumHeight: 300
@@ -271,9 +271,9 @@ Item {
}
ColorWheelItem {
id: gammawheel
Layout.columnSpan: 3
- implicitWidth: parent.width / 3 - parent.columnSpacing
+ implicitWidth: parent.width / 3 - parent.columnSpacing - 20
implicitHeight: implicitWidth / 1.1
Layout.alignment : Qt.AlignCenter | Qt.AlignTop
Layout.minimumHeight: 75
Layout.maximumHeight: 300
@@ -307,9 +307,9 @@ Item {
}
ColorWheelItem {
id: gainwheel
Layout.columnSpan: 3
- implicitWidth: parent.width / 3 - parent.columnSpacing
+ implicitWidth: parent.width / 3 - parent.columnSpacing - 20
implicitHeight: implicitWidth / 1.1
Layout.alignment : Qt.AlignCenter | Qt.AlignTop
Layout.minimumHeight: 75
Layout.maximumHeight: 300
I do this.
I remove +150 in shotcut/qml/views/filter/filterview.qml
Here is with original files (qml/filters/color/ui.qml)
Here is with your modification (add - 20 for each ColorWheelItem)
There is no modification for the horizontal scrollbar, but the vertical scrollbar allows lowering down and the wheels are smaller.
This is fixed for the next version.
Have you tried with the French language?
I just did the test with the English language and it’s OK.
Since the text in French is longer than the text in English, can this have an impact
Ah hah! Now, I did and reproduce it. Yes, the row of colorwheel labels has a minimum width requirement that is not satisfied. The following fixes it for me:
--- src/qml/filters/color/ui.qml
+++ src/qml/filters/color/ui.qml
@@ -24,10 +24,10 @@ Item {
property var defaultParameters: ['lift_r', 'lift_g', 'lift_b', 'gamma_r', 'gamma_g', 'gamma_b', 'gain_r', 'gain_g', 'gain_b']
property double gammaFactor: 2.0
property double gainFactor: 4.0
property bool blockUpdate: true
- width: 520
- height: 300
+ width: 620
+ height: 350
Component.onCompleted: {
if (filter.isNew) {
// Set default parameter values
Here are 2 more things fixed not mentioned here:
- autosave not working
- very poor audio quality of Reverse… MP4 and MKV options
This is fixed for the next version.
1 Like
Does this fix also cover this bug when it happens with the mouse scroll wheel? @Namna had reported it before a couple of times here in this thread and also made a whole thread devoted to it here. I also have had the very same problem of two keyframes being created side by side when trying to create a new keyframe by scrolling the mouse wheel up and down.
No, it does not, and it is not the scroll wheel specifically; it is changing the value when frame-dropping is enabled. I just fixed it for the next version.
For me too
Thank you Dan
It seems the auto save feature is no longer working. The last files saved in the autosave folder are dated June 2, 2019. Since then no files have been added to that folder. I believe auto save was working in 19.04-30.
The autosave on crash seems to be working. Before the Beta every time a project was saved a copy of some sort was written to the autosave folder. It’s not happening anymore.
Hi, Archlinux user here compiled from git r3227.1560136583.a926d799-1 r3227.1560136583.a926d799 So this may or may not be relevant (today’s build). I also tried with the current package 19.04.something and I still have the problem.
Simple bug report: Scopes not displaying. I had a problem with the audio waveform scope and it would crash without fail. So, audio waveform crashes the program. Tried multiple times.
This is a bigger problem, now none of my scopes are displaying, and video histogram is essential to a documentary project I am working on currently.
Is my .mlt broken? From trying the broken audio waveform scope. Or is it a wider problem with this build?
EDIT: It’s kind of working now. I’m not messing with it. These are fairly big projects with 12 tracks and maybe two or three hours total in the timeline.
A bouquet as well! Loving the new quick shortcuts for all the major controls (filters, properties, all that stuff). Getting around quickly in the UI is a major bonus for me. Thank you thank you! 
When the radius control in the Crop: Circle filter is put at 100%, black edges in all four corners are still visible. Can this be tweaked so that at 100% there is no black edges visible? Also, for both new Crop Filters, can a decimal point be added to give more control (e.g. 100.0%)?
Also, I am not sure if this is a bug but the behavior seems strange. I was moving multiple clips by turning on both Ripple & Ripple All. When I take the 1st clip and move it on top of the second clip then all clips move accordingly as expected. But if I take that 1st clip and move it beyond the 2nd clip all clips move backward not forward. I made a demo to show what I mean here. I move the 1st clip on top of the 2nd clip two times. Then on the 3rd time I move the 1st clip beyond the 2nd clip and all clips move in the opposite direction:
That was a bug you are calling a feature. It is not supposed to behave like that and just keep eating disk space. It is only supposed to keep one copy of a project in autosave - not a new copy every 30 seconds!
My bad. Thought I discovered a new feature.