547 karma · joined August 16, 2020
As for themes, I quite like the new libadwaita theme, and prefer it to the default GTK theme. You're free to disagree, but you can't say your opinion is correct, nor can I.
Keep in mind that libadwaita is an optional library _specifically for gnome apps_. If you don't like gnome, don't use libadwaita. If you want the widgets from libadwaita, but don't like the styling, then either copy the code (it's open source, fork it!), or use libadwaita and disable the libadwaita stylesheet (and add styling for the widgets that aren't part of GTK).
Agreed that beginners using desktop GUI toolkits often make the mistake of putting long-running code in a button press callback, and then the GUI freezes.
But it's pretty easy to avoid this, so long as you know about it. If you're doing network/IO related stuff, make your callback async and await the data. GUI toolkits often have an event loop built in that can run user-supplied async code. If you're doing CPU intensive work, spawn a thread (maybe in a threadpool), and send data back to the GUI thread over a channel (the GUI thread uses async callbacks to check the channel). Not as easy as async, but often GUI toolkits encapsulate this into some kind of "Task" object for you that can take out some of the boilerplate.
I ended up with the LG 32UL500-W (https://www.rtings.com/monitor/reviews/lg/32ul500-w), for about $300 US.
My conclusion was that trying to get a higher refresh rate 4k monitor, or even higher resolution, or OLED or anything else, made it 2-6x more expensive. Prices for these features still have a _ways_ to go before they're affordable.
2. Given a brand new group with 0 members yet, it's still likely that women will avoid it, because of their past experiences with 1. putting them off joining groups in general
3. Women are less common than men in general in CS. Any group that accepts the average person will statistically end up with more men than women.
The groups that "advertise" to women avoid these problems, which is why they tend to work.
I agree that we shouldn't need specialized groups, but I haven't seen any other solution, at least in the immediate term. Likely society will improve simply due to the passing of time, and in 50 years from now and it won't be a problem anymore.
My school also hosts a hackathon for women and underrepresented gender minorities every year (organized by a student org that rents out a building from the school for it). The hackathon is also open to high school students. Many people I've talked to there talk about how they only went into CS because someone they knew invited them to the hackathon, or have made friends and feel less alone in CS because of it.
There's a real need for these groups. Whether men needs their own groups is a separate discussion that I have no real stance on.
WebGPU more or less fills this gap. It's built on top Vulkan/Metal/DirectX12 primarily, and targeted as a WebGL2 replacement, but there's also major interest (and right now, better support) around using it natively for games and other programs. There are bindings for Rust, C++, C, and Javascript (either through the browser, or using deno for native).
Here's an excellent tutorial that uses Rust, although the API is more or less identical across languages https://sotrh.github.io/learn-wgpu/.
As a counterpoint, I've been using WebGPU (through wgpu-rs) for the past 1.5 years. It's been a pleasure to use. For instance, here's the CPU-side code for a glow post-process shader using 4 render passes https://github.com/JMS55/sandbox/blob/master/src/glow_post_p....
I don't have a problem with Windows having DirectX12 in addition to Vulkan. Or even that vendors typically add new features to DirectX12 first, with Vulkan getting them later. This is because you can still write a Vulkan program, and have it run on Windows. Apple only supporting Metal breaks "write once, run on any platform". It's one thing for Apple to have Metal as a better supported/approved API that they can make the best apps with. It's another to lack Vulkan support altogether. Because Apple aren't just trying to get the highest Metal adoption. They could easily do that with AppStore restrictions or something, or just accepting that UIKit using Metal is good enough adoption. Lack of Vulkan has knock on effects on every other platform, because now engines have to do a ton more work, and likely have more bugs.
B) Games might not have to deal with macOS if they're using an engine, but the engine themselves still do. This limits what engines can do to the least common denominator. And we all know Apple isn't the fastest when it comes to new standards or features. In the graphics world, that comes in the form of DirectX12 vendor-specific extensions, with Vulkan vendor-specific extensions a few months later, and then Metal support whenever Apple feels like copying it.
Someone else in this thread linked an example about Metal lacking support for a type of atomic primitive that prevented the decoupled loopback algorithm from running on Metal. That means the author couldn't use WebGPU to implement the algorithm, and had to make an implementation in Vulkan and Metal separately (iirc all the details of this correctly, you get the general idea). And it _wasn't_ clear that they couldn't use WebGPU to begin with. The WebGPU spec had to actually be clarified based on the author's investigation. Engines and other APIs wouldn't have to deal with this if Apple just supported Vulkan.
The problem is that historically, this is what's lead to tons of issues in games. Drivers make their own "optimizations" resulting in terrible performance for some task on one GPU, and great performance on another. Or instead of performance differences, it's outright bugs.
Then, combine that with GPUs being fairly expensive, and fast moving when it comes to new features. Most game studios aren't going to buy 20 different GPUs and test their entire game on all of them. So games often ship with terrible performance or bugs on various different GPUs. And it's often not the game's fault: are games really supposed to detect your exact GPU model, and change code paths to work around a driver bug? That's crazy.
To combat this, GPU drivers often get updates after a game launch that fix the issues with performance/bugs for specific games at the driver level, when it detects that those games are running. So now drivers become a pile of game-specific hacks, making the problem even worse.
This is the reason Vulkan is so low level. The goal is to make sure drivers don't get horribly bloated, and games aren't working around driver-specific bugs (they still happen, just hopefully less). And when games want to use specific GPU features for extra performance, instead of drivers trying to magically improve normal operations, they can make a vendor-specific extension providing the new functionality that games can opt into when the feature is detected (e.g., raytracing). That's part of why Vulkan has so many more extensions than OpenGL does.
Vulkan may be low level, but it's intended to be so. By foregoing Vulkan support, Apple rejected any attempt at making a higher level API on top of Vulkan that would work on every system. Instead, WebGPU has to try and abstract over Vulkan/Metal/DirectX12 separately, which mostly works, but leads to a whole lot of clunk and longer development time than if Vulkan was the standard everywhere.
That's not to say macOS should never have made Metal. But by not adding Vulkan support in addition later on, they're really hurting cross-platform compatibility. Sure, now Apple can optimize their platform to the best of their ability (theoretically). But that comes at a huge overall cost to the ecosystem, for instance with games having poor support for macOS.
* Automatically figuring out which parent objects the class you're subclassing derives from, instead of having to import and then list out all of them individually. This is for the glib::wrapper!() macro. * Automatically filling out ObjectSubclass, and WidgetImpl, etc. * Helpers for properties and signals * A flat list of methods, instead of the public/imp split
The bigger issue that Relm solves imo, is state management. I feel like I had a difficult time figuring out how to share state between widgets. You end up with lots of OnceCell, Rc, and RefCell, and it quickly becomes confusing, especially when you start subclassing GObject and making your own objects.
As soon as I think of a good project to work on, I'm going to try out Relm4 and see if it is better than gtk4-rs.
The gtk4-rs book has a tutorial on them: https://gtk-rs.org/gtk4-rs/stable/latest/book/interface_buil...
Gladis seems to wrap the child widgets in a regular Rust struct. The composite template stuff in GTK uses subclassing to make a new widget wrapping the child widgets.
GTK has a better approach imo - the issue is that the macros for subclassing in gtk4-rs are _really_ verbose and confusing. You need two different structs, with several trait impls on them. Adding GObject properties is verbose and tedious. Adding methods on the widget is confusing - it's confusing which struct the method goes on and how to access the widget in each part.
Overall I liked GTK for the end result it produces, but not the API. I've been meaning to give Relm4 a try - it seems like a much better way to handle state and widget composition in Rust than the vanilla GTK stuff.
On one hand, the police being paid for by the company for their enforcement, especially so much money, definitely creates perverse incentives for the police officers to disrupt the protests more than they should.
On the other, the police were going to do it anyways because several of the protesters were breaking the law. I'd rather the police be doing this than a private enforcement company who is entirely dependent on the pipeline company, without the additional duties of being a police officer.
So I'm not sure where to stand on this.
Reusing native stuff is fine - it provides rendering, text, accessibility, window management, and other hard stuff for you. But it's not equivalent to a native app, because you'll never conform to each platform's UI guidelines without significant work per app.
1. LiveViews were kind of weird to fit in, as they were a separate format
2. Webpack was the bain of my existence, it was slow and hard to figure out as a first time webdev
Glad to hear this is being fixed! Looks like I'm going to have to go back and update the site
The switch is for everyone else - way cheaper, unique games you won't find on a PC, etc. Plus, co-op. I recently spent 6+ hours at my friends house playing Super Mario 3D World Deluxe. They got one joycon, I got the other. In my college dorm, we have a switch dock attached to a monitor in the dorm lounge. Split the joycons, and 4 people can play smash or mario kart. I don't see the deck supporting these use cases.
So then yeah, sticking with a load screen _might_ be easiest. But if the tooling supports it, it might be even easier to just not worry about loading and having to make a loading screen, and let the engine handle that stuff for you. UE5 at least seems to be going in that direction.
* gtk-rs is fairly good, very completely and functional bindings to a functional library. But GTK is also very GNOME/linux centric, is tricky to learn, and not developed as stable or as fast as you might want. Not to knock on the GTK/gtk-rs teams, they're doing amazing work, and imo the best open source GUI library. They've even made great strides in documentation with the new website and API docs recently. Just not quite good enough yet to be recommended for general purpose use. But if you insist on making your GUI in rust, gtk-rs/gtk4-rs optionally with libadwaita-rs is what I'd recommend.
* druid and iced are both promising, but too incomplete.
* egui and RAUI are nice, but meant for gamedev.
And yeah that's a niche example, maybe this is super helpful for writing a react app or something very library heavy. But gut feeling without trying it is that there's no way this could actually work on anything but the most common tasks that you can google and find solutions for already, just made easier so you don't actually have to google for it.
When I used tabnine which learned from you as you edit, it was fairly helpful for very repetitive code within the same project. But it was no where near "read english and write the code I meant for it". I'm curious to know how well this actually performs for non-common tasks, and whether it can understand ideas in your codebase that you come up with. If I make a WorldAbstractionOverEntities thing in my code, and then later use it in the project, will the AI be able to help me out? Or is it going to go "sorry, no one on github has used this thing you came up with an hour ago, I can't help you". An AI that could understand your own codebase and the abstractions you make and not just popular libraries would be infinitely more useful imo.
That said, I haven't tried this, maybe it'll turn out really good.