Posted by sand1024 on Feb 01, 2025; 8:03am
URL: https://forum.librecad.org/Incorrect-pen-results-from-the-entitycontainer-tp5726283p5726292.html

emanuel wrote

Yes, exactly, that's how I imagine the implementation in the end.
...

The object model is still very complex for me and I always try to incorporate as little as possible into the LibreCAD-API source so that the github doesn't break again with the next master update.

A scripting API is essential if the whole thing is to work well.

oh, I see.  And so I could propose you to consider a bit different approach:

1) First, define the interface of that scripting API. For your testing, you may use any dummy implementation (what ever). The idea that you will not bother with LC internals and will be more focused on scripting support part.

2) That interface may be examined, and based on it, it will be clear  - what should be changed in LC core (if needed), what is not possible to support at all ( :() or how individual functions should be implemented.  

emanuel wrote

The attempts to port the entire object model to Python using swig make no sense at all for script applications, because it is far too complex and can quickly lead to situations that cause a crash.

Yes, exactly - as I've mentioned earlier - this is a way to nowhere. Plus, it's too complex for the user who will write the script.

emanuel wrote

My main problem at the moment is that the whole thing is so much work.

I think I can support you with implementation of the API if you could define which methods should be there.

emanuel wrote

* Outsourcing and loading the VisualLisp functions in shared plugin libs.

Yes, the entire plugins system should be reworked. However, plugins support is quite aside of the scripting itselt, I suppose, and proper wrapping of scripts into plugins may be added later on top of the existing code.

emanuel wrote

* Centralized command alias management...

Well, I suppose Cmd widget will be reworked with better support of command line, and as for aliases - yes, UI for managing them is also planned (yet that's actually is embellishment, as it's just possible to edit .alias file for commands).

emanuel wrote

* Centralized menu management...

Oh yes, more flexible menu (and, UI in general) creation is needed and it's also planned.

emanuel wrote

You can't do this alone.

yes, that's was my point - it will be too complex if you'll try to do everything - support scripting part and also implement the underlying logic. That's another reason why api is useful - it will let sharing efforts.

emanuel wrote

I'm grateful for any developer help and especially for tips like the one with the pen.

No problem, please let me know if you need some assistance.

emanuel wrote

At the moment I have assigned both entity-name (DXF -1), parent-softid name (DXF 330), and the entity-id (DXF 5) group codes to the LC entity id.
I don't know how to get the correct entity-name (DXF -1) parent-softid name (DXF 330).

Oh, you've touched quite interesting beast.. Actually, the current way of working with entity's id is quite,
well, careless.

Each modification of the entity leads to creation of entity's clone - with new ID. I suppose the reason there is related with support of undo - so the entity's state on modification is frozen in the original entity's copy and results of the modifications are stored in entity's clone instance.

So for traditional referring entities by IDs - that's currently the issue and thus entity's IDs are actually not persistent (well, they are - but they may be different for the same graphical entity in different versions of the same file).

This approach also prevents reliable selecting entities via ID's in the command line.  

I've planned to review this and check whether it's really necessary to modify id always on cloning - but probably I'll do this earlier to support scripting.  Actually, that's another good point why api there is a good thing...