Standardize Workflow by Supporting GraphML Extracted Directly from Images (PNG/JPG)

[GREENRAT-K405]

Currently, concore explicitly requires a standalone .graphml file to process the architecture.

If a user wants to build a study from an embedded image (which naturally acts as self-documenting code), they have to manually extract the GraphML or manually save multiple versions of their architecture.

Benefits are:

• Better Developer Experience: Users can drop an embedded PNG/JPG and then run makestudy.
• Eliminates the necessity to keep identical visual copies (PNG) and parser instructions (GraphML) artificially separated, preventing desyncing.
• Easier sharing

@pradeeban @Rahuljagwani @mayureshkothare , I have already implemented import/export feature of embedded images (.graphml.png or .graphml.jpeg) in concore-editor few days ago, This can be considered a step further to make concore studies out of those embedded images

[pradeeban]

Ok, makes sense. Previously we didn't have the concept of an embedded image in concore.

[GREENRAT-K405]

@pradeeban @Rahuljagwani @mayureshkothare , the concore right now is mostly based on monolithic structure, like concore.py or concore.cpp (there is concore_base) but still concore scripts mostly act as standalone engine.

I wanted to try giving our entire repo an proper library structure (I have proposed this in my proposals also)

for example this could be one of the structures:
concore/
└── lib/
├── python/
│ └── concore/
│ ├── pyproject.toml # Language-specific config/build metadata
│ └── src/ # All decoupled functional logic
│ ├── concore.py # Primary user-facing client API
│ ├── concore_base.py # Base simulation logic and inheritance engine
│ ├── concoredocker.py # Container integration & execution runner
│ ├── io.py # Input/Output data parsing and validation
│ ├── params.py # Configuration parameters and environment loading
│ ├── ports.py # Input and Output port handling (iport, oport)
│ ├── shm.py # Shared memory interactions and buffer management
│ ├── state.py # Concore state lifecycle, transitions, and tracking
│ └── zmq.py # ZeroMQ messaging layers and network throughput logic
│
├── cpp/
│ └── concore/
│ ├── CMakeLists.txt
│ └── src/ # (Contains equivalent submodules: io.cpp, zmq.cpp...)
│
├── java/ # Java ecosystem equivalents
├── matlab/ # MATLAB ecosystem equivalents
├── julia/ # Julia ecosystem equivalents
└── ...

If you think this is a great idea please let me know, I can start working on it and do time to time discussion with you regarding it.

These are my points:

• When the julia project will get started, I believe we will be building it in library structure ad-hoc so why not implement that for the existing languages beforehand as a solid groundwork?
• This will drastically increase the usability from perspective of both end-user (they can get predictable APIs and modularity) and developers alike.