[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