Thanks for replying here... I hadn't seen it.
Please read below:
> Thanks for reviewing my proposal.
> An example from application point of view:-
>
> ========== CODE START ===========
>
> #include <dwg.h>
> #include <myapi.h>
> Dwg_Data dwg;
> Dwg_read_file('path/to/file/provided/by/application',&dwg);
> int circle_array[1000]; // It can be of any length not less than
> number of entities.
> circle_array = extract_circles(dwg);
>
> ========== CODE END ===========
>
> This is all and hence circle_array will get values of center_x, center_y,
> radius
> circle_array[0] = value of center of x of circle 1
> circle_array[1] = value of center of y of circle 1
> circle_array[2] = value of radius of circle 1
> circle_array[3] = value of center of x of circle 2
> circle_array[4] = value of center of y of circle 2
> circle_array[5] = value of radius of circle 2
> And so on.....
As I mentioned, managing the data in a semantic way should not be
inside the scope of libredwg. I mean, for the library's sake it
doesn't matter how many circles or lines or whatever are inside a
file. The application should care about it, not the library. On the
other hand, it does matter how many OBJECTS or how many ENTITIES or
how many LAYERS are inside a file.
This plugin code [1] makes my point. LibreDWG provides access to the
data and the plugin manages it. It works, you can build GRASS + addons
and try it if you want.
In this case, "manages" means: OK, I don't care about circles or
hatches. Just loop through everything, skip all but lines and text and
put them into the rendering pipe. IMHO this kind of treatment should
be done by the application, specially because CAD and graphics stuff
generally deal with many different formats, with different API's.
Anyway, I might be wrong, so if anybody has another idea of what an
API should be please step in. The point is that my approach doesn't
exclude a more functional API in the future.
> Regarding low level and high level functions in C, what I had
> understood is to create the functions in an object oriented way, I was
> thinking to use C++ for this.
> May be I am wrong on above statement, In that case can you please show
> me an example of any low level function and how do you wish to see it
> in high level C code. Basically I didn't get you regarding low level
> and high level code.
As for low-level/high-level examples:
Dwg_Object * should_be_layer = obj->tio.entity->layer->obj;
Dwg_Object_LAYER * layer;
unsigned int _type = should_be_layer->type;
//dwg_print_object(should_be_layer);
printf("type = %u ", _type);
if (_type == 51)
{
layer = obj->tio.entity->layer->obj->tio.object->tio.LAYER; //low level
struct access
in a higher level c-ish way:
Dwg_Object_LAYER * layer;
int error = dwg_get_obj_layer(obj, &layer); //higher level c api
or in C++:
layer = (Dwg_Object_LAYER) dwg; //throws an exception if it can't cast
another example (I've implemented it already, I guess)
int layer_count = dwg_get_layer_count(&dwg_data);
in a C++'ish way that would be
int layer_count = dwg_data->get_layer_count();
> Regarding the dxf converter, We are not having any support for reading
> DWG files on linux yet. Though libredwg made an awesome effort, due to
> licensing problems we are unable to use the libredwg in any cad
> softwares like librecad, freecad or any such cad program. The
> situation is basically same as it was before libredwg. Even now people
> can't view drawings that were provided them in dwg format. So to make
> them able to read and view the drawings I decided to create a
> converter to convert dxf to dwg. Until there is licensing problem, We
> can provide people a conversion software so that they can atleast open
> the drawings in librecad or freecad after conversion to dxf by my
> converter. I personally feel this is a requirement in the real world.
> Agreed that library is not complete yet but we can read upto some
> extent and thats enough I guess untill further library gets developed.
> People would be able to upload a file, convert it to dxf and utilise
> it. It will be the first opensource dwg to dxf converter ever.
Nor "providing an online system". Appart from being an application,
which is out of the scope of libredwg (a library), "online
applications" in general are against GNU policies. People should be
able to do computing in their own machines. See [0] for more
information.
>
> Moreover, I had selected API for LibreDWG since It was posted on your
> ideas page. I know we need to concentrate on the core part but right
> now I feel that I can do this project much better than other projects
> though if I get support from you all I will work on core part after
> GSOC since then there will be no time bounding and moreover right now
> I am not having all the required knowledge of the core part as much as
> I have gathered regarding API functionality. I have love for
> opensource cad and I wish that libredwg again comes back to life and
> people are able to use it. I would try to develop it to the maximum
> extent I can, May be after GSoC also But right now I can provide
> maximum efficiency regarding API only.
In general, my opinion about this proposal is: forget about DXF and
CGI; focus on the high level C API, fix the handle system if you can
(you'll stumble across handles pointing nowhere while writing the API)
and improve the SVG converter (which is part of libredwg just as an
example) using this API. Of course a DWG 2 DXF is desirable, but it
should be written out of the scope of this project. And I agree with
you, if you are not comfortable with the core please keep going with
the API.
Finally, you are applying for the GNU Project. Please avoid "open
source" [2] in favour of "free software", which is the term that best
expresses what really matters for us, freedom :)
[0] https://www.gnu.org/philosophy/who-does-that-server-really-serve.html
[1] https://svn.osgeo.org/grass/grass-addons/grass7/vector/v.in.redwg/
[2] www.gnu.org/philosophy/open-source-misses-the-point.html
PS: If it is OK for everyone, I would like to mentor this proposal,
otherwise HSRai will have to take care of 2.
happy hacking,
--
Rodrigo Rodrigues da Silva
http://metamaquina.com.br
http://garoa.net.br
http://polignu.org
http://gnu.org
