[Bf-funboard] A Proposal for Blender Interface Creation, Editing and Configuration

[Roland Hess]

Here's the proposal I mentioned in the previous message to this list.
Originally posted at http://www.harkyman.com

While I can’t be at the upcoming development sprint (which, 
realistically, it’s not like I should be — when it comes to coding, I’m 
a hack AT BEST), I did want to write something up about a few ideas for 
working with the interface that have weighed on me for the past year or 
so. With one exception at the end, this isn’t about how the user 
interacts with Blender. I’ll leave that up to better minds than my own. 
But, when it comes to how that interface is created — the actual tools 
that are used — I’d like to pitch in my 2 cents.

AN INTERFACE EDITOR
Right now, the one and only way to edit/change/test/configure the 
Blender interface is through c coding. That’s a huge problem. Let’s call 
the set of all people who can code in c “Group C”. Let’s call all people 
who are good at interface design “Group I”. The overlap between Group C 
and Group I is dwindlingly tiny. Very tiny. Most likely just a few 
people. Restricting the job of interface work to the C/I overlap is a 
huge mistake. Why not put in some more work up front, and give access to 
the entire Group I? I’m proposing that Blender’s interface (and by this 
I mean buttons, panels, header elements, panel elements, etc., not such 
things as Click-n-Hold vs. modal click) be configurable directly from 
within the application, and that any configurations that are created be 
savable to an external file, much like Themes are saved into Python 
files currently.

DESIGNING THE INTERFACE WITHIN THE APPLICATION
At the moment, a user can change the “rt” value and play around with 
button configurations. That’s nice for making screen shots, but very 
limited. Best would be a system in which all interface elements (colors, 
panels, button contexts, menus) are changable by the user, along with 
some nice examiner and informational panels a la an IDE. Call it an IDE 
for Blender’s widgets. At any point, the current state of all controls 
could be dumped to a Python file. In fact, Blender’s base configuration 
would be converted (one time!) to such a format, and that base file 
would be loaded at runtime to configure the default interface. Elements 
could also be exported and imported on a modular basis.

This would not only be great for users, but for developers as well. If 
you code a new feature or module, the last thing you want to have to 
worry about is digging through the interface code, doing the math for 
buttons, etc. You build your feature, properly code it’s DNA and RNA, 
compile and run. Switch into “interface edit” mode, create a new panel 
in the proper buttons context, add/configure/arrange widgets and link 
them to proper RNA right in Blender. Bind key commands to the operators 
you’ve written. When you’ve got it as you like it — export the new panel 
and bindings either as a simple module that anyone can import to try 
(sort of like a patch), or just save your entire configuration as a new 
default. When it comes time to commit your feature/module/etc., the 
interface code exports and patches right in to the trunk version of the 
interface configurator.

 From a user standpoint, one could configure tools, menus, and pop-ups 
to suit their workflow — even creating toolboxes or toolbars with their 
favorite widgets. They would be easily sharable with others, and if 
useful enough could be included in future releases.

A scheme like this really continues and extends the promise to the 
artistic community that Blender has already begun. To the artistic 
community, Blender says: “Here’s a great tool, at no cost to you.” And 
now, this great tool can be customized by you without any special 
knowledge. But even better than that, you as an artist get the potential 
to benefit from the entire community of Group I, not just the C/I 
coincidence.

Will people do stoopid things to their Blender interface? Of course. 
Will this take the onus away from Blender’s development team to make the 
interface as good as it can be? Of course not. I think that such a 
system, though, would drastically improve the interface in short order. 
You’re reducing the testing and experimentation cycle to virtually zero 
time. It’s instant feedback, and almost no effort to game something 
differently and give it a try. Our interface people will be 
significantly more productive with such a system.

PREFERRED TOOL
Apart from my system-level suggestion above, I do have one specific idea 
that’s nagged at me for a while. It’s a “preferred tool” designator. 
When working in the 3D view (which comprises a vast majority of the 
time) Blender artists are confronted with a number of pop-up menus: 
Specials, Merge, Mirror, Edge, etc. While it’s fairly simple to, say, 
press the W-key followed by a number to select an option, I’ve found 
that in my own work, I tend to use tools in clusters. While I’m 
performing a certain portion of the modeling pipeline, I might use 
Subdivide a number of times in a row. What would be fantastic would be 
to structure those sorts of pop-ups to allow for the on-the-fly 
designation of a “preferred tool.” Then, instead of repeatedly pressing 
W, then 1 (or just using the mouse to choose it), you hit the menu key 
(W) with a modifier (like Ctrl) and it just activates the preferred 
tool. Done with that part of your work and moving on to something else? 
Set a different preferred tool. You could also include secondary and 
tertiary tools (Alt, and Ctrl-Alt?). This way, Blender works the way 
that you want it to — losing nothing in the process. All of the options 
are still there, but you can easily bend Blender to the specific task 
you are doing, on the fly.

SUMMARY
While I have great faith in rest of the development team to come up with 
good solutions for the road ahead, I wanted to place a vote for ultimate 
configurability. A system that lets interface design and configuration 
take place directly in the application workspace would not only benefit 
users in the long run, but have immediate benefits for the developers 
themselves.

The sort of sharability and openness that we already enjoy with BLEND 
files and artistry could be extended even further, and we would all come 
out ahead.

-- 
Roland Hess
harkyman