*** This bug has been marked as a duplicate of bug 362474 ***

The fix in bug 362474 does indeed remove the "<copyMoveOrLink>" text from the file name field in the copy, move or link dialogs - but it still doesn't set the original file name by default, which was the problem reported here.

Instead after that fix (I tested with the latest git as of today), there is no file name pre-filled at all.

I suggest de-dupping this report.

Patch available: https://phabricator.kde.org/D8409

Actually, are you taking about the window title, or the actual filename field? If you weren't seeing the filename in the filename field, that seems to be fixed now, as I can't reproduce that issue.

Created attachment 108515 [details]
screenshot showing the problem

It's not about the window title, its about the pre-filled file name in the move/copy/link dialog. It used to be pre-filled with the current file name, making it easier to move/copy/link it to another directory with the same file name, but then it just started to have the text "<copyMoveOrLink>", and not after the fix in bug 362474 it has nothing pre-filled. As per my comment #2.

See the attached screenshot as to how it looks when opening gwenview with a picture and then immediately pressing F8 (for move), and doing nothing else. The "Name" field is empty. I'd expect this to have the same text as displayed as the filename shown in the main window's title.

Just to be clear, this is running with Gwenview version 17.11.70 with KF5/Plasma framework 5.39

I still can't reproduce this when following these steps:

1. Open Dolphin
2. Navigate to a picture file
3. Double-click on the file to open it in Gwenview
4. Immediately hit F7, F8, or F9.

For me, the filename field is always filled, both with Gwenview 16.12.3 + KF 5.31.0 and Gwenview 17.11.70 + KF 5.39.0

One thing I notice about your screenshot is that the dialog looks different from mine. You seem to have a text field on top, and in other ways it looks different from mine. It looks older, rougher, a bit more primitive. What version of Qt do you have? It feels like you've got a really old Qt version, or else Qt is mis-rendering the dialog box.

Oh, or are you running Gwenview in a predominately GTK environment, outside of KDE Plasma? If so, then what you're looking at is the GTK dialog, not the Qt one, in which case this would be GTK's fault for translating the Qt request improperly when it attempts to substitute a GTK dialog.

Or rather, actually I think it would be a Qt bug, since Qt is what does the substitution.

The screenshot shows the GTK file dialog styled with breeze-gtk.

To reproduce on openSUSE Tumbleweed (GTK3 3.22):

XDG_CURRENT_DESKTOP=gnome gwenview

However, doing the same on KDE Neon (GTK3 3.18) shows a GTK file picker with the file name.

In conclusion, this is either a regression in GTK3 or the "qgnomeplatform" QPA (both distros had Qt 5.9.1) behaves differently for different GTK versions. Probably best to open a ticket over at qt.io?

Also, on Tumbleweed I get this:

(gwenview:4572): Gtk-CRITICAL **: gtk_file_chooser_default_set_current_name: assertion 'impl->action == GTK_FILE_CHOOSER_ACTION_SAVE || impl->action == GTK_FILE_CHOOSER_ACTION_CREATE_FOLDER' failed

Now that you mention it, I see that all my KDE applications (just checked with Kate and Kompare), and when running the Gwenview workflow I described above, I see the GTK warning described in comment #11 -  even though I'm running under Plasma:

$ declare -x | grep XDG
declare -x XDG_CONFIG_DIRS="/etc/xdg/xdg-/usr/share/xsessions/plasma:/etc/xdg/xdg-/usr/share/xsessions/plasma:/etc/xdg:/usr/share/kubuntu-default-settings/kf5-settings"
declare -x XDG_CURRENT_DESKTOP="KDE"
declare -x XDG_DATA_DIRS="/usr/share//usr/share/xsessions/plasma:/usr/share//usr/share/xsessions/plasma:/home/odeda//.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share:/var/lib/snapd/desktop:/var/lib/snapd/desktop"
declare -x XDG_RUNTIME_DIR="/run/user/1000"
declare -x XDG_SEAT="seat0"
declare -x XDG_SEAT_PATH="/org/freedesktop/DisplayManager/Seat0"
declare -x XDG_SESSION_CLASS="user"
declare -x XDG_SESSION_DESKTOP="KDE"
declare -x XDG_SESSION_ID="3"
declare -x XDG_SESSION_PATH="/org/freedesktop/DisplayManager/Session1"
declare -x XDG_SESSION_TYPE="x11"
declare -x XDG_VTNR="7"

I am running with Qt 5.9.1:

$ qtdiag  | head -n1
Qt 5.9.1 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 7.2.0) on "xcb"

I'm not really interested that much with GTK+ inter-op, but its really weird that KDE apps are using GTK+ dialog - how would I turn this off?

Are you using the Fedora KDE spin, or did you install Plasma on top of a stock Fedora install with GNOME? If the latter, there's probably some subtle conflict and I would recommend reinstalling with the Fedora KDE spin for a better user experience and fewer weird bugs like this.

@Nate: It says Kubuntu…

> /home/odeda//.local/share/flatpak
Don't know much about Flatpak, but are you possibly running Gwenview via Flatpak? There might be still some integration issues like the one you see…

> how would I turn this off?
Not sure we can help you with that. Plasma's default config in general should not show GTK dialogs. This is either a change you or your distro did.

Try running /usr/bin/gwenview or ask in the Kubuntu forums.

I'm running Kubuntu Artful with KDE staging PPAs.


(In reply to Henrik Fehlauer from comment #14)
> > /home/odeda//.local/share/flatpak
> Don't know much about Flatpak, but are you possibly running Gwenview via
> Flatpak?

No - I'm running Plasma and KDE apps installed as native Ubuntu system packages.

The problem is apparently caused by the Ubuntu package qt5-style-plugins that was installed as a dependency of the budgie-desktop package. When that package is installed, it provides the file /usr/lib/x86_64-linux-gnu/qt5/plugins/platformthemes/libqgtk2.so which when exists causes QT to use it for file dialogs - I'm not sure why but I think this calls for a bug report on that package.

When I remove this package, Gwenview uses the KDE file dialog where everything works fine. Thanks for helping me figuring this out!

If anyone else encounters such a problem and get here, here's the actual problem: the Ubuntu package budgie-desktop-common sets up a file /etc/profile.d/10-budgie-desktop.sh that defines an environment variable called QT_QPA_PLATFORMTHEME to "gtk2" causing all QT application to load the GTK+ dialogs instead of the default KDE dialogs.

This is definitely a bug in the Budgie desktop setup that is not respecting other desktops and forces a configuration that breaks expected behaviors of other environments. I've opened a ticket on this here: https://bugs.launchpad.net/ubuntu/+source/budgie-desktop-environment/+bug/1727796

>           What    |Removed                     |Added
>         Resolution|UPSTREAM                    |DOWNSTREAM
@Nate: I still think the original issue (name not appearing in dialog) is upstream (GTK or Qt). What you mean is the GTK dialog appearing at all (Oded's issue), but that's not what this bug originally was about :)

@Oded: Thanks for keeping us up-to-date :) If you have the patience, it would be great if you could  also report the bug in the GTK dialog to Qt or GTK (which IMHO is valid), even if you can workaround it by using KDE's dialog.

Ach, this is what happens when I try to do bug screening on complicated bugs that have been repurposed to track other issues when sick. I'll bow out now. :)

(In reply to Henrik Fehlauer from comment #17)
> @Nate: I still think the original issue (name not appearing in dialog) is
> upstream (GTK or Qt). What you mean is the GTK dialog appearing at all
> (Oded's issue), but that's not what this bug originally was about :)
> 
> @Oded: Thanks for keeping us up-to-date :) If you have the patience, it
> would be great if you could  also report the bug in the GTK dialog to Qt or
> GTK (which IMHO is valid), even if you can workaround it by using KDE's
> dialog.

After investigating it a bit more, I'm not convinced that the problem is in the Qt adapter or the GTK library - as I failed to reproduce the problem with kdialog.

My initial test was to see which platform themes exhibit the problem by setting QT_QPA_PLATFORMTHEME to different available platform themes and see how Gwenview's move/copy/link dialog behaves. I can get correct operation with the default (KDE) platform theme as well as with the GTK+3 theme. Only the GTK+2 theme exhibit the problem.

I then tried to reproduce the problem with the same platform theme configurations using kdialog --getsavefilename /path/to/dir/suggested.file . Using this setup *all* platform themes correctly pre-populate suggested.file in the file dialog's file name.

So now it looks to me as the problem is in Gwenview. Any suggestions for other things I can test?

Thanks for your continued investigations, Oded. Did some more testing and discovered it can be misleading to use XDG_CURRENT_DESKTOP=gnome, because depending on distro and env this results in either a GTK2 or a GTK3 dialog (i.e. scratch my previous finding about this being a GTK3 regression).

Proper test matrix, confirming your observations:

BROKEN:
QT_QPA_PLATFORMTHEME=gtk2 gwenview ~/Pictures

WORKING:
QT_QPA_PLATFORMTHEME=gtk2 kdialog --getsavefilename ~/file.ext
QT_QPA_PLATFORMTHEME=gtk2 kate ~/file.ext
QT_QPA_PLATFORMTHEME=gtk3 gwenview ~/Pictures
QT_QPA_PLATFORMTHEME=gtk3 kdialog --getsavefilename ~/file.ext
QT_QPA_PLATFORMTHEME=gtk3 kate ~/file.ext

This is a bit weird, I wonder why that is. Maybe because kdialog is a standalone app? However, testing with Kate (open file, trigger "save as"), GTK2 also works. I guess the next step would be to compare the code snippets responsible for opening the dialog in Gwenview and Kate respectively (let me know if you are interested and need help in getting started with this). Note this does not yet mean Gwenview is at fault :)

In general Gwenview is supposed to work in a GTK environment, but I'm not sure which desktops are still stuck on GTK2 and have no plans of migrating to GTK3. I'm reopening and adapting the title a bit, but I don't think the issue is of high priority and users can set GTK3 for Gwenview as a workaround for now.