To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.cad.mlcadOpen lugnet.cad.mlcad in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 CAD / MLCad / 90
89  |  91
Subject: 
Re: Suggestion for MLCad Plug-Ins
Newsgroups: 
lugnet.cad.mlcad
Date: 
Fri, 7 Jan 2000 19:21:30 GMT
Viewed: 
1676 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 (...) (24 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 (...) (24 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
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR