Great write-up! It would be useful if various PKMs would settle on a similar format for recording (nested) tasks, dates and metadata, as it seems to have become the standard way to store kanban boards and similar 'enhanced' views of the underlying md tasklist. Currently there exist various strategies ranging from embedding JSON as comments to esoteric (non-markdown) formats, often trailing at the end of each task. This makes the source look cluttered and difficult to edit/navigate.
IMO, metadata (such as date ranges) could instead be stored as empty links leading each task (or maybe showing a symbol such as '@'), paving the way for a 'linked' data format while resulting in a same-width list for easy lookups and editing:
For instance, the above tasks would link to the virtual '30..31.md' and '29..30.md' files to collect all backlinked tasks for the provided daterange (akin to Obisidan/Logseq/etc).
In an ideal world, the task marker could hold the metadata itself, but this would unfortunately result in non-standard behaviour:
This is brilliant work and I love the Qt ecosystem.
Can’t help but imagine the things we could’ve had if Apple wasn’t pushing the horror of Swift down everyone’s throat by blocking alternatives in so many tiny ways.
Swift and SwiftUI on macOS are the most complete UI framework that is native, fast, performant and works very well.
Basically no other platform comes even close in terms of ease of use and performance. The best would be to extend that kind of framework on Windows (and/or Linux) and make it work same / similar.
If you mean due to lack of C++ for doing GUIs, Google and Microsoft have also long left C++ to the dust, in what concerns GUI frameworks.
Even Microsoft, for all its C++ use, has never produced anything better than MFC to this day, and only Windows team cares about XAML C++, others rather use React Native or Webview2 alongside C++.
It is up to third parties to use frameworks like Qt.
Looks great, and it has some features and polish that I would love Logseq to have natively, but overall I prefer the customisation potential of logseq with tags, templates, block refs etc.
I've worked with QtWidgets and I have mixed feelings about the extensive (1) documentation about integrating C++ with QML and QtQuick.
Here's a quick history lesson (as I understand it):
- QtWidgets the original C++ QT graphics library.
- Around 2008 or something, they introduced QML and QtQuick. This was basically declarative UI + javascript for logic.
- QtWidgets is considered 'done' and all new features and dev is basically happening in QML / QtQuick.
- ...as described in this post, the current recommended 'best practice' is to avoid writing a pile of javascript spaghetti and bridge between C++ for logic and QML for UI.
So, long story short: We've moved from a robust C++ framework, to a javascript backed framework to 'appeal to the masses', but it's kind of hard to build a whole application that way, and so 'best practice' is to go back and write your logic in C++.
Does that seem weird to anyone else?
> While powerful, Qt Widgets lack some essential modern features, in my opinion, such as declarative UI, bindings, behaviors, anchors, and more. These features enable the creation of beautiful, animated UIs simply and quickly, as seen in QML.
Hum. QML is certainly declarative.
I'd love to see a breakdown of specifically what features you can't do with widgets, and why having a js <-> c++ bridge is better than not having one.
Don't get me wrong; if you want to write a 100% javascript QML application, that's cool. Go for it... but when you're writing a C++ application and choosing, deliberately, to implement you UI in another language and communicate with that UI via a bridge...
...well, let's just say, if you had another option (eg. just use C++), wouldn't that make sense?
Couldn't you do the the same thing with react native components and logic in C++? (You could) Why is this any better than just writing a react native UI? Or a flutter UI?
You could do any kind of UI, even fully native, if you're implementing the application is c++ and then just doing cross language <-> to the ui.
> Couldn't you do the the same thing with react native components and logic in C++? (You could) Why is this any better than just writing a react native UI? Or a flutter UI?
The tooling, that is why.
Having QtCreator, Qt Design Studio, compiling QML to native code, debugging experience.
React Native has all the gotchas from JavaScript and poor tooling for developers that never left the CLI world.
Flutter depends on Dart, a programming language that was rescued from oblivion thanks to Flutter, and is pretty much useless everywhere else.
Great write-up! It would be useful if various PKMs would settle on a similar format for recording (nested) tasks, dates and metadata, as it seems to have become the standard way to store kanban boards and similar 'enhanced' views of the underlying md tasklist. Currently there exist various strategies ranging from embedding JSON as comments to esoteric (non-markdown) formats, often trailing at the end of each task. This makes the source look cluttered and difficult to edit/navigate.
IMO, metadata (such as date ranges) could instead be stored as empty links leading each task (or maybe showing a symbol such as '@'), paving the way for a 'linked' data format while resulting in a same-width list for easy lookups and editing:
For instance, the above tasks would link to the virtual '30..31.md' and '29..30.md' files to collect all backlinked tasks for the provided daterange (akin to Obisidan/Logseq/etc).In an ideal world, the task marker could hold the metadata itself, but this would unfortunately result in non-standard behaviour:
It would then be up to the editor to render this metadata accordingly.This is brilliant work and I love the Qt ecosystem. Can’t help but imagine the things we could’ve had if Apple wasn’t pushing the horror of Swift down everyone’s throat by blocking alternatives in so many tiny ways.
Swift and SwiftUI on macOS are the most complete UI framework that is native, fast, performant and works very well.
Basically no other platform comes even close in terms of ease of use and performance. The best would be to extend that kind of framework on Windows (and/or Linux) and make it work same / similar.
If you mean due to lack of C++ for doing GUIs, Google and Microsoft have also long left C++ to the dust, in what concerns GUI frameworks.
Even Microsoft, for all its C++ use, has never produced anything better than MFC to this day, and only Windows team cares about XAML C++, others rather use React Native or Webview2 alongside C++.
It is up to third parties to use frameworks like Qt.
Looks great, and it has some features and polish that I would love Logseq to have natively, but overall I prefer the customisation potential of logseq with tags, templates, block refs etc.
This could have been based on KDE's KTextEditor https://github.com/KDE/ktexteditor
Isn't that targeting Qt Widgets?
I've worked with QtWidgets and I have mixed feelings about the extensive (1) documentation about integrating C++ with QML and QtQuick.
Here's a quick history lesson (as I understand it):
- QtWidgets the original C++ QT graphics library.
- Around 2008 or something, they introduced QML and QtQuick. This was basically declarative UI + javascript for logic.
- QtWidgets is considered 'done' and all new features and dev is basically happening in QML / QtQuick.
- ...as described in this post, the current recommended 'best practice' is to avoid writing a pile of javascript spaghetti and bridge between C++ for logic and QML for UI.
So, long story short: We've moved from a robust C++ framework, to a javascript backed framework to 'appeal to the masses', but it's kind of hard to build a whole application that way, and so 'best practice' is to go back and write your logic in C++.
Does that seem weird to anyone else?
> While powerful, Qt Widgets lack some essential modern features, in my opinion, such as declarative UI, bindings, behaviors, anchors, and more. These features enable the creation of beautiful, animated UIs simply and quickly, as seen in QML.
Hum. QML is certainly declarative.
I'd love to see a breakdown of specifically what features you can't do with widgets, and why having a js <-> c++ bridge is better than not having one.
Don't get me wrong; if you want to write a 100% javascript QML application, that's cool. Go for it... but when you're writing a C++ application and choosing, deliberately, to implement you UI in another language and communicate with that UI via a bridge...
...well, let's just say, if you had another option (eg. just use C++), wouldn't that make sense?
Couldn't you do the the same thing with react native components and logic in C++? (You could) Why is this any better than just writing a react native UI? Or a flutter UI?
You could do any kind of UI, even fully native, if you're implementing the application is c++ and then just doing cross language <-> to the ui.
Right?
[1] - https://doc.qt.io/qt-6/qtqml-cppintegration-overview.html
> Couldn't you do the the same thing with react native components and logic in C++? (You could) Why is this any better than just writing a react native UI? Or a flutter UI?
The tooling, that is why.
Having QtCreator, Qt Design Studio, compiling QML to native code, debugging experience.
React Native has all the gotchas from JavaScript and poor tooling for developers that never left the CLI world.
Flutter depends on Dart, a programming language that was rescued from oblivion thanks to Flutter, and is pretty much useless everywhere else.