I’ve written a proposal for interface tools and configuration that I hope will be read and considered by the rest of the development community. I also thought I’d share it here. While it appears on harkyman.com, I’ve reposted here for your convenience. Any thoughts – realizing that we’re not talking about interface specifics, but interface creation tools?
The proposal follows:
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 <i>AT BEST</i>), 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, 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.
