Extensions aren’t just add-ons. Your entire argument is based on wrong understanding of the feature. I advise you read up documentation on this.
They literally just are, except for themes. Especially from the point of view of users, and especially the new ones. No one wants to do hard thought exercises just to figure out how something as essential as addons/extensions/plugins work.
There’s VSCode for example, or Chrome… They have “just” extensions, and that’s all the users care about. There’s no reason for Blender to invent something wonky to confuse users.
Do you really think I spent an hour making a mockup before knowing what they are? I’ve read the blog post as soon as it was up long time ago, and watched development closely.
My point is that users don’t, and should not be expected to care about some Blender’s wonky reasons of legacy system why there are “two types of addons”, the old ones and new ones called different name.
Take VSCode for example. In VSCode, extension can be a theme, a skin for solution explorer icons, a complete low level static analyzer replacement for built in intellisense, a support for another file format, a code snippet “asset”.
You are living in the mental prison of Blender where it’s easy to justify the wonkiness, but there’s just so many proofs outside of the Blender bubble that it’s possible to have just one name for plugin/extension/addon, whatever you want to call it, which encompasses many different types of content.
It’s super lazy to offload this design work onto the mind of users, having to learn about some legacy reasons blender has two.
Yes, apparently. Your entire premise is wrong.
Extensions are umbrella term for add-ons, themes, assets, and etc. Everything that extends Blender
Add-ons are add-ons, whether downloaded from internet or installed from disk.
Add-ons are always in add-ons tab, whether downloaded from internet or installed from disk.
What is in Get Extensions tab is your inside-Blender access to your remote repositories, which you can use or not.
Everybody is familiar with VSCode extensions, it was discussed when designing extensions for Blender, as well as other examples. But VSCode is simple software compared to Blender in a sense that it only does one thing, while Blender is required to accommodate whole range of different workflows. I understand your argument, its just bad design. First of all, there is no “Add-on extensions” for Blender. There are just add-ons. I see no reason why anybody in future will have to call something “add-on extension” and not just add-on when add-on in itself will mean extension.
This is particularly bad. First of all, do you really wanna see all those themes/add-ons/assets thrown in together when you’re browsing extensions websites? I’m not gonna go into UX categorization hell that will become website and Blender if this happened, but add-ons are more complicated and can have bigger impact on your Blender, sometimes negative. They require more careful picking from users side. User should know what type of extension they’re dealing with so they know potential consequences of them. Blurring the line between add-ons: scripts that run on your computer and use your resources, and themes, which color your panels differently, is gonna have big consequences.
I agree that two panels isn’t good idea, my proposal was to have “Browse” and “Manage” categories in both theme and add-ons panels (and in future assets and studiolights), where Browse would be what is now Get Extensions, but for that specific type, and Manage would be what is now add-ons and themes tabs. But I just know we would get number of complaints about people having to press one more button to get add-on from extensions platform so I didn’t push it too much.
Yes, I do. That’s what the tags are for. I’d be happy if themes were just yet another type of extension you could filter in or out using the extension tags that were added in 4.2. The themes would then be authored in the same way extensions are, except the manifest file would define the extension is the theme type, so Blender can handle it accordingly.
I could them simply install themes from extension repo and they would show in the list with all the other extension types, and if I wanted to see just the themes I downloaded, I would uncheck everything except “Theme” in the tags. And the “Extension Type” dropdown could just be nuked VSCode has exactly that. Theme is just another category in the list of Extensions categories you can use to filter your Extensions list.
I’m not going to get pulled into this, but personally I like the new system of having separate tabs for addons, themes and getting extensions.
It’s open to be extended in the future. As far as I understand, there is no reason to limit extensions to just addons and themes, and in the future they could be extended to also include geometry nodes setups, brush packs, node tools etc.
When that happens, I’d much rather have each category properly organised than have to sift through a massive list of unrelated extensions each time I want to find something.
Many of the issues still being addressed here I felt could potentially be resolved by breaking extensions out of preferences into its own panel. See posts 156-158 above for the rationale and UI mockups.
As an example,@Strike_Digital’s desire for categories would be available in the filter functionality and having categories in the filter functionality seems as though it could be cleaner way to go as opposed to a button for each, particularly if the number of categories could continue to grow.
Hi, the available extension are not alphabetically sorted, could you do something for that?
Today I was updating one non-extension addon and noticed I had to do more clicks than in previous blender versions to disable/uninstall addon before installing newer addon version. I had to:
- open Add-on tab
- find/search addon
- disable addon
- go to Get Extension tab
- find/search again addon
- click dropdown arrow
- click Uninstall
In previous blender, it goes:
- open Add-ons tab
- find addon
- click disable
- click remove
That’s almost half of steps needed in 4.2. Are there UI plans to simplify process of disabling/uninstalling addons in blender 4.2+?
You don’t need to disable add-on before uninstalling. You can still do second workflow and take one step out of it while you’re at it.
Although we could use sorting there, this won’t change for Blender 4.2 LTS (its release is tomorrow).
Hi, is this still planned? Would be nice to increase the readability when browsing add-ons in Blender.
Also, could be nice as well to show the icon when browsing as well.
Proposal:
Currrent:
Currenly I just kinda feel that the icon has been forgotten and most users will very rarly see them.
I definitely agree with this approach. The idea that people now need to understand the difference between what is an extension, what is a theme, what is an add-on, what is legacy, what is free, what is paid, is just going to be very hard for users .
It is an unfortunate function of the developer process that one gets mired in the details of the trees and misses the whole forest.
Photoshop has plugins. They are code that runs. They also have themes as well. That’s a whole different thing. For years blender has worked too communicate the concept of themes to users. Why all the sudden does one do away with it?
Well I’m sure this has been asked and answered, I cannot find the part of this thread that explains or answers my questions about security. Perhaps someone can either point me to them or answer them directly here .
- How easy is it for someone to add an extension to the online repository?
- Is there any review process where a human verifies the extension works or more importantly that it is safe?
- If it is downloaded and run inside of Blender from blenders own online repository, and it installs malware or some sort of exploit-- who then would be responsible? In other words, does Blender legally have any liability here?
I know that Apple and Microsoft take this subject very seriously. One of the reasons why they so actively monitor applications and apps on their delivery platforms.
While of course exploits are possible with any downloaded add-on, the fact that they are coming directly from Blender may provide the user with an expected tacit approval and more importantly overall ease of access to problem add-ons. I would want to make sure that Blender has firm legal understanding of potential liabilities.
Perhaps this examination has already taken place and if so can someone point me to it. I would appreciate it. Thanks for listening.
If you are not sure “how easy is it for someone to add an extension to the online repository” or if there is “any review process where a human verifies the extension works or more importantly that it is safe” then scroll to the very first message of this thread. There are links that answer these questions quite well.
Where is the manpower for reviews actually coming from? Since Blender is always short on manpower for eg. PR review.
Thankfully, there are lots of experienced people who are creating or have created addons for Blender and are capable to help with the review process. As far as I know, @nickberckley is one of them.
Edit: If you read or have a glance over the blog post that is linked in the first post, you literally find all that information.
Thank you and there is some information there. Perhaps you know where I can find information about Blender’s understanding of its liability?
After talking today with a security expert they mentioned that they thought most if not all corporate IT personnel would not allow one click installs of Blender’s python scripts without a very clear understanding of Blender’s validation processes.
Trying to find more information about extension security is difficult. I think Blender should be very upfront and transparent about all of this.
I can just imagine the harm it would do to Blender’s reputation if some sort of exploit got through. I certainly would be very sad if something like that happened.
Good corporate environment shouldn’t and wouldn’t allow one-click installs of python scripts even if Ton himself reviewed all of them, so that is not relevant. Local add-ons are still supported and still installed same way as they were before (+ with drag & drop). Nothing changed in that regard. There is only an addition of remote repositories and if corporation isn’t ok with that they can just ignore that addition and keep working as they were before.