Android Notes App: where to contribute?

I am looking for help on where to consider beginning contributions to some of the core Android apps. Taking the “Android Notes” app as an example, should issues, feature requests, or merge requests be against the /e/ notes gitlab instance or instead at the upstream nextcloud notes github instance

Since I don’t see a way to create an issue at the /e/ gitlab instance, I guess maybe it is better to consider contributing to the Nextcloud Notes github? The question is how closely matching upstream do the /e/ forked android apps seek to remain? Would updates to upstream trickle to /e/ or instead will these projects diverge more and more until the /e/ notes app won’t be tracking upstream as closely?

Regain your privacy! Adopt /e/OS the unGoogled mobile OS and online servicesphone

For Notes I think you get a change more quickly merged if you MR against downstream and upstream both. If your MR needs an separate issue to be explained, for external contributors I guess creating a backlog entry helps.

/e/ replaces the account lookup that upstream Notes has a dependency on for the official nextcloud client. Merging 3.7.1 beginning of 2023 was a major upgrade after years on 1.x and I think the only update for years.

Going with “contribute” through has some FAQs too.

1 Like

Thank you for the time to reply. As a followup question if you don’t mind: is it mainly (or only?) about the automatic account configuration with that has been the motivation for /e/ to fork the various apps that integrate with nextcloud, saving the user some confusion of getting their account configured and set up? I guess I am wondering about why fork the apps, thus splitting any collaborative development momentum if this is the only reason?

I hope you don’t feel I am criticizing /e/, but a bit of insight would be helpful in considering contributing to /e/ vs. only working upstream with the nextcloud team. I am positively impressed with what /e/ is doing, but am wondering about the working relationships with upstream and why not work more directly with them?

1 Like

It’s fair to scrutinize and find a way to meaningfully contribute.

As to reasons why to fork, I think it is both: using DAVx5 centrally for all *dav-dependant Apps, easing onboarding through the first-time-setup-wizard and creating a common look&feel towards “a product” in a narrow timespan. What forking “giveth, it taketh away” in momentum, agreed. They’d be good fireside-type questions for Romain/Vincent/Gaël on choices made.

Now Nextcloud Notes the Android App imo has an unfortunate architecture. It works well for Nextcloud users, but personally I’d have gone device-local first with versioning integrated.

Did you have a specific itch to scratch with Notes that motivates you?

1 Like

The main thing I am looking at is facilitating others to migrate away from google services on their existing google play enabled devices. I have used the same approach for years in getting people to consider Linux by first putting LibreOffice and Thunderbird on their Windows (or macOS) laptops. Then when they are comfortable with new ways to work with their data a change of the underlying OS is relatively trivial (and an improvement for them rather that the point they find that “nothing works”).

Anyway, that is a wordy introduction to note that moving shared grocery lists to murena is the step I am at. I would add nextcloud to the existing phone, they would use it and move away from google services, then consider their next phone to be with /e/ and google-less. On to shared shopping items: Notes does not allow re-ordering of shopping items (and moving completed items to the bottom: this is less necessary but still nice). As of right now, when you need to add an item, you are back to plain text mode. Yes you can hit return on an existing checklist item and the - [ ] is created on a new line for a new checkbox, but it will not be friendly for those I am targeting, esp if you want to re-order the items.

I tried “carnet” which is more rich in graphical functionality, but is slow and a bit clunky, and also questionable in sync. Since it does it as a database linked to a task calendar instead of a simple text file I was not as eager to do it that way.

I did try tasks, it was a bit more of a challenge for a simple checklist, it will not be accepted by others looking for simple non-nested checklists I fear, and again I would prefer plain text files if possible. Let nextcloud do what it does well: sync files and manage conflicts!

I tried “nextcloud deck” which also isn’t quite right for this case (but will do nicely to replace my personal task lists from Trello), and once again works with tasks not text files.

What I liked about notes is that it is plain text files, the syncing is handled by nextcloud. The Notes are easy to share by just making a folder under ~/Notes/ in and sharing that with another user. But the graphical interaction is cumbersome as noted above. I did find a proposed MR that has been rejected upstream due to it being difficult to handle multiple checklists in a single note. But what I envision is more like what G Keep does by “converting” a text note to a checklist and vice-versa. If it is a “checklist” it is only a checklist, so don’t have to worry about all the complication of possibility of multiple checklists in a single note, etc. I would think if you open a note and it only has a title and a checklist then it could be identified as a checklist (only) and thus expose more GUI friendly ways to manage it (again checking an item would strike it and move it to the bottom, and have friendly “handles” on the side of each item to re-order them). If it is a checklist as part of a note with other text, then do not expose the handles for re-ordering, treat it as “just text”

I have tried quillpad which does both of these things nicely against the stock Nextcloud Notes folder text files, giving the features of re-ordering with handles, and completed items to the bottom. You do need to add the nextcloud app and log into murena as a nextcloud instance. It seems that its syncing feature is a bit buggy and was causing edit conflicts.

So I was considering looking at quillpad code and evalutating if those features could be incorporated to the Nextcloud or /e/ Android Notes app. Rather than coding from scratch it would be a better possibility to see about re-using so I could learn a bit more about how the app is written.


Well I did try Quillpad some more and honestly it is meeting all the design needs I was missing with Notes. I do get some complaints if I attempt to then open a note edited in quillpad in Notes that “it was edited outside” so it asks if I want to revert edits. But I don’t think this is Quillpad’s problem specifically, I don’t see it losing edits as long as I refresh before opening to make sure in sync. I think in general that there isn’t a “locking” mechanism for the Notes files and this could be a risk but isn’t more risky with Quillpad than other Notes apps.

(I like reading long reviews)

Quillpad was recommended by users before. I think it’s solid, nowadays a better default app on a few dimensions. It hasn’t got a powerful versioning system though.

Here’s a good integration task:

Working upstream on Quillpad to use the official library would ease effort required to use it as shipped default app (a switch that I think is unlikely to happen but more likely with that work already done).