[ToDo] Check and document, if cloud-storage options work

[Olf0]

Check and document (here), if the other web- / cloud-storage options still work: Box, Google Drive, OneDrive, WebDAV (used by e.g. OwnCloud / NextCloud)
Note that Dropbox is known to fail, but nobody has yet tried to address it: See issue #4 for details.

For each one which fails, concisely denote what is failing (login, file transfer etc.) and provide the exact error message, preferably as copied text (alternatively as a screenshot). Also start FileCase at the command line (simply type filecase), repeat the action which results in an error and copy & paste the relevant output here (i.e ignore all the output at application startup).

[Logic-gate]

Hey, cheers for getting filecase up and running again.

A few notes on Drive; If I am not mistaken, filecase uses OOB, which has since been deprecated.

If that is the case, and this is to save you a lot of hassle, is to use InstalledAppFlow.

Here's the discussion we had for Cargo. Logic-gate/harbour-cargo#6

And the python implementation
Logic-gate/harbour-cargo@a3ee5e1

[Logic-gate]

I think it would be wise to unify efforts into a singular app(filecase) for all cloud services. Having it decentralized as it is now is not the best approach in my opinion.

We have Ghostcloud for generic webdav(nextcloud and owncloud).

Cargo for Drive.

Cargo Dock for dropbox(doesn't work as far as I can tell).

Unifying efforts into a singular app is the best approach.

I cant promise anything, but I'll have a look at the code for Drive and will try to reach out to @fredldotme for Ghostcloud.

Even if the implementation is done via exposing some filecase apis to the different apps. As in an implementation of an internal api scheme for filecase so that apps like Ghostcloud can integrate with filecase without having a bloated codebase. Allowing for each app to exist independently and as a module to filecase. Although this is beyond the scope of filecase, and I imagine your vision for it.

[Logic-gate]

A quick fix to Webdav is to comment out all _labelItem.opacity: 1
here:

filecase/qml/pages/AddWebDavAccount.qml

Line 68 in 1516d80

_labelItem.opacity: 1

filecase/qml/pages/AddWebDavAccount.qml

Line 81 in 1516d80

_labelItem.opacity: 1

filecase/qml/pages/AddWebDavAccount.qml

Line 93 in 1516d80

_labelItem.opacity: 1

filecase/qml/pages/AddWebDavAccount.qml

Line 105 in 1516d80

_labelItem.opacity: 1

filecase/qml/pages/AddWebDavAccount.qml

Line 117 in 1516d80

_labelItem.opacity: 1

filecase/qml/pages/AddWebDavAccount.qml

Line 129 in 1516d80

_labelItem.opacity: 1

and to add port.text as an argument in Button since createAccount takes 6 args as defined here

filecase/src/webdav.cpp

Line 886 in 1516d80

void WebDav::createAccount(QString name, QString host, QString path, QString user, QString pass, QString port)

port.text here

filecase/qml/pages/AddWebDavAccount.qml

Line 149 in 1516d80

webdav.createAccount(name.text, host.text, path.text, user.text, pass.text)

Not worthy of a PR, just a quick fix until everything is sorted it.

Tested on nextcloud with app password.
Although I am not entirely sure how to upload files.

[Olf0]

Oh, I am a bit behind your considerations and efforts.

I think it would be wise to unify efforts into a singular app(filecase) for all cloud services. […] Although this is beyond the scope of filecase, and I imagine your vision for it.

Well, the scope of and vision for FileCase is as one defines it: you, me, anybody!

My personal goal was to resurrect FileCase (SailJail config etc.) and provide a better infrastructure, e.g. by using Transifex and implementing CI workflows at GitHub. As a matter of fact by doing this I became the maintainer of FileCase, a role I will try to continue fulfilling.

Note that I am not a developer, my C++ and QML skills are limited; as the original developer (Matias Perez) ceased to develop FileCase in 2015 there is no FileCase developer ever since (but you sure can become one).

I am glad about any contributions and will check, if they make sense before merging them in my role as maintainer; but note that my capabilities to perform profound checks are limited due to my limited C++ and QML skills. Hence I would be very happy, if you have someone else to review your code contributions first; well, if not, so be it, good coders (and code reviewers) are scarce.

What I can help with are architectural discussions, as I have had a decade of IT software project management experience. So back to this topic: Currently I do not really understand, why FileCase should rather provide APIs for other clients to access cloud-storage providers than to implement this accesses in FileCase. Mind that every additional function requires code to be written and maintained, plus offering APIs for other apps requires interaction with the developers of these apps. Hence IMO first and foremost efforts should be directed at restoring the cloud-storage functionality which was once there by adapting FileCase to the current APIs of the cloud storage providers. Practically there is little I can do to support these efforts, because I am not using any cloud storage provider (but consider to use WebDAV for OwnCloud, but that is a long term project).

Big picture

The general situation of file managers for SailfishOS is not nice, the only minimalistically maintained one is File Browser, which does not provide any cloud storage access; real development for it has ceased years ago. The two cool file managers in 2015 were Cargo Dock and FileCase (I always preferred FileCase for its usability), but development for both stopped before 2020 and Cargo Dock seems to be fully unmaintained since 2021.

So if you decide FileCase's code base is sound and not too hard to understand (and Cargo Dock is not vastly better in this regard), it makes sense to improve FileCase, because here you have at least me for performing some administrative work. If Cargo Dock's code base is much better, you may be better off enhancing it instead of FileCase. And it is all open source software, you may take code from either file manager and reuse it in the other, if you like (ignoring unlikely licence incompatibilities).

P.S.

WRT your code rectifying post: Yes, Jolla has altered some QML properties since 2015, so it can well be that _labelItem.opacity: 1 causes incorrect rendering on recent SailfishOS releases (so consistently commenting them out is a perfect solution) and you are absolutely right on the argument count mismatch for WebDav::createAccount, i.e. the missing port.text argument on the QML side. I am exited to see how your full resolution of this mismatch will look like. 😃

[Logic-gate]

why FileCase should rather provide APIs for other clients to access cloud-storage providers than to implement this accesses in FileCase. ......Hence IMO first and foremost efforts should be directed at restoring the cloud-storage functionality which was once there by adapting FileCase to the current APIs of the cloud storage providers.

I concede to the "exposing Filecase's API" idea.

Since your experience is in project management--a plus to any project--you should have complete control over what tasks and issues should be addressed first. I went ahead and detailed a few things from my perspective(https://ghamama.openproject.com/projects/filecase/work_packages) and will work accordingly. Idea?

[Olf0]

Since your experience is in project management--a plus to any project--you should have complete control over what tasks and issues should be addressed first.

Well, in contrast to a formal project manager role at work ("real job"), I am just the maintainer here. As I have no external contractor(s) or subordinate employees to direct, I am dependent on voluntary contributions. Additionally it should be a positive, self-determined experience for any contributor.

I went ahead and detailed a few things from my perspective(https://ghamama.openproject.com/projects/filecase/work_packages) and will work accordingly.

Oh, this is cool, because it provides a nice overview, keep track of the progress, allows for detecting interdependencies early (as with all good planning tools) and to dynamically adjust anything easily, if necessary.

Thank you very much, also (on a more abstract level) for making your plans so transparent.

Idea?

As I am originally an (electrical) engineer (M.sc.), I love practical approaches, hence I suggest:

1. To pick the easiest or most interesting (for you) cloud storage service and make it working again. IIRC you are already almost there with WebDAV.
2. Create a PR, I will review it, merge it and create a new release. IMO there is no reason for special releases, as the working functionality (local file accesses) should be unharmed. (I should try to address issue Submit FileCase to SailfishOS:Chum #28 at the upcoming weekend, so a release reaches more people.)
3. Either you or me then can create a new thread at FSO, asking for people to test. I would suggest you, because you earn the merits / visibility, I can still add additional info in a separate message, if needed. But if you rather want to concentrate on coding, I can sure do that instead.

Then there is something to build upon, which allows for public testing of each new feature implemented. I see multiple options how to proceed from there:

• Work on the other cloud storage services one by one, and finally address the GUI work.
  • Pro: If a cloud service has special GUI requirements (information to display etc.), this is know before working on then GUI.
  • Con: A long time with no visible improvements.
• Do the GUI work first and test it with the single, working cloud storage service, then address the other cloud storage services.
  • Pro: Visible improvements first.
  • Cons: GUI may need to be slightly adapted for a specific cloud service later on. And less people who test the GUI improvements, because there is only one working cloud service.
• A mix of both: Implement the easiest or two easiest GUI tasks (out of tasks 88, 87, 85), then the other cloud services and the finalise the GUI.

These are just my suggestions / considerations (hope they are helpful), as you drive the whole cloud storage thing, proceed as you like.

[fredldotme]

I think it would be wise to unify efforts into a singular app(filecase) for all cloud services. Having it decentralized as it is now is not the best approach in my opinion.

We have Ghostcloud for generic webdav(nextcloud and owncloud).

Cargo for Drive.

Cargo Dock for dropbox(doesn't work as far as I can tell).

Unifying efforts into a singular app is the best approach.

I cant promise anything, but I'll have a look at the code for Drive and will try to reach out to @fredldotme for Ghostcloud.

Even if the implementation is done via exposing some filecase apis to the different apps. As in an implementation of an internal api scheme for filecase so that apps like Ghostcloud can integrate with filecase without having a bloated codebase. Allowing for each app to exist independently and as a module to filecase. Although this is beyond the scope of filecase, and I imagine your vision for it.

Sorry for just responding yet, wanted to wait for a bit. Anyhow GhostCloud in and of itself is built for exactly that, namely plugging in Providers in the common core code (LGPLV2.1) and have that transparently be handled by the application code (which exists for Silica as well as QuickControls).

There is no special requirement, the Provider in GhostCloud can adapt to that API use as seen fit, one could even pass them as transparently as an IO object and have QFile-like semantics (ie transparent copies across hosts through a direct IO pipe).

[Olf0]

Topic: NextCloud / OwnCloud / WebDAV by GhostCloud

I assume you are both talking about https://github.com/fredldotme/harbour-owncloud/ , correct? I am asking, because no link was provided; hope I picked the right repo, because there are others being called "GhostCloud" and this one is not (well, in the README).

Also I fail to comprehend (logically) what both of you are stating:

1. Even if the implementation is done via exposing some filecase apis to the different apps. As in an implementation of an internal api scheme for filecase so that apps like Ghostcloud can integrate with filecase without having a bloated codebase. Allowing for each app to exist independently and as a module to filecase.

2. […] GhostCloud […] is built for […] plugging in Providers in the common core code (LGPLV2.1) […]

• Why should GhostCloud use FileCase as a WebDAV provider? AFAIU GhostCloud is a WebDAV provider.
• Why should FileCase expose APIs to GhostCloud? In my understanding it may theoretically make sense to import GhostCloud as a git submodule and use its APIs for WebDAV.
• Why should GhostCloud integrate ("with") FileCase, instead of FileCase integrating GhostCloud's core code?

But after all FileCase extant WebDAV code seems to be functional, only some GUI elements do not render properly any longer. So why investing effort into some kind of integration? It creates a dependency (on git, library or RPM level) and rather increases the maintenance burden than reducing it.

[fredldotme]

Topic: NextCloud / OwnCloud / WebDAV by GhostCloud

I assume you are both talking about https://github.com/fredldotme/harbour-owncloud/ , correct? I am asking, because no link was provided; hope I picked the right repo, because there are others being called "GhostCloud" and this one is not (well, in the README).

Also I fail to comprehend (logically) what both of you are stating:

1. Even if the implementation is done via exposing some filecase apis to the different apps. As in an implementation of an internal api scheme for filecase so that apps like Ghostcloud can integrate with filecase without having a bloated codebase. Allowing for each app to exist independently and as a module to filecase.

2. […] GhostCloud […] is built for […] plugging in Providers in the common core code (LGPLV2.1) […]

• Why should GhostCloud use FileCase as a WebDAV provider? AFAIU GhostCloud is a WebDAV provider.
• Why should FileCase expose APIs to GhostCloud? In my understanding it may theoretically make sense to import GhostCloud as a git submodule and use its APIs for WebDAV.
• Why should GhostCloud integrate ("with") FileCase, instead of FileCase integrating GhostCloud's core code?

But after all FileCase extant WebDAV code seems to be functional, only some GUI elements do not render properly any longer. So why investing effort into som kind of integration? It creates a dependency (on git, library or RPM level) and rather increases the maintenance burden than reducing it.

I have no clue, I would rather think if this app is wanting to support something with GhostCloud it might be through their use of our common code, which ships everything incl Providers. I was mentioned here, I didn't start it TBH so I don't know whats going on here, just making sure to make opportunities obvious though.

[Logic-gate]

I have no clue, I would rather think if this app is wanting to support something with GhostCloud it might be through their use of our common code, which ships everything incl Providers. I was mentioned here, I didn't start it TBH so I don't know whats going on here, just making sure to make opportunities obvious though.

It's my fault. I was thinking out loud and have conceded to @Olf0 point on not having any api's exposed as it will be wasteful for both projects. My idea was to unify efforts by means of having a singular access point to all cloud services. But I see now that this is by no means the best approach. Perhaps the shift should be in development efforts rather than on merging projects.

@Olf0 Webdav should be ready for testing:
devel...Logic-gate:filecase:devel

Fixes include:

• Fix QML rendering error in AddWebDavAccount -- Removal of all _labelItem.opacity: 1 and the addition of port.text

• Fix Transfer View For Webdav Upload -- This needs to be rechecked since I removed Sailfish.TransferEngine and used Sailfish.Share It works fine, but I am not sure if it's the intention of it, since it only shows cloud services. I'll retest with multiple webdav accounts later today.

• Fix Webdav Upload -- This entails the change in src/transfers.cpp. It was throwing a Segmentation Fault and fishing for the cause led me to simply select the first element in the list. I suspect it has to do with the changes in UploadFiles.qml

Tested on Nextcloud. Simple changes here and there. Nothing major.

Also, I found a lot of translations in my repo which were not merged, didnt want to mess up anything...I'll leave the git stuff to you 😵‍💫

[Olf0]

@Logic-gate, please see PR Logic-gate#2; let us break out the implementation and discussion of WebDAV specifics to the subsequent PR of that, so this issue / thread can return to its original purpose: Check and document, if cloud-storage options work

[Olf0]

It's my fault. I was thinking out loud and have conceded to @Olf0 point on not having any api's exposed as it will be wasteful for both projects. My idea was to unify efforts by means of having a singular access point to all cloud services. But I see now that this is by no means the best approach. Perhaps the shift should be in development efforts rather than on merging projects.

Well, it is no fault to initially believe that consolidating duplicate or similar functionality into a single, common piece of code is the optimal approach. Technically it even may be in many cases, specifically when starting from the scratch (i.e. without any extant code), but a purely technical perspective omits many other aspects, e.g. social ones (the efforts of collaboration, communication etc.).

Also, I found a lot of translations in my repo which were not merged, didnt want to mess up anything...I'll leave the git stuff to you 😵‍💫

Do you mean you have translation updates at hand? If so, please pose a separate PR with (only) these, after we have resolved, why you do not seem to be able to pose PRs.

[Olf0]

For using a common component for accessing WebDAV, see also this comment in PR #60 WRT mhaller's qwebdavlib.