Hi @bruns - did you have a chance to go through this patch again? Am I missing anything to move on with this?

Review comments

@bruns - thanks a lot for the feedback, I have updated the patch with your suggestions.

Addressed review comments

Hi @bruns - I have updated this patch with the changes you requested and would really like your feedback :)

Updated patch with review comments

In D26600#596631, @bruns wrote:

and this is definitely too much code being moved around. Please split this up into multiple reviews.

You should likely start with the introduction of the FilesystemEntry class, use that from the existing code.

In D26600#596533, @bruns wrote:

Moving existing code to new files does not make you the copyright owner.

I have refactored the fstab handling to make supporting fuseiso _much_ simpler - so please take a look at D26600 - once that is merged I will push a new review of this patch.

@meven - I am a little unsure if I have broken the fix you have done in commit c97f0b2a3076731b35435f200bd09a22859f3e03 - could you please check?

Sorry for breaking the build :/

@davidedmundson - ping ;)

@bruns - ping ;)

In D25125#558043, @anthonyfieroni wrote:

Set QT_PLUGIN_PATH to you local path with plugin after that set the system path for others
QT_PLUGIN_PATH=/local/path:/system/path executable

Note that I haven't tested this patch locally because I don't know how to "run" the locally compiled devicenotifier. I can see that I get a plasma_engine_devicenotifications.so library from building the project, but I don't know how to "run" it, do we have a cli tool to load the shared library for testing? Or how do you guys test?

@bruns - ping :) I have updated this patch with the changes you requested, I hope you are ok with it now.

Review comments

Review comments

Reorder functions to make diff smaller

@bruns - I have now refactored the patch so that it uses the getmntent functions for parsing the mtab file, so I think this patch is pretty much ready for a serious review ;)

Rewrite to use the getmntent function for parsing the mtab file

Currently you have the 'unmount' action if you right click on the device in dolphin, but it cannot unmount, so should we hide it? Or should we fix it so that it can actually unmount?

Implemented parsing of the fuseiso mtab file

@davidedmundson ping :)

Updated to use KListOpenFilesJob

In D24434#542440, @dfaure wrote:

Argh, I retagged, but this wasn't pushed yet.
Landing and retagging again...

@dfaure - I just found that if you include KListOpenFilesJob from e.g. Dolphin then it fails because it cannot include jobs/kjob.h :(

In D24389#541644, @dfaure wrote:

git tag doesn't show any 5.63.0-rc* tag yet, so it hasn't been tagged, so this commit will be included.

(I do that on the first Saturday of the month)

In D24389#541539, @ngraham wrote:

Please land this ASAP so it gets into Frameworks 5.63.

In D19989#540686, @meven wrote:

We can now restart this work leveraging KCoreAddon KListOpenFilesJo D21760 .

In D19989#540686, @meven wrote:

We can now restart this work leveraging KCoreAddon KListOpenFilesJo D21760 .

In D21235#536576, @hallas wrote:

In D21235#535951, @bruns wrote:

In D21235#535861, @hallas wrote:

I have been resurrecting this patch again :) and have run into an issue I need some guidance on. To be able to parse the ~/.mtab.fuseiso file I would like to use the KMountPoint class, but this class currently resides in KIO which Solid doesn't depend on. But, KIO actually depends on Solid so would it be an option to move this class from KIO to Solid?

What do you gain by using KMountPoints? Solid already has code for parsing fstab style files.

Hi @bruns , no you are right that I should be able to do with the code that is in Solid already. It just needs to be updated to be able parse an arbitrary mtab file. But anyhow, the fstab/mtab code in Solid seems kind of duplicated with the code in KIO, so we might consolidate at some point.

But let me look into the mtab code in Solid and see if I can make it work there :)

In D19311#539582, @elvisangelaccio wrote:

@hallas I noticed the following warning on dolphin start:

KXMLGUIFactoryPrivate::saveDefaultActionProperties(): Shortcut for action  "go_forward" "&Forward" set with QAction::setShortcut()! Use KActionCollection::setDefaultShortcut(s) instead.

Could you have a look? Maybe it's because we call actionCollection()->setDefaultShortcuts(m_backAction, backShortcuts); and we don't do the same for m_forwardAction ?

Review comments

In D21235#535951, @bruns wrote:

In D21235#535861, @hallas wrote:

I have been resurrecting this patch again :) and have run into an issue I need some guidance on. To be able to parse the ~/.mtab.fuseiso file I would like to use the KMountPoint class, but this class currently resides in KIO which Solid doesn't depend on. But, KIO actually depends on Solid so would it be an option to move this class from KIO to Solid?

What do you gain by using KMountPoints? Solid already has code for parsing fstab style files.

I have been resurrecting this patch again :) and have run into an issue I need some guidance on. To be able to parse the ~/.mtab.fuseiso file I would like to use the KMountPoint class, but this class currently resides in KIO which Solid doesn't depend on. But, KIO actually depends on Solid so would it be an option to move this class from KIO to Solid?

In D19311#534728, @ngraham wrote:

Just noticed that Alt+left/right shortcuts for back and forward are now broken.

Fix Back/Forward shortcuts

@davidedmundson - ping :)

Restrict the number of navigation entries to 12

Use QSKIP to skip tests

Use QStandardPaths::findExecutable to locate lsof

Updated @since

In D19311#527963, @ngraham wrote:

Thanks @hallas. I'm good with this now. For the future, I would like one of the following UI improvements:

• Show no visible arrow at all (i.e. what web browsers do)
• Make the downward-pointing arrow be really tiny and sit in the bottom-right corner of a square toolbutton, rather than making the toolbutton wider to accommodate it

In D19311#527071, @felixernst wrote:

Thanks for the analysis :) I still think we should get the change in with the current KToolBarPopupAction functionality (like Nate suggest), and then work on refining the user experience. But feel free to pinch in on the user experience part.

This is such a big discussion already. Which suggestion of Nate do you refer to specifically? I thought the current approach that shows indicators was denied.

Rebased

In D19311#526881, @felixernst wrote:

In D19311#508519, @hallas wrote:

We have previously discussed various ways to simplify this change, but no other suitable solutions has been found, but I am still open to simpler solutions :)

This is what I think can produce the wanted behaviour:
KToolBarPopupAction uses QToolButton internally so Indicators are drawn (because of style rules if I understand correctly). If there is no way to use QToolButton and hide indicators without forcing style changes (which was blocked) then it seems to me like the only way forward is not using a QToolButton.
AFAICT there are two ways forward:

• Further modify KToolBarPopupAction to not use QToolButton internally in the case of menuIndicator being turned off and instead internally implement the same behaviour using some other button class. The QAbstractButton with it's pressed and clicked signals might be enough to handle it but there are possibly more fitting specialised button classes. This way no changes to the Breeze style or any other style for that matter should be necessary.
• It might be a bit difficult to imitate the behaviour of KToolBarPopupAction without using a QToolButton so alternatively it might be easier to not modify KToolBarPopupAction at all and create or use a different class. In this case you don't have to mimic all options of KToolBarPopupAction perfectly since it is expected that the new class behaves differently. You could then copy from/use Falkon's NavigationBarToolButton (like @david.fontanals suggested in D19311#432597) . I'm pretty sure the license of that class is incompatible with frameworks though so that would have to be handled if it's supposed to land in KWidgetAddons.
  
  Take my analysis with a grain of salt though since it is mainly based on me reading documentation without having ever actually tried similar stuff.

In D19311#526869, @ngraham wrote:

Hmm, can you rebase it on master?

In D21760#526652, @dfaure wrote:

This is good to go in :-)

If you push it today it'll indeed be in 5.62, to be tagged tomorrow, otherwise we'll need to adjust the @since tag ;-)

Review comments

In D19311#526124, @ngraham wrote:

At this point I'm inclined to say that we should go forward with the patch regardless of widget changes, because otherwise it's gonna be stuck in patch review limbo forever.

Can you make the menu show up on press-and-hold without showing any arrow on the buttons without widget changes? That's probably the simplest path forward until we sort out the appearance issue. Better to temporarily make it semi-hidden than never getting it landed. :)

In D19311#526466, @nerdopolist wrote:

Dolphin appears to not compile without F6773036 in KWidgetAddons though. All I can find for F6773036 is the diff. Is there a Dxxxxx thing in phab for that?

In D19311#526124, @ngraham wrote:

At this point I'm inclined to say that we should go forward with the patch regardless of widget changes, because otherwise it's gonna be stuck in patch review limbo forever.

Can you make the menu show up on press-and-hold without showing any arrow on the buttons without widget changes? That's probably the simplest path forward until we sort out the appearance issue. Better to temporarily make it semi-hidden than never getting it landed. :)

Review comments, renamed the files to match the class name

In D21760#525842, @dfaure wrote:

Yes, the filenames should match the classname, obviously :)

I did a deeper review of the KJob usage and I have two more comments, sorry for not taking the time to do this earlier...

In D19311#525778, @nerdopolist wrote:

Looks good. I do have a weird occurrence with three slashes appearing in the path for

seems when I leave and reenter, then leave the home dir.

In D21760#524860, @dfaure wrote:

Given that the namespace doesn't contain anything else anymore, I would just get rid of it, and provide a single class, KListOpenFilesJob.