In D28034#643194, @ngraham wrote:

Yeah, the PC3 busy indicator component itself seems to be to blame for items 1 and 3. I'll look into it.

I hadn't really considered #2 as a valid use case while working on the component, but I can look into it.

Both issues fixed, however I found two news:

1. Getting file:///usr/lib64/qt5/qml/org/kde/plasma/extras/ExpandableListItem.qml:438:13: QML BusyIndicator: Binding loop detected for property "implicitHeight" spammed in terminal from plasmashell process, but this is not related to this review.
2. You are not able to disconnect a connection which is being activated, for example when you accidentally click on one to connect and want to stop it, I don't know if it's super important, but it was there and I'm using it from time to time (wanted to use it right now).
3. I'm thinking of not using the busy indicator, it makes the UI to lag and I have been experiencing it recently and it's super annoying, I don't know it's the rendering process or what, but everytime I activate a connection, the UI is super slow until it connects. Might be combination of the busy indicator and something in the background, but not using the busy indicator made it significantly less laggy. Do you experince it as well?

Update to fix review comments

Seems to work with all functionality working as before, well done!! Just few details:

If there are objections to this change, we can just make all the opened files automatically writable.

In D27783#632940, @ngraham wrote:

Ah, thanks. LGTM. Would you be okay with me submitting a patch to alter/polish the UI after it lands?

For the record, GTK file dialog has same option:

In D28218#632909, @ngraham wrote:

In D28218#632907, @jgrulich wrote:

but you can restrict the write access if you don't the sandboxed application to modify the file.

Under what circumstance would you want that?

In D27783#632900, @ngraham wrote:

Ok. When trying to compile I get the following:

In file included from ../libportal/portal-qt5.h:20,
                 from libportal-qt/a370903@@LibPortalQt@sha/../../../libportal-qt/portal_p.h:24,
                 from libportal-qt/a370903@@LibPortalQt@sha/../../../libportal-qt/parent_p.h:21,
                 from libportal-qt/a370903@@LibPortalQt@sha/moc_parent_p.cpp:10:
../libportal/portal.h:20:10: fatal error: libportal/portal-enums.h: No such file or directory
   20 | #include <libportal/portal-enums.h>
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~

More generally, what does this thing do? What's it for?

In D28218#632902, @ngraham wrote:

Hmm, this seems like the kind of nerdy exposing-implementation-details thing that would be problematic from a UX standpoint. I can see the use cases for wanting to open a read-only file read-write so you can actually save to it, but I think a better UX for this might be to ask the user right at the point of use, rather than putting a custom checkbox in the dialog.

And what's the use case for wanting to open a read-write file read-only?

In D28218#632843, @apol wrote:

This is a feature we generally don't show. What's the use-case?

In D27783#632600, @ngraham wrote:

How can I test this?

Avoid potential crash when captured variable goes out of scope

Replace my custom function for quoting of arguments with KShell

In D27783#630734, @ngraham wrote:

UserInfoDialog.qml an Item with a Rectangle in it, could you use a Window?

https://doc.qt.io/qt-5/qml-qtquick-window-window.html

I thought I already had support for this, maybe it got lost somewhere. Looks good otherwise.

I would approve, but @ngraham requested some changes.

I would say it's not a big deal as we use groupboxes quite a lot in plasma-nm. We can get rid of them in future when rewriting the KCM to QML.

In D27764#621204, @dkosovic wrote:

In D27764#621173, @jgrulich wrote:

@dkosovic will you update the review to address my comments?

I agree with all your comments and they are great nitpicks and suggestions.

Sorry I didn't have time tonight to work on testing everything and submitting an updated patch. I'm guessing submitting an updated patch is what I need to do for the review?

@dkosovic will you update the review to address my comments?

Don't use deprecated color

One thing I'm not sure about whether to use viewBackgroundColor or just backgroundColor, because I want the buttons to look like they are part of the view.

Only nitpicking, otherwise it looks good to me.

Looks this changed introduced an issue. The traffic monitor doesn't fit into the applet.

Makes sense.

It will need rebase, there are some changes in master now which will be conflicting. Other than that I think it looks good, but I would like Nate to approve this from the UI point of view.

In D27643#618132, @fvogt wrote:

In D27643#618125, @jgrulich wrote:

I have never used fuse. I see you can use kio-fuse over dbus to mount a file, but you still have to unmount it, which will be a problem, because from the portal I don't know whether the app is still using it or not.

kio-fuse was designed with this in mind and does not even support unmounting. When the file isn't being used anymore, it drops everything except what's needed to reopen the file when requested.

If anyone is familiar with fuse and have solution in mind, can you give me a hint?

In this case it would be as easy as just calling org.kde.KIOFuse org.kde.KIOFuse.VFS mountUrl with the url and it gets a local path back.

This should ideally be handled transparently by the KDE file dialog though.

I have never used fuse. I see you can use kio-fuse over dbus to mount a file, but you still have to unmount it, which will be a problem, because from the portal I don't know whether the app is still using it or not.

In D27287#617316, @Kanedias wrote:

Well, okay. I'm not happy that the whole code just got bulkier because of PW 0.3, but that's the only concern.
If you have time on your hands, please split this into two distinct implementations (PWFrameBufferV02 and PWFrameBufferV03) so you won't need to wrack your brains around #ifs in the future