|
Articles
13 Nov 2021 
Deciding Which is Better: Plug-ins or ApplicationsIvan Rykov, Chief Technology Officer, LEDAS 
Many of LEDAS’ projects are developed as plug-ins for CAD software programs, ranging from powerful systems like CATIA to lighter weight solutions like Rhino. Oftimes, we help our customers decide on which direction their ideas are best developed: in the form of a plug-in or as a standalone program.
In this post, I reflect on why and when plug-in development is the better approach compared to building an application from scratch. I’ll also talk about the forms of plug-in that are useful in different situations. Learn more about our CAD plug-in development expertise.
Pros and cons of plug-ins
Plug-ins either solve specific problems or add functions that are missing from CAD systems. A good example is CAMWorks from HCL, an advanced plug-in that adds computer-aided manufacturing functions to the SolidWorks design system.
When comparing plug-ins with independent applications, we have found that plug-ins are better suited to software used in-house by design engineers, with the aim of assisting their day-to-day work. In certain cases, the plug-in approach significantly reduces the cost of development. Ready-made CAD systems work with plug-ins through their APIs.
The drawback to plug-ins that they have to run on a host application. Before the plug-in can be used, you have to pay a license fee and then install the software. Plug-ins intended for wider distribution have their demand limited by the number of seats of the target CAD system.
We have found that, in general, end-user plug-ins are not usually at the top of our customers’ wish lists. More commonly, such software is made as standalone software for the desktop and, more often in recent years, a client-server Web application.
Pros and cons of standalone applications
When instead considering the development of an independent application, either for desktop or the Web, keep in mind that it will require a geometric kernel with which it constructs, represents, and tessellates 3D objects. (We talk more about kernels on the 3D Modeling page.) The annual cost of a subscription license for a kernel is usually significantly higher than a one-time payment for a single license of a lightweight or middle-class CAD system on which plug-ins can run.
Another source of cost is the effort to implement 3D scenes: visualization, camera manipulation (zoom, pan, rotate) and object manipulation (selection, movements, and so on. With a plug-in, the host application provides all these features via its API; in case of standalone applications, these have to be programmed at a low level or with the help of a licensed visualization component.
Types of plug-in solutions
The APIs provided by CAD systems are often thought of as a way to extend and tailor functions for the system itself, rather than creating customized processes for solving particular problems. Also, it’s not always an easy task to make a focused plug-in which overrides the user interface of the host application and substitute its own workflow.
From our experience, Rhino is an excellent example of such a system. It allows us to hide most of its default panels and toolbars, and then easily create our own panels using WPF (Windows Presentation Foundation). This gives us almost the level of same control over the Rhino’s user interface as do independent WPF applications.
Example of panel and toolbar added by plug-in in Rhino
In other CAD systems, this could become problematic as they might use outdated GUI frameworks (have you heard of WxWidgets?) or are limited to predefined UI controls provided by their APIs.
If, however, the application has an external API that can be called from another process, e.g., via COM or WCF, we can build a plug-in UI as an external application that interacts with the host CAD system through the API. (Technically, this is not strictly a plug-in.) This allows us to build the UI using modern technologies, exactly matching the required process, yet still using the geometric kernel and 3D scene capabilities of the host CAD application. This approach is quite popular, although a somewhat more complicated approach.
How to decide
So, we have trade-offs that can be resolved by knowing the number of simultaneous software users: when the total cost of the copies of the host CAD system does not exceed the cost of a custom application (with licenses for geometric kernel, visualization components, and 3D scene implementation), the plug-in is the cheaper option.
It’s worth noting that sometimes the cost of licensing the host application can be considered to be zero, because company engineers already use the software in their processes. In this case, a plug-in based on such a system possesses the additional benefit of fitting a familiar environment.
Thus, in our experience, plug-in solutions are quite popular for semi-automation of certain CAD-related processes performed by a small group of engineers, or else by a large group already using a suitable CAD system. Many of our digital medicine projects, for example, are in the form of plug-ins.
Conclusion
All in all, plug-in development is best suited for in-house applications where employees already use a specific CAD system. It significantly decreases the cost of development at the cost of needing to pay for licenses of the host software.
Permanent link :: http://isicad.net/articles.php?article_num=22122
|
