Just write it all in Java, no need to worry about fancy modern GUI toolkits or SSD vs CSD when your application looks like it hasn't been updated since 2008!
Or C#, the popular Avalonia framework provides cross-platform GUI support. That way, they'd be able to have the same developers who're working on the Agent part of Bottles also do work on the UI.
Imo, the issue with Electron isn't just "it uses too much memory" (although it definitely does, but that's mostly not a problem in and of itself in current year). It's the general trend it represents - developers, especially those focussed on the web, getting less and less concerned about performance. While this generally isn't noticeable in the app itself, a big issue I run into frequently with Electron apps (and many websites) is that when they're running, other apps have degraded performance. This is more noticeable on my laptop, or my older desktop playing some newer games. It probably doesn't HAVE to be this way, but because resource-hungry tools are nice to use, they keep being used.
Yeah, I can make an app quickly or I can make an app *run* quickly, can't really do both. I can build a vue3 app in hours what it would take me weeks to do in flutter, and months to do in cpp + gtk If I am working alone, its super appealing to be able to see progress so quickly.
The issue with electron is also - every copy of electron in apps is unique - so they do not share the code segment. + the chromium codebase is way too big for decent audit. And lots of other issues.
vscode is a good example, i ran nicely on my crappy pc but other electron apps were slow as heck, but they did a lot of work to optimize it and that cannot be expected of a hobby/smal project
I'm working on a project using libcosmic and yeah, it works OOTB fine in 99% of cases on different DEs (there are quirks I've seen my friends-testers mention but that can be ironed out)
That's the blessing and a curse of FOSS development. You don't have to make everything as time/cost efficient as possible, you can write your app with a super young toolkit just because you like it
I won't be surprised if C# will be up for debate. It's possible to build Rust programs for Windows which could use a Windows named pipe (or Unix domain socket with winelib), to communicate with an application running natively in Linux. Microsoft has invested heavily in Windows API support for Rust.
We’re testing that right now, looks very promising, already have a working system using gRPC, a CLI talks to the server and the server talks to the agent, all written in Rust.
@@flame.sniperyeah, and gtksharp, i used gtksharp for a uni project and it works really well, but it doesn't have documentation other than everything having the same naming as the c functions so you can use the gtk docs
Yep, the original Next concept was going to have an electron and GTK4 interface. When it released people will probably make them one in all the major toolkits.
...meanwhile I just use Bottles as a convenient Wine CLI on Bazzite. I rarely interact with the GUI itzelf, I just don't want to mess around with Wine dependencies.
I have never ever used a electron app that feels good to use. They're literally always sluggish and laggy. So proudly announcing that your rewrite will be very bad, is just weird.
For what it's worth I'm happy with Freetube, which is an electron app. I even tested using it on a catastrophically underpowered laptop (4GB of RAM, Intel pentium T4500, only saving grace is I swapped the spinning rust for an SSD) and aside from the part where playing video itself isn't stutter free (and that's down to the laptop's limitations, I checked with playing the same video using MPV and not even that was enough), the UI is plenty fluid. A libcosmic youtube frontend, now there's an idea.
@@onceuponaban It's possible given that cosmic-player is now ready for prime time. Since libcosmic uses wgpu for rendering, we can get access to wgpu shaders for improving video player performance. A shader is already being used for faster color space conversion. Just need some improvements from iced to get backported to improve GPU usage when moving the mouse around the interface.
I am glad they didn't went Electron, I'd give up on Bottles right way if they did so. I am also glad they they moved on from the GTK/LibAdwaita/Gnome bs. Besides that, whatever else they choose would've been fine by me. I don't care the language a program is written as long it works(rust haters gonna hate), and LibCosmic doesn't seem extremely restrictive and a cheap MacOS UI clone like GTK/LibAdwaita is, hope it comes along nicely and fast, Bottles is one of my favorite Linux programs and I use it on a daily basis.
Sane, I don't care if it's written in plain C, JS, Java, C#, Rust, C++, Python, Nim, Zig, R, hell even BF, if it works I'm happy.(how to start a war in 99 seconds)
Even though I am generally not a fan of using non stable releases of toolkits since I have the tendency to break them very very hard. The sheer number of projects using libcosmic now is such that any issues that do arise should be able to be fixed very quickly and it seems mature enough to be usable right now.
@@BrodieRobertson There’s a book 📕 in development, API docs are in a pretty good state, multiple examples in the libcosmic repository and a GitHub template to get started. You can find them all in the repository, you’ll have to search it cause posting a link got my last comment deleted I believe. 😅
@@BrodieRobertson There's a link in the readme for the API documentation, an app template that supports cargo-generate, a handful of examples, and the book covers everything necessary to get started. I may add examples for each widget, but the API docs already do that well enough.
Wow, libcosmic does look beautiful, especially with that demo version of Bottles Next. I'm already semi-proficient in Rust, so I might give it a go for my next application!
I'm running Bottles on Plasma, and I have no experience with libcosmic apps (nor am I a fan of Rust), but I'm excitedly waiting to have libcosmic-basex Bottles.
@cameronbosch1213 I tried, and I don't like it as a language - it's interfaces syntax is very limiting and it's hard for me to create the semantics I want. I'm currently programming in Ruby, Java, Qt, C++, TypeScript, PHP, Perl, C#, JavaScript and Go (in order of preference, and only the things I actively use) - and I prefer each of them better than Rust - even Go, that I'm still having trouble wrapping my head around some of it's stuff. I'll note that Qt isn't exactly C++ - it's a superset of C++ with some extra features that make message passing and handling a lot of fun (in addition to a rich class library that rivals Java's).
@@cameronbosch1213qt has partly the same purpose as rust, to make programming safe or at least safer and more solid. Except that qt does not hide c++/c, but at least the developer must '''only''' abandon his habits and try to use only what qt provides. Then there is the synchronous event management. The slot/connect mechanism is a potentially good part, but requires understanding and knowing exactly what you are doing, otherwise it quickly becomes chaotic. It has multithread management, but I have no direct knowledge, except crashes in third-party programs. qt significantly decreases the risk of crashes and it is easy to fix them, but it does not prevent the generation of anomalous/chaotic uses and behaviors, which are as always difficult to flush out.
@@cameronbosch1213 my recommendation about learning a programming language is that (a) you should pick up something that jives with your style, and (b) one is not enough - how will you know which is best for you if you only try one? Rust has an advantage that it is rather small, so it's easy to cover most of what you need and still have the time to pick up a second language by the end of the week. Qt, OTOH is based on C++ - which is huge: it's one of the largest (if not the largest) languages ever, before they added more stuff. But you can do quite a lot of damage with just QML and a bit if rudementary C++ - or even Python - which BTW, Qt has good Python support, so if you are interested in GUi development, it's probably a good idea to know Qt, and you don't even need C++ for that.
I love that the app is structured in such a way that these rewrites are even possible. Yes GUI is important, but without the capability there would be no app. The fact that you can rewrite GUI and not touch the capabilities of the app (except for exposing the capabilities via the GUI) is awesome and would allow for another rewrite in the future if libcosmic and/or rust hype possibly dies.
I'm glad to be away from electron. That said I'm honestly not an electron hater. Like we've just kinda failed a making easy consistent UI app interfaces. The browser, unfortunately, presents pretty much the simplest solution to this problem. Although at great cost.
The mpv frontend Celluloid does the SSD on Libadwaita pretty well. It adds a regular menu bar if you turn off the CSD. Of course everything else still looks off. Mirko has said on your podcast that he had to wrestle with the Gnome community everytime he strayed away from the Adwaita HIG so I can imagine why he doesn't like it.
You know libcosmic and QT both support CSD. TBH, I don't know any libcosmic application that doesn't have CSD, everyone wants their UI framework to work best on their own DE, not others...
I really like the approach of localsend (ie. flutter (with material theme) + golang) This allows cross platform even android / ios as first class citizens which is nice. Though I can be okay with rust as well , its just that rust is really hard & I admire simplicity
04:48 libadwaita hamburger menus have big black bezel when running on x11 without compositor windows have different border without shadow and without rounded corners when no compositor but not menus!
There's all this complaining around the UI side of things, but at the very least the server-client model gives users and developers more of a possible choice to go for a different UI. The question then becomes how many people there are to actually _build_ alternate UIs. Then again, I was never really aware of Bottles before this video and now I want to look into it. You're exposing more people to it once again; very nice.
As a frontend dev, building your GUI-heavy app on an alpha-quality library is absolutely crazy. They're going to have nothing but troubles. I personally chose Flutter for that, because it has years of battle testing and has had many many iterations after already being production-ready. Dart isn't as good as Rust, but the framework is way more important than the language for GUI applications.
15 днів тому+1
Since the move to GTK3 and now 4, GNOME has become the worst desktop environment I've ever had the displeasure to use. I'm glad more projects are deprecating it
man, the idea of bottles having 1 unified wine environment is really nice. just hope they get something figured out. i prefer using bottles over lutris because i just find it simpler to use.
Can we get a video on client-side decorations and server-side decorations? This topic has come up a few times, but I don't know if it has ever actually been discussed.
I always do that on Lutris, running multiple programs in a single wine prefix, I sometimes do that so that I dont have to install dependencies multiple times and for programs that have dependencies to another program....
I love bottles! And the demos for Bottles Next looks great. Ik many ppl love lutris or Heroic, but honestly bottles is so versitile and clean, but as a GNOME enjoyer, I 100% get, why ppl dislike GTK Apps on something like KDE. (The GTK dominance on the Flathub is one of the reasons I'm on GNOME, lol)
Agreed, I would still take libadwaita over electron. I fixed some of the issues he is having by patching gtk itself on my system. Nothing I can do to solve electron's problems.
@@cameronbosch1213 I don't know what you are talking about. I was simply stating my preference of libadwaita to electron. I didn't make any remarks on what the project is using to my knowledge.
I actually don't really care that a program is consistent with the system UI myself - as long as they aren't trying to imitate the system UI but not actually doing so properly, because that just leads to weird off-putting awkwardness where things don't quite match up. That said, it does also somewhat depend on whether or not it's trying to sell itself as a part of the system, or a separate application you went out of your way to install - Bottles would fall in the latter category for me.
OH MY GOD, not having a singular prefix was the only thing that turned me away from Bottles and forced me to write my own scripts per game, this is so good
Don't have time to watch yet so don't know if it's mentioned, but I'm really curious to know if they considered Tauri if they initially were thinking of Electron and if so why they decided against it.
CSD as a sole system is dumb, and libadwaita is ultra basic. The hybrid CSD-SSD approach that KDE took is by far the best compromise. So yes, yapping against CSD and libadwaita is warranted.
It's a drop-in replacement for Electron that's superior in every way. Tauri is a high level Rust framework enabling you to build desktop applications using your platform's native webview library. Since the application's interface is described via HTML/CSS and JS, you can either develop your application in JS with a JS web framework, or develop them in Rust (perhaps even with a Rust web framework). This renders your application with WKWebView on Mac and iOS, WebView2 on Windows, WebKitGTK on Linux, and the Android System WebView on Android. And therefore unlike Electron, you don't have to bundle your app inside of a custom web engine, so you don't have to compile your application inside of Electron's source code.
When did you update the outro to include "--no-preserve-root"? Anywho, I'm looking forward to Bottles Next, I don't really care how they get it done, but one shared prefix sounds amazing for when you need to use modding tools. It's been a bit bothersome getting Mod Organizer 2 to behave with certain Bethesda games as an example.
Has anyone tried to use bottles for office 2021/2024? Its the only thing holding us back to fully transition to linux on all PCs. And no, Liebreoffice/onlyoffice and so on are unfortunately No alternatives, already tried that.
@@Wkaelx Very long startup times with high memory usage and slow garbage collection. Fractional scaling and Wayland are not well supported. Oracle has abandoned Swing. Wakefield and Caciocavallo are a WIP and require rebuilding the entire JDK. Not worth it. Better to switch to Rust at this point.
My only problem with electron is that youre basically shipping a full browser with your application, otherwise is very practical and fine. If you dont care about performance and storage, electron is perfectly fine. Im actually avoiding using online electron apps bc i realized that you can actually use the web version with all the features hahaha. Discord, Teams, Spotify... All work perfectly on the browser instead of the app.
To be honest, the only graphical toolkit which doesn’t suck is gtk3. It can be easily themed with css and there are lots of themes already. Gtk4 is usually paired with libadwaita, which is impossible to theme. QT has too many standards and it’s very hard to make it look consistent even if only using qt apps (unless using breeze). Electron is notorious resource hog. Libcosmic is not really themable atm from my understanding, but it looks promising.
6:56 Those are Go GUI libraries, but yeah, even though Go has those libs, they are just... fine. Not great, but fine. I get why the devs don't go with Go (no pun intended).
Yeah, Go really shines at TUI with programs like lazygit, FZF, LF, and many more which I use regularly. Go is actually really great for most of programming (even system, with its CGO and assembly support). But for some reason, its GUI ecosystem never really took off...
Change the UI framework? Fine I guess. The real problem is that they keep rearranging options and introducing weird UX choices for things that were never a problem to begin with, an example of this are the shortcuts you can add to your bottle's program list, for some reason it only allows you to launch a single instance of the same application from there unless you go to the kebab menu and explicitly choose the "launch with terminal" option.
The Bottles webpage still has Apex:Legends on it, the developers of that game has blacklisted Linux. I never used Bottles, I prefer go outside the repositories as little as possible and when I do I use the AUR or I compile from source. I don't have the need for Flatpak. Maybe OBS is packaged wrong for Arch (fair enough) but that which is missing is not something which I need for how I use OBS.
Bottles is a godsend for me, i can do so many advanced things in Linux yet with any other tools i have only managed to get 1 game running, but with bottles? Pretty much anything will run.
As a Gnome user i like libadwaita, but i agree that clientside decorations as a default is stupid. As a web developer I have no issues with Electron. Cosmic looks promising.
Libcosmic might have been the right call. GTK is restrictive and I've seen enough devs say QT can be a nightmare to work with. Either way I'm glad its not Electron.
Default QT is a nightmare, QML is less. QML feels somewhat as a merge of CSS and HTML into a JSON5-alike structure (Though I have no clue why they decided to stuff JS into there)
the one time i tried to use Qt getting the libraries and build toolchain set up was an absolute nightmare. at least with gtk and libadwaita you can just install the packages from your distro's repos and swap in whatever cxx toolchain you want and forget about it. distribution also seems like a nightmare, they really should just give up on their weird licensing setup and just go full FOSS
ever since I figured out how to get games running through steam/proton, I haven't used bottles or lutris. maybe there's advantages, but it's been nice having everything in steam. And while there have been some issues, it's been relatively simple to figure most things out. Mostly protontricks/winetricks. If I config winetricks, then protontricks the same as I would winetricks, I think that's what works. I'd be interested if anyone could shed some light on why that might be though. It's been slightly annoying.
its kinda ridiculous how effective Rust is at rekindling joy and fun in developers, despite it being a lanuage everyone admits has quirks, a tough learning curve, and long compile times. call it a cult, whatever, i call it joy. i like joy, and i'm not an un-cynical person.
It had a tough learning curve in 2015, but with the 2024 edition that's no longer an issue. The borrow checker is nowhere near as strict as it used to be, and error messages over the last few months have gotten significantly better. Despite error messages already being really good by the 2021 edition.
Surprised that they aren't going with Flutter/Dart. Am very much biased, but feel that it is the most flexible, mature and performant, far more so than even libcosmic at this stage and, thanks to work by Canonical, has a mature GTKesque UI library in the form of yaru.dart.
@@dashcharger24 No, it isn't. It's used by the Google Adsense team for their dev work. Adsense are the only team at Alphabet that reliably brings in billions, so Flutter has a solid future.
@@dashcharger24 Flutter has just been updated (11.12.2024) with some major improvements and is used for development by the AdSense team, who are essentially the biggest source of profits for Google/Alphabet. Unless they want to cause their moneymaker to completely rebuild internal processes and pipelines, Flutter will be maintained.
@@dashcharger24nope, by far the best cross platform toolkit. I would love to use stuff like tauri, but flutter's ecosystem and solid design is hard to beat.
Honestly, while I dislike libadwaita apps for looking out of place, I am kinda used to thing being inconsistent from the Windows land. Electron apps in the meantime make me question what even is the RAM being used for. Even with 32GB in my setup, I don't want a UI toolkit this wasteful on my system since some games benefit from plenty of memory, that's especially the case for modpacks that spike in memory use.
Going to be a bit of a culture shock moving from Go to Rust. All the influencers and sites make it out to be the holy grail but the two languages couldn’t be more different in syntax and the ethos. Lost count how many times I started writing something in it and initially liking it but gave up and went back to what I know because I needed to get the job done. Unlike other languages where you can learn it by building a practical project, you need to know the theory first.
I have never understood why having Qt, people opt to GTK. I have developed in both with C++ and Python. To this day, I still find no reason not to go Qt by default.
Frankly, i still don't understand why bottles needs a new ui. Yes, a more controller featured mode would have been great, but the current gtk ui is just incredibly smooth, as compared to basically any other technical app in the linux ecosystem. I also doubt they'll manage to match gtk/adwaita's QOL on touch screens.
They need to start from scratch to change to the client-server framework in order to support the single prefix utility inside the prefix. It will therefore need a new UI. GTK and libadwaita aren't doing anything special with touch that other Wayland GUI toolkits can't also do. Libcosmic already supports touch.
The fact that it looks like ass on anything that isn't GNOME would be reason enough on its own. In fact "I can't look good outside of GNOME" is a perfectly valid reason for anything that isn't part of the GNOME project to abandon the GTK+libadwaita stack.
have you used bottles? even without gtk/libadwaita the ui is a complete organizational nightmare. if the rewrite gives them a chance to just start from scratch and fix it i'm more than happy
As someone who only recently started using Bottles because of a certain mobile game, the one thing that I don't like about it is the UI. To be fair, all of these Linux games launchers have bad UIs. I probably would still hate Steam's UI if I hadn't been using it for years, but Bottles in particular has a little too many layers of nested menus. To even launch the one game I use it for, I have to go into a sub-page for that application because god forbid my "run launcher" option can't intuitively be set to the default behavior.
library exists?? But yeah, running it the defalt way is kinda annoying, you need to open bottles, select the app, select the prefix... I think if you really want to, you can DIY a .desktop with a launch command, but I'd like to see that automated
@@qlx-i Thanks for talking about the Library. I think I'd seen it up there but it never had anything in it so I ignored it. I am literally the "oh you can jump?" guy who has been trying to beat mario for an hour right now
Although I think rust is very efficient in some other contexts, I don't think frontend development is one of them. I think eventually the stiffness of the borrow checker/lifetimes are going to get you and slow down development, also the compilation time and the JS inspired culture of 1000 deps for a hello world are going to be a hurdle as well. But, given the lack of options for GUI libs in Linux, I do understand this back and forth, however IMO I think developing a good golang lib for this would be the best choice, even so given bottles devs are comfortable with Go.
The Elm approach to GUI development (MVU) is a perfect match for Rust's borrow checker and pattern matching features. There are never any borrow conflicts because the app model is only mutated in the update method, and the view method does not require mutability. There's never an overlap in mutable borrows, and no need for interior mutability either. Views are even able to borrow values directly from the app model because the lifetime of the view is tied to the app model upon being borrowed the view method. A lot of web developers also prefer this approach to GUI development because of how it simplifies the logic in the app, and enables applications to be reloaded without losing state. Since views are generated directly from the model, the model always reflects the state of the UI. An app developer could, for example, save the app model to disk on exit and then reload it on startup as if it were never closed. The borrow and lifetime checker is also a compile-time checker. It does not happen at runtime, and therefore does not impact performance. Performance is actually improved by it because it allows the compiler to assign noalias tags to most things. This allows the compiler to more aggressively and reliably apply optimizations like autovectorization.
4:42 I can say the same about qt or other similar interfaces, on my desktop they look like I'm running something from the Windows 3.11 era, as if 30 years of ui and ux development were just thrown out the window
i kinda like client-side decorations, provided they are good and optional. for example, firefox has great client-side decorations. they look good, save space and are completely optional, not removing any functionality when disabled. that's good client-side decorations. gtk and libadwaita still suck though. to the point that i'm genuinely wondering if the Gnome devs are really just incompetent or outright malicious, trying to ruin the Linux desktop or at least the competition.
My issue with libcosmic is that it essentially looks the same as libadwaita right now on non-Gnome desktops. Cosmic is great, but the style of the libcosmic toolkit just isn't it.
@@mmstick It's less the color scheme I'm talking about and more the style of the windows/decorations. libcosmic applications have the same CSD headerbar style that libadwaita apps have on Plasma. I understand *why* it's like that (since you'll be migrating users away from Gnome and don't want to shock them) but it still makes the applications look non-native on literally every other DE out there. And since I want and expect Cosmic to blow up, it means that it will only cement the giant headerbar CSD look as "the Linux Native look" going into the future.
@@Daktyl198 Windows and Mac OS X are also using CSDs today, so I'm not sure why that would be considered native to Linux specifically. It definitely doesn't use the same headerbar style as libadwaita though. There's a completely different design guideline for that, in addition to differences in the theme engine. Regardless, nothing stops KDE from applying a custom theme to COSMIC apps to make them integrate more cohesively there. Same for GNOME. Just as COSMIC supports integrating COSMIC theming with GTK applications, and later KDE once they adapt to using Union.
@@mmstick Windows and mac are CSD, and there's nothing wrong with CSD on the backend. It's the visual style of GTK and libcosmic that I'm talking about. You can't sit there and say that GTK and libcosmic don't have "the same headerbar style" when they definitely do. Icon font and specific colorings/spacings aside, GTK and libcosmic are the only toolkits that default to 40+ pixel tall window decorations with large buttons placed inside of them. Themeing has nothing to do with what I'm talking about. My point is that Gnome is the only non-alpha compositor to default to those style headerbars. KDE, XFCE, LXQt, Cinnamon, MATE, Sway, Hyprland, etc etc ALL default to a default old-school Windows or mac style window decorations (if any decorations at all) with optional CSD. This means that those style headerbars are foreign in the "Linux ecosystem", even if Gnome has a large marketshare. Given that I want and expect Cosmic to quickly blow up in marketshare, it's only going to cement what is currently foreign design language as "The Linux design language" since two out of the 3 largest DEs will be using that language, but it effectively means non-native looking apps for 90% of the compositor ecosystem unless they change their ways. Fwiw, I personally like the look of libadwaita even though I don't use Gnome, but it's always jarring when opening one of their apps and it looks and works so different than 95% of my other applications, even those that use CSD. libcosmic design language doesn't quite appeal to me yet, but I'm giving it time as I'm excited about Cosmic itself.
@@Daktyl198 You should actually verify statements like that. The headerbar in libcosmic has configurable density, does not use hamburger menus, and prefers menu bars.
I like Electron If there is no other way developers bring software to Linux and maybe macOS otherwise. If a program doesn't rely on web connectivity, I could live without it but the more options there are, the better I guess.
Seems odd. I don't get the problem with all the other UI frameworks and libraries. And if all of those are problems why go to rust, a language not really supportive of gui's, and even then why use something still labeled as a WIP that is designed only for COSMIC? And if they are doing it in libcosmic and gtk that just seems like extra work.
@@mgord9518 First, time. There are languages with much longer running, feature rich libraries and frameworks to use. Second, purpose. I can't imagine rust lending itself well to the frontend. You can make a game in python? Sure. But it is not Python's strong point.
@@gsgregory2022 The state of GUIs in the Rust ecosystem is more varied and active than any other. Many of these GUI projects have been developing libraries which enable cross-project collaboration. Linebender's tiny_skia, Bevy's work on wgpu, and libcosmic's cosmic-text are used in most GUI libraries now. The existing state of GUIs on Linux is so bad that even a WIP Rust toolkit can quickly elapse GTK with a little bit of effort. Rust lends itself very well to the Elm approach to GUI development.
@@gsgregory2022 some rust web ui frameworks use the macro system to let you write html *in your rust code* without a preprocessor like react needs. i'd say that allows for quite a bit more user friendly experience than anything written in C/C++ like gtk. nothing in the language itself prevents writing good UIs, and even if you don't do crazy metaprogramming things, people have been writing UIs in C for years just fine and it's not any easier or harder than rust
@@SmplySilver We're doing our best to avoid macros in libcosmic. Similar to iced, all APIs are exposed as functions which can be chained together. The Apply trait is also useful for keeping that chain going when you need to apply a function-or wrap the return value-before returning it. This gives us a really nice functional GUI API.
Electron is my last choice when being forced to use software. Just saying. Bottles developer is awesome and has very high attention to detail and UX. I respect his choices and I doubt that he would have picked Electron unless no other choice existed.
1:31 oh I sort of do a hybrid of the two systems. I have one bottle that runs pretty much everything and then if a bottle requires much customisation it gets its own separate one. Layering would be much more clever, save on storage requirements
Just write it all in Java, no need to worry about fancy modern GUI toolkits or SSD vs CSD when your application looks like it hasn't been updated since 2008!
thx but do i pick swing, awt, swt, javafx, vaadin, ...? they all have this awesome retro look and feel
Or C#, the popular Avalonia framework provides cross-platform GUI support.
That way, they'd be able to have the same developers who're working on the Agent part of Bottles also do work on the UI.
Just use java for everything
RRIJ
while I get the joke, that's not the case with JavaFX and whatever Jetbrains (that maker of Intellij and more) use
Imo, the issue with Electron isn't just "it uses too much memory" (although it definitely does, but that's mostly not a problem in and of itself in current year). It's the general trend it represents - developers, especially those focussed on the web, getting less and less concerned about performance. While this generally isn't noticeable in the app itself, a big issue I run into frequently with Electron apps (and many websites) is that when they're running, other apps have degraded performance. This is more noticeable on my laptop, or my older desktop playing some newer games. It probably doesn't HAVE to be this way, but because resource-hungry tools are nice to use, they keep being used.
Yeah, I can make an app quickly or I can make an app *run* quickly, can't really do both. I can build a vue3 app in hours what it would take me weeks to do in flutter, and months to do in cpp + gtk
If I am working alone, its super appealing to be able to see progress so quickly.
The issue with electron is also - every copy of electron in apps is unique - so they do not share the code segment. + the chromium codebase is way too big for decent audit. And lots of other issues.
> discord
TwT
+
vscode is a good example, i ran nicely on my crappy pc but other electron apps were slow as heck, but they did a lot of work to optimize it and that cannot be expected of a hobby/smal project
im glad they turned away from electron
Yup. Instantly saved 100 megabytes.
Electron is a Java equivalent of current days. I remember 20 years ago: "why this app is so not responsive? It's written in java!".
@@pablloseeto be fair, other languages gave unpredictable issues. Java at least brought something useful running on a interpreter.
@@ToumalRakesh o wow incredible savings totaly makes the difference when you have 16+ gb ram and multi tb storage
@@bigpod Just because I have 16 GB of RAM doesn't mean all of it is for you. I'd prefer to have less RAM.
If system76 could build a full DE with libcosmic, then it's probably good enough for a single app too, as long as it doesn't depend on the whole DE.
I have used libcosmic once for a test and and I can confirm that it does not require the desktop environment to work
Luckily, all of Cosmic is pretty modular by design.
It's our intent that COSMIC applications be able to run on-and adapt to-any OS and environment.
Yep, I developed a dummy app with libcosmic and it worked in cosmic, KDE Plasma, and gnome without adding any config
I'm working on a project using libcosmic and yeah, it works OOTB fine in 99% of cases on different DEs (there are quirks I've seen my friends-testers mention but that can be ironed out)
That's the blessing and a curse of FOSS development. You don't have to make everything as time/cost efficient as possible, you can write your app with a super young toolkit just because you like it
I won't be surprised if C# will be up for debate. It's possible to build Rust programs for Windows which could use a Windows named pipe (or Unix domain socket with winelib), to communicate with an application running natively in Linux. Microsoft has invested heavily in Windows API support for Rust.
We’re testing that right now, looks very promising, already have a working system using gRPC, a CLI talks to the server and the server talks to the agent, all written in Rust.
What I mean is from the start he was set on using C# whereas with the front end from the start he was willing to play around with other options
There are C# GTK bindings out there. Parabolic used to use them. I think the name is Gir.Core ?
@@flame.sniper This isn't about the GUI but the windows service that communicates to the GUI from within the wine environment.
@@flame.sniperyeah, and gtksharp, i used gtksharp for a uni project and it works really well, but it doesn't have documentation other than everything having the same naming as the c functions so you can use the gtk docs
let's play a fun game, take a shot every time brodie says "steam deck"
So it needed a new UI specifically for the steam deck?
if they are breaking it up into model view separation, doesnt that mean anyone could just write their own alternative interface for it?
Yes, they could. Depends on their communication protocol and how open they are on sharing the API.
Yep, the original Next concept was going to have an electron and GTK4 interface. When it released people will probably make them one in all the major toolkits.
We’re most likely going with gRPC as the communication protocol, so any language that supports gRPC could be used to create a client.
Did you read that? I didn't read enough to conclude that. It's a client-server but not necessarily Model-View.
@@rGuntiit's an open source project, it's not a question of if but of how much documentation
*THE JAR*
Jarvis rewrite rust in rust
Pretty sure the rust compiler could already compile itself.
Rust is already written in rust.
Jarvis rewrite Rust(the videogame) in rust
@@joshix833 thx smart guy
@@rigen97 yeah rust bootstraps itself now.
...meanwhile I just use Bottles as a convenient Wine CLI on Bazzite. I rarely interact with the GUI itzelf, I just don't want to mess around with Wine dependencies.
Figma balls lmao
2:30 seeing a loop of the same thing again. i think that happened on the last video too
I heard it and thought Brodie was stuck in a mental loop.
This seems fairly common throughout a lot of his videos. I think he accidentally includes multiple takes of certain lines from the script
Don't worry, you'll get used to this
I wish he just stops attempting to fix these things, because changing video duration messes up sponsorblock
@@felixfourcolordo any of his videos even have sponsors? i certainly dont remember seeing one
It's impressive how System76 has been able to bring new things in the linux Desktop so quickly with Cosmic.
I have never ever used a electron app that feels good to use. They're literally always sluggish and laggy.
So proudly announcing that your rewrite will be very bad, is just weird.
Good thing they moved away from that.
For what it's worth I'm happy with Freetube, which is an electron app. I even tested using it on a catastrophically underpowered laptop (4GB of RAM, Intel pentium T4500, only saving grace is I swapped the spinning rust for an SSD) and aside from the part where playing video itself isn't stutter free (and that's down to the laptop's limitations, I checked with playing the same video using MPV and not even that was enough), the UI is plenty fluid.
A libcosmic youtube frontend, now there's an idea.
@@onceuponaban It's possible given that cosmic-player is now ready for prime time. Since libcosmic uses wgpu for rendering, we can get access to wgpu shaders for improving video player performance. A shader is already being used for faster color space conversion. Just need some improvements from iced to get backported to improve GPU usage when moving the mouse around the interface.
I am glad they didn't went Electron, I'd give up on Bottles right way if they did so. I am also glad they they moved on from the GTK/LibAdwaita/Gnome bs. Besides that, whatever else they choose would've been fine by me. I don't care the language a program is written as long it works(rust haters gonna hate), and LibCosmic doesn't seem extremely restrictive and a cheap MacOS UI clone like GTK/LibAdwaita is, hope it comes along nicely and fast, Bottles is one of my favorite Linux programs and I use it on a daily basis.
Sane, I don't care if it's written in plain C, JS, Java, C#, Rust, C++, Python, Nim, Zig, R, hell even BF, if it works I'm happy.(how to start a war in 99 seconds)
most rust haters don't know why they hate it (the community is a valid reason)
@user-sb5vt8iy5q community. compatibility (see the mess with Linux kernel right now). Syntactic sugar.
I'm a golang guy, and I'm 100% with him on rust being g better just because there are legit toolkits. There are none in go.
Even though I am generally not a fan of using non stable releases of toolkits since I have the tendency to break them very very hard. The sheer number of projects using libcosmic now is such that any issues that do arise should be able to be fixed very quickly and it seems mature enough to be usable right now.
For alpha software the API is surprisingly stable.
What exists in the way of documentation right now, because my understanding is there's not much
@@BrodieRobertson There’s a book 📕 in development, API docs are in a pretty good state, multiple examples in the libcosmic repository and a GitHub template to get started.
You can find them all in the repository, you’ll have to search it cause posting a link got my last comment deleted I believe. 😅
@@BrodieRobertson There's a link in the readme for the API documentation, an app template that supports cargo-generate, a handful of examples, and the book covers everything necessary to get started. I may add examples for each widget, but the API docs already do that well enough.
Wow, libcosmic does look beautiful, especially with that demo version of Bottles Next. I'm already semi-proficient in Rust, so I might give it a go for my next application!
I'm running Bottles on Plasma, and I have no experience with libcosmic apps (nor am I a fan of Rust), but I'm excitedly waiting to have libcosmic-basex Bottles.
Is there a reason you don't like Rust? I'm legitimately curious. (I want to learn Qt, but I heard they currently only have C++ bindings...)
@cameronbosch1213 I tried, and I don't like it as a language - it's interfaces syntax is very limiting and it's hard for me to create the semantics I want. I'm currently programming in Ruby, Java, Qt, C++, TypeScript, PHP, Perl, C#, JavaScript and Go (in order of preference, and only the things I actively use) - and I prefer each of them better than Rust - even Go, that I'm still having trouble wrapping my head around some of it's stuff.
I'll note that Qt isn't exactly C++ - it's a superset of C++ with some extra features that make message passing and handling a lot of fun (in addition to a rich class library that rivals Java's).
@@cameronbosch1213qt has partly the same purpose as rust, to make programming safe or at least safer and more solid.
Except that qt does not hide c++/c, but at least the developer must '''only''' abandon his habits and try to use only what qt provides.
Then there is the synchronous event management.
The slot/connect mechanism is a potentially good part, but requires understanding and knowing exactly what you are doing, otherwise it quickly becomes chaotic.
It has multithread management, but I have no direct knowledge, except crashes in third-party programs.
qt significantly decreases the risk of crashes and it is easy to fix them, but it does not prevent the generation of anomalous/chaotic uses and behaviors, which are as always difficult to flush out.
@@guss77 Interesting. So you think I should keep trying to learn Qt?
@@cameronbosch1213 my recommendation about learning a programming language is that (a) you should pick up something that jives with your style, and (b) one is not enough - how will you know which is best for you if you only try one?
Rust has an advantage that it is rather small, so it's easy to cover most of what you need and still have the time to pick up a second language by the end of the week. Qt, OTOH is based on C++ - which is huge: it's one of the largest (if not the largest) languages ever, before they added more stuff. But you can do quite a lot of damage with just QML and a bit if rudementary C++ - or even Python - which BTW, Qt has good Python support, so if you are interested in GUi development, it's probably a good idea to know Qt, and you don't even need C++ for that.
I love that the app is structured in such a way that these rewrites are even possible. Yes GUI is important, but without the capability there would be no app. The fact that you can rewrite GUI and not touch the capabilities of the app (except for exposing the capabilities via the GUI) is awesome and would allow for another rewrite in the future if libcosmic and/or rust hype possibly dies.
I'm glad to be away from electron. That said I'm honestly not an electron hater. Like we've just kinda failed a making easy consistent UI app interfaces. The browser, unfortunately, presents pretty much the simplest solution to this problem. Although at great cost.
The mpv frontend Celluloid does the SSD on Libadwaita pretty well. It adds a regular menu bar if you turn off the CSD. Of course everything else still looks off.
Mirko has said on your podcast that he had to wrestle with the Gnome community everytime he strayed away from the Adwaita HIG so I can imagine why he doesn't like it.
You know libcosmic and QT both support CSD. TBH, I don't know any libcosmic application that doesn't have CSD, everyone wants their UI framework to work best on their own DE, not others...
But both also support SSD, which is really nice so apps don't look broken. (Like DaVinci Resolve.)
@@cameronbosch1213 You're talking about desktop support, not toolkit support.
Also, GTK has SSD support. It's GNOME/mutter that doesn't have it.
@@cameronbosch1213 Does it support HHD?
@@fotnite_ True, but GTK is bascially a GNOME project at this point.
@@Wkaelx Good one! 😂
I really like the approach of localsend (ie. flutter (with material theme) + golang)
This allows cross platform even android / ios as first class citizens which is nice.
Though I can be okay with rust as well , its just that rust is really hard & I admire simplicity
04:48 libadwaita hamburger menus have big black bezel when running on x11 without compositor
windows have different border without shadow and without rounded corners when no compositor but not menus!
Libadwaita apps are intentionally made to be good only on GNOME and nothing else.
The best decisions, RUST and libcosmic, I would love if everything went this route
There's all this complaining around the UI side of things, but at the very least the server-client model gives users and developers more of a possible choice to go for a different UI. The question then becomes how many people there are to actually _build_ alternate UIs.
Then again, I was never really aware of Bottles before this video and now I want to look into it. You're exposing more people to it once again; very nice.
As a frontend dev, building your GUI-heavy app on an alpha-quality library is absolutely crazy. They're going to have nothing but troubles. I personally chose Flutter for that, because it has years of battle testing and has had many many iterations after already being production-ready.
Dart isn't as good as Rust, but the framework is way more important than the language for GUI applications.
Since the move to GTK3 and now 4, GNOME has become the worst desktop environment I've ever had the displeasure to use. I'm glad more projects are deprecating it
man, the idea of bottles having 1 unified wine environment is really nice. just hope they get something figured out. i prefer using bottles over lutris because i just find it simpler to use.
Can we get a video on client-side decorations and server-side decorations? This topic has come up a few times, but I don't know if it has ever actually been discussed.
I have discussed it before but it might be worth coming back to
i love libadwita on my KDE desktop :D
I would like that most thing become a PWA with properly implemented features like cache and offline use and not that crappy electron tank
interesting update, thank you
I always do that on Lutris, running multiple programs in a single wine prefix, I sometimes do that so that I dont have to install dependencies multiple times and for programs that have dependencies to another program....
I love bottles! And the demos for Bottles Next looks great.
Ik many ppl love lutris or Heroic, but honestly bottles is so versitile and clean, but as a GNOME enjoyer, I 100% get, why ppl dislike GTK Apps on something like KDE. (The GTK dominance on the Flathub is one of the reasons I'm on GNOME, lol)
Ooh, I mistook it for Boxes...
I'd take libadwaita over electron any time. At least libadwaita looks and feels consistent (and good imho, although i use Plasma)
Agreed, I would still take libadwaita over electron. I fixed some of the issues he is having by patching gtk itself on my system. Nothing I can do to solve electron's problems.
@d-air1 Thats not what they're using now though, if you actually watched the video. They're using libcosmic, and the prototypes look GOOD.
@@cameronbosch1213 I don't know what you are talking about. I was simply stating my preference of libadwaita to electron. I didn't make any remarks on what the project is using to my knowledge.
I actually don't really care that a program is consistent with the system UI myself - as long as they aren't trying to imitate the system UI but not actually doing so properly, because that just leads to weird off-putting awkwardness where things don't quite match up.
That said, it does also somewhat depend on whether or not it's trying to sell itself as a part of the system, or a separate application you went out of your way to install - Bottles would fall in the latter category for me.
same, especially on my 10 yo laptop
i would have probably picked Tauri and saved the UI work on Vue.
OH MY GOD, not having a singular prefix was the only thing that turned me away from Bottles and forced me to write my own scripts per game, this is so good
I honestly hoped they'd give tauri a chance but I'll take libcosmic it's way better than electron
Ive stopped using bottles in favor of umu launcher packaged in a flatpak
Oh. Yeah. I love having 30 different versions of electron installed on my system because of app upgrades. Totally pro software management there !!!
rust is hip and cool
My sister (formerly brother) agrees!
I agree !! 🦀
@@RustIsWinning the user RustIsWinning agreeing with an opinion saying Rust is hip and cool? No way, so unexpected
I've heard Tomato is going to be even better. It does require to rewrite again unfortunately.
@@jackt-z2mWdym? Is she transgender?
Don't have time to watch yet so don't know if it's mentioned, but I'm really curious to know if they considered Tauri if they initially were thinking of Electron and if so why they decided against it.
Brodie is yapping about CSD and libadwaita again
Scrumptious
CSD as a sole system is dumb, and libadwaita is ultra basic. The hybrid CSD-SSD approach that KDE took is by far the best compromise. So yes, yapping against CSD and libadwaita is warranted.
How does Tauri compare to Electron in this context?
It's a drop-in replacement for Electron that's superior in every way. Tauri is a high level Rust framework enabling you to build desktop applications using your platform's native webview library. Since the application's interface is described via HTML/CSS and JS, you can either develop your application in JS with a JS web framework, or develop them in Rust (perhaps even with a Rust web framework). This renders your application with WKWebView on Mac and iOS, WebView2 on Windows, WebKitGTK on Linux, and the Android System WebView on Android. And therefore unlike Electron, you don't have to bundle your app inside of a custom web engine, so you don't have to compile your application inside of Electron's source code.
When did you update the outro to include "--no-preserve-root"? Anywho, I'm looking forward to Bottles Next, I don't really care how they get it done, but one shared prefix sounds amazing for when you need to use modding tools. It's been a bit bothersome getting Mod Organizer 2 to behave with certain Bethesda games as an example.
Has anyone tried to use bottles for office 2021/2024? Its the only thing holding us back to fully transition to linux on all PCs. And no, Liebreoffice/onlyoffice and so on are unfortunately No alternatives, already tried that.
Can we rewrite it in Mosaic??????? I think they should use CTK rather than GTK+
I think I'll stick with Crossover Office.
Yeah this is pretty understandable. I've been in this position last few weeks. fyne works pretty well but libcosmic is tempting me
Just use java for everything
@@Wkaelx Very long startup times with high memory usage and slow garbage collection. Fractional scaling and Wayland are not well supported. Oracle has abandoned Swing. Wakefield and Caciocavallo are a WIP and require rebuilding the entire JDK. Not worth it. Better to switch to Rust at this point.
I'm interested why he did not go with fyne since it was mentioned he was using golang.
I'm using fyne for hobby projects and it works really well
@@mmstick It's a meme bro, "Just use java for everything", I'm not serious here.
My only problem with electron is that youre basically shipping a full browser with your application, otherwise is very practical and fine.
If you dont care about performance and storage, electron is perfectly fine.
Im actually avoiding using online electron apps bc i realized that you can actually use the web version with all the features hahaha. Discord, Teams, Spotify... All work perfectly on the browser instead of the app.
To be honest, the only graphical toolkit which doesn’t suck is gtk3. It can be easily themed with css and there are lots of themes already.
Gtk4 is usually paired with libadwaita, which is impossible to theme.
QT has too many standards and it’s very hard to make it look consistent even if only using qt apps (unless using breeze).
Electron is notorious resource hog.
Libcosmic is not really themable atm from my understanding, but it looks promising.
Sounds amazing
6:56 Those are Go GUI libraries, but yeah, even though Go has those libs, they are just... fine. Not great, but fine. I get why the devs don't go with Go (no pun intended).
True, although go is good for cli gui, like lazygit, etc.
Yeah, Go really shines at TUI with programs like lazygit, FZF, LF, and many more which I use regularly.
Go is actually really great for most of programming (even system, with its CGO and assembly support). But for some reason, its GUI ecosystem never really took off...
@@zill_laiss yeah, no clue, fyne is the most mature one I think.
Change the UI framework? Fine I guess. The real problem is that they keep rearranging options and introducing weird UX choices for things that were never a problem to begin with, an example of this are the shortcuts you can add to your bottle's program list, for some reason it only allows you to launch a single instance of the same application from there unless you go to the kebab menu and explicitly choose the "launch with terminal" option.
The Bottles webpage still has Apex:Legends on it, the developers of that game has blacklisted Linux. I never used Bottles, I prefer go outside the repositories as little as possible and when I do I use the AUR or I compile from source. I don't have the need for Flatpak. Maybe OBS is packaged wrong for Arch (fair enough) but that which is missing is not something which I need for how I use OBS.
The second system syndrome is strong in these people.
Bottles is a godsend for me, i can do so many advanced things in Linux yet with any other tools i have only managed to get 1 game running, but with bottles? Pretty much anything will run.
As a Gnome user i like libadwaita, but i agree that clientside decorations as a default is stupid. As a web developer I have no issues with Electron. Cosmic looks promising.
Libcosmic might have been the right call. GTK is restrictive and I've seen enough devs say QT can be a nightmare to work with.
Either way I'm glad its not Electron.
Default QT is a nightmare, QML is less. QML feels somewhat as a merge of CSS and HTML into a JSON5-alike structure (Though I have no clue why they decided to stuff JS into there)
the one time i tried to use Qt getting the libraries and build toolchain set up was an absolute nightmare. at least with gtk and libadwaita you can just install the packages from your distro's repos and swap in whatever cxx toolchain you want and forget about it. distribution also seems like a nightmare, they really should just give up on their weird licensing setup and just go full FOSS
Fuck that. keep the prefixes separate, it's far less to fuck up.
Rust mentioned? mmstick summoned
Hi
ever since I figured out how to get games running through steam/proton, I haven't used bottles or lutris. maybe there's advantages, but it's been nice having everything in steam. And while there have been some issues, it's been relatively simple to figure most things out. Mostly protontricks/winetricks. If I config winetricks, then protontricks the same as I would winetricks, I think that's what works. I'd be interested if anyone could shed some light on why that might be though. It's been slightly annoying.
Nice. Maybe Bottles will be usable now. Every time I've tried it, I've always had more success just using Steam to install my non-Steam "game".
Lol this. Have had multiple audio plugins as non-steam games.
its kinda ridiculous how effective Rust is at rekindling joy and fun in developers, despite it being a lanuage everyone admits has quirks, a tough learning curve, and long compile times. call it a cult, whatever, i call it joy. i like joy, and i'm not an un-cynical person.
It had a tough learning curve in 2015, but with the 2024 edition that's no longer an issue. The borrow checker is nowhere near as strict as it used to be, and error messages over the last few months have gotten significantly better. Despite error messages already being really good by the 2021 edition.
Surprised that they aren't going with Flutter/Dart. Am very much biased, but feel that it is the most flexible, mature and performant, far more so than even libcosmic at this stage and, thanks to work by Canonical, has a mature GTKesque UI library in the form of yaru.dart.
Isn't Flutter dead? I thought Google gave up not that long ago.
@@dashcharger24 No, it isn't. It's used by the Google Adsense team for their dev work. Adsense are the only team at Alphabet that reliably brings in billions, so Flutter has a solid future.
@@dashcharger24 Flutter has just been updated (11.12.2024) with some major improvements and is used for development by the AdSense team, who are essentially the biggest source of profits for Google/Alphabet. Unless they want to cause their moneymaker to completely rebuild internal processes and pipelines, Flutter will be maintained.
@@dashcharger24nope, by far the best cross platform toolkit. I would love to use stuff like tauri, but flutter's ecosystem and solid design is hard to beat.
@@askeladden450yes. Also, dart is easier than rust. So there's that
Another GUI app written in rust! Rust vanilla desktop OS when?
Nooo Brodie, get out of the jar!
Honestly, while I dislike libadwaita apps for looking out of place, I am kinda used to thing being inconsistent from the Windows land. Electron apps in the meantime make me question what even is the RAM being used for. Even with 32GB in my setup, I don't want a UI toolkit this wasteful on my system since some games benefit from plenty of memory, that's especially the case for modpacks that spike in memory use.
Rustify the world!
WHELP, ANOTHER COSMIC W.
Going to be a bit of a culture shock moving from Go to Rust. All the influencers and sites make it out to be the holy grail but the two languages couldn’t be more different in syntax and the ethos. Lost count how many times I started writing something in it and initially liking it but gave up and went back to what I know because I needed to get the job done. Unlike other languages where you can learn it by building a practical project, you need to know the theory first.
It is true that Rust demands more thought in design before implementation.
Bottles never works for me but lutris always.
I have never understood why having Qt, people opt to GTK. I have developed in both with C++ and Python. To this day, I still find no reason not to go Qt by default.
Frankly, i still don't understand why bottles needs a new ui.
Yes, a more controller featured mode would have been great, but the current gtk ui is just incredibly smooth, as compared to basically any other technical app in the linux ecosystem.
I also doubt they'll manage to match gtk/adwaita's QOL on touch screens.
They need to start from scratch to change to the client-server framework in order to support the single prefix utility inside the prefix. It will therefore need a new UI.
GTK and libadwaita aren't doing anything special with touch that other Wayland GUI toolkits can't also do. Libcosmic already supports touch.
The fact that it looks like ass on anything that isn't GNOME would be reason enough on its own. In fact "I can't look good outside of GNOME" is a perfectly valid reason for anything that isn't part of the GNOME project to abandon the GTK+libadwaita stack.
have you used bottles? even without gtk/libadwaita the ui is a complete organizational nightmare. if the rewrite gives them a chance to just start from scratch and fix it i'm more than happy
Of course Ive heard of FLTK
They should make it with Dear IMGUI
As someone who only recently started using Bottles because of a certain mobile game, the one thing that I don't like about it is the UI. To be fair, all of these Linux games launchers have bad UIs. I probably would still hate Steam's UI if I hadn't been using it for years, but Bottles in particular has a little too many layers of nested menus. To even launch the one game I use it for, I have to go into a sub-page for that application because god forbid my "run launcher" option can't intuitively be set to the default behavior.
library exists??
But yeah, running it the defalt way is kinda annoying, you need to open bottles, select the app, select the prefix... I think if you really want to, you can DIY a .desktop with a launch command, but I'd like to see that automated
@@qlx-i Thanks for talking about the Library. I think I'd seen it up there but it never had anything in it so I ignored it. I am literally the "oh you can jump?" guy who has been trying to beat mario for an hour right now
Bottles works so poorly right now, but sadly it's still the best way to manage prefixes. I hope Bottles Next will be better im every way
The more it evolved the more crab it becomes
Although I think rust is very efficient in some other contexts, I don't think frontend development is one of them. I think eventually the stiffness of the borrow checker/lifetimes are going to get you and slow down development, also the compilation time and the JS inspired culture of 1000 deps for a hello world are going to be a hurdle as well.
But, given the lack of options for GUI libs in Linux, I do understand this back and forth, however IMO I think developing a good golang lib for this would be the best choice, even so given bottles devs are comfortable with Go.
The Elm approach to GUI development (MVU) is a perfect match for Rust's borrow checker and pattern matching features. There are never any borrow conflicts because the app model is only mutated in the update method, and the view method does not require mutability. There's never an overlap in mutable borrows, and no need for interior mutability either. Views are even able to borrow values directly from the app model because the lifetime of the view is tied to the app model upon being borrowed the view method.
A lot of web developers also prefer this approach to GUI development because of how it simplifies the logic in the app, and enables applications to be reloaded without losing state. Since views are generated directly from the model, the model always reflects the state of the UI. An app developer could, for example, save the app model to disk on exit and then reload it on startup as if it were never closed.
The borrow and lifetime checker is also a compile-time checker. It does not happen at runtime, and therefore does not impact performance. Performance is actually improved by it because it allows the compiler to assign noalias tags to most things. This allows the compiler to more aggressively and reliably apply optimizations like autovectorization.
honestly comparably GTK libadwaita looks better on KDE then QT looks on gnome
This should improve once KDE applications adopt Union as their theme engine.
@mmstick interesting although my solution for that is that themes should be app based not system based
4:42 I can say the same about qt or other similar interfaces, on my desktop they look like I'm running something from the Windows 3.11 era, as if 30 years of ui and ux development were just thrown out the window
i kinda like client-side decorations, provided they are good and optional. for example, firefox has great client-side decorations. they look good, save space and are completely optional, not removing any functionality when disabled. that's good client-side decorations.
gtk and libadwaita still suck though. to the point that i'm genuinely wondering if the Gnome devs are really just incompetent or outright malicious, trying to ruin the Linux desktop or at least the competition.
If cross platfom and fast iteration is a concern, flutter is way more mature and viable then libcosmic, at least for now.
Considering the fact that bottles exists to run *Windows* software on *Linux*, I don't think cross platform is a concern...
Plus flutter focusses on mobile, desktop is a 2nd class citizen
So when is it coming? Been talking about it for a long time now
My issue with libcosmic is that it essentially looks the same as libadwaita right now on non-Gnome desktops. Cosmic is great, but the style of the libcosmic toolkit just isn't it.
Adapting to GTK color schemes in GNOME isn't implement yet. For KDE, that will likely require waiting for Union to be implemented and adopted.
@@mmstick It's less the color scheme I'm talking about and more the style of the windows/decorations. libcosmic applications have the same CSD headerbar style that libadwaita apps have on Plasma.
I understand *why* it's like that (since you'll be migrating users away from Gnome and don't want to shock them) but it still makes the applications look non-native on literally every other DE out there. And since I want and expect Cosmic to blow up, it means that it will only cement the giant headerbar CSD look as "the Linux Native look" going into the future.
@@Daktyl198 Windows and Mac OS X are also using CSDs today, so I'm not sure why that would be considered native to Linux specifically. It definitely doesn't use the same headerbar style as libadwaita though. There's a completely different design guideline for that, in addition to differences in the theme engine. Regardless, nothing stops KDE from applying a custom theme to COSMIC apps to make them integrate more cohesively there. Same for GNOME. Just as COSMIC supports integrating COSMIC theming with GTK applications, and later KDE once they adapt to using Union.
@@mmstick Windows and mac are CSD, and there's nothing wrong with CSD on the backend. It's the visual style of GTK and libcosmic that I'm talking about. You can't sit there and say that GTK and libcosmic don't have "the same headerbar style" when they definitely do. Icon font and specific colorings/spacings aside, GTK and libcosmic are the only toolkits that default to 40+ pixel tall window decorations with large buttons placed inside of them.
Themeing has nothing to do with what I'm talking about. My point is that Gnome is the only non-alpha compositor to default to those style headerbars. KDE, XFCE, LXQt, Cinnamon, MATE, Sway, Hyprland, etc etc ALL default to a default old-school Windows or mac style window decorations (if any decorations at all) with optional CSD. This means that those style headerbars are foreign in the "Linux ecosystem", even if Gnome has a large marketshare.
Given that I want and expect Cosmic to quickly blow up in marketshare, it's only going to cement what is currently foreign design language as "The Linux design language" since two out of the 3 largest DEs will be using that language, but it effectively means non-native looking apps for 90% of the compositor ecosystem unless they change their ways.
Fwiw, I personally like the look of libadwaita even though I don't use Gnome, but it's always jarring when opening one of their apps and it looks and works so different than 95% of my other applications, even those that use CSD. libcosmic design language doesn't quite appeal to me yet, but I'm giving it time as I'm excited about Cosmic itself.
@@Daktyl198 You should actually verify statements like that. The headerbar in libcosmic has configurable density, does not use hamburger menus, and prefers menu bars.
LFG!!! COSMIC!!!!!
I like Electron If there is no other way developers bring software to Linux and maybe macOS otherwise.
If a program doesn't rely on web connectivity, I could live without it but the more options there are, the better I guess.
2025 is the year of rust, and linux too ofc
Seems odd. I don't get the problem with all the other UI frameworks and libraries. And if all of those are problems why go to rust, a language not really supportive of gui's, and even then why use something still labeled as a WIP that is designed only for COSMIC? And if they are doing it in libcosmic and gtk that just seems like extra work.
How exactly is Rust "not supportive" of GUIs?
@@mgord9518 First, time. There are languages with much longer running, feature rich libraries and frameworks to use. Second, purpose. I can't imagine rust lending itself well to the frontend. You can make a game in python? Sure. But it is not Python's strong point.
@@gsgregory2022 The state of GUIs in the Rust ecosystem is more varied and active than any other. Many of these GUI projects have been developing libraries which enable cross-project collaboration. Linebender's tiny_skia, Bevy's work on wgpu, and libcosmic's cosmic-text are used in most GUI libraries now.
The existing state of GUIs on Linux is so bad that even a WIP Rust toolkit can quickly elapse GTK with a little bit of effort. Rust lends itself very well to the Elm approach to GUI development.
@@gsgregory2022 some rust web ui frameworks use the macro system to let you write html *in your rust code* without a preprocessor like react needs. i'd say that allows for quite a bit more user friendly experience than anything written in C/C++ like gtk. nothing in the language itself prevents writing good UIs, and even if you don't do crazy metaprogramming things, people have been writing UIs in C for years just fine and it's not any easier or harder than rust
@@SmplySilver We're doing our best to avoid macros in libcosmic. Similar to iced, all APIs are exposed as functions which can be chained together. The Apply trait is also useful for keeping that chain going when you need to apply a function-or wrap the return value-before returning it. This gives us a really nice functional GUI API.
Electron is my last choice when being forced to use software. Just saying. Bottles developer is awesome and has very high attention to detail and UX. I respect his choices and I doubt that he would have picked Electron unless no other choice existed.
You know what's sad? I was more triggered by the Vue.js thing that by Electron.
1:31 oh I sort of do a hybrid of the two systems. I have one bottle that runs pretty much everything and then if a bottle requires much customisation it gets its own separate one.
Layering would be much more clever, save on storage requirements
As an user of MO2, it seems to me what we do with Skyrim modding.
Don't get locked out of your account. :^)
Brodie you should start screaming very loud every time you want to do another take, this way you'll never miss it and keep both takes in the video
Bottles team going for New Game+
Should have chosen Swift 7 and Iced version 1.3. Linux gets no GUI love.