On 09/04/12 12:11, Chris Russ wrote:
> But your approach is worth trying. I can spawn a new thread
> for the UI after copying the image out of Photoshop.
> Let me give that a shot.
Hi Chris,
Just clarifying: I'm not recommending a separate /thread/,
but rather a separate /process/.
Threads will share the same event queues and event libraries from the
OS,
and therefore a potential for contention over events and message queues
can occur
causing unpredictable behavior in one toolkit or the other, something
I'd think
you'd want to avoid.
I *think* any success you've had so far has more to do with luck
that the two toolkits don't immediately show confusion over events.
Both FLTK and PS's event loops will be contending over the same
events at times, so you really would want to avoid that, I'd think.
With separate processes, event queues will be entirely separate,
so there's no chance PS's event queue management conflicting with
FLTK's,
and no chance that internal changes to PS from one release to the next
would affect FLTK's event handling either.. only the DLL might have to
change.
For what I'm recommending, when your DLL initializes, it would
immediately
start a child 'helper' process that has all the FLTK code in it, and
from
there, all subsequent interaction between the DLL and FLTK be done via
bi-directional IPC (Inter-Process Control), using either
pipes/sockets/mmap,
the DLL acting as a "liaison" between PS and FLTK.
So event triggers from PS would send IPC messages to the FLTK process,
and vice-versa, clicks in the FLTK GUIs would send messages to the DLL
for PS to handle, the DLL acting as the arbitrator.
So in other words:
Photoshop Process | FLTK 'helper' process for the DLL
----------------------|-----------------------------------
|
PS |
\ |
your plugin <---|---> fltk-helper-process
| (child process of your plugin+PS)
|
> The problem appears to be one of re-entrancy.
You might be right about the re-entrant issues, but I think
a separate problem is purely a design issue; one should probably
avoid two different graphics toolkits running in the same process.
But I defer to others on the FLTK dev team, because I'm not as familiar
with the lower level FLTK event code as others on the team..
I'm more of a widget and systems programmer.
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
