On Oct 13, 2009, at 9:58 AM, Erik Buck wrote:
I think that the Core Data model and any generated classes should be
left untouched because you may want to regenerate the classes later.
I use Categories to add View specific drawing methods to the objects
that represent Core Data entities.
For a variety of reasons, I use Core Data with OpenGL all of the time. One of
my presentations this weekend at "Voices That Matter: iPhone Developers
Conference" uses a Core Data application with two different Views as an example
of the MVC design pattern. One View presents information about t
On Mon, Oct 12, 2009 at 11:30 PM, Richard Somers wrote:
> So you are saying that I should abandon this and put the draw method
> somewhere else like in a controller. Perhaps you could fill the picture in a
> little more for me. So far I have yet to find any sample code that is a
> document based
On Oct 12, 2009, at 2:27 PM, Ben Trumbull wrote:
It sounds like you're trying to create a tight 1:1 binding between
your model objects and controller objects to avoid actually writing
a controller layer.
That may be the case. I am currently using an off the shelf
NSObjectController and NS
On Oct 12, 2009, at 4:27 PM, Ben Trumbull wrote:
but in this case it must draw itself.
No, it doesn't must do anything. Views draw themselves, model
objects are state, and controllers are intermediaries.
...
What problem are you trying to solve by knowingly violating the MVC
design patte
On Oct 12, 2009, at 1:17 PM, Rob Barris wrote:
Within a single thread of execution, if you are about to do some GL
drawing and you are unsure of the current context, you should set
it, and it will stay set.
If I knew what it was I could set it. My model object knows nothing of
the glConte
Consider an application using Core Data and OpenGL.
Normally a model object (MVC) has no knowledge of views or controllers
for good reasons.
but in this case it must draw itself.
No, it doesn't must do anything. Views draw themselves, model objects
are state, and controllers are intermed
On Oct 12, 2009, at 12:04 PM, Kyle Sluder wrote:
This is typically where the controller layer would come in. A
controller-layer object would know of the GL context and of the
insertion/removal of objects in the MOC, and create resources
accordingly.
I think I can perhaps see light at the
Rob, your comment got me thinking and I did some checking. I am
drawing to a CAOpenGLLayer which has two OpenGL contexts, one public
and one private. The frameworks switch at times to the private one
(outside of the normal drawing cycle). This private one is where some
of my OpenGL commands
On Mon, Oct 12, 2009 at 7:47 AM, Richard Somers
wrote:
> Any suggestions or comments?
This is typically where the controller layer would come in. A
controller-layer object would know of the GL context and of the
insertion/removal of objects in the MOC, and create resources
accordingly.
--Kyle S
10 matches
Mail list logo
