Bug 452943 - Opening a file does not work
Summary: Opening a file does not work
Status: RESOLVED DUPLICATE of bug 441802
Alias: None
Product: okteta
Classification: Applications
Component: general (show other bugs)
Version: 0.26.7
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Friedrich W. H. Kossebau
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-04-24 10:28 UTC by Aaron Williams
Modified: 2022-05-05 15:15 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Aaron Williams 2022-04-24 10:28:27 UTC
SUMMARY
Clicking on File->Open and selecting a file does not open the new file

STEPS TO REPRODUCE
1.  Open okteta with an existing file
2.  Click Open->File and select another file
3.  Observe nothing happens, no new tab is opened for the new file.

OBSERVED RESULT
No file is open

EXPECTED RESULT
I expect another tab to show up with the new file

SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 
KDE Frameworks Version: 5.93.0
Qt Version: 5.15.2

ADDITIONAL INFORMATION
Comment 1 Friedrich W. H. Kossebau 2022-04-24 10:42:25 UTC
Thanks for the report. Though works here (openSUSE TW, KF 5.93, Qt 5.15.2, Plasma env).

To find what special case might trigger things for you, please give more detail, for a start where the selected file is stored, local filesystem or not, any special filesystem mount, which file picker dialog is used (Plasma/KDE or something else).
Comment 2 Aaron Williams 2022-04-25 04:47:02 UTC
It does not matter what file I choose. Whenever I attempt to open any file in the GUI, nothing happens, no matter if the file is a standard file under /home/[user] or any other file. All files are readable. This is extremely repeatable. All files are local.

1. At the command prompt type "okteta"
2. Click open and select a file, any file.
3. Watch absolutely nothing happen. No file is displayed.

If, on the other hand, I pass a filename or multiple filenames on the command line, that works fine. I have also tried file->open.

Note that new does work and saving a file works, only open is totally broken.
Comment 3 Friedrich W. H. Kossebau 2022-04-25 10:59:58 UTC
What workspace are you using? For now I would suspect the platformtheme integration plugin has a broken file dialog implementation, as the QFileDialog is the main difference here in the code paths when loading a file via the file picking UI or from the commandline. The actual file dialog itself is provided by the platform theme integration plugin, and Okteta relies on the public API with the signal QFileDialog::urlsSelected to properly provide the selected files as list of QUrls. If that is broken, if will also be broken for others, so nothing to work-around in Okteta.

No idea right now how to find out which platformtheme integration plugin is actually used/picked.

But can you please try and manually enforce a certain one and try loading files for comparison, e.g. by starting okteta via the extra args "okteta --platformtheme gtk2" (see also other options in /usr/lib64/qt5/plugins/platformthemes).

What workspace/desktop environment are you using, and which Linux flavour/distribution (and version)?
Comment 4 Friedrich W. H. Kossebau 2022-04-25 11:31:12 UTC
I now remember that a similar issue had been reported in bug 441802, can we assume your issues seen have the same cause?
Comment 5 Friedrich W. H. Kossebau 2022-05-05 15:15:13 UTC
All things heard point to the same cause, so closing as duplicate.

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