Hello and welcome back to the Nikolov's show, I guess, that's not the name, but still did you know that if you want to develop an app for Keri and you want to use a Keri framework to actually build the app, there's like three different choices, if not more, but three are the main ones. So they are Kregami, but also Maui, but also just cutie widgets, and I'm going to offer examples of them, I'm going to quickly explain what they are and what they are different, and why three. Before we get into that, just quick shout out to all the patrons, just a new one today, so I'm very happy, and this month I'm currently in Stockholm, not exactly a lot of money, so if you want to do a patron, keep in mind that I'm doing all of this in my free time, so it is particularly well appreciated, but anyway, this is Dolphin, you probably know about Dolphin. Now Dolphin is a relatively old Keri application, a very good one in my opinion, but in the context of Keri applications, it has its good story, I think it looks very nice, and it is built using cutie widgets. In general, all applications that are on the older side, again, I'm not saying old as a negative thing at all, I'm just trying to distinguish from the applications that were creating the last three, four years, which are actually a lot. All the Keri applications that are on the older side generally use cutie widgets, because when Dolphin was created, QML didn't exist, so what's QML? I'm probably just confusing you at this point, let's explain everything. Let me also open Discover, which is not cutie widgets, Discover is a more recent Keri application. Okay, so Keri uses cutie, I think we know that. Cutie is what is the toolkit that actually allows Keri to draw anything on the screen, amongst other things actually, but it's rather important to actually draw things on the screen, and it offers different ways of drawing on the screen. When Dolphin was created, the main one was through cutie widgets, but then QML was created. QML is a markup language in which you can embed JavaScript, so it is almost a fully-fledged programming language, because it has JavaScript inside of it, but it is a markup language that describes the UI, and through JavaScript, also the functioning of an application. Why QML? QML is interpreted instead of compiled, usually, I'm not trying to be technical, so it is a bit slower compared to the other alternatives, which are cutie widgets, which you describe in C++ directly. However, it is much, much simpler for people that don't know to programming that well to actually edit, and even if you do know programming, it is easier to read and easier to maintain. So it is a bit like HTML, CSS, JavaScript online, it is a very similar concept. There's a lot of people that know how to do web pages, basic web pages, but maybe not programming C++, because it's slightly easier to get into, not necessarily to know well, but to get into. QML, similar things, it's easier to read, easier to maintain. So it was a pretty nice thing, and when it was announced, however, on top of QML, QML didn't have all the end-user widgets already. There's KuriGami. KuriGami is built on top of QML. KuriGami I think is mostly, or entirely written in QML, as far as I'm aware, might be wrong, but I think so. KuriGami is a framework by KDE that actually has the components that you use for the UI. Let me make a very easy example. These cards, the shadow behind them, these are KuriGami components. The sidebar, this is a KuriGami component. All of this application is inside a KuriGami template application. If you open a lot of KuriGami apps, you will see that they look very similar. They are all KuriGami.application, something. So this is KuriGami. Qt Widgets, a bit older, C++. I know Qt Widgets less. There's also here not just Qt Widgets, but something from Qt built on top, but I'm not particularly expert in that. However, you do have components throughout Qt Widgets applications that are the same, consistent, sorry. As an example, let's take the toolbar. Any toolbar in all KDE applications that actually use toolbars, you can actually customize. You just directly configure toolbars, and you can change the order of the buttons, which button should be displayed, whether it should only have an icon or just text, and if so, what icon and what text. A lot of things you can do. KuriGami apps, you don't have that. That's mostly because KuriGami doesn't actually want to be the framework that stores data. So something should be built on top of KuriGami that stores a particular user configuration of the UI, and that hasn't been done yet. Another good example of a Qt Widgets app is Ocular, like this one. As an example, here we have a toolbar, right-click, toolbar settings, configure toolbar, same exact thing. You can see that these two between themselves are consistent, and they look different from this one, because these are Qt Widgets. This is KuriGami. So these are the applications that feel like Plasma. Then there's Maui. Maui doesn't feel like Plasma. What's Maui? Let's open up index. I lost my index, sorry. Okay, this is index. This application. Do you notice anything different? I do. It's completely different. Okay, so whereas there is an active effort to make sure that KuriGami and Qt Widgets app are consistent between each other, and at least look like they're made by the same person, Maui doesn't try to achieve that. So what is Maui? Or rather, Maui is the environment. This is a Maui application. Maui applications are built with MauiKit. MauiKit is built on top of KuriGami. So there is Qmau, programming language, markup. Above it, there's KuriGami, which is made by core Kd developers to build a Kd application with all of the widgets. And then on top of that, there is Maui, which is used to build this one. Again, it redefines the various components of the application, changes how they look, changes how they behave significantly. So as an example, first of all, we have CSDs out of the box. That is currently something that KDE core applications don't do, and probably will never do. That's something that the developers, me included, partially are generally against KDE developers at least. So who is doing Maui then? And in theory, Maui is part of KDE. In practice, I've already talked about this, it's rather embracing because Maui has some apps that are part of KDE. The framework MauiKit, which is part of KDE, a part of the framework I discovered today while I was trying to build the index, is not part of KDE for some reason. It is on a private repo, not private, but not on KDE's repo. So weird. And then there's a shell, a desktop shell, which is not part of KDE. And all of this together is Maui. So we kind of together, it's very closely related to KDE. However, the main difference is that the people working on Discover and the people working on Dolphin, we actually have a significant intersection. So there's a lot of people that work on both of these applications, making sure, and this makes sure really that there's a consistent design between them. The people that are working on Maui are just working on Maui, and nobody that works on Korgami and QWidget's application generally also contributes to Maui, generally, of course, with significant exception. But usually, this is entirely done as we could word it about. Generally, all of this is done by Camilo. If you open all of Maui applications, they're all done by Camilo, which I praise for their ability to make so many apps. I'm rather impressed. So these two categories are very much different. We not only have CSVs, we have a completely different concept. And there's also much more of a focus to make sure that Maui applications are extremely convergent, meaning that you can use them in very small form factors, such as a phone. If we take the Pine phone, we can see that Index is installed on it by default. Why is that? Because that's the only convergent KDE in a file manager. Discover is also convergent to some extent. You can see that it also works nicely. Dolphin, generally, QWidget's applications are less meant to be convergent. And you can see that these two looks right. This one doesn't. Because Korgami originally wasn't meant to be the framework to make applications convergent. Maui follows that. QDE, QWidget's app, not quite. It depends on the app, but in general, not quite. As far as I know, all of the latest apps done by KDE are Kirigami apps. And then, of course, there's Camilo doing Maui apps by himself, almost. So I think that as time passes, you'll see more and more Kirigami applications. Another reason for that, and sorry if I bore you for so long, but I do want you to have a clear idea of what's going on, is that there's currently a lot of work to develop Plasma Mobile, so a Plasma shell for mobile phones, such as the Pine phone. Sorry. What that means is that you need applications that work on a phone. And since we built Kirigami for that, like the goal of Kirigami is to make applications that are convergent, meaning work both on the desktop and on phones. Generally, the Plasma Mobile team uses Kirigami to make applications that work on the phone. But since Kirigami makes sure that application is convergent, meaning that it works both phone and desktop, all the applications that are done for the phone also work nicely on the desktop. And of course, Plasma Mobile developers also make sure that the applications that are meant for Plasma Mobile also work really nicely on Plasma Desktop too. So there's a very big series of applications that are built with Plasma Mobile in mind that are bringing actual real value to Plasma Desktop as well. Not all of them. Another example, Calendar, is a very new application. It is built with Kirigami. It is built with Plasma Desktop in mind. Maybe it also works on Plasma Mobile as well. I'm not sure on that. I never tried, but I mean it's convergent should throw. I don't know. I never tried. And that is an extremely powerful application. And it really tells you that Kirigami is able to do a complex application as well and not just mobile phones one. I've also heard Kirigami is just able to do mobile. No, no, it's also able to do a complex application. Last example, System Monitor. System Monitor is an application that is meant for test stops, obviously. And just by looking at it, I think you at this point easily recognize that it is a Kirigami application because I mean just look how similar they are with between each other. So it has the same card, the same sidebar, the same ideas. And again, this application is extremely customizable. You just go edit page and you can edit anything just by dragging and dropping. It is, see how much customization there is. There's a lot of customization. And this is to say that Kirigami apps not necessarily mean that you don't have customization. It feels so because on all things you can like customize toolbar and stuff whilst on most Kirigami apps you can't. But the apps that do require customization, such as the System Monitor are absolutely able to deliver it. So Kirigami I think is very valid toolkill that I would suggest you check out. New applications for KDE are generally done in Kirigami. I would suggest against developing new applications that are meant for the KDE community as a whole with Maui simply because Maui is currently a bit closed in themselves, also in terms of developer. Again, there's like this Camilo guy doing all of the applications. Kirigami has more developers behind them that are doing a variety of different applications. So I think there's more value to that. But of course it is your pick and your choice. So this was not too detailed. Of course we didn't see any code, but at least from the user part of it. Yes, one final remark. Obviously with Kirigami apps meant to be convergent. So being able to use them on phones as well, they're much better when it comes to touch. Touch screenability for Kirigami applications is generally better. Also Dolphin and apps like that work nicely because they have been ported to, but in general Kirigami apps are better. So that's also something to keep in mind and Maui being built on top of Kirigami, he narrates that for free. And that is the end of the video for this time for real. I hope that you learned something and see you tomorrow with another video if you want. There's no, you don't have to, just I think you could


So, in the previous video, I introduced two separate heuristics, H1, which looked at sort of this idea of how many tiles are in a misplaced location for our sliding puzzle problem. So if, for example, I had my three tile, my eight tile, my seven tile, four, one, two, five, one, two, three, four, five, and six in this place, again, if we're looking at it from this first H1 heuristic, we're simply counting the number of tiles in the wrong place. So one, two, this should be a two, that should be three. I think all of them are in the mis-wrong places, that one doesn't count. So we would get an H1 equaling an eight. But then we also looked at a second heuristic, this idea of using Manhattan distance and the summation of how far it would take to get all of these tiles into their respective locations. So again, if I just quickly run through them, right, an eight's already in the right spot here, so this is technically a seven. So again, if we look at sort of that one position, that would take one plus six, six needs to go, let's see, down one, two, three, four needs to go one, seven needs to go down one, two needs to go up one, three needs to go up one, five needs to go up one, and eight can stay. So what we're dealing with is one, two, three, four, five, six. So an H2 equaling nine. Okay, once again, I've created these numbers, right? I have a seven, I have a nine, but which one do I pick? That's the ultimate goal, right? I have these different heuristics that I could work off of, which one do I select? And, you know, there's really only one way we can find out and that's by implementing both of these and then testing them out. And what we would actually see if we were to run through both our H2 and our H1 is that over time, H2 almost always outperformed H1 when we were working off of an A star search. And just to see this in action, this is from sort of the textbook, you can see again, we had H1, if that was the heuristic we were doing with A star, you know, at the start, when we have a very small, easy solution, then, you know, right now, there's not a major difference between H1 and H2. But notice as these steps increase as we get into more complex problems, that just counting how many tiles are in a misplaced space is going to, you know, ask us and require us to do hundreds of thousands of considerations. Whereas if we look at H2 using the Manhattan distance formula, that's actually going to only kind of take us into the tens of thousands. And so, yeah, we now have run our different heuristics, we see that H2 is the better of the two. And that's the one we would go with. Ta da, we're done. That that that seems odd. And it doesn't really help. And in fact, what you can actually recommend is what if you just combine them. And the idea here is if we think about this, again, we had that H1 spitting out a seven, and then we had some H2 spitting out a nine. But what happens if I had another heuristic, I figure out, you know, I can program if Jupiter is in retrograde with Mars. And that turns out to be a heuristic and that turns out to make, I don't know, a 13. Well, the big idea is when we're looking at these heuristics, the key thing is we simply don't want to overestimate. Do not overestimate. And if our sliding puzzle problem, again, if we sort of dig through my older video, if it had a move set of roughly speaking 22 steps to find the solution, each one of these is, you know, technically going to get me there, if especially if the, you know, Jupiter in the retrograde one can figure out ways to get towards the solution. My point being is I have all of these potential solutions, and one may be better than the other or maybe underestimating a little too much. And so one solution that we could do is rather than just working off of one single solution, right, I know that that's how you want to do it for like assignments because grades. But if we're looking at it from I need to use this in a real world situation, what if I simply say, let me take the max, whatever the biggest number is of my heuristics, and that's the one we work off of. A good way to think about this, it's kind of like the price is right, especially in this sort of part of the game where part of the show where contestants come down, and they have to bid on the price of some thing, you know, a dishwasher, a car, I never think it's a car, an armoire, whatever, my point being is the game at this state is to guess as close to the price as possible without going over. Now, if we assume that each one of these people are a perfectly good heuristic and they would never go over, right, I know that's not how the game works in real life and people are not good heuristics. But if each one of these are trying to get as close as possible, and they know, you know, a certain number to not go over, because again, we would consider them admissible, then each one of these, again, if we're taking the max of these sort of estimations, oh, well, you know, this 825 is getting me super close to our goal without going over. And so we would select this individual who is clearly happy that I think they won. I don't know. My point being is, again, if we're starting to look at this, again, we're looking at the big idea of not overestimating. So this approach of a 700, all right, we have 700 steps that we have to take to get to our goal, that's pretty good. But again, another heuristic saying, well, we have 800. And one more is saying that we have 825. And if that's again, how many steps it takes, that's perfectly fine. One thing to take note of is obviously, you know, we've got the one person in the price is right, who always bets $1. Technically, it's a an admissible heuristic, you know, it may not be the best one. But you can see that again, it's not overestimating how many steps it's going to take us to the goal. It's underestimating to some degree. But again, if I'm taking sort of the max of all of these, you know, in this situation, sure, they're not the best one to pick this time around. But again, we've got one that we can work off of. And so again, that allows us to sort of get us closer, utilizing this max approach.  Okay, that's not realistic. But what if I want to create some other types of heuristics, because I may not always be working off of a star, right? I may not may not be working on distance. That's really what we're kind of looking at here. Sometimes the problem is not this just how far away I am in traveling kind of perspective, right? The grids doing even the airport algorithm or example, those were again, working off of a distance. But what if I wanted to work off of that sliding puzzle, it's not 100% distance, we're starting to kind of break away from just a straight kind of shoot. And so that's where we look at this idea of relaxing out our problem. The entire idea to relaxing and what all this text is kind of stating is remove some of the restrictions. When we think about any sort of puzzle, right, where we typically have some restrictions or constraints, which we'll see a little later on in videos. But the entire idea is, well, to make a heuristic, what if we just strip away some of those constraints, because again, that's producing some estimate if we're in sort of this perfect world. Here's a good example, right? If we're thinking about the sliding puzzle problem, there's sort of the real world kind of definition of what it means for a tile or a particular tile to move to another tile. So in that sense, right, again, we're making sort of the rule, a tile can only move from one tile to another, right, this two can only move to be if the two following statements are in place. A is horizontally or adjacently or vertically adjacent to B, aka B could only be sort of in these separate locations, because a has to only work in a horizontal or vertical direction. It's like a rook in a chess game. That's the only way it moves. The second rule was B has to be blank. And again, we can think about that in that sense of like, you know, if there was a five here, or even if let's arbitrarily say, if B was here, and there's a five, I can't move there. Something's already in the way. So those are sort of at least some simple rules or restrictions that the sliding puzzle problem has. But again, what we can do is we can say, let's strip away some of these restrictions, let's strip away that B has to be blank. Now, again, if we're looking at that same idea that we have a two here, we have a five here, I want to move here. Well, that's perfectly fine. I'm perfectly allowed to move and have two numbers in the same location. Again, this isn't the real world sliding puzzle problem where it's a physical thing blocking, but it's just sort of relaxing out our problem. We still say that two can only move in sort of the cardinal directions left, right, up and down. But we've just said it can move into places that are perfectly already filled. That's perfectly fine. That's one sort of relaxation. Well, if you can sort of take this relaxation, you might already have an idea of what else we can do. What if the only restriction is B has to be blank. Now, we've removed sort of that cardinality rule. And so two, as long as say this portion, this center portion is blank, two can move there. It's perfectly, we're just saying, yeah, it can move there. It's kind of like now it's a queen, or rather a superpowered queen, because two could technically also move to this location. There's, you know, we're not restricting it by any sort of dimensions. We're just saying it can move to these spots. And sort of the last little one that we could operate off of is what if both of those were stripped out? Then, you know, again, a tile can move from A to B. There is no if going on there. All of these are again, just sort of relaxing out our problems. And what we can start to think about is those turn into heuristics. Each one of those is turning into their own heuristic. So if we said that again, that that first one is still working off of the idea of adjacency, right? Well, if you think about that for a moment, that's very similar to how the Manhattan distance problem is working. You know, we're just looking to see based on some kind of going up and down or going up or down and then left or right. That's it. It as long as we're adjacent, it's perfectly fine. It doesn't matter that B is filled already. So we've already sort of seen this approach. And just to jump a little down here, this one where we strip out everything, that's technically just our H1 number of misplaced tiles. Again, what we're looking at in this context is again, if tiles are just free to move around, then it's just a matter of which tiles need to be swapped. And then finally, that last one where we're sort of only worried about B being blank. Well, that could be sort of a mythical new heuristic that I would call very similar to our straight line heuristic that we saw in the A star problem. Again, we're just kind of operating with this idea that this tile needs to be moved into this tile. As long as B is blank, it can. And so let's make the B line for it. So each one of these, again, I have a new heuristic that I've been kind of brewing. The only way to see if H1 is better than H2 or if H3 is better than H2 is to test them out or build all of them. Just build them all. Again, it's not the end of the world. If you do it, and then take out the max, whatever that max happens to be, that is your H.


I just discovered something that may have been common knowledge, but it's opened up the world of Sonoma desktop widgets to me. I didn't think desktop widgets would be all that helpful, because I usually have two completely full 34 inch screens with windows covering everything. How would I ever conveniently see any desktop widgets? Well, I just happened to click on a tiny sliver of open desktop space and, lo and behold, all of my windows moved off screen to display the blank desktop. Another click, and they're all back. This makes my full 68 inches of desktop widgets one click away. Another click, all my windows are back. He says, sorry to say, if any of you're saying, I've been doing that for years, you haven't, none of us have been doing it for years. It is new to Mac OS Sonoma. I'm sure it was put in for exactly this reason. And you can change it if it drives you crazy. And this is it. It's sort of a quick tip in reverse, because when Sonoma first came out, we talked about how to disable this. Mark M makes us realize why we might not want to disable it and instead just adopt a new habit, because he's totally right. Having those desktop widgets a click away actually makes them valuable. But if you want to control this, you can go into system settings, go into desktop and doc, and you will see an option there called click wallpaper to reveal desktop. And you can either have it set to always or only when you're in stage manager mode.


Alright guys, this week I'm going to talk about Level of Detail and what this means for 3D art. The term Level of Detail refers to the method of reducing the number of polygons or triangles used in 3D models based on their distance from the player or camera. This technique increases the efficiency of rendering by reducing the workload on the graphics card or GPU. This is usually achieved through the use of Level of Detail groups. The way these work is for each asset or piece of scenery in a game a number of models are actually created. Each of these models has a different polygon count ranging from the most detailed version which may be tens of thousands of triangles down to a version featuring very little detail and a vastly reduced polygon count. This is demonstrated in this example featuring a bunny that we'll call Nigel. As you can see, each model represents exactly the same bunny. All of these are clearly Nigel. These four models would represent the different levels of detail in the LOD group. The clever thing about the way LOD works is that the closer the object is to the camera the higher the level of detail that is shown to the player. So if in a game we're standing right next to Nigel, we'll be shown the version with 69,451 polygons, but if Nigel's right at the other end of the level, we'll only see the 76 poly version. The next example demonstrates the way that this works. As you can see, when we're close to Nigel, we need to see the highest quality version in order to see all of the detail. But as he moves further away, the polygon count can be reduced without us really being able to tell. This avoids wasting processing power and rendering detail that we can't see because the object is too far away and ensures that the game can maintain an acceptable frame rate. Here's a video which shows level of detail being handled by an algorithm rather than an LOD group. The closer we are to the terrain, the higher the number of polygons that is shown to create all of the detail we can see. But as we move further away, you can see the polygon count being dynamically reduced to lower the amount of processing needed on Jones that doesn't need to show a high level of detail. So there you have it, level of detail. I hope I've given a clear explanation of what this is and if you think that I have, then please show your support by hitting that thumbs up button below the video. I upload a new video every week, so if you want to see more videos like this one, then please subscribe to my channel. If you have any questions or comments on this video or anything else to do with 3D graphics, game design or media studies in general, then drop a comment below the video or contact me through any of the methods you can see on screen. Thanks for watching and I'll see you on the next one.


Yeah, but there's really no other way to do that. Like, because that's where it was very intimidating. You're activated, man. So a little bit different. So, so, so a little bit different. I built a thing. That's our faces. That's our faces. I built the HTTP 2.0.3 Progressive Web App. And this is for our podcast, because I don't know. Do you know? We do a podcast as well. Yeah, it turns out that most of the videos are actually podcasts just during the video. Don't care about the video. Don't actually, podcasts are where our hearts are. All right, we don't give or take this really. We just do this because we have to. But this is the podcast. Oh, you built a little podcast. Little podcast app, yeah. So it works offline, because it does. And you can download the episodes to work offline, right? Oh, that's neat. So what I'm going to do is, well, I'm going to go on to a slower network, because I think that's an interesting thing to do. So people can have a look at all the interesting networks we have here at Google. One of them, we have a 3G network. So this is basically our proper interconnection, but the access point just makes it bad. So we have a quick way of testing how things behave on a bad network, because that's usually quite interesting to look at. It is, yes. So, right, I'm going to download one of these episodes. Take that one. And so, it's downloading now. You'll see now. Oh, there's a mini progress bar. Look how cute. A mini, tiny progress bar. So let's set this one off as well as a shorter one. Now, this is kind of how things work on the web today, right? Yeah. It's slow, whatever, but that's fine. But here's the problem, is if this app gets closed, which if I put the phone, this is a big phone, if I put the phone in my massive pockets, then at some point, this is going to be collected from memory, because you'll be using other apps. These devices don't have as much memory as other things. So we can sort of emulate that by doing this. Yeah, this is basically a phone in a pocket, and at some point, the network goes, nope. And it might not be the whole browser, it might just be that tab's gone, and we go back in, and, eh, wait, I downloaded this. Why is it not downloaded, Jake? What did you do? Write it back to our app. And because it's the tab was in charge of doing that download. And the tab closed, and it stopped. Yeah, but there's really no other way to do that. Like, whoa, whoa, whoa, whoa, whoa, whoa, whoa. That's where. That was very intimidating. You activated it. Things have changed. So this is the progressive web app based in Canary. It looks the same. It looks the same. So there's little differences. Whoa, whoa, whoa. Look at parallax. Parallax scrolling. This is an animation worklets. I'm using all the modern things. We should link to that article that someone wrote about animation worklets in case people don't know what it's about. Yes, we should. Is that one of your articles, is it? It might be. Who knows? Excellent, brilliant. People should go and find out. It is a good article, actually. I mean, it's what I used to figure this stuff out. So I'm going to do the same thing again. Let's download, let's download these two. Brilliant. Now, some things are different. Oh, look, it's integrated, like, notifications. Integrated into notification. And we've got progress here. We've got the icon there. That's neat. I'm going to do something magic. So that's the Chrome beta one. That's the old way. And this is the Chrome Canary one. So they've gone out. Close them all. Close them. Look, it's still up there. It's still up there. And we can go back. That's neat. OK, it's still there. What is this? What are you using? This is background fetch. That's a good name. It's a fetch in the background, isn't it? Yes, it is. And so as you say, yeah, it will not just battle through things like the app closing. It will go through connection changes as well. So I'm actually going to switch networks. So that was going to cut the download. That's going to stop. And then it's going to, once it connects onto this other network, it's essentially going to resume. But it'll be able to resume from the same point it was at before. It's not lost. Provided the server supports it. Provided the server supports range requests. Good catch. Now it's going to start downloading a whole lot faster. There it goes. So we've just got one through and the next one through, because this is fast network. And those are fast networks. That's amazing. Who would have thought they're now available offline? So is it still a fetch? Like is it still just a response object for me on the code side? Well, I'm sorry. Have a look at this. So this is how you would kickstart one of those things happening. OK. And like I said, I designed this API, so be nice. No, no, be brutal. Be brutal and ask questions. All right, so this is actually main thread code. This is not service worker code yet. So you're just getting the service worker register. You're waiting for the service worker to be ready because I guess a service worker has something to do with it. Yes, it does. But you're kicking off it from the normal JavaScript. So it's hooked off a service worker registration. Now you could still do this within a service worker or a worker. This is an example from a page. But yeah, it can be done elsewhere. So you get sRU edge background fetch, fetch. Oh, it's just a new fetch call, which seems to have the same parameters just with a name at the start? It's slightly different parameters. So you're right, it's a name at the start, and then it's URLs or response request objects. And an array of these, even. An array of them, yes. And that's important because we felt like if it's a podcast, could have artwork with it, movies could be spread across thousands of files. It's true. And you want to have one semantic group of downloads. But you can cancel one. You want to cancel all the other ones. And that's something a developer shouldn't have to re-implement, I guess. Exactly. OK, that makes sense. And then the options objects, where you can give it a title. That's for the notification. Icons for the notification. And the download total is for the notification. Kinda, as well. Because if you've got. I can't figure it out. If you've got 1,000 downloads, we don't want to block on starting all 1,000 of those. I guess the notification is mandatory. Like, you're not allowed to do a background fetch without the user knowing about it. Yes. And that's why, so you can do, if you're fetching one thing, you don't need permission. The idea is it's super visible. It's in the notification tray. You can cancel it from there. So if it's multiple thing grouped into one notification, it's a bit. OK, I see that. It's the same pattern as proper downloads from a website. You can start one of those without any permission. If you try and do multiple at once, it will ask for permission. So will the download total get automatically corrected in case I provide a wrong value? No. It will be enforced. So this is one of the things we wanted with the API. If you say this is 10 megabytes and you go beyond 10 megabytes, then you get canceled. OK, what if I do give too much? If you provide a download total that's higher than what it turns out to be, the progress bar will get to 80% and then it's done and you're fine. So it's not an error. Interesting. So if you're unsure about the download total going? Be conservative in. Yes. But the idea behind this is we want to show the user, because if they look at that notification, it says this website is downloading 10 megabytes. You think I'm fine with that? You don't want them to end up actually using 500 megabytes. Yeah, because they might be on their mobile plan and not on the Wi-Fi, right? Yeah. All of these are optional. If you don't provide a download total, you get an indeterminate thing. And our idea is. Oh, but that's OK? It is OK, but the idea is like if the site's not going to tell you how much it's going to download, the user's more likely to cancel it because they're like, well, I don't know what this is doing. I'm not getting any promises. So what's the name for? For getting it later on. So you get a background fetch registration object. I don't actually have the, they didn't do a code slide for this, but you can do sw-backgroundfetch.get. You pass an ID, you get the registration back. And once you have the registration, you can start doing things like this. So wait, what is bgfetch? So that is bgfetch, this is the registration object. So it's the same deal. That is the registration. So a new fetch returns your registration object. Not like a normal fetch will return a response. This one gives you a registration object because progress is probably much more important in a long-running fetch scenario. Yes, it is. And this is like a grouped progress as well. It's for the whole thing. So you get these, it's very similar to how XHR works. But this will also give you things like .id, which is the ID you've already provided. Yeah. Things like .abort, that you can cancel it from code. Oh, that's good. Exactly, I might want to build your own UI for cancelling it. Which you have in your thing. Exactly. Can it also do upload? That's a good question. Not in Chrome right now. Because one of the biggest issues in a long-running issue is that fetch upload still doesn't have progress and you always have to go back via either XHR or do a weird second channel to the server that reports back how much has been uploaded. So I feel like this would be a good fit. Chrome's current implementation doesn't support requests with a body. But the spec does, because one of our use cases is uploading a gallery of photos.  Hit send, put the phone in your pocket, don't care. And you can set all that up when you're in airplane mode or offline and it will just figure stuff out. That's going to be interesting because I think resumable uploads are tricky. Resumable uploads are not in the spec and it's one of the things that me and a couple of engineers might look at next year. 2019, the year of resumable uploads. Yeah, maybe. So as well as progress, it's on the same registration object. You can match things. This is very simple. Meaning I can look into the record of an individual file of a group download thing. Yes, so this is me getting the podcast. It will resolve if undefined if it's not there. Then you get the response ready, which is another promise for the response, because you might not have the response yet. No, true. And the response might even fail. If you queue up 1,000 files and you match on the last one. Exactly, exactly. But this will give you an in progress response as well. Oh, neat. So the idea is as you're downloading the MP3, you could start playing it. That's not supported in Chrome, yeah. Can I add access to the streams as well? Well, the response will be the response object. So the response ready says the same as in fetch. The headers have arrived, but the body might still be in progress. Exactly. OK, that's cool. Exactly, exactly that. So this is all stuff you can do on the page. But this is what happens in a service worker. You get top level events, background fetch success. So I get to blame you for this event name. Yes, you do. I originally called it background fetched just to try and be shorter, but people said that's weird. And I can see where they're coming from. Why not bgfetch success? Oh, we've shipped now, mate. Not changing it. I've been told that as long as only one browser has it, you can still change stuff. And it's not instable yet. So this doesn't minify. It's a string. Well, it'll gzip with the other ones. Actually, they'll only be one of them. Actually, you'll have background fetch failed and background fetch abort as well as the free events you get in your service worker. I'll open an issue on the spec. Thank you for that. Thank you. So this is, you get the registration object. And it's the same that we saw before. Oh, no, that's the same. OK, cool. And this is where background fetch success, after this event, those requests and responses are gone. So it's your responsibility to put them in the cache. Exactly. So this is what I'm essentially doing here. And this is one of the things we're thinking about making a helper method for, like, put these in that cache. Yeah, I mean, we already have cache.addall. Yes, but that takes just requests. I know, but I feel it's similar helper method on a cache. Put all. Put, yeah, something. Or some kind of transfer. Yes, that is what we're thinking. That seems reasonable. Because we also think it might be difficult for browsers to do this without copying and so it transfers. So if we think along videos, we say like they can be split into multiple files and they're probably quite big. Yes. What's the story there with cache API? Because I feel like I would get worried about quotas and things. Well, if you've got it here, you're taking quota anyway. OK. So as long as we can implement this without copying, you're not doubling the quota. That's why we're thinking about introducing a transfer method to make it easier for browsers to do that shift rather than it be a copy operation. I mean, this is something you probably don't want to just easily lose because the browser needs to claim space. It'll probably be a good case to also look at persistent storage API, whatever it's called. That is what I'm using in the HTTP203 app as well. Cool. So if you add it to the home screen or bookmarked or there's been a strong signal of usage, you can ask for persistent storage and you'll get it. The thing worth just asking for and you don't get it, fine. So another part of it, and this is the last bit. Background fetch click, background fetch click. This is a bit. Oh, let me guess. When you tap on the notification? When you tap on the notification. And so again, you get the registration and you can decide what to do based on maybe how the background fetch is doing. I have never used the clients.thing to open something. I need to look into this. But this is really cool. So you get to decide how you react to a click. And apparently you're deciding what to do depending on whether the download is done or not, which is cool. Exactly. Because if it's successful, we can go to the latest podcast. If it's not successful, so this would be, if it's in progress or if it's failed, just go to the download screen. And presumably you would have an error there or something. Maybe I don't know. Oh, cool. I was just kind of making this up. But yeah. And so as a result, this is what you get for that. This kind of download system where you can just click a load of stuff. And it will just happen. And if the tab closes, if you're offline when you press these things, it will still work. You said in Canary behind a flag? It is in Canary behind a flag. And we are going to move to an origin trial for it. So the details will be different. Do you have an article on this by any chance? I have it ready to land at some point. It might have landed by the time this video comes out. You'll find out by looking in the notes. In which case there'll be a link down the, what's that bit, below the below our faces. Yeah. Also can be appreciated in this nice parallax. Oh. Yes, we'll link to an article of how to do that as well. Brilliant. We can cut out how long this is taking to connect. Oh, look. It's blazingly fast to connect. I mean, it's just an authentic experience. Is it kicking you out? There we go. Connecting to the internet. Come on. Figure it out. Figure it out. Figure it out. Come on. Hey. That's good. Right.


Canadian Prime Minister Justin Trudeau and European Union leaders capped a two-day summit on November 24 with visit to the landmark Signal Hill overlooked to take in views of the St. John's Harbour. Trudeau gave European Council President Charles Michel and European Commission President Ursula von der Leyen a tour of sight which sits atop the capital of the Newfoundland and Labrador Province on the Atlantic Ocean.ATA news conference with the EU leaders earlier on Friday Trudeau announced plans to send 11,000 assault rifles and ammunition to Ukraine. Local media reported that the summit would address issues such as Ukraine, the Gaza War and joint action on climate change.