You can actually cut/paste in finder - just little different. You copy a file with Cmd+C, then paste it somewhere with Cmd+Option+V (instead of usual Cmd+V) and voila you have cut the file.
One of the very few apps I actually paid for. The mental peace that comes with not leaking my data to yet another calendar application alone was worth it. I find this business model lot more sensible than demanding that open-source developers should eternally martyr themselves. You can see the effect of this in the feature set of these applications.
If you are the semi-paranoid kind, the following stack of opensource apps will enable you to keep a calendar/contacts/tasks in sync between Linux and android without an internet connection.
On Android Side
1. Simple Calendar
2. Dec Sync (Fdroid)
3. SyncThing
On Linux Side
1. SyncThing
2. Evolution with Decsync plugin
What Decsync does is keep your calendar/contacts/tasks data in a single folder in open format. This can be read on GNU+Linux side with any app that has a Decsync plugin. This folder can be backed up using whatever is your backup solution (For those who are curious - I do a encrypted incremental backup with BorgBackup (Vorta GUI) and then upload to cloud using Rclone).
Decysnc also supports syncing RSS feeds between applications, although I have not been able to find a working Linux RSS app that has Decsync plugin.
It's nice that a flow exists for your use case, but when I see things like this I'm always puzzled by the use case in the first place. The only reason I use a calendar on my phone is to sync my schedule with the wife/family. We put things on a shared calendar. I use it to capture appointments and check if we have commitments on a given date. Otherwise I would never use a calendar on my phone. So syncing between accounts over the Internet is a hard requirement.
In that case why don't you sync your calendar with Nextcloud directly using CalDav?
I use DavX5 for this and it works great, actually i think DecSync is a fork of DavX5.
1. Data is saved in SQlite. I am at 33k notes and it springs open instantaneously.
2. Notes can be arranged into arbitrarily deep tree. Single note can be placed into multiple places in the tree. (Think soft-links)
3. WYSIWYG support (CKEditor)
4. Tags, advanced scripting features
5. Other ususal wiki stuff like backlinks, note-map etc
Cons:
1. Electron.
2. Data is saved in SQlite, not plain text.
It supports various types of file stores for syncing between devices. I've used OneDrive and WebDAV. The project has also recently launched a cloud service for people who want to sync between devices but don't want to set up a network file store.
Having a proper database for note systems isn't necessarily a bad idea. For large knowledge bases, it lets you do arbitrary queries at least somewhat efficiently. Many apps just limit the kinds of searches/queries you can do, but eventually you end up needing to have an ad hoc query optimizer and planner or for users to have control over query evaluation so they can do the optimization themselves.
However, you could probably still use sqlite for analytic queries by just creating an in-memory or temporary database at startup then watching for file changes to keep the database consistent. Creating this database probably won't take that long unless you are trying to store all of Wikipedia in your knowledge base.
I love trilium, in fact I think I'm going to start a hosting service for it (built-in syncing mechanism). For a few reasons: 1. Sync to allow the sharing of notes publicly, which allows you to create simple websites very quickly. 2. Instant access as long as you have a browser. 3. As a backup. It's an incredible application and I'm proud to have contributed to it in the past no matter how little.
As a rule, I try to minimize the number of electron applications. Suppose I am reading something in my web browser and want to jot down something. Be it firefox and chrome, the demands on RAM is considerable at this point. An electron note taking app and VSCodium are also usually open side by side. God forbid if I have to open a fourth application and that is also electron, my system will start to mildly grumble. Note here, my system while not exactly a gaming behemoth, ain't no potato either.
I am not blind to the advantages electron brings to a developer. Including electron as a con is in no way a critic of the developer but a expression of disbelief that the developer world has not yet managed to agree upon and popularize a reasonable electron alternative.
PS: Webview hoards memory in linux for some reason.
consider it as a feature request, but if you really plan to match github pages, I hope you will eventually include an on the fly renderer for org-mode files too, like GitHub. Markdown serving packages are dime a dozen, I am yet to see something that will serve org files without having to export first.
Sorry, to be clear the tool is designed to make it easier to locally test your static HTML GitHub Pages repos, where things like a `/about` link will not resolve in the context of your filesystem and likely also won't know to check for `about.html`. I'm not trying to make sites equivalent to GitHub Pages from other sources. Does GitHub Pages actually support org-mode? That's certainly news to me, and if so I'll take a look into how it works and whether I can add support.
- Modularity: I would like it if I could open a folder with the app, and the app will interpret some meta file in the folder to understand settings for that folder. This will ensure that it is scalable. I can open another folder with app in addition to, or by appending to existing folder.
- Interlinking of notes.
- Tagging at least at file level.
- Ability to add yaml metadata to files and search the metadata fields of multiple files/all files in current folder.
- Ability to set a default notebook/folder and create quick notes in that folder.
- Ability to extend via plugins written in a major language.
Yeah, it sucks.