Blender Toolbar

June 4th, 2005 . 20 comments

Today, I committed a first revision of code for a user-customisable toolbar to tuhopuu3 (testing Blender version). I overcame my last hurdle of saving the info to the .blend file during the week, so after a very long time in development, here it is.


The toolbar is stored in UserData, meaning it is saved in the default .B.blend file so it’s there when you start tuhopuu3 or load a new file. It is context-sensitive, so it contains different items depending on what mode you’re in. This useful, but also a technical constraint since you don’t want to be executing object mode tools while in edit mode, or vice versa.

Working with it is very simple, just right-click on a menu item in the menus system, or in the toolbar itself for a menu of choices. In the menus: Add to Toolbar adds the clicked-on menu item to the toolbar. In the toolbar, Remove from Toolbar removes the clicked-on item from the toolbar. Wow, who would have guessed! Move Up and Move Down let you re-order the items within the list, and Insert Separator inserts a separator after the clicked-on item. You can give the separator a name, as a nice way to group different tools like view tools, selection tools, interactive tools, whatever you like. Otherwise, you can just leave the name blank to use it as a spacer. And of course, the toolbar items align nicely in their rounded groups ;).

There are a few things that I’d like to try, which are on the todo list:

  • Options for using icons, or abbreviated item titles like in Silo (i.e. Subdivide Fractal becomes “SF”)
  • Option for horizontal layout, like a pseudo second header
  • Putting these custom tools in a popup menu if you don’t want it on screen all the time

The back-end code behind it is probably not a good long term solution, and will likely be made redundant whenever Blender’s fabled internal events system refactoring happens. Perhaps you can consider this implementation a proof of concept, but I continued with this project and committed it for a few reasons:

  • Regardless of whether a ‘real’ back-end is in place, we can still use this for user testing and experimenting with the interface and interaction design.
  • Seeing this in action might ‘inspire’ whoever’s going to be working on a proper events refactor to get moving on it!
  • Whether or not programmers consider the code good, or sustainable, this is working here and now and useful for users, so why not put it in tuhopuu anyway.

§ 20 Responses to Blender Toolbar"

  • batou says:

    coolllllllllllllllll

  • Jiri says:

    Hi,
    it looks very good :-). I will revise your code again, because it seems as huge commit. ;-).

    Jiri

  • Matt says:

    Excellent, thanks Jiri! Most of the logic is in toolbox.c – you’ll see I’ve learnt from your lesson about dynamic lists 🙂

  • Erik says:

    This looks really promising–I can’t wait to see how it matures.

    By the way, whatever happened to your new interface? I thought it’d be in 2.37.

  • malefico says:

    WOW !!!! Simple, elegant, useful, and it even looks pretty !!!! Congratulations !

  • leander says:

    WOOOOOOOOOOWWW!! AMAZING!!!!! GREAT WORK!!!!

  • leander says:

    Sorry my english, A-A,Can toolbar access directly to the python scripts? (like bridge, edgeloop cut… ) This can be a really great feature! And can optimize the modeling process. This is a idea.

  • 8tintin says:

    Very useful!! 😀
    I would like a direct acces to he python scripts, too. ItA-AYens posible?
    Thanks

  • Matt says:

    Cheers, guys!

    Erik: Nah, there’s still a bit of work to go, then the inevitable politics.

    About Python scripts, well Bellorum has posted a testing build for windows, so you can try it yourself 🙂 http://www.blender.org/modules.php?op=modload&name=phpBB2&file=viewtopic&t=6293

    But the short answer is: yes, it automatically works nicely for scripts that don’t have GUI buttons. Scripts that use the scripts window have trouble – I haven’t investigated why, yet, but I think it might be to do with refreshing the 3D view.

  • yeonil says:

    I think it needs a feature that you can assign (override?) hotkeys depending on the position on the list…ie.: 1,2,3,4, q,w,e,r… or with ctrl, shift or alt, to prevent conflicts (or better, make a toggle button: click it, and then you can press 1,2,3,4… for using subsequent toolbar positions. this way there will be no conflicts, and relieving the mouse from work will enhance the workflow)

    Yeonil

  • shizu says:

    fantastic!! 🙂

  • Erik says:

    I see. Well, that’s too bad. But I look forward to all of your improvements.

  • Vassilios Boucer says:

    The Tool Bar is Amazing!Great Work!

  • Dave Parsons says:

    well well, In one fell swoop you’ve managed to evevate your status to near deity! This has to be the most important new feature since the UI refactor began (from a workflow standpoint). I’ve always maintained that the larger and more feature packed the menus became, the harder it is to find the tool that you need with split second timing — Thusly damaging workflow. Now everything I need is laid out exactly where I need it. Brilliant!

    I do have some suggetions tho:

    1)It would be great if the toolbar automatically resized itself to accomodate the largest text entry. This would mean that the toolbar only uses the space it needs to and frees up valuable 3d window space.

    2) A rename option would be nice. Some of the menu items are a bit heavy on the ole word usage, and it would be nice to trim them down somewhat. This would go nicely with request 1.

    3)Some things that should be accessible aren’t. The undo history (alt+U) is a great example. The perfect scenario for me would be to click the undo History button and have the pull down with all editing changes right there in the 3d window. Oh yeah, one other thing….In editmode the undo options are in the menus, but in object mode they aren’t, meaning no undo options can be placed in the object mode toolbar.

    4) Click and drag funtionality to move the buttons up and down the toobar.A no brainer and something I’m 100% sure you’ve already considered.

    Im aware that this is very beta at the moment, but even now this is proving to be invaluable. My hat goes off to you.

  • Dave Parsons says:

    evevate = elevate =)

  • Matt says:

    Cheers, all!

    Dave: Very good ideas there! Now I just need some time and energy to do it, which wona[euro]A,A’t be until next week :/

    I’d like to note that this isn’t some kind of ‘solution to the problem of the menus’, rather the two are complementary, in a kind of symbiotic relationship. This toolbar is really only possible *because* of the previous work done on the menus. It’s easy for people looking at the little picture to criticise (as some people did at the time) saying “oh, the menus are only useful for newbies, they’re too big and slow, blah blah” but there is inherent value in having a comprehensive and well structured system, which we’re now seeing the rewards of here. And this is definitely not the end of the more advanced benefits that the menu system can bring.

    In a way, this idea kind of related to the current work with the panels, trying to separate out the functionality more cleanly with a clearer structure behind it all. This isn’t just a short term thing, but also might make future work (i.e. customisable buttons window tabs?) much more feasible.

    Anyway!

    1) I have a vague idea about how this could be possible, need to test. 2) Yes, so obvious but I completely missed it! Not only would it be good to abbreviate things if thata[euro]A,A’s what you like, but to also make things clearer a[euro]A,A- since things in submenus may not make a lot of sense like Select by Type → Mesh would just appear as “Mesh”. Very easy to do, expect this in the next commit. 3) Yep, No matter how hard I try to track down missing menu items, they keep cropping up 🙂 I need to investigate the undo stuff a bit more – the differences between the ‘global’ undo and edit mode undo might be a bit of a pain. 4) Indeed 🙂 I have some preliminary ideas on it, but it’s much harder to implement than think about! It’s on the list though.

    Thanks for the feedback! 🙂

  • Burns says:

    Hi,

    Excellent toolbar – but i’m having real trouble getting it working for some reason. I have followed the above instructions but a couple of things are not working;

    1, when i click “add to toolbar” on certain buttons nothing happens.

    2, when i click on the buttons that i have added to the toolbar nothing happens?

    Please help.

    Thanks

  • Matt says:

    Hi Burns,

    In the current state in tuhopuu CVS, it only works for menu items in the 3D View in object mode and mesh edit mode – I’m guessing you’re trying to add a menu item outside of those modes. Adding the capability for other modes is very easy, just time consuming. I’ve been quite busy recently, but hopefully I’ll have some spare hours to add the capabilities for the other modes in the next few days, as well as some new functionality too!

    Cheers and thanks for the comment.

  • Silgrin4D says:

    And… It seems it`s out the official branch now. Why?!

  • Matt says:

    Hi, it never was in the official branch, it was in tuhopuu, the experimental . It seems that it won’t be going into the main tree until Ton’s ‘unified tool api’ rewrite is finished, which won’t be until after the Orange project is finished. So expect movement on this to hopefully happen after March this year. It’s a shame, but there are more important things we need Ton for right now, coding compositing and rendering features for Elephants Dream 🙂 Hang in there!

What's this?

You are currently reading Blender Toolbar at Matt Ebb.

meta