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
  • tengkuizdihar@programming.devOP
    link
    fedilink
    arrow-up
    1
    ·
    2 months ago

    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.

    • wiki_me@lemmy.ml
      link
      fedilink
      English
      arrow-up
      1
      ·
      2 months ago

      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.

      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).

      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.

      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.

      • tengkuizdihar@programming.devOP
        link
        fedilink
        arrow-up
        1
        ·
        2 months ago

        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.

        • wiki_me@lemmy.ml
          link
          fedilink
          English
          arrow-up
          1
          ·
          edit-2
          2 months ago

          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?)

          • tengkuizdihar@programming.devOP
            link
            fedilink
            arrow-up
            1
            ·
            2 months ago

            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.

            • wiki_me@lemmy.ml
              link
              fedilink
              English
              arrow-up
              2
              ·
              2 months ago

              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”).