[Bf-committers] First pure Cocoa version ! [Fwd: Re: Finally did it]

[Campbell Barton]

blender is quite usable without SDL (which can be disabled when
building), you just miss joystick support in the GameEngine and the
option to use SDL audio out, though openAL and jack can be used still.

On Wed, Oct 7, 2009 at 7:29 PM, Daniel Genrich <daniel.genrich at gmx.net> wrote:
> Hey,
>
> About Fluid + SDL: It didn't take me long to exchange SDL timers with
> pthreads one year ago :-)
> So they aren't used anymore in fluids.
>
> Anything else gainst 64bit mac?
>
> Greetings
> Daniel / Genscher
>
> johnmadstone at yahoo.it schrieb:
>>> Hi  Marco,
>>>
>>> My impression is that there isn't really much disagreement about all
>>> this.
>>>
>>> The main priority so far has been to get things working, providing a
>>> path for Blender on a Mac that allows for 64 bit and other advantages
>>> of Cocoa. This is great, considering that the Mac version of Blender
>>> hasn't received much attention for years, and has many annoyances.
>>>
>>
>>
>> Considering what MrRage written in is old document, 64 bit port is not
>> possible, because of some SDL dependecies in the fluid engine.
>> I am not sure of the details, because it is passed long time since I
>> read MrRage documentation, though I remember that it was about SDL timers.
>>
>>
>>
>>> Blender/GHOST and Cocoa have been viewed as rather incompatible
>>> entities, so it's quite refreshing to see it working. In fact it
>>> already seems nicer than the old Carbon implementation in many ways.
>>>
>>
>>
>> Of course, it is better, because Carbon is not evolved anymore since the
>> publication of Leopard.
>>
>>
>>
>>> Your plan to recode GHOST is a more long term plan, and though it
>>> sounds nice in some ways, I think it's reasonable to first get things
>>> working first.
>>>
>>
>>
>> I agree with it. Though, you misunderstood me. I still have to repeat
>> that the intention of my email was not to complain about GHOST architecture.
>> I complained about the fact that I spent my time for nothing, since the
>> current Cocoa project is managed like in an anarchy. Or, most likely,
>> has no management.
>>
>>
>>
>>> A couple of questions:
>>>
>>> Apart from avoiding Objective C++ and other code niceties, are there
>>> any user level advantages to recoding GHOST for the Mac?
>>> What problems do you think are better solved this way?
>>>
>>
>>
>> For the event part, we decided to short-circuit Cocoa Event Loop. That
>> means that GHOST/WM event loop (unchanged) is actually a nested loop of
>> the Cocoa Main Run Loop.
>> This is a solution, I found, used by some fullscreen OpenGL examples
>> provided by Apple.
>> Though, since Apple discourages polling techniques, I think that it is a
>> solution good mainly for fullscreen applications that take full control
>> of the UI.
>>
>> And, even if it is commonly used for fullscreen applications there exist
>> a technique, in pure Cocoa applications, to avoid short-circuit loop and
>> use the default Cocoa event handlers.
>>
>> Therefore, the short-circuit solution, could be just a temporary solution.
>>
>>
>> For other optimizations (if any) I have to study things better, before
>> to provide my own detailed opinion.
>>
>>
>>
>>> I hope you don't leave Cocoa/Blender development. Perhaps we can
>>> outline a longer term plan so we avoid confusion and conflicts like
>>> this.
>>>
>>
>>
>> I think I will write (by myself) an Objective-C replacement of
>> GHOST_C-api.cpp. No problem for sharing, since Blender is GPL, my
>> implementation will be, of course, GPL too and will be published
>> somewhere on the internet.
>> This approach will let me to write it in plain Objective-C (easier for me).
>>
>>
>>
>>> Cheers,
>>>
>>> -William
>>>
>>
>>
>>
>> Marco Frisan, Triest
>>
>>
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>>
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
- Campbell