Integrated language help feature in OpenSCAD

[t-paul]

Outline

Add more interactive help features for built-in functions and modules. Right now there's already a nice summary of parameters linked as cheat sheet. Scope of this projects would be to use this information in extended form and make it available in a more direct way in the editor.

Details

• Convert the cheat sheet information into machine readable format
• Find a way to generate the existing HTML format based on the core data
• Add context help to editor giving help for built-in functions and modules, e.g. by adding formatted help output to the console window, including the links to further documentation like the language manual on Wikibooks

Expected Outcome

Cheat sheet is integrated into the application and additional context help for built-in functions and modules is available.

Project Properties

Skills

• Programming language is C++
• GUI programming with the Qt framework

Difficulty

Easy

Size

Medium (175h)

Additional Information

• Potential mentor(s): Marius Kintel (IRC: kintel), Torsten Paul (IRC: teepee), Ryan Colyer (IRC: InPhase)
• Organization website: https://www.openscad.org/

[mundele2004]

Hello @t-paul ,

I’m interested in contributing to the Interactive Help Integration for Built-in Functions project for GSoC 2026.

I really like the idea of making OpenSCAD’s cheat sheet information directly accessible inside the editor to improve usability and learning for users. Integrating structured help, generating documentation from a single data source, and adding contextual assistance within the Qt-based interface sounds like a meaningful improvement to the overall developer experience.

I’ve started exploring the repository and understanding how the current cheat sheet is organized, and I’m planning to work on converting this information into a machine-readable format as an initial step.

Please let me know if there are any recommended starting points or specific areas you’d like me to focus on.

Looking forward to contributing!

Thank You,
Lokendra Mundele

[t-paul]

@mundele2004 my suggestion for a first step would be to ignore the code for a bit and focus on using the application for an hour or two and put yourself into the shoes of a person getting started with it. Collect a couple of points and places where having documentation would make things easier and create some idea how that information could be presented.
With that as a base, we could then talk about what's possible to do on the code side and transform the script of ideas into a plan for coding.

[mundele2004]

@mundele2004 my suggestion for a first step would be to ignore the code for a bit and focus on using the application for an hour or two and put yourself into the shoes of a person getting started with it. Collect a couple of points and places where having documentation would make things easier and create some idea how that information could be presented. With that as a base, we could then talk about what's possible to do on the code side and transform the script of ideas into a plan for coding.

Thank you for the suggestion!

That makes a lot of sense. I’ll spend some time using OpenSCAD from a beginner’s perspective and note down areas where contextual help or clearer documentation would improve the experience. I’ll also think about how that information could be presented within the editor in a helpful and non-intrusive way.

Once I’ve gathered these observations, I’ll share them so we can discuss what would be feasible to implement and shape them into a concrete development plan.

Thanks again for the guidance!

[t-paul]

Oh, as a side note from technical perspective: The editor component we use currently (QScintilla) is in maintenance mode for some time now, so we may need to swap it out eventually. That means we probably should not focus too much (or only) on deep integration into the editor itself, anything general that likely can transfer to other editors too is fine. Long story short: a broad look at the whole application is useful.

[mundele2004]

Oh, as a side note from technical perspective: The editor component we use currently (QScintilla) is in maintenance mode for some time now, so we may need to swap it out eventually. That means we probably should not focus too much (or only) on deep integration into the editor itself, anything general that likely can transfer to other editors too is fine. Long story short: a broad look at the whole application is useful.

Thanks for the heads-up, that’s really helpful to know.

I’ll keep this in mind and avoid focusing too heavily on editor-specific integrations tied to QScintilla. Instead, I’ll look at the help system from a more general perspective so that the approach and data model can remain reusable even if the editor component changes in the future.

I’ll make sure my observations cover the overall application workflow and identify solutions that can work independently of a specific editor implementation.

Appreciate the clarification!

[vrajmevada]

Hi @t-paul,

After spending some time using OpenSCAD more extensively, I observed a few things regarding contextual documentation.

The existing signature hints (e.g., for cube()) are helpful for understanding parameter structure, so I don’t think the goal should be to replicate that functionality. However, for more complex built-ins such as linear_extrude, offset, or rotate_extrude, the popup conveys syntactic structure but not semantic meaning.

While the hint lists parameters like twist, scale, or convexity, it doesn’t explain their purpose, default behavior, or typical usage patterns. In those cases, I still needed to consult the cheat sheet or manual to understand the intent behind the parameters rather than just their order.

This suggests that the opportunity may lie in exposing richer built-in metadata through a centralized help component, rather than extending hover-based hints alone. A dockable help panel or structured help browser powered by shared metadata could provide semantic descriptions and examples while remaining largely independent of the current editor implementation, which seems important given the potential future replacement of QScintilla.

I’ll continue exploring additional workflow cases, but I wanted to confirm whether this interpretation aligns with the intended scope of the project.

[Harshgill77]

Hi everyone! I'm Harsh, a 3rd-year CSE student from India. I'm interested in the "Integrated Language Help Feature in OpenSCAD" GSoC 2026 project (#110). I have experience in Python, JS (React/Node),C/C++ ,and ML. I'm really excited to learn. I understand the cheat sheet needs to be converted to a machine-readable format and integrated as contextual help in the app. Any tips on where to start? Thanks!