Re: patch for fonts on Mac OS X

[Mojca M. <moj...@gm...>]

>> 2.) in plot.c:
>>
>> #if defined(_Windows) || defined(_Macintosh)
>> int
>> gnu_main(int argc, char **argv)
>> #else
>> int
>> main(int argc, char **argv)
>> #endif
>>
>> I don't understand what this does, but gnu_main is probably not needed
>> on Apple (modern Mac OS X), so "|| defined(_Macintosh)" may probably
>> go away if there is no code to support the old macintosh anyway.
>
> It's a compiler flag, not an OS flag.
> Given that the next line says "gnu_main", I imagine that it was an identifier
> defined by some version of gcc.   Whether the current version of gcc used on
> OSX has that same flag defined or not, I don't know.

I take my words back. Apparently Timothée really wanted to use this
for Mac OS X, judging from the message below. However, I have no idea
how the problem was fixed later and independent of that: the code
currently cannot be used since _Macintosh is not defined. I'm CC-ing
Adam who wrote some patches for wxt to comment on whether that
function might be needed or not.

(Maybe Adam also has some ideas if making Qt work without forking is
doable in the same way as wxt, but that's a completely separate and
very low priority issue.)

Mojca


PS: here's the thread

2007/4/28 Timothée Lecomte wrote:
> Timothée Lecomte wrote:
>>
>> Dear Mojca, Joe, and all gnuplot enthusiasts,
>>
>> Here are some news about the availability of the wxt terminal for the
>> MacOS platform. I have had the chance to get my hands on my MacBook and I
>> have worked a little bit on the issues you got when trying to use the wxt
>> terminal.
>>
>> (...)
>>
>>
>> So there is one remaining thing to try, but this will involve more work on
>> my part: changing the way wxt works on Unix and Mac and arrange it so that
>> the main thread runs the event loop while the usual gnuplot command-line
>> loop runs in the separate thread. The challenge is to do that only when
>> wxt_init() is called, not before (doing it at startup time is easy, but I
>> don't feel like it would be the right way).
>> (note that on Windows we don't have this problem because the fake terminal
>> already has the event loop and runs gnuplot command loop inside it)
>> (as far as aquaterm is concerned, it has another design again, something
>> like the X11 terminal: the GUI is in a different program with its own loop
>> and talking with gnuplot through some interprocess communication
>> mechanism)
>
>
> Hey people, here are some more news about "wxt on Mac". I've found some time
> yesterday to investigate a little further. I found that wxMac has some
> limitations :
>
> - the GUI thread (i.e. the one running the GUI event loop) has to be the
> main thread. I had some success making the second thread be the GUI one, but
> still a lot of issues come after that, because:
> - GUI calls should all be done in the same thread. With wxGTK, there's a
> mutex locking mechanism, but it seems that it's really not working on wxMac.
>
> So far, I was able to make wxt work by :
> -at startup, first initialize wxWidgets
> -create a second thread that run gnu_main (otherwise called main in plot.c)
> -start the event loop in the main thread
> and use messages to tell the GUI event loop to do something, instead of
> doing it directly in the second thread.
>
> (it may seem very close to a two process-scheme, such as what is done for
> the X11 terminal, but I don't want to have to deal with inter-process
> communication, or fork+exec for now ;)
>
> So, it's working !
>
> The drawback is that there will be problems if, one day, we want to do, for
> example, a GTK terminal with a similar design... there may be some sort of
> clash between the two wanting for their main loop be in the main thread...
> but that day is probably quite far !
>
> I'll be cleaning up the corresponding patch in the next days if I have some
> time again, and I'll send it to the list as soon as it's ready.
>
> Best regards,
>
> Timothée