event system recode

i have seen the sunday meeting agenda page on the wiki. it sounds great (and will be a lot of work :p) but i didn’t really understand all of it. i have a question about python…

will this make it possible to write tools in python which work just like if they were written in c? will python scripts also be able to do the “operator -> notifier -> listeners -> view -> …” loop?

Not much echo on this Christmas day is there?
Well, maybe not that many people can keep an interest for that most obcure subject either and, to top it, it still quite in its infancy.

Ask Cambo: he’s mostly in the Python forum and I bet that he’ll love to have somebody to discuss the matter.


That’s part of the plan, yes.


Can’t wait until the event refactor is finished. What Ton have done so far and what’s planned is just awesome. I know the devs have mountians to climb before we get there, but when we do, I’m sure it will be more than worth it =)

My goodness!

I also read that whole log and I just want to say that it sound fabulous! I’m sure it will make it easier for other coders to get into programming tools for Blender. Now I must re-read to understand it fully!

Merry Christmas!


It has begun.

The beginning of customized hotkeys and everything. I’ll keep the hotkeys the way they are now/

It seems that for shortcuts we will also have arpeggios (successions of keys), not just chords anymore.
I’d rather have it than some Shift+Alt+Ctrl+Key that we have now.
Maybe we won’t have to run the left hand all across the keyboard anymore; we may at last even be able to keep our right hand on the mouse at all time.
The use of laptops without NumPads could also be facilitated.
If standardized keymaps for this may emerge in the long run that would be perfect.


I’m not a coder, so I had some trouble following the details of what they were talking about, but from what I could see, they are going to be recoding pretty much all of the UI and mesh modelling tools and also how Python interacts with the kernel.

Looks like we will get a whole new Blender! :eek: they mention that the new versions (v.3.0!!) will be non-backwardly compatible with the older versions. Would be a bugger to release the new open-source movie and the open-source software dosen’t support any of the files! :confused:.

Could you quote something to that effect?
Or is it something that you read elsewhere?


I read the log and took it a little differently…

I think they mean that files created with the new version cannot be opened or edited in older versions of blender, but that old files can be opened in the new version when it arrives

It’s cool stuff to be sure, but this amount of work will surely take a year from now at least to be finished to current functionality?

I hope I can open older files in Blender 3.0 when it comes out, I have BGE games that I would need to be able to open in the new version.

To say the truth I dont understand why people are so happy about the possebilety to have customized hotkeys. When it will be possible everybody has to recognise that we dont have free hotkeys, beside the fact that some keys are covered with 16 (!) commands. To use this new feature we need free !!! hotkeys. This means the organisation of shortcuts has to be thougt over right from the start. So lets imagine we throw away only 30% of all the hotkeys which means round about 100 (!) how do we aktivate the missing functions? We need more menues and this means totaly new solutions for the gui - even changes with left, right and middle mouse functionality. If one thinks about the concequences of “free hotkeys” this could mean greater changes in the functionality than most people might imagine. You are opening the box of pandora…

Why all complain about the new .blend and other things ?

The 3.0 will have some conversion script to convert old version or will have it built in so no worry it is still python and will be python made ?

Be happy and a good new Year!

after the refactor sequences of modifier will be taken into account, e.g. Ctrl+Shift will be different from Shift+Ctrl and so on. This alone will make some room.
Also we will be able to redefine our shortcuts on the fly (using a button in the menus likely) so if you anticipate that you are going to do a lot of Alt+M>At Center you could redefine the Qkey for doing all that, or even Ctrl+Q: who needs a shortcut to quit anyway? Is that something we do all the time?
There are other letters that I would redefine gladly like the Vkey since I don’t really need to out and in, out and in VertexPaintMode when I am painting. Same for Ctrl+S since we have Ctrl+W that works way better.

There will be other means of expanding and make the shortcut assignment more flexible, like being able to hold down any key as a modifier or even multi-events like holding more than two keys, any keys down at the same time, if I understand well what I read.

Will the new system be context-sensitive?

Of course, as I’m sure you know, currently the same key can do different things depending on what window/mode you are in.

Not that it bothers me or anything - just curious!


Koba: yes. The operators which will process the data will receive context information as an argument.

indeed, they talked about forward compatibility eg. as you said opening the files made in the newer( timeline - forward) version in the older( timeline - backward) version of blender, wont work, as i read from there… :confused:

Sweet now I can have all my hot keys set up this way: select edge loop = Ctrl>alt>shift>F>U>*>K>b

lol, just a joke


I wonder if it’ll make music too?

But, almost seriously, keys can all become modifiers so holding down Skey and using RMB will be enough, for example.

BTW even mouse buttons can become modifiers. That’s mad !

Now, I wonder if we will be able to use more than one button at a time.
Ton talked about investigating the possibility of using multi-pointing devices, even 2 mouses at the same time.

Another goodie: vertical headers, multi-headers, headers one doesn’t have to scroll…

Tools generating their own mini-panels for their settings, just the time they are needed.

About the compatibility, this is clear enough by itself:

<ton> stiv: i am 100% sure we can be backwards compatible with this
<ton> but not forward compatible
<ton> so once you use new .blend files, it will throw warning box
<LetterRip> backwards compatible - can use old blends in new blender
<LetterRip> forward compatible - can use new blends in old blender?
<ton> i do keep in some forward compatible features though
<ton> LetterRip: yes

This is just a bit more than custom hotkeys, it’s a whole cleaner code, with seperation of UI and business process. Very extensible, maintainable etc… However, the coders do have a HUGE task to port to that design.