I made merge request for storageAccessFromPath: https://invent.kde.org/frameworks/solid/-/merge_requests/8

I have created a Merge Request on GitLab with a a couple new commits.

In D28745#675709, @bruns wrote:

In D28745#675698, @marcingu wrote:

How often do I have to repeat the thumbnailer has to use the canonical path anyway? Please use that.

storageAccessFromPath converts given path into canonical. I figured it should do so anyway, so I'm not doing it again here.

And thats wrong. You need the canonical path in the thumbnailer itself.

In D28745#675698, @marcingu wrote:

How often do I have to repeat the thumbnailer has to use the canonical path anyway? Please use that.

storageAccessFromPath converts given path into canonical. I figured it should do so anyway, so I'm not doing it again here.

How often do I have to repeat the thumbnailer has to use the canonical path anyway? Please use that.

In D28745#675685, @marcingu wrote:

Solid::Device device = Solid::Device::storageAccessFromPath(filePath);
if (device.is<Solid::StorageVolume>()) {
    allowCache = device.as<Solid::StorageVolume>()->usage() != Solid::StorageVolume::UsageType::Encrypted;
}

for (Device device: list) {
    StorageAccess *storageAccess = device.as<StorageAccess>();
    if (canonPath.startsWith(storageAccess->filePath()) && storageAccess->filePath().size() > match_length) {
        match_length = storageAccess->filePath().size();
        match = device;
    }

Ok, so far I have implemented Solid::Device::storageAccessFromPath by talking all StorageAccess devices, going though all of them and and returning proper one.
code:

Solid::Device Solid::Device::storageAccessFromPath(const QString &path)
{
    // TODO check if symlinks are in the path
    QFileInfo fileInfo = QFileInfo(path);
    if (!fileInfo.exists()) {
        //TODO error handling
    }
    QSet<QString> checked; //To avoid weird infinete loops
    checked.insert(fileInfo.path());
    while (fileInfo.isSymLink()) {
        fileInfo = QFileInfo(fileInfo.symLinkTarget());
        if (checked.contains(fileInfo.path())) {
            //TODO error handling
        }
        checked.insert(fileInfo.path());
    }
    QDir dir = fileInfo.dir();
    QString canonPath = dir.canonicalPath();
    QList<Device> list = Solid::Device::listFromType(DeviceInterface::Type::StorageAccess);
    Device match;
    int match_length = 0;
    for (Device device: list) {
        StorageAccess *storageAccess = device.as<StorageAccess>();
        if (canonPath.startsWith(storageAccess->filePath()) && storageAccess->filePath().size() > match_length) {
            match_length = storageAccess->filePath().size();
            match = device;
        }
    }
    return match;
}

I think having 44x44 and 150x150 icons is just a matter of scaling the ones we have, they are a SVG anyways.
I think the hard part is that somebody needs to check if all things work ok for the binary factory builds and later care about the reported issues.

I use Dolphin from the binary factory. I can test dolphin builds if needed.

-> Moved to: https://invent.kde.org/system/dolphin/-/merge_requests/21

In T12308#216754, @manueljlin wrote:

dolphin with breadcrumbs inside view

Definitely please do continue with this patch, and maybe link to it on invent in here.

In D28745#675033, @marcingu wrote:

Ok, so, what I want to do now is to create static method findByPath which is going to return Solid::StorageVolume instance (is there a case in which we can expect something different than StorageVolume?).

Ok, so, what I want to do now is to create static method findByPath which is going to return Solid::StorageVolume instance (is there a case in which we can expect something different than StorageVolume?).

In D28745#674863, @meven wrote:

In D28745#674827, @bruns wrote:

In D28745#674711, @meven wrote:

Solid does not provide straight folder => StorageVolume yet, but I think Solid could have such a utility feature added.
Something like Solid::Device::findByPath(), it would need to canonically and recursively resolves the path parent to pay attention to symlinks.
This would also help D26407

No recursion needed, stat provides the device.

Only when the file is not a symlink, if so we need to check the symlink target recursively, that's what I meant.

Yep, looks great!

In D28745#674827, @bruns wrote:

In D28745#674711, @meven wrote:

Solid does not provide straight folder => StorageVolume yet, but I think Solid could have such a utility feature added.
Something like Solid::Device::findByPath(), it would need to canonically and recursively resolves the path parent to pay attention to symlinks.
This would also help D26407

No recursion needed, stat provides the device.

@ngraham Does the UI look good? Can we ship this?

Closing as discussed.

Sorry for the delay :(

And can you please use arc to upload the patch - it is nearly impossible to do a review with the missing context

In D28745#674711, @meven wrote:

In D28745#674294, @marcingu wrote:

I tried to research Solid using api.kde.org (https://api.kde.org/frameworks/solid/html/classSolid_1_1Device.html, https://api.kde.org/frameworks/solid/html/classSolid_1_1StorageVolume.html) and looking for usages of both Solid::Device and Solid::StorageVolume in code but I'm not able to get StorageVolume instance for given file/directory.

Ping! I'm not able to continue without help of someone who knows Solid::Device well.

I guess waiting for approval didn't go anywhere. I'll continue work on this soon then and I'll move it to invent.kde.org.

Will merge soonish if @elvisangelaccio has nothing to say

Rename member field to m_ready

I tried to research Solid using api.kde.org (https://api.kde.org/frameworks/solid/html/classSolid_1_1Device.html, https://api.kde.org/frameworks/solid/html/classSolid_1_1StorageVolume.html) and looking for usages of both Solid::Device and Solid::StorageVolume in code but I'm not able to get StorageVolume instance for given file/directory. Could someone help me with that?

Any progress @felixernst ?

In D29805#674225, @pino wrote:

In D29805#674218, @meven wrote:

In D29805#674206, @pino wrote:

In D29805#674205, @meven wrote:

In D29805#674204, @pino wrote:

FIXED-IN: 20.08

still for 20.08...

Yes kio-extra is released with KDE Applications

Yes, I know. Asked to land this fix instead to release/20.04, and thus change the commit message accordingly.

Please be explicit when you comment, no one could deduce what you meant.

I wrote it two times to land this on the stable branch: the first time when I explained why the initial patch was not correct and what the problem actually was (with hints on short term and long term fixes), and earlier today when I wrote:

In D29805#674185, @pino wrote:

please target release/20.04 for this fix, thanks

There is no need to "deduce" anything, just read what I wrote, thanks.

If this is ready approve and add a comment "land to 20.04".

The commit message still says "20.08", so not yet.

In D29805#674218, @meven wrote:

In D29805#674206, @pino wrote:

In D29805#674205, @meven wrote:

In D29805#674204, @pino wrote:

FIXED-IN: 20.08

still for 20.08...

Yes kio-extra is released with KDE Applications

Yes, I know. Asked to land this fix instead to release/20.04, and thus change the commit message accordingly.

Please be explicit when you comment, no one could deduce what you meant.

In D29805#674206, @pino wrote:

In D29805#674205, @meven wrote:

In D29805#674204, @pino wrote:

FIXED-IN: 20.08

still for 20.08...

Yes kio-extra is released with KDE Applications

Yes, I know. Asked to land this fix instead to release/20.04, and thus change the commit message accordingly.

In D29805#674205, @meven wrote:

In D29805#674204, @pino wrote:

FIXED-IN: 20.08

still for 20.08...

Yes kio-extra is released with KDE Applications

In D29805#674204, @pino wrote:

FIXED-IN: 20.08

still for 20.08...

still for 20.08...

Remove brackets

please target release/20.04 for this fix, thanks

LGTM

In D29213#670124, @ngraham wrote:

+1, though I see a brief flicker of the widget when I switch between two views where it's hidden, such as recentlyused:/files/ and recentlyused:/locations/ can you reproduce?

A a shown and ready bool to manage the state of the statusbarspaceinfo

ping @pino

Moved to https://invent.kde.org/network/kio-extras/-/merge_requests/2

Will land after KF 5.71 release

Update patch to new dependency

Thank you for reviewing the rev, Hannah! I've merged the parent rev and hence updated libssh to use version 0.9.4 by default in Craft. If we can merge this we would get 🟢 for kio-extras builds. \o/

It will need quite some work to rebase indded, since this introduce the concept of having context menu actions in DolphinViewActionHandler and this is now a few weeks old...
I might rename DolphinViewActionHandler to simply DolphinActionHandler since this will be more relevant.
I believe the code will overall be in better shape that previous with more code delegated to DolphinViewActionHandler rather that bloating forever DolphinView and DolphinMainWindow.
Might move to gitlab directly as this is just in the infancy of the review.

This has some merge conflicts if I try to rebase it on current master Can you rebase it?

In D29169#673777, @ngraham wrote:

Sorry for the delay in reviewing. This is a large and somewhat intimidating patch :) I will check it out soon.

Sorry for the delay in reviewing. This is a large and somewhat intimidating patch :) I will check it out soon.

(once the dependent patch lands)

(once the dependent patches have landed)

Not sure if this should go to release/20.04, but I guess it shouldn't hurt.

ping reviewers

Blocked by D28590

@pino ping

In D28337#648844, @meven wrote:

Solid only sends broadcast notification and doesn't wait for any reply, thus unmounting may fail due to preview jobs not stopping in time.

That points to a solid shortcoming worth fixing. Adding a wait for apps to ask solid to wait or to wait by default for instance 20-50ms between tearDownRequested and teardownDone

Great job, that's perfect! You can close this now.

In terms of interaction, this feels great to me! I wonder, do you think you could move the patch to https://invent.kde.org/system/dolphin/-/merge_requests/? We've recently migrated to GitLab and are trying to stop using Phabricator.

In terms of interaction, this feels great to me! I wonder, do you think you could move the patch to https://invent.kde.org/system/dolphin/-/merge_requests/? We've recently migrated to GitLab and are trying to stop using Phabricator.

• fix the stuck TapAndHold indicator
• add a small animation to TapAndHold indicator
• set minimal speed, lower for swipe gesture

Browsing the code it looks like it mmaps the file though? And when I add some strategic sleeping I can verify that file goes towards shared memory.

I am only half satisfied by the patch.
Mostly because of libmagic magic_load that loads a 5M file each time which is not needed to detect encoding.

LGTM. Seeing as I don't have much background knowledge I'm not comfortable accepting though. I guess if nobody comes up with better options by next week feel free to land.

Use QByteArray, find typo, code style and naming

Second commit :
https://invent.kde.org/system/dolphin/-/merge_requests/3

Atomic first commit in :
https://invent.kde.org/system/dolphin/-/merge_requests/2

Will probably send to gitlab ;)

Haha the "before" image is hilarious!