A platform define for the Cocoa port?
Hi all, While working on the wx port, I've noticed there are a number of places where there are __APPLE__ defines that will conflict with the wxWidgets port because wxWidgets uses Carbon and so the Cocoa defines, native data types, etc. aren't appropriate in this case. What I was thinking is that we can add a PLATFORM(COCOA) define to Platform.h and define it when __OBJC__ and __APPLE__ are defined. Would this be an acceptable solution? This would still cause conflicts with our wxCocoa port, but unfortunately development work on that port has stalled so IMHO the conflict is not a major issue at the moment. Eventually, if we do move to support wxCocoa, we could add some __BUILDING_WXCOCOA define and check for that in Platform.h before defining KXMLCORE_PLATFORM_COCOA. Thoughts? Thanks, Kevin
On Jun 28, 2006, at 11:15 AM, Kevin Ollivier wrote:
While working on the wx port, I've noticed there are a number of places where there are __APPLE__ defines that will conflict with the wxWidgets port because wxWidgets uses Carbon and so the Cocoa defines, native data types, etc. aren't appropriate in this case.
What I was thinking is that we can add a PLATFORM(COCOA) define to Platform.h and define it when __OBJC__ and __APPLE__ are defined. Would this be an acceptable solution? This would still cause conflicts with our wxCocoa port, but unfortunately development work on that port has stalled so IMHO the conflict is not a major issue at the moment. Eventually, if we do move to support wxCocoa, we could add some __BUILDING_WXCOCOA define and check for that in Platform.h before defining KXMLCORE_PLATFORM_COCOA.
There should definitely be a platform for the version of WebKit that's built on top of AppKit; the original one that Apple ships and that we use for most of our day to day development. I'm not sure the name of it should be COCOA, though. We can discuss the best name for it. But this platform switch should not be based on the __OBJC__ define. That's only defined for Objective-C and Objective-C++ source files, but the "WebKit on AppKit" platform affects the C++ and plain C source files too. There are some source files where we need __OBJC__ checks, just so that we can compile them in pure C++ code, even on platforms that are using Objective-C. And there are some __OBJC__ checks in there that are just wrong and should instead be this new platform. So, lets come up with a name for the platform, lets start using it, but lets not use __OBJC__ to set its value. -- Darin
On Jun 28, 2006, at 11:15 AM, Kevin Ollivier wrote:
Hi all,
While working on the wx port, I've noticed there are a number of places where there are __APPLE__ defines that will conflict with the wxWidgets port because wxWidgets uses Carbon and so the Cocoa defines, native data types, etc. aren't appropriate in this case.
What I was thinking is that we can add a PLATFORM(COCOA) define to Platform.h and define it when __OBJC__ and __APPLE__ are defined. Would this be an acceptable solution? This would still cause conflicts with our wxCocoa port, but unfortunately development work on that port has stalled so IMHO the conflict is not a major issue at the moment. Eventually, if we do move to support wxCocoa, we could add some __BUILDING_WXCOCOA define and check for that in Platform.h before defining KXMLCORE_PLATFORM_COCOA.
Thoughts?
The intent is that PLATFORM(DARWIN) means core MacOS system facilities which would likely be used by any toolkit port on the Mac, and PLATFORM(MAC) means Cocoa/Aqua UI (and other higher-level Mac OS stuff). So PLATFORM(MAC) is intended to mean what you suggest for PLATFORM(COCOA), we just haven't deployed it everywhere yet. Regards, Maciej
Hi Maciej, On Jun 28, 2006, at 11:36 AM, Maciej Stachowiak wrote:
On Jun 28, 2006, at 11:15 AM, Kevin Ollivier wrote:
Hi all,
While working on the wx port, I've noticed there are a number of places where there are __APPLE__ defines that will conflict with the wxWidgets port because wxWidgets uses Carbon and so the Cocoa defines, native data types, etc. aren't appropriate in this case.
What I was thinking is that we can add a PLATFORM(COCOA) define to Platform.h and define it when __OBJC__ and __APPLE__ are defined. Would this be an acceptable solution? This would still cause conflicts with our wxCocoa port, but unfortunately development work on that port has stalled so IMHO the conflict is not a major issue at the moment. Eventually, if we do move to support wxCocoa, we could add some __BUILDING_WXCOCOA define and check for that in Platform.h before defining KXMLCORE_PLATFORM_COCOA.
Thoughts?
The intent is that PLATFORM(DARWIN) means core MacOS system facilities which would likely be used by any toolkit port on the Mac, and PLATFORM(MAC) means Cocoa/Aqua UI (and other higher-level Mac OS stuff). So PLATFORM(MAC) is intended to mean what you suggest for PLATFORM(COCOA), we just haven't deployed it everywhere yet.
But as I understand the code in Platform.h, platform Mac is defined whenever Darwin is defined, rather than being defined based on the toolkit used. Or do you mean that's what the define is supposed to be for, but that it is not currently correctly defined? Also, IMHO this is a bit confusing in that I typically think of Mac as an OS name, not a "port/toolkit" name. I think it might get confusing when debugging and auditing code that on OS X, PLATFORM (MAC) would be false when building the wx port (for example). Just by reading the code, I would interpret it as "the Mac platform" which means to me Mac OS X, regardless of what toolkit I'm working with. Same with PLATFORM(WIN). Even though I know what they are supposed to mean, they naturally read to me as "Win OS" or "Mac OS" and I have to mentally correct myself whenever I read them. If we want to keep the current naming system, what about having an OS (MAC) and PLATFORM(MAC) to differentiate? I think at this point every major OS has more than one WebKit "port" in progress for it, so I think we should differentiate port and OS as clearly as possible. Regards, Kevin
Regards, Maciej
participants (3)
-
Darin Adler
-
Kevin Ollivier
-
Maciej Stachowiak