v2.4.3 will not start

[ghost]

Describe the bug

when I launch the application from the terminal I get this that follows:

openshot-qt Loaded modules from installed directory: /usr/lib/python3/dist-packages/openshot_qt launch:INFO ------------------------------------------------ launch:INFO OpenShot (version 2.4.2) launch:INFO ------------------------------------------------ app:INFO openshot-qt version: 2.4.2 app:INFO libopenshot version: 0.2.0 app:INFO platform: Linux-4.15.0-34-generic-x86_64-with-Ubuntu-18.04-bionic app:INFO processor: x86_64 app:INFO machine: x86_64 app:INFO python version: 3.6.6 app:INFO qt5 version: 5.11.1 app:INFO pyqt5 version: 5.11.2 language:INFO Attempting to load qt_it_IT.UTF-8 in '/home/luigi/.local/lib/python3.6/site-packages/PyQt5/Qt/translations' language:INFO Attempting to load qt_it in '/home/luigi/.local/lib/python3.6/site-packages/PyQt5/Qt/translations' language:INFO Attempting to load it_IT.UTF-8/LC_MESSAGES/OpenShot in '/usr/lib/python3/dist-packages/openshot_qt/locale' language:INFO Attempting to load it/LC_MESSAGES/OpenShot in '/usr/lib/python3/dist-packages/openshot_qt/locale' language:INFO Successfully loaded it/LC_MESSAGES/OpenShot in '/usr/lib/python3/dist-packages/openshot_qt/locale' language:INFO Qt Detected Languages: ['it', 'fr'] language:INFO LANG Environment Variable: it_IT.UTF-8 language:INFO LOCALE Environment Variable: it_IT language:INFO Skipping English language (no need for translation): it_IT.UTF-8 language:INFO Skipping English language (no need for translation): it_IT project_data:INFO Setting default profile to HDV 720 24p app:INFO Setting font to /usr/lib/python3/dist-packages/openshot_qt/images/fonts/Ubuntu-R.ttf logger_libopenshot:INFO Connecting to libopenshot with debug port: 5556 app:INFO Setting custom dark theme exceptions:ERROR Unhandled Exception Traceback (most recent call last): File "/usr/bin/openshot-qt", line 11, in load_entry_point('openshot-qt==2.4.2', 'gui_scripts', 'openshot-qt')() File "/usr/lib/python3/dist-packages/openshot_qt/launch.py", line 70, in main app = OpenShotApp(sys.argv) File "/usr/lib/python3/dist-packages/openshot_qt/classes/app.py", line 159, in init from windows.main_window import MainWindow File "/usr/lib/python3/dist-packages/openshot_qt/windows/main_window.py", line 43, in from windows.views.timeline_webview import TimelineWebView File "/usr/lib/python3/dist-packages/openshot_qt/windows/views/timeline_webview.py", line 40, in from PyQt5.QtWebKitWidgets import QWebView ModuleNotFoundError: No module named 'PyQt5.QtWebKitWidgets'

and the program is waiting, to close it I have to do CTRL + C with these results before the prompt ^C logger:ERROR Exception ignored in: logger:ERROR <module 'threading' from '/usr/lib/python3.6/threading.py'> logger:ERROR Traceback (most recent call last): logger:ERROR File "/usr/lib/python3.6/threading.py", line 1294, in _shutdown logger:ERROR t.join() logger:ERROR File "/usr/lib/python3.6/threading.py", line 1056, in join logger:ERROR self._wait_for_tstate_lock() logger:ERROR File "/usr/lib/python3.6/threading.py", line 1072, in _wait_for_tstate_lock logger:ERROR elif lock.acquire(block, timeout): logger:ERROR KeyboardInterrupt

System Details (please complete the following information):

• Kubuntu 18.04.1 (new installation)
• KDE Plasma 5.12.6
• KDE Frameworks 5.44.0
• Qt 5.9.5
• OpenShot Version [2.4.2]

[DylanC]

@spaccabist - I would recommend to try v2.4.3. How did you install v2.4.2?

[ghost]

version 2.4.3 gives the exact same error

[DylanC]

@spaccabist - Did you try manually installing python3-pyqt5.qtwebkit?

[DylanC]

@ferdnyc - Do you think we need to swap this import for something more modern? (Qt WebEngine)

Line 40: https://github.com/OpenShot/openshot-qt/blob/develop/src/windows/views/timeline_webview.py

Reading material: https://stackoverflow.com/questions/37876987/cannot-import-qtwebkitwidgets-in-pyqt5

[ferdnyc]

@DylanC

Do you think we need to swap this import for something more modern? (Qt WebEngine)

"Need"? Not as long as QtWebKit continues to work. And fingers crossed that it does.

"Should"? Absolutely, but in the broadest sense that's a conversation we've already had (or at least started), when we were batting around things like timeline-as-QGraphicsView and timeline-as-QML over in #1864. Any reimplementations like that would eliminate the dependency on QtWebKit, since the only place it's ever needed is in timeline_webview.py.

(Funny story, I discovered when grepping the source tree that QtWebKitWidgets was also being used by src/windows/title_editor.py — but after the import line at the top of the file, the QWebView class was never referenced again! It was a completely spurious import. So now #2171 will remove it, and timeline_webview.py will be the only file with any dependency on QtWebKitWidgets.)

Short of a timeline reimplementation, though, updating timeline_webview.py from QtWebKit to QtWebEngine is far from the simple matter that they make it sound in the answers to that StackOverflow question. Yes, for their code it may be a simple matter of:

from PyQt5.QtWebEngineWidgets import QWebEngineView as QWebView

and the code works without modification. But if the code runs any JavaScript, it's no longer a simple conversion due to the synchronous evaluateJavaScript() method being removed in favor of an async runJavaScript() implementation. That change is really unfavorable to OpenShot's Python-JavaScript interaction.

In places where the OpenShot code triggers JavaScript calls in a fire-and-forget manner, just telling them to run and then moving on, it's probably NBD. Just update the syntax and give it a dummy callback, you're all set. Just like before, code runs whenever it gets around to it, but the interface isn't waiting around for it.

But in other places where OpenShot makes JavaScript calls in a direct, synchronous manner, the problem is that QtWebEngine just no longer supports that at all. I'm talking about sections of timeline_webview.py such as:

    # Find the closest track (from javascript)
    top_layer = int(self.eval_js(JS_SCOPE_SELECTOR + ".GetJavaScriptTrack(" + str(position.y()) + ");"))
    new_clip["layer"] = top_layer

    # Find position from javascript
    js_position = self.eval_js(JS_SCOPE_SELECTOR + ".GetJavaScriptPosition(" + str(position.x()) + ");")
     new_clip["position"] = js_position

    # Adjust clip duration, start, and end
    new_clip["duration"] = new_clip["reader"]["duration"]
    if file.data["media_type"] == "image":
        new_clip["end"] = self.settings.get("default-image-length")  # default to 8 seconds

[...skipping...]

    # temp hold item_id
    self.item_id = new_clip.get('id')

    # Init javascript bounding box (for snapping support)
    code = JS_SCOPE_SELECTOR + ".StartManualMove('" + self.item_type + "', '" + self.item_id + "');"
    self.eval_js(code)

With QtWebEngine, JavaScript just can't be used synchronously like that. There's no calling JavaScript functions and getting return values passed right out to the calling function. Every "lookup" type JS call has to fire off an asynchronous runJavaScript(), and anything the code wants to do with the results of that call moves to the callback that fires when the JS completes.

It's certainly not an insurmountable problem to convert the code in theory, but I'm really not optimistic that inherently synchronous operations like looking up coordinates on the Timeline can be performed over multiple async callbacks, with anything approaching acceptable performance. My gut feeling is that the JavaScript side would have to be rewritten to accomodate the async nature of the requests. (Say, having a single JS function that takes a two-dimensional point as an argument, and in turn returns the point that represents both the X and Y coordinates currently being retrieved in two separate calls #ForSomeReason. Since when you look at it, that's all those two sync calls are doing: retrieving first an X coordinate, and then a Y coordinate, corresponding to the .x() and .y() components of position, respectively.)

There isn't a lot of that, but there's enough (timeline_webview.py is just shy of 3000 lines long) that it feels like something not worth doing unless forced to. Especially if there's any hope that QtWebKit would be going away entirely, not in favor of QtWebEngine but in favor of some complete reimplementation. Then an intermediate QtWebEngine conversion just seems like completely wasted effort.

[DylanC]

@ferdnyc -

There isn't a lot of that, but there's enough (timeline_webview.py is just shy of 3000 lines long) that it feels like something not worth doing unless forced to. Especially if there's any hope that QtWebKit would be going away entirely, not in favor of QtWebEngine but in favor of some complete reimplementation. Then an intermediate QtWebEngine conversion just seems like completely wasted effort.

I think you are right. We should leave it well alone until we come up with something better. Although as much as a QML timeline sounds amazing I think time would never permit any of us to develop that feature to the same extent of features as the current timeline. Its really a project all of its own.

[ferdnyc]

@DylanC — I should say that I do think a fully-async implementation of the Timeline's Python-JavaScript interactions would probably make for some improvement in overall application performance, since the Python code would no longer be blocking on any of the JavaScript calls. Whether or not it would be measurable / significant, I don't know.

Currently there are sections of code, like the one above, that flip between Python and JS in an inherently synchronous fashion, tossing the control-flow "baton" back and forth between the two interpreters over the course of performing an operation. It's not clear how much latency and overhead that's really adding to OpenShot — probably not too much, at least under normal circumstances — but it's definitely more than 0. And bottlenecks like that can be self-constricting: once resources start to dwindle and context switches become expensive, each toss of that baton takes longer and becomes more noticeable.

Having done some more reading, though, I'm not sure QtWebEngine would be the right target for that anyway. If you read that Qt 5.6 announcement that the stack question linked to (the one where QtWebKit was removed from the Qt distribution), here were the new features in that release:

• QtWebEngine
  • Based on Chromium 45
  • Support for pepper plugins including Flash
  • Support for unbundling and linking with system libraries on Linux
  • Support for following global Qt proxy settings.
  • More WebActions from QtWebKit and WebAction API in QML.
  • New QtWebEngineCore module for shared low-level API
  • New core API for custom URL schemes
  • New core API for intercepting and blocking network requests
  • New core API for tracking or blocking cookies.

Plugins? Even Flash?! Network requests? Cookies? No wonder that porting guide says, "However, Qt WebEngine is thus also heavier than Qt WebKit"

There have to be lighter ways to incorporate purely local web-based content into Qt applications than QtWebEngine, since Qt Quick and QML are even targeting mobile devices and lightweight systems like the Raspberry Pi.

I'm also not as convinced anymore that QtWebKit is deprecated per se. The Qt announcement only said that it was "removed" from the Qt distribution, meaning it was parted out as an optional component that's no longer distributed by Qt themselves. It appears to still be maintained by Qt themselves, though not super actively (the last commit was in January). And many distributions package both QtWebKit and QtWebEngine separately from the rest of Qt, putting them on equal footing as far as availability/integration.

[ferdnyc]

I'm also not as convinced anymore that QtWebKit is deprecated per se. The Qt announcement only said that it was "removed" from the Qt distribution, meaning it was parted out as an optional component that's no longer distributed by Qt themselves. It appears to still be maintained by Qt themselves, though not super actively (the last commit was in January). And many distributions package both QtWebKit and QtWebEngine separately from the rest of Qt, putting them on equal footing as far as availability/integration.

Whoops, I will correct myself on one point here: I happened to notice someone mention in a stack comment that QtWebKit was deprecated in the release prior to it being removed. Sure enough, while the Qt 5.6 announcement "removed" QtWebKit, that came on the heels of it being deprecated in the Qt 5.5 release.

So, it maybe is a little more "borrowed-time" than it had seemed. I'm still in agreement that it would be great to move away from QtWebKit, for the OpenShot timeline implementation. And I'm still of the opinion that the thing it moves to should be something other than QtWebEngine, something requiring a completely new implementation anyway.

As we discussed above, the way OpenShot's current timeline implementation uses JavaScript is as incompatible with QtWebEngine as it would be with any other method of integrating an asynchronous, web-based component into the existing PyQt5 interface. An effort to migrate from QtWebKit to QtWebEngine would be far too big an undertaking, as big as any other QtWebKit replacement effort. Even (hell, especially) as an interim solution along the road to something else, it would produce far too little real benefit to be worth doing unless it becomes absolutely unavoidable. (And maybe not even then.)

[stale[bot]]

Thank you so much for submitting an issue to help improve OpenShot Video Editor. We are sorry about this, but this particular issue has gone unnoticed for quite some time. To help keep the OpenShot GitHub Issue Tracker organized and focused, we must ensure that every issue is correctly labelled and triaged, to get the proper attention. This issue will be closed, as it meets the following criteria: - No activity in the past 180 days - No one is assigned to this issue We'd like to ask you to help us out and determine whether this issue should be reopened. - If this issue is reporting a bug, please can you attempt to reproduce on the latest daily build to help us to understand whether the bug still needs our attention. - If this issue is proposing a new feature, please can you verify whether the feature proposal is still relevant. Thanks again for your help!