> I've gotten approval from the bosses to attempt a two-part plug-in -- > first part that grabs the image, second part that does the processing/UI. > Now I have to do it. Doing it as a DLL is no biggie -- I've got a lot of > experience with that, but making part be stand-alone in a different > process, and yet not appear to be that way will be challenging. > Especially that yield portion (I'd have to go async between the two parts > so that the Photoshop stub continues to allow Photoshop to update). This > gets ugly fast.
OK - so here's my take on this; likely to be bogus and probably overly simplistic, so use with caution! I see two blobs of code here: Blob 1) Written in straight C, has no GUI elements and hopefully no other "awkward" dependencies. This becomes the PS plugin. Called by PS, and works the "pump" to keep the PS side of things going, e.g. driving the progress callbacks etc. On being invoked, this spawns Blob 2, and sets up whatever socket / pipe / shared mem is deemed best for communication between B1 and B2 here. Blob 2) Is a standalone exe that gets spawned by B1, and communicate with it. This is a static linked fltk GUI app that does... whatever your current GUI does, but with access via the IPC created by B1 rather than direct to the PS context. On termination, this signals B1 that it is closing, then simply terminates its process in the usual way. I strongly advocate static linking fltk for this to make it "immune" to any DLL issues. Since it runs in its own independent process space, this would be better anyway. Is that the sort of thing we are talking about here? Or do others have a different (better!) suggestion? > So here are my questions: > > a) Why does FLTK rely upon exit() on the way out? Does it? In what way? Why is that bad? Fltk takes advantage of the exit clean-up to tidy things away, but if you static link a "standalone" GUI as I suggest, then I can't see that would be a Bad Thing to do. > b) Does anyone have an idea about how to "save the state" of the GDI, > event handlers, and OpenGL so it could be easily restored? This might be > the other kind of solution. If you do not destroy the widgets created the first time through the DLL, but retain references to them but just hide them, then there's a fair chance (if the DLL is not unloaded) that their state will still be valid anyway, I think? Never tried that... That is, first time through we create the widgets and windows we need (with new so that they persist on the heap, nothing is created stack-automatic, and nothing is created static other than what flk has in the DLL). We stash the widget pointers somewhere that persists. Subsequent times through, we see that the pointers are set and we do not create the widgets again, we just re-show them, and cross our fingers that it Just Works. That said, going with the "standalone" GUI approach should make that irrelevant, I think? > c) Besides those in Fl_Devices.h, how many other classes have a persistent > static instantiation? And that's a hard one... Again, going the standalone GUI route probably makes that academic. That's what I've got, ideas wise. YMMV. SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England & Wales. Company no. 02426132 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
