Step it up: Compose for Desktop
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 637 | |
| Autor | ||
| Mitwirkende | ||
| Lizenz | CC-Namensnennung 2.0 Belgien: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/53581 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache | ||
| Produktionsjahr | 2021 |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
00:00
AeroelastizitätFramework <Informatik>Deklarative ProgrammierspracheFormale SpracheBitGebäude <Mathematik>FunktionalFramework <Informatik>DifferentePunktBeobachtungsstudieSoftwareentwicklerMAPFormale SpracheZirkel <Instrument>Domain <Netzwerk>TermDeklarative ProgrammierspracheAeroelastizitätÄhnlichkeitsgeometrieGoogolJensen-MaßRechter WinkelStabilitätstheorie <Logik>VersionsverwaltungComputeranimation
02:01
BenutzerschnittstellenverwaltungssystemProjektive EbeneKonfiguration <Informatik>MereologieHumanoider RoboterEmulator
02:39
FaserbündelVererbungshierarchieInhalt <Mathematik>Inhalt <Mathematik>FunktionalWidgetDeklarative ProgrammierspracheParametersystemKartesische KoordinatenExistenzsatzCodeTouchscreenNummernsystemPlug inElektronische PublikationGraphfärbungDefaultFramework <Informatik>PunktSchreiben <Datenverarbeitung>Quick-SortCompilerMereologieSpeicherabzugGebäude <Mathematik>RahmenproblemZweiAdditionZirkel <Instrument>MultiplikationsoperatorGewicht <Ausgleichsrechnung>GoogolUmwandlungsenthalpieMetropolitan area networkBenutzerschnittstellenverwaltungssystemEnergiedichteTransformation <Mathematik>Kontextbezogenes System
05:38
Quick-SortFigurierte ZahlPlug inCompilerDifferenteSampler <Musikinstrument>Transformation <Mathematik>WidgetRechenbuchCodeSichtenkonzeptMathematikUmwandlungsenthalpieHumanoider RoboterPhysikalisches SystemHierarchische StrukturDigitale VideotechnikMereologiePhasenumwandlungGarbentheorieFramework <Informatik>CASE <Informatik>Schreiben <Datenverarbeitung>Ordnung <Mathematik>WasserdampftafelDatenverwaltungAggregatzustandBitrateMechatronikWhiteboardGewicht <Ausgleichsrechnung>Computeranimation
07:35
AggregatzustandFramework <Informatik>Humanoider RoboterDigitale VideotechnikMathematikDatenverwaltungAutomatische IndexierungWellenpaketSoftwareplattformProjektive EbeneCoxeter-GruppeComputeranimation
08:05
Humanoider RoboterCoxeter-GruppeSoftwareentwicklerMereologieAutomatische HandlungsplanungHumanoider RoboterEindringerkennungPunktFokalpunktWeb-DesignerProdukt <Mathematik>Ordnung <Mathematik>Gebäude <Mathematik>Rechter WinkelXMLComputeranimationUML
09:32
Projektive EbeneSchaltnetzCASE <Informatik>Konfiguration <Informatik>Spezielle unitäre GruppeStabilitätstheorie <Logik>Rechter WinkelPunktGarbentheoriePlug inProgramm/QuellcodeJSONXML
10:16
Humanoider RoboterLaufzeitfehlerComputervirusBildschirmfensterGebäude <Mathematik>Klasse <Mathematik>DateiformatBinärdatenRadikal <Mathematik>Kartesische KoordinatenSichtenkonzeptCASE <Informatik>TouchscreenArithmetisches MittelMereologieProjektive EbeneWhiteboardOrdnung <Mathematik>Klasse <Mathematik>BildschirmfensterInhalt <Mathematik>FunktionalProdukt <Mathematik>DatensichtgerätQuaderSoftwareplattformQuellcodeVererbungshierarchieElektronisches ForumWort <Informatik>HypermediaGesetz <Physik>Gewicht <Ausgleichsrechnung>DifferenteGarbentheorieStreaming <Kommunikationstechnik>Bildgebendes VerfahrenKonfiguration <Informatik>Mailing-ListeGruppenoperationProzess <Informatik>DistributionenraumTaskGebäude <Mathematik>Humanoider RoboterElektronische PublikationCodeVersionsverwaltungRechter WinkelDateiformatBinärcodeTypentheorieAppletMultiplikationsoperatorSystemplattformProgrammierumgebungPartitionsfunktionJSONUML
15:32
Framework <Informatik>ProgrammbibliothekOffene MengeAppletGoogolSoftwaretestSystemplattformPhysikalische TheorieHumanoider RoboterCoxeter-GruppeTemplateSoftwaretestHumanoider RoboterMathematikQuick-SortPunktSoftwareplattformSchnelltasteMultiplikationsoperatorFlächeninhaltRechter WinkelAppletVererbungshierarchieProgrammbibliothekOpen SourceGebäude <Mathematik>PortabilitätDifferenteFlächentheorieStreaming <Kommunikationstechnik>Framework <Informatik>Formale SpracheCodeFunktionalLeistungsbewertungDokumentenserverEvoluteMobiles EndgerätImplementierungSystemplattformKartesische KoordinatenMathematische LogikGoogolSynchronisierungGradientTreiber <Programm>SystemaufrufZentrische StreckungDoS-Attacket-TestBildschirmmaskeProzess <Informatik>Wort <Informatik>Mini-DiscSchreiben <Datenverarbeitung>ZeichenketteMereologieOrdnung <Mathematik>Demoszene <Programmierung>SpeicherabzugZahlenbereichDickeFormation <Mathematik>WechselsprungHypermediaVersionsverwaltungRandverteilungRechenbuchComputeranimation
21:19
Element <Gruppentheorie>Kartesische KoordinatenTemplateMathematische LogikÄhnlichkeitsgeometrieQuaderMultiplikationsoperatorTabelleOrtsoperatorProjektive EbeneSchnelltasteDatenmissbrauchTermMAPMaßerweiterungSchreiben <Datenverarbeitung>MereologieStichprobenumfangComputerspielOpen SourceGeradeDifferenteProzess <Informatik>ServerVersionsverwaltungElektronische PublikationForcingCompilerZeichenketteARM <Computerarchitektur>Rechter WinkelFramework <Informatik>Quick-SortSoftwareentwicklerMailing-ListeWechselsprungGüte der AnpassungAppletCodePlug inTopologieDateiverwaltungBenutzerbeteiligungTwitter <Softwareplattform>ExistenzsatzHumanoider RoboterSoftwarewartungStandardabweichungRechenschieberStabilitätstheorie <Logik>ComputeranimationBesprechung/Interview
28:39
Element <Gruppentheorie>Besprechung/InterviewComputeranimation
Transkript: Englisch(automatisch erzeugt)
00:12
Hello everyone, thank you all for coming to this talk. My name is Nishant Srivastava and I'm an Android engineer working here in Berlin. Today, I'll be talking about Compose for desktop.
00:23
But even before we start jumping into Compose for desktop, maybe the question is where did it all start from? What's the actual origin of this? Well as most of you who are probably working in the mobile domain would know about there's a new technology that Google came up with and this one is called Jetpack Compose.
00:44
Basically, Google wanted to do something different with the UI framework. So they started exploring something else that they could have worked out. So what is Jetpack Compose? Well, Jetpack Compose is a modern toolkit that is heavily inspired by what React.js
01:01
was doing or React as a framework was doing and then you have also seen something similar in Flutter framework if you have had a look at that. It's mostly a declarative and reactive UI framework. It's used to simplify the UI development and best of all is basically using Kotlin language. It's completely built around that. So you have
01:22
almost all the functionalities that you would get from Kotlin language. Declarative and providing more functionality in terms of how you write this UI in a simpler and much more concise manner is all possible because you are using Kotlin language. The important point though is that it's currently in alpha stage. So as in it's I think it's in alpha 10 right now.
01:46
It's not reached the complete stability. But we would probably see it sooner. I would say maybe by this year-end or something. You might see some beta version of it come out. So
02:01
how do you even start working with Jetpack Compose? So if you are using Android Studio, what you do is that you basically just go ahead and start a new project in that in Android Studio also something that I almost forgot to mention is that you need to use the Canary build which is the the bleeding edge of Android Studio. Once you have that and you start a new project you have the option of
02:24
choosing empty Compose activity. What this will do is that it will kind of set up all your dependencies and everything that you need and it will set up a bare-bone Android project which you could compile to an emulator.
02:40
So what is the core part of this Jetpack Compose? Well Jetpack Compose in general is going to allow you to have access to some declarative UI widgets that you could basically just mention and you don't have to write XML code or anything. What this means is that you kind of create composable functions.
03:00
The way you write it down is that you create a standard function as you would do in Kotlin and then you annotate it with a composable annotation. Inside it you use specific declarations that you would use to define a certain widget. So for example earlier in XML you would be doing something called TextView
03:21
but now you just do text and then you pass in a text value to it. So it's a bit different from what you would do but all of your code is now in Kotlin. You're writing a UI code also in Kotlin. If you had to use this you would in your main activity go ahead and set the content to this composable function and what this will do is that you're basically saying instead of
03:43
setting the content of an XML file now you're saying my composable function is what will draw the UI for me. Okay, and that's where the content exists. So when you run this application you would see a blank white screen which has hello world text written on the top left corner. So
04:05
that you can do. That's one way of doing it. But there's also a different functionality that Jetpack Compose comes up with and this one is called the preview functionality. Basically what it allows you to do is that you can in your Android studio, in your ID itself, you can see the preview of the widget that you have defined, the composable function that you have defined.
04:25
Without even compiling or building anything. It does the rendering for you inside the ID. So the way that you do it is that again you create another function. This is separate from what your actual composable function was. And you create this one called some sort of a preview function, right?
04:41
So we can define it as fun default preview and then we say that there's an application theme to it. So that we have something like a setup color scheme for it. And then you pass the actual composable function to it. Notice there is an extra annotation on top of this. And this one is called add the rate preview.
05:00
And basically saying that you can pass some more arguments to it by saying show background true, false, or some other arguments that you would want to pass. But basically it's defining how your preview is going to look like. But that's Jetpack Compose. The important point till now is that everything that we have been discussing is something that Google has been building for some time.
05:21
But what needs to be made clear is that Jetpack Compose is not completely a UI framework. Somehow the naming is so hard and things are like so difficult to name nowadays that you end up like this. But basically Jetpack Compose is a Compose compiler plugin. And then there is a Compose
05:43
UI framework on top of it. So in general there's like a common framework that we can think of. Which is kind of doing all these transformations. So what does this Compose compiler plugin is doing? Well Compose compiler plugin in general is trying to do incremental changes to your view hierarchy.
06:04
Once your view is drawn it's gonna make some sort of like calculations and it will try to figure out when a certain state changes and what one particular part is gonna change. It's gonna do incremental changes to your UI versus what was earlier is that if you made a change in your UI in say an XML based system
06:25
you will have to reload the whole or redraw the whole UI again. But that's not what's happening here. Compose is kind of doing some sort of like diffing. It's trying to calculate the change and only making that small change update. But that's the compiler's work. It's kind of like gonna figure things out and it's gonna write specific code for you.
06:43
On top of which there's a Jetpack Compose which in my case I would say that it's very specific to Android and this is what ID is what Jetpack Compose is. It's split into two different parts. There is a Compose compiler plugin and then there's a Jetpack Compose for Android.
07:02
Now here comes the different section here. So the section here is that because the Compose compiler plugin is doing most of the work wherein the UI widgets are sitting on the Jetpack Compose side what it means is that right now it's targeting Android, right? You can draw some UI on the Android system, but
07:21
there's definitely a possible that you could use this compiler plugin to build something else for a different target. In this case, you could actually have gone to build for Compose for desktop, which is totally possible. So this is how it looks like. There's a Compose compiler plugin which is common between Android and Compose for desktop as what we are going to call
07:43
and what it's going to do is it's going to do most of the calculation, the algorithmic, the diffing and all that change detection, state management and everything. It's going to do inside itself, but how this gets targeted on a certain platform, for example Android and desktop is going to be decided by this specific framework.
08:04
That brings us to Compose for desktop, which is the main topic of this presentation. So Compose for desktop is everything that you actually saw that I mentioned for Jetpack Compose for Android has, but it's also a simplified desktop UI development. So it's kind of trying to take what people learned by building it for Android. They're trying to bring this down to
08:26
desktop UI development. For now, it only targets JVM. The lead developer for this, I think I read somewhere mentioned that this is the reason it's doing that right now is because it's part of the plan of how the roadmap would go for JetBrains, who is basically
08:46
building all of this Compose for desktop. And they wanted to do this specifically because all their products are based on JVM. Their IDs are based on JVM, but that's not a limitation. The point is that the focus right now is JVM for now.
09:00
The first public milestone was released in November 2020. And this also is in currently in alpha. A point to note though, is that it is also called Jetpack Compose for desktop. As I said, naming is hard. So it's going to be called like if you read through the internet, people would call it Jetpack Compose for desktop, Compose for desktop. In this presentation,
09:24
we are going to try to separate the two. Jetpack Compose for Android and call the other one as Compose for desktop. So if you had to actually work with this and you wanted to build a project that could leverage the Compose for desktop, it's quite easy. You just download the latest stable
09:43
IDEA plugin. And in that, specifically when you start a new project, you have Kotlin section on the left side. And in that you have a Jetpack Compose for desktop, which is experimental right now. And you basically just go through the wizard and compile it.
10:02
Important point to note though, is that you need to have JDK 11 to build this project. So you need to have the project JDK set to some sort of like in my case, it is set up to adopt open JDK 11. You could use some other open JDK 2. Now the function in general looks the same, exactly how we did it in the last time. For Jetpack for Android,
10:23
you will see that it says function hello world text and then has an composable annotation on top of it. But did you notice something here? So there in the imports, there's something called AndroidX.compose.material.txt, AndroidX.compose.renttime.composable.
10:43
Again, naming is hard. The reason it is called AndroidX, even though we are building for desktop, is that this actually originated while building for Android. So Jetpack Compose for Android came first and then the target was expanded to say that this Compose functionality should also allow us to build UI for desktop.
11:04
So this is why AndroidX is kind of like being split into the common code away by now. That's why they are able to build it for Compose for desktop as well as for Android. But the naming is still there. So I don't know if it is on the roadmap that it could be changed in the future,
11:22
but for now, this is not problematic. Basically, it is not going to affect anything. It's just a package naming in which it just says AndroidX, but you are building for desktop. We will see that. So you do that and then to run this whole code, this composable function that you just built, you just create a basic main function
11:41
and then you define a window because it's not Android anymore. You don't set content anymore. You just define a window and then you push the content on it, which is your hello world composable function. Now in this particular case also when you are defining windows, you will see there's another AndroidX as the package name in the import. But it's very simple. You build and run and then this is what you get the preview as.
12:04
You get a standard window and then the hello world text written there. One thing to note here is that there is no preview setup that I could find out when you are building for Compose for desktop. In Android, you definitely had that annotation for preview, but there's nothing set up in at least for IDE.
12:26
So you end up in this situation. You basically have to build the project every single time. So what this means is that you can write any composable function. You can create a list, you can add images, you can do media. There's a lot of different functionalities out there and it's kind of like
12:43
fully functional that you could actually take the code that you built for Android and then you just have to port it over here. All the composable functions here, but instead of setting the content, you pass it inside a window. Then your UI application would still compile and it will display on a
13:03
specific based on whatever platform you're using. So Linux, Mac, Windows, it would basically show it inside a window and things would work out of the box. When you actually create this new project inside the build.gradle.kts file, there's something very specific that I want to show you here.
13:21
And that is that there's a bunch of code there, but the important part is what I've highlighted here. So you have something under the application where you define the main class, which is a main.kt file. Basically, it's called main.kt file and then the Java class version is main.kt class file. So in that you have something called native distribution. Now, this is where you actually define what are the target
13:45
distributions that you can create out of this. So you write this code in Kotlin. Everything is there. You have composable functions. But where do you want this to run? You want this to run on say Mac OS, then you target format.dmg. If you want this to run on Windows, you target from format to MSI.
14:04
You want to run this on Linux, you just start from format.dmg. Okay, and then obviously it needs to know the partition. So the section that I'm actually highlighting, if you actually try to look into the source code for target format class itself, it shows what are the different platforms it can actually
14:23
target and in what format it can create the binaries for. So you can see for Linux, it can create DAB. The DEB format, the Debian format, the RPM formatters, it can do DMG and package format. For Windows, it can also do EXE and MSI both.
14:42
And if you actually wanted to generate them, the way that you do it is that you just go to terminal and you say ./gradle new and then package task. The binaries are generated at your project name slash build slash compose slash binary slash main and then the package type. So in this case, it could be say a DEB.
15:01
In Mac version, it would say DMG. But if you're not used to jumping on terminal as much, there's also option inside the IDE that if you go into the Gradle panel under the compose desktop group, you can find the package, package DEB, package DMG, package MSI. Now these are defined based on what target format you already set up.
15:22
What this basically means is that once you have the application ready, you can kind of display or you can generate the binaries right away in whatever version you want. But the question is why do we actually want to do all of this? Why certainly compose for desktop? Well, the point is that traditionally a desktop UI frameworks at least on Java
15:44
or the JVM were being built with Swing and AWT and they are all callback driven. It's not so good. You'd like go through everything and then you kind of like have to generate a callback and then make an update to the whole UI, maybe redraw everything. And compose for desktop is kind of like
16:02
a step forward. It's trying to do things in a much clean manner. It's kind of it allows you to do some sort of like asynchronous and incremental changes to your UI versus of like redrawing everything or like maybe doing excessive complex calculations, which you don't need to. The other problems are that we have already been handling and working with Electron, Qt,
16:26
GTK, and there are many so many frameworks, right? And then for each of these you have to learn a different language. But at the end if you are proficient in building say Android applications UI and you use Kotlin and
16:41
then there's the possibility of building the same UI in your desktop, you would definitely want to use that, right? So that's that's why this thing has been explored. Most of the functionality actually lives inside the common code base and Kotlin now that it has the Kotlin multi-platform
17:00
implementation in place and then there's like this a lot of functionality is now being put into in a way that it can be targeted in different platforms. Compose for desktop was a was a natural evaluation to happen, evolution to happen. So what's the magic? Well, the magic is mostly Skia. So Skia is like a 2D rendering library. It's super old like as in it's been couple of years
17:25
it's been around. It's been used in Mozilla, Chrome, Flutter, that's how I think most people know about this and then in a lot of different places that you can see it. So Skia is like kind of the de facto 2D rendering library. It's open source in the BSD
17:40
so anyone can use it. It's mostly maintained by Google and the way Compose for desktop is actually using this is that it's using Skija or you can say S-K-I-J-A where it stands for the Java bindings for Skia, which is maintained by JetBrain by the way, to go and triggers those
18:03
changes in the Skia library when they are trying to show it or draw something on the desktop UI for this. So we mentioned that that Compose for desktop basically works only on JVM right now. Now the reason that is because this Java bindings for Skia are maintained by JetBrains and
18:24
to build it for some other native versions, say imagine you wanted to build it for Mac OS or say some other version, in that sense you need to have some sort of bindings to Skia to draw on that particular native platform. So if there is some sort of a binding for that, there's definitely a possibility of generating the same UI
18:46
onto a native platform, which is not JVM. JVM right now is kind of allowing us to have this portability wherever JVM is, you can run this code and you have the Java bindings for Skia.
19:00
But other than that, if you wanted to target a native platform, you could just use a binding for Skia and you could just go ahead and use Compose for that. So what's next? Well, the first thing that needs to be happening right now is that the Jetpack Compose for Android needs to hit stream. That's the idea. And once that happens, I think Compose for desktop would have more
19:21
surface area to cover and become stable much faster. Right now, most of the engineering is going into the Jetpack Compose for Android and also stabilizing the API. And once that has happened, I think it will carry forward onto Compose for desktop. There is some sort of JUnit testing that you could use for testing your business logic.
19:43
But the idea is that there would be some more testing set up, something like screenshot testing or mocking of your UI. But that's something that has yet to be explored. It is not platform dependent, but rather more of a possibility if this will ever exist in the future or not.
20:01
In theory, this should also work on the GraalVM, which has some extra, I would say the startup times reduces when you're trying to load up your applications. So GraalVM is also something that can be looked into when you're trying to Compose for desktop.
20:22
And also, as I mentioned, you can target native platforms and once you have more bindings available for Skia. What you should do right now, or maybe whenever you get the time for this, is that you need to go to Jetpack the Compose JB repository on GitHub and try out the examples. I did not cover
20:41
big examples in this session itself because I thought that this is a huge topic, building UI in general. But rather the introduction to how Jetpack Compose is kind of doing things internally and working with different things would make more sense. But there are definitely good examples that you should go out and try and look at the code base how things are working.
21:02
And these are some links, maybe you shouldn't use them. And I believe that is all. Thank you. If you have any questions, please go ahead.
21:44
And we are live. Thank you very much for the talk, Nishant. It was a pleasure. And thank you for being with us today for the live Q&A. Thank you for having me. This was super nice. So we have some most upvoted questions.
22:02
If anyone has more questions, feel free to drop them in the Kotlin Dev Room channel, or you can jump over in the private room afterwards. But let's kick on with the first. It's from Russell Wolf and he asks, do you know any good samples for working with a Compose compiler plugin without a UI?
22:21
Yeah, well, typically there aren't any public examples right now. But there are people, those who have been working, for example, I think Jake Wharton kind of tweeted about this some time back where he said he is going to make some some of these projects public. I haven't made any of those myself. But if you understand the whole logic of what I was talking about in the in
22:43
the presentation, the compiler plugin is basically something that's just doing kind of like tree shaking. It's basically taking all your nodes and then allowing you to do incremental updates. So if you have this kind of an example or something where you would want to do something similar, that's where you would just want to plug this in.
23:02
The rest part, the UI part, the one where your Skia engine comes in is the part that is drawing things for you. That's why if you just skip that part, you basically have a functional project for that. So in my, I think in my experience, something similar would be where you probably just want to maybe like if you
23:22
are if you have a like a list of items that you basically are trying to update at a certain point, but you just want to update only subset of that you could use compiler plugin from from Jetpack Compose, the Compose compiler plugin. Awesome. Then we have another question that's from me.
23:40
And I wanted to ask you if you actually tried Compose desktop with a pet project, what it is about, if it's even open source, like what was like a nice example of usage? So I have an open source web application, which I kind of promote all the time and is also open source. This one is called App Privacy Policy Generator.
24:03
Basically, that pet project is being used by people all over the world. And it's a web based application. So it uses Vue.js and it uses standard HTML JavaScript just to create a template of your privacy policy. So what I wanted to do was I wanted to bring this project down to the desktop version. So I started designing this whole thing in my, say, Jetpack Compose version and then putting the whole thing into a Compose desktop version.
24:28
So it kind of works. It is there, almost there. It's not open source yet, but that's part of the roadmap. Hopefully what you will see is that this pet project that right now lives in the web app, there would be people who would be able to download this on your local.
24:43
And then you just don't need to be online to generate your templates. Also, another thing that allows me to do this when it goes into a desktop version is that I could do a more logic, which I could not do in the web version as much because you have access to your file system. You have a lot of different things that you could work with.
25:00
So what this will allow us and in general, that project to do is that it will start using more templates and you could just feed in and generate your version of privacy policy. So a lot of extensibility is possible once you start going using Compose desktop. Awesome. Then I have, what's another question?
25:23
It's related to your past experience. So have you experienced desktop development with other frameworks in the past? And how it compares in terms of developer API? So was it like, easy to use? Was there like something missing? Like what was the experience overall? So one thing that I can say, so I've mostly been doing Android development.
25:43
So there's like obviously a big jump from going from XML layouts now to a more fluent API that you can build with the Kotlin. So this is something that's a good thing, but I've also developed application using Swig, which is the Java framework, allowing you to do UI stuff.
26:02
And that was pretty hard to work with. There's always so many gotchas that you had to work with. And it's also not like super, I would say developer friendly, which as you start moving into something that's more fluent and it's more like Kotlinized version, I would say, because we use Kotlin so much. Compose desktop kind of just brings us in a different land.
26:24
We started, at least when I started designing my pet project, I was like, I just don't have to remember everything because everything is, first of all, the ID supporting all of the stuff. And when I'm writing this, it's actually readable. That's the best part. The whole code that you're writing for your UI is something that you can read through and you understand exactly how it's going to represent itself.
26:46
So I think it's going in a good direction, but we should all keep in mind that right now, Compose for desktop is in its milestone stage. It's not like completely in the stable. Hopefully it becomes stable. So there are some small quirks here and there.
27:03
Actually, people start talking about this build is more in the side of like, say, Friday tested frameworks like Swig and JWT and other, not JWT I'm saying. But basically, yeah, all of these state-based frameworks are more stable, but eventually when it goes stable, I think more people would start using Compose for desktop.
27:23
Awesome. Yeah, we still have a couple of minutes. So if there are other question, yeah, there is one. So the question is, are there any native bindings or was that just hypothetical? Oh, so yes.
27:41
So I think I did mention this in the, in the slides that we had, but basically, so Compose for desktop works. The way that it works is that you have the compiler plugin, right? And then everything on top of that is the Skia engine that is working, but it's, it's not directly talking to Skia. So there is a well-maintained Java, Java which entails, sorry, JetBrains maintains.
28:09
And that's how they are able to compile for the Skia engine using Compose for desktop compiler plugin. Now, if you, that's one of the reasons that it actually only works on JVM right now, because the Java bindings exist for Skia right now.
28:25
But if you did want to go and do something like a, like a Mac OS version, then you need to have some sort of binding for Skia engine. And that doesn't exist. At least no one is maintaining that, or no one has created one. Once that, and I think we lost Nishant or we had problems with this.