Subject:
|
Re: Suggestion for MLCad Plug-Ins
|
Newsgroups:
|
lugnet.cad.mlcad
|
Date:
|
Fri, 7 Jan 2000 19:21:30 GMT
|
Viewed:
|
1877 times
|
| |
|
|
Michael Lachmann <m.lachmann@xpoint.at> wrote in message
news:FnyBpI.5HD@lugnet.com...
> I must say, until now I never played around with plug-ins at all, so there
> goes my expirence with such things :-(
In my other life, I write what is essentially a plug-in for mechanical CAD
systems. I also use plug-ins in other applications, like PageMaker. The
common theme in all of these is a way to access some published API or data
structure of the application. The better the API, the more powerful the
plug-ins.
I don't think that a standard plug-in format for many systems is
appropriate, unless it is very limited. And I don't want to see them very
limited, so I wouldn't want to vote for this (if it was a democracy, which
it is not). However, I recognize the power of the common data file format
(dat) that we have now. As has been discussed, if we lose that, we lose a
lot of power of our efforts. So your initial suggestion, that plug-ins be
limited to manipulating dat files, is certainly the lowest common
denominator. But it limits plug-ins to being dat file filters.
But I think to make this really sing, we will eventually be asking for:
1. Event-based notification. Things like opening, saving, etc. that allow
the plug-in to take part in various processes.
2. Render pipeline. Allow plug-ins to participate in the render in some
way. For example, a plug-in that allows dynamic 3D rotation of the part,
like most CAD systems. Or allows plug-in "owned" stuff to be rendered in a
unique way.
3. UI enhancement. Allow plug-ins to add to menus and toolbars. Allow
plugs to add "right click" items on objects.
Don't get me wrong, I am all for even the minimal file filter stuff. There
are many things I can do even with that level of ability, and it certainly
is a good first step. But while you are enhancing things, it sometimes
helps to have ideas on what is down the road, so I mention them here.
As an aside, your biggest problem will be keeping plug-ins out of each
others hair -- plan for lots of plug-ins from the beginning.
So. When do we get 1.8? ;-)
--Jack Gregory
|
|
Message has 1 Reply:
 | | Re: Suggestion for MLCad Plug-Ins
|
| Sorry for the delayed reply. I agree that plug-ins should have more functionallity than just playing the roole of a format converter. What I could imagine is chaining the plug-in into the read processing of a dat/mpd file, that allowing the plug-in (...) (25 years ago, 12-Jan-00, to lugnet.cad.mlcad)
|
Message is in Reply To:
| | Re: Suggestion for MLCad Plug-Ins
|
| I'm happy to hear the general agreement for plug-ins. I agree defining a standard, valid for other programs too, would be the best scenario. The idea to choin the plug-in into the rendering pipe-line is a good idea, but has to be well defined. I (...) (25 years ago, 7-Jan-00, to lugnet.cad.mlcad)
|
18 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
