Re: [Perlplusplugin-developers] authorization?
Status: Beta
Brought to you by:
fholtry
From: Dmitry K. <dk...@pl...> - 2000-09-16 15:01:07
|
Hi Frank! On 15 Sep 00 at 16:46, "Frank" (Frank Holtry) wrote: >> >> However, the subject of security itself is a tough one, so the real >> opsets and wrappers require thorough design. Frank> Do you think more needs to be done with opsets than what is Frank> currently in np_perl.h? And you say 'wrappers' as if more than one Frank> might be needed? The sequence of programs and modules involved are currently Prima-oriented, so to say. But I don't want to make the plugin working only with Prima - I want to keep it's current functionality, when non-gui scripts could be launched also. I have now only one wrapper - but it has 'nice GUI' and windows and all that stuff - but it requires Prima to be installed. Maybe the same thing will be written latter for Tk. The one I have written now, is rather toyish - since when subprogram fails, it analyzes the output and if it was sort of 'no package blabla found' it launches either CPAN or PPM gui setups with nice buttons and all that kind of stuff. But I'm afraid that if opcode-security scheme will be applied, I'll have to remove them... Frank> But if the Prima widgets are designed from the beginning to work Frank> with both a plugin and an external event loop, I think it would be Frank> a dynamite tool. I hope also! >> But, I read the plugin guide and it says that NPP_SetWindow is called ( >> in this case) with two different windows, so there's a moment when both >> old and new windows are alive? If it is so, then a blocking >> notification Frank> NPP_SetWindow( NPP instance, NPWindow * window) is what I have for Frank> the function, which only has one window pointer. It's possible the Frank> API changed so that both the about-to-be-destroyed window and the Frank> newly created window are available. Is yours different? No, I meant that when it's called, the instance have to compare old and new windows, ( the code from the samples, for example) to determine the action it should take. I thought it should be reasonable, that if netscape says 'go change from old window to new one' the old window should be accessible in some way. But even if it's not so, some notification on the window's own handler should be called before destroy process - in X, I think, it's DestroyNotify ( but it will be useful if only catched within the plugin, not from perl). >> And, what way did you signal the perl application? Frank> This is really the crux of the problem. I haven't found a good way Frank> to signal the application. The plugin itself is notified too late Frank> to provide a useful signal to the Perl application. You mean NPP_SetWindow here? Or DestroyNotify? It would be real bad if one couldn't reliably catch the Destroy event! But I doubt that such a mighty mouse as the X11 can't guarantee such a condition. btw - I'm planning rather not create hacks for Prima in a way it could communicate with plugin - I'd rather announce a hook for the inner event loop, which could be useful for all kind of stuff. If only that thing would be available in both tk and netscape! -- Sincerely, Dmitry |