Menu
▾
▴
basilisk-devel
|
From: Jean-Pierre <cho...@fr...> - 2012-06-18 17:38:43
|
Le 18 juin 2012 à 15:04, Ronald P. Regensburg a écrit : > It would be nice to be able to copy and paste graphics between emulator and host, but I would rather see that efforts are directed first to clipboard integration for text. As it is now in SheepShaver on OSX, clipboard integration for text does not work at all in 64-bit mode and only works with severe limitations in 32-bit mode. I wrote a small patch to exchange text clipboard for the Mac OS X 64bit version when I worked on the 64bit Mach-O support, but It was never merged.Not sure if I ever submitted it either... If you want it let me know. -JP. |
|
From: Robert M. <mr...@gm...> - 2012-06-18 18:05:26
|
Wow, Frank, this is cool! I love being wrong this way. (I feel like if I keep saying things that I hate about Apple, you'll keep telling me I'm wrong :-) I found some examples of people booting Lion in 32-bit mode: https://discussions.apple.com/thread/3225388?start=0&tstart=0 https://discussions.apple.com/thread/3943837?start=0&tstart=0 So does that mean we can boot Lion in 32-bit mode and run 32-bit SheepShaver and get a working copy and paste? I hope so... then maybe I'll actually try out that copy of Lion I bought last winter for $30. PICT files and SheepShaver cut/paste were holding me back. (Also the lack of Save and Revert commands in the standard suite, what were they thinking? Oops, I'm complaining again. Please tell me I'm wrong.) On 6/18/12, Frank Trampe <fra...@gm...> wrote: > Not exactly. Certain kernel-related things must run in 64-bit mode, but > there is still i386 support. > > { > cambridge:~ admin$ uname -v > Darwin Kernel Version 11.4.0: Mon Apr 9 19:32:15 PDT 2012; > root:xnu-1699.26.8~1/RELEASE_X86_64 > cambridge:~ admin$ file /mach_kernel > /mach_kernel: Mach-O universal binary with 2 architectures > /mach_kernel (for architecture x86_64): Mach-O 64-bit executable x86_64 > /mach_kernel (for architecture i386): Mach-O executable i386 > } -- Robert Munafo -- mrob.com Follow me at: gplus.to/mrob - fb.com/mrob27 - twitter.com/mrob_27 - mrob27.wordpress.com - youtube.com/user/mrob143 - rilybot.blogspot.com |
|
From: Ronald P. R. <ron...@xs...> - 2012-06-18 19:01:00
|
Op 18 jun. 2012, om 20:05 heeft Robert Munafo het volgende geschreven: > So does that mean we can boot Lion in 32-bit mode and run 32-bit > SheepShaver and get a working copy and paste? > I can run SheepShaver fine in 32-bit mode in Lion, booted into 64-bit mode. That is true for all applications (also many of Apple's own applications) that are built for both i386 and x86_64 architectures. One can choose to run an application in either 32-bit or 64-bit mode in Finder Info for the app. With SheepShaver running in 32-bit mode, one can copy and paste text between MacOS and OSX, with limitations. I do agree, though, that working on 64-bit SheepShaver (and BasiliskII) is essential for maintaining compatibility with future OSX versions. Ronald P. Regensburg. |
|
From: C.W. B. <com...@ho...> - 2012-06-18 23:03:06
|
Just to clarify, you can run 32-bit apps under a 64-bit kernel under OS X. For instance, I have Skype running on my 64-bit kernel Lion installation and that is only 32-bit right now. You can't run 32-bit Kernel Extensions on a 64-bit kernel, though. The reverse is also true: You can run 64-bit apps on a 32-bit Mac kernel (If you have a 64-bit processor). My server, a 2007 Mac mini is unable to boot into 64-bit kernel mode but still runs 64-bit programs just fine. On Jun 18, 2012, at 12:05 PM, Robert Munafo wrote: > Wow, Frank, this is cool! I love being wrong this way. > > (I feel like if I keep saying things that I hate about Apple, you'll > keep telling me I'm wrong :-) > > I found some examples of people booting Lion in 32-bit mode: > > https://discussions.apple.com/thread/3225388?start=0&tstart=0 > https://discussions.apple.com/thread/3943837?start=0&tstart=0 > > So does that mean we can boot Lion in 32-bit mode and run 32-bit > SheepShaver and get a working copy and paste? > > I hope so... then maybe I'll actually try out that copy of Lion I > bought last winter for $30. PICT files and SheepShaver cut/paste were > holding me back. (Also the lack of Save and Revert commands in the > standard suite, what were they thinking? Oops, I'm complaining again. > Please tell me I'm wrong.) > > On 6/18/12, Frank Trampe <fra...@gm...> wrote: >> Not exactly. Certain kernel-related things must run in 64-bit mode, but >> there is still i386 support. >> >> { >> cambridge:~ admin$ uname -v >> Darwin Kernel Version 11.4.0: Mon Apr 9 19:32:15 PDT 2012; >> root:xnu-1699.26.8~1/RELEASE_X86_64 >> cambridge:~ admin$ file /mach_kernel >> /mach_kernel: Mach-O universal binary with 2 architectures >> /mach_kernel (for architecture x86_64): Mach-O 64-bit executable x86_64 >> /mach_kernel (for architecture i386): Mach-O executable i386 >> } > > -- > Robert Munafo -- mrob.com > Follow me at: gplus.to/mrob - fb.com/mrob27 - twitter.com/mrob_27 - > mrob27.wordpress.com - youtube.com/user/mrob143 - rilybot.blogspot.com > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > basilisk-devel mailing list > bas...@li... > https://lists.sourceforge.net/lists/listinfo/basilisk-devel > |
|
From: Charles S. <bas...@ch...> - 2012-06-18 18:26:50
|
On Jun 18, 2012, at 1:05 PM, Robert Munafo wrote: > So does that mean we can boot Lion in 32-bit mode and run 32-bit > SheepShaver and get a working copy and paste? You can’t boot Lion into 32-bit mode, but you don’t have to. 64-bit Lion can run 32-bit i386 apps (but not PowerPC apps) just fine. > I hope so... then maybe I'll actually try out that copy of Lion I > bought last winter for $30. PICT files and SheepShaver cut/paste were > holding me back. (Also the lack of Save and Revert commands in the > standard suite, what were they thinking? Oops, I'm complaining again. > Please tell me I'm wrong.) Don’t upgrade to Lion now. Mountain Lion is coming out in probably less than a month. It’s *much* improved, although I can’t disclose how or why because of NDA. But you should definitely upgrade to Mountain Lion rather than Lion. Charles |
|
From: Robert M. <mr...@gm...> - 2012-06-18 18:43:13
|
So noted. I'm definitely going to buy Mountain Lion. I mainly only bought Lion so I'd have it in the future in case I need to do some testing. On 6/18/12, Charles Srstka <bas...@ch...> wrote: > Don’t upgrade to Lion now. Mountain Lion is coming out in probably less than > a month [...] you should definitely upgrade to Mountain Lion rather than > Lion. -- Robert Munafo -- mrob.com Follow me at: gplus.to/mrob - fb.com/mrob27 - twitter.com/mrob_27 - mrob27.wordpress.com - youtube.com/user/mrob143 - rilybot.blogspot.com |
|
From: Frank T. <fra...@gm...> - 2012-06-18 18:27:32
|
On Mon, Jun 18, 2012 at 1:05 PM, Robert Munafo <mr...@gm...> wrote: > Wow, Frank, this is cool! I love being wrong this way. > > (I feel like if I keep saying things that I hate about Apple, you'll > keep telling me I'm wrong :-) > > If you complained about the sharp-edged aluminum casings that scratch themselves and other things at the slightest provocation or about the inconsistency of Apple's update packaging or about how Apple intentionally accelerates the depreciation of its products so as to shorten purchase cycles, I would not tell you that you're wrong. There are plenty of absolutely awful things that Apple does. If you are using an Apple product as something other than a disposable consumer product, you will be disappointed quite often. > I found some examples of people booting Lion in 32-bit mode: > > https://discussions.apple.com/thread/3225388?start=0&tstart=0 > https://discussions.apple.com/thread/3943837?start=0&tstart=0 > > So does that mean we can boot Lion in 32-bit mode and run 32-bit > SheepShaver and get a working copy and paste? > > 32-bit applications can run even when the kernel is running in 64-bit mode. This does not work for certain things like drivers, but it ought to work for anything that you would put into the Applications folder. A Mach-O package can hold code for multiple architectures, and most of the Lion libraries have 32-bit and 64-bit code. If you run a 32-bit application, it calls stuff from the 32-bit code in the libraries. This is why mach_kernel on Snow Leopard had PowerPC code, for example. > I hope so... then maybe I'll actually try out that copy of Lion I > bought last winter for $30. PICT files and SheepShaver cut/paste were > holding me back. I am not sure of whether that works when running the operating system in 64-bit mode, but it is worth a try. > (Also the lack of Save and Revert commands in the > standard suite, what were they thinking? Oops, I'm complaining again. > Please tell me I'm wrong.) > Standard suite? You mean the things like TextEdit? > > On 6/18/12, Frank Trampe <fra...@gm...> wrote: > > Not exactly. Certain kernel-related things must run in 64-bit mode, but > > there is still i386 support. > > > > { > > cambridge:~ admin$ uname -v > > Darwin Kernel Version 11.4.0: Mon Apr 9 19:32:15 PDT 2012; > > root:xnu-1699.26.8~1/RELEASE_X86_64 > > cambridge:~ admin$ file /mach_kernel > > /mach_kernel: Mach-O universal binary with 2 architectures > > /mach_kernel (for architecture x86_64): Mach-O 64-bit executable x86_64 > > /mach_kernel (for architecture i386): Mach-O executable i386 > > } > > -- > Robert Munafo -- mrob.com > Follow me at: gplus.to/mrob - fb.com/mrob27 - twitter.com/mrob_27 - > mrob27.wordpress.com - youtube.com/user/mrob143 - rilybot.blogspot.com > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > basilisk-devel mailing list > bas...@li... > https://lists.sourceforge.net/lists/listinfo/basilisk-devel > |
|
From: Nigel P. <ni...@in...> - 2012-06-18 23:35:45
|
On 19/06/2012, at 4:27 AM, Frank Trampe wrote: > > If you complained about the sharp-edged aluminum casings that scratch themselves and other things at the slightest provocation I actually like the sharp edges on my MB Air - often rub a finger along it in-between typing! There is a slight ding on one edge, but it can easily be filed or sanded off, and you get used to disposability on portable computers. I do wish a lot of things in the OS were still like they were in 10.3.9 days, though. -- Nigel Pearson |"Now the world has gone to bed.| ni...@in... | Darkness won't engulf my head.| Telstra Sydney Australia| I can see by infrared. | 8576 5449, fax 9298 9033| How I hate the night." -Marvin| |
|
From: Robert M. <mr...@gm...> - 2012-06-18 18:39:03
|
In my scientific apps, written by me and running within SheepShaver, the clipboard PICT data includes a label with important information as text strings (DrawString). These label text strings need to survive the transfer to the host OS in order for cut/paste to be useful. There are many other cases of real users transferring object-based (i.e. not bitmap) PICT data between MacOS classic applications via cut and paste. On 6/18/12, Charles Srstka <bas...@ch...> wrote: > But this is only for pasteboard support between the emulated and host > systems, right? Do we really need 100% compatibility for that? As long as a > PICT image on the emulated pasteboard gets translated to a TIFF or PNG or > something on the host pasteboard and vice-versa 99% of the time, any rare > corner cases should be only a minor inconvenience. -- Robert Munafo -- mrob.com Follow me at: gplus.to/mrob - fb.com/mrob27 - twitter.com/mrob_27 - mrob27.wordpress.com - youtube.com/user/mrob143 - rilybot.blogspot.com |
|
From: Robert M. <mr...@gm...> - 2012-06-18 18:40:27
|
On 6/18/12, Jean-Pierre <cho...@fr...> wrote: > I wrote a small patch to exchange text clipboard for the Mac OS X 64bit > version when I worked on the 64bit Mach-O support, but It was never > merged.Not sure if I ever submitted it either... > If you want it let me know. Yes, that would be great! Handling text-only clipboard transfer is a very good first step. It will benefit a lot of end-users. -- Robert Munafo -- mrob.com Follow me at: gplus.to/mrob - fb.com/mrob27 - twitter.com/mrob_27 - mrob27.wordpress.com - youtube.com/user/mrob143 - rilybot.blogspot.com |
|
From: Charles S. <bas...@ch...> - 2012-06-18 18:44:35
|
On Jun 18, 2012, at 1:38 PM, Robert Munafo wrote: > In my scientific apps, written by me and running within SheepShaver, > the clipboard PICT data includes a label with important information as > text strings (DrawString). These label text strings need to survive > the transfer to the host OS in order for cut/paste to be useful. > > There are many other cases of real users transferring object-based > (i.e. not bitmap) PICT data between MacOS classic applications via cut > and paste. Are there any OS X / Windows apps that currently accept pasteboard data in PICT format though? Charles |
|
From: Robert M. <mr...@gm...> - 2012-06-18 19:05:25
|
On 6/18/12, Charles Srstka <bas...@ch...> wrote: > Are there any OS X / Windows apps that currently accept pasteboard data in > PICT format though? No, that's why SheepShaver converts it. Here are the steps, to make it clear: 1. I start SheepShaver, and start my old app within SheepShaver. 2. Copy to clipboard. 3. Switch to Snow Leopard's TextEdit, hit Paste. 4. I get my image, with the original bitmap image and the label text nicely rendered below it. Somewhere in the process (SheepShaver and/or TextEdit) it has turned the PICT, including the label text, into a TIFF image. The text is there because something in the Carbon libraries is making it happen. But it we use that stand-alone PICT conversion library instead of Carbon, the text label would be missing. -- Robert Munafo -- mrob.com Follow me at: gplus.to/mrob - fb.com/mrob27 - twitter.com/mrob_27 - mrob27.wordpress.com - youtube.com/user/mrob143 - rilybot.blogspot.com |
|
From: C.W. B. <mad...@gm...> - 2012-06-18 23:08:56
|
Actually, it's probably happening in the pasteboard server. The Cocoa pasteboard can have multiple types of data in it, and some formats can be converted natively under Cocoa. In fact, the gimp-macclipboard did this to convert TIFFs to PICTs. On Jun 18, 2012, at 1:05 PM, Robert Munafo wrote: > On 6/18/12, Charles Srstka <bas...@ch...> wrote: >> Are there any OS X / Windows apps that currently accept pasteboard data in >> PICT format though? > > No, that's why SheepShaver converts it. Here are the steps, to make it clear: > > 1. I start SheepShaver, and start my old app within SheepShaver. > 2. Copy to clipboard. > 3. Switch to Snow Leopard's TextEdit, hit Paste. > 4. I get my image, with the original bitmap image and the label text > nicely rendered below it. > > Somewhere in the process (SheepShaver and/or TextEdit) it has turned > the PICT, including the label text, into a TIFF image. > > The text is there because something in the Carbon libraries is making > it happen. But it we use that stand-alone PICT conversion library > instead of Carbon, the text label would be missing. > > -- > Robert Munafo -- mrob.com > Follow me at: gplus.to/mrob - fb.com/mrob27 - twitter.com/mrob_27 - > mrob27.wordpress.com - youtube.com/user/mrob143 - rilybot.blogspot.com > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > basilisk-devel mailing list > bas...@li... > https://lists.sourceforge.net/lists/listinfo/basilisk-devel > |
|
From: Jean-Pierre <cho...@fr...> - 2012-06-18 19:50:15
Attachments:
clip_macosx.cpp
|
Le 18 juin 2012 à 20:40, Robert Munafo a écrit : > On 6/18/12, Jean-Pierre <cho...@fr...> wrote: >> I wrote a small patch to exchange text clipboard for the Mac OS X 64bit >> version when I worked on the 64bit Mach-O support, but It was never >> merged.Not sure if I ever submitted it either... >> If you want it let me know. > > Yes, that would be great! > > Handling text-only clipboard transfer is a very good first step. It > will benefit a lot of end-users. Here you are. It's still incomplete, but it could be a good start for sharing pictures as well. Best regards, -JP. |
|
From: Alexei S. <ale...@gm...> - 2012-06-19 13:23:24
|
On Mon, Jun 18, 2012 at 3:50 PM, Jean-Pierre <cho...@fr...> wrote: > Here you are. > > It's still incomplete, but it could be a good start for sharing pictures > as well. > > Best regards, > Hey, Nice work! Would you be willing to clean up the patch a little and re-send it (on a separate thread or via GitHub) for inclusion upstream? Here are some of my thoughts on a couple of things that could be cleaned up: - indentation is inconsistent throughout - _CARBON_BUILD_ stuff: I understand that the purpose is to have separate the two codepaths - but my question is: Is there anything preventing switching completely to the new path that you've implemented? If it has feature parity with the old code, we don't need to keep the old code around. I'm looking forward to landing these changes upstream. Thanks! -Alexei |
|
From: Robert M. <mr...@gm...> - 2012-06-18 20:48:15
|
I'll take a look at it, thanks! Why is there "#ifndef _CARBON_BUILD_" around the "#include <Carbon/Carbon.h>" ? Isn't that backwards? (The rest of the ifdefs seem right though) On 6/18/12, Jean-Pierre <cho...@fr...> wrote: > Le 18 juin 2012 à 20:40, Robert Munafo a écrit : >> Handling text-only clipboard transfer is a very good first step. It >> will benefit a lot of end-users. > > Here you are. > > It's still incomplete, but it could be a good start for sharing pictures as > well. > > Best regards, > > -JP. -- Robert Munafo -- mrob.com Follow me at: gplus.to/mrob - fb.com/mrob27 - twitter.com/mrob_27 - mrob27.wordpress.com - youtube.com/user/mrob143 - rilybot.blogspot.com |
|
From: Jean-Pierre <cho...@fr...> - 2012-06-18 21:02:41
|
Le 18 juin 2012 à 22:48, Robert Munafo a écrit : > I'll take a look at it, thanks! > > Why is there "#ifndef _CARBON_BUILD_" around the "#include > <Carbon/Carbon.h>" ? Isn't that backwards? (The rest of the ifdefs > seem right though) Carbon API does not exist for x86_64 code in Mac OS X, this was the reason of my patch, as I was working on the 64 bit part of Mach-O JIT code and this file couldn't compile. I guess this macro is defined somewhere when you add the Carbon Framework. I don't remember how I did, this was too many years ago. ;) -JP. |
|
From: Charles S. <bas...@ch...> - 2012-06-18 20:51:57
|
On Jun 18, 2012, at 2:05 PM, Robert Munafo wrote:
> On 6/18/12, Charles Srstka <bas...@ch...> wrote:
>> Are there any OS X / Windows apps that currently accept pasteboard data in
>> PICT format though?
>
> No, that's why SheepShaver converts it. Here are the steps, to make it clear:
>
> 1. I start SheepShaver, and start my old app within SheepShaver.
> 2. Copy to clipboard.
> 3. Switch to Snow Leopard's TextEdit, hit Paste.
> 4. I get my image, with the original bitmap image and the label text
> nicely rendered below it.
>
> Somewhere in the process (SheepShaver and/or TextEdit) it has turned
> the PICT, including the label text, into a TIFF image.
>
> The text is there because something in the Carbon libraries is making
> it happen. But it we use that stand-alone PICT conversion library
> instead of Carbon, the text label would be missing.
Out of curiosity, would you mind trying -[NSImage imageWithData:] on one of your PICT files with the text label? I am curious whether NSImage preserves the label text or not.
Here’s the code for a minimal PICT viewer app:
@interface Document ()
@property (copy) NSImage *image;
@end
@implementation Document
@synthesize image = _image;
- (NSString *)windowNibName {
return @"Document";
}
+ (BOOL)autosavesInPlace {
return NO;
}
- (NSData *)dataOfType:(NSString *)typeName error:(NSError **)outError {
NSException *exception = [NSException exceptionWithName:@"UnimplementedMethod" reason:[NSString stringWithFormat:@"%@ is unimplemented", NSStringFromSelector(_cmd)] userInfo:nil];
@throw exception;
return nil;
}
- (BOOL)readFromData:(NSData *)data ofType:(NSString *)typeName error:(NSError **)outError {
self.image = [[NSImage alloc] initWithData:data];
if(self.image == nil) {
if(outError) *outError = [NSError errorWithDomain:NSCocoaErrorDomain code:NSFileReadUnknownError userInfo:nil];
return NO;
}
return YES;
}
- (IBAction)convertToTIFF:(id)sender {
NSSavePanel *sp = [NSSavePanel savePanel];
sp.allowedFileTypes = [NSArray arrayWithObject:(__bridge NSString *)kUTTypeTIFF];
[sp beginSheetModalForWindow:self.windowForSheet completionHandler:^(NSInteger result) {
if(result != NSFileHandlingPanelOKButton) {
return;
}
NSError *error = nil;
if(![self.image.TIFFRepresentation writeToURL:sp.URL options:NSDataWritingAtomic error:&error]) {
[self presentError:error];
}
}];
}
@end
If you don’t have the dev tools installed or would just prefer for me to send me a binary, let me know.
Thanks,
Charles
|
|
From: Robert M. <mr...@gm...> - 2012-06-18 21:14:02
|
I have Xcode 3.2.6 on both of my Snow Leopard machines, but I'll need instructions on how to create the project and where to put the missing main() routine, and/or how to compile it from the command line with /usr/bin/xcodebuild. I tried making a new project from templates "Cocoa Application" and "Quick Look Plug-In", but your code doesn't seem to fit into either of those. (Anyone else aside from Charles, feel free to clue me in. I don't mind looking foolish :-) On 6/18/12, Charles Srstka <bas...@ch...> wrote: > Out of curiosity, would you mind trying -[NSImage imageWithData:] on one of > your PICT files with the text label? I am curious whether NSImage preserves > the label text or not. > > Here’s the code for a minimal PICT viewer app: > [...] > > If you don’t have the dev tools installed or would just prefer for me to > send me a binary, let me know. -- Robert Munafo -- mrob.com Follow me at: gplus.to/mrob - fb.com/mrob27 - twitter.com/mrob_27 - mrob27.wordpress.com - youtube.com/user/mrob143 - rilybot.blogspot.com |
|
From: Charles S. <bas...@ch...> - 2012-06-18 21:24:26
|
On Jun 18, 2012, at 4:13 PM, Robert Munafo wrote: > I have Xcode 3.2.6 on both of my Snow Leopard machines, but I'll need > instructions on how to create the project and where to put the missing > main() routine, and/or how to compile it from the command line with > /usr/bin/xcodebuild. > > I tried making a new project from templates "Cocoa Application" and > "Quick Look Plug-In", but your code doesn't seem to fit into either of > those. > > (Anyone else aside from Charles, feel free to clue me in. I don't mind > looking foolish :-) You just paste it into the Document-Based Application template. Then, you put an NSImageView in the .xib file and bind it to the “image” property on File’s Owner, and put in a button, menu item, whatever you please, and bind it to -convertToTIFF: either on File’s Owner or on First Responder. However, the snippet I posted was ARC, which Xcode 3 doesn’t support, so you’ll want to stick a release after assigning self.image, in order to avoid a memory leak. I should have thought of that, since you already mentioned you were on Snow Leopard. Sorry about that. I can just send you a binary if you want; send me a message off-list if you want me to. Charles |
|
From: Charles S. <bas...@ch...> - 2012-06-18 21:38:40
|
On Jun 18, 2012, at 4:24 PM, Charles Srstka wrote: > On Jun 18, 2012, at 4:13 PM, Robert Munafo wrote: > >> I have Xcode 3.2.6 on both of my Snow Leopard machines, but I'll need >> instructions on how to create the project and where to put the missing >> main() routine, and/or how to compile it from the command line with >> /usr/bin/xcodebuild. >> >> I tried making a new project from templates "Cocoa Application" and >> "Quick Look Plug-In", but your code doesn't seem to fit into either of >> those. >> >> (Anyone else aside from Charles, feel free to clue me in. I don't mind >> looking foolish :-) > > You just paste it into the Document-Based Application template. Then, you put an NSImageView in the .xib file and bind it to the “image” property on File’s Owner, and put in a button, menu item, whatever you please, and bind it to -convertToTIFF: either on File’s Owner or on First Responder. > > However, the snippet I posted was ARC, which Xcode 3 doesn’t support, so you’ll want to stick a release after assigning self.image, in order to avoid a memory leak. I should have thought of that, since you already mentioned you were on Snow Leopard. Sorry about that. Oh, one other change you’ll have to make for Xcode 3 is to stick a declaration for the -convertToTIFF: method in the header file; otherwise Interface Builder probably won’t see it. As for main(), there’s rarely anything in there in a Cocoa app. Typically it’s just one line that calls NSApplicationMain() and returns the result. The framework handles all the actual initialization stuff. Charles |
|
From: Alexei S. <ale...@gm...> - 2012-06-18 22:52:32
|
On Mon, Jun 18, 2012 at 2:38 PM, Robert Munafo <mr...@gm...> wrote: > In my scientific apps, written by me and running within SheepShaver, > the clipboard PICT data includes a label with important information as > text strings (DrawString). These label text strings need to survive > the transfer to the host OS in order for cut/paste to be useful. > Assuming there's no good open source library to handle arbitrary PICT data, the solution here would be to add some functionality to TESyncScrap or a similar extension that would intercept clipboard data on the guest OS side and when it's a PICT, rasterize it into PICT bitmap-only data, putting that back on the guest clipboard. Then, when SheepShaver gets that data, the PICTs will be guaranteed to only have bitmap data, which could be handled by paintlib (or possibly even some simpler code we can just write for SheepShaver) which would then be easily convertible to the host OS clipboard format. This solution would then work cross-platform, instead of being tied to Mac OS X as the host. -Alexei |
|
From: Charles S. <bas...@ch...> - 2012-06-18 22:57:13
|
On Jun 18, 2012, at 5:51 PM, Alexei Svitkine wrote: > On Mon, Jun 18, 2012 at 2:38 PM, Robert Munafo <mr...@gm...> wrote: > In my scientific apps, written by me and running within SheepShaver, > the clipboard PICT data includes a label with important information as > text strings (DrawString). These label text strings need to survive > the transfer to the host OS in order for cut/paste to be useful. > > Assuming there's no good open source library to handle arbitrary PICT data, the solution here would be to add some functionality to TESyncScrap or a similar extension that would intercept clipboard data on the guest OS side and when it's a PICT, rasterize it into PICT bitmap-only data, putting that back on the guest clipboard. > > Then, when SheepShaver gets that data, the PICTs will be guaranteed to only have bitmap data, which could be handled by paintlib (or possibly even some simpler code we can just write for SheepShaver) which would then be easily convertible to the host OS clipboard format. > > This solution would then work cross-platform, instead of being tied to Mac OS X as the host. Alternatively, depending on how well the NSImage-based functionality turns out to work for Robert’s specialized PICT files, we could use the host OS functionality on OS X, and use the libpaint/other library/homespun code for the other targets, which would result in one less library requirement for the OS X port, which is nice. Charles |
|
From: Josh J. <jj...@gm...> - 2012-06-19 01:06:59
|
On Jun 18, 2012, at 3:51 PM, Alexei Svitkine wrote: > On Mon, Jun 18, 2012 at 2:38 PM, Robert Munafo <mr...@gm...> > wrote: > >> In my scientific apps, written by me and running within SheepShaver, >> the clipboard PICT data includes a label with important >> information as >> text strings (DrawString). These label text strings need to survive >> the transfer to the host OS in order for cut/paste to be useful. > > Assuming there's no good open source library to handle arbitrary > PICT data, > the solution here would be to add some functionality to TESyncScrap > or a > similar extension that would intercept clipboard data on the guest > OS side > and when it's a PICT, rasterize it into PICT bitmap-only data, > putting that > back on the guest clipboard. This would be a separate extension which patches PutScrap(). > Then, when SheepShaver gets that data, the PICTs will be guaranteed > to only > have bitmap data, which could be handled by paintlib (or possibly > even some > simpler code we can just write for SheepShaver) which would then be > easily > convertible to the host OS clipboard format. I don't think replacing the PICT data is a good idea, since the pre- rasterized picture would no longer be available to other Mac applications. But adding it as, say, 'Pict' or 'Bits' should work. > This solution would then work cross-platform, instead of being tied > to Mac > OS X as the host. Shall I do this? Josh |
|
From: Alexei S. <ale...@gm...> - 2012-06-19 03:31:39
|
On Mon, Jun 18, 2012 at 9:06 PM, Josh Juran <jj...@gm...> wrote: > On Jun 18, 2012, at 3:51 PM, Alexei Svitkine wrote: > > > On Mon, Jun 18, 2012 at 2:38 PM, Robert Munafo <mr...@gm...> > > wrote: > > > >> In my scientific apps, written by me and running within SheepShaver, > >> the clipboard PICT data includes a label with important > >> information as > >> text strings (DrawString). These label text strings need to survive > >> the transfer to the host OS in order for cut/paste to be useful. > > > > Assuming there's no good open source library to handle arbitrary > > PICT data, > > the solution here would be to add some functionality to TESyncScrap > > or a > > similar extension that would intercept clipboard data on the guest > > OS side > > and when it's a PICT, rasterize it into PICT bitmap-only data, > > putting that > > back on the guest clipboard. > > This would be a separate extension which patches PutScrap(). > > > Then, when SheepShaver gets that data, the PICTs will be guaranteed > > to only > > have bitmap data, which could be handled by paintlib (or possibly > > even some > > simpler code we can just write for SheepShaver) which would then be > > easily > > convertible to the host OS clipboard format. > > I don't think replacing the PICT data is a good idea, since the pre- > rasterized picture would no longer be available to other Mac > applications. But adding it as, say, 'Pict' or 'Bits' should work. > > > This solution would then work cross-platform, instead of being tied > > to Mac > > OS X as the host. > > Shall I do this? > I think that would be useful. If you store them in a separate data type, then it doesn't have to be a PICT at all - maybe something even simpler so we could process it from the SheepShaver side without needing any library. By the way, maybe the sources for these extensions should live in the SheepShaver repository? What do you think? -Alexei |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X