I've tried a few apps including better display to find a better resolution for my portable 16 inch monitor. It does allow you to set the resolution you want, but it's a bit blurry.
No way to really fix it, it's just another Mac shortcoming. Using resolution to scale the UI is not a compromise, it's a mediocre workaround.
I'd call that a shortcoming of all hardware that isn't retina resolution, but I know how that sounds to anyone who isn't bought into the ecosystem.
To be clear, I criticize the hell out of the company on things that I think are truly bad. Their app store policies are a disaster. I get that gamers want framerates over resolution. I'm not a gamer and want the other thing.
It's a shortcoming of the software. Apple could claim it's a third-party issue if they didn't support arbitrary external monitors, but they do. As such it's entirely reasonable to expect a fallback solution for third-party displays that Just Works.
For my money, Windows is a terrible operating system but it embarrasses Mac and Linux thoroughly in this regard.
mac users love to repeat this but it's just nonsense. if you can plug another non-mac computer into the same display and get crystal clear, correctly scaled UI then the screen isn't the problem, the computer is.
I agree that the "project size" argument doesn't make much sense, however size as in file size does. There are multiple methods to add support for large binary files in git, but none are great.
With their focus on game developers, I imagine that's one of the primary use cases.
For something that puts "not using electron" so prominently I didn't expect it using flutter. I admit I don't really have much experience with it, I thought it was like react-native (but better?), still far from truly native apps.
Im here to being told I'm wrong. I would love to, specially since we can transpile clojure to dart
Yep. This app uses 230mb of RAM on my machine compared to Spotify that uses 208mb. But it's definitely more performant than my hideously slow Electron Spotify client. I'm really done with Electron. I hope this shaming of Electron apps continue because I can't stand this degradation of software. The only Electron app of recent that had good performance is Notion Calendar (used to be Cron). Although, Notion itself is painfully slow. This is why I'm building a Notion alternative in Qt C++ and QML[1].
Now tbe modern tech stack is to build a bash+python app in an env, add a touch of R, some js, and bundle it into docker container, then make that docker container into wasm with container2wasm, and give that out as the executable.
It's wonderful honestly. You can get just about anything working with stitching together stuff, and then serve your 10GB executable to anyone :).
Serious question: What's the feasibility of local web apps in containers, which appear to the user to be a "regular" app. E.g. Django + SQLite, running in a Docker container, and run by a Mac app shortcut. How would you recommend setting up and running that stack? Better ideas?
Coming from AppKit/UIKit I tried to learn Qt and it was just awful. I hated how tightly coupled with C++ it was. Everything was based around subclassing and overriding methods, there was no way to just have a dumb UIView and set its frame and add a bunch of subviews to it. There was also no clean way to expose a C ABI to use a scripting language (with an FFI) to configure the UI easily
All of the Qt apps I know about (Ripcord, Dolphin) are fast but the aesthetics of the UI was just terrible. So I gave up on learning Qt. But this thing you made, Plume, actually looks good. If there isn't a monstrosity of hacks and boilerplate underneath this UI I might give Qt another shot. Otherwise I think I might just build my own thing from scratch on top of OpenGL or something....
I know what you mean. Would love to just have AppKit/UIKit with some platform integrations (e.g. correct widget themes) on other platforms. Closest that exists to that is GNUStep, but it’s stuck on an old version of Objective-C (no Swift) and targets something like OS X 10.6 with API compatibility.
Outside of the that the next closest I’ve tinkered with is GTK, but since version 3 it kinda gave up on looking right running under anything but GTK/Qt-based desktops. It’s easy to make idiomatic bindings for which is nice though.
Disagree regarding frameworks, though. The newer snapshot-based APIs for NSTableView, NSOutlineView, and NSCollectionView (added in 2020 as part of macOS 11) are a massive improvement over the old index-based ones for example, and there’s been numerous polish and quality of life improvements scattered throughout.
Also disagree about Swift if only for the large number of things it comes with out of the box that’d require a third party dependency with Objective-C, but so many more errors being caught at compile time, no need to maintain header files, and no awkward split between C and Obj-C for basic types are nice too. I still enjoy Obj-C for some types of projects but as project complexity increases so too does my preference towards Swift.
Oh I didn't realize they were still adding APIs to AppKit. That's cool.
Yea I mean the ObjC vs Swift thing.... a matter of preference. I trust Steve Jobs more than I trust Tim Cook. I hate the feature creep in Swift. I hate Swift optionals. ObjC compiles faster than Swift. The ObjC ABI/runtime is superior to the Swift ABI/runtime (which allows for cool stuff like https://cycript.org). I like the dynamic typing a lot. Managing headers is a non-issue for me, I just consolidate everything into one monolithic header file.
I've worked in pretty big ObjC codebases (1M+ lines) so I know most of the tricks to deal with complexity. For Swift, max I've dealt with is 100k lines and it was crippled with tech debt. Frankly, the other engineers on the team were terrible, so maybe that's why. They abused the shit out of RxSwift and refused to use the `!` force-unwrap optional feature
I feel ya! I thought the same, until I discovered the world of combining Qt C++ and QML. QML is extremely easy to learn (I studied all the basics in one day using this Udemy course[1] (not affiliated, just love his work). BTW, he has many free awesome YouTube videos for Qt C++. Creating an aesthetically pleasing app in any framework takes a lot of effort (it's mostly about being focused on what necessary and then creating a lot of white space around it, haha). It's so easy to create beautiful, fluid UI with QML. I've created a short video that demonstrate what I'm working on currently[2] - a Kanban view inside my block editor (kinda buggy now, still WIP). Hopefully, this does inspire you that it's possible.
And it's actually pretty easy to write the C++ code. I don't really use custom sub-classing much. I use Qt's QtObject which allows me to create C++ object that work beautifully with QML. Bryan's course doesn't delve deeper as that, I had to do a lot of searching to figure it out. I hope to open source some of Plume's components to inspire others to do the same. Another point regarding aesthetics, it really takes effort, but Qt can be extended using community libraries. For example, if you want your app to look native on macOS and Windows with a sexy frameless border with a transparent window, then you could use the awesome qwindowkit[3]. Another example, I wanted to position the window buttons on macOS (the traffic light buttons) differently, but couldn't figure it out, and obviously this can't be done using Qt alone, so I looked at Electron's source code and saw how they do it there in Objective-C and incorporated it in my app (ChatGPT-4 wasn't very helpful at that). Now I really want to have these buttons' fill color transparent like Things 3 does, so I'm looking at how to achieve that haha. I already got some ideas. If you need any further help, let me know![4][5].
EDIT: A cool feature of combining Qt C++ with QML is that you get the performance of a compiled language like C++ with the reactivity, ease-of-use, fluid and easy animations (and more) of QML. You can see on Plume's website that it's 4x faster than the fastest comparable native app on macOS.
Thanks for the candid reply. Man... this sounds like too much for me. Oh well. Guess I'll use AppKit for now and if I wanna add Windows/Linux I'll bring in Qt. Definitely will come back to this comment if/when that happens.
Thanks! One of the next features we'll on work will be support for arbitrary folders (basically all notes will be plaintext inside folders, currently they are all plaintexts but inside a local database), so you could sync your notes with any cloud provider (e.g., Dropbox). We'll also provide our own built-in sync option. There are plans for sharing notes, but not quite for real-time collaboration, if that's what you mean by "multiplayer". There are plans for collaboration in the future, but not real-time - I just don't think real-time collaboration is good for text-based formats.
Flutter on the web is absurd: At least when I last checked, it's been rendering UI widgets into an HTML canvas by default, using its own low-level drawing library.
That sounds about as good of an idea as the old Java desktop GUI framework that used to (poorly) imitate native UI elements of Windows and macOS: Everything always looked three major versions behind and felt extremely janky.
I wouldn't care less if it worked in a performant way - in the end Flutter apps are using their own design (Material 2 / 3) - so rendering them in a Canvas is OK-ish.
The problem is that, on the web, the performance is extremely poor, so Flutter is still not worth being used there (IMHO).
Last I knew it had significant performance issues on iOS (framerate drops/stutters), which dampens its cross platform appeal somewhat and is part of why I’ve heard of apps using Flutter for the Android port of their app, but nowhere else.
I’m sort of surprised it’s considered a good thing. Some of my favourite programs use electron, like visual studio code. I haven’t used Spotify though, so maybe that is one of the many electron apps that suck?
I was very unimpressed by flutter when we PoC it at work, but that was years ago, so maybe it’s gotten better since.
> VSCode couldn't support multiple windows until just recently, entirely because of a limitation from the early days of Electron.
That sounds like Microsoft deflecting blame. You've been able to do multiple windows for a very long time in Electron, I remember being able to do so in 2019 at the very least, and the book "Electron in Action" (https://www.manning.com/books/electron-in-action) even have a chapter dedicated to it, a book which was released in 2018.
VSCode always could have multiple windows. You can open multiple projects and they all share the same process(es), so clearly Electron supports multiple windows.
What it couldn't do, though, was to have a single workspace span multiple windows (ie "detach" tabs).
Whether or not this was caused by an electron limitation or a design flaw in VSCode, I can't say. Though I find it hard to believe that it would have been impossible to implement had they really wanted to.
Flutter is pretty native as far as resource usage goes. The language does use a VM and GC but it's performant enough. There isn't native look and feel though. (They can emulate it a bit, but it isn't perfect)
The last time I tried Flutter it was hilariously bad. The "Flutter Gallery" sample was blasting my GPU to render at max framerate without even moving the cursor.
Now with Spotube it appears it has gotten better. But I can still see:
- "off feeling" scrolling with the scrollwheel
- some kind of framepacing issue when using the scrollbar at the right hand side
- Click latency that's better than electron but still worse than anything QML/QT has to offer.
- DPI set in KDE/X11 seems to be ignored. I'm not sure about this, could be a personal preference of the developer to have things this size.
People will always complain, but in reality you can make an electron app which no one will distinguish from a native app, and you can make a native app which will lag so hard that it would feel like a browser page from 2004. People just like to put the label "electron" or "flutter" on it and base their blames on that.
I've heard many good things about it from Android developers. As an iOS user, I despise it. Apps written in it feel extremely janky. How is it even possible to bring down an iPhone 15 Pro to what seems like less than 10 fps in simple UI element scrolling?
I was surprised when I learned Flutter actually runs as native code without needing a JavaScript bridge like so many others.
Although similar to something like React Native - Flutter does paint the screen. Personally I see it as a potential Electron replacement in the future.
From what I’ve seen Impeller is also a big help on iOS. Screen jank was pretty bad for us when Flutter was using Skia as a rendering engine, although when I last messed with Flutter (~6 months ago) Impeller felt almost production ready but iirc there were still a couple small things, not sure if they are better now.
Personally I’ve become a big fan of Flutter, especially for back-office/utility type apps. We would follow all the Material Design 3 guidelines and when it comes to time spent, if you need to develop the same app on more than 1 platform, it’s worth consideration.
I’ve found some people will say: “But it’s hard to get it to look like a native app in Flutter” but for me I’ve always seen that as more of a skill issue. You are literally painting the screen, you can get whatever pixel perfect design you want, if it can be Figma’d it can also be Fluttered and to be fair there are Cupertino widgets and you absolutely can get the best of both/many worlds if you want. Just like how on the web you can do a transform based on device width to switch between the mobile or web view, if you desire you can have different widgets show up for different platforms and give everybody a native feel. I personally still think that’s easier than writing/maintaining multiple individual apps.
I think the biggest downside though is that search engines don’t do well with Flutter Web. It isn’t the nice easy to crawl HTML, and it’s really hard to get a flutter app indexed or to give it good SEO. There’s also silly rules that search engines have about how the content displayed to the user vs crawlers has to have the same data. (I.e. when the web-crawler asks for your page, you are supposed to give it a page with the same data you would give the user.) The best we could do to improve SEO was to make the landing page a page that in the background ran all the same queries and shoved the data into HTML tables, with a popover that said “this is a page for robots that had a button that said “Take me to ABC.com” and a check box that said “automatically redirect me next time” that we stored in a cookie. It was hacky and not a good user experience.
For now, whenever I need to do anything GUI I will use React for the web and Flutter for everything else, but it would be nice to truly be able to only use 1 framework for every platform, which to be fair I’ve used Flutter web and it isn’t all to bad if it weren’t for the issue with search-engines web-crawlers. For apps that don’t need SEO.. Flutter is a great choice. I suspect we’ll see a lot more SaaS apps building in Flutter in the next few years. I think it’s on the cusp of being mature enough to be seriously considered for production scenarios.
I’m just mostly worried about the ecosystem. Google chose Dart for flutter after the results of a lot of research that only Google scale companies can do and to be honest although it IS a lesser known language it isn’t a bad one. It’s AOT and JIT so the hot reload is amazing. It reads like “insert most language you know” here. If you know how to code nothing in Dart should be drastic or surprising. If anything I’d almost say Dart is boring, which I like boring things. I’ve experience with a handful of languages, and for me Dart ranks highly in terms of usability/ergonomics. But there’s a not unsubstantial risk that Google could decide to drop the ball and Flutter could become kind of like the Windows phone. Really great, but canned because people didn’t build enough things for it.
If I were on the Flutter team I’d be most focused on figuring out how to deal with SEO issues. (assuming impeller does indeed provide a full fix for the screen jank, I’d assume it’s gotten better in the past few months, can anyone comment as to if it’s “there” yet or not?)
>can anyone comment as to if it’s “there” yet or not?
It's enabled for ios by default. Android probably in two more releases if I had to guess. If you were doing a lot of custom stuff you may run into issues with Impeller on some CPU bound tasks regarding tessellation but for a regular flutter app it will almost always outperform Skia especially around previous pain points like scrolling and animation.
Can we infer anything about what llm's can achieve from what we can achieve with AIs like AlphaGo? I thought their approaches were completely separated
Gpts are a class of text predictors. Ultimately they are ranked on whether or not the output is similar to the training data, text-wise. If the training data included a game then it may be able to play that game, but only if that game requires reasoning about entire words (because of tokenization, gpts can't reason in terms of letters, that's why they do poorly at crosswords for example)
On the flip side, alphazero is a class of networks that have a list of actions they can take, and a list of parameters they observe about the game (in chess: the board position, in other games: their position on screen, score, speed, etc). The model is then trained to take actions that maximize an actual hard value from the game, like winning a game of chess, capturing a piece, increasing a score, driving the furthest.
In theory you could train a model with the alphago method to do text prediction, but LLMs are called "large" for a reason, the input and output spaces would have to be the number of possible tokens (and at that point just train a normal gpt, it's much more efficient). Also in theory you could train a gpt to play games, but you're spending huge amounts of compute evaluating extraneous words in the input (the prompt) and the output (most words do not have anything to do with your game). on top of that, you're iterating over every word you generate to generate the next one, so you're doing multiple passes of this largely infficient computing, which means you're slower compared to a tailor-made model that can evaluate one situation once and give you a list of outputs to perform.
in this specific case it's a bit wierd because the input space for the alphazero model would have to be every word that can appear on the board, but the reasoning part is most likely not a problem given enough model size. since it's competing with a multi-gigabyte llm though, there is space to spare.
That's a good point. People who argue that even if LLMs are put in physical bodies, self aware with their own learned value function, should have no rights just because they're made of metal are going to be viewed in 100 years the same way Hitler is viewed today.
You need a seed, and a previous hash. The seed is usually sourced from another random generator, that uses environmental noise and some (salted) hashing as well.
In practice, a precise clock and a few difficult to guess events like keyboard and mouse inputs are enough to get a descent seed.
No way to really fix it, it's just another Mac shortcoming. Using resolution to scale the UI is not a compromise, it's a mediocre workaround.