On Android it more or less just uses the accessibility APIs to grab the actual text, you can do it without using Google Assistant even by selecting text inside an app's thumbnail window from the Recent Apps screen.
> I am uninterested in `you can do that in git with [insert esoteric commands]`.
Why? If the only requirements you specified are that you're looking for something that is compatible with Git but with better ergonomics, wouldn't something that wraps Git (whether that's via aliases or something more comprehensive) fit the bill?
It's a fair question, but the answer is simple: because there are significant design choices in the UX and algorithms which are user visible, and percolate throughout the entire system design, which can't just be wrapped or alias'd away.
There is git-branchless, which is kind of like this[1][2] and is something like a half-way point between Git and Jujutsu/Sapling. However, it needs to be stated that git branchless does NOT just "wrap" existing things or alias them. It has significant engineering to add features, using a lot of code, because you can't "just" add things like revsets or 'undo' using wrappers or aliases, at least not in an efficient way.
Some examples from Jujutsu are that:
A) jj rebase is lightning fast compared to git rebase, because it works in memory. Git rebase touches disk for all operations, so it becomes slower the larger the repo, the more history, the bigger the files etc you have. You may spend significant IOPS moving large-ish files around, flushing the index to disk, and so forth; and you also cannot do things like rebase inside a bare repository (imagine you want a handy "Rebase branch on main" button in your GUI -- you need to have the whole working copy to do that!) jj rebase works entirely in memory so it never touches the disk for any files in the commits themselves. This is called "git move" in git-branchless, but requires significant code. Git itself is trying to solve this with a new "git replay" command, but it is extremely new and has some current limitations compared to, say, Jujutsu, IIRC. (But the fact they have to add a whole new command with significant code is a good example of how the algorithmic differences matter and can't be papered over.)
B) Revsets are a non-trivial addition to make the commit graph "queryable", but they add open ended features in a way that can't easily be recreated without them, because they are composable. For example, "list all commits authored by me that are not merged into main that can be rebased on main" is written as `all:mutable() & mine()`, but to recreate this level of flexibility you would need a dozen one-off features added to something like 'git log' -- but these revsets can work with many more commands than log! You can use the above revset to automatically rebase all your open branches at once for example, which is not possible in Git without shell scripting (what about Windows users?) and duct-taping stuff. But then where's the reuse?
C) Jujutsu has a notion of first-class conflicts, which can only be vaguely approximated with something like `git rerere` and `git rebase --update-refs`, but this isn't quite the same because for example you need to know details like purging the rerere cache if you get a conflict resolution wrong and want to undo it and start over, not to mention you can still easily screw things up mid-way with `git rebase` in a form that requires you to start over. These "catches" do not apply to Jujutsu and I have no idea where you would even begin if you wanted to add a feature like this.
So, the details matter a lot in practice for users, and delivering them a good experience is something that I think is way more difficult than just a bunch of opinionated commands. To be clear, if you like opinionated aliases and wrappers, that's OK! But there's a lot more underneath the surface if you scratch at it a bit.
- https://blog.waleedkhan.name/in-memory-rebases/ — It's non-trivial to support workflows like "rebase just commit X out of its branch and insert it before commit Y in that branch" in a single command. jj implements the same workflows as well.
I'm actually surprised to learn that Notion mandates on-site. It gives the impression that the leadership doesn't believe in their own product (which revolves entirely around collaborating on work online).
They're building a product that revolves around React and Typescript and include an email specifically for receiving investors, so it's reasonable that they'd talk up both technologies.
Since it's Kotlin, it has backends for the JVM, LLVM, and JS/Wasm, though curiously Jake recently removed the JS target because it wasn't seeing much usage.
Great, another one. Recently someone else was touting something called avalonia for .net? Then there are older ones that still exist, like Kivy and QT.
These folks should be working together on just a few open-source projects :-D. Trying to support every mainstream platform is a huge undertaking and as mentioned in this thread, few succeed, and even fewer over the long term.
I think that's an absolutely reasonable reaction. I can only say that, as someone that primarily works on Android, I'll of course prefer Compose UI since it's technically the "native" solution for me already. And while reading further, keep in mind that my views are going to be biased towards Kotlin and such for that reason, of course. There's also the additional disclaimer that it's still relatively early days, and the developer experience isn't perfect out of the box with every platform, just yet.
By opting for Kotlin and Compose UI, in addition to being a first-class citizen on Android, I gain the ability to share code with many other platforms to any degree I need. That is, just the app logic can be done in Kotlin while keeping the actual UI in whatever each platform prefers (UIKit on Apple platforms, Swing on JVM, etc.), or it can be entirely done with Compose UI (which usually means being rendered via something like Skia). And even if you adopt Compose UI, there are different degrees to which that can be applied; Compose UI can output either DOM elements or render to a canvas for the Web target, for example. (It's actually curious you mentioned Qt. As a day-to-day KDE user, I'm interested in playing around with the possibility of wrapping Qt components with Kotlin/Compose as well.)
No matter what degree of that I choose, it's still going to be more "native" than something like RN. Depending on the target platform, Kotlin will compile down to JVM/Dalvik bytecode, LLVM bitcode/machine code, JavaScript, WASM, etc. RN (last I checked, at least) still relies on running in a JavaScript engine at the end of the day. Flutter will get you closer than RN, but it's still not quite native to any one platform in particular and you're still introducing Dart as another language you need to know. A .NET-based solution suffers a similar problem, and IMO it feels even more out of place on Linux than the rest.
(To be clear, Compose UI has been able to learn a lot from Flutter, as they both originated at Google and both take a declarative UI approach; I largely consider Compose UI to be Flutter's successor.)
Ultimately, it can boil down to this: if you want to support multiple platforms, you need expertise in each. Adding most traditional cross-platform frameworks such as Flutter or RN also means you need expertise in that framework as well. In the worst case, my expertise with Compose UI will remain good for the work I need to do on Android. The worst case for most of these other frameworks is that it becomes irrelevant and you need to learn something else anyway.
