-
Notifications
You must be signed in to change notification settings - Fork 161
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement Task to quickly sync files #37
Conversation
You have made a lot of progress :) Do like to completely finish this or should we merge the main parts earlier and then later add additional features? Could you please either confirm the CLA and/or add yourself to the contributors file? Because you own the rights to all your changes (not just new files), and your PR would then be covered by different licenses, which is a legal nightmare. |
I will add myself to the contributors file :D Yes and no. There are some things that are fine if they are not fixed for a release, but some should be taken care of beforehand. (Especially codestyle and the ui) I will mark what i deem nessessary, and if you want to add/change priorities you can tell me (or edit the message directly? Is that possible?) |
Sorry, I did not want to rush this. I was thinking of these items...
...which imho aren't really merge blockers.
Also looking through the commits, firebase seems to cause a bit of a struggle when building. It might be a good idea to wrap that in a noop implementation that is replaced in release builds. |
@x0b I think for now i am done. I have added some new icons, i tried my best :D if anyone wants to redo them, thats fine by me ^^ this is far from perfect, but i guess it will be useful. Should i squash this? |
I would rebase it on top of the latest release, fix/squash the commits and then merge it. If you want less work with merge conflicts, I'd wait until 1.11 is merged into master (currently only in preview). I haven't yet had the time to try out the current version, but it looks great. |
Sorry, I accidentally deleted the base branch because it was no longer protected. What do you think, how far along are you with the feature? |
I think this is more or less done. If you dont see any issues with the code, or with something else i dont think there is a reason to not merge it |
Okay, I've pulled your changes and started rebasing them onto the latest master. This was required because development has diverged significatly from the original app, e.g. Gradle, Java 8, AndroidX, etc. The changes will be documented in git history, if you are interested. A few ideas for later versions:
|
return sw.toString(); | ||
} | ||
|
||
public static void storeFile(Activity activity, String content) throws IOException { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
String xml = Exporter.create(activity); | ||
Exporter.storeFile(activity, xml); | ||
} catch (ParserConfigurationException | TransformerException | IOException e) { | ||
e.printStackTrace(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Always use FLog with appropriate log level and log tag (create log tags with logt
shortcut). E.g. FLog.e(TAG, "Error when exporting tasks", e)
Note: These comments are examples of things I'm changing before merging this into master - don't worry, you don't have to do this yourself. |
@x0b do you want me to fix the issues you mentioned? That way we could merge it, if you are busy atm |
Sorry, this was a bit of a onboarding/collaboration/communicaton failure on my part. When I initially pulled your code, I thought It would be ready to merge with a simple rebase. Unfortunately, the rcx code base has deviated quite a bit from the original rcloneExplorer code base - AndroidX, Java 8, View Binding - just on the tooling side. And it also needs to integrate properly with new rcx features like renaming remotes. I did that before this reply. And then I started actually reviewing your code, and noticed that it differed wildly in quality from the existing project code. And here is where I failed. I noticed more and more things that needed to be changed, and it just seemed ridiculous to add a review comment for all of them, and I also knew that I lacked the time to work with you on those things - I thought it would be more efficient if I just quickly solved those things and then later explained why. However, I did not consider the time needed to actually implement those changes, so progress has been slow. Unfortunately, I haven't yet pushed the current state back to GitHub, but I can do that tomorrow or at the latest on the week. That way, you can work on it without me blocking you. |
Ah okay :D what do you want me to do? I'd still like this feature, should i reimplement this or are you on it? |
E.g. I'll push the current state to this branch on the weekend (I don't have it with me unfortunately) - it's 80% where it should be, so it should be relatively easy for you to continue working on this. |
I don't seem to have access rights to your branch, so I've pushed it to rcx/pull/37 - It is rebased on top of 1.11.3, so you'll need to pull it into a new branch ( |
@x0b I didn't think you would actually have rebased my code onto the new rcx-base, it's quite impressive! Two things: i tested syncing two small files (with the rclone binary from 1.11.3) and it is extremely slow (1 or 2 b/s). Is that a known issue or is it just me? Second: you mentioned that my code lacks quality, which i will not deny. But could you point me to stuff that should be improved, so that i can do that? From now on, all my work will be based of your pull/37 branch |
For small files the transaction itself probably takes a significant time. I have not experienced slow speeds though - can you cross-check against executing the same command in Termux + rclone? If Termux is faster, we might be using rclone inefficiently.
There is a lot of commentary in 2a19150, and there are also a few TODOs I didn't manage to address. For specific feedback, update this PR by force-pushing the Some things that I might comment on might not be "wrong", rather than unnecessarily unusual. For a project with our line count, it is very important to keep the code as readable and maintainable as possible, which means using the same style and approaches as the rest of the code base. |
For the slow speeds: I found out that it was the bruteforce protection of nextcloud that delayed everything. It seems that my initial builds with a wrong password triggered the protection. For the rest: i will do that, and hopefully we can merge this soon! On a sidenote, it's offtopic but i didnt want to open a new ticket for that, it would be cool if you could make the link to "https://x0b.github.io/dev/" a little more visible in the page, or maybe add an index. to make finding it a little bit easier :D |
Good that that's solved. I was afraid we were doing something stupid with rclone.
The dev page is linked from the README, but the website is still a work in progress. I'll look into the index thing. |
Just checking in if you are still up for this? I am currently extremely busy and won't have the time to make further adjustments to release this. I'm planning a release in 2-3 weeks. Also, GitHub support has informed me that they have successfully detached this repo from kaczmarkiewiczp'. They have further explained that you will have to create a new PR for that. Also, I'm planning on completing the move to the new app name and structure, which means we should merge your PR before that to avoid conflicts. |
closed in favor of #84 |
Also see original pull request.
Additional features:
Further bugs: