Unable to browse for files on "other locations"

[fyrekrig]

Intel® Core™2 Duo CPU E8600 @ 3.33GHz × 2 NVA8 Kali GNU/Linux Rolling 2018.1 OpenShot 2.4.1 File/ImportFiles does not include "other locations" i.e other partitions on HDD than C:/ How can I navigate to these folders?

[ferdnyc]

Mine does. (Fedora 27; currently OpenShot 2.4.1 built by hand, but I don't recall any difference in the rpmfusion openshot-2.4.0 builds.) Sounds like it may be a build issue.

[ferdnyc]

(Also, you're on Linux, you say? You know there's no such thing as C:/, right? ...Not even on Windows, there it would be C:\.) :wink:

[DylanC]

@ferdnyc - I'm assuming its a dual booting PC with Linux and Windows on it. :)

[fyrekrig]

@ferdnyc - I'm assuming its a dual booting PC with Linux and Windows on it. :) Actually it's not. The first partition used to have a windows install and might have again. Enclosing screenshots from filemanager and OpenStop "Import files"

[fyrekrig]

Sorrry made mistake by closing!

[peanutbutterandcrackers]

@ferdnyc - Whoa! Neat! Your 'import' dialogue uses the gnome import dialogue for some reason, not OpenShot's own. Which is pretty neat, I think. How did you you do that?

@DylanC - I think we should get ^that going on with OpenShot rather than the default 'import' dialogue. This issue happens with me too. But I have figured out a work-around. :)

@fyrekrig - First, go to your file manager, click on the drive. That will open (or rather, mount) the drive. Then, head over to OpenShot. Click Import. Click 'Computer' on the right panel. Click 'media'. Click your-username. You should see some cryptic directories. Those are the ids of the drive that are currently mounted. Click on them and figure out which drive is the one you're looking for. And it will work. I have attached a screenshot. Hope this helps!

[ferdnyc]

@ferdnyc - I'm assuming its a dual booting PC with Linux and Windows on it. :) Actually it's not. The first partition used to have a windows install and might have again.

Aha! Yeah, and that's kind of what I was getting at — you may have drives/partitions still named things like C:\ or whatever, but Linux doesn't care about those names. GIO (gvfs) muddies the water a lot here, but before it existed, Linux (like Unix before it) operated on a unified filesystem architecture — every accessible local filesystem was located somewhere below /, the root dir. (Unless it was a network share. Though even then, nfsmount could be used to bind local filesystem paths to remote shares.)

If you wanted to mount some random partition that wasn't part of the standard /usr, /var, /home filesystem layout, someone with root access created a path for it (the legacy standard was originally /mnt) and mounted it manually at that path. Then Linux came along with its concept of (non-root) user filesystem mounts (like removable drives), so /media/ was added as the "userland-partition" location, along with helper daemons like GnomeVFS that would manage directories under /media/ as needed for mounts. (The directories were typically named /media/LABEL, with "LABEL" being the filesystem label if there is one, so something like /media/C/ became possible. If the filesystem doesn't have a label, or if the system chooses not to expose it, then you get cryptic filesystem IDs like in the screenshot above.) It appears that @peanutbutterandcrackers 's distro has also improved on the /media/ concept by partitioning it into /media/$USER/, so that different users' mounts don't potentially collide.

If you're not operating in a GIO/Gvfs world, then that's probably the end of it and the advice @peanutbutterandcrackers posted about looking in /media/$USER/ should work for you. However, for anyone who does happen to be running Gnome3 (with or without Gnome Shell as their desktop), or any other system that's adopted GIO, then your filesystems may be managed by gvfs. And things get more complicated.

With GIO, mounted filesystems aren't necessarily represented as filesystem paths. Remote servers can be accessed by URL. Mounted media are accessed by disk label. If I want to browse my remote fileserver in Nautilus, I visit sftp://ferd@remotehost/path/. My Windows partition, I visit its entry in the "Other Locations" selector and it just shows up as a drive named WIN7. Those paths don't obviously follow the /path/below/the/root/directory/ unified-filesystem scheme of traditional UNIX.

But even though the unified-filesystem paths are hidden, they still exist so that legacy apps (ones that don't understand GIO URLs) can access mounted filesystems. You just have to know where to look.

gvfs/GIO takes the /media/$USER/ concept and does it one better, in terms of security and isolation, by managing each individual user's drive/filesystem mounts separate from other users'. It also manages remote-filesystem mounts in a directory managed by the gvfsd daemon. So in a GIO world, there probably won't be anything mounted by you as a user under /media/, it'll be in your gvfs user directory. The easiest way to figure out where that is would be to run mount on the command line, and look for its mounts: the gvfsd-fuse virtual mountpoint, for remote folders, and mounts of type fuseblk for mounted local disks. For instance:

% mount sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime,seclabel) proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) [--- 8< -- Like literally 30 lines of crap --- 8< ---] tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,size=2496k,mode=700,uid=1000,gid=1000) gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,[...]) /dev/sda2 on /run/media/ferd/WIN7 type fuseblk (rw,nosuid,nodev,user_id=0,[...])

So my distro/configs has GIO storing my personal remote filesystem mounts in /run/user/$UID/gvfs/, and any partitions or drives I mount (with root access) under /run/media/$USER/. Anything I have mounted will be located in those locations, and I can navigate to them with any tool or file chooser that doesn't understand GIO locations.

And that's waaaay more than you ever wanted to know about the Unix/Linux standard filesystem, with GIO modificatiions.

[ferdnyc]

@ferdnyc - Whoa! Neat! Your 'import' dialogue uses the gnome import dialogue for some reason, not OpenShot's own. Which is pretty neat, I think. How did you you do that?

Well... I didn't, to be honest, in the sense that it happened automatically. The RPM spec file I used to build this OpenShot 2.4.1, even though I built it myself, was a barely-edited version of the standard rpmfusion spec that was used to build the openshot-qt-2.4.0 packages they distribute. It doesn't do anything special at all in the build process that would trigger this. And looking at the OpenShot code, the only thing it does to open a file chooser whenever it needs to is call some method of the standard QFileDialog class, e.g:

        app = get_app()
        _ = app._tr
        recommended_path = app.project.current_filepath
        if not recommended_path:
            recommended_path = os.path.join(info.HOME_PATH)
        files = QFileDialog.getOpenFileNames(self, _("Import File..."), recommended_path)[0]
        for file_path in files:
            self.filesTreeView.add_file(file_path)
            self.filesTreeView.refresh_view()
            log.info("Imported media file {}".format(file_path))

So my guess is that it's all to do with the way Qt5 is installed on either your local system, or the build system where your OpenShot package was created. Specifically, QFileDialog is part of Fedora's qt5-qtbase package, so it would be a matter of how that's set up.

This StackOverflow question is about the file-chooser topic generally (not specific to OpenShot, because I don't believe this is specific to OpenShot at all, it's simply a question of local Qt configuration), and the accepted answer has some pointers to Ubuntu resources for solving this, if you're running Ubuntu, and would probably be some help even if you're not.

[DylanC]

@peanutbutterandcrackers @ferdnyc - In my own project I do something kinda similar in C++: const QString& fileName = QFileDialog::getOpenFileName(this, tr("Open File"),

The interesting thing is sometimes in the past it has opened a Gnome style open dialog. In more recent versions of Ubuntu and the version of Qt they ship I can see the default Qt5 open file dialog. (like the one you see in peanutbutterandcrackers screenshot)

I think its down to the configuration of lib Qt5 in the different Linux distributions.

[peanutbutterandcrackers]

@ferdnyc - Whoa! That was a great explanation of filesystem management thingy!

@DylanC - I see. So, I think it's sth that has to do with PyQt5, then..

[fyrekrig]

Everybody, thanks for your inputs.

However the functuality does not seem to be there. Ofcourse there are simple workarounds by dragging the file to the Desktop.

Using Linux Kali for pen testing is great but thought I would try to use it as a main OS. No such luck. When it comes to Linux nothing works as expexted. Started trying Linux a long time ago (Mandrake/Mandriva) and it seems not much have happened since then.

Unless an earthkwake happens I still have to use Windows or OSX for day to day computing.

You have to love the terminal to love Linux!

[peanutbutterandcrackers]

@fyrekrig - You have to love freedom to love Linux, actually. And freedom is worth the inconvenience. I understand that the program might not have the functionality now. But someday, we will have that. And all the other cool functionalities that none of the others will have. It only depends on how much we are willing to support this amazing free software. :)

[ferdnyc]

@ferdnyc - Whoa! That was a great explanation of filesystem management thingy!

Not that great, as it turned out there were several mistakes in my information. That's in addition to the fact that I'd completely failed to properly explain how GIO makes things different / more confusing (by hiding the simple-filesystem paths to its resources). So I've updated it accordingly.

[ferdnyc]

@DylanC wrote:

The interesting thing is sometimes in the past it has opened a Gnome style open dialog. In more recent versions of Ubuntu and the version of Qt they ship I can see the default Qt5 open file dialog. (like the one you see in peanutbutterandcrackers screenshot)

Yeah, that's the issue that was brought up in the Stack Overflow question I linked to earlier, it's specifically an issue with how Ubuntu's Qt5 installation works. (They forced the platform theme to make their app menus work. But that was in the Unity world, not sure it's still true with Ubuntu 17.10+, now that they've gone Gnome Shell.) You may be able to get native dialogs back by simply installing the libqt5libqgtk2 package. Or you may need to (un)set an environment variable. I don't have a Ubuntu system to test it on, myself.

[peanutbutterandcrackers]

I did install libqt5libqgtk2 on my friend's elementary OS 0.4.1 'Loki' laptop, and it still the same file chooser... :neutral_face:

Any further ideas? o.O

[ferdnyc]

Only one, try starting OpenShot from a terminal with:

QT_QPA_PLATFORMTHEME="" openshot-qt

If that doesn't work, then I'm really out of ideas. (But the folks at Stack Overflow might have some more.)

[peanutbutterandcrackers]

Sorry. That doesn't work either... :neutral_face:

Perhaps this needs to be on the list of things that need to be sorted out soon list...

[ferdnyc]

OK, let's take a run at this from a different direction. What's the output of qtdiag on the system in question? (Relevant output, tho it's not always trivial to decide what is relevant. But it outputs a lot of information.)

On my Fedora Linux box (native GTK dialogs by default), it includes the following sections:

Platform capabilities: ThreadedPixmaps OpenGL ThreadedOpenGL WindowMasks MultipleWindows \
ForeignWindows NonFullScreenWindows NativeWidgets WindowManagement SyncState \
RasterGLSurface SwitchableWidgetComposition

Theme:
  Platforms requested : gtk3,gnome,generic
            available : gtk3
  Styles requested    : fusion,windows
         available    : Windows,Fusion
  Icon theme          : Adwaita,  from /home/ferd/share/icons,/usr/share/icons,/usr/share/icons,/usr/share/pixmaps
  System font         : "Source Sans Pro" 11
  Native file dialog
  Native color dialog
  Native font dialog

If you don't see the same platform theme information, on elementary OS 0.4.1, then what's there may provide some clues as to what they're doing differently.

If you don't have a qtdiag command you may need to install the necessary package; in Fedora it's part of qt5-qttools-devel.

[peanutbutterandcrackers]

qtdiag outputs qtdiag: could not find a Qt installation of '' Do you think that might have something to do with it, @ferdnyc ?

[ferdnyc]

Hmm. Odd. But... I don't think it's related to the file-chooser issue, at least not directly. I mean, OpenShot works on the machine so clearly Qt is installed and accessible after some fashion.

That kind of thing does make me think that maybe Elementary's Qt setup isn't the most... cultivated? Mature, that's a better word. It's clearly possible to get native GTK file/color/font dialogs in Qt apps, though with Qt5 it seems like it might take a little work to ensure that things are set up that way right out of the box. On some distros, that work's been done by the packagers and things Just Work™. On other systems, what the user ends up getting will be dependent on the package selection choices they make or configuration they do, so you end up with a lot of community support posts from people wondering why they're seeing certain behaviors. (There are a ton of support hits online about native file chooser issues; clearly this is a common problem for lots of people, at least in certain situations. And predictably, "could not find a Qt installation" is another big winner, with "About 1,450 results" in google that almost exclusively involve debian, Ubuntu, or their derivatives.)

So, while as I said I don't think they're directly related... when you can install qtdiag on a system and have it not function right out of the box, it feels less surprising to discover that you can install Qt and have it not just use native GTK resources right out of the box. Apparently something isn't installed. The same something? Different somethings? ¯\_(ツ)_/¯

I would focus on sorting out the qtdiag issue, possibly using the resources in this Stack Overflow question for starters. Not only is qtdiag the best hope for tackling the file-chooser issue using information on the system's current platform theme. (I mean, if you look at the qtdiag output in my comment, everything is laid out right there — we need to see that same info for your system.) But whatever bits of Qt you end up having to install/configure in the course of getting qtdiag to function, there's at least a fair chance you might discover you've accidentally fixed the native dialogs issue as well.

[peanutbutterandcrackers]

Okay. So now qtdiag works now on my Elementary OS 0.4.1 'Loki'.

I first installed qt5-default, it didn't work. Next I installed qt5-qmake, it didn't work either. Finally, I installed qtcreator, and it worked.

I then removed qt5-default and qt5-qmake and did sudo apt autoremove too, just to see if qtdiag still works. It did.

So, attached is the output of $ qtdiag. :) qtdiag_output.txt

[ferdnyc]

OK, great. Yeah, the issue appears to be that you simply don't have a platform theme, which AIUI is what drives Qt's selection of things like native dialogs and etc. Compare the snippet from my qtdiag output, above, to yours:

Theme:
  Styles: Fusion,Windows  System font: "Sans Serif" 9
  General font : "Sans Serif" 9
  Fixed font   : "monospace" 9
  Title font   : "DejaVu Sans" 12
  Smallest font: "DejaVu Sans" 12

The output isn't directly comparable due to differing Qt versions. (Your 5.5.1 vs. my 5.9.4; "Fonts:" is a separate section entirely in mine, which I didn't bother quoting.) But the lack of mention of a Platform Theme is definitely an issue, as it's that theme (/usr/lib64/qt5/plugins/platformthemes/libqgtk3.so on my system) which triggers the "Native... dialog" lines in my qtdiag output. Without the platform theme to tell it otherwise, Qt5 just uses its crappy, built-in "cross-platform" dialogs.

Now, it appears that something changed in Qt 5.7 regarding platform theming (or the Debian/Ubuntu-family packaging thereof), which broke things for Ubuntu users. But since you're not running Qt 5.7+, the "used to work" method from that post is probably what you need, at least for now. It sounds like that would mean installing the package qt5-gtk-platformtheme, and possibly also qt5-styleplugins if it exists. You might also look for packages with names like qt5-style-plugins (tho I think that's too new), libqt5libqgtk2(1, 2 — tho that may be too old), or really anything qt5-related that involves the words "theme", "style", or "gtk".

Just installing the right one(s) alone might do it. But if you've managed to get a theme file installed in the platformthemes directory, and it isn't being picked up, there may also be environment variables that need manual setting. My first link has some info about that, but mostly as it pertains to Qt 5.7+. This ArchWiki article has far more info, spanning the entire history of Qt4 and Qt5 — so much, in fact, that it can be very difficult to see what's actually applicable, let alone figure out how to apply it.

[ferdnyc]

Oh, duh, I forgot that I have the path information for your system — the advantages of qtdiag! The platform themes would be located in /usr/lib/x86_64-linux-gnu/qt5/plugins/platformthemes/.

[peanutbutterandcrackers]

So, after installing qt5-style-plugins and libqt5libqgtk2 and adding "export QT_QPA_PLATFORMTHEME=gtk2" in my ~/.profile, and sourcing it, if I click on the OpenShot icon to start it, nothing changes. However, if I type in $ openshot-qt, I get the system file chooser but it uses a different icon for OpenShot in the dock and uses a different icon theme too. Noteworthy might be the fact that I have also got OpenShot 1.x series on my comuter. Note the OpenShot 2.x launcher on the left of the Openshot 2.x icon.

I also went ahead and removed openshot1.x from the machine and now, it doesn't open with openshot1.x icon but uses the 2.x one. But the themes are still different. Still doing $ openshot-qt, BTW. Clicking doesn't work. Still. Perhaps it's because I put the line in ~/.profile?

Here's the output of qtdiag: qtdiag_output.txt

But then again, the strange thing is, it seems to be the same generic qt file chooser even in windows and stuff, if I remember correctly. So, perhaps there's something that could be changed in OpenShot source that could fix it?

[peanutbutterandcrackers]

P. S: @ferdnyc - Please do check your mail. I have sent you an important message regarding OpenShot. Thanks! :)

[ferdnyc]

So, after installing qt5-style-plugins and libqt5libqgtk2 and adding "export QT_QPA_PLATFORMTHEME=gtk2" in my ~/.profile, and sourcing it, if I click on the OpenShot icon to start it, nothing changes. However, if I type in $ openshot-qt, I get the system file chooser but it uses a different icon for OpenShot in the dock and uses a different icon theme too.

Yeah, the problem is that sourcing a .profile file (or any script), just like an explicit export command, only sets the environment for the current shell and subshells — nothing started before that point, and nothing started by a parent process. And since the session manager is the parent to everything in the session, you'd need to log out and log back in for it to pick up the updated .profile. At that point, the openshot-qt.desktop launcher should pick up the changes to the environment, and operate just like the command-line invocations after you'd set QT_QPA_PLATFORMTHEME for the local shell.

But then again, the strange thing is, it seems to be the same generic qt file chooser even in windows and stuff, if I remember correctly.

Nope... at least, not anymore, even if that was the case in the past. I just spun up a fresh Win7 SP1 VM on my machine, installed from ancient ~2013 media, then downloaded OpenShot 2.4.1 from the openshot.org site and installed it. Right out of the box, it's using the native dialog:

So, perhaps there's something that could be changed in OpenShot source that could fix it?

Highly unlikely — not universally, at least. Any attempts to solve things from the OpenShot end are doomed to a nightmare loop, where a fix gets added for one OS/distro, and ends up breaking three more, so another fix is added to sort those out, but that fix breaks something else, and... well, you get the idea.

There are two main reasons for that:

1. The range of Qt versions OpenShot might be running under is insanely broad.
   1. The most recent Qt release is 5.10.1, which came out a month ago. (5.11 is due in May.)
   2. In Fedora 27 I'm running Qt 5.9.4, which came out January 23.
   3. At some point, recent Ubuntus upgraded past 5.7 (June 2016), where a lot of things changed from previous builds, including the move from GTK2 to GTK3, and that caused people some problems.
   4. The Windows installer for OpenShot 2.4.1 comes bundled with Qt 5.6.1, also from June 2016.
   5. You're running Qt 5.5.1, which is craaaazy old (released October 2015!) and still using GTK2. At some point, when you upgrade to Qt 5.7+, those things you just did to get this working will stop working (because the GTK2 platform theme goes away, which ultimately is a good thing). It's unclear, based on other Debian-like users' experiences, if you'll then need to do different things (and what) to again have native dialogs. But based on Fedora's config, it's possible to have it Just Work™ out of the box without the user having to configure anything.
2. OpenShot is currently doing exactly what it's supposed to, for native dialogs: Absolutely nothing.
   1. The documented behavior for Qt's standard dialogs, at least in recent Qt versions, is that it will use native dialogs if possible on the platform. If there's a native dialog available to the application, it will be used — unless the application specifies otherwise.
   2. You read that correctly: The only control an application has over the selection of native vs. built-in dialogs is the QFileDialog::DontUseNativeDialog option, which instructs Qt to ignore an available native dialog and use its built-in ones.
   3. If a user isn't being shown native dialogs, it means that Qt can't display them. It most likely means that something is missing from its install, like (in your case) the libqt5libqgtk2 package. Merely setting an environment variable, without installing that package, won't do anything. And OpenShot can't install that package for the user, because the exact identity of that package will be dependent on the OS, distro, distro version, and Qt version in use.
   4. OpenShot could be packaged to pull in the correct platformtheme automatically, but even then it shouldn't do it directly. It should do it the way it's done on Fedora:
      1. The platformtheme library is packaged in the qt5-qtbase-gui package, which is the same one that contains core Qt components like libQt5Gui.so.5.9.4 and libQt5Widgets.so.5.9.4.
      2. Because it uses Qt GUI components and links to the Qt GUI libraries, the libopenshot-0.1.9 package is built to require those libraries, the same way every Qt GUI application on Fedora is packaged.
      3. So when any of those applications is installed, platformthemes/libqgtk3.so is pulled in automatically as part of the hard requirement on qt5-qtbase-gui, and Qt makes use of it automatically to display native dialogs.
   5. That's the way it's supposed to work, that's the way it works in Windows (and mac OS, according to the documentation, though I can't test that), and that's the way it can work on Linux. If a Linux distro's Qt setup is broken, it should be fixed there, not in OpenShot.
   6. Even though OpenShot can't really fix this problem, it can break things by trying. Even though my system uses native dialogs by default, that can be broken if the QT_QPA_PLATFORMTHEME environment variable is set wrong. And there's no one "right value" that's correct for every system, or even every Linux system.

So, while the native-dialog configuration should be handled by the local distro's Qt packaging (and can be, as some do it already), and as a convenience/workaround it could be included in an OpenShot package targeted specifically to a problematic distro (which would make that package no longer applicable to most other compatible distros), in practical terms nothing could or should be done in the OpenShot source itself. Because not only is "do nothing" the officially-documented correct way to have Qt provide native dialogs, but if anything other than "nothing" is added as a band-aid for one platform, it's probably going to accidentally cause massive hemorrhaging somewhere else.

Phew. That got crazy-long, sorry. I will check my email, I saw the message but my inbox is kinda backed up. I typically treat email as lowest-priority, since I don't use it for anything important.

[peanutbutterandcrackers]

Wow. That was quite informative. Thank you!

I hope Ubuntu 18.04 fixes these stuffs. Strangely enough, Linux Mint 18.3 'MATE' seems to have resolved this issue. But if Ubuntu does, then so will all the Ubuntu-based distros, hopefully.

Please do check the mail. :)

For the time being I'll add the line to my /etc/profile, then.

[DylanC]

@ferdnyc @peanutbutterandcrackers - Can we close this since it seems to be a Linux distribution issue rather than Openshot?

[peanutbutterandcrackers]

@DylanC - Yes, Cap'ain. It most certainly seems so.

@fyrekrig - Sorry. Turns out there isn't much that can be done in OpenShot's source code to fix this issue. However, Ubuntu 18.04 should be out next month. And with that, probably they will ship a newer version of PyQt5, in which this issue does not seem to persist. For the meantime, if you want to use the default file manager, please try the doing something like this, and hopefully, it might work. Please do remember to add the environment variable in /etc/profile and not just ~/.profile. Hope that helps!

[ferdnyc]

I actually ignored one other facet of this whole thing (my biases are showing), and since I hate to end on the impression that things are as completely hopeless as I perhaps made them sound...

OpenShot does have one recourse for working around problematic distros/packaging, and it's the one it's already taking: The AppImage builds. OpenShot distributed that way does an end run around the distros' dependency packaging completely, because it controls the entire horizontal and the vertical — the libraries and toolkits it makes use of, which would normally be provided by its package dependencies, are instead bundled right in with the software itself.

In theory, that allows it to be distro- and packaging-agnostic, since everything included with the app will be configured however it needs to be, and can be reconfigured by the application developers, instead of having to rely on distro packagers.

Now, I say "in theory", because we're talking about "native dialogs" here. Those are inherently dependent on local system resources, to some degree (that's the "native" part) — so this is one of those few things that could even be more difficult when running inside an AppImage. Plus, a lot more is riding on the details of the AppImage packaging itself.

In my previous comment, I mentioned that OpenShot 2.4.1 on Windows is bundled with Qt 5.6.1. The GTK3 native dialogs on Linux require Qt 5.7+, so if the AppImage is also built with Qt 5.6 then it's going to have to rely on GTK2, and as we've seen that can be a headache to get working. (There's a reason Qt just went ahead and tore out the GTK2 platform completely as soon as their GTK3 version was finished.) And presumably, whether it's GTK2 or GTK3, the AppImage will not only have to contain the correct bits of Qt (the platformtheme library and related components), but perhaps some or all of GTK itself.

Honestly, I'm not familiar at all with AppImage bundling (or its cousins like Flatpak and the like), in practice especially but even my theoretical understanding is limited. So I'm far from certain how that all works, and how it fits together with the system it's being run on. I'll spare you my rant on why I think creating software bundles that include a slightly-different copy of the same library alongside every individual application that uses it, is just replacing a problem with a different problem. But for those on problematic distros, where the shared Qt support is causing issues with things like native dialogs, then using the AppImage build of OpenShot might be the most expedient path to overcoming distro dependency issues. (← That's the TL;DR takeaway here.)

IF it's possible for Qt in an AppImage to use native dialogs, and IF the OpenShot AppImage is built with the right versions/configuration of Qt, and whatever other dependencies it might need (Gtk?), in order to make that happen.

Some time this week I'll try to find time to download the AppImage and test it out, to get an idea of where things stand there, and I'll let you know what I find. Or, if anyone else feels like giving it a whirl, it should be a matter of download-and-launch, simple as that. (That's sort of the whole point of the entire AppImage concept.)

[peanutbutterandcrackers]

@ferdnyc - Awesome! Looking forward to your deductions, Mr. Holmes! :)

[ferdnyc]

Yeah, so I was afraid of this. The current OpenShot-v2.4.1-x86_64.AppImage build doesn't use native dialogs, even on Fedora. So, not only does it not help to solve distribution deficiencies, on some distros it can actually be worse than the local package.

That may be due to the AppImage bundling an ancient version of Qt (5.2.1!!! :open_mouth: ). Or it may be that it's not configured properly to use native dialogs. (Actually, I suspect both of those go hand in hand.) Or, it may be that this isn't supposed to work, because AppImage encapsulation interferes with the ability to access native dialogs.

I'm going to assume for now that the last of those isn't true, and that the problem is due to one or both of the other possibilities. So, I'll file a new issue, tracking the need to bring the AppImage build into this half of the decade. (Seriously, 5.2.1 was released Feb. 5, 2014.) Upgrading the included Python from 3.4.3 to some 3.6.x release probably couldn't hurt, as well.

[peanutbutterandcrackers]

Okay. I will bring the devs attention to this too. Thanks for the detective work, Mr. Holmes! :)