[Bf-python] DXF exporter in 2.5*

[Campbell Barton]

On Fri, Aug 26, 2011 at 1:03 AM,  <migius at gmx.net> wrote:
>> Von: Vaclav Klecanda <vencax77 at gmail.com>
>> Betreff: Re: [Bf-python] DXF exporter in 2.5*
>> Hi,
>> I have adopted and the 2.4x version of DXF exported as well as some
>> snippets
>> from already ported exporters in 2.59 version. I have made the original
>> linear, long and thus hardly readable modular. The mesh exporting already
>> runs which is what I wanted to make. Other primitive would be ported
>> later.
>> As well as some parts with features which I have not fully understand.
>> Please review the code and let me know if it is worth something.
>> One more thought: I have split the actual DXF file generation and the
>> exported scene into a model. This allow to use another DXF library for
>> format handling. I have found a DXF library in python and asked myself if
>> would be better to use the same library for both the exporter and
>> importer.
>>
>> regards Vasek Klecanda, aka vencax
>>
>
> Hi Vasek,
> thank you for your efforts.
> I have reviewed your code,
> and tested the active mesh export.
> It looks good!
>
> For better usability I would suggest to hide all options in UI panel, which are not implemented yet.
>
> /BTW, I am not very impressed by usability of UI system in 2.5x - one can not create a neatly arranged compact panel with bigger list of options. New paradigm is "scrolling, scrolling, scrolling" /
>
> Modular structure is convenient for collaborative development, though IMHO it is not good for release purposes. Well, in context of 2.5x bloated release it should be no problem (look at bundled python 3.2 with over thousand files). So lets do it modular.
>
>>I have split the actual DXF file generation and the
>> exported scene into a model. This allow to use another DXF library for
>> format handling.
>>
> If you meant different libraries for different DXF versions,
> I would prefer to stay by one export library handling all DXF versions ("r12","2005", etc), because specifications differ marginally, and the few differences can be well handled with tags.
>
>>would be better to use the same library for both the exporter and
>> importer.
> I think it is better to have separate libraries for import and export.
> There are other applications utilizing DXF-export-library (look at FreeCAD). Obviously they have no use from Blender specific import methods.
>
>
> The DXF support in Blender needs some redesign if we want to use it for real CAD work (huge models, better representation of DXF data). I am making some research and prototyping within "CADtools" project - it is a big task and still under development.
>
> People are asking for DXF exporter in 2.5x, so it is a big help, you are migrating the code now.
>
> thanks,
> migius
>
> p.s. please replace in code "Migus" with "Migius"
> p.ss. write your name as co-author please.


Hi Migius, Quick point about the usability & scrolling, agree its a problem

Py operators can define their own draw functions, See "OBJ Import"
which has its own draw compared to "OBJ Export" which uses the default
layout, when you make you're own draw you can layout buttons together
more logically/tightly.


Also, I think default button spacing is too big at the moment, see:

See:
- http://www.graphicall.org/ftp/ideasman42/blender_style_big.png
- http://blenderartists.org/forum/showthread.php?227686-Edit-button-spacing-%28hidden-theme-setting%29&p=1922575#post1922575