felipefar

The Telegram desktop app also uses Qt Widgets.

Yes, most people who have an incentive in pushing AI say that hallucinations aren't a problem, since humans aren't correct all the time.

But in reality hallucinations either make people using AI lose a lot of their time trying to stuck the LLMs from dead ends or render those tools unusable.

Just wanted to share that I've found part-time roles hard to get by. It seems companies mostly look for full-time employees.

This is unfortunate because it makes harder to keep working on personal projects on the side, because you either have to make them lucrative to let you work on them full-time, or you have to squeeze them during night-time, when you are tired from daily work.

You could support mobile platforms as well. IIRC, even if Android allows creating only one window per activity, this behavior can be easily mapped on the abstraction that you provide.

They solve the use-after-free issue by keeping pointed objects alive, not by helping you think better about object lifetimes in your code. That means some objects will live for longer than you initially thought they would, and potentially even introduce circular references. Added to that, they also introduce random, unpredictable slowdowns in your application to run their algorithms.

I'm not yet sold on Rust, but exploring alternatives for achieving memory safety without needing to put on a GC is commendable.

Hard pass on the garbage collector. We don't need that, and the minimal GC support that was in the standard has been removed from C++23.

I'm excited by these explorations of dynamic components in rich text. Notion has popularized the idea of documents with rich blocks, where the blocks can provide dynamic behavior to traditional documents. And now we're seeing types of inline elements that also provide more structure to rich text. Those location routes seem something that I'd use myself.

There's already been some talk of using consumer cloud providers. One shortcoming however is that to work well you have to duplicate the users' data for each client app, so you'll consume x times more storage space of the user. This is fine for apps with little data, but is impractical for other apps.

It seems that Notion is a kind of product that tries to solve issues from many areas, so it has everything that almost solves a meaningful problem for the user, but not quite. So the burden is on the user to go that extra mile, who will have to search for templates, memorize how non-standard tech works just to setup and maintain a system that only the maintainer knows how it works.

Some people use Notion for research and academic writing, which is the same use case for my software (https://getcahier.com). By specializing on this specific use case, I've been able to: offer a standard data model that's widely used in the field (bibtex), innovate in the PDF reader in the direction that my users need (by adding scrollbar markers for the relative position of highlights), and provide clear instructions to users on how to use the software. In principle, learning to use the software is learning how to perform an activity better - in this case, formal or informal research. When working with a software that's too general the user will always have to ask himself an additional question: "now, how do I make it do what I need?".

As the mathematician Hardy used to say, a beautiful theorem is one that is not too specific but also that is not too general - it has to strike a balance between the two.

I've heard about SwiftUI just some months ago, and was initially excited about the demonstration in WWDC, so I started to pay more attention to it. Now I've been reading comments on how it doesn't handle well more complex UIs, but haven't really read anything in depth. Can you recommend any resources on that?

Nice work! It wouldn't be much work to support Android with this library and keep the single source file, since the addition of native_app_glue. It'd require just an AndroidManifest.xml, and the API communication can be done by calling the functions provided by the NDK or in the worst case by calling JNI.

I'm curious to hear more about those problems. Do you have any articles covering them in more depth?

That's actually a great idea for a second follow up article. I've worked a lot with rich text and custom text objects, but would also like to explore itemization and the lower level layers.

What would you like to know more about it?

I saw them, they are a very small step in what I believe is the right direction, since you can use a custom textDocument. Anyway what I think would be useful is to jailbreak the QML API. Make the QML C++ API publicly available. Let us derive from the controls, manipulate and customize them with C++, as the Qt team devs themselves do.

I've had more problems with Widgets, especially when doing a lot of animations (even just scrolling big text views) on a 4K display on MacOS, but maybe I'm thinking graphics and not input lag.

There's two things to consider when comparing rendering performance: throughput and latency. Throughput, or how much FPS the engine can sustain, is much better in QML since it's leveraging the GPU, but latency it's very platform-dependent. Mac is actually the one where QML does best in terms of latency (and by that I believe it approaches the latency of Qt Widgets), since it's synchronizing with the VBlank signal provided by CVDisplayLink. On Windows and Android the situation is worse.

Well, I don't want to bash on QML, since I really appreciate the efforts that the team puts in it. But I do think its current state is not the best when compared to Qt Widgets, and lament that there's a split between the two toolkits inside the framework. The problems I had with QML are:

1) The controls that Qt Quick 2 provides are oriented toward touch interfaces, and some are not even feature-complete. For example, QML's Flickable on desktop can be scrolled by clicking and moving the mouse, a behavior that is clearly an artifact from the touch implementation. QML's TextEdit doesn't support much that QTextEdit does, which was particularly important for implementing an app that offers advanced text editing. Ironically, even though Qt Quick is touch-centric, Qt has lots of bugs on mobile platforms, and has a history of presenting regressions on those platforms.

2) Communication between QML and C++ is finicky. You have to use macros and Qt-specific constructs (Q_PROPERTY, signals, slots) to bridge both worlds. Qt Widgets doesn't need bridging in the first place, since it's C++ all the way down.

3) Control customization is a pain. In Qt Widgets, we can create a class that inherits from a standard widget, and then we can customize it however we want while inhering the behavior from the base control. In QML, you have to resort to javascript for that, which has different tooling and ecosystem than C++. Besides, C++ programmers find javascript dynamic typing more error-prone than static typing.

4) The latency of interfaces built with QML is higher than the ones built with Widgets. QML's rendering engine is lagging behind in the input latency mitigation front when compared to browsers, although they've been making efforts in this area.

I don't think those problems are unsolvable, and historically Qt has evolved a lot, so I hope they eventually tackle these issues seriously.

I've been researching CRDTs for a reference manager that I'm building (https://getcahier.com), and thought that some hybrid of automatic and user-operated conflict resolution would be ideal, as you described. But current efforts are mostly directed to automatic resolution.

Do you use last-write-wins using the received order of operations on the server or using a logical clock?

I believe that for Notion the collaboration use case is more important than async editing, so a CRDT makes more sense, but for text editing apps that favor asynchronous collaboration maybe explicit conflict resolution is more reasonable.

CRDTs are powerful, but it's unfortunate that they leave behind a trail of historical operations (or elements), both in their ops- or state-based variants. Even with compression, it's still a downside that makes me concerned about adopting them.

Even so, the discussion surrounding them made me excited by the possibility of implementing conflict-free (or fine-grained conflict resolution) algorithms over file-based storage providers (Dropbox, Syncthing, etc.).

Nice job! I've been wanting to write a PDF parser for learning purposes, but have been put off by the quantity of files that open source PDF parsers have on their repos and the different tech that they need (image formats, compression formats, etc.). I'll probably settle for a reasonable ratio between PDFs supported/learning extracted from the project, so it's useful knowing that PDFs with JS are not very widely used.

Also, I'm the developer of a reference management software, and have naturally been thinking about what it'd take to save in the PDF file metadata fields that are generally useful for advanced readers and academics: original publication dates, ISBNs, DOIs, edition, publisher, etc., instead of just author and title.

Cahier is built from scratch with native tech. Besides more comprehensive notetaking support, I also want to provide support for synchronization with existing cloud providers (Dropbox, iCloud, etc.).

Low UI density is the new emperor's clothes in modern UI design. It's being actively promoted by companies in order to cut design costs, but the truth is that it's only reasonable on touch interfaces or casual apps.

Mouse interfaces are fundamentally different, because you have much more pointing precision, so it pays off to show more data on the screen. You don't have to cram your interface with with spaces to make it scan-friendly, you just use heterogeneous elements and colors. Look at Blender and you'll know it can be done.

I'm designing a desktop reference manager (https://getcahier.com), and one of its aims is to provide a UI with high information density. The mobile version will be able to adjust the experience, replacing desktop-only interaction patterns with mobile ones, and the UI elements that are shared will be somewhat bigger, so that users are able to interact them with touch.

Apart from that, it seems that the whole industry is confused regarding UI styles. UI frameworks are either favoring touch interfaces and degrading the experience on desktop, or vice-versa. Even Windows 10 released certain parts of the control panel with desktop look and feel and others with touch-friendly but desktop-antagonistic screens. It's time we realize that both platforms are different and we shouldn't degrade one in favor of the other.

I might be going against the current here, but why Markdown?

Hardly anyone outside tech knows how to write using Markdown, and a rich text editor with good shortcuts will cater to both non-tech and tech audience.

All in all, I agree that writing in LaTex can be painful. I've wasted too many hours after having fallen into LaTex rabbit holes trying to fix obscure errors and weird rendering.

Unfortunately it's not supported by Safari either.

I'm already convinced of the benefit of declarative GUIs over imperative ones. To be clearer, what I mean by declarative GUIs is ones where I can specify that UI elements should be bound to certain values in the memory of my program, so that they don't have to be changed explicitly by imperative code. Ex.:

TextBox { Text: app.currentUser.name }

Instead of having to call setText on that TextBox.

What I'm still missing is why it has to involve a virtual tree being maintained and synchronized with the real GUI tree. The UI engine could implement the above binding by instantiating for the user a callback trigerred when the bound property changes and changing precisely the value currently shown on the screen. Hence, the UI engine is in charge of the callbacks, which keeps the user unburdened by callbacks.

I'm curious to hear your take on this: what's the advantage of following the virtual control tree approach compared to instead updating directly the controls that are displayed to the user?

That'd be amazing not only for go apps but for software built on other languages as well. I'd pay for a good, straightforward build packing + crash reporting + autoupdater solution for my apps.

I hope Microsoft would settle for one UI library instead of pushing a new one every five years. WinUI 3 is their most recent invention. Application developers can't keep up with the changing standards.

I would mention as an alternative QML, although I wouldn't claim it is the "best method". It's marketed as being mobile-capable, but I've heard problems about scrolling inertia and vsync delays.

I'm curious to know what others think about it.

That was unfortunate. Thanks for the heads-up, it's fixed now!