A Moogle  🏳️‍🌈 💻 🎮 🎶 🇸🇪

To actually be pointed about it, such a bar for contributing a simple, one-off fix to a project is exactly the sort of gatekeeping that the purported open-source "community" could do with less of. And if that's the bar I have to hit, I'll happily just use Sony VEGAS Pro.

Oh, totally agree, 100%. I find I have to go to IRC a lot to get anything happening in open-source. (Formerly on the KDE Usability Team)

Yeah, I'm tearing my hair out at this point. I *had* a manual ZIP-download clone of the Kdenlive repo compiling for the past 2 hours or so in Qt Creator, and I was able to iron out the bug I'm trying to fix. But...

...after cloning the repo properly via git, following what I *thought* were the same steps to import its CMakeLists.txt into QtCreator, I get 7600+ errors where it acts like it's trying to compile/link C++ code as C. So I'm back to square one of even being able to build Kdenlive.

Is the bug in the older windows version of kdenlive? I remember one of the early versions I used was okay but the new ones on Linux were more broken.

As I understand it, the Rotoscoping effect is somewhat new. It would appear that the bug comes as a side effect from how keyframes for the effect are serialized into a JSON document: QJsonDocument has a fromVariant function which takes a QVariantMap to construct an object.

QVariantMap is effectively a map which uses QStrings as keys, so KeyframeModel::getRotoProperty string-ifies the raw frame index of each keyframe for the key. Problem is, the width parameter for the rightJustified is miscalculated.

1-digit frame indices get 0-padded to 2 digits with a leading 0, but 3-digit frame indices and up are unchanged. As the ordering in QVariantMap is based on the ordering of the keys, the keyframes end up serialized into JSON, and written into the project XML, out-of-order.