Merge lp://staging/~nikwen/ubuntu-filemanager-app/zips into lp://staging/ubuntu-filemanager-app

This one should contain all new files now. :)

I have freshly updated image (r299) and I don't have unzip on my phone. So I can't say this or that to this merge request for now, perhaps it's coming in a later image?

Other than that, I'm just pondering... might it be more logical to have an Archiver application, that would register itself for Content-Hub for archives. Then clicking on a zip/tar/tar.gz file could have as target the Archiver where you could extract it. That way archives could be handled from other apps also not just from File Manager. I'm not sure how well Content-Hub is suited for such scenario, so this is just me thinking aloud.

Hello guys,

How about having all open files stuff available to all applications not only for file manager?

It could be part of Content-Hub or a separated module, as Qt provides Qt::openUrlExternally() we would have something similar as Ubuntu API, so all applications can open files just calling one method.

unzip landed in the rtm image back on 16th Oct. See http://people.canonical.com/~ogra/touch-image-stats/rtm/112.changes

I'd recommend re-flashing (without wiping) your device using the "ubuntu-touch/ubuntu-rtm/14.09-proposed" channel.

Something like this should do it:-

ubuntu-device-flash --channel=ubuntu-touch/ubuntu-rtm/14.09-proposed

As an aside I'll find out why it didn't land in devel-proposed.

With Alan Pope's instructions I got this branch working. Thanks a lot for the good work!

Is it possible to add a "cancel" button to the dialog where it's extracting files? Doing a call on external programs there's always a chance that things get stuck for a variety of reasons. Being able to cancel the operation in such situations is much preferable compared to user having to kill whole FileManager and starting anew.

But if the above suggestion is too much work for this merge proposal, I'll happily approve the current one. It's a great feature.

The image contains many more possibilities for extracting files, containing at least tar, gunzip and bzip2. After this commit lands to trunk I will file bugs to add support for more supported archives. If you can work on those too that'd be just great.

Thank you very much for reviewing this.
A cancel button looks like a good addition. I won't be able to look into this before the weekend but then I'll finally do it. I'll check how easy aborting a QProccess is.
I planned to enable extracting for more archive types anyway but I first wanted to make sure this one gets merged. Expect me to do some work on that matter. ;)

Some time ago, I looked into building an archiver application to push to the store as well but that proved to be fairly difficult as running commands like "unzip" or "tar" requires the application to run unconfined. One would therefore have to write a wrapper for respective Qt libraries so adding this functionality to the file manager seemed to be easier.

Just found a close() function so it should be possible: http://qt-project.org/doc/qt-5/qprocess.html#close

> Just found a close() function so it should be possible: http://qt-
> project.org/doc/qt-5/qprocess.html#close

Great! If you can try to include that cancel into this merge request, that would be awesome. If it's not straightforward and requires more time then do comment and we'll merge this as it is, and you can continue on another branch on the cancel button.

Regarding the Content-Hub stuff me and Carlos were talking about. I think that would be better, but since it's not clear how well Content-Hub is suited for this kind of stuff it's probably best to leave for future to ponder about.

Hi, I'm sorry to say that but I didn't have the time to work on the cancel button (well, to do any coding) this weekend. I'll try to do it as soon as possible but I'll probably not be able to do it before next weekend.

> Hi, I'm sorry to say that but I didn't have the time to work on the cancel
> button (well, to do any coding) this weekend. I'll try to do it as soon as
> possible but I'll probably not be able to do it before next weekend.

Thanks for the heads-up! Let's approve this change, and when you have time to work on the cancel button that would be a great improvement.

Thank you!

Thanks for approving this. I will for sure look into adding a cancel button and into adding more archive formats like tars as soon as I have time for that. :)

OK. Let's release one more improvement to the filemanager.

FAILED: Autolanding.
No commit message was specified in the merge proposal. Hit 'Add commit message' on the merge proposal web page or follow the link below. You can approve the merge proposal yourself to rerun.
https://code.launchpad.net/~nikwen/ubuntu-filemanager-app/zips/+merge/239662/+edit-commit-message

Rerun autolanding

Hm, the comment above says the following: "You can approve the merge proposal yourself to rerun."
However, autolanding hasn't been rerun yet. Does anyone know how to trigger that properly?

Needs top-level approve I think to rerun the tests. Done, let's see what happens.

FAILED: Autolanding.
More details in the following jenkins job:
http://91.189.93.70:8080/job/ubuntu-filemanager-app-autolanding/158/
Executed test runs:
    UNSTABLE: http://91.189.93.70:8080/job/generic-mediumtests-vivid/56
        deb: http://91.189.93.70:8080/job/generic-mediumtests-vivid/56/artifact/work/output/*zip*/output.zip
    SUCCESS: http://91.189.93.70:8080/job/ubuntu-filemanager-app-vivid-amd64-autolanding/1

Ah, thanks for doing this. I've never contributed code to the core apps before so I didn't know that.
Did I break the tests with my changes or have they been broken before as well?

Can someone with autopilot/Jenkins test experience help with that? It seems like a newQML plugin "Archives" is not detected when running Jenkins. It's nevertheless built without problems locally.

@ajalkane: Would you mind retriggering the tests by doing another top-level approve? I don't seem to have the rights to do this.
The reason why I didn't look into this earlier was that I didn't find the test logs before...

Oh, sorry. I forgot to add a file. I'll add it now.

There you go. ;)

FAILED: Autolanding.
More details in the following jenkins job:
http://91.189.93.70:8080/job/ubuntu-filemanager-app-autolanding/160/
Executed test runs:
    UNSTABLE: http://91.189.93.70:8080/job/generic-mediumtests-vivid/152
        deb: http://91.189.93.70:8080/job/generic-mediumtests-vivid/152/artifact/work/output/*zip*/output.zip
    SUCCESS: http://91.189.93.70:8080/job/ubuntu-filemanager-app-vivid-amd64-autolanding/3

Ah, great. At least that worked now. Still two tests to fix though. I'll look into them later. ;)

Does anyone know what was wrong with the tests? I've never done automatic testing before and haven't managed to get the tests to run on my device. Anyone who could help me with that?
I just merged trunk as well. Maybe that will fix the tests. Would require another top-level approve to run them again though...

Thank you for your patience. :)

Niklas,

it seems the "Cut" action somehow triggers extracting action in this new code:

http://91.189.93.70:8080/job/generic-mediumtests-vivid/152/artifact/filemanager.tests.test_filemanager.TestFolderListPage.test_cut_file.ogv

Looks like the test failures show 'cut'-ing a file brings up the extract archive prompt, which it shouldn't.

I would also like to see some tests added to support this new functionality. Ideally the tests would extract and verify a zip, but at least running through the menu options would be good.

FAILED: Autolanding.
More details in the following jenkins job:
http://91.189.93.70:8080/job/ubuntu-filemanager-app-autolanding/162/
Executed test runs:
    UNSTABLE: http://91.189.93.70:8080/job/generic-mediumtests-vivid/258
        deb: http://91.189.93.70:8080/job/generic-mediumtests-vivid/258/artifact/work/output/*zip*/output.zip
    SUCCESS: http://91.189.93.70:8080/job/ubuntu-filemanager-app-vivid-amd64-autolanding/5

Ah, thank you very much for looking into this. That's something which I should be able to fix and I think I know why it happens. There is some strange behaviour regarding the visible attribute of an Action in an ActionList. Let me have a look at it this weekend. ;)

Regarding tests for archive extraction: I've never worked with autopilot before and, sadly, I don't have enough time to learn about automatic testing at the moment. (I'd love to do so much more coding but I can't...)
So if you really need them, someone else will have to do it for now.

> Ah, thank you very much for looking into this. That's something which I should
> be able to fix and I think I know why it happens. There is some strange
> behaviour regarding the visible attribute of an Action in an ActionList. Let
> me have a look at it this weekend. ;)

Thanks!

> Regarding tests for archive extraction: I've never worked with autopilot
> before and, sadly, I don't have enough time to learn about automatic testing
> at the moment. (I'd love to do so much more coding but I can't...)
> So if you really need them, someone else will have to do it for now.

That's understandable. If you can fix it so that existing tests run, maybe we can file a bug about the missing test cases for later implementation if that's okay with all parties?

I think my latest commit should fix the issue for now. It's actually a workaround since the bug is in the code for the ActionSelectionPopover. It doesn't set the visible property of the list items to false according to the visible property of the Action.
I'll file a bug and submit a merge proposal to upstream tomorrow. Please don't approve that change until then so that I can add the issue and MP links to the comment in the code. ;)

Thanks. :)

Can you link the bug you worked around in source please?

> Can you link the bug you worked around in source please?

That's exactly what I wanted to do. I just filed the bug report, created a merge proposal for the UI Toolkit and adjusted the comment (as well as the workaround code so that it's like in the other MP).
Could someone please do a top-level approve again to see whether it passes the tests? I think it will.
Thanks to all of you for your help and patience. :)

FAILED: Autolanding.
More details in the following jenkins job:
http://91.189.93.70:8080/job/ubuntu-filemanager-app-autolanding/164/
Executed test runs:
    UNSTABLE: http://91.189.93.70:8080/job/generic-mediumtests-vivid/340
        deb: http://91.189.93.70:8080/job/generic-mediumtests-vivid/340/artifact/work/output/*zip*/output.zip
    SUCCESS: http://91.189.93.70:8080/job/ubuntu-filemanager-app-vivid-amd64-autolanding/7

Ah, sorry. I forgot to change a variable name when copying the workaround code into the filemanager code.

PASSED: Continuous integration, rev:320
http://91.189.93.70:8080/job/ubuntu-filemanager-app-ci/405/
Executed test runs:
    SUCCESS: http://91.189.93.70:8080/job/generic-mediumtests-vivid/367
        deb: http://91.189.93.70:8080/job/generic-mediumtests-vivid/367/artifact/work/output/*zip*/output.zip
    SUCCESS: http://91.189.93.70:8080/job/ubuntu-filemanager-app-vivid-amd64-ci/27

Click here to trigger a rebuild:
http://91.189.93.70:8080/job/ubuntu-filemanager-app-ci/405/rebuild

Thanks for approving it again. I'm glad it finally passed the tests.
Why is its status still "Needs review"? May I change it to "Approved"? (I do now have the ability to do that for some reason.)

Ah, I know why I am able to approve this now if I want to. For some reason I was added to the "Ubuntu Core Apps Test Writers" team which makes me an indirect member of the file manager app team.
Nicholas, would you mind telling me why I was added to that team (not that I want to leave it :p)?

Niklas I added you to the team so jenkins would automatically build things for you. You've helped out in several core apps, it makes sense to have jenkins autorun on your mp's :-)

Thank you very much, Nicholas. I really appreciate it. :)

My other question still remains though: Is there still anything missing to get this merged? Or will it be done automatically later?

> My other question still remains though: Is there still anything missing to get
> this merged?

Nope, I will try top-approving again and it should get merged if there's no issues.

> My other question still remains though: Is there still anything missing to get
> this merged?

Nope, I will try top-approving again and it should get merged if there's no issues.

Ok, great. So it was finally merged. :)
I'll file issues for missing features in the extraction process (like the cancel button or other archive types) tomorrow and assign as many as I can deal with to me.

Thank you very, very much. :)

No, thank you very much for your great contributions to make File Manager better! I'm very happy that this gets now merged.

Hopeful to see more contributions when you have the time, and it's a big help even if it's filing bug reports as then we have something concrete to track on!

Ok, I didn't have the time today to file those bugs but I will definitely do that as soon as possible.
For now, there's the MP for extracting tar archives. ;)
https://code.launchpad.net/~nikwen/ubuntu-filemanager-app/tars/+merge/240986

Here are the bugs I reported:

https://bugs.launchpad.net/ubuntu-filemanager-app/+bug/1397058
https://bugs.launchpad.net/ubuntu-filemanager-app/+bug/1397060
https://bugs.launchpad.net/ubuntu-filemanager-app/+bug/1397070
https://bugs.launchpad.net/ubuntu-filemanager-app/+bug/1397072