File Directory Strangeness

[wd5gnr]

Do you want to request a feature or report a bug?
Not sure. I think it is a bug, but if it is expected behavior, it is a feature request.

What is the current behavior?
File Open and save as dialogs have some problems (see OS notes below; not sure if this is specific to my OS)

1. If you move to a directory outside of home (say /tmp or /media) the dialogs don't work. They show no files.
2. You can't type into the file name field. So if you can select a file that's already there with the mouse, fine. But you can't create a new file name. Workaround is to paste the file name in which works.
3. I find it odd that linked cloud accounts don't show up in file open/save.

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem.

What is the expected behavior?
I should at least be able to enter file names as Save As is nearly useless without this.

Which versions of DesktopEditors, and which OS are affected by this issue? Did this work in previous versions of DesktopEditors?
Desktop editor 5.6.4.20 running on 64-bit Neon 20.04 on an AMD processor.

[matveevms]

Hellow, @wd5gnr
Could you record a video on the first two problems and clarify what you mean in the third item? Where would you like to show linked cloud accounts?

[wd5gnr]

No videos because there's nothing to video but here's a few screen shots:
https://imgur.com/a/Byv6Dw9

On #1, any directory outside of ~ does not enumerate any files even if there are files there.

On #2, any file dialog does not allow you to type a name. So you either take the suggested name or you paste a name from clipboard.

On #3, there is no way I can see to Save As to storage. I noted, for example, that when inserting an image you can pick from URL/File/Storage. But there is no way to save an open document to cloud storage that I see without saving it locally and then moving it yourself.

A small thing, I agree.

The first two, however, must be something specific to KDE because otherwise everyone would be reporting this. It may even be specific to my setup since Neon is relatively well used.

[XDmitryK]

@ wd5gnr I checked your problem on my KDE Neon but I haven't confirmed it
I can see files in the / tmp directory and can also change the filename
I think the problem is only with your system

[matveevms]

@wd5gnr To save the document on the portal, you need to create this document on the portal, or upload the document. You can also take the image from storage, which you gave as an example, only if you are logged into the portal.

[wd5gnr]

@XDmitryK well, it is strange because it is happening on two different machines (I checked). Not sure what would be the same on them that would do something like that. I'll investigate some more.

@matveevms Yes, I understand that. I'm saying as a feature, there should be a save as target if you are logged in.

[wd5gnr]

A little more detail.
Setting QT_XKB_CONFIG_ROOT to /usr/share/X11/xkb allows the keyboard to work again

I still don't see files in /tmp and possibly other locations but not sure why not. Saving to those locations appears to work but doesn't save there. Saving to a "good" location works, though.

[wd5gnr]

Ok, so the snap packaging explains the /tmp issue. I'm in /tmp off the snap root which is not /tmp on the filesystem. I guess it maps my user directory somehow, so that solves that problem.

[wd5gnr]

So I removed the snap and installed the .deb. Now any document I try to create new just hangs with a placeholder image and the app is hung. Straces shows it is stuck polling something. So I removed it and put the Snap back in. Same problem. I don't think it is related to any of the above.

[wd5gnr]

No amount of work with the .deb or snap would get things working. Flatpak works, though.