From kc at omnigroup.com Wed Sep 1 00:58:49 1999 From: kc at omnigroup.com (Ken Case) Date: Thu Nov 3 14:42:15 2005 Subject: NSCStringText questions Message-ID: <199909010758.AAA21380@scyther.omnigroup.com> > I need to convert an app from NEXTSTEP to OPENSTEP/YellowBox. This > app makes heavy use of NSCStringText's find features. How do I solve > this problem whithout using NSCStringText anymore? Is there some > kind of a find controller somewhere in the public, or ... ?! There are at least two: You'll find the source code to Omni's find controller (OAFindController, the one used in OmniWeb and OmniPDF) in the source code to our OmniAppKit framework--download it from http://www.omnigroup.com/community/developer/sourcecode/. This isn't really specific to the Text system, though: we also use it to search PDF documents, bookmarks, etc. What might be a closer fit for your purpose is the source code to TextEdit's Find/Replace class, TextFinder, which you'll find in /System/Developer/Examples/Java/AppKit/TextEdit/. (It's actually an Objective C class, despite being part of the TextEdit Java example.) This TextFinder class supports full undo using the new undo mechanism introduced in Mac OS X Server. Hope this helps! Ken From jerome at openbase.com Wed Sep 1 11:18:35 1999 From: jerome at openbase.com (Jerome Lebel) Date: Thu Nov 3 14:42:16 2005 Subject: Convert color to a RGB Color Message-ID: <9909011826.AA00277@mozart.openbase.com> I would to know RGB component of some system colors (like controlColor). How can I convert a color from one space to another ? I found nothing about that on the doc. Thanks, -- Jerome Lebel jerome@openbase.com +1-603-547-8404 ext. 207 From andrew at stone.com Wed Sep 1 14:22:48 1999 From: andrew at stone.com (Andrew Stone) Date: Thu Nov 3 14:42:16 2005 Subject: Project Builder emacs keys? Message-ID: <199909012123.PAA05634@floyd.stone.com> >Is there a bundle that activates emacs-style keys in PB? This activates emacs keys in EVERY NSTextView and NSTextField, save this to the following path: /* ~/Library/KeyBindings/DefaultKeyBinding.dict */ { /* Additional Emacs bindings */ "~f" = "moveWordForward:"; "~b" = "moveWordBackward:"; "~<" = "moveToBeginningOfDocument:"; "~>" = "moveToEndOfDocument:"; "~v" = "pageUp:"; "~d" = "deleteWordForward:"; "~^h" = "deleteWordBackward:"; "~\010" = "deleteWordBackward:"; /* Alt-backspace */ "~\177" = "deleteWordBackward:"; /* Alt-delete */ /* Escape should really be complete: */ "\033" = "complete:"; /* Escape */ } === Andrew Stone, QuixMaster of Stone Design Corp mailto:andrew@stone.com (505) 345-4800 http://www.stone.com - Create(TM) From andrew at stone.com Wed Sep 1 14:28:22 1999 From: andrew at stone.com (Andrew Stone) Date: Thu Nov 3 14:42:16 2005 Subject: Convert color to a RGB Color Message-ID: <199909012128.PAA05642@floyd.stone.com> > I would to know RGB component of some system colors (like > controlColor). How can I convert a color from one space to another ? It's so easy you're going to laugh: NSColor *rgbColor = [color colorUsingColorSpaceName:NSCalibratedRGBColorSpace]; > Jerome Lebel > jerome@openbase.com > +1-603-547-8404 ext. 207 > > === Andrew Stone, QuixMaster of Stone Design Corp mailto:andrew@stone.com (505) 345-4800 http://www.stone.com - Create(TM) From bungi at omnigroup.com Wed Sep 1 16:01:16 1999 From: bungi at omnigroup.com (Timothy J. Wood) Date: Thu Nov 3 14:42:16 2005 Subject: EGCS on MacOS X Server (was Re: Using STL in Cocoa apps) Message-ID: <199909012301.QAA01161@electabuzz.omnigroup.com> >p.s.: Did anyone else notice the AltiVec descriptions in the ppc >configuration subdirectories? Yeah, there is a whole ChangeLog.AltiVec that has stuff about this. I haven't looked at it yet since I hadn't looked for it yet. Yeah! -tim From pshum at alitech.com Thu Sep 2 12:56:49 1999 From: pshum at alitech.com (Paul Shum) Date: Thu Nov 3 14:42:16 2005 Subject: Installation of packages through a telnet session Message-ID: <013901bef57d$4ba9f820$0202010a@ali.bc.ca> Hi, Apple has released NS3.3 User Patch 2 and OS4.2 Mach User Patch 4. We need to install these Y2K packages to our customers. As our customers are all over the States and Canada, we would like to do the installation of the packages through a telnet session (i.e. we cannot use the Installer to do the installation). Does anyone have any idea how to do the job? I have tried to uncompress the OS42MachUserPatch4.tar.Z and use installer_bigtar xpvfiT to extract the files. After the extraction has completed, I run the OS42MachUserPatch4.post_install script. However, I do not feel very comfortable because the files installed in this way have different file sizes than the ones installed using the Installer. In addition, there is no receipt generated under /NextLibrary/Receipts. Could anyone show me some guidelines what I should do? Thanks! _____________ Paul S. L. Shum Christianity is not a way of life but is the truth of life. From karl at nfox.com Thu Sep 2 16:24:32 1999 From: karl at nfox.com (Karl Kraft) Date: Thu Nov 3 14:42:16 2005 Subject: Installation of packages through a telnet session References: <013901bef57d$4ba9f820$0202010a@ali.bc.ca> Message-ID: <004d01bef59a$5138d3c0$0329040a@nfox.com> You might get a better response that what follows if you directed this to the admin list of osx, or even one of the next newsgroups. This group is for discussion of OSX. > However, I do not feel very comfortable because the files installed in this > way have different file sizes than the ones installed using the Installer. I don't have any nextstep machines anymore, so I haven't looked at this patch. My guess would be that the files you are installing this way are larger becuase you have installed them FAT instead of for just the specific architecture. If the files are smaller, then you have a real problem. The CDIS stuff has actual usable telnet tools for installing packages, and stripping them down to a specific or set of architectures. > In addition, there is no receipt generated under /NextLibrary/Receipts Yeah, neither tar nor uncompress will do that magic for you. You could do it by hand, or you could use those CDIS tools. You will find them on your original 3.x CDs. They are used by the initial install process. Why do you feel you need the receipt? Are you planning on unistalling the Y2K patch later :-) ? From cybergrog at bigpond.com Thu Sep 2 21:26:45 1999 From: cybergrog at bigpond.com (Greg Hulands) Date: Thu Nov 3 14:42:16 2005 Subject: Getting the paper source from NSPrinter. Message-ID: <04225871006352@domain0.bigpond.com> I am trying to get the paper sources available from the printer chosen in a popup menu. The code looks something like this: (NSArray *) getPaperTrays:(NSString *)printerName { NSPrinter *selectedPrinter = [NSPrinter printerWithType:printerName]; NSArray *printTrays = [selectedPrinter stringListForKey:@"InputSources" inTable:@"PPD"]; return printTrays; } I call this function when the user changes the printer from one to another so it updates the correct paper sources available. I believe that thing I am doing wrong is passing the wrong strings into stringListForKey as it returns nil. I could not find how to get the correct list when reading the NSPrinter information. Any help is greatly appreciated. Greg. From cybergrog at bigpond.com Fri Sep 3 07:26:59 1999 From: cybergrog at bigpond.com (Greg Hulands) Date: Thu Nov 3 14:42:16 2005 Subject: Reading a file into an NSTextView Message-ID: <14243809719617@domain6.bigpond.com> How does one read in a file into an NSTextView. I have found this documentation quite confusing - but I am sure that it is not. Any help is greatly appreciated. Greg From waynez at erols.com Fri Sep 3 07:46:08 1999 From: waynez at erols.com (Wayne) Date: Thu Nov 3 14:42:16 2005 Subject: Reading a file into an NSTextView References: <14243809719617@domain6.bigpond.com> Message-ID: <010e01bef61b$110ee010$c959453f@rover> Greg, Check out: http://www.stepwise.com/Articles/Technical/HTMLEditor/index.html This example was provided by Scott Anguish and in addition to answering your question deals with some other issues your likely to encounter. Wayne ----- Original Message ----- From: Greg Hulands To: Multiple recipients of list Sent: Friday, September 03, 1999 10:42 AM Subject: Reading a file into an NSTextView > How does one read in a file into an NSTextView. I have found this > documentation quite confusing - but I am sure that it is not. > > Any help is greatly appreciated. > > Greg > > From cybergrog at bigpond.com Fri Sep 3 21:03:40 1999 From: cybergrog at bigpond.com (Greg Hulands) Date: Thu Nov 3 14:42:16 2005 Subject: Listening for an NSNotification Message-ID: <04013481034483@domain2.bigpond.com> I need to listen for an NSNotification for when the window is about to be close, so I can save the state of the objects that are used in the controller. What message do I listen for. Greg From jjfeiler at relief.com Fri Sep 3 21:40:06 1999 From: jjfeiler at relief.com (John Jay Feiler) Date: Thu Nov 3 14:42:16 2005 Subject: Listening for an NSNotification Message-ID: <199909030844.BAA23046@haque.relief.com> > From: "Greg Hulands" > I need to listen for an NSNotification for when the window is about to be > close, so I can save the state of the objects that are used in the > controller. What message do I listen for. APPKIT_EXTERN NSString *NSWindowWillCloseNotification; -- John Feiler jjfeiler@relief.com From cybergrog at bigpond.com Fri Sep 3 23:19:40 1999 From: cybergrog at bigpond.com (Greg Hulands) Date: Thu Nov 3 14:42:16 2005 Subject: DocDisplayer Message-ID: <06172077334397@domain4.bigpond.com> I have made an object that allows you to display any rtf or rtfd files in a window and title it. I am using it in the app I am currently writing. The rtf files need to be in the application wrapper. Hope someone finds it useful. Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman/archive/macosx-dev/attachments/19990904/b8de0fd3/attachment.html From cybergrog at bigpond.com Sun Sep 5 07:33:30 1999 From: cybergrog at bigpond.com (Greg Hulands) Date: Thu Nov 3 14:42:16 2005 Subject: NSTableView Message-ID: <14312677350297@domain7.bigpond.com> I have an NSTableView which I want to be able to have an empty record available to fill in (like MS Access's table view). When I enter something in any of the fields in the new row, it will then create another empty row. I thought NSTableView would implement this cause I have told it the data source. What is the best implementation to use? Any pointers *greatly appreciated! Greg. From mark at jiiva.com Sun Sep 5 14:02:15 1999 From: mark at jiiva.com (Mark Ericksen) Date: Thu Nov 3 14:42:16 2005 Subject: Choosing paper-tray for printing (NT) Message-ID: <199909052055.PAA23955@dfw-ix6.ix.netcom.com> I have this very issue. According to Apple technical support there is a bug in the AppKit when parsing PPD files which prevents any other paper tray from being selected and used. They told me that the bug was scheduled to be fixed for MacOS X (Personal Edition). No patch will be provided. I have a brand new HP 4050TN printer that will only print from tray 3... Mark Ericksen Jiiva, Inc. Markus Ullius Wrote: > Hi > > I'm developing an application which should also print some created documents. > Now there is a problem in choosing the tray. Independant of the printer > settings under NT (where tray 2 is selected), the printer always takes its > paper from tray 1? > > What can I do? > > Thanks > > Markus > ------------------------------------------------------------------ > Markus Ullius > Institute of Transportation, Traffic, Highway & Railway Engineering (IVT) > ETH Hoenggerberg > 8092 Zurich > Switzerland > > Fax: +41 1 633 10 57 > Phone: +41 1 633 31 05 > Direct: +41 1 633 24 15 > > http://www.ivt.baum.ethz.ch > http://www.ivt.baum.ethz.ch/opentimetable.html > > From ahoesch at smartsoft.de Mon Sep 6 08:55:57 1999 From: ahoesch at smartsoft.de (Andreas Hoschler) Date: Thu Nov 3 14:42:16 2005 Subject: Autoresizing NSTextView Message-ID: <9909061555.AA04514@smartsoft.de> Hi, I would like to autoresize an NSTextView if the (entered) text reaches the right edge of the textview so that the text can still be laid out in one line. Is there any notification or delegate method or whatever that can be used to determine when and how much the textview width has to be increased (automatically or manually)? I've played a bit with - setHorizontallyResizable: and - sizeToFit, unfortunately without success yet. How are these methods intended to be used? Thanks a lot, Andreas From fischer at fokus.gmd.de Mon Sep 6 07:57:08 1999 From: fischer at fokus.gmd.de (Robert Fischer) Date: Thu Nov 3 14:42:16 2005 Subject: NSPerformService ruins NSPasteboard? Message-ID: <37D3D644.1D008983@fokus.gmd.de> Hi, I am trying to invoke a service programmatically with NSPerformService(NSString*, NSPasteboard*). At the first time everything works as expected, but then I got a 'Bad return value'. In the following ProjectBuilder from which I started my app will do no more pasteboard operations until being restarted. I am using the pasteboard [NSPasteboard generalPasteboard], which should be the same, whenever i call it, or? Has anyone a clue what's going on? Thanks in advance, Robert -- --- - .-. -- -- --- / \ ---- Robert Fischer .-. / \ --- .-. __o .-. @ / \ / \ / \ _`\<,_ / \ GMD-Fokus / \ / \ / \ (*)/ (*) / `-------------- / `---' `-' `-----------' From paulrs at lgs-systems.com Mon Sep 6 07:08:50 1999 From: paulrs at lgs-systems.com (Paul R. Summermatter) Date: Thu Nov 3 14:42:16 2005 Subject: Context Menu & selections Message-ID: <9909061408.AA01291@slab> Hey guys, I recently posted on a problem regarding context menus (as generated by menuForEvent:) and mouseDown: not being called. In an attempt to resolve this issue, I took matters into my own hands in menuForEvent: and set the selection based on the mouse location. In one instance, I have a context menu popping up in a custom subclass of NSMatrix. I want the selection in the matrix to change based on the location of the right (or control) click in the matrix. I added code to find the appropriate cell for the click and select it in the matrix. On MOSXS, this worked fine and the selection changed before the context menu appeared. However, on NT, the selection does not cause a redisplay until after the context menu is dismissed. I assumed that I could force the issue by calling an explicit 'display' on the matrix just after changing the selection, but this had no impact. Is this a bug on NT? It appears that normal event processing does not go on while a context menu is raised on NT (ie, views are not being asked to redisplay themselves each time through the loop). Does anyone know how else I might work around this problem? Regards, Paul --- Paul Summermatter LGS Systems, Inc. Medical Computing Division 15 TJ Gamester Ave Portsmouth, NH 03801-5871 (603) 433-9822 voice (603) 433-9818 fax (603) 498-6935 voice mail paulrs@lgs-systems.com (NeXT or MIME Mail Welcome) http://www.lgs-systems.com From buck.erik at mcleod.net Mon Sep 6 20:03:29 1999 From: buck.erik at mcleod.net (Erik M. Buck) Date: Thu Nov 3 14:42:16 2005 Subject: Context Menu & selections Message-ID: <008501bef8dd$b6747960$b52a10d0@elcry> I do not know how to work around your redisplay problem when a menu is up. I can suggest that perhaps you shouldn't work around it. Windows Apps do not select with a right click. Windows File Explorer is the perfect example. Right clicking an icon does not change the selection. I honestly do not know which behavior is better. I can only guess at which behavior is expected. From jojo at thinkapple.com Tue Sep 7 07:53:09 1999 From: jojo at thinkapple.com (Adrian) Date: Thu Nov 3 14:42:16 2005 Subject: Offscreen graphics Message-ID: I was wondering if there is a better strategy than using NSBitmapImageRep for directly setting pixels in its offscreen bitmap and then pushing it out to screen as you normally do? Is there anything faster/efficient? -- Kind Regards Adrian From bbum at codefab.com Tue Sep 7 09:38:39 1999 From: bbum at codefab.com (Bill Bumgarner) Date: Thu Nov 3 14:42:16 2005 Subject: New version of Mssh released (and mailing lists) Message-ID: <199909071638.MAA15005@bjork.codefab.com> Mssh version 0.01 is now available. Lots of new features, bug fixes, and other hacquery in this version-- release notes at end of message. I have also created a mailing list for the discussion of mssh; it will very likely also include discussions of runtime hacquing, framework hacquing, and otehr relatively undocumented fun stuff that one can do to the Apple supplied frameworks. See the following for access to the archives and to subscribe (or manage your subscription): http://darwin.codefab.com/mailman/listinfo/mssh You can also send email to mssh-request@darwin.codefab.com with 'help' in the subject or body and the system will reply with documentation as to how to subscribe/unsubscribe via email. (To subscribe, simply send a message with "subscribe" in the subject/body). I will be making various random extensions, scripts, and hacques available shortly and, once (if) there is a reasonable sized community on the mailing list, will be asking for volunteers to script up some solutions to various nagging problems and to finish off partial solutions that have already been implemented. enjoy! b.bum Release 0.01: - Formalized Scripted Module support. Scripted modules have: - search paths and search bundles - cache of already loaded modules - Added defaults module; when used, it adds the name of the script to the defaults domains that are searched. This allows per-standalone-script defaults. - Improved command line modules ability to find executables. - differentiates between absolute paths and relative paths (i.e. won't search if executable "name" passed to -which: is already a full path to an executable - now has "-launchedTaskWithCommand:arguments:" convenience API that will create and execute an NSTask given a command name (including findind the command's executable by search the path environment variable). - now has "-stringFromExecutingCommand:arguments:" API that returns the string based result of executing a command. - Added a Java based scripted module. This module makes it trivial to wrap a java package for execution from the command line. It takes care of searching for the necessary packages, setting up various environment variables, and launching the 'java' virtual machine with the appropriate arguments. (see javatest.wos example in Scripts directory) - Added a proxy object that makes it possible to use a scripted object as the target of distributed notifications, invocations, and the various performSelector: methods. (see example(s) in Scripts that contain references to "ScriptedPerformProxy") - exposed and normalized more of the NSScanner, NSPAthUtilities, NSString and NSFileManager APIs that were not previously available in scripted code (because they either used ranges or had arguments like (NSString **)). - exposed many more "standard" variables as globals. Invoke the showglobals.wos example in Scripts. - added a number of new examples; includes darray.wos -- a command line tool for easily manipulating the contents of default values that contain arrays. - added API for retrieving full set of command line arguments Release 0.00: - execute webscript files from shell - write standalone shell scripts by starting script with: #!/usr/local/bin/mssh (Path should be adjusted to your local installation) - define most common global variables that are normally found in ObjC; string encodings, exception names, etc... - beginnings of scripted module support (includes a command line module that has notion of executable paths and 'which' command) From mark at jiiva.com Tue Sep 7 11:19:28 1999 From: mark at jiiva.com (Mark Ericksen) Date: Thu Nov 3 14:42:16 2005 Subject: distant object invalidation Message-ID: <199909071813.NAA03408@dfw-ix6.ix.netcom.com> Greetings, I have a distributed objects question. I have a client and server connected via distributed objects. The server stores objects from the client and passes them on to other clients. The server also stores objects in a cache in case a new client registers and needs to catch up with the others. All is working great except for one thing. When I client dies and is unable to unregister properly, I need to clean up the server so it doesn't contain stale object proxies. So far my attempt is to do the following: I register for the NSConnectionDidDieNotification and try to ask each NSDistantObject if this is its connection so I can then remove the object from the cache. However when I try to access the NSDistantObject that is from the dead connection I get an expection about accessing the NSDistantObject from another thread... NSThread says that I am not multi-threaded, however. What am I doing wrong? What is the proper way to handle dead connections? Is there a hidden NSDistantObjectInvalidatingNotification? That would be perfect. Thanks, Mark Ericksen Jiiva, Inc. From alexnet at gestalt.com Tue Sep 7 13:03:17 1999 From: alexnet at gestalt.com (Alex Molochnikov) Date: Thu Nov 3 14:42:16 2005 Subject: distant object invalidation Message-ID: <9909072003.AA00527@gestalt.com> Here is how we do it in STEP FORWARD which is also a Client-Server system: 1. Register an object for NSConnectionDidDieNotification notification with senderIsInvalid: method to be called. Allocate an NSArray in the Server to hold ClientRecord objects (say, clientArray). These objects are intended to hold identifying information about the remote Client, e.g. the proxy to the Client's object. 2. When a client registers in the Server, have the Client pass one of its objects back to the Server (as a callback). On the Server side, implement the following method that the Client should call as a part of registering: - (void) registerClient: (id) proxy { id client, connection; connection = [proxy connectionForProxy]; client = [[ClientRecord alloc] initWithConnection:connection]; [clientArray addObject:client]; [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(senderIsInvalid:) name:NSConnectionDidDieNotification object:connection]; } This is a bare bones method, add any other info about the remote client you want to keep in the ClientRecord object instantiation or in separate methods. 3. Implement the notification handling method: - (void) senderIsInvalid: (NSNotification *) sender { int i, count; id client, deadConnection; NSString *eName; deadConnection = [sender object]; [[NSNotificationCenter defaultCenter] removeObserver:self name:NSConnectionDidDieNotification object:deadConnection]; count = [clientArray count]; for (i = 0; i < count; i++) { client = [clientArray objectAtIndex:i]; if ([client connection] == deadConnection) { /* ** Do your cleanup here. If you want to be on ** the safe side, add the following error handling code: */ NS_DURING /* ** Do something... */ NS_HANDLER eName = [localException name]; if (![eName isEqualToString:NSExceptionYouWantToSuppress]) [localException raise]; NS_ENDHANDLER break; } } } BTW, the NSConnectionDidDieNotification will NOT work on WO/NT if the Server runs as an NT Service. This is a known and very old bug that neither NeXT nor Apple ever bothered to fix. Hope this helps. Alex Molochnikov Gestalt Corporation From gclem at frontline-software.dk Tue Sep 7 13:33:09 1999 From: gclem at frontline-software.dk (Geert B. Clemmensen) Date: Thu Nov 3 14:42:16 2005 Subject: Timers and notifications in Java Message-ID: <199909072033.WAA28108@snaps.frontline-software.dk> Hello there, Any good ideas on how to achieve -scheduledTimerWithTimeInterval: and NSNotification (and associated methods) functionality in in pure Java? Thx. for your time, Geert B. Clemmensen Frontline Software From xavierb at proxyware.fr Wed Sep 8 02:51:18 1999 From: xavierb at proxyware.fr (Xavier Barrier) Date: Thu Nov 3 14:42:16 2005 Subject: distant object invalidation In-Reply-To: <199909071813.NAA03408@dfw-ix6.ix.netcom.com> References: <199909071813.NAA03408@dfw-ix6.ix.netcom.com> Message-ID: <199909080951.AA13904@proxyware.fr> You wrote: > Greetings, > > I have a distributed objects question. > > I have a client and server connected via distributed objects. The server > stores objects from the client and passes them on to other clients. The > server also stores objects in a cache in case a new client registers and > needs to catch up with the others. All is working great except for one > thing. When I client dies and is unable to unregister properly, I need to > clean up the server so it doesn't contain stale object proxies. > > So far my attempt is to do the following: > I register for the NSConnectionDidDieNotification and try to ask each > NSDistantObject if this is its connection so I can then remove the object > from the cache. However when I try to access the NSDistantObject that is > from the dead connection I get an expection about accessing the > NSDistantObject from another thread... NSThread says that I am not > multi-threaded, however. > > What am I doing wrong? What is the proper way to handle dead connections? > Is there a hidden NSDistantObjectInvalidatingNotification? That would be > perfect. > > Thanks, > > Mark Ericksen > Jiiva, Inc. > > It is normal that accessing the distant object via a dead NSConection fails, how could it be possible to acces it since the NSConnection is no more present ;-) the best way to handle it, would be to store the proxies linked to each NSConnection. When receiving NSConnectionDidDieNotification you are then able to free evry proxy using this NSConnection. BTW we are handling the same kind of pb in our architecture, and solved it like it is described above! Good luck --- Xavier BARRIER --------------------------------------------------------- ProxyWare SARL 147, rue Saint Martin Paris France Financial Software Company Tel : (+33) 1 42 71 97 66 Fax : (+33) 1 42 71 97 06 e-mail : xavierb@proxyware.fr From rvamerongen at zeelandnet.nl Wed Sep 8 05:44:49 1999 From: rvamerongen at zeelandnet.nl (R.H van Amerongen) Date: Thu Nov 3 14:42:16 2005 Subject: Localization Message-ID: Hi All, Maybe someone can use it. Do you want to program or Localize a language who isn't available? Let say you want to localize you App. to the Dutch Speaking People. There a lot of them in Belgium, Suriname, Curacao, Aruba, St. Maarten, South of Africa, America, Canada Australia and in Holland (The Netherlands) the country with the wooden shoes. Ok enough serious talk. First. change inside the Preferences.framework ( /System/Library/PrivateFrameworks ) the file global.defaults - NSLanguages = (Dutch, English, French, German, Japanese, Spanish, Italian, Swedish); AvailableLanguages = (Dutch, English, French, German, Japanese, Spanish, Italian, Swedish); - change the file language.strings in /System/Library/CoreServices/Resources - /* in native languages. */ "Netherlands" = "Nederland"; "Dutch" = "Nederlands"; "England" = "England"; - Second. To change PB to get this working. Change MainInfo.table The file exists in System/Library/Frameworks/ProjectBuilder.framework/Versions/Current/Re sources/ change MainInfo.table to - Architectures = (C64, ppc, i386); HumanLanguages = ("Dutch", "English", "French", "German", "Spanish", "Portuguese", "Italian", "Swedish", "Japanese"); CompilerLanguages = ("ObjectiveC++", "Java"); CompilerLanguagesPrefixes = (OBJCPLUS_, JAVA_); - So far as I see it is not really needed to sort them alphabetic LET OP!!! <== Dutch for 'Be Aware'. You see it works already. You did make a backup of those files before you....... Greetings Ren? From cybergrog at bigpond.com Wed Sep 8 04:20:17 1999 From: cybergrog at bigpond.com (Greg Hulands) Date: Thu Nov 3 14:42:16 2005 Subject: oddities in my for loop Message-ID: <13044293120068@domain2.bigpond.com> I am having a strange thing happen to me when using a for loop and an array. The code: for (i=0; i<[exercises count]-1; i++) //exercises is the array { newExercise = [[Exercise alloc] init]; [newExercise setName: [exercises objectAtIndex:i]]; [myWorkout addExercise:newExercise]; [newExercise autorelease]; } I put 2 items in the array (exercises), so the [exercises count] message should return 2, which it does, the only thing wrong is that it assigns it to i (that is i = 2). That is the strange thing - an assignment taking place in the condition of the loop. Another strange thing about it is that if i=2 then it doesn't satisfy the condition but allows it to go through the loop. This causes an object out of bounds exception in the [newExercise setName:[exercises objectAtIndex:i]], which would be expected because i = 2. Any Suggestions or explanations? Greg From paulrs at lgs-systems.com Wed Sep 8 05:41:17 1999 From: paulrs at lgs-systems.com (Paul R. Summermatter) Date: Thu Nov 3 14:42:16 2005 Subject: Context Menu & selections In-Reply-To: <008501bef8dd$b6747960$b52a10d0@elcry> References: <008501bef8dd$b6747960$b52a10d0@elcry> Message-ID: <9909081241.AA02715@slab> You wrote: [ I do not know how to work around your redisplay problem when a menu is [ up. I can suggest that perhaps you shouldn't work around it. Windows [ Apps do not select with a right click. Windows File Explorer is the [ perfect example. Right clicking an icon does not change the selection. I [ honestly do not know which behavior is better. I can only guess at which [ behavior is expected. [ Eric, Based on my tests (NT 4.0 sp 4), right clicking a file or folder in the Explorer window DOES select the item you have clicked prior to bringing up the context menu. I tried a couple of other applications such as Outlook and found the same behaviour. I believe this all relates to the same problems that we have with being unable to redraw views while dragging and dropping on NT. If any of the AppKit guys could comment on this, I would love to hear it. Regards, Paul --- Paul Summermatter LGS Systems, Inc. Medical Computing Division 15 TJ Gamester Ave Portsmouth, NH 03801-5871 (603) 433-9822 voice (603) 433-9818 fax (603) 498-6935 voice mail paulrs@lgs-systems.com (NeXT or MIME Mail Welcome) http://www.lgs-systems.com From mike at lorax.com Wed Sep 8 07:50:51 1999 From: mike at lorax.com (mike) Date: Thu Nov 3 14:42:16 2005 Subject: Autoresizing NSTextView Message-ID: <199909081544.IAA09425@boom.lorax.com> See the TextSizing example. Basically you want a very wide (say 1.0e6) text container that does not track the text view width, and a horizontally resizable text view. The view will then size itself to the usage of the container and be as wide as necessary to display the text. The text will never wrap (until it gets a million pixels wide :-). Mike Ferris Begin forwarded message: > From: Andreas Hoschler > Date: 1999-09-06 08:05:50 -0700 > To: Multiple recipients of list > Subject: Autoresizing NSTextView > X-Nextstep-Mailer: Mail 4.2mach (Enhance 2.1) > X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas > Originator: macosx-dev@omnigroup.com > X-Comment: To unsubscribe, follow directions at > http://www.omnigroup.com/MailArchive/ > > Hi, > > I would like to autoresize an NSTextView if the (entered) text reaches the > right edge of the textview so that the text can still be laid out in one > line. Is there any notification or delegate method or whatever that can be > used to determine when and how much the textview width has to be increased > (automatically or manually)? > > I've played a bit with - setHorizontallyResizable: and - sizeToFit, > unfortunately without success yet. How are these methods intended to be used? > > Thanks a lot, > > Andreas > From hordur at mail.lausn.is Wed Sep 8 09:31:51 1999 From: hordur at mail.lausn.is (hordur) Date: Thu Nov 3 14:42:16 2005 Subject: Character encoding woes - help needed ! Message-ID: <199909081631.QAA29741@gremlin.skyrr.is> Hi, I am having an awful problem with my WO app. I am using an OpenBase 6.0.4 database (local to my machine) and when I run my WO app on my machine and insert a record with foreign characters in some strings (like a name), the value that goes into the database is all messed up. On another machine which is also running MacOSXServer and OpenBase 6.0.4 and the same WO app, everything works fine, all characters that go into the database are fine. I have EOAdaptorDebugEnabled turned on for my app and I can see exactly what the INSERT statement looks like on both machines. When I insert a record with some foreign (special Icelandic characters, the same INSERT statement is being generated on both machines. The only difference is that when I go into OpenBaseManager and examine what was inserted, it is messed up on one machine and not on the other one. By the way, both databases are set to ASCII encoding and all the webpages/webbrowsers being used are set to Windows-Latin1 encoding. It does not matter what webbrowser is used (I've tried Netscape 4.5 and Omniweb 3.0). Any light anyone could possibly shed on this would be ever so much appreciated since I am totally clueless as to why this is happening. I've allready re-installed OpenBase on the machine where things are not OK and that did not help (I also deleted and recreated the database). One other thing I tried was replicating the database in question from the machine where things are OK, to the database on the machine where things are NOT OK, and the replicated records are identical in both databases. Sincerely, Hordur Thordarson Iceland From mtarbell at tarbell.jpl.nasa.gov Wed Sep 8 09:33:58 1999 From: mtarbell at tarbell.jpl.nasa.gov (Mark Tarbell) Date: Thu Nov 3 14:42:16 2005 Subject: Localization In-Reply-To: References: Message-ID: <199909081633.JAA02507@tarbell.jpl.nasa.gov> > Do you want to program or Localize a language who isn't available? 'Localization' is fairly slick, but the downside is that you'll still need to manually create & arrange a duplicate set of .nibs for each language you wish to support. For a large project with many supported languages, it can really be a pain to have to go into each .nib, for each language, for every change. (It would be nice if there were an alternative to this based on a single set of .nib files. You can programmatically update text fields, buttons, etc., on a .nib (for instance, using a single English.lproj with TextFields (no hard-coded text), and use NSLocalizedString() with -setStringValue: to populate the fields), but this doesn't work out very well due to the differing lengths of text strings and fonts. And, having to populate each .nib as it is brought up is kludgey.) Mark -- Mark Tarbell (Mark.A.Tarbell@jpl.nasa.gov) Applications Development Section Information Systems Development and Operations Division Engineering and Science Directorate Jet Propulsion Laboratory 4800 Oak Grove Drive MS 502-500 Pasadena, CA 91109 Opinions expressed herein do not reflect those of JPL. From mark at jiiva.com Wed Sep 8 09:58:06 1999 From: mark at jiiva.com (Mark Ericksen) Date: Thu Nov 3 14:42:16 2005 Subject: Conclusion - distant object invalidation Message-ID: <199909081652.LAA08479@dfw-ix4.ix.netcom.com> Thanks to all those who replied to my post. I appreciate the quick responses. The error I received regarding the access of the distant object from another thread was resolved by calling [connection runInNewThread] after I setup the connection and registered it with the name service. I admit that I do not know the technical reason that this solves the issue, but I'm glad it works. Additionally, a few replies I received were concerned about accessing an NSDistantObject when its connection is dead. This is okay to do as long as you're not causing the NSDistantObject to forward its message to the real object. NSDistantObject has a method named, connectionForProxy, which returns the NSConnection object that I used to compare. What does make a difference is how the NSDistantObjects are stored in your cache. I have a dictionary with array values. The array contains more dictionaries and the distant objects are in these dictionaries. When I wanted to invalidate the connection and remove it from the cache, I tried to remove the dictionary from the array. This, to my surprise, caused a copy operation and therefore the distant object tried to access its real object causing another exception. Instead I removed the invalid distant object from its dictionary first and then remove the dictionary from the array. This worked for me and now my cache is being cleaned properly. Thanks again. Mark Ericksen Jiiva, Inc. Greetings, I have a distributed objects question. I have a client and server connected via distributed objects. The server stores objects from the client and passes them on to other clients. The server also stores objects in a cache in case a new client registers and needs to catch up with the others. All is working great except for one thing. When I client dies and is unable to unregister properly, I need to clean up the server so it doesn't contain stale object proxies. So far my attempt is to do the following: I register for the NSConnectionDidDieNotification and try to ask each NSDistantObject if this is its connection so I can then remove the object from the cache. However when I try to access the NSDistantObject that is from the dead connection I get an expection about accessing the NSDistantObject from another thread... NSThread says that I am not multi-threaded, however. What am I doing wrong? What is the proper way to handle dead connections? Is there a hidden NSDistantObjectInvalidatingNotification? That would be perfect. Thanks, Mark Ericksen Jiiva, Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 4069 bytes Desc: not available Url : /mailman/archive/macosx-dev/attachments/19990908/c089cb7d/attachment.bin From dyoung at vviuh221.vvi.com Wed Sep 8 10:26:20 1999 From: dyoung at vviuh221.vvi.com (David Young) Date: Thu Nov 3 14:42:16 2005 Subject: Interesting quotes from Sun Message-ID: <9909081726.AA02473@vviuh221.vvi.com> Excuse the interruption but I thought these quotes from Sun regarding their Sun Ray computer are interesting. John Loiacono, VP marketing at Sun says when JavaStation floundered: "... We've learned that users don't want to just use Java, ..." Sounds like Apple is the only one promoting Sun's Java technology on the desktop nowadays. Thanks A Bunch! David Young; VVI-DCS dyoung@vvi.com Full article: http://www.mercurycenter.com/svtech/news/indepth/docs/sun090899.htm From rthomas at uiuc.edu Wed Sep 8 19:57:34 1999 From: rthomas at uiuc.edu (Ryan Thomas) Date: Thu Nov 3 14:42:16 2005 Subject: EGCS on MacOS X Server (was Re: Using STL in Cocoa apps) In-Reply-To: <199909010407.VAA17644@electabuzz.omnigroup.com> Message-ID: <4.1.19990908215531.00b08100@ntx1.cso.uiuc.edu> At 09:30 PM 8/31/99 -0700, Timothy J. Wood wrote: [...] > As far as installing the results, I haven't any idea. For my work, I = >only need the actual compiler executable. Which is what? All I want to do is use egcs to try to compile htdig and python since I can't get them to compile with existing compiler. How do I do it with the provided egcs-2? -Ryan >-tim > > > >Begin forwarded message: > > >From: Ryan Thomas = >< > >Date: 1999-08-31 20:13:02 -0700 > >To: Multiple recipients of list < > >Subject: Re: EGCS on MacOS X Server (was Re: Using STL in = >Cocoa apps) > > >Thanks, Tim. I'm now subscribed to PublicSource. Please bear with me. > > >I downloaded said egcs package and ran ./configure and make without any=20= > > >parameters and it seemed to compile just fine. But, what's the next = >step?=20 > >Everything went into subdirs of <, and the makefile seems to = >suggest=20 > >they were supposed to. (?) Why do these Darwin packages never have any=20= > > >INSTALL or README docs? > > >Where can I read about whatever next/rhapsody/mosxs -specific stuff it = >is=20 > >I'm lacking in order to know how to install these Darwin packages? For=20= > > >example, how the heck did you come up with this? > > >RC_OS=3D3Dnextstep RC_ARCHS=3D3Dppc RC_CFLAGS=3D3D'-arch ppc' make = >TARGETS=3D3Dppc=3D > > HOSTS=3D3Dppc build > > >Also, I've not seen DSTROOT, SYMROOT, OBJROOT anywhere but in=20 > >next/rhapsody/mosxs -related installs (often needing to be defined on = >the=20 > >command line, I assume). > > >Where can I learn about these idiosyncracies? > > >Thanks. > > >-Ryan > > >At 03:07 PM 8/27/99 -0700, Timothy J. Wood wrote: > >0000,0000,DEB7> If you read the = >PublicSource@public.lists.apple.com, you might have > >>noticed the thread about this. > >> > >> > >> Wilfredo just put up the real egcs package at =3D > >= >>0000,0000,FFFFhttp://www.publicsource.ap= >ple.com/projects/darwin/source/egcs-2.tar.gz > >> > >> > >> This isn't 2.95.1, but it is close enought that I can open it in =3D > >>FileMerge and not just get an uncomprehensible mess. It's close enough = >=3D > >>that it looks like someone could actually do the merge with 2.95.1 with = >=3D > >>a non-zero chance of success (although hopefully Apple will do this =3D > >>before MacOS X Client ships). > >> > >> > >> I've downloaded it and built it and compiled some code with it = >already =3D > >>(No C++, just ObjC). The command I used to build it was: > >> > >> > >>cd <<< > >> > >>RC_OS=3D3Dnextstep RC_ARCHS=3D3Dppc RC_CFLAGS=3D3D'-arch ppc' make = >TARGETS=3D3Dppc=3D > >> HOSTS=3D3Dppc build > >> > >> > >> If you define RC_OS=3D3Dmacosx, it will end up wanting the pthreads = >=3D > >>stuff that isn't in MacOS X Server. Partway through the build, = >nextstep =3D > >>somehow gets magically changed to macosx_server for the configure =3D > >>scripts. Dunno what is up with still having 'nextstep' in the source =3D= > > >>anywhere, but it seems to work this way. > >> > >> > >>-tim > > > From fischer at fokus.gmd.de Thu Sep 9 01:32:32 1999 From: fischer at fokus.gmd.de (Robert Fischer) Date: Thu Nov 3 14:42:16 2005 Subject: .keyboard file for B&W keyboard Message-ID: <37D770A2.452C02F3@fokus.gmd.de> Hi, am I blind or is there no keyboard layout description file available with MacOSX for configuring the 'standard' USB keyboard? Cheers, Robert -- --- - .-. -- -- --- / \ ---- Robert Fischer .-. / \ --- .-. __o .-. @ / \ / \ / \ _`\<,_ / \ GMD-Fokus / \ / \ / \ (*)/ (*) / `-------------- / `---' `-' `-----------' From Peter.Ochmann at ifs-gmbh.de Thu Sep 9 03:13:49 1999 From: Peter.Ochmann at ifs-gmbh.de (Peter.Ochmann@ifs-gmbh.de) Date: Thu Nov 3 14:42:16 2005 Subject: IB-style window Message-ID: <813D90EEB732D211878800A0244B6D54017449E4@A0200030.ess.ifs-gmbh.de> Hi there, I would like to have a view similar to the IB instances view, i.e. a view with icons and context sensitive menus. How is this done or is there any example application how to do this ? Peter Ochmann From garrison at talosiv.cit.cornell.edu Thu Sep 9 07:55:51 1999 From: garrison at talosiv.cit.cornell.edu (William Garrison) Date: Thu Nov 3 14:42:16 2005 Subject: oddities in my for loop Message-ID: <199909091453.KAA00353@postoffice.mail.cornell.edu> > From: "Greg Hulands" > Date: 1999-09-08 09:19:58 -0400 > To: Multiple recipients of list > Subject: oddities in my for loop > > I am having a strange thing happen to me when using a for loop and an array. > > The code: > > for (i=0; i<[exercises count]-1; i++) //exercises is the array > { > newExercise = [[Exercise alloc] init]; > [newExercise setName: [exercises objectAtIndex:i]]; > [myWorkout addExercise:newExercise]; > [newExercise autorelease]; > } Greg, Have you tried putting [exercises count] in a local variable to see if the behavior changes? int cnt = [exercises count]; for (i=0; i < cnt -1; i++) //exercises is the array { newExercise = [[Exercise alloc] init]; [newExercise setName: [exercises objectAtIndex:i]]; [myWorkout addExercise:newExercise]; [newExercise autorelease]; } Bill -- ---------------------------------- William Garrison, wvg2@cornell.edu CIT/ATS, Cornell University From Paul.Hoehne at ps.net Thu Sep 9 08:23:55 1999 From: Paul.Hoehne at ps.net (Hoehne, Paul) Date: Thu Nov 3 14:42:16 2005 Subject: Using the XML parser Message-ID: <8F31BE142C54D21194BD0008C756AD6C012CA2C3@resexch01.rmf.ps.net> The P-Lists are stored as XML documents so therefore there must be an XML parser at some level which reads those p-lists. Is the parser that reads those XML docs accessible as a Yellow Box class or set of function calls? If it is, what am I missing? I keep trying to track it down with precious little success. perotsystems Paul C. Hoehne (703) 295 1279 Paul.Hoehne@ps.net From infinity at apple.com Thu Sep 9 08:36:10 1999 From: infinity at apple.com (Sam Krishna) Date: Thu Nov 3 14:42:16 2005 Subject: [Fwd: Inaugural DaWG (Darwin and WebObjects Group) Meeting] Message-ID: <37D7D3EA.DFCB7F75@apple.com> All, Apologies for the spam, but I figured if anyone who's in the Triange this weekend and who's interested in (or developing for): EOF WebObjects Mac OS X (or X Server) Darwin Cocoa (formerly known as Yellow Box and OPENSTEP) NEXTSTEP would be interested in this email. Take care, Sam -------------- next part -------------- An embedded message was scrubbed... From: "Michelle P. Malach" Subject: Inaugural DaWG (Darwin and WebObjects Group) Meeting Date: Thu, 09 Sep 1999 11:05:40 -0400 Size: 2569 Url: /mailman/archive/macosx-dev/attachments/19990909/2d67ea89/attachment.mht From ckane at apple.com Thu Sep 9 09:15:29 1999 From: ckane at apple.com (Chris Kane) Date: Thu Nov 3 14:42:16 2005 Subject: Using the XML parser Message-ID: <001701befade$88e5d540$9d0eca11@verbosity.apple.com> The XML parser is in the CoreFoundation framework in Mac OS X DP1, but the header is not public. It is public in DP2, and is a general XML parser. Chris Kane Apple Computer, Inc. -----Original Message----- From: Hoehne, Paul To: Multiple recipients of list Date: Thursday, September 09, 1999 8:31 AM Subject: Using the XML parser >The P-Lists are stored as XML documents so therefore there must be an XML >parser at some level which reads those p-lists. Is the parser that reads >those XML docs accessible as a Yellow Box class or set of function calls? >If it is, what am I missing? I keep trying to track it down with precious >little success. > >perotsystems >Paul C. Hoehne >(703) 295 1279 >Paul.Hoehne@ps.net From infinity at apple.com Thu Sep 9 11:37:52 1999 From: infinity at apple.com (Sam Krishna) Date: Thu Nov 3 14:42:16 2005 Subject: Inaugural DaWG (Darwin and WebObjects Group) Meeting Message-ID: <37D7FE80.C6BD9F68@apple.com> All, It seems like my original posting didn't go through. Here's the original note: (Please direct all replies to Mike Laster - mailto:mlaster@apple.com ) Take care, Sam -------------------------------------------------------------------------- All, Apologies for the spam, but I figured if anyone who's in the Triange this weekend and who's interested in (or developing for): EOF WebObjects Mac OS X (or X Server) Darwin Cocoa (formerly known as Yellow Box and OPENSTEP) NEXTSTEP would be interested in this email. Subject: Inaugural DaWG (Darwin and WebObjects Group) Meeting Date: Thu, 09 Sep 1999 11:05:40 -0400 All, There will be an inaugural meeting for all people interested in participating in the Darwin and WebObjects Group (DaWG) this Saturday, September 11, 3pm at 2nd City Grill, 506 Daniels Street, Raleigh, NC 27605 (919) 856-0336 http://yp.yahoo.com/py/ypMap.py?Pyt=Typ&YY=6505&city=Raleigh&state=NC&country=US&slt=35.7719&sln=-78.6389&cs=5&stx=7737232&stp=y&ad=2500&ycat=&l=7&tuid=2784491&tq=8&btype=default The meeting will address future meetings and future meeting agenda. Please RSVP Mike Laster (mlaster@apple.com) or reply to this mailing if you are interested in attending. If you cannot make this meeting, but are interested in participating in future meetings please reply as well. Michelle Malach Mike Laster David Coyle William Wei From rcfa at cubiculum.com Thu Sep 9 12:10:13 1999 From: rcfa at cubiculum.com (Ronald C.F. Antony) Date: Thu Nov 3 14:42:16 2005 Subject: Using the XML parser In-Reply-To: <001701befade$88e5d540$9d0eca11@verbosity.apple.com> References: <001701befade$88e5d540$9d0eca11@verbosity.apple.com> Message-ID: <199909091910.PAA05220@wenix.cubiculum.com> you wrote: > The XML parser is in the CoreFoundation framework in Mac OS X DP1, but the > header is not public. It is public in DP2, and is a general XML parser. Will there be ObjC bindings, or will this remain a plain C-based thing? Ronald ============================================================================== "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." G.B. Shaw | rcfa@cubiculum.com | NeXT-mail welcome From ckane at apple.com Thu Sep 9 12:59:59 1999 From: ckane at apple.com (Chris Kane) Date: Thu Nov 3 14:42:16 2005 Subject: Using the XML parser Message-ID: <003e01befafd$e5aad2c0$9d0eca11@verbosity.apple.com> Ronald C.F. Antony >> The XML parser is in the CoreFoundation framework in Mac OS X DP1, but the >> header is not public. It is public in DP2, and is a general XML parser. > >Will there be ObjC bindings, or will this remain a plain C-based thing? There will be no ObjC binding in DP2, and likely never will be. Chris Kane Apple Computer, Inc. From marcel at system.de Thu Sep 9 14:59:31 1999 From: marcel at system.de (Marcel Weiher) Date: Thu Nov 3 14:42:16 2005 Subject: Using the XML parser Message-ID: > From: "Chris Kane" > > Ronald C.F. Antony > >> The XML parser is in the CoreFoundation framework in Mac OS X DP1, but > the > >> header is not public. It is public in DP2, and is a general XML parser. > > > >Will there be ObjC bindings, or will this remain a plain C-based thing? > > There will be no ObjC binding in DP2, and likely never will be. Anyone else sickened by this? Apple really seems to be going through with their crazy plan. Oh well, I've got an Objective-C XML-parser in development here, currently used for object-archiving and XML-property-list parsing. If anyone is interested in helping out, I could make it available as OpenSource. Marcel From rcfa at cubiculum.com Thu Sep 9 15:55:10 1999 From: rcfa at cubiculum.com (Ronald C.F. Antony) Date: Thu Nov 3 14:42:16 2005 Subject: Using the XML parser In-Reply-To: <003e01befafd$e5aad2c0$9d0eca11@verbosity.apple.com> References: <003e01befafd$e5aad2c0$9d0eca11@verbosity.apple.com> Message-ID: <199909092255.SAA05745@wenix.cubiculum.com> you wrote: > Ronald C.F. Antony > >> The XML parser is in the CoreFoundation framework in Mac OS X DP1, but > >> the header is not public. It is public in DP2, and is a general XML > >> parser. > > > >Will there be ObjC bindings, or will this remain a plain C-based thing? > > There will be no ObjC binding in DP2, and likely never will be. No personal offense, but this *severely sucks*, particularly the "likely never will be" part. Does Apple really think we lust for Java, C++ and plain C S&M sessions? I'd prefer the cozier relationship I have with ObjC, Scheme and SmallTalk. Apple better stop the talk about "object oriented" and "advanced" in connection with their software, if all that's being done is a regression. Nice hardware really can't cover up the fact that NeXT's direction was much more modern in the software development area than anything Apple has so far come up with. It's pathetic. Please forward this to the people in charge. Ronald ============================================================================== "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." G.B. Shaw | rcfa@cubiculum.com | NeXT-mail welcome From rcfa at cubiculum.com Thu Sep 9 16:01:04 1999 From: rcfa at cubiculum.com (Ronald C.F. Antony) Date: Thu Nov 3 14:42:17 2005 Subject: Using the XML parser In-Reply-To: References: Message-ID: <199909092301.TAA05760@wenix.cubiculum.com> > > > >The XML parser is in the CoreFoundation framework in Mac OS X DP1, but > > > >the header is not public. It is public in DP2, and is a general XML > > > >parser. > > > > > >Will there be ObjC bindings, or will this remain a plain C-based > > >thing? > > > >There will be no ObjC binding in DP2, and likely never will be. > > Anyone else sickened by this? Yes, very much so. > Apple really seems to be going through with their crazy plan. I hope that it will come back to bite them. > Oh well, I've got an Objective-C XML-parser in development here, > currently used for object-archiving and XML-property-list parsing. If > anyone is interested in helping out, I could make it available as > OpenSource. How about working with the GNUStep people on this? It seems that there are people there looking into the same issue, in particular in reference to OSX XML based NIB files. They need such a parser, and there are people who probably can help out, too. Ronald ============================================================================== "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." G.B. Shaw | rcfa@cubiculum.com | NeXT-mail welcome From mmarkowitz at ceiss.org Thu Sep 9 16:32:06 1999 From: mmarkowitz at ceiss.org (Maury Markowitz) Date: Thu Nov 3 14:42:17 2005 Subject: Using the XML parser Message-ID: On Thursday, September 09, 1999 3:05 PM, Marcel Weiher [SMTP:marcel@system.de] wrote: > Anyone else sickened by this? Yes and no. My take on this is that it's a little bit of slight of hand. Ask yourself this, is Apple trying to kill AppKit by putting stuff only in CF, or is Apple making a completely new "OS" (API) called CF? I believe it's the later. Apple's in a bit of a tough place. It's clear that many MacOS people are not going to go to Obj-C no matter how good it is (and before people start telling me they're luddites, I've see the same in reverse just as many times), yet they've got all this great code in Foundation and such that would be of tremendous use to all Mac apps, and even Apple itself. So we separate out all the cool code, stick it into CF and now both the Obj-C people and the Mac people can use it. We've already seen the results, new API's coming out of Apple are using CF types. The Keychain uses them for instance, as does the MacOS side of the URL handling stuff. As time goes on I think we'll see this more and more, we'll get language neutral API's using CF types - maybe even newer versions of older API's that use them (please Apple, make QT CF friendly!). Sooner or later CF becomes rich and complete. Foundation and AppKit are wrappers over CF. At that point the language debate goes away. Want to use C? Be our guest! Want to use Obj-C? Hey, great? Java? Fine! I can't see any downside to this. Sure it means smaller numbers of direct updates to the Obj-C world (the NS things), but at the same time it means more and more API's that we can get easy access to via CF. I think the later is more important to us. Of course one problem is that the "original language" colours the API, no matter how hard you try. Consider for example that even a CF based AppKit-like layer is likley to use target-action, making it look weird to Java developers who are used to (uggg) the throw/catch system. I don't know if the Obj-C flavouring is bad when you see it in CF though, as Obj-C specific things like protocols are invisible. Another reason why I like the concept at least is that Obj-C is getting very long in the tooth. Apple is clearly not interested in upgrading Obj-C, so essentially we can expect the libs to remain largely the same. Yet you can't help but wonder how much nicer AppKit would be if it was multiple-inherited rather than protocoled (for instance) and included garbage collection - and CF allows me to move to TOM in theory. > Apple really seems to be going through with their crazy plan. I don't think it's that crazy, layering is good after all. It might not be great for us, but overall I think it's a greater good. Maury From mmarkowitz at ceiss.org Thu Sep 9 16:34:03 1999 From: mmarkowitz at ceiss.org (Maury Markowitz) Date: Thu Nov 3 14:42:17 2005 Subject: Using the XML parser Message-ID: On Thursday, September 09, 1999 4:16 PM, Ronald C.F. Antony [SMTP:rcfa@cubiculum.com] wrote: > How about working with the GNUStep people on this? Noooooo! Please do NOT put a GPL on anything you write! Maury From marcel at system.de Thu Sep 9 16:42:33 1999 From: marcel at system.de (Marcel Weiher) Date: Thu Nov 3 14:42:17 2005 Subject: Using the XML parser Message-ID: > From: David Young > > > Apple really seems to be going through with their crazy plan. > > And what plan is that? The "let's not give developers a choice but force Java down their throats now matter how loud they scream or what the technical merits of the case are, or just how ridiculously badly it works"-plan. Anyway, another question: I have a patch to the egcs version recently released that makes certain types of meta-programming a lot easier. Anybody know where/how I can submit the patch? Thanks, Marcel From cmh at greendragon.com Thu Sep 9 16:51:25 1999 From: cmh at greendragon.com (Chris Hanson) Date: Thu Nov 3 14:42:17 2005 Subject: Using the XML parser In-Reply-To: References: Message-ID: At 3:05 PM -0700 9/9/99, Marcel Weiher wrote: >Anyone else sickened by this? > >Apple really seems to be going through with their crazy plan. Oh, for God's sake. Just GIVE IT UP. Objective-C is nice, but the sky is not going to fall if Apple doesn't implement an Objective-C binding for everything under the sun. Put together an LGPL'd Objective-C binding to Apple's XML parser and I'll bet Apple adopts it for inclusion. They just don't want to spend the effort to maintain such a thing when the primary API to it -- thanks to the vast majority of Mac OS X applications being based on Carbon for a long time to come (probably forever) -- will be C. From cmh at greendragon.com Thu Sep 9 17:02:36 1999 From: cmh at greendragon.com (Chris Hanson) Date: Thu Nov 3 14:42:17 2005 Subject: Using the XML parser In-Reply-To: References: Message-ID: At 4:52 PM -0700 9/9/99, Maury Markowitz wrote: > Noooooo! Please do NOT put a GPL on anything you write! Just to clear things up, GNUstep is under the Library GPL. This means it's okay for proprietary software to dynamically-link against it. From marcel at system.de Thu Sep 9 17:18:24 1999 From: marcel at system.de (Marcel Weiher) Date: Thu Nov 3 14:42:17 2005 Subject: Using the XML parser Message-ID: > Sooner or later CF becomes rich and complete. Foundation and AppKit are > wrappers over CF. At that point the language debate goes away. Want to use > C? Be our guest! Want to use Obj-C? Hey, great? Java? Fine! It would be great if that were the case, but the statement that made me sick was that there wouldn't be any Objective-C bindings, meaning either plain C or Java. Neither of these is good enough. Heck, Objective-C isn't *really* good enough, but just barely good enough to get by on. > Another reason why I like the concept at least is that Obj-C is getting > very long in the tooth. In what way, except for Apple not supporting it any longer? > Apple is clearly not interested in upgrading Obj-C, Obj-C doesn't really need much upgrading, and hasn't really needed much in the last ~15 years, because it is a small and sensible design with enough flexibility ( e.g. meta-programmability) that you can get both flexible, high-level interfaces and lightning fast implementations. C++ gives you fast implementation and brittle interfaces. Smalltalk gives you even more flexibility at a slight speed penalty. Java gives you both brittle interfaces and an additional speed penalty. For example, the XML-parser I referred to earlier uses a small plain-C routine at the lowest level, character scanning and progressively more abstract techniques in the higher levels. Since this is Objective-C, the layers are freely mixable, so you can, for example, create very fast partial parsers that only incur the parsing overhead for the parts they are actually interested in. The only problem with Objective-C right now is that Apple is actively trying to kill it, by willfully not making licenses availabe and removing interfaces from the system, despite strong developer opposition (from those that have actually used it). In my feeble mind, that's not a problem with Objective-C, but with Apple, and the result is that if Apple removes Objective-C without providing a better replacement (neither C nor Java fit that bill), it will be Apple being dumped, not Objective-C. Heck, there are now what appear to be very usable Smalltalk implementations for Windows + cross platform versions. If I'm going to pay the VM-speed penalty, I might as well get something for it. That said, I also like the layering aspect of CoreFoundation. It sure can be useful having access to the bare metal at times. Marcel From mmarkowitz at ceiss.org Thu Sep 9 17:59:09 1999 From: mmarkowitz at ceiss.org (Maury Markowitz) Date: Thu Nov 3 14:42:17 2005 Subject: Using the XML parser Message-ID: On Thursday, September 09, 1999 5:18 PM, Marcel Weiher [SMTP:marcel@system.de] wrote: > It would be great if that were the case, but the statement that made > me sick was that there wouldn't be any Objective-C bindings, meaning > either plain C or Java. No, I think that means plain C. However let us not confuse "won't be" with "can't be". Writing Obj-C wrappers for CF based API is trivial. I don't think this is an issue, this should take you a few minutes to wrap. > Objective-C isn't *really* good enough, but just barely good enough > to get by on. TOM on the other hand is *really* good. In fact it's so good that I think this is where the debate should be turning. TOM includes modules for namespace issues (similar to Java), multiple inheritance (yes, you can do this safely if you have modules), garbage collection, reflection, class vars, etc. It also has the Obj-C syntax, but cleaned up to a degree (some things I don't like). > In what way, except for Apple not supporting it any longer? When Obj-C was being built, a lot of the questions out there weren't yet answered. For instance there was a lot of confusion as to whether or not multiple inheritance could be done safely, and whether or not auto-GB could be done realistically. In the time since then we've learned that both of these can be made to work, and to work well. We've also learned a lot about namespaces, Eiffel introduced programming by contract, etc. In fact most of the languages in use today are old in this same way. C++ isn't even worth talking about, but Java is also fairly old in most ways. Dylan, TOM and Cecil are some of the newer ones. Of all of these, TOM has the advantage of looking and working like Obj-C, and even expanding some of the concepts, like it's version of catagorization, which allows you to even add ivars. You get all sorts of things for free, for instance you get NSCoding without a single line of code (no void *) > Obj-C doesn't really need much upgrading, and hasn't really needed > much in the last ~15 years, because it is a small and sensible design > with enough flexibility ( e.g. meta-programmability) that you can > get both flexible, high-level interfaces and lightning fast > implementations. I'm sorry, but I simply don't agree. Every second you spend tracing down a NSZombie is one wasted second. TOM is better, more powerful, and easier to use. > interfaces. Smalltalk gives you even more flexibility at a slight > speed penalty. Java gives you both brittle interfaces and an > additional speed penalty. You are naming a bunch of old languages. You need to do a little research here I think. > In my feeble mind, that's not a problem with Objective-C, but with > Apple No, it's the market. Apple simply has zero chance of being able to support Obj-C in the Java and Obj-C world. If YOU want to use something better fine, but you can't expect Apple to do it. Maury From rcfa at cubiculum.com Thu Sep 9 19:10:40 1999 From: rcfa at cubiculum.com (Ronald C.F. Antony) Date: Thu Nov 3 14:42:17 2005 Subject: Using the XML parser In-Reply-To: References: Message-ID: <199909100210.WAA06234@wenix.cubiculum.com> > TOM on the other hand is *really* good. In fact it's so good that I think > this is where the debate should be turning. TOM includes modules for > namespace issues (similar to Java), multiple inheritance (yes, you can do > this safely if you have modules), garbage collection, reflection, class > vars, etc. It also has the Obj-C syntax, but cleaned up to a degree (some > things I don't like). Sounds interesting. I'm not married to ObjC, I just don't want to regress back to the past. (Links to information on TOM appreciated...) However what chances do you think a language like TOM stands? ObjC is at least 100% ANSI-C compatible, and while the step from procedural to OOP-thinking is large, the step of learning ObjC as a C programmer is small, and equally small to non-existent are the issues involved with linking in legacy code with ObjC projects. Now unless TOM is an ANSI-C extension like ObjC, TOM is going to fight the same up-hill battle as Scheme, T, Dylan, SmallTalk, etc. Out of the barely-useful and better languages, ObjC has the best chances to succeed, because it has both a proven track record, is compatible with legacy code, and it has a dedicated following. Apple is only shooting itself in the foot. Apple offering Java bindings and plain-C based CF, is a great thing, because it offers choice and calms down the programers stuck in the past who get a panic attack when they hear about OOP. But as much as I'd like to see a language better than ObjC, I can't believe that any of the other languages has even a small chance, given the amount of resistance even ObjC runs into. But before this goes completely off topic, a little remark about your comment that "Writing Obj-C wrappers for CF based API is trivial. I don't think this is an issue, this should take you a few minutes to wrap." I'd refute that. Ask the Omni people, if it was just a matter of minutes to write wrappers around AIAT. "a wrapper" and "a well designed, subclassable wrapper with an API that's consistent with the rest of the OpenStep/Cocoa API" are two totally different things. The former may be an issue of "a few minutes", the latter is an engineering effort. Ronald ============================================================================== "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." G.B. Shaw | rcfa@cubiculum.com | NeXT-mail welcome From wsanchez at apple.com Thu Sep 9 19:59:01 1999 From: wsanchez at apple.com (Wilfredo Sanchez) Date: Thu Nov 3 14:42:17 2005 Subject: Using the XML parser Message-ID: <199909100258.TAA04742@scv3.apple.com> | Anyway, another question: I have a patch to the egcs version | recently released that makes certain types of meta-programming a lot | easier. Anybody know where/how I can submit the patch? To the FSF or on http://www.publicsource.apple.com/modifications.html. I suggest you try the FSF first. -Fred -- Wilfredo Sanchez, wsanchez@apple.com Apple Computer, Inc., Core Operating Systems / BSD Technical Lead, Darwin Project 1 Infinite Loop, 302-4K, Cupertino, CA 95014 From rcfa at cubiculum.com Thu Sep 9 17:55:18 1999 From: rcfa at cubiculum.com (Ronald C.F. Antony) Date: Thu Nov 3 14:42:17 2005 Subject: Using the XML parser In-Reply-To: References: Message-ID: <199909100055.UAA06039@wenix.cubiculum.com> you wrote: > On Thursday, September 09, 1999 4:16 PM, Ronald C.F. Antony > [SMTP:rcfa@cubiculum.com] wrote: > > How about working with the GNUStep people on this? > > Noooooo! Please do NOT put a GPL on anything you write! That's another inane comment. First GNUStep is under LGPL and not under GPL, and that's a very relevant distinction. LGPL can be freely used in commercial projects, but it doesn't allow freeloaders to take it, and make it their private property. Either you don't understand the GNU licensing, or you're trying to benefit more from someone else's work than you should be entitled to, given your response... Ronald ============================================================================== "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." G.B. Shaw | rcfa@cubiculum.com | NeXT-mail welcome From rcfa at cubiculum.com Thu Sep 9 17:52:50 1999 From: rcfa at cubiculum.com (Ronald C.F. Antony) Date: Thu Nov 3 14:42:17 2005 Subject: Using the XML parser In-Reply-To: References: Message-ID: <199909100052.UAA06027@wenix.cubiculum.com> > Sooner or later CF becomes rich and complete. Foundation and AppKit are > wrappers over CF. At that point the language debate goes away. Want to use > C? Be our guest! Want to use Obj-C? Hey, great? Java? Fine! There are a few problems with this: CF is only as useful as the abstractions it makes. If it ends up just being yet another cleaned up procedural API, then the improvement over Toolbox/Carbon is marginal to non-existent. Wrappers around procedural code work, as long as the procedural stuff is so basic, that it constitutes the building blocks of everything else. If things become more complex, there will be a clash of software models and/or a problem with such things as subclassability, etc. Worst of all, I could deal with the fact that CF provides building blocks and a procedural API for those eternally stuck in the past, and that higher level OO abstractions are provided by proper ObjC wrappers around that base. We have had similar things in the past e.g. ixKit, EOF adaptors, etc. No problem. *BUT* that requires that these wrappers be made. While Chris Cane's statements may not be "offical Apple words", they are at least an honest assessment as to how he sees the situation as someone who works at that joint. So if he thinks it's not likely that ever there will be ObjC wrappers around these things, then your theory breaks down. If every developer has to spend months wrapping CF API on their own, and if everyone rolls their own more or less well designed wrappers, etc. then all the benefits of a consistent, standardized, well integrated and rich set of OO APIs are right out the window, and we end up with the "job security" mess we have on all other platforms: a plethora of so called object oriented toolkits and APIs in a wild mixture, none designed to work with the other, each employing a different set of conventions, etc. In short, we're back in the programming nightmare I tried to escape by moving to SmallTalk and then NeXT. Very f*cking pleasant to feel trown back in time by about 20 or so years. I start understanding the agony of the people who used to work on Lisp-machines, and the original SmallTalk-80 environment about 20 years ago, who still bitch and moan that in all this time no commercial platform has ever come close to providing an environment of similar consistency, integration and programming efficiency. Rather pathetic for an industry that prides itself to have a product life cycle of only a few months. It might behoove some people here to revisit history for a while. It's also pathetic that an entire industry is dominated by a mass of brainless lemings, and that nobody has any guts anymore to show leadership. If we add up the inefficiency, wasted resources, etc. that are the result of an intentionally delayed development in the software field, then we start to understand the saying "Behind each large fortune hides a large crime" in a new dimension. I don't think giving to charity can offset the damage done in the first place. Sort of like burning down a forest, and then offering to plant a few hundred trees as a tax deduction... > I can't see any downside to this. Sure it means smaller numbers of direct > updates to the Obj-C world (the NS things), but at the same time it means > more and more API's that we can get easy access to via CF. I think the > later is more important to us. I can't say I agree. First, there's no intention to ever create the relevant wrappers, and second, productivity is the main advantage Apple can offer. If I have to use a procedural API, then I can go with Linux or Win* and have a bigger market and a more portable product. NS allows me to achieve my goals in a fraction of the time, it allows me as a single individual to compete with entire teams when it comes to creating custom software. Enter the world of CF, that is history. Besides, what irony: while people were ditching OOP because it's supposedly a performance hog, NeXT succeeded creating an OOP environment and OS with acceptable performance, on hardware, that by modern standards can only be called slow. Now Apple has the fastest boxes around, which could easily handle the little bit of potential OOP overhead, and guess what: we're going back to procedural APIs. I suggest, while Apple is at it, they may want to reconsider their support of m68k Macs... They should be able to handle CF just fine. > Apple is clearly not interested in upgrading Obj-C, > so essentially we can expect the libs to remain largely the same. ObjC doesn't need much upgrading. Other than name spaces, which by convention already exist anyway, the language is fine. GC, the other much requested item, is not a matter of the language, but of the runtime/libraries, as GNUStep versions can do GC quite nicely. > Yet you > can't help but wonder how much nicer AppKit would be if it was > multiple-inherited rather than protocoled That is flame bait. Multiple inheritance is not in ObjC *by design*, not by omission. There is *a lot* of critizism against multiple inheritance, e.g. that it's a bad idea to mix implementation sharing with conceptual relationships, the issue of undefined results on subclasses, categories, etc. Personally, I'd be the first person to oppose adding multiple-inheritance to ObjC. (Note: AFAIK, Java doesn't support that either, for good reason.) > I don't think it's that crazy, layering is good after all. It might not > be great for us, but overall I think it's a greater good. Again: layering requires however that the layers be built, which is exactly what has been denied. Nobody here minds or opposes that the XML parser is a CF framework, but what causes a riot is that there neither are nor won't be any ObjC wrappers. Ronald ============================================================================== "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." G.B. Shaw | rcfa@cubiculum.com | NeXT-mail welcome From wsanchez at apple.com Thu Sep 9 20:28:47 1999 From: wsanchez at apple.com (Wilfredo Sanchez) Date: Thu Nov 3 14:42:17 2005 Subject: Using the XML parser Message-ID: <199909100328.UAA06655@scv3.apple.com> | That's another inane comment. First GNUStep is under LGPL and not | under GPL, and that's a very relevant distinction. LGPL can be freely | used in commercial projects, but it doesn't allow freeloaders to | take it, and make it their private property. | Either you don't understand the GNU licensing, or you're trying to | benefit more from someone else's work than you should be entitled to, | given your response... Um, I think the GPL is a pain. And I think I do know what I'm talking about, because I deal with licenses and lawyers quite a bit. The LGPL is OK, except when one uses the option to switch to the GPL. If you have a choice, and aren't married to the GPL, I suggest you go with a BSD license, the Artisitc license (Perl), or something a little friendlier than the GPL. -Fred -- Wilfredo Sanchez, wsanchez@apple.com Apple Computer, Inc., Core Operating Systems / BSD Technical Lead, Darwin Project 1 Infinite Loop, 302-4K, Cupertino, CA 95014 From sanguish at digifix.com Thu Sep 9 21:34:11 1999 From: sanguish at digifix.com (Scott Anguish) Date: Thu Nov 3 14:42:17 2005 Subject: Using the XML parser In-Reply-To: References: Message-ID: <199909100434.AAA04669@digifix.com> Maury Markowitz wrote: > On Thursday, September 09, 1999 3:05 PM, Marcel Weiher > [SMTP:marcel@system.de] wrote: > > Anyone else sickened by this? > > Yes and no. > > My take on this is that it's a little bit of slight of hand. Ask yourself > this, is Apple trying to kill AppKit by putting stuff only in CF, or is > Apple making a completely new "OS" (API) called CF? I believe it's the > later. > Considering CF is entirely function call based, I hope not. > > So we > separate out all the cool code, stick it into CF and now both the Obj-C > people and the Mac people can use it. > But Apple won't be providing a standard Objective-C API for these calls... which means that passing them around is going to be less than clear, and EVERYONE gets to roll their own. > We've already seen the results, new API's coming out of Apple are using CF > types. The Keychain uses them for instance, as does the MacOS side of the > URL handling stuff. As time goes on I think we'll see this more and more, > we'll get language neutral API's using CF types - maybe even newer versions > of older API's that use them (please Apple, make QT CF friendly!). > > Sooner or later CF becomes rich and complete. Foundation and AppKit are > wrappers over CF. At that point the language debate goes away. Want to use > C? Be our guest! Want to use Obj-C? Hey, great? Java? Fine! > So we can all write in whatever language we want, but in order to provide Object Interfaces to these C-APIs, we have to all roll our own. That is so much the Mac OS Toolbox approach, and 10 years out of date that it sickens me. From sanguish at digifix.com Thu Sep 9 21:37:07 1999 From: sanguish at digifix.com (Scott Anguish) Date: Thu Nov 3 14:42:17 2005 Subject: Using the XML parser In-Reply-To: References: Message-ID: <199909100437.AAA04684@digifix.com> Maury Markowitz wrote: > On Thursday, September 09, 1999 5:18 PM, Marcel Weiher > [SMTP:marcel@system.de] wrote: > > It would be great if that were the case, but the statement that made > > me sick was that there wouldn't be any Objective-C bindings, meaning > > either plain C or Java. > > No, I think that means plain C. However let us not confuse "won't be" > with "can't be". Writing Obj-C wrappers for CF based API is trivial. I > don't think this is an issue, this should take you a few minutes to wrap. > All the more reason that we should have OFFICIALLY SUPPORTED APIs for these things. It IS trivial, and yet by Apple providing them, they are ubiquitous.. From theisen at akaMail.com Thu Sep 9 23:17:37 1999 From: theisen at akaMail.com (Dirk Theisen) Date: Thu Nov 3 14:42:17 2005 Subject: Using the XML parser In-Reply-To: <199909100434.AAA04669@digifix.com> Message-ID: <1dxwpcv.w62gri1b8se4gM@[192.168.0.2]> Hi, Scott! > > Sooner or later CF becomes rich and complete. Foundation and AppKit are > > wrappers over CF. At that point the language debate goes away. Want to use > > C? Be our guest! Want to use Obj-C? Hey, great? Java? Fine! > > > So we can all write in whatever language we want, but in order to > provide Object Interfaces to these C-APIs, we have to all roll our own. I agree! But if Apple really doesn't wrap the CF stuff for us (I hope for the opposite), we have to make sure there is an early public release that can be integrated with GNUstep, so we all have access to this and few developers see any reason to roll their own. Regards, Dirk From dyoung at vviuh221.vvi.com Fri Sep 10 04:51:12 1999 From: dyoung at vviuh221.vvi.com (David Young) Date: Thu Nov 3 14:42:17 2005 Subject: patch to the egcs version References: Message-ID: <9909101151.AA06404@vviuh221.vvi.com> Marcel, > Anyway, another question: I have a patch to the egcs version > recently released that makes certain types of meta-programming a lot > easier. Anybody know where/how I can submit the patch? Here are some ideas: Sign up to the mail list: gcc@gcc.gnu.org gcc is actually egcs from what I know. post the patch there, see what people say. Also, go to: http://egcs.cygnus.com See the section titled: "Bugs", "Known Bugs" for bugs See the section: "Mailing Lists" to sign up. http://egcs.cygnus.com/lists.html See: http://egcs.cygnus.com/onlinedocs/objc-features_toc.html to see the egcs compiler obj-c features. Cygnus seems like a nice compiler-oriented tools company. Thanks A Bunch! David Young; VVI-DCS dyoung@vvi.com From marcel at system.de Fri Sep 10 04:50:12 1999 From: marcel at system.de (Marcel Weiher) Date: Thu Nov 3 14:42:17 2005 Subject: Using the XML parser Message-ID: > Another reason why I like the concept at least is that Obj-C is getting > very long in the tooth. Apple is clearly not interested in upgrading Obj-C, > so essentially we can expect the libs to remain largely the same. Yet you > can't help but wonder how much nicer AppKit would be if it was > multiple-inherited rather than protocoled (for instance) and included > garbage collection - and CF allows me to move to TOM in theory. Of course, the dynamic nature of Objective-C makes such interfaces *much* easier. For example, an interface from Squeak-Smalltalk to Objective-C took about a day to write and minimal code ( 2-3 C functions, 3 Squeak classes with a total of ~ 15 methods). Tcl was very similar, FScript (a very nice scripting language with Smalltalk-like syntax and some other interesting ideas) is also similar etc. Wrapping C-procedural APIs on the other hand is much more painful because there is no run-time information available (Lawson's GX-wrapper, anyone? :-) Marcel From helge.hess at mdlink.de Fri Sep 10 06:14:18 1999 From: helge.hess at mdlink.de (Helge Hess) Date: Thu Nov 3 14:42:17 2005 Subject: Using the XML parser References: Message-ID: <37D9042A.EBC5CA5F@mdlink.de> Marcel Weiher wrote: > > Another reason why I like the concept at least is that Obj-C is > getting > > very long in the tooth. Apple is clearly not interested in > upgrading Obj-C, > > so essentially we can expect the libs to remain largely the same. > Yet you > > can't help but wonder how much nicer AppKit would be if it was > > multiple-inherited rather than protocoled (for instance) and included > > garbage collection - and CF allows me to move to TOM in theory. Can you give an example what benefits MI would bring in this context ? Regarding GC: GNU Objective-C provides this as well. Regarding NameSpaces: could be easily added to Objective-C as well if Apple would have interest in this. > Wrapping C-procedural APIs on the other hand is much more painful > because there is no run-time information available (Lawson's > GX-wrapper, anyone? :-) I don't know how the CF API looks like, but is it really procedural ? What people seem to miss in this discussion is that Objective-C is after all done in plain C as well. Actually one can use *any* features of Objective-C from plain-C, it just looks different, eg instead of: [a blah] one can use the 'Objective-C C API' and write objc_msgSend(a, sel_getName('blah')) Of course the C API requires more work, but there is actually no functionality loss. What is gained is that this code can be used with any language without problem (eg from C++ without an ObjC++ compiler). So, personally I can imagine that the MacOSX C API is in fact an object system which might be based on the Objective-C one, therefore providing all it's features, including classes, categories and so on. If this is the case I wouldn't have any problem with a C based API. Greetings Helge -- MDlink online service center GmbH http://www.mdlink.de/ From mmarkowitz at ceiss.org Fri Sep 10 09:32:27 1999 From: mmarkowitz at ceiss.org (Maury Markowitz) Date: Thu Nov 3 14:42:17 2005 Subject: Using the XML parser Message-ID: On Thursday, September 09, 1999 7:17 PM, Ronald C.F. Antony [SMTP:rcfa@cubiculum.com] wrote: > However what chances do you think a language like TOM stands? That all depends on who supports it. If everyone here were to join the TOM mailing list and steer it in the direction of an Obj-C replacement, then I'd say it would have a big chance. > ObjC is at least 100% ANSI-C compatible, and while the step from > procedural to OOP-thinking is large, the step of learning ObjC as a > C programmer is small, and equally small to non-existent are the > issues involved with linking in legacy code with ObjC projects. TOM is essentially a modern Obj-C. It bootstrapped just like Obj-C, albiet on egcs, but now also has it's own native compiler as well. Unlike Obj-C, TOM defines it's own basic types, so full reflection is possible (ie, no void *). Yet because we all work in a c world, TOM allows pure ANSI-C blocks inside it's methods. This is a little bit different than Obj-C where the mix is purely inline, in TOM the c code is blocked in it's own {}'s. The difference is tiny, the long and short of it is that it works the same. If you're at all interested go to http://www.gerbil.org/tom/doc/why.shtml and read the portion on Extensibility. Under TOM you can categorize in new ivars, cvars, add new superclasses to existing classes, REMOVE methods, add methods, and even replace existing methods! This kicks Obj-C's butt. Apple faces a tough fight with OC, essentially it's power is hidden in non-obvious places. Unless you really use the language, it's hard to explain why it's better - and after many years in tech sales on the road, I can say that the basic rule is that if it takes more than 2 minutes to explain, you lose. Obj-C takes more than 2 minutes to explain. Comparing it to Java is even harder, because they both have the same set of buzzwords. Not so with TOM, TOM wins every buzzword war with any language you care to toss at it. Yet again, I don't expect Apple can support it directly. > But before this goes completely off topic, a little remark about > your comment that "Writing Obj-C wrappers for CF based API is trivial. > I don't think this is an issue, this should take you a few minutes to wrap." > I'd refute that. Ask the Omni people, if it was just a matter of minutes > to write wrappers around AIAT. AIAT is not a CF based API, your argument is a non-sequitur. Maury From mmarkowitz at ceiss.org Fri Sep 10 09:03:29 1999 From: mmarkowitz at ceiss.org (Maury Markowitz) Date: Thu Nov 3 14:42:17 2005 Subject: Using the XML parser Message-ID: On Thursday, September 09, 1999 9:41 PM, Scott Anguish [SMTP:sanguish@digifix.com] wrote: > Maury Markowitz wrote: > > On Thursday, September 09, 1999 3:05 PM, Marcel Weiher > > [SMTP:marcel@system.de] wrote: > > > Anyone else sickened by this? > > > > Yes and no. > > > > My take on this is that it's a little bit of slight of hand. Ask yourself > > this, is Apple trying to kill AppKit by putting stuff only in CF, or is > > Apple making a completely new "OS" (API) called CF? I believe it's the > > later. > > > Considering CF is entirely function call based, I hope not. > > > > > So we > > separate out all the cool code, stick it into CF and now both the Obj-C > > people and the Mac people can use it. > > > But Apple won't be providing a standard Objective-C API for these > calls... which means that passing them around is going to be less than clear, > > and EVERYONE gets to roll their own. > > > We've already seen the results, new API's coming out of Apple are using CF > > types. The Keychain uses them for instance, as does the MacOS side of the > So we can all write in whatever language we want, but in order to > provide Object Interfaces to these C-APIs, we have to all roll our own. > > That is so much the Mac OS Toolbox approach, and 10 years out of > date that it sickens me. Perhaps so, but one thing that has happened in the last 10 years is the open source movement. This proves, conclusively, that a community can come together and provide standardized API - even good ones some times - if there's interest in doing so. So enough bellyaching, we never expected Apple to do all the work for us in the past, and we shouldn't now. This time around we have widespread internet use to help us though. Again, I'll happy act as coordinator on this effort if you all think it's important. But if all you're going to do (not you Scott) is complain that Apple isn't doing it that's not getting anyone anywhere - indeed it will turn into exactly the problem you're talking about. Also, while I'm here, I've got a lot of e-mail asking me about TOM. Go here...http://www.gerbil.org/tom/ And please join the mailing list and make it clear that we're interested in a modern Obj-C replacement, as opposed to an entirely new system (I for instance am not terribly interested in using TOM's X stuff, I'm far more interested in using TOM against Foundation). Maury From cybergrog at bigpond.com Fri Sep 10 06:31:22 1999 From: cybergrog at bigpond.com (Greg Hulands) Date: Thu Nov 3 14:42:17 2005 Subject: Setting Up A CVS Server Message-ID: <13282362720369@domain2.bigpond.com> Does anyone know of any good websites or books which talk about setting up a CVS server. Greg From mark at jiiva.com Fri Sep 10 09:52:24 1999 From: mark at jiiva.com (Mark Ericksen) Date: Thu Nov 3 14:42:17 2005 Subject: Future of Apple Technology (Re: Using the XML parser) Message-ID: <199909101646.LAA01150@dfw-ix10.ix.netcom.com> As developers, the future of Apple's technology is of the upmost importance. Sometimes I work myself up into a small rage with Apple and their lack of communication to us about what is *really* going on with Objective-C et al. In reading the many emails on this subject I've been thinking about a "what if" scenario. What if Objective-C was to go away (or at least stop being supported). Where does that leave us developers who have been depending upon it for the last 10 years? Apple came up with the idea of Yellow Box and then Cocoa to replace OPENSTEP. If there is no more Objective-C what language to we program in? According to Apple marketing it will be Java. For now Java sits on top of Objective-C via the bridge. Even if Apple ports all the Objective-C APIs to Java, Java will still be sitting on top of the Quartz graphics library. Now, I could be wrong, but doesn't this smell like a law suit waiting to happen? Didn't Sun sue Microsoft for trying to create a Java that worked best on Windows? Isn't Apple using the Java language and providing the APIs that are written in C? Doesn't this create a platform specific advantage to those who use Java-Cocoa? So if Sun gets upset and sues Apple, where does that leave Cocoa? Will Apple just kill off Cocoa? Apple did say at the Apple Developer's conference in May that the "crown jewel" of Cocoa is the API. So what language would they implement the API in? C++? Go back to Objective-C after burning everyone for years? Or go after a new language? It seems that Apple has another "crown jewel" that they fail to recognize. That is Objective-C. After all when they purchased NeXT they purchased the rights to the language. Perhaps their marketing group can come up with another name for the language and Apple could tout it as the better, faster, natively cross-platform environment. Apple could make a few modifications to the language to give it new life. Look at the marketing success of Java! As people already suggested, Objective-C has a better migration path for legacy code since it is ANSI based, all it needs is a successful marketing campaign! Imagine: Steve Jobs enters the stage and tells the audience, "Java was a great idea. Building truly cross-platform software would have revolutionized the industry. However these goals and dreams were never realized. That is why Apple is announcing today a new development language that is built from the ground up to bring your legacy application into the next millennium and letting new applications take advantage of all the features of modern languages we've come to know and love. Today we give you ! Build on top of ANSI C it allows you to create blazingly fast code while providing a messaging syntax rivaling Smalltalk. bla bla bla..." You get my point. Alright I'm done, back to coding and wondering what I'll be doing next year! Mark Ericksen Jiiva, Inc. From ckane at apple.com Fri Sep 10 09:19:21 1999 From: ckane at apple.com (Chris Kane) Date: Thu Nov 3 14:42:17 2005 Subject: The intent behind CoreFoundation (was Using the XML parser) Message-ID: <009d01befba8$3fa04c60$9d0eca11@verbosity.apple.com> Normally when the hornets get stirred up*, I don't bother getting back into the fray, because it's unclear how relevant to actual development continuing the discussion would be, even when it's my fault (as here). But some comments on the role and goal of CoreFoundation may puts its intended use into perspective which may help when deciding whether or not to use it. I may also throw in some comments about the internal development perspective here wrt Cocoa. Let the rambling begin! [* merely descriptive imagery, not meant to be derogatory] CoreFoundation in a C-based API (and implemented in C) with a lot of the "look and feel" of facilities found previously only in the Foundation framework in Cocoa. It was and is currently developed by the same group which maintains the two principal Cocoa frameworks, Foundation and AppKit, and some other Cocoa-related technologies. The primary intent is to broaden the availability of Foundation-like APIs and data types to a wider audience: Mac OS developers and internal providers of other C-based APIs. It uses as many of the principals of OO design as practical: encapsulation/information hiding is used heavily, there is some polymorphism (CF has its own tiny simple runtime), but no subclassing generally. We could have brought the concept of abstract superclasses down to CF to get a sort of subclassibility, and a few modules do allow for something like that, but decided that that would interfere with another primary architectural goal: highest performance. If you were at the CoreFoundation talk at WWDC you heard about this. When you look at the API too, though, you definately see the influence of Mac OS APIs as well; for example, since Mac developers are (we are told) used to not dealing with seeing pointers, the pointers are often embedded in the types (you deal with CFArrayRef rather than CFArray *); or, constants are named kCFBlah, rather than CFBlah. I'm somewhat dubious of all that, but when the alternative was near-zero adoption, we compromised. The CF APIs are very consistent at least, which was another goal. And you get used to it, though it seems strange at first. [Java APIs end up being in a similar position.] CoreFoundation is what I call a "sharp tool"; it isn't safe and friendly like one might consider the Foundation APIs to be, but rather very precise and literal, a tool for intermediate to advanced programmers. For example, it tends to simply do what you tell it to do: if you ask a CFArray to remove the value at index -17, it believes that you know what you are doing, and will remove that element (even though valid indices are always non-negative) and shift all the other elements to close the gap. This may have no observable affect on the program, may corrupt memory causing a crash possibly days later, or may cause immediate program termination. What you've asked for is undefined behavior, so in a sense CF gives it to you. This is a cruel API to thrust on developers who don't type in perfectly correct code (and I myself cannot cast the first stone), so there is also a debug version of the library, which has assertions turned on and assertions all over (though even more would be useful, as is always the case). CoreFoundation also tends to not have all of the convenience APIs of the Foundation in some cases, but in other cases has some that Foundation doesn't have. So, when deciding whether or not to use CoreFoundation, you need to be aware of its sharp nature and decide if you really need the performance (if that's why you think you need to go to it) or use caution if you have to use it because it is the only source of the functionality you need, and use the debug library. Since we also develop Cocoa libraries, we went to some effort to make some types of interaction with Foundation/AppKit APIs convenient. We call this toll-free bridging, where a CFFoo can be used (eg, messaged) like an NSFoo, and an NSFoo can be used where parameters of type CFFoo are expected. They're completely interchangeable. You can even subclass NSFoo and use it like a CFFoo. Not all CF/NS types have a correspondence in the other, and not even all of those are toll-free bridged (sometimes the NSBar contains a CFBar to which messages are forwarded). It's a fair bit of hassle to do this toll-free bridging, but we think it's worth it. > [On not providing an ObjC interface to the XML parser etc.] I should have said "possibly" there will never be an ObjC version of the CFXMLParser API, rather than "likely never". Now I love Objective C more than life itself, and know it better than the back of my hand. But I'm also realistic. There are only a small number of us tasked to maintain and develop CoreFoundation, Foundation, AppKit, etc. (I won't quote a number, but it's small, trust me), so we begin to see additional APIs as additional liability; we have to maintain backwards compatibility with new APIs after all. If we change something in the CF API, then we need to go to another project and change the ObjC version, and another project and change the Java version (possibly). And because of language differences we get differences from the base API, or different constraints (for example "You can't make that change because somebody might have subclassed in ObjC and be doing XYZ." Sometimes we decide to break that anyway, because that is the least of evils, and then the people who are broken are up in arms.) [It be nice if we could "write once, deploy multiple versions" of an API, but autogenerated APIs are usually not great or don't make proper use of the target language or constrain the APIs to least-common-denominators of capabilities. But we haven't figured out how to simplify the maintainence of 3 or more APIs at once yet. We have some tools but they are complex and cumbersome.] I know what the state of the open bugs assigned to me is and how much time I have to devote to bug fixing and feature enhancement in existing APIs and how long bugs tend to wait before being fixed, and what's similarly happens with the other engineers. And I still spend most of my time having to write new code and repair the new code rather than work in the 150K lines I already am responsible for. Providing a cover API is fine as long as you don't expect bugs in it to be fixed for a release or two; but people do want bugs fixed, so providing the new API is not so appealing. Eventually we get around to things (eventually the Foundation came along; eventually we added a document architecture in the AppKit), but it takes a while, which is why I say an ObjC wrapper for CFXMLParser may not happen (or may not happen in a useful timeframe). There are a number of ancillary things that would need to be wrapped, in this case, not just the parser itself, too. We know and hear the "Apple should do it so everybody doesn't have to do it themselves" argument. And XML parsing is a big enough ticket item that an ObjC API may appear. We also hear a lot of request for (and no offense here intended to anyone) dumb or low-bang conveniences which are tied to this argument, that it colors our opinion of that argument (like, "I need a function to sort only every other object in an array and it should take a parameter to allow choosing between the even or the odd indices, and Apple should add this to the frameworks they ship so everybody doesn't have to invent it themselves.") At NeXT we never had any intent of covering all operating system or lower-level functionality with ObjC APIs (though the requests did/do come in). The same still applies. We try to do what will be potentially useful to 80%+ of apps, but we can't do everything nor are we inclined to do so. This gives us, we hope, the biggest bang for the resources we have. Perhaps though it would be a better strategy to tell people what they want to hear rather than honest assesments, and then not be able to deliver. That sort of strategy doesn't seem to have made people any happier [eg. Yellow Box for Windows licensing], though. I've gotten off of the development angle here with some self-pitying raving, for which I apologies to the list. Please decide if replies are appropriate to the discussion of Mac OS X development. Chris Kane Apple Computer, Inc. My opinions are just and merely that. From bentley at crenelle.com Fri Sep 10 11:28:02 1999 From: bentley at crenelle.com (Michael Brian Bentley) Date: Thu Nov 3 14:42:17 2005 Subject: Using the XML parser In-Reply-To: <37D9042A.EBC5CA5F@mdlink.de> References: <37D9042A.EBC5CA5F@mdlink.de> Message-ID: I concur with Ron Antony regarding the choice of direction Apple is apparently taking with regard to non-OO wrappers. Apple has always been driven by the lowest common denominator in their development APIs, with the occasional homage to objects (Open Transport API defines a few C++ classes). The advantage NeXT had that OSX doesn't have is mobility and freedom! NeXT was able to use the experiences of the early 80's to build a late 80's development environment. Apple has a large legacy community that's literally steering the company. It's like a few thousand developers compared to a couple hundred. And there's likely significant top secret work being done for the Java side. The overt Apple Java work seems sound and occasionally cool, but it doesn't get my heart started in the morning. Yet. Apple tried to do something quite clever in OpenDoc by using SOM. The results were quite, hm, indefinite when someone pulled the plug on OD. The whole of OpenDoc seemed ponderous. C++ thing. Is there a commercial need for support for Objective C? Wrappers, libraries, and so on? Can you think of dev products that use ObjC that would sell to legacy Mac OS developers? I asked on the OSX talk list in the same thread (by name), but I'll ask here too, perhaps in a more appropriate form of question: how does one address the same needs, but in Objective C, that C++ addresses with the Standard Template Library (STL)? The STL appears to have become a vital component for current C++ development projects everywhere. The biggest reason, I think, that ObjC is not going anywhere on the legacy Mac OS side is because there's nothing for the legacy Mac developer to grab onto and make work with their stuff. You'd think the upgrade path would be obvious, but for some reason it isn't. Nobody provides cool C enhancements for Metrowerks via Objective C to whet people's appetite. There's no reasonable OO cross library available for legacy Mac OS developers to use to get to Windows. YB could create critical mass by itself, Apple isn't letting that happen. The legacy Mac OS community has to be able to use it too for their stuff. I've been caught short recently, Metrowerks took out the Pascal compiler from CW Pro 5. Lots of the legacy Mac OS code I've been maintaining is at least partly written in Pascal, including the majority of the client app. My new code tends to be entirely C++, but clients still use twelve year old code. What a _mess_. -m From hordur at lausn.is Fri Sep 10 07:10:15 1999 From: hordur at lausn.is (Hordur Thordarson) Date: Thu Nov 3 14:42:17 2005 Subject: Foreign chars in ProjectBuilder Message-ID: <199909101409.OAA20872@gremlin.skyrr.is> Hi, I can?t write some foreign characters in the text editor in Project Builder - PB offers to convert them to ASCII and if so instructed, the chars turn into underscore chars. Of the 20 or so special Icelandic characters (10 upper case and 10 lower), this problem occurs with 3 characters in both upper and lower case. Can anything be done about this ? Thanks, Hordur Thordarson From kcd at jumpgate.com Fri Sep 10 12:00:31 1999 From: kcd at jumpgate.com (Kenneth C. Dyke) Date: Thu Nov 3 14:42:17 2005 Subject: [Off-Topic] Fun C++ quote In-Reply-To: References: Message-ID: <199909101900.MAA09732@babylon5.jumpgate.com> I just thought this might lighten someone's day. "If you think C++ is not overly complicated, just what is a abstract virtual base pure virtual private destructor, and when was the last time you needed one?" -- Tom Cargil in the C++ Journal -Ken --- Kenneth Dyke, kcd@jumpgate.com (personal), kcd@3dfx.com (work) Sr. Software Engineer, Cross Platform Development, 3dfx Interactive C++: The power, elegance and simplicity of a hand grenade. From phr at projectcenter.ch Fri Sep 10 12:02:08 1999 From: phr at projectcenter.ch (Philippe C.D. Robert) Date: Thu Nov 3 14:42:17 2005 Subject: Using the XML parser In-Reply-To: References: Message-ID: <9909101902.AA00448@projectcenter.ch> You wrote: > On Thursday, September 09, 1999 4:16 PM, Ronald C.F. Antony > [SMTP:rcfa@cubiculum.com] wrote: > > How about working with the GNUStep people on this? > Noooooo! Please do NOT put a GPL on anything you write! Please be careful about what you say, GNUstep is LGPL... sweet dreams, Phil --- Philippe C.D. Robert FreeBSD/Linux Hacker http://www.nice.ch/~phip From phr at projectcenter.ch Fri Sep 10 12:02:12 1999 From: phr at projectcenter.ch (Philippe C.D. Robert) Date: Thu Nov 3 14:42:17 2005 Subject: Using the XML parser In-Reply-To: References: Message-ID: <9909101902.AA00453@projectcenter.ch> You wrote: > > There will be no ObjC binding in DP2, and likely never will be. > Anyone else sickened by this? yup...;-( > Apple really seems to be going through with their crazy plan. > > Oh well, I've got an Objective-C XML-parser in development here, > currently used for object-archiving and XML-property-list parsing. If > anyone is interested in helping out, I could make it available as > OpenSource. This would be VERY cool. If you are interested, what about releasing it with GNUstep? sweet dreams, Phil --- Philippe C.D. Robert FreeBSD/Linux Hacker http://www.nice.ch/~phip From sanguish at digifix.com Fri Sep 10 21:06:52 1999 From: sanguish at digifix.com (Scott Anguish) Date: Thu Nov 3 14:42:17 2005 Subject: Using the XML parser In-Reply-To: References: Message-ID: <199909110406.AAA08458@digifix.com> Maury Markowitz wrote: > > That is so much the Mac OS Toolbox approach, and 10 years out of > > date that it sickens me. > > Perhaps so, but one thing that has happened in the last 10 years is the > open source movement. This proves, conclusively, that a community can come > together and provide standardized API - even good ones some times - if > there's interest in doing so. > Have you noticed just how little of this 'community' is left? Look at the lack of forward momentum the MiscKit has had in the last 2 years. For the longest time we had NO Foundation. MiscKit came along and filled that gap (as best as possible). Then Apple decided to make that a priority, and we got Foundation. But we also had much, much pain along the way to Foundation because of this lack of leadership on (then NeXT's) part. Ask yourself this.. will CF's XML parser have a Java interface? > So enough bellyaching, we never expected Apple to do all the work for us > in the past, and we shouldn't now. Low level objects like this, I think it IS Apple's responsibility to provide. Especially when it consists of virtually no effort on their part aside from sitting down and hashing out the API. The development effort is minimal. Getting a third party solution widely adopted on the other hand, is not. I don't hold any grudge against Chris or Ali for their choice.. just I'd like to see it corrected. :-) From don at misckit.com Fri Sep 10 22:20:35 1999 From: don at misckit.com (Donald A. Yacktman) Date: Thu Nov 3 14:42:17 2005 Subject: Using the XML parser In-Reply-To: <199909110406.AAA08458@digifix.com> References: <199909110406.AAA08458@digifix.com> Message-ID: <9909110520.AA05333@misckit.com> You wrote: > Have you noticed just how little of this 'community' is left? Look > at the lack of forward momentum the MiscKit has had in the last 2 years. That's not _just_ the community. It is partly my fault... ...after a string of several disasters (various key hard drives dying and worse), plus being swamped at work, it has been hard to get the next (very long overdue) releases out. I *do* have enough submitted material to justify both a new NEXTSTEP and a new OPENSTEP/MOSXS release. Now if I hadn't had all these delays, excitement over the kit might not have waned as much as it has. Hopefully someday I'll get my act together...and all that will change. However, there's also truth in what Scott is saying: a lot of the key people who comprised the original set of MiscKit authors have moved on to other pastures and are no longer paying one whit of attention to Apple. Any "revival" of the MiscKit will happen with (for the most part) new blood. (I'd personally like to have the next release include the opening up of a public CVS repository and a bug tracking database. I'm not quite done setting all this up yet...but it is coming, and hopefully with the next release...) -- Later, Don Yacktman don@misckit.com From sanguish at digifix.com Fri Sep 10 23:13:02 1999 From: sanguish at digifix.com (Scott Anguish) Date: Thu Nov 3 14:42:17 2005 Subject: Adding file extensions to an app on the fly Message-ID: <199909110614.CAA09321@digifix.com> I'm working on an app that has an extendable architecture... adding new bundles would allow you to deal with more file types... I need to be able to add these new file types to the list that the Workspace allows to be opened automatically by the application (which will load the correct bundle at runtime). I'm thinking that maybe the only way to do this that won't require modifying the data in the app wrapper directly is by creating filter services... BUT... some of the types that I'm going to need to deal with can have 'compound' file-extensions and would need to be recognized as being distinct from a file that has only the single trailing extension. As a practical example... I'd want a different bundle to be activated if it was fed a .tar.gz than if it was just a .gz The other concern is how Workspace will interact with the compound files... I suppose I could have just one massive services entry for all the file types, which I could build on the fly and save in the ~/Library/Services when a user launches the app for the first time.. then I could determine the appropriate action to take after my app gets launched.. that way I can put all the granular stuff there... Any comments? Please? From bbum at codefab.com Sat Sep 11 00:13:05 1999 From: bbum at codefab.com (Bill Bumgarner) Date: Thu Nov 3 14:42:17 2005 Subject: Using the XML parser Message-ID: <199909110616.BAA15759@wellington.friday.com> It isn't just that the community fragmented, but also that we haven't had a consistent set of APIs or ***publically accessible*** vision for the future of the OpenStep/Macintosh platform. Note the emphasis there. Consider Darwin; for all intents and purposes, any effort at the kernel/driver layer down is wasted-- Apple has openly discussed that the kernel/driver layers are being replaced in OS X Client and that that work will migrate to Darwin and OS X Server. The same can be said for pretty much the entire line of NeXTSTEP/OpenStep technologies-- they are all in flux right now. It is very hard to motivate oneself to undertake any kind of community project at this point in time-- any effort put forth now will have to be largely revisited in the very near future. This isn't necessarily a bad thing. Actually, all things considered, I would rather be in the situation we are in now than where we were, say, three years ago in the NeXT community OR the Macintosh community. In the NeXT community, we had insanely great programming tools, but absolutely nobody in the marketplace cared.... In the Apple community, we had an insanely great UI and user community, but the development community had been promised Major Changes since '89-- but NOTHING ever came to fruition. Though there have been growing pains... though some of the technologies that are resulting are not exactly what some of us idealists would like to see... the path being taken will very likely result in Apple releasing what could be considered to be a pretty damned impressive achievement: The first commercial operating system with a large suite of productivity applications that is actually stable and quite potentially secure (when set up correctly). For the NeXT community, this means that folks like Andy Stone will be able to ship great applications into a third party market that actually exists. Stone Design -- a 2.5 person software house -- will be able to leverage the OpenStep/Yellow/Cocoa/Quartz technologies to effectively be able to build products that compete directly with Adobe. That's cool! For the Apple community, it means that Macintosh developers will actually be able to develop software on an API and operating system that isn't 15 years old... that they will finally be able to take advantage of some truly killer modern computing technology in an environment that won't crash/freeze/require-a-reboot every time you look at it funny. For the rest of us, it means that we will have a platform that: - runs a plethora of excellent apps, tools, games, etc... - is a consumer system that is *way* more stable than any other commercial platform out there - is incredibly flexible and is running on some very exciting hardware And, most importantly, the technology has a very bright future. OS X Server/Client is a really well designed system from the top to the bottom-- from the user to the system bus. It is modular; that means that bits and pieces can be easily augmented to take advantage of new technologies that haven't even been dreamed of yet! It is flexible; it can play a server role... it can play a client role... it can be a multi-headed monster of a desktop machine... or it can serve as a great environment for lightweight portables. Finally-- and very important-- it leverages standards without being mired in standards; it will leverage XML, PDF, HTML, HTTP, QuickTime, etc... but it is built in a fashion that *none* of these technologies are truly inseparable from the system. And when it comes, I suspect that the developer communities will be back in full force... that once we have the APIs in a form where they are on our primary desktops, there will be a lot of developers quite willing to contribute to various community projects. With the openness of the system, we are going to see a rich array of very interesting projects-- who wouldn't want to build out their cool idea/experiment/research project/thesis system in an environment where all of those standards come for free? b.bum (BTW: No, I didn't forget Linux in the above.... Linux is wonderful-- we use Linux in production systems on a regular basis. I have used and-- will use it again-- as a desktop OS many times. However, Linux is *not* a consumer operating system-- it has come a long, long way, but the human interaction experience is just not there yet. Nor does it have the applications. It'll happen... but it is going to take time. Same with Be-- very cool technologies there, as well. Lots of compelling reasons to use it for certain niche markets. As it stands, it is *not* a consumer desktop environment by any stretch of the imagination) From mark at jiiva.com Sat Sep 11 09:29:39 1999 From: mark at jiiva.com (Mark Ericksen) Date: Thu Nov 3 14:42:17 2005 Subject: Using the XML parser Message-ID: <199909111623.LAA01942@dfw-ix13.ix.netcom.com> > Stone Design -- a 2.5 person software house -- will be able to leverage the > OpenStep/Yellow/Cocoa/Quartz technologies to effectively be able to build > products that compete directly with Adobe. That's cool! So can you explain what "Cocoa" will be in five years from now? This is my biggist hangup. CoreFoundation is written in C. AIAT is written in C++ I believe. Foundation is written in Objective-C with Java wrappers. TextEdit is written in Java (using AppKit) The Finder will be written for Carbon. Will I be able to access an Objective-C API for the Finder or will I have to know C++? Is Objective-C worth programming in if it may go away? There is no clear standard for what technologies we as developers will need to know in order to write a Cocoa application. Yes, for now there is Objective-C and I hope it stays (only because I love it and know it so well). But other Mac programmers may not know Objective-C or care about it so they are screaming to keep their C or C++ libraries and all of Carbon. I worry about the coherency of the various APIs and the ability to write a fully integrated application using all of Apple's technologies. This mybrid of languages in the system may be of concern with those wanting to write applications. Some may say this is a good thing to have the choice. But it is also a larger learning curve for someone not familiar with a particular language, let alone the APIs and design patterns that go along with them. Especially if there are three to four languages, APIs, and patterns to learn just to write one app. I'm not suggesting Apple drop all other languages and go with one, but I've been waiting to start writing a few desktop apps, just wondering what the right language (etc.) will be and how I'll be able to access other system functions and features before I start spending time and money. I bet you that in a few years after MacOS X Personal Edition is out Apple will start dropping one of the languages to simplify things. Any guesses as to which one will be first? Cheers, Mark Ericksen BTW, I really do love the new OS, just need continued communication from Apple leadership... From bentley at crenelle.com Sat Sep 11 10:39:12 1999 From: bentley at crenelle.com (Michael Brian Bentley) Date: Thu Nov 3 14:42:17 2005 Subject: Using the XML parser In-Reply-To: <199909110616.BAA15759@wellington.friday.com> References: <199909110616.BAA15759@wellington.friday.com> Message-ID: To me, a living implementation language has really good libraries, and the language undergoes change. A good implementation language doesn't change that much., but it does appear to change some because requirements change and our knowledge of how things are done improve with time. Objective C doesn't appear to have changed much in the last ten years, which is both good and bad, and perhaps unnatural. It also doesn't seem to have many users, and the only libraries I can find and use appear to belong to Apple. Right now there is no strong case for learning Objective C stated anywhere. One of the things I'd have thought would make sense is to provide some easy migration for C developers to use objects. Remember when C++ was supposed to be an easy migration path for C developers to employ objects? There's no such migration path exploited on the legacy Mac OS side, yet there's a HUGE amount of C code out there. Apple is steering a very overloaded bus filled with legacy Mac OS developers. The burden of the pre-Carbon code base is immense. You can get these folks' attention with working compilers, working libraries (an easier-to-fathom equivalent of STL would go a lonnnng way, by this I mean the classes, not the template mechanism), and some PR. And maybe it is time for Objective C to add a new feature or two; it may not take much at all to get people's attention. I'd have to say that Objective C gathers zero interest because there are no libraries for it where the developers are, but there is tremendous library support for C and C++, some of it nicely cross-platform. Nothing out there takes advantage of the fact that adding way cool stuff to C code is very easy, turns it into Objective C--which is beneficial! (Somehow.) -m From phr at projectcenter.ch Sat Sep 11 11:42:12 1999 From: phr at projectcenter.ch (Philippe C.D. Robert) Date: Thu Nov 3 14:42:17 2005 Subject: Using the XML parser In-Reply-To: References: Message-ID: <9909111842.AA01009@projectcenter.ch> You wrote: > years, which is both good and bad, and perhaps unnatural. It also > doesn't seem to have many users, and the only libraries I can find > and use appear to belong to Apple. Not quite true, GNUstep doesn't belong to Apple and neither the ObjC bindings for gtk. I just mention this to encourage people to have a look at GNUstep. Version 0.6.0 "Dawn" has been released these days! sweet dreams, Phil --- Philippe C.D. Robert FreeBSD/Linux Hacker http://www.nice.ch/~phip From dyoung at vviuh221.vvi.com Sat Sep 11 12:56:25 1999 From: dyoung at vviuh221.vvi.com (David Young) Date: Thu Nov 3 14:42:17 2005 Subject: Using the XML parser References: Message-ID: <9909111956.AA08245@vviuh221.vvi.com> > I'd have to say that Objective C gathers zero interest because there > are no libraries for it where the developers are, but there is > tremendous library support for C and C++ Many of the c++ libraries out there are redundant and/or superficial. Also, there are obj-c based libraries. Apparently you aren't aware of any of them. Also, you can link any c or c++ lib. into an obj-c based app. So those are suitable consumables for obj-c apps. > So can you explain what "Cocoa" will be in five years from now? Yes, indeed I can: "Five years from now Cocoa will be whatever Apple thinks it wants at the time and what developers will be porting to". You can quote me on that, although the name Cocoa may change. > Objective C doesn't appear to have changed much in the last ten > years Do you use distributed objects with in/out/bycopy argument extensions? Categories? Don't try to rewrite history! Thanks A Bunch! David Young; VVI-DCS dyoung@vvi.com From cmh at greendragon.com Sat Sep 11 15:20:54 1999 From: cmh at greendragon.com (Chris Hanson) Date: Thu Nov 3 14:42:17 2005 Subject: Localization In-Reply-To: <199909081633.JAA02507@tarbell.jpl.nasa.gov> References: <199909081633.JAA02507@tarbell.jpl.nasa.gov> Message-ID: At 9:56 AM -0700 9/8/99, Mark Tarbell wrote: >(It would be nice if there were an alternative to this based on a single set >of .nib files. You can programmatically update text fields, buttons, etc., If nibs go XML as Apple's said they will, this should be really easy (as long as they're *real* UTF-8 or UTF-16 XML). Just build some sort of processing tool to auto-generate localized nibs from a string table and a reference nib. From bentley at crenelle.com Sat Sep 11 16:38:56 1999 From: bentley at crenelle.com (Michael Brian Bentley) Date: Thu Nov 3 14:42:17 2005 Subject: Using the XML parser In-Reply-To: <9909111956.AA08245@vviuh221.vvi.com> References: <9909111956.AA08245@vviuh221.vvi.com> Message-ID: >Many of the c++ libraries out there are redundant and/or superficial. Also, >there are obj-c based libraries. Apparently you aren't aware of any of them. I know about GNUStep, which appears to work only with Linux. I think something is needed to help get Mac OS developers interested in using Objective C. Perhaps someone can name some Objective C libraries that can be used to build Mac OS 8 apps? This is part of what I'm asking for. The GNU Objective C Class Library, for example, isn't certified on Mac OS, but aside from that there doesn't seem to be that much in it. >Also, you can link any c or c++ lib. into an obj-c based app. So those are >suitable consumables for obj-c apps. Why would a Mac OS developer do that? > > Objective C doesn't appear to have changed much in the last ten > > years > >Do you use distributed objects with in/out/bycopy argument extensions? >Categories? Don't try to rewrite history! I don't use ObjC for much of anything, much less legacy Mac OS projects. There's little out there for the old OS to work with. Also, even though as you say there have been changes, as far as I can tell Objective C hasn't changed much since 1986, according to the documents I've been able to find so far, among the many orphaned web links. ObjC is not in the legacy MacOS literature... I personally have a desire to be able to work with the language on substantive projects, and I can do that right now on OSXS, but I think that unless the rank and file of Mac OS developerdom actively express an interest, Apple at least seems to emphasize Java, and Metro of course emphasizes C, C++ and Java. Maybe the name Objective C should be changed to Messenger; objective languages are "a dime a dozen" but a message-based language is more unique and cool and helps to explain that "wierd non-C++ like syntax." Also, that way, nobody shoots the messenger. Ah-heh. I just called a