|
From: <tim...@en...> - 2007-06-06 15:59:56
|
> On Wednesday 06 June 2007 08:06, Timothée Lecomte wrote: >> >> The only solution I can think of (apart from recreating the windows one >> by >> one in the child process, which would cause an obvious flickering) is to >> fork before windows are created, i.e. *immediately* when gnuplot >> *starts*. >> Then have the parent process do nothing but wait for the child to tell >> him >> to exit. > > I have not been following this whole OSX debacle very closely, > but if I understand what you are saying then it seems to me that this > may introduce problems. Suppose that you have GNUTERM set to png or > pdf or something else on entry. This would be fairly normal for a > script. If you run this script under OSX, are you going to fork > off a child process even though it probably won't be needed? > Or do you rule out doing a "set term wxt" or "set term aqua" later > on? > > It might be better to simply accept that "persist" is not supported > on OSX. There are other ways to get the same behaviour now. > > Ethan If the user asks for 'gnuplot -persist', it probably means that he's going to use the interactive screen terminal... Anyway, there's no problem with GNUTERM=png or if the user don't use wxt at all. The child process will handle it fine, because it's exactly the same process as the parent would be if there were no "persist" option at all. Meanwhile, the parent process does nothing but waits so that we don't return to the shell immediately. And as a bonus note, even if the patch is restricted to wxt only, this implementation would also work for aqua ! It would also work for x11, and would have the advantage to give full mouse interaction instead of the current behaviour (only coordinated). Best regards, Timothée |