- cross-posted to:
- rust@programming.dev
- cross-posted to:
- rust@programming.dev
Hello again everyone, Dihar here. It’s been a while since the last release of treedome, but here you go! This release is all about UI update, emojis, and bug fixes. Please consult this git diff
for a more detailed changelog https://codeberg.org/solver-orgz/treedome/compare/0.4.5...0.5.0. These are the highlight of the release.
- Add emoji picker for title, will show up in tree!
- Text Editor toolbar is back, now with option to toggle both toolbar and floating menu independently!
- Checkbox is here! Thanks Mantine UI!
- You can check the size of each notes by navigating to Escape Menu -> Configure -> Show Note Sizes!
- Add created/last modified date in notes. Note created before this will not have this field and will set as today’s date!
- Create child note can now be done through dropdown instead of only from shortcuts!
- Fix bugs of saving empty tree
- General UI update and more stability for auto scrolling in tree view
- Documentation update
Yeah but as far as i can tell it still has extensions (see this) , there is no process including RFC where a standard is ratified like ISO/ECMA does for stuff like HTML/javascript/C++ or the open document format. i have some stuff that is more then a decade old that really don’t want to lose.
the extension could cease to exist, but you can absolutely still access your notes with any text editor decades from now. I still don’t get where the “non-future proof” here. Can’t really be more future proof than a simple text file.
Arguably, open document format, although standardized, are harder to open and manage because it’s far more complex than a text file that ends with
.md
.Yeah but his kinda turns into a “programmers user interface” that will drastically reduce the usability. As time go by they could add more and more extensions that could make using it in a text editor harder to and harder (my cognitive bandwidth could be used for better things then monitoring that situation).
It does a lot more then .md . The structure of incentives will make it usable for a very long time if not forever (there is a lot of content in it, and having it standardized means organisations are more likely to use it). it has also passed the test of time by existing for 19 years. foam is less then 4 years old as far as i can tell.
Hmm if it comes to the age of a tech and its stability, I agree. I guess only time will tell. But do you have any suggestion for what this note taking format would look like? I personally think for non encrypted notes, foam’s implementation is on the right track.
seems fairly simple , some form of XML? that gives you a schema that can be used to check the file and a rich software ecosystem of writers and parsers. Speaking of consensus based standards its also a standard way to store data.
I would not worry too much about encryption, i use gocryptfs which gives me a encrypted folder where i store my notes in org-mode (there is also gui software for this). the encrypted notes could be some encrypted folder and some sort of standardized encryption (or maybe the encryption type specified in the metadata?)
Honestly this is the thing I worry the most. Without having encryption as a first class citizen, the ux of the notes will be sacrificed greatly. Simply because good encryption tends to be slow, making the app unproductive imo.
gocryptfs is very fast for me. i have a file with about 5600 lines and i detect no difference when opening it under encryption and not under encryption. but in gocryptfs each file is encrypted separately . so you could get some information about the directory structure. but the name of the files and folders is encrypted (“archive” for example turns into something like “AaL6P86WWMnqQkMYnsRBXg”).