plugin interface for LibreCAD 3

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

plugin interface for LibreCAD 3

gaganjyot
Hi all,

I am trying to develop a plugin interface for LibreCAD 3.

http://gaganjyot.com/CAD_Plugin_interface

I have just started the progress and I have my thoughts and ideas on the above blog. I'd appreciate any thoughts, Ideas or contributions in any forms for this.

If anyone is interested in standardizing the JSON format for communication between plugin and LibreCAD, that would be of very great help to me.

https://github.com/gaganjyot/cad_interface

--
Thankyou
Gaganjyot
Reply | Threaded
Open this post in threaded view
|

Re: plugin interface for LibreCAD 3

ravas
While you could write CSON and convert to JSON,
I would much rather write YAML.

https://github.com/bevry/cson
https://github.com/jbeder/yaml-cpp

Reply | Threaded
Open this post in threaded view
|

Re: plugin interface for LibreCAD 3

R. van Twisk
Administrator
In reply to this post by gaganjyot
Hey Gagan,

long time no seen :D 
Are you making a REST interface (Call LibreCAD over some protocol) or really a plugin interface?

Ries


On 14 Nov 2016, at 12:50, gaganjyot [via LibreCAD] <[hidden email]> wrote:

Hi all,

I am trying to develop a plugin interface for LibreCAD 3.

http://gaganjyot.com/CAD_Plugin_interface

I have just started the progress and I have my thoughts and ideas on the above blog. I'd appreciate any thoughts, Ideas or contributions in any forms for this.

If anyone is interested in standardizing the JSON format for communication between plugin and LibreCAD, that would be of very great help to me.

https://github.com/gaganjyot/cad_interface

--
Thankyou
Gaganjyot


If you reply to this email, your message will be added to the discussion below:
http://forum.librecad.org/plugin-interface-for-LibreCAD-3-tp5714404.html
To start a new topic under LibreCAD-dev, email [hidden email]
To unsubscribe from LibreCAD, click here.
NAML

Reply | Threaded
Open this post in threaded view
|

Re: plugin interface for LibreCAD 3

gaganjyot
Hi Ries,

I have joined a new job this October, so was busy with initial days.

Ries, I am thinking more towards a REST based API for LibreCAD. Plans are if this rest API works fine, we can always have python/ruby library created for the API communication.

This way people can send raw JSON ( over some port via http or socket ). People could create drawings via web json. or if there's some python library wrapped around this API for sending the requests, people could write plugins in python/ruby.

These are the first thoughts.

--
Thanks
Gaganjyot
Reply | Threaded
Open this post in threaded view
|

Re: plugin interface for LibreCAD 3

gaganjyot
In reply to this post by ravas
Hi Ravas,

Thanks for the reply.

I am thinking it to make a bit more abstract so that people can even have their own implementations if they want ( json/yaml/toml/cson etc ).

I am more biased towards json since json is more common and easy to understand. I'll look into YAML more.

Rest, any of you if get sometime I might need some help regarding developing the API ( standardizing what info needs to be sent and recieved etc. ).

--
Thanks
Gaganjyot
Reply | Threaded
Open this post in threaded view
|

Re: plugin interface for LibreCAD 3

R. van Twisk
Administrator
Gaganjyot,

I would look into Lua and see if there are any libraries available to create a (preferable for your development to make life easy) stand alone rest service.
Once you have a listener fired up in lua within LibreCAD 3 you can start processing the requests with Lua code and execute that against the kernel. Lua is almost already a plugin interface anyways, so that means when LibreCAD 3 fireup, you can communicate with it :) Or leave it out for user's that don't want to have the REST API enabled....


Some thoughts:

1) I would prefer an API that has the command in it's naming, for example : /api/entry/create_point /api/entry/create_line, /api/entry/create_circle etc... This way they are easer to be maintained, secured aswel.


2) Think about sending objects instead of how a data structure looks like (as mentioned in your blog post) and let some underlaying framework take care of serialisation of said objects (this way you can create xml, json or whatever else).

3) You might beable to take the objects from LibreCAD 3 itself somewhat how the builder does it's work, you might beable to take this straight from the current lua implementation

For example if there is a Lua rest service that can serialise objects, you can try to see what happens when you serialise something like :

layer = active.proxy.layerByName("0")
c=Circle(Coord(50, 50), 70.7106781, layer);

This should generate some json for you and see if that is suitable (remember I am a java guy and in java this stuff is easy because we reflections) and if that works :)

I would imagine you need a supporting javascript library in case you want to select/create layers, attributes etc... So you can create a line with a set of attributes.

Let me know how it goes,
Ries

PS: From looking at https://github.com/gaganjyot/cad_interface this might not cross compile very well.
Reply | Threaded
Open this post in threaded view
|

Re: plugin interface for LibreCAD 3

gaganjyot
I would look into Lua and see if there are any libraries available to create a (preferable for your development to make life easy) stand alone rest service.
Once you have a listener fired up in lua within LibreCAD 3 you can start processing the requests with Lua code and execute that against the kernel. Lua is almost already a plugin interface anyways, so that means when LibreCAD 3 fireup, you can communicate with it :) Or leave it out for user's that don't want to have the REST API enabled....

I'll look more into this. I am though a bit biased towards pure C++ work. People won't be dependent upon another language for the same until they personally prefer.

Some thoughts:
1) I would prefer an API that has the command in it's naming, for example : /api/entry/create_point /api/entry/create_line, /api/entry/create_circle etc... This way they are easer to be maintained, secured aswel.

Seconded! makes much more sense.

api/entry/open_file
api/entry/save_file

looks nice.

2) Think about sending objects instead of how a data structure looks like (as mentioned in your blog post) and let some underlaying framework take care of serialisation of said objects (this way you can create xml, json or whatever else).

Even I was thinking the same. Actually what I was thinking was how will this work with GUI components.

Like if I requested,

api/entry/zoom_in
api/entry/add_toolbar_menu
api/entry/append_function_to_context_menu

etc.

3) You might beable to take the objects from LibreCAD 3 itself somewhat how the builder does it's work, you might beable to take this straight from the current lua implementation

For example if there is a Lua rest service that can serialise objects, you can try to see what happens when you serialise something like :

layer = active.proxy.layerByName("0")
c=Circle(Coord(50, 50), 70.7106781, layer);

This should generate some json for you and see if that is suitable (remember I am a java guy and in java this stuff is easy because we reflections) and if that works :)

yes, Java/Go I've seen this for json. I'll see more into this.

I would imagine you need a supporting javascript library in case you want to select/create layers, attributes etc... So you can create a line with a set of attributes.

first priority will be some REPL ( interactive command prompt ). That will communicate with kernel and write a DXF file. Then I'll write python scripts for the same. :p

Also ries the best part of this work is we can incorporate plugins with a license which we don't like. we just need them to communicate over IPC.

lets say a DWG/DXF library "A" is GPL and we prefer MIT, we might write a program that will parse the DWG/DXF using library "A" and send the data to some socket or HTTP. This can be seperately bundeled and Licensed GPL and distributed.

Our LC already listens on HTTP/socket so can recieve this data though being completely MIT without any problems.

Let me know how it goes,

Sure I'll keep updating.

PS: From looking at https://github.com/gaganjyot/cad_interface this might not cross compile very well.

Actually I am on a windows platform these days. I'll port it to CMake once I get some POC going good.