[Bf-committers] (agree to not do it) Split Collada into a python frontend and a C++ backend

Gaia gaia.clary at machinimatrix.org
Sun May 20 23:05:12 CEST 2012


If we wanted  to move these selections to the Collada Exporter,
then we would have to add these buttons to the file export panel
as far as i understand the concept.

- But the Collada exporter's user interface is programmed in C.
- Hence wouldn't we have to implement all these buttons in C as well ?
- And wouldn't we also have to implement every target specific
   part in C as well ?

And what about third party exporters ? Such exporters would never
be able to be added to the Blender C-part and must end up as separate
export modules anyways.

However doesn't all that contradict the idea of having a "default exporter"
which should just behave according to the Standards ?

On 20.05.2012 22:40, Thomas Dinges wrote:
> Why do we need 4 different menu entries? It's totally sufficient to have
> one Collada entry in the menu and then select the type in the File Browser.
>
> Am 20.05.2012 22:20, schrieb Gaia:
>> As discussed with ideasman_42 we have agreed to just do a tiny little
>> change and rename the Exporter to make it more clear that it is
>> Blender's Default Collada exporter and that there can be more of them.
>> Now the menu could look like this (if these exporters existed):
>>
>> File ->   export ->   Collada (Default) (.dae)
>>                      Collada (3DS) (.dae)
>>                      Collada (Maya) (.dae)
>>                      Collada (Second Life) (.dae)
>>
>> Really a minor change, but acceptable for me :)
>>
>> BTW: I never ever want to disable the Blender Collada module.
>> In fact i want to help making this module shiny and precious
>> until end of this year, so that there is no longer any reason
>> to kick this module out of blender as it was considered earlier
>> this year.
>>
>> Gaia
>>
>> On 20.05.2012 21:47, Dan Eicher wrote:
>>> You wound need to write some C helper functions and either add them to
>>> makesrna or hand write your own python wrapper to be able to access
>>> them from python.
>>>
>>> A while back I was working on some auto-generated python bindings for
>>> collada-dom and all I can say about that is it's not for the faint of
>>> heart -- them folks aren't too worried about fixing bugs and the whole
>>> spec is a crazy, complex beast. Pretty sure that was the makefile that
>>> borked my /home dir so maybe I'm a little gun shy.
>>>
>>> I did have some good luck with generate-ds which can take the whole
>>> spec/xml definition/whateveryoucallit and output a pure python
>>> implementation. Not that it has anything to do with the question
>>> though.
>>>
>>> I do tend to agree with the others, there's already the option to turn
>>> it off in the build system and if it's already in there why bother
>>> hiding it?
>>>
>>> Dan
>>> _______________________________________________
>>> 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
>



More information about the Bf-committers mailing list