This patch fixes one lingering problem with the 64-bit clipboard code; the way it was designed, the Mac clipboard was being cleared every time a single item was being requested by GetScrap, causing clipboards with multiple items to be unceremoniously whittled down to one. On the other hand, a similar issue was causing some items to get duplicated on the host pasteboard. This patch fixes the issue by making conversion between the host pasteboard and the Mac clipboard a singular operation; when the pasteboard data changes on the host side, it is all converted and sent to the Mac pasteboard at once, and similarly, all Mac clipboard data is sent to the host pasteboard in one operation. Also, data from the host side is copied to the Mac clipboard only if it has changed since the last check, which should improve performance as conversions will not be done over and over every time the Mac side checks whether the scrap has changed.
In addition, I've added a rudimentary PICT converter. It's rudimentary at the moment, only going in one direction, converting to PICT and not from PICT, and currently it always rasterizes the source image and creates a PICT containing bitmap data. However, it's a start, and it should solve Ronald's issue with copying images from OS X to Mac OS. In the future, more could possibly be added. I've put the new PICT code in the main source directory instead of in the MacOSX subdirectory, so that it can be used by other platforms if needed.
I would like to leave the license on the new PICT code as "Public Domain" if that is okay.
Thanks,
Charles
This patch adds support for international text to Basilisk II / SheepShaver's clipboard support. Text copied on the host side is converted from Unicode to the format that the classic Mac OS Script Manager expects, with localized font variants used if they are available on the emulated system (unfortunately, if a localized font is not available, the text will render incorrectly due to the nature of the Script Manager). When text is copied on the emulated system, the script of the current font is used to determine the encoding of the text, and it is converted to Unicode to be pasted on the host side.
This patch supports copying and pasting text containing multiple scripts; for example, "EnglishČeský日本語", where ranges (0, 7) and (8, 3) are Roman, (7, 1) and (11, 1) are Central European, and (12, 3) is Japanese, can be freely copied and pasted back and forth between the host and emulated platforms, provided that the emulated platform has localized Central European and Japanese fonts installed.
In order to get this to work, I rewrote pretty much all of clip_macosx64.mm. The code now completely uses the Cocoa framework rather than CoreFoundation and Pasteboard Manager. Because this API now uses the Mac OS X 10.6+ version of the pasteboard API, the minimum version of OS X supported by clip_macosx64.mm is now 10.6. I think this shouldn't be a problem, since the 32-bit version still exists, but if this version needs to support older releases, let me know and I can add version-check code to do so. One of the benefits of using the modern API, however, is that our rich-text format is no longer hard-coded to the RTF format, which means we have automatic support for any other format used by the OS X pasteboard system, which as of Lion seems to include RTF, UTF-16 text, UTF-8 text, 'ut16'/'ustl', and others, and which may be supplemented by other formats in future releases of OS X.
I hope you find this patch useful.
Charles
Added code to parse the Classic Mac OS 'styl' resources, allowing formatted text to be copied and pasted out of SheepShaver, not just plain text. In order to do this, I made some changes to the emul_op mechanism, patching ZeroScrap() in addition to the scrap methods that were already being patched. The reason for this is that since we need to read data from multiple items that are on the clipboard at once, we cannot simply assume a zero at the beginning of each PutScrap() operation.
This patch uses RTF to store styled text on the host side; unfortunately, since the APIs to convert to and from RTF data are in Cocoa but not in CoreFoundation, I had to write the new portions in Objective-C rather than C, and changed the extension from .cpp to .mm accordingly. In the future, if we are confident that this file will only be used on Mac OS X 10.6 and up, we can rewrite the Pasteboard Manager code to use NSPasteboardReading/Writing instead. This would allow us to read and write NSAttributedString objects directly to and from the pasteboard, which would make sure we were always using the OS's preferred rich text format internally instead of hard-coding it specifically to RTF as in the current implementation.
I believe that this patch should also fix the problem Ronald reported with copying accented characters.
Since I am new to 68k assembly and the emul_op mechanism, I would appreciate if someone could double-check all my changes to make sure that I have done everything correctly.
Thanks,
Charles
In file included from ../kpx_cpu/sheepshaver_glue.cpp:32:
In file included from ../kpx_cpu/src/cpu/ppc/ppc-cpu.hpp:24:
../kpx_cpu/include/basic-cpu.hpp:50:1: warning: struct 'task_struct' was previously declared as a class [-Wmismatched-tags]
struct task_struct;
^
../kpx_cpu/include/task-plugin.hpp:27:7: note: previous use is here
class task_struct;
^
In file included from ../kpx_cpu/sheepshaver_glue.cpp:32:
In file included from ../kpx_cpu/src/cpu/ppc/ppc-cpu.hpp:24:
../kpx_cpu/include/basic-cpu.hpp:52:1: warning: 'basic_cpu' defined as a struct here but previously declared as a class [-Wmismatched-tags]
struct basic_cpu
^
../kpx_cpu/include/task-plugin.hpp:29:1: note: did you mean struct here?
class basic_cpu;
^~~~~
struct
../kpx_cpu/sheepshaver_glue.cpp:725:13: warning: unused function 'dump_log' [-Wunused-function]
static void dump_log(void)
^
3 warnings generated.
Note: Checks for __LP64__ explicitly because build/host/target
all get reported as i686-apple-darwin10.8.0 (not x86_64).
Also fixes a compile warning in clip_macosx64.cpp.
+ Running autoheader: configure.ac:1393: warning: AC_CACHE_VAL(ac_cv_gcc_no_strict_aliasing, ...): suspicious presence of an AC_SUBST in the second argument, where no actions should be taken
4fb0f92aaf065276712a36cb169081ebc41eeeb4
From: Alexander von Gluck IV <kallisti5@unixzen.com>
Date: Sun, 17 Jun 2012 03:47:26 +0000
Subject: [PATCH] Haiku: Fix missing ;
28ff27fc3ae3878fe9ca589f3c55c4261814266a
From: Steven Noonan <steven@uplinklabs.net>
Date: Wed, 1 Jun 2011 01:34:07 -0700
Subject: [PATCH] configure.ac: fix TUN/TAP detection on Linux
Signed-off-by: Steven Noonan <steven@uplinklabs.net>
d4dc0c70b24dc5981e752403e8fe047637d712a1
From: Steven Noonan <steven@uplinklabs.net>
Date: Wed, 1 Jun 2011 17:48:33 -0700
Subject: [PATCH] configure.ac: enable JIT on 64-bit Intel Mac
Signed-off-by: Steven Noonan <steven@uplinklabs.net>
