[SDL] Scrap for OSX (copy and paste)

E. Wing 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
> such
> as your scrap_OSX.m.  I do have it working by including it in my xcode
> project,
> but I would like to include it in my main.c.  I use one code base for
> Windows,
> OSX and Linux.  I have a define at the top of the code which I change for
> each
> OS.  I would like to be able to stick to this with the scrap_OSX.m as well.
> I
> 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
> instead
> of a .m?  Pardon my ignorance, I just have not use .m files before, I
> understand
> they are for Mac OS which is probably why I have not been exposed to them.
> Thanks,
> Josiah
> _______________________________________________
> SDL mailing list
> SDL at lists.libsdl.org
> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

More information about the SDL mailing list