[SDL] Scrap for OSX (copy and paste)
ewmailing at gmail.com
Wed Dec 5 12:11:52 PST 2007
So .m is the extension used for Objective-C. (And .mm is the extension
used for Objective-C++.) Since I wrote the copy & paste code for OS X
in Cocoa, I used Objective-C which is the native language of Cocoa.
I intentionally separated the Cocoa implementation from the rest of
the code by placing it in scrap_OSX.m. The reason is pretty much the
same as why you would keep pure C code and C++ code separated. If you
take a pure C file, and put C++ only stuff in it, you now must compile
as C++ or you will get a compile error. And while some people have no
issues/reservations of simply making a former C file a C++ file and
changing the extension from .c to .cpp, unlike Objective-C which is at
least a pure superset of C, C++ creates a whole bunch of subtle
side-effects when compiling C code as C++.
Anyhow, you could use a bunch of #defines to guard the Objective-C
code inside main.c, but I don't recommend it. This means that when
compiling for a Mac, you must compile the file as Objective-C instead
of C. The easiest way of doing this is to rename the extension to .m,
but this will confuse/break things on other platforms that have no
idea what Objective-C is (e.g. Visual Studio). Or you could leave the
extension alone and tell your build system to compile as Objective-C,
but this requires that you tell your build system how to compile
something other than relying on the defaults. Xcode will let you do
this, but I suspect things would get harder when using alternative
build systems like autoconf, CMake, etc. (You could also flip-it so
that it always has the .m extension and tell the other compilers to
compile as C, but it's the same problem, but in reverse.)
I think this is more trouble than dealing with the separate files. So
I personally recommend you leave it as is, and structure your build
system to have a case that says, 'when on Mac, compile scrap_OSX.m,
otherwise compile scrap.c'.
The public interface is all pure-C, so scrap_OSX.m and scrap.c is just
an implementation detail. Your main code should never know/care how
the backend was implemented. You really shouldn't have any of this
platform specific stuff in your main.c.
By the way since you mention Linux, I was not able to fix up the copy
& paste code for X11 so it is still mostly/all of Sam's original code.
While I was able to fix up Windows and Mac, I couldn't figure out how
to get X11 to behave properly. I can't remember all the issues, but it
was something like...
- Can't copy text from my program to the clipboard (for other programs to read)
- Might be able to paste text into my program.
- There might be some big lags from when you copy/paste and when it
actually appears. I don't know why.
- I can't remember if I tried anything with images.
I tested Sam's code and some other pure X11 code I found and they
suffer the same problems on my system.
My system was running Linux with KDE, so it's possible that the X11
clipboard buffers Sam uses are different/incompatible with KDE. This
implies that maybe a KDE, Gnome, etc, native pasteboard implementation
needs to be developed sort of like how SDL handles the different sound
I don't know X11 or any of these other APIs, so I hit my limits in
trying to fix this up. Maybe some X11/KDE/Gnome gurus would like to
take a crack at this.
On 12/5/07, Josiah <ravean_uo at hotmail.com> wrote:
> E. Wing <ewmailing <at> gmail.com> writes:
> > Attached is my modified version. To compile on OS X, your build system
> > should skip the scrap.c and build scrap_OSX.m instead.
> > -Eric
> Quick question for you if you have a min. I am not familiar with .m files
> as your scrap_OSX.m. I do have it working by including it in my xcode
> but I would like to include it in my main.c. I use one code base for
> OSX and Linux. I have a define at the top of the code which I change for
> OS. I would like to be able to stick to this with the scrap_OSX.m as well.
> tried including it like I would a normal .c file but that did not work. Is
> there a way to include it from the main.c? Or make it a normal .c file
> of a .m? Pardon my ignorance, I just have not use .m files before, I
> they are for Mac OS which is probably why I have not been exposed to them.
> SDL mailing list
> SDL at lists.libsdl.org
More information about the SDL