Openshot-qt: Properties for transitions are not visible in daily build

[rexdk]

Daily build from 29Oct20
Win 10

Right click on a transition on a clip; choose properties. The properties panel shows but there are no longer any transition properties there (eg no Brightness, Contrast etc). Something has changed I think - it's been working fine, eg with a daily build from July.

[ferdnyc]

That's gotta be my fault. I'll take a look thanks.

[ferdnyc]

@rexdk
Hmm. No, works OK for me with the current develop branch code under Linux.

Can you reproduce, then post your openshot-qt.log file? There's probably a Python traceback in there that will point to the location of the bug.

[rexdk]

1.delete log files
2.. open openshot

1. import an image
2. add to timeline and extend length
3. drag transition to end of image
4. right click on transition > Properties
5. no properties shown
6. close openshot without saving

log files and screen shot attached

Sorry to burden you - again ;)

libopenshot.log
openshot-qt.log

[rexdk]

just checked - my daily build is 25 Oct I think, so possibly it was found and fixed after that?

[ferdnyc]

@rexdk
Very possible, that code has been changing some lately.

Ah! Yes, you managed to grab a Daily Build generated during a (hopefully brief) interval when I was a dumbass and merged broken code:

07:48:53 ERROR exceptions: Unhandled Exception
Traceback (most recent call last):
  File "C:\Program Files\OpenShot Video Editor\windows\models\properties_model.py", line 105, in update_item_timeout
    t = get_app().window.timeline_sync.timeline.GetTimelineEffect(item_id)
AttributeError: 'Timeline' object has no attribute 'GetTimelineEffect'

That was fixed the next day, with 4d6b05d9efa42223b279849cb9d3a31bdb48e38f. Any build generated after October 26 should have the fix.

[rexdk]

Rats! - sorry to bother you then. The trouble with daily builds is - well they're daily - hard to keep up. I'll check it later, but will close this one now

[rexdk]

@ferdnyc of course the problem with updating to the latest daily build is that it might not work... The 6Nov one I've just tried either pauses during a video or crashes - I guess having 2 hourly versions/corrections indicates something is not quite right :)
But it's difficult if you want something that actually can be used. I might have to go back to July, because Github doesn't put a date on whichever version was 26Oct

[ferdnyc]

@rexdk Two versions in one hour just means that two PRs were merged during that hour, no more no less — a build is auto generated for each update to the repo. :grinning:

But it's difficult if you want something that actually can be used. I might have to go back to July, because Github doesn't put a date on whichever version was 26Oct

Yeah, that can be frustrating. The date is actually present in the filenames — but in the form of a UNIX epoch timestamp, so effectively "useless" for any practical purposes. There have also been a _lot_ of builds since then.

But the builds that were generated directly off the merge of #3789 (the PR for 4d6b05d9efa42223b279849cb9d3a31bdb48e38f), meaning the ones with the fewest changes from Oct. 25 other than that issue being fixed, are these:

OpenShot-v2.5.1-dev2-1603696643-07a447c9-46debb51-x86_64.AppImage
OpenShot-v2.5.1-dev2-1603696750-07a447c9-46debb51-x86.exe
OpenShot-v2.5.1-dev2-1603696751-07a447c9-46debb51-x86_64.exe
OpenShot-v2.5.1-dev2-1603696978-07a447c9-46debb51-x86_64.dmg

[ferdnyc]

(And then anything at https://github.com/OpenShot/openshot-qt/releases/tag/daily that's labeled with a timestamp N that's higher than 1603696643 is (N - 1603696643) seconds further into the future.)

[ferdnyc]

(The two strings after the timestamp are the commit tags for the libopenshot and libopenshot-audio builds, respectively, that are incorporated into the build. So from a stability / feature-parity perspective, what you want to watch out for _in particular_ is any change in those strings. A new libopenshot build always has the potential for the biggest impact on OpenShot — it can be a bit of a gamble whether that takes the form of either greatly improving things, or greatly destabilizing them.)

[ferdnyc]

And this conversation inspired an idea for how we can at least transform those filenames so that all build files have the _same_ (cryptic) filename, instead of having slightly-differently-timestamped ones. #3828 and its companion PRs in the other two project repos are submitted to hopefully make that a reality.

[rexdk]

@ferdnyc Thanks for all that - very helpful :). I'll update to 26Oct for the time being.

[rexdk]

yep that fixed it thank you