It would take a significant effort for an experienced UI dev to properly implement the sidebar tabs unfortunately. That’s why I’ve implemented the workspace and properties editor tabs differently, they don’t have the same issues and the sidebar tabs can be converted to their design. But like I said, that would still take a significant amount of work from somebody who understands the code well.
It’s a big problem, our backlog of open patches is huge and increases by the day. And many of the devs who could review them are overworked with other things already. It’s not very rewarding work too. You brought down the backlog and two weeks later it’s where it was before. Same thing over and over again; it’s a great way to burn out experienced devs really.
I love the community involvement and hate talking about many patches as being an issue - in a way it’s a luxury problem. But reality is that it often just feels like a big burden in day to day work - and you have to remind yourself constantly that it’s worth it (without really getting to directly enjoy the benefits yourself, not being a regular user).
Now in this specific case (being the one who reviewed and finished the initial IME support some years ago), it’s even harder than usual:
Testing requires Windows, with some additional setup.
You have to test & review a feature you never used, for languages you don’t speak.
The patch is big and will take quite some time and plenty of back and forth to get reviewed.
The feature by nature doesn’t fit well into Blender’s internal designs (OS window integrating into the Blender UI, intercepting events and sending modified input…) and needs uncommon solutions, which need to be judged carefully.
(Excuses I know! But I’d appreciate if people would try to understand the difficulties we face as well.)
Just a thought, would it make things easier if you created a “layered” approach to things like community patches ? , for instance eg. I have a patch that does xxx to something xxx inside blender, instead of active top level developers reviewing and approving it you would have lower level devs go through the process of reviewing and approving (with consultation from top level devs).
If by any chance something like that exists, would expanding this area as a community project help ? like a Community code quest, where people commit themselves to fix an issue or implement a feature, like a Blender Community Quest
Some initial review could be done by some “first responder” team, similar to how we have our bug triaging team. There are actually plans to do this eventually but it’s not a small thing to organize. I personally pushed quite hard for applying similar practices to the patch tracker when we improved the bug triaging efforts and started doing bug sprints. It will still be tricky either way.
Usually the most work to review non-trivial patches has to be done by experienced devs unfortunately. Only they can make a good estimate on how this will affect further maintenance and what further consequences certain design decisions may have (or what alternatives could be better).
Another issue - and I’ve seen this happen plenty of times - is when a more junior dev reviews a patch, goes through a bunch of back-and-forth with the author, maybe pushes it in a certain direction and eventually approves it, and finally the more senior dev takes over and disagrees with the design entirely. That is a terrible experience for everyone involved.
I think you are talking about a workflow design core.
But the problem is still the same - it is hard to find a person who can possibly be fluent in such a wide range of workflows presented in Blender.
As hard as find a fast modeling engineer, that performs organic modeling, familiar with project management and deadlines on massive projects and simultaneously fluent in sculpting, compositing and animation.
I’d personally love to work on almost every single one of these. For some of them I’ve planned the implementation and solved the tricky parts in my head for years already. But every single one of them also needs significant amount of time to get done well. And my time and mental capacity is currently spent on other topics, that I’d argue are high priority as well for the most part. I can only speak for myself, but I think other devs have the same problem.
As usual, the problem is not the ideas or the will to do things. It’s the sheer amount of other important things that have to be done (including never ending patch review as discussed in my earlier post).
There are good news about it, but anyway, it is a hard to solve task.
It is mathematically hard problem, it is not similar to UI/UX usability problems.
The difference is that they require almost completely different types of research.
Math problems are hard, but can be solved in the sandbox.
UI/UX can be solved only during massive production to make sure that concept work in practice.
For example, during toolsets development we faced with lost of ideas, shiny at the concept level, which was literally crashed by the very first deadline.
The problem is that such a concepts technically cannot be handled as a bugs, because they was actually designed, but they can be just as dangerous as bugs.
As I say, something like this was proposed some time ago, as a mere consulting device to see if there were objections to some ideas in the first instance so as not to waste time implementing them, and it is not that the idea was officially rejected, quite the contrary. But it was rejected de facto because of the implications that it has…
There was a problem that usually solves a workflow design core as well.
An excessive listening and wrong prioritization.
For example, 3dsmax was built around parametric modeling, and its mesh/poly paradigm was made quite limited to fit that feature. As a result it is physically painful to fix cursed meshes there, because there are no proper UI/UX solutions for working with things like photoscans or CAD imports.
So when you are using 3dsmax it is mostly creating than fixing meshes.
In contrary, Blender has got several nice solutions to problems like that, a more flexible mesh paradigm, vertex-to-edges highlighting to detect tearings, flexible non-manifold selection modes to detect a wide range of mesh issues, facedots to control faces distribution over edges carcass and so one. As a result, fixing meshes in Blender is just as easy and pleasant as creating.
For sure, max users was voting against facedots because they are not familiar with such a paradigm, that solves a problem generally unsolved in max, and it is impossible to explain that such a feature is needed for a wider range of modeling workflows than is presented in max.
As a result there was an attempt to remove facedots, than they was brought back with corrupted display, which was fixed only after a year. But the amount of work that required facedots did not diminish, no matter how corrupted they were, so people doing these types of work grew gray hair all this time.
Lots of cases like that, when systemic problems are solved through votings, brings a tension.
Blender contains surprisingly many solutions to problems that are not solved anywhere else.
There is always a feeling that one day lots of Sketchup users will claim something like UV editing as useless and complicated, because it was never solved in Sketchup, and Blender users will be forced to protect it, citing things like gamedev modeling Sketchup users are not familiar with.
Is this proposal available anywhere? It’s good to link to this kind of proposal when claiming your suggestions are being ignored as it’s possible we just didn’t see it, or were busy with other things at the time.
Also, I already mentioned this addon by PM to Alberto.
He can hate me for this, because it’s already implemented by addon that need to mention for everyone who want this features instead of to be built-in.
To the point:
Cursor Fit & Align (selection can be any element/s)
Blender original - comparison of convenience of use
Addon
Align Origin to the Cursor - with option to keep cursor rotation
Addon
Align View to the Cursor - position and rotation
Addon
Cursor and View Bookmarks
Addon
This can be a huge feature for Blender 3.0, improved 3D Cursor.
If you want to talk more about this feature and how to implement it in Blender UI, we can start separate topic.
The first time that I proposed was in a conversation in a thread about that, I think that few hours after you talked and before some williams comments. And other user quote to highlight the proposal.
So many people want to solve common 3 point precise aligning in so inprecise way…
It is build from existing abilities and does not cover aligning demands completely (they want to “enhance cursor” in pretty obvious way, not to “solve aligning”), and requres a lot of GUI for such kind of a functionality, so it is nice for addons, but does not fit the core functionality design.
Most of such a tasks we solved with a single button solution - through making temporal rewrittable transform orientation with a predefined name, which orientation is generated based on a selected geometry.
Thanks for sharing this insight. I believe you should write a full blog post about this issue and your expirience with this grunt work.
Although, I am not a dev I know fully well what it is like to do low level work that HAS to be done. It really can burn you out in a couple of months.
I DO appreciate the work dev do on all level but often forget that not everyone gets to work on exciting projects like Cycles-X or geometry nodes etc. Your work is really appreciated too!
Make that blog post so we can remind ourselves that it’s not all roses and also point others so they can get a good inside into devs day to day work.
I’ve seen random strangers find each other on discord and have a nice conversation and then the one who knows how to code makes a script or addon or custom build of some open source project and implements dozens and dozens of features/changes the other person asked for just because they’re bored and enjoy chatting with the other person and find their requests as in interesting distraction.
I really hope Alberto isn’t asking for anything I actually want. I don’t want them poisoning the spirits of the devs with this attitude.
I also don’t understand why if they have already created a script that does what they need for their workflow, why argue here?
Have you considered a 2nd tier repo where contributors can work amongst themselves, review each other’s code and then only once every 3 months or so have everyone in the core Blender dev team review just one or 2 of the highest quality items from that group of people? Of course this will enrage people if you look at a patch that a lot of people put a lot of work into and decide you don’t think it fits with the long term goals of core Blender.
I really like Blender’s current UI on the surface. I have heard that beneath the surface the code the powers the UI is horrible. How would you feel if an organization created from scratch a UI framework directly inspired by Blender with one of their initial goals being to somehow be capable of replacing all of Blender’s current UI with their system without most users even noticing it changed?
I think of other FOSS apps like gimp and inkscape that would probable get a massive injection of cash donations if they modernized their UI like Blender did. It might be a good idea if many creative projects all agreed to have a core UI system they could all benefit from instead of having to internally reinvent the wheel.
FIrst of all I don’t speak for anyone but myself. I’m obviously no dev, don’t know anybody, have any influence, or reputation that would matter. I’ve just noticed a consistent lack of awareness as far as how ask for things in a decent way.
The devs are totally used to weird attitudes, and even if they aren’t, they wouldn’t withold assistance out of spite.
As far as I know, there is no problem with Alberto.
I know a lot of users completely roasted being trolled by several maya/C4D users with unknown scope which opinion was heavily prioritized users during development conversations.
I know people who have lost the ability to work in a program even if they don’t need too much, or who have followed workflows that are fairly common in the industry, but they don’t speak english.
Technically anyone who cares enough about Blender efficiency can take his place.
That’s important question.
Addons always have higher design flexibility than core development, they are perfect for workflow prototyping and extention as well, so the most precious part of any program is API (which is not obvious to most users anyway ). For example, Autodesk provides an LT version of products that are much cheaper but comes with blocked API.
Addons provide the abilities that cannot be done without a workflow design.
So sometime addons are proposed as a concept provement to core design. For example, Grid Fill in its current realization was proposed as an addon.
When I think about this, I coming to a question - how to define what tasks have to be solved in core or by addon. How to determine the dividing border?
There are four groups of users feedback in my opinion.
Green - workflow issue that can be solved with addon by design, since it provide an additional infrastructure with limited scope and/or too redundant to be built to the core. (Hardops, Kit Ops, DECAL MACHINE, CAD snaps infrastructure) Yellow - workflow issue that can but sould not be solved with addons since provide basic usability on a wide range of workflows since intended design don’t work properly. (Group Pro, Collection Manager, basic snaps and alignment) Orange - critical workflow issue that was designed intentionaly and cannot be solved with addons. (wiremesh display, selection display order, Collections RTOs behavior) Red - provable unintentional program bug (bugtracker)
Such a system require a workflow design core to sort feedback and can be very expensive.
A system to sort possible designs and existing workflow issues.
It is hard to imagine such a sorting system that will work effectively on a wide range.
It says so in the thread title. No one is poisoning anything here. This is just another example, of the hundreds that there are, of how in everything that has to do with a part of blender some developers ignore all user feedback and simply don’t give a damn about it. How even some of them lie to users and go attacking them in the forum like little kids.
If you want go to the same thread about this problem in developer webpage and how other users complain about how developers have ignored all user feedback and are going to do the absolute opposite of what we asked for. Someone else has even used the word “dictatorship”, So, it’s not me, it’s a real problem. And is that a whole part of blender has constantly the same development touches (and this has already been many internal debates where many other developers agree with this) where user feedback is requested but also this same feedback is deliberately ignored.
Sometimes comes an anonymous user, says a comment that is exactly the same as the dev wanted to do and magic, the feature is made by user feedback. For example not long ago for the development of a UX feature a user, a novice, gave an idea that did not hold anything. But it was just what someone wanted to do and it was proposed as to develop. We talked to this user, explained the problems of his idea, he realized and told the developer that he was against his proposal because it was obviously the result of ignorance and there were far superior proposals. It didn’t matter, the developer had used him as an excuse and wanted to do that if or if. In the end for other reasons this was not started, but it is still the current design to implement.
In this thread I explain how an implementation that involves very little work has not wanted to implement in almost 4 years when it gives solution to one of the biggest losses compared to 2.79.
This is what I’m talking about. At some point you didn’t get what you wanted, so you freak out a little bit and make this melodramatic thread with a clickbait title. It’s a little annoying, but who am I to judge, right? Mission accomplished because you get the attention of a few developers. That’s all typical stuff, but like I said, I’ve noticed you do it a lot.
But it’s just too ridiculous when your response to getting the attention of people who have better things to do, but who still are interested in what problems you have to report, is something like this:
A bit of a conspiracty about some devs who “just don’t give a damn” and are actively working against you and the other downtrodden voices who have gone unheard, for whatever reason. Lets act like this accusation is the unexaggerated truth. Not only that, we can pretend that Alberto and friends are the boss of everybody, and donating untold amounts of money. This would get you more of the developers’ ear, but at the end of the day, nobody owes you anything.
Whether you’re trolling, or just delusional, some part of you knows that there’s no reason to act the way you do. Blender is free and open source. I’m reminded of what you said before because it’s so laughably unbelievable
Just talk to some of them and explain your situation. I’m sure they will help you. I’m sorry for giving you some grief, but I meant well. I won’t waste any more of anybody’s time talking to you about this. Maybe something will click upstairs with you, and you’ll calm down.
I think you made enough of a fool of yourself when you accused me of being here all day long for posting 40 messages in 6 months.
I already have you on my ignore list because I have a policy of not dealing with people with mental problems. So do me a favor, and don’t talk to me again.
Green - workflow issue that can be solved with addon by design, since it provide an additional infrastructure with limited scope and/or too redundant to be built to the core. (Hardops, Kit Ops, DECAL MACHINE, CAD snaps infrastructure)
Yellow - workflow issue that can but sould not be solved with addons since provide basic usability on a wide range of workflows since intended design don’t work properly. (Group Pro, Collection Manager, basic snaps and alignment)
Orange - critical workflow issue that was designed intentionaly and cannot be solved with addons. (wiremesh display, selection display order, Collections RTOs behavior)
Red - provable unintentional program bug (bugtracker)