 Again, hello everyone, welcome to Blender UI today. So I don't know if you're familiar with it, but every Monday on the Blender channel, we share what's new in Blender today. It's in the last week. And this time, we're going to do that. But for the UI module, the user interface side of Blender, which it's a module, but also it's mixed with the other modules. So it's a bit of what we're going to show here is some of our work, but actually lots of other people's work as well. So just a roundup. I'm going to present everyone. Here we have Harley. Hello. I don't know if you know him. I'm Harley from Western Canada. I've been working with the Blender UI module for 13 years before I had gray hair. So yeah, forever. Hey, I'm Hans. I started working on Blender through the UI with Property Search. Nowadays, I'm mostly working on nodes, but it's mixed together with UI, as always. Hey, I'm Julian. I'm doing eye development pretty much since almost 10 years now. I'm since four years full-time at the Blender Institute in Amsterdam. Yeah, but I'm also doing some other things like the Asset System and I did some VR stuff. But mostly I focus on usability things. I'm not a developer, but I try to copy-paste other people's work. So guess that counts. So this is a small roundup. So what happened since, well, we never did a presentation like this. So what happened since Blender was born 30 years ago? Well, now we have a regular meeting. Every other Tuesday, we do have an official user interface module meeting. But every Tuesday or whenever it's needed, we do have meetings, calls, short meetings. Yeah, we have only two hours or more. But it's hard to, with Canada, US, and Amsterdam, it's kind of hard to put it on a good time slot. But we try. You can read all the, that's also new. We are sharing every outcome of each of the meetings on the DevTalk forums. And there are some discussions there going on. So you can read what's new and comment on it. It's still a maintenance mode. You wrote this thing. The Blender UI module was put on hold or as a maintenance mode, which means that we are not actively, I mean, I don't know. We actually don't say that we're maintaining it. I mean, I didn't come up with that. It was mostly sort of the ideas that we currently don't really do bigger changes. So there's not going to be another 2.8 project or something like that. But we do regular development, bug fixing maintenance, and we can still do changes that are more likely to not cause the pitchforks to get rised. So yeah, we still do work, but we don't still like those bigger overarching changes anymore currently. That this presentation is like the opposite of that, because we are going to see a lot of these projects that actually are quite big. So I think that saying that it's on maintenance modes is just like, hey, don't blame us. If we didn't tackle this one issue, but I think we are to blame. We should be back. Full track. 2024. UI 2024. Now we have a name for the project. All right, so next, human interface guidelines. We have this document. We have started this document a year or two years ago, right? I think during COVID, I think. The idea was to have documentation to, I mean, what it is already in Blender and try to organize it, but also give it as guideline for other developers, for other developers, especially if you look at some add-ons and they, let's say, they're pretty interesting looking. And it would be much nicer for everybody, for the only the add-on developers to have guides, but also for the users to have a more familiar UI, depend no matter the add-on that they're using or which part of Blender they're using. And there is a lot of limitations in the Blender layout system that may lead to funky UIs, but we can do better. At least just aligning, for example, terminology. How, which type of word would you use? Like, do you use, if something is normal, don't use the word normal because in, I don't know, Vertex has a normal face, has a normal custom. Custom can be anything. So a lot of these things. And make a UI consistent with the rest of Blender. Yes? I think it's also a bit useful for us, like it forces us to also think about UI a bit different on a different level and try to come up with actual concepts, not just solve one issue by one, but actually to think about concepts, like try to generalize things and have some consistent ideas throughout the UI. And I mean, I think we figured out a fair amount of things by just working on this and thinking on that level. So it's pretty useful, I think. We did, and we keep finding these kind of issues sometimes, like even, even also, okay, what was our thinking back then when we actually decided that all labels should start with title case, right? Like why? But also as a place to point other developers. So even, I noticed that the translations for Spanish doesn't start all labels with capital, like with title case, and that makes it look very different. But in Spanish, actually, it kind of makes sense. So those things should be written down as a guide for, okay, why are we deciding this? Or for example, there's a new feature when I mentioned later, it's input placeholders, which is a small hint of text inside of text inputs. And that's new. So how do you write text in there? Is it title case? Is it lower case? Is it upper case? Is it like exclamation marks? We don't know. We need to decide on that. So that's something we're gonna continue working on. It's on the wiki, by the way. It's on the human user for human interface guidelines on wiki.blender.org. And with that, we can start a bit of talking a bit of the projects that I've been working on. Such as? Okay, you've got the most boring part first. Many of you might know me as somebody who's obsessed about single pixels, but I'm also obsessed on typography. I think it's important. I've been working on this for a couple of years and we've had some milestones now. The first you'll notice is that we've changed the font for Blender 4.0. You might like it, you might hate it, but there's reasons why we did it. Hopefully, I can explain this a bit better. Whoa, did I know what we want? This. Ah, this. We're trying to move toward typographical correctness in Blender, although we only use type, in, I don't know, action graphics and titling and in the interface. I think it's important that we deal with it correctly everywhere. It just opens up more possibilities for using type correctly. So we're sizing now to the 64th of a pixel. Positioning is close as we can, 64th of a pixel. I added the sub-pixel anti-aliasing, so we now render individual glyphs on quarter pixels just so that if you turn that on, you're getting those letters as close as possible to where they're supposed to be. Important to me is that if we now make a font twice the size, it's twice as long, which is really important in an interface that scales. Otherwise, things move all over the place and drive us nuts for the anal of us who like things to be where they're supposed to be. So yeah, it's just a matter of making everything correct as far as the type of font designer was wanting. There's also been a lot of performance changes. We cache everything now, the fonts and the faces and the sizes of the glyphs and how we look up different parts of characters. So it's blazing me quick, but importantly, all the underlying code now allows us to use an unlimited number of fonts simultaneously. There are roadblocks in the way of that getting to users yet, that we have some fixed size tables in a few places, but we can literally get rid of those and have as many fonts as you want all the time. So that'll come probably to text objects first, let's see. Variable fonts, we've had supports for that for quite a while. These are fonts that internally can be not just one weight or width, but the font itself can change over different design access. You probably are familiar with these. We have underlying support for all these axes now. We've just exposed that for 4.1 for the weight of the UI font. So we've changed to enter, but if you wanna use enter light, you can just dial it down to 300 and you're using inter light in the interface. That's for 4.1. I think too interesting there. We do have also the underlying code that if a font is not variable, we just augment it with transforms. Like, or if a font has a limited range of weight, say, we will augment it as well. So we could add extra boldness to something that only goes so bold or slant something the opposite way, even though the font doesn't support that. So we have, yeah, all that working now. Many people, we may not realize that we replaced our single font before with 24 now, the work in a stack. So if you enter a character that's not in that first font, it'll find it in one of the others. Without having to go through all of them, it's all quite efficient. We support almost every language in the world now down to about 15 million speakers is what the cutoff we have right now. We'll be adding one, a Cambodian language for 4.1, but we're covering almost everybody now. It's, I think we're missing maybe a half billion people, but we're pretty close to covering everybody. It also means that we have complete and full coverage for most of the unicode blocks. So really every symbol, every, I don't know, math symbol you wanna use, it's all in there. All the glyphs are in there. All the emojis are in there. All of them, including up to 4.1. Come on, yeah, every emoji. Yeah, skip those. The last resort font is in there too, so if you put something in that's totally weird, it'll at least show you something, not a little empty box. Hate that. But future work is important here. I should be able to move most of these features into text objects fairly soon, which means that we can use variable features and have it use the fallback stack, because I just hate that people right now will load up Blender, make a new text object, type something in their own language, and nothing shows up. It's that initial frustration is terrible, so this should eliminate that. Everything will show up. With right now the limitation that we're not currently doing complex languages, like right to left languages, like Arabic, but that'll come soonish, I hope. The support for new output formats, I should be able to get that in fairly soon. At the moment, our code assumes we're outputting in one format, and we need to be able to add the capability of doing multiples simultaneously so that we can do color, sign distance field, or even clear type like output, but it's not a matter of just selecting one or the other. If you're doing a sign distance field output, that can't do color, so you've gotta have some backups. You have to be displaying them simultaneously. If it's clear type, you've gotta take that off if you're moving it around. There's lots of little details there. The reason I'm gonna add support for open type SVG though is that those can be used for our current icons. Like although you can now find icon fonts, those are all just strokes, like simple strokes, where our icons need fields of varying opacity, some things that regular fonts don't do yet. Open type SVG does that, which means that if we can put our fonts in there, we've got infinitely sized fonts, not just the little tiny ones we have now. The next step after that is adding complex shaping so we can do right to left languages and ligatures and all sorts of cool things, but it's really hard. So that might be, I might really add some of that to text objects within, I don't know, a couple of releases, but Arabic in the interface could be much longer. It's really difficult to edit these things. It's easy to display them, but editing right to left is really hard, especially when I'm not gonna be happy unless we can do mixed languages, so English and Arabic and then English again, it gets really complex. But we'll get there. Most of these things are 4.1 and 4.2 and I can probably get some in there for 4.3. So the next year. Promises, promises, but yeah, I'll get there. That's it, that's it. Is there, yeah. Also, this is your moment. If you need help with like, I don't know if you know all those languages by heart, but if you need help with people contributing with like, okay, this is correct, this is not correct, this is... Oh yeah. Yeah, very much welcome. All right, find at Harley on Blender Chat if you can help with like testing those languages. All right, another big project of last, doing well from the last year, but actually a bit before that, which landed in 4.0, is the Asset Shelf. And for that, we have Hermann. Yeah, so the Asset Shelf. A few years ago, we wanted to basically animate us from the Blender Studio, but also from all over the world, like everybody wanted to have this new, a better post-library design and we wanted to do that based on the Asset Browser that we developed. So one of the first things that we figured out when talking about this new post-library design was, okay, animators should be able to just use this in the 3D viewport that like, just even have it in full screen and just have access to their poses all the time, very fast and very convenient. Back then we made the decision, okay, we don't have that much time. We also want to kind of get this done for the sprite-frites production so they can actually use it for that. So we kept it simple for the first version and we came up with this sidebar UI. That is, I mean, it worked, it was fine, but it wasn't great. And you know all the issues that you usually have, like the sidebar, every add-on on their mother already puts their UI in there, so it's a sacred space and animators ended up switching tabs a lot and whatever. So we did work on this new design for the Asset Shelf and that the trigger to finally work on this was the Prash Assets project then because we also wanted to rethink how people use Prash Assets in Blender. The current workflow is just really convoluted and not great at all. So we came back to this idea of this Asset Shelf and so we finally made it work and we decided, okay, let's first get it to work for post-libraries and then apply this to Prash Assets as well. So this is not how it looks, but it's close to it. But you can see, you can just see your pose at the bottom of the screen and you have the buttons to select different catalogs. So you can, in the Asset Browser, customize where are your assets in which catalog and then you can really easily browse for the different catalogs of assets. Yeah, and then you can say, I wanna see either my hands or like my mouth or whatever, it's really fast to use, really convenient to use for productions. And this is basically how you select which catalogs you use. You have the tree of catalogs and you just say, these are the catalogs that I want to have and they show up as tabs. A bunch of more features, I'm not gonna go into all of the detail. We put in a lot of effort into really optimizing it, fleshing it out well. You can also just resize it and it snaps to like multiples of the preview height and you can resize the previews and show the names and blah, blah, blah, a lot of stuff. So this is sort of a very temporary work and progress on brush assets. So this example for hair sculpting, the curve sculpting, and then you can, instead of using the toolbar and all that kind of stuff, you can just very easily click on the brush in the asset shelf and this scales to 100, 200, 500 brushes, whatever. So it's a really scalable UI. Develop for this kind of use case. So the asset shelf basically is really optimized for using assets. It is not for like authoring assets or like, you know, for that you still open the asset browser. You have the full context. You can edit the tags and the other metadata, the preview image. You can put things in catalogs and whatnot. You see all your assets there. This is really optimized for certain context. So if you go with vanilla blender and you go to post mode currently, then you will be able to use the asset shelf. Currently it's hidden by default. So you have to click the little plus icon to show it or do it from the menu. But it's sort of very context sensitive. So it depends on which mode you are in, which tool you have. You could make it dependent on which tool you are in, whatsoever. So it's really optimized for a certain use case to show you the assets that you want in that specific situation. I think that's already it. This is not really all that well. Like a planner today, like you have the sections, but I mean, we just throw this out now. So one topic I wanted to talk about was code quality. The Blender UI code does have some serious code quality issues and I want to like briefly cover about what we can do about it or what my perspective at least on this is. Basically like it's very old, like there's still plenty of code from like long before 2.5 in there and then 2.5 things were added and then a lot of development happened and then 2.8 and like, so it's like this thing that just really grow over years and it's layers and layers of hacks and new features and things just sort of added there. And that is really becoming a problem. We often talk about spaghetti code where everything sort of depends on each other and you fix something, though you change a little thing there and something there breaks. I always say like if you change an icon and your toilet starts flushing, that's a problem. And it's not even like, I mean, I'm sort of joking about it, but it's actually these kind of things happen. Like very simple examples, we did change an icon like a year ago and suddenly tracking drop in some editors wouldn't work anymore. This kind of stuff happens. Like it's stupid what happens with this kind of code. So here we do start having the issue. Not we just start having that issue, but many developers really don't want to touch your I code and there's a good reason for it because they know they are going to break things. It's very complicated and yeah. So there's the big question, of course. Do we need a rewrite, like a big project where we replace the entire your I code? And it's kind of like, I kind of want to say yes, like we definitely need to rework parts of it. But easily end up with like second system syndrome where you try to like replace an entire system and you try to make it perfect and try to really engineer it and you know, but it actually never gets done and it's a big failure. So I do want to do things there, some bigger rewrites, but I want to really focus on, okay, how can we slice this up and actually make it a bit more manageable so it actually can happen. I really want something that is a bit more future proof that gives us a lot of more features, more tooling also to develop user interfaces and blender basically. So nowadays we actually do a lot of refactoring. It didn't really use to be that way, but we do really follow the principle nowadays. I think all of us developers of, you know, leave the campground a bit cleaner than you found it in. So we constantly changed things in the small and also a bit in the bigger, not big architectural changes, mostly, but yeah. All the code is compiled in C++ now. Like it's still mostly C code, but you can at least make use of C++ features that helps a bit also to optimize things and stuff. There was a, some years ago, I started a bigger refactoring of the Outliner just to start exploring how can we do this better with modern code design. And this year we actually had a GSOC student pick up that and continue that work there, so that was also really nice. Google some of code. And then the last thing I want to talk about is views. That is also going in the direction of code quality. They have the awkward name views, maybe it should be like model views or whatever data views, but basically it's this concept of, you have some piece, you have some set of data, repetitive data also, and you want to display that in the UI nicely. And I realized at some point we keep sort of rewriting the same UIs. You have like these list or three views in like the Outliner and the file browser, browser animation channels, UI lists, like the vertex and materials and that kind of stuff, and a bunch of more places. And for every single time we implement, re-implement like the layout, the UI drawing, filtering, custom or like the context menus. Every time we keep re-implementing those things and everything, all of them is like incomplete and like a bit inconsistent and stuff. So the idea was to have a system that basically allows you to create these user interfaces quite easily and have a consistent feature set. It's all run by the same UI system basically. And the first or the most prominent example right now are the three views for those hierarchical views. And we already use them in a bunch of places. We use them in the asset browser. We use them in the asset shelf. This is now the new CreasePencil V3 UI basically for the CreasePencil layers. It uses it quite a lot. Light Linking, yeah, this is the asset browser. I'm using a picture for the node panels, but they also use it. So yeah, we immediately jumped on it and started using this. Like different developers jumped on it and started using this already. There's not just, okay, one of the features, for example, that is added there now and that's quite easy to use. It's like actual track and drop in the tree view. So the CreasePencil, for example, uses this. Yeah, that's, I mean, it's quite simple and it's how it should work. But except often the outlander, we don't usually have that just because we always write this the same kind of UI code over and over again. Now we have it unified. Not play this and go get it. Then there's also the grid view. It uses the same system, has many of the same features. This is a bit more optimized to be really efficient at what to potentially be really efficient at loading like previous images as you scroll over them. And this is the grid view. Very simple, but it's used the same system, same ideas. I think that's it for me. What way to replace it? He asked if the asset shove is meant to replace the toolbar. I wouldn't say so because tools and assets are still a bit conceptually different, but for a big degree like in sculpt mode, you wouldn't use the toolbar anymore to select brushes. You just use the asset shove to select your brushes. So practically to big degree, yes, but not entirely. I guess you're still gonna have your transform tools, your annotation tools and stuff. Sorry? Yeah. The toolbar will still be there. Yeah. I don't think so because I mean, you can also make, select the transform asset or something, but I don't know. That sounds a bit weird to me. I mean, I kind of like that you just have a thin row of icons on the side where you select your tool which is sort of a bit of a mode that you're in. And then you can still, based on that, you can still select different assets like when I have a particle painting brush or so. You can just select two different assets or so. I mean, again, the asset shove can replace many of the current use cases of the tool shove, but it's not gonna entirely replace it, I think. Love time at the end. I wanted to go through one use, the one situation where people hear of the UI team which is often when we make a mistake. I'm guessing that's probably most of the time when people think of the UI module as a concept is from one of these situations. And yes, it happens, but it's part of the process, right? And that's when feedback is super essential. One situation where this came up recently is with the new searching. So you've probably used menu search in Blunder already and that opens one search bar where it searches every single menu in the current editor. And that's great, but a lot of the times you want to just search a smaller chunk of items. So you want to search everything in the add menu. In the node editor, people use that all the time. So recently, Jacques here added a feature to search just a single menu. And here, oh yeah, thanks. That was the, yeah, yeah, yeah, yeah. Simple. So yeah, there's this one simple concept, a quicker way to search inside menus. Yes, yes, but how do we expose it? It should be fast, it should be easy to use and it should be consistent and it should work with the shortcuts that we have in Blunder, but it also should work with accelerator keys, those little underlines and menu items that people use a lot more than we expected, I'd say. One other thing, we wanted it to be consistent so we should have this everywhere. But then how do we show people that they can search in any menu just by typing? We don't want to add the search text in every single menu, but how else are people going to know? So we thought in our wisdom that that's just something you learn as a Blunder user. You just type the search in every menu and people will love it, it'll be fast, but think of a new user learning Blunder for the first time. They will have no clue about this and it's just another one of those things that people will have to learn and that's just wasting people's time. So then I may be missing some parts of this journey, but yeah. No, mainly yeah, it's consistent and trying to fit all of the requirements because of course everybody wants it to be fast and then to be discoverable and then you only discover it once and then you just use it. But trying to get all of those requirements together, we I think at the end, after some back and forth with the community and the mistake of putting it into the beta release and then people getting used to the beta and then come back, this is what we end up with, I think. I think we managed to get, it is fast now, you just type to search, right? You can press spacebar to type to search. It is discoverable in some menus because there is the search entry. In the other menus, it's a thing you learn, just press spacebar to search anywhere. It works everywhere if you know how to trigger it or if you can also assign in a shortcut, you can right click, assign a shortcut, you can search in any menu, you can even search in the file menu for exporting a USD and FBX. The last item though, should not change how menus currently work and that is, that's what we did for most of the cases because accelerator keys are still available in most menus except in three, the ad menus. Add modifier, add notes and add objects. They do have a type to search by default, so you do shift A, cube and you have a cube. You don't have to start, you don't have to click on search but there is a search indicator there. So we kind of managed, I think. And it's so fast. This is how you add a modifier now. Of course, if you, like the first time is, the second time, it is not sped up by the way. This is how it works at the moment. If you do shift A, well, this is a combination of features. Shift A to add a modifier, start typing right away and then you find it. This change in the menu also came with some extra benefits to add assets, modifier, note groups, from geometry notes but in the nutshell, I think it's a much more usable experience with search. That's it with search. So the trade off there is being bold and making the big change that will theoretically possibly upset users and then taking the feedback and actually listening to people and finding a compromise. I think that that's not the worst way to do it because it gives us the opportunity to make the solid change that keeps Bunders design consistent but also encounters that ideal with the reality of how people use Bunder. So that's how things happen behind the scenes sometimes. All right, so we hope to continue, well, to improve this, to not let this happen again. A change like this so late in the development, it was a combination of things. Such as recently, recent as in the last few months, before this happened, the team started having meetings more often and that came with a lot of traction with some of it being backlog of features, some of them being features introduced by other modules, like with the help of Jack with the recent search, making the search results show up, show the latest things that you search for and that triggers like, oh, maybe we can improve also search in other ways and that triggers like enthusiasm and wanting to make everything better until the very last minute and it's not gonna happen again. 4.1, that would be the good 4.0. And some other projects that we worked on, this is the next, it's actually just inter, just to blind you all for a moment, this is the font that was introduced and it was mentioned by Harley. Another font design for once, we have a font that is designed for interfaces. It's not exactly this one on the website, actually we do have some changes for the numbers, the numbers look a bit different in Blender. It is a feature from the font that give you two types of numbers to choose from and we went with some that are easier to read, I think, on interfaces like Blender. Then input placeholders, this looks like a small thing, but it's the text here, the hints in this part. There, it's such a small thing, but it's on every website out there and you don't notice, you just sometimes you expect it, right? Sometimes you have an input field that doesn't say anything, but it's an email, you know that it's an email because it says email at example.com or something. And in Blender, in this case, this is not the most useful showcase in this example because active clip, it's a, well, a clip in Blender, what is a clip even, right? So a movie clip, okay, that's the data type. Scene, it says background scene, that's a bit redundant, okay. Camera, not so much. Camera, what is it? Camera data or camera object? So you know, it's an object. And in many other areas in Blender, you don't know exactly what does it mean. Sometimes the field could say coordinate system and then the hint is gonna tell you which type of object to use. The way of adding this placeholder is pretty also pretty simple and we hope that add-on developers are gonna start using them on their own with the placeholder or forks too, and with placeholder and just add some text just like you would with any text label in Blender. Another, whoops, another change, a list of changes though, that is way too long to fit in this presentation. The header in the Blender 4.0 and in 4.1, there are some changes coming but in 4.0 already has a cutout so it doesn't block the view when it's not needed, nice. Region Pi, it's not food, it's a Pi menu for changing the region, toggling the sidebar, the header, the footer or the asset shelf when there is an asset shelf or a footer when there is a footer in some editors. Highlight selected item, that also sounds like so, what is that? It's so simple but it's this thing which might not look like much but once you get used to it, like I don't know if you noticed but the item that I have selected is highlighted in the list. This list has four items, right? But when the list is longer, it's nice to see, okay, what was the thing that I had selected? Also a small thing but not so trivial so thank you, Harley, for working on that. The AdModifier menu that I just mentioned, know the panels, here we're taking credit for other people's work, thank you, Lucas. And that also ripples to other parts like the UI for materials. Also some work done by Brecht to integrate it in that area. Viewport overlay popovers, now the list of popovers for the object mode is not huge yet because probably developers are gonna continue adding more now that there is room for them and the overlays for each mode are split into their own popovers so things are easier to find and more discoverable. File and asset browser improvements, now the asset browser and the file browser and supports transparency for the background, right? Like a checkerboard and SVGs. And like so many, like even the full names of the, if you leave the mouse over you get a tooltip with the full names. So such small things here and there but huge improvements. Outliner drag and drop between windows also Harley. Statistics also Harley per object. So you can see the total number of vertices or objects faces and for the selected objects. So you can see, instead of just seeing all of them like you have 20 objects, you can select five and then you get these stats for those five objects. Also super handy, once you get used to it it's like how did we live without that before. Canvas speaker in paint modes, while you're painting attributes or yeah, weight paints, vertical groups, color attributes and even images in sculpt mode. You can now pick, you can select from the 3D viewport without actually going to the material or the properties editor. You can select them from there. Strip lines for invalid caches in timeline. This is one of so many. I wanted to add this one here to thank Leon for all his work, but it's done so many, so many improvements that this is small, but it's also huge. This is for the cached lines in the timeline. So you can see when something is invalid and it shows nice strip lines. We don't have that concept anywhere in Blender. I wonder what else can we use that? New progress indicators. This is not even used yet anywhere in Blender but it's there. It's a way to display progress in a small space. This is going to be used for the extensions platform and for any add-on developer that needs to show progress in a small space without a progress bar. Also, thanks, Harley. And the recent search results, think Shaq and hundreds of small tricks and fixes. When I was typing, this is really hundreds. Is it thousands? I mean, you could say, but hundreds at least with all the... Since Blender was made, thousands, yeah, but everybody, so thanks, Don. And that's about it, but there's so much more. And the future, actually this slide, I didn't share it with them, so it's more of a wish list on my side. And some of the work that we know that we are gonna work on, integrate the extensions platform, extensions.blender.org is a website that is not even running yet, so don't even go there. But it was announced last year, there is a blog post on the code blog about for the very first time, having Blender be aware of the internet. Yeah, and extending with add-ons and in the future, other areas like assets in the future. From within Blender access the internet, that's a big project, right? Blender needs to be aware of the internet, which we know many add-ons, they're already connected to the internet, which is not so great because everybody tries to do it at the same time when they open Blender, right? They check for updates and then it's a bit overwhelming for Blender to start that way. So we need to think of a way to make it a bit more manageable or a way for Blender to toggle internet offline mode. Airplane mode, a better Keymap Editor or a Keymap Editor at all because the one we have now, it's far from ideal in some situations. And it's, yes, I know, right? This should be like top priority. And to me, it is one of my top priority but I am not a developer so I can only just wish we can work on this although it is pretty, pretty huge. So working on that would mean not working on many other also very important parts of Blender. Like conflict detection for Keymaps or Keymap Layers or who knows? Editor tabs, this is with a question mark because it's a mock up that I mean, it's something that we would like to work at some point part of improving the way the editors work in Blender and they get split and joined. And a lot of this work was already done by Harley in the previous releases. It is so much better than it used to be and we would like to maybe do some research, investigate how tabs could work. The same way we have tabs for workspaces but for editors because that way we could even simplify the whole UI a lot more. In the timeline, for example, that we have at the bottom could have tabs for the graph editor and all the animation editors pretty much. The compositor, I use the shortcut shift F3 to change between the editors and it takes me a bit to understand where am I? Geometry nodes, materials, texture nodes and shading nodes. I just continue. Replace UI list with views. I think this is more of a cleaning up but also bringing those features into more parts of Blender. That was already mentioned. A simpler theme editor. Yep, now it's ours is a bit overwhelming and improve documentation so much more and excitement because there are many things that people contribute from the community which we don't know yet what we're gonna talk about next year. I think that's it, questions? Yeah, so, all right, here. So the question or the comment is about a simpler theme editor and how it could improve the way we edit themes now. I mean, if I have to choose between key map editor and theme editor, key map is there and theme editor is still important but you can edit it now. You just need to type text and XML text. It is an important project especially to improve accessibility and make things simpler. But also, not so much simple that we run out of the options that we have now because at some point, many, many, many years ago, I was like, why do we need to set the header, different header color for every editor and or the tabs, different background color for the tabs on every single editor? Why do we need options for that? And I was like, we should just nuke that. And nowadays, I don't think like that. I think we should have a way where you should say, my tabs, I want this one color and then go and being able to override that per editor. I think it is still useful because I run into or all these years, run into some screenshots of people or sharing there or some screencast on YouTube where people with either some visual impairments have these changes in their blender because it makes them like, I know the yellow bar editor, it's this and the red bar editor is this other thing. So I think flexibility is not a bad thing. You wanted to say something? Oh, I just want to say that, I know you wanted a simpler theme editor but I think you still want lots of customization. I just wanted to say that it was up to me to be less customization because some of the theme options we give users keep us from implementing some features, right? Like we had some problems with highlighting the active enum while also having hover highlight. So we're having to do two things at once and that's a limitation of our theme. But I can't show, say focus because we can't have the outline because you guys have the outline, right? Like I would like to take some themes back and have less customization so that we can give you more features because there is a conflict there. I mean, in a perfect world, we would have a light and a dark theme that we would have to maintain and you'd have less customization. I'm not sure how that would be received, right? But I would love that. Just wanted to add to the theme thing. Many years ago, I think long before 2.8 I counted the amount of theme options that we have and if I remember correctly it was something like 750 or so and since then we of course added many more theme options. Well, I didn't, but I was. Hey, I can't show. Probably a few. But yeah, it's like how do you control this? And they actually are add-ons that make it easier. I think it's mostly a matter of abstraction. Like, you know, you don't really need to control every little theme option yourself but sometimes even the theme toggle is really useful or just, you know, if you have like a color palette of three, five, 10, 20 colors or whatever, that would also already be useful. Some add-ons already do that. If we want to solve this, we wanna do it properly and like have a proper theme editor actually. Until then, add-ons. Peter, yeah, right? So the question is regarding drag and drop of FBX or any other file format to trigger the import system in Blender instead of first deciding which file format you want and then deciding on what to do with it. There is a patch, right? We worked on by Guillermo, also another contributor, online contributor. Do you know? There are two things. One is like having the drag and drop thing. There's also an idea to have a unified interface basically for importers, exporters to use that is think being developed with the USD importer. You can talk to Precht about that. And then, yeah, for the drag and drop thing, there is a patch from a contributor. He made a first version that was basically just hard-coding it for OBJ and we had some concerns like it would conflict if you have multiple OBJ importers or it's hard-coded and everything. But he's now working on a more dynamic version which is a much more promising direction. So you can just register your own file type and say, this is how I want to import things. There's still a question of how do you handle the properties like after importing and that kind of stuff, but yeah. Yeah, it sounds pretty simple actually. It's like actually that this developer made a object like that OBJ drag and drop support and that was working but it is a lot more complex, especially if you want atoms to be able to register their own drag and drop stuff. It's just, yeah, right here. Sorry. Oh, you'd like it. We have the strips back. It'll bother some people that a sans serif font has serifs for the eye and the L's are slightly curled but we selected that disambiguation option for that font for users that need it. I like that, that's what I want. Yeah, there'll be an equal number of people who will prefer the other way but we wanted to keep it for people that require it where it's not a choice. Yeah, accessibility. It doesn't sound like it would be practical for most use cases but this line is tech tips have some great videos on use cases like editing text on it and you can really grade on the eyes but existing subjects or anti-aliasing models conflict with both of these monitor types because the subjects will arrange into different things you're considering. Oh yeah, no, if we get there you'd have to be able to select the RGD ordering but that's fine. I mean, what I've got so far is really something separate which is literally rendering each glyph for the correct sub-pixel positioning where that's more like a Windows clear type with the blue and red fringes on the sides basically and yeah, we can get there once I've got support for multiple outputs at once because again, if we could just select that you can't render that way for moving text say, right? Like there's a lot of weird things with it so I need to be able to do that and other formats at the same time and that should be, I don't know, soon. Yes, Bob? Yeah, you spoke about this many times on the vendor today and the vertical tasks. Vertical, vertical tabs. Yeah, you know what, and if you look at all these tasks yeah, all these, when they stack up so many that you don't see anything there's a solution for that. But that was tackled in 3.3, I think, this. That they don't get, yeah, this was actually a few releases ago. By Guillermo, the one working on the drag and drop. Yeah, so thank you Guillermo if you're watching. Yeah, scrolls, yeah, scrolls like the rest so it's just like this. Like in, yeah, yeah. There is no scroll bar, but yeah. I don't want that. Green? Ah, yeah. No, it's a Blender feature. It's not fixed with it. Under? Yeah, so the question is if, because there is many people that are still stacking all their Blender versions that are potentially slower even than, like the computer can handle a newer Blender, but it's slower. Yeah, so if there are plans to notify users, yes. Once we have the extension platform in place, which is the, like introduces this concept of Blender connecting to the internet, we do want to have a place online, like an API somewhere Blender can ping for, like a JSON, just a text file that says, hey, there is a new Blender version and which one it is. We would like to do this, especially for the LTS releases because the long-term release, long-term support releases because those are a no-brainer. We want to upgrade always and they get updated for two years. So yeah, we want to do that. But again, it's a, it takes some design. Where do you do that? Like off by default for sure, but people should be able to, I don't know, maybe go to help check for updates or in the splash screen at the beginning, they could. But it should be off by default. Blender should not connect to the internet by default. Yeah, we want that. Blender should work offline of the shelf. Yeah, that's why we are setting all your data. Yeah, not setting all your data. You don't need to send any data other than your classroom Blender version. But still, I think we would like to keep it that way. So by default, no permission to access internet in any ways unless you explicitly ask for it. And probably yes, but yeah. Well, in the splash screen, we can show it, right? Like just a check for updates. Yeah, yeah. Check for updates. So even like after three months or so of Blender version, it could say like there's probably a new version. Like you don't even need to connect to the internet because we know Blender is going to get update in some months anyway, right? So we can already show it in the UI, say after three months, maybe you should check if there's an update. You can do it offline, right? If the option is off, yeah. It's over there. So the question is like because all the add-ons use the sidebar to, yeah, to populate, to place their add-on options, if there are plans to introduce new, like being able to introduce new editors or new areas in Blender. So that's a two-part problem. One of them is like, why does your add-on that has nothing to do with the viewport, they all choose to put it in the sidebar in the viewport. You can literally add a button anywhere in Blender, everywhere. You can even add like, I don't know, any here, there, there in the header, everywhere. But for some reason people choose the sidebar and maybe they need some, like we need to educate add-on developers to like, no, you can actually maybe reuse the name. Like if you're making something related to the view, don't call it view max, view plus for making a new tab. Show you the view tab and just add something out here. Item, the item tab is only one option, one panel. But yeah, that's one part, but I think we do want to expand. Also just a brief practical one, maybe don't call your tabs the name of your add-on. Name what the add-on is about, like if it's about animation, just name it animation, then you have one animation tab with all your animation tools in there. Don't give it the name of your add-on, like just a little tip there. There's also sort of conflicting design goals where one is that add-ons should be integrated with Blender in the UI as well. But then maybe some add-on is really doing something entirely different and that's where it makes sense, but it is a rather huge project to add custom editors, so maybe not super high on the priority list. Yeah. Yeah, actually I wanted, I don't know if I'm not gonna show it, but in Blender 2.70 is when the tabs were introduced and I don't know if we mentioned it here, the user interface, tabs were introduced and there is a section dedicated to documentation on how to actually use the tabs. There is like tabs and it's somewhere here, like there's guidelines, oh, here. Guidelines on how to use it and we expect there is a place where like add-on developers should make an effort to only create new tabs when necessary, which as we can see everybody uses and written. Yeah, I mean in general, the question like how do add-ons integrate in the UI is a big one, right? This is like a big box that we could open up and talk about. In general, yeah, maybe custom editors would help. I'm a bit skeptical because people already don't follow the existing UI guidelines and suddenly everybody creates their own editors and you just get a ginormous list of editors for every add-on. But to big degree it's also just providing better tools, better documentation guidelines, like how should you write user interfaces? Our human interface guidelines I think are important for that and then yeah, better tools like people just often work around your UI system basically and try to create user interfaces that sort of do what they want to do, but they're anything but great user interfaces and with some better tooling, better options for add-on developers, I think we can also solve many problems that we have there. Question there? Nice, thank you. Yeah, the Blender apps was announced last year, two years ago and it turned out to be a bit too early to announce that because there were so many other parts of Blender that needed attention and some of those are gonna be used for the Blender apps, but yeah, integrating them as part of Blender, I think extending the widget system, the tooling in general, like being able to make new tools with geometry nodes, maybe that will like lead to this development. So it's in line, but it's not officially there yet. Sebastian. Any other questions? No, I mean, we talked about this, yeah, he's basically asking about an option to keep the viewport orientation when you switch workspace and when we designed the original workspace, that was one of the main ideas that we had, like this is something that should be there, just never happened. There's actually a patch, I think, I haven't looked at it in a while that adds this. There was an earlier version that was, I think, a bit awkward to use from a design perspective. I think the new version may be a bit better, but we should actually look at that again. Now with the local view that the opposite, well, it actually would change the view to focus on the local option basically. Yeah, exactly, now it doesn't have that anymore, but it's a bit of a different thing that was just basically disabled. Well, I think it doesn't zoom in on it anymore, or how does it work now? There you have an option. Oh, it's an option, yeah. That's something I would also like to see, but for all the, yeah, yeah, something like keep the views connected. We even have an icon for that already, because there is a screen icon with a lock, yeah. There are also two days, but there's a high level. There's also the question of how much data you want to sync between the viewports. Maybe you don't want to sync the overlays, maybe you just want to sync the transforms, but then maybe there's some important setting that you want to share, and that's how it balloons into this huge design topic that sort of feels impossible. Although I think the idea was always to just have the viewpoint, because the idea of the workspace is still, they put you sort of in a new context and they give you all the tools for this different task, but people end up not using them as much, because every time they change like ooh, they get disoriented like where am I in my 3D scene. So just having this bit of consistency would be nice. Yeah, just a bit more background, that would be like the connected view point between workspaces. The other feature about the overlays and everything and all the settings in each editor, it's for 2.8 actually, when we were coming up with like, okay, which modes should we use? Which ones should be customizable? And yes, part of the design, the idea was that we should be able to make your own presets basically of a combination of these settings so you can have your own. That would be one way of connecting between views. But yeah. Yeah, viewpoint, yeah, that was something else, yeah. Another question, I don't even know, is there another presentation here? Well, there's one that she asked just now. We're on the last ones? Okay. Yeah, sorry. Oh, dinner. Hi. Sorry, there's two questions. Over there. The question is if there are plans to make a big thing confirmation operators, that you don't have to... Dialog windows. Like, I don't know if there are plans, but I don't think so. It's like more generally. But I would love to make them more configurable. What I'd like to do is to have optional confirmation on almost all operators that are turned off by default and we can just turn on what we want, right? It seems dumb to have some that have confirmations, some that don't and we have to decide which ones are there. Yeah. I think what you're asking for is like in some widget tool kits, you can just spawn a popup and it's confirmation popup basically without having to connect it to an operator. I don't think we have plans for that necessarily. If we could edit, I do have concerns because then people would start adding popups all the time and we do not want that in Blender kind of. Like generally popups should be used scaly like when they actually make sense, they should be undo instead. Like you don't need a popup if you can just undo something. Yeah, I don't think there's a plan to add an API code for that specifically. But if there's a patch, we can discuss it or if somebody comes up with a design, design first please would be nice. Yeah. Nice. Say. It's regarding texture nodes. The question is regarding texture nodes editor. So if it's basically gonna be brought back to life, yes or no? And I, yes, I think the goal is to phase it out and instead work on bringing back some of those features but with like first layered materials, so a way to combine and layer textures. There is a, it was announced as a strategical project I think two years ago and it's still in the schedule for some point. I think 2020. On a simpler level, there's also this idea that node group types can be more flexible. So if you use nodes that are common between the compositor, shader nodes and geometry nodes you could use the same node group in many places. And that sort of is one of the use cases of texture nodes is to make this reusable node group that can be used in multiple areas of blunder. So maybe that sort of system can just be not sort of necessary in a lot of cases anymore. Bob. Future request. The question is, if it would be possible to have different shading per quadrant basically. That sounds really complex, right? Because you have to load the textures only in one. So it's based, I don't know. I'm not the one to answer this, but I think it can be technically quite difficult. Also you need to evaluate data for different views a few ports and stuff. It's not really planned, I don't think so. The quad viewer isn't really designed for that in Blender. Blender just works a bit different, but yeah. I don't think it's, that is gonna happen so. Yeah. Yeah, question, sorry. Oh, like a text area. Okay, the question is, if in the layout, yeah, basically text wrapping or multi-line or in web, it's called a text area. Like a reason, I don't know, a reason we need it. UI code quality. I mean, I did a prototype some time ago to have multi-line labels that automatically wrap. And so basically I have no idea on how to do it. It's just one of those things that I kind of have to get to or maybe someone else or so, but it's a bit tricky because UI code quality. Yeah. Yeah, we need it for example for the note part. So many places. In metadata, I don't know, so many places. Any other question? You're hungry because dinner is ready. So thanks everyone. Thank you.