As someone who works with QML daily, I had the same question. The work is already done. Why write a common UI backend in swift when you can have the whole thing common using QML/Qt.
It’s the best way to write native Multiplatform apps at the moment. It just is.
I’m not entirely convinced that multiplatform UI is a good idea for anything other than the simplest of applications. It always ends up looking out of place on at least one platform and sometimes all of them.
It just takes an effort to make Qt apps look and behave native. This has been one of the goals with my new note-taking app, and I think it looks pretty native (at least on macOS): https://www.get-plume.com/
Hey, I don't use your app because it's too limited for my "PKMS" needs (I use trilium notes instead), but I appreciate that you make being "native and fast" a distinguishing feature (vs all the other electron based alternatives boiling the oceans).
Thanks for the feedback, although the app isn’t released yet so you should at least give it a shot once it’s out.
I do try to strike a balance between flexibility and ease of use. I think Notion is too complicated (yet very flexible/powerful). With Plume, the focus is to be able to organize your thoughts in a powerful way, effortlessly. Sign up to the waitlist and try it once it’s out. Much more is coming soon.
I wrote about the problem space extensively on this site before, tl;dr, to me the issue lies in the fact that most of the contenders aim to manage data/knowledge/notes as "types" (for categorization, templating and derivation/re-purposing), but, to my knowledge, only trilium is enabling that with a "sound" design. Notion is exposing a lot of incidental complexity due to its "unsoundness".
@ezst I've come across a couple of your comments noting the benefits and shortfalls of the current crop of PKMS. Lots of head
nodding going on over here on the "sure you can define your tags/categories/types, but after page/note creation you're on your own for management" theme. That had me jumping with enthusiam towards Trilium, only to see it's gone into maybe-discontinued mode (https://github.com/zadam/trilium/issues/4620). What are your thoughts on it's viability for someone who is not a current user but thinks they might want to be?
(if there's a better place to have this conversation than (ab)using this thread feel free to point the way. Assuming you wish to indulge me at all that is. ;-)
Just read this comment of yours[1]. Plume is aimed to be much simpler than Trilium, I want a non-tech-savvy 40-year-old mom that doesn't know what Kanban is to be able to happily use it as someone that is tech-savvy that knows all about Kanbans. Something that just works for many people, like Apple Notes but with a more advanced editor and features.
Which kind of supports my thesis. It’s not so much the underlying tech stack that matters, but the attention to platform conventions. I would expect text input on a Mac, for example, to support ctrl-a and ctrl-e shortcuts for beginning and end of the line (Microsoft is a gross offender on this front thanks to their wanting to accommodate Windows users on a Mac who will be used to using ctrl instead of cmd for keyboard shortcuts).
Thanks! It’s both. The model side and logic is written in C++ while the view is written in QML. That way I get the best of both worlds, the performance of C++ with the ease of use, flexibility, animations, etc of QML. It’s worth noting that most Qt Quick components and much of QML code is compiled to C++, so even code on that side is performant.
For me, QML, while expressive, had a lot of rough edges.
If most of your logic is inside the C++ backend, its JS engine is just useless overhead. If you do something like lite data wrangling in QML, or worse, try to adapt existing JS libraries for it, it quickly becomes a nightmare of standard JS weirdness, non-compliance with normal JS, and just outright ridiculous and difficult to diagnose issues like data getting passed by reference from the previous page and that page getting popped off the stack, resulting in error.
And besides that, QML tooling is virtually non-existent. Major code editors don't even ship basic syntax highlighting for it out-of-the-box, the linter doesn't catch anything useful forcing you back into manual testing, and recently added language-server is at best a little useless and at worst impossible to get working correctly because your components live inside the build container and cannot be installed on the host without risk to system stability (Ubuntu Touch Clickable and Lomiri.Components).
If something like that was possible for Qt, I'd probably switch in a heartbeat. If our modern programing languages are finally expressive enough to write sane reactive UI and statically verify parts of your logic, why keep relying on the unverifiable and slow DSL?
> If most of your logic is inside the C++ backend, its JS engine is just useless overhead.
Well, if most of your logic in C++, what's the problem then? For my app[1] most of the logic in C++ but there's still a good amount of logic in JS (out of laziness or ease). BTW, much of QML code is compiled to C++ these days[2]
> difficult to diagnose issues like data getting passed by reference from the previous page and that page getting popped off the stack, resulting in error.
This is very true, it's quite difficult to diagnose issues in QML, and it doesn't seem to me like Qt ships debugger tools for errors as available for C++ when a program crashes.
I relate to your issues with syntax highlighting (although the linter is good imo). Also auto-complete is pretty bad in Qt Creator for QML.
I wonder how feasible it is to integrate Typescript into QML rather than JS.
But I think that while all these issues should be addressed, developing with C++ and QML is the most joyful combination I've experienced so far for GUI development (I also developed in React and React Native).
Call me harsh, but I think this is one of those things that is fun to create but not very useful. Possibly that's the reason it was made.
The reasoning has everything to do with confusion. This will be a de-facto leaky abstraction of an experience. Many windows programs will not work and require debugging. It isn't clear to the user that this is actually Ubuntu, so the system ultimately becomes less usable when something (inevitably) goes wrong as you are now dealing with nuances of two different systems at once.
I can only see this being useful in situations where a user has learned the 'bare minimum' of windows functionality and needs to be presented with a similar UI ('fooled') to be able to function in the OS at a basic level.
EDIT: And they offer a paid version that 500s? This is starting to read like very suspicious software...
I predict the end state of Windows is a user experience like Aqua is on Darwin for Apple.
That is, Wubuntu = Darwin.
If Redmond can't beat Torvalds, and the cost of kernel development continues to get less affordable when Office365, ActiveDirectory and Exchange are where the money is, then why bother?
It does seem a bit of a throwaway statement regarding OCCT - I also work with it every day and, for the most part, it has all the same eccentricities and limitations of any large heritage-listed C++ library. There's a lot it can do!
Have you worked with Open Cascade recently? As someone who works with it every day for developing a CAD application, it would be interesting to know what people see as its limitations. It's the only geometry kernel I've had access to, and it seems like an absolute gift
> Build123d is a python-based, parametric, boundary representation (BREP) modeling framework for 2D and 3D CAD. It's built on the Open Cascade geometric kernel and allows for the creation of complex models using a simple and intuitive python syntax. Build123d can be used to create models for 3D printing, CNC machining, laser cutting, and other manufacturing processes. Models can be exported to a wide variety of popular CAD tools such as FreeCAD and SolidWorks.
> Build123d could be considered as an evolution of CadQuery where the somewhat restrictive Fluent API (method chaining) is replaced with stateful context managers* - e.g. with blocks - thus enabling the full python toolbox: for loops, references to objects, object sorting and filtering, etc.*
> This package is inspired by the NURBS-Python package, however uses a NumPy-based backend for better performance.
> Curve, and Surface are non-uniform non-rational B-Spline geometries (NUBS), RationalCurve, and RationalSurface are non-uniform rational B-Spline Geometries (NURBS). They all built upon the class BSpline. Coordinates have to be in 3D space (x, y, z)
This was my impression as well. I think people actually feeling burnt out creatively might read this and get a forlorn feeling that what is required is more work, and then go straight back to mindlessly scrolling
Any non-trivial feature that Unity has where Godot lacks is usually re-implemented by bigger developers anyway. For Indie developers, these features are almost never necessary.
When developing tools, Godot is far superior. Any support guarantee that Unity provides is easily bested by the ability to inspect the Godot source code without signing an NDA. With the changes in Godot 4, developing add-on tools is easier than ever.
The Godot project is well managed, with pull requests being merged in a timely manner without a loss of overall project quality.
The mass exodus to Godot is perfectly timed. Godot 4 just released with many changes and improvements, addressing almost all the usual pain points between the two engines (especially in 3D).
The one aspect that godot lacks currently is the store and marketplace ecosystem.
But perhaps the existing unity ecosystem sellers will look towards porting their stuff over, since their customers are in mass exodus mode.
Godot needs to prepare a good marketplace solution to accept the oncoming ecosystem developers, so that they can take advantage of this. Could even have a potential to use revenue from the marketplace to fund godot development!
I don't know where I read that bit, but the maintainers are very aware of the lack of marketplace and I think it was the first point for the "how can we accommodate the new devs" list. So it's likely to happen relatively soon.
I never tried with Godot specifically, but i (and fellow varied developers) did it a lot in Unity and "it worked". The main points were :
- Relative ease of use for us (especially when working with juniors/intern who often only studied game engine and don't have framework experience)
- Performances ok/good (seriously it may depend the platform but a native game engine often have far better performance than a browser on input latency/rendering, wich is logical, it's the point AND they do a lot less than browser on other features)
- You can go really wild on design/feedback with low effort, especially if you have a mobile game ui on yours work folders
The pain points (some may be alleviated with dedicated libraries, I used none) were :
- On complex UI (multi tabbing/multiple modal screen ) the lack of native support you have in dedicated web framework was a pain
- You have to add yourself complex features natively offered on forms. Especially history, complex filtering.
- On complex I/O (network/files manipulation) the engine was (naturally) lacking.
- Unity and probably Godot assume by default they are the main windows on screen, you can encounter problems about that if you use it as a 320x200 windows between 4 other windows.(that said if you considered electron you won't be in unknown territory ^^)
I've done it a few times at my current job and it worked great for some simple UIs. Would probably work great for more complex stuff too but I haven't needed anything like that, I use it with C# as well.
Just because I’m curious, in what respect is Conan a “partial” package manager? Within the constraints of existing C++ projects and the variance of their build systems, I can’t imagine how to do it differently.
In my experience, most of the value of Conan is with creating packages yourself when needed. You can then self-host a Conan remote and have pre-compiled binaries ready development. Having a conan recipes repository with CI that produces binaries for each required build configuration has become a de-facto standard for projects I have worked on
The closest thing we have at the moment is conan[1]. It’s a cross platform package manager that attempts to implement “integrations”, whereby different build systems can consume the packages[2]. This is a big problem with package management in C/C++, there’s no single, standardised build system that most projects use. There isn’t even a standardised compiler! So when hosting your own packages using Conan, often you need to make sure you build your application for three different compilers, for three different platforms. Sometimes (for modern MacOS) also for two different architectures each.
If you control the compiler AND build system you can get away with just one package for most cases. This true for Microsoft’s C/C++ package manager, NuGet[3]
Historically, the convention has been to use the package manager of the underlying system to install packages, as there are so many different build configurations to worry about when packaging the libraries. The other advantage of using the system package manager is that dependencies (shared libraries) that are common can be shared between many applications, saving space.
The cpp ecosystem is insane. I don't know how it got so out of hand. At the end of the day you are just a running a bunch of clang/gcc cli commands. It's really, really, really simple. But all these commands are generated, and the user becomes so detached from what they are actually doing, and then they are left with an error about one of these commands not working, and then they need to dive into this huge monstrosity to figure out what is making a command do something.
Declarative build systems obfuscate so much without providing the proper debugging and error-handling capabilities.
Build systems should be imperative and type-checked. A simple script that a user can step through and observe what is happening.
Makefiles suck because they are not type-checked.
The only abstraction you need is some kind of dependency graph. But then it should be completely transparent to the user so they can easily understand it.
The schema of the linked post doesn't look useful to me at all haha