silicon VS notes

It's nowhere near as featureful as Outline, but I wrote my own Markdown knowledge base thingy in Python. It is web-based and geared toward single-user (or _very_ small team use) but it's Apache licensed and has no commercial tie-ins. Super easy to deploy as long as you know how to layer some rudimentary authentication on top of it.

https://github.com/cu/silicon

I wrote my own note-keeping system[0] and very much wanted all of the notes to just be markdown files on the disk. It turns out that there are trade-offs to this. If you want plaintext markdown files on disk AND want fancy features like file versioning, a search index, tags, etc then you need to store all of that metadata somewhere and you're down writing a half-assed implementation of a DBMS.

Now, you can certainly bite the bullet and full-ass the implementation like Dokuwiki did, but that is really quite a lot of work and effort against simply `import sqlite` and writing a couple of tutorial-level queries. And it turns out that exporting all of your documents to plaintext, if you should so choose, is a one-line command away.

[0]: https://github.com/cu/silicon

I wrote my own. It's a web app but one of its features is that it doesn't have many features. https://github.com/cu/silicon

It doesn't have folders and tags, but if that's not a deal-breaker you could check out https://github.com/cu/silicon

Not sure which features you're looking for, but you could try this thing I wrote: https://github.com/cu/silicon

3. Very occasionally, I will click on a link on one page to go to another page.

And what would be the point of categorizing all my notes? Every single time I go to my wiki, it's to either write down something specific or search for something specific. I have _never_ wanted to see a list of all of my pages about programming languages for example. Or every page tagged "bash".

I think as software engineers building our own tools, we sometimes build features because they sound interesting and we know how to do it, or because the project doesn't "feel" complete without them. Not because we'll ever actually use them.

When I _do_ want to break up a large subject (e.g. Python) into multiple pages, I just create one "Python" page and link to all of the others from that page.

The one concession I've made to categorization/organization is that I've added a feature where two pages can be marked as "related" to one another. This is mainly to avoid having a manually-edited "See Also" section on pages that touch upon topics covered on other pages.

[1]: https://github.com/cu/silicon

Thanks! I'm not 100% sure about this, still hearing feedback from people on both ends. Some reasons for the switch would be:

1. File versioning

2. Easier self-hosted syncing

3. Better data portability (although we already support exporting to .txt)

I would love to hear counterpoints. Currently, SQLite works pretty well, and our custom database is pretty simple (plus, our database code is also open source[1]).

[1] https://github.com/nuttyartist/notes/blob/master/src/dbmanag....

Plume is actually based on my open source note-taking app Notes[1]. You can already get it on Flathub, Snap Store etc. Notes uses just a simple plain text editor while Plume has a completely revamped block editor that I built from scratch. That parts of Notes used in Plume will remain open source (per the MPL license) but the rest of the code will be closed source. At least for the time being.

[1] https://github.com/nuttyartist/notes

Plume is built on top of my open source note-taking app Notes[1]. Since Plume is based on Notes, I'll of course comply with the MPL license and release all existing files that were changed (and must stay MPL licensed).

But I recently discussed my reasoning to go close-source with Plume[2]. I've been working night and day (every day) converting 4 cups of coffee into code for the last 4.5 months to create Plume. I don't want to risk not being rewarded sufficiently for it. But, I'm 99% sure that I'll either open source the core block editor or the entire app in the future.

[1] https://github.com/nuttyartist/notes

[2] https://news.ycombinator.com/item?id=38584960

2. Each note is just a simple plaintext in the underlying data (although currently stored in a database, but in a future update we'll convert the database to an arbitrary folder).

So you can create beautiful and advanced notes, easy. In a non-proprietary format (when that future update arrives). All while using a resource efficient and fast software that is cross-platform.

[1] https://www.get-plume.com/

[2] https://www.get-notes.com/

My Noets app[1] editor is built on top of the Markdown syntax of QOwnNotes.

My new app Plume[2] is built on top of Notes but features an advanced block editor and a new design.

[1] https://www.get-notes.com/

[2] https://www.get-plume.com/

Indeed, I want this feature badly myself to create wikis and such. There's an open issue[1]. We'll definitely implement that some day.

[1] https://github.com/nuttyartist/notes/issues/431

I mostly disagree. Like you said, Qt is the best native GUI toolkit available today. And that is a hard achievement. There are many tradeoffs (some you pointed out) but the open source community seems to find a way around those limitations. There are thousands of open source libraries you can plug-in into your Qt app to overcome many of its limitations (although some remain, like how can't we still not easily change caret/cursor color of QTextEdit??).

Unlike you, I like the direction where Qt is taking. I think QML and Qt Quick are great. I just implemented a feature in my note-taking app that turns Markdown text into Kanban board using QML and the experience has been great (https://github.com/nuttyartist/notes/pull/574). I'm planning to continue transition from QWidgets to QML/Qt Quick.

I do worry of the continuous friction with open source development and hate the online installers as well. I can recommend this useful tool https://github.com/miurahr/aqtinstall that allows you to easily download prebuilt Qt binaries. I hope they can revert their approach on that.

I beg to differ, QML is great. I'm implementing a feature that converts all tasks in Markdown editor to a Kanban view (written in QML) and it's been so easy to do. Work in progress GIF here: https://imgur.com/a/sZNHnp6

And it's even crazier that most of it compiles to C++. It's so fast to develop with it, and runs so fast.

BTW, source code here: https://github.com/nuttyartist/notes/pull/574