Why did Add Existing Files Dialog UI change?

[philja]

I second the remarks about preferring the non-native dialog and the consistency it provides between the different OS. When I realised that I could drag directories into the left hand nav pane and they'd be remembered, it was even better.

I shall be sticking with the non-native version.

[Stasia]

The issue for me is that I often need to look for images, and it's far easier to see the image I want if I can see the image. The current/new dialog box is text-only, which I find difficult to work with.

I've dragged my usual folder to the left side part of the dialog box, and I can sort that by time (what I'm working with is almost always recent), but I find this format far clunkier than the older version.

I'd be willing to add the code thingy that everyone's mentioned, but I don't know where and how to add it and no one seems to have mentioned that in their comments.

I only use one OS, so having cross-OS functionality is not important or useful to me.

[DiapDealer]

Originally Posted by Stasia

I'd be willing to add the code thingy that everyone's mentioned, but I don't know where and how to add it and no one seems to have mentioned that in their comments.

Unless you can compile Sigil from source, you can't. You'll have to wait for the next version of Sigil (if we decide to keep the code we're talking about in place).

Originally Posted by Stasia

I only use one OS, so having cross-OS functionality is not important or useful to me.

That doesn't change the fact that Sigil IS a cross-platform project that has to work similarly on three different platforms using the same codebase without crashing. No one platform is more important than another when we make decisions like this. It doesn't matter that you only use one OS. You're using a program that has to make concessions to keep things running smoothly on all platforms. Not just yours.

[DNSB]

Originally Posted by DNSB

I compiled Sigil with the changes and played with the file dialog. I could toggle the native and non-native dialogs and seemed to be no issue with either.

Originally Posted by Stasia

I'd be willing to add the code thingy that everyone's mentioned, but I don't know where and how to add it and no one seems to have mentioned that in their comments.

As mentioned in my comment in message #12 in this thread quoted above, I compiled Sigil with the changes.

Originally Posted by Stasia

I only use one OS, so having cross-OS functionality is not important or useful to me.

I do use multiple OS and for me, the consistency is nice. For the most part, images I add have somewhat meaningful names (see attached image) so, for me, being able to see images is cold pancakes and no honey.

[Stasia]

Originally Posted by DiapDealer

Unless you can compile Sigil from source, you can't. You'll have to wait for the next version of Sigil (if we decide to keep the code we're talking about in place).

Ah, okay, that does help me. Knowing it's not something I can add makes me feel less like an idiot about it. Thanks!

Originally Posted by DiapDealer

That doesn't change the fact that Sigil IS a cross-platform project that has to work similarly on three different platforms using the same codebase without crashing. No one platform is more important than another when we make decisions like this. It doesn't matter that you only use one OS. You're using a program that has to make concessions to keep things running smoothly on all platforms. Not just yours.

Yes, I do understand that I'm a single user in a sea of people who use the program in widely varying ways, but I wanted to give an alternate perspective.

[Stasia]

Originally Posted by DNSB

I do use multiple OS and for me, the consistency is nice. For the most part, images I add have somewhat meaningful names (see attached image) so, for me, being able to see images is cold pancakes and no honey.

Yes, I do name my image files, but it's faster and easier for me to scan visually - text, especially if it's small, rapidly becomes a blur. Brains are all different. I can use the current search box, it's just a lot harder for me than the older version.

I wasn't commenting to say that My Way Is The Only Way; I was simply offering an alternate experience with the change.

[DiapDealer]

At this point, I see no reason why the proposed changes (to allow Windows users to override this non-native dialog) won't be available in the next release of Sigil. Users just have to realize that we're not going to support any issues that may arise from reverting to the native dialog.

[KevinH]

They are still finding crashing bugs related to using Qt QFileDialog native versions especially on Windows.

See this new bug that says how you connect it to the menu that invokes it can cause a crash. but only with newer Windows versions ...

https://bugreports.qt.io/browse/QTBUG-138803

Using "native" QFileDialogs is an issue we may need to address on a platform by platform basis. So adding that env var seems to be the way to go, for users that can accept more crashing behaviour instead of stability.

If it helps, we could probably add a pane that shows an image thumbnail for the selected item to the non-native file dialog much like we have for our own insert Image tool. If we have to move to all non-native dialogs in the future for all platforms, that might be a way to see what an image is without having to first add it.

But creating un-cacheable file thumbnails for each file would really slow down performance in Folders with lots of files.

Caching thumbnails is something better left to the underlying OS.

[BeckyEbook]

I think everything is fine right now (in the master branch), and I sincerely appreciate that.
For the majority of users, file dialogs are safe, and those who take risks have an environment variable. Obvious that they are doing so with full awareness of the potential risks, such as a Sigil crash.

[KevinH]

Originally Posted by BeckyEbook

I think everything is fine right now (in the master branch), and I sincerely appreciate that.
For the majority of users, file dialogs are safe, and those who take risks have an environment variable. Obvious that they are doing so with full awareness of the potential risks, such as a Sigil crash.

The problem is they will blame Sigil for the crash when it is in fact a Qt crash and from the looks of it primarily related to insufficient testing on their part. When you combine macOS native QFileDialog crashes with Windows native QFileDialog crashes (not even counting Unix/Linux ones) there has been serious Qt crashing bugs in more than 50% of the Qt versions we have tried (and those are chosen to be the more stable Qt 6.x.y with y >= 2).

Qt needs to stop their mad push for new features and instead focus on proper testing and bug squashing. But they reserve that for commercial $ licenses only. We open source users are just their guinea pigs!

[BeckyEbook]

This is a sad reality. I can only nod my head with understanding.
When I think about how many hours Kovid must spend creating workarounds for bugs in Qt, I still admire his enthusiasm and not giving up.
For an ordinary person it is simply inconceivable.

[DiapDealer]

We already had one report related to a crash when dragging & dropping text in Code View that could have only happened in that particular version of Sigil if they'd overridden our decision to disable drag & drop text (we'd actually had no idea it was ever enabled) with the similarly provided environment variable.

It's clear to me that many people will set these variables to quickly get the result they desire and then promptly forget all about the overridden behavior. Then when a crash DOES happen, they'll submit a bug report without giving it a thought that they'd long ago waived their right to complain.

[KevinH]

FWIW, if we ever decide to go all Non-Native, I have found a PreviewFileDialog class that wraps a QFileDialog and adds a Preview QImage Pixmap in an added right side panel. So when a user clicks on an image file, a thumbnail is created and shown.

We can also set a QFileDialog Option to not use third party QFileIconProviders which is supposed to greatly speed up network access.

I will play around with the PreviewFileDialog code to try to extend it to add an image for text files showing a bit of content and maybe even auto extract the cover image from an epub.

That should make using Non-native file dialogs less painful.