On 09/05/12 07:31, Chris Russ wrote:
> 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.
I'd suggest try making a simple program that splits itself in two,
and then simulates the bidirectional async behavior you want.
For instance, to simulate photoshop, make an image buffer,
and then try to share it between the two processes.
Try to simulate the different kinds of interactions; if you
need to simulate that PS always needs to get some cpu,
create a loop that simulates that (prints messages to the
console every second), but has some kind of way to interrupt
photoshop to check for things to do from the FLTK gui process.
I imagine PS might have a timer of some kind that you can
use to keep an eye on the pipe to see if new things to do
have come in from the FLTK process.
I use this sort of technique (a simple standalone tool)
to test system calls I've never worked with before;
it helps to have a small bit of code so that porting
becomes easy to manage, then once the code works on
the target platforms, rewrite it or fit it into the
final app as a separate pass at the code.
Basically, break everything into parts; perhaps start
with shared memory between two processes, then add
pipes/sockets/whatever, then a message queue between
the two processes, and tune it for keeping both sides
alive and non-blocking.
Sometimes a message queue can be as simple as a semaphore
and an array of strings in shared memory. (if you find
working with pipes or sockets are too hard).
> Also, I have absolutely no objections to contributing to the cause.
> I'm pretty sure that someone else should be testing and checking
> in any changes that are worthwhile keeping, though. :)
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
