Topic Mac Dev Mode
This board is threaded (i.e. has a tree structure). Please use the Reply button of the specific post you are referring to, not just any random button. If you want to reply to the topic in general, use the Post button near the top and bottom of the page.
In Response to Günther
Hm, nice, but:
- C4_OS is mostly used for the update package name. I still think we should ship a combined Linux 32+64 bit package, but given Macosx "universal binaries" we really should only ship one Macosx package. So that change doesn't help.
- I still disagree with the Execute/DoExecute stuff, the DrawableWindowContent, and a lot of other interface choices. These interfaces aren't the most sane to begin with, so we need to be careful with them ;-) Apparently, Cocoa wants to do stuff with C++ class instances, while Windows, GTK+ and X11 all use opaque handles (well, GTK uses not-so-opaque C objects, but one can ignore that). We tried to hide these behind the StdWindow class, but apart from some event delivery mechanisms for X11 the individual window types do not really share code. Unfortunately, I don't have a good idea how we can design something better without someone learning how all three platforms work. Maybe we can approach it from the Clonk side?
- I really think we should not attempt to share the code that currently is in C4WinMain.cpp between the platforms. CStdApp::RestartAtEnd is not a method we will ever need on Windows due to the way the upgrade has to work there, so it shouldn't be part of the common API. The common API is C4Application::Init, Run and Clear. Posix and Cocoa can share the restartAtEnd variable, but there's no reason to share more.
Maybe we should start by applying the patches to split the editor implementations into platform-specific files, the changes to the sound system, and the other Cocoa-unrelated changes you made. And then work on the interfaces for StdWindow and friends. After that, the Cocoa port should be mostly code additions, which are easy to check for changes to the common code, and we can just trust your choices for the Cocoa parts and merge. Sounds like a plan?
- C4_OS is mostly used for the update package name. I still think we should ship a combined Linux 32+64 bit package, but given Macosx "universal binaries" we really should only ship one Macosx package. So that change doesn't help.
- I still disagree with the Execute/DoExecute stuff, the DrawableWindowContent, and a lot of other interface choices. These interfaces aren't the most sane to begin with, so we need to be careful with them ;-) Apparently, Cocoa wants to do stuff with C++ class instances, while Windows, GTK+ and X11 all use opaque handles (well, GTK uses not-so-opaque C objects, but one can ignore that). We tried to hide these behind the StdWindow class, but apart from some event delivery mechanisms for X11 the individual window types do not really share code. Unfortunately, I don't have a good idea how we can design something better without someone learning how all three platforms work. Maybe we can approach it from the Clonk side?
- I really think we should not attempt to share the code that currently is in C4WinMain.cpp between the platforms. CStdApp::RestartAtEnd is not a method we will ever need on Windows due to the way the upgrade has to work there, so it shouldn't be part of the common API. The common API is C4Application::Init, Run and Clear. Posix and Cocoa can share the restartAtEnd variable, but there's no reason to share more.
Maybe we should start by applying the patches to split the editor implementations into platform-specific files, the changes to the sound system, and the other Cocoa-unrelated changes you made. And then work on the interfaces for StdWindow and friends. After that, the Cocoa port should be mostly code additions, which are easy to check for changes to the common code, and we can just trust your choices for the Cocoa parts and merge. Sounds like a plan?
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill