[Bf-committers] New event system

Jean-Luc Peurière jlp at nerim.net
Wed Jun 27 23:54:31 CEST 2007


Le 26 juin 07 à 20:43, Ettore Pasquini a écrit :
>
> A good source of ideas could be the current OS X Cocoa  
> architecture. It has
> a strong MVC enforcement and it's built across many design  
> patterns.  I was
> at WWDC this year and an experienced windows .NET developer said he  
> was
> unable to "break" the MVC separation.
>
> It could be interesting to consider GNUstep [ http:// 
> www.gnustep.org ]...
> Not sure where the current implementation is at the moment, but if it
> includes cocoa  bindings it would be really great.


Cocoa is indeed a very good source of inspiration at it is one of the  
cleanest
MVC modern implementation i'm aware of (Ruby on Rail is also known as
good, but web app programming is a much simpler domain).

It is in fact possible to break it but this is very hacky and  
unnecessary.

However cocoa or its ancestors from NeXt come imho with too many strings
attached :

- Objective-C is my favorite language but i think it is fully  
inappropriate for
   blender, even if only for the interface. Main reason is  
portability. If there is
   not much  problems in the *n*x world thanks to gcc, the compilers  
available
   for windows  are imho not up to the task. POC (Portable ObjectiveC  
Compiler)
  can work with M$ tools but it is a bit of a dialect based on a new  
(and bizarre
  to my taste) interpretation of the old stepstone specification.
- the foundation libs are not part of the language and would need to  
be either
   ported from GNUStep or rewritten. This is an huge task and the  
opaque types
  basis concept of foundation is quite a contradictory to the basic  
philosophy of
  blender.
- Cocoa uses and abuses of all the nifty advanced concepts of Obj-C  
especially
   delegates and protocols. Not easy to replicate in any other  
language as Apple
  failure to do so in Java is a proof (Well it is possible in scheme ;).
- We dont need that. Our needs are much simpler than what provides  
Cocoa,
   while at the same time, the fully OpenGL interface concept put some
   requirements (like being able to do all drawing in one go) that we  
would have
   troubles  to meet with cocoa.

My early design tried to get the good ideas while not doing more  
changes than
expressly needed. C language for the core of blender is really  
mandatory and
it is possible to do that in C, even if it will be very OOP in design.

we have already the Model part (the blender datalibs) and splitting  
the interface
code is not that hard imho (but still a big task).

I will provide soon more documentation on how i see things. One nice  
point by
the way is that writing a controller in python should be easy. views are
probably harder but feasible.

I would very much appreciate that others enhance this design or propose
something else that works better.

however we need to :

- code in C
- solve the problem at hands which is essentially customizing interface
   and simplifying the event handling, not more, not less
- respect the blender existing concepts. No problem with the datalibs
   which are the equivalent of model, but the scene itself (and the  
spaces
   embedded in it) is also a datalib. Space independence must be
   kept.
- get rid of all the while loops and define clear communication paths



-- 
Lukep


More information about the Bf-committers mailing list