1) GNUStep Foundation has been 100% complete for a long time. There is no reason to use Apple's implementation.
2) CoreFoundation isn't 100% open source. The closed source version supports the extremely useful FSRef data type while the open source version does not.
3) There is an open source implementation of a JavaGNUStep bridge so there is no need for Apple's bridge.
4) Java sucks. It's amazing how Sun got everything wrong considering how hard they tried to copy OpenStep.
It is IMPOSSIBLE to write 100% Java apps which behave like Mac apps. It lacks something equivalent to FSRefs or NSDocument whereby the app won't lose track of a file if its path changes. Swing doesn't help at all. All Swing does is make it possible to make Java apps which kinda look like Aqua, but don't behave like Aqua. This is the worst possible combination IMO.
Carbon isn't "transitional" and it isn't any older than NeXT APIs. Want to use FSRefs? Want to use Aliases or FileIDs? Want to use keychain? You have to use Carbon. In fact well written Carbon apps are faster than well written Cocoa apps. he problem with most Carbon apps is they use deprecated APIs like the Event Manager instead of Carbon events. In fact Cocoa is a front-end for Carbon/POSIX/BSD/Quartz (although I wish it were less POSIX and more Carbon).
I actually prefer to code using Objective-C, but I also prefer using Carbon apps.
KDE and Gnome are being ported by Open Darwin and FINK.
If you want to burn CDs you can compile cd-record or cdrdao which have their own drivers. IOKit provides the CD and DVD classes of devices which cdrdao and cd-record communicate with (in user-space).
1) Aqua is not code. It's a human interface specification.
2) Nothing interacts with Open Firmware. OF is turned off once the kernel is loaded.
3) How the hell would anything running in user-space interact with any hardware directly?!
4) It is possible provided Apple's binaries don't check for a specific machine type. If it does you'll have to pretend to be that machine type. I'm running OS X on an unsupported clone so currently I doubt it does any such check. However if everybody were to do this I doubt Apple would survive and Mac OS X would die.
As good as it can get considering it's impossible to make 100% Java apps which behave like Mac apps.
I wish Apple would give the user a choice of which L&F to use so it's easier to differentiate (and avoid) Swing apps. You can change the default to Metal instead of Aqua which helps in most cases.
Supporting an extra ABI isn't difficult at the execution level provided you have a separate set of libraries or shims like they do for PEF binaries now. That's also how you can run 32 and 64bit apps on the same system.
But what now? Another set of shims?
The whole situation is ridiculous. They should use PEF/CFM natively.
If Apple would just use CFM/PEF natively we woudln't need the PEF shim crap for PEF Carbon apps.
I mean where does Apple go from here? Do they create a 3rd spec so they have to upkeep two non-native formats? Will they have to create three sets of libraries or shims?
Apple supposedly saved some time using Mach-O because they wouldn't have to rewrite their linker to use CFM/PEF. If we're going to hack Mach-O so it uses the standard PowerPC ABI why not just support PEF/CFM?!
There are many reasons for this. Not only are there tools already available to handle PEF/CFM, you wouldn't need the whole PEF interpreter w/shim libraries to run PEF Carbon apps!
You can't generalize SIMD performance, or any form of benchmarking for that matter. I was never a fan of SPEC because it doesn't tax the branch predictor like normal applications do.
VMX (AltiVec) also has operators which aren't really SIMD but are very useful, like permute which takes two 16-byte streams and creates a 3rd using a combination of the previous two.
The problem here is you're talking about monolithic applications which are designed to be used solo. The very reason it takes to long to learn how to use these interfaces is due to the fact they are designed and run in a vaccuum.
The larger problem with human interfaces in computing is when using more than one application where their interfaces suggest they are each running in their own emulator. Even applications which use the same API suffer from this problem. I prefer to use Carbon apps in Mac OS X because of this. All the Cocoa apps I use behave differently from each other. For example some of them use drag+drop wells which really suck and are inconsistent with each other.
Yea, but then people assume I'm trolling if I say shit too often |-)
My G4 broke some time ago so I'm not in a position to develop anything ATM. A bit frustrated right now. Not that I don't have a long enough dev to-do list as it is.
The master plan is to port this horrible, horrible program to Quartz, then add Aqua-looking widgets. The result will be an app which is organized and behaves the same as it does now. That is if there is any organization to this interface...
C'mon people, this is Sun Microsystems we're talking about! Doesn't anybody remember CDE?
Sun has NO CLUE WHATSOEVER when it comes to human interface design. I mean look at their Swing apps for crissakes! All they do is try to copy current designs, and they aren't even as good at that as Microsoft is!
The current plan SUCKS and nobody should waste their time propping up these pieces of poop AKA OpenOffice's views, controllers, and 'design' (if you can call it that without offending developers who have actually designed interfaces).
What we REALLY want are not the views and controllers which are poop, but rather Open Office's MODEL which can import/export Microsoft formats! Port THIS to Cocoa and then create native views and controllers!
This in turn could be ported back to GNUStep so people trying to use this piece of poop on other platforms don't have to suffer as much.
Slashdot Mirror
1) GNUStep Foundation has been 100% complete for a long time. There is no reason to use Apple's implementation.
2) CoreFoundation isn't 100% open source. The closed source version supports the extremely useful FSRef data type while the open source version does not.
3) There is an open source implementation of a JavaGNUStep bridge so there is no need for Apple's bridge.
4) Java sucks. It's amazing how Sun got everything wrong considering how hard they tried to copy OpenStep.
It is IMPOSSIBLE to write 100% Java apps which behave like Mac apps. It lacks something equivalent to FSRefs or NSDocument whereby the app won't lose track of a file if its path changes. Swing doesn't help at all. All Swing does is make it possible to make Java apps which kinda look like Aqua, but don't behave like Aqua. This is the worst possible combination IMO.
Carbon isn't "transitional" and it isn't any older than NeXT APIs. Want to use FSRefs? Want to use Aliases or FileIDs? Want to use keychain? You have to use Carbon. In fact well written Carbon apps are faster than well written Cocoa apps. he problem with most Carbon apps is they use deprecated APIs like the Event Manager instead of Carbon events. In fact Cocoa is a front-end for Carbon/POSIX/BSD/Quartz (although I wish it were less POSIX and more Carbon).
I actually prefer to code using Objective-C, but I also prefer using Carbon apps.
KDE and Gnome are being ported by Open Darwin and FINK.
If you want to burn CDs you can compile cd-record or cdrdao which have their own drivers. IOKit provides the CD and DVD classes of devices which cdrdao and cd-record communicate with (in user-space).
Another reason to use CodeWarrior is CFM/PEF is more efficient than dyld/Mach-O, especially for C.
But Darwin's kernel, xnu, isn't a microkernel.
The BETATESTERII product costs a lot less. Check it out for yourself:
http://www.morphos-news.de/
1) Aqua is not code. It's a human interface specification.
2) Nothing interacts with Open Firmware. OF is turned off once the kernel is loaded.
3) How the hell would anything running in user-space interact with any hardware directly?!
4) It is possible provided Apple's binaries don't check for a specific machine type. If it does you'll have to pretend to be that machine type. I'm running OS X on an unsupported clone so currently I doubt it does any such check. However if everybody were to do this I doubt Apple would survive and Mac OS X would die.
Amazing! It runs OSs which don't exist yet? WOW!
As good as it can get considering it's impossible to make 100% Java apps which behave like Mac apps.
I wish Apple would give the user a choice of which L&F to use so it's easier to differentiate (and avoid) Swing apps. You can change the default to Metal instead of Aqua which helps in most cases.
It actually has practical uses. For example type this:
If only Apple would fix drag gestures in NSLayoutManager, especially drag down on the left side versus the right side.
Note that their CFM/PEF compatibility layer isn't in Darwin. I wonder how inefficient THAT is!
So what ABI will the libraries use?
Supporting an extra ABI isn't difficult at the execution level provided you have a separate set of libraries or shims like they do for PEF binaries now. That's also how you can run 32 and 64bit apps on the same system.
But what now? Another set of shims?
The whole situation is ridiculous. They should use PEF/CFM natively.
If Apple would just use CFM/PEF natively we woudln't need the PEF shim crap for PEF Carbon apps.
I mean where does Apple go from here? Do they create a 3rd spec so they have to upkeep two non-native formats? Will they have to create three sets of libraries or shims?
Not very forward-thinking Apple.
Apple supposedly saved some time using Mach-O because they wouldn't have to rewrite their linker to use CFM/PEF. If we're going to hack Mach-O so it uses the standard PowerPC ABI why not just support PEF/CFM?!
There are many reasons for this. Not only are there tools already available to handle PEF/CFM, you wouldn't need the whole PEF interpreter w/shim libraries to run PEF Carbon apps!
Or he considered the ammount of tape he had and decided it would be too costly |-p
I disagree.
Widgets do not make a human interface. You been a higher level of abstraction which encompasses the behavior of apps, like GNUStep.
You can't generalize SIMD performance, or any form of benchmarking for that matter. I was never a fan of SPEC because it doesn't tax the branch predictor like normal applications do.
VMX (AltiVec) also has operators which aren't really SIMD but are very useful, like permute which takes two 16-byte streams and creates a 3rd using a combination of the previous two.
The problem here is you're talking about monolithic applications which are designed to be used solo. The very reason it takes to long to learn how to use these interfaces is due to the fact they are designed and run in a vaccuum.
The larger problem with human interfaces in computing is when using more than one application where their interfaces suggest they are each running in their own emulator. Even applications which use the same API suffer from this problem. I prefer to use Carbon apps in Mac OS X because of this. All the Cocoa apps I use behave differently from each other. For example some of them use drag+drop wells which really suck and are inconsistent with each other.
http://developer.apple.com/technotes/tn/tn1150.htm l
HFS+ isn't POSIX compliant since it preserves case, but doesn't allow two files with the same filename sans case to exist in the same directory.
Furthermore there are a lot of neat HFS+ features which can only be accessed via Carbon.
You can read the HFS Plus technote and see for yourself.
Personally I won't use a filesystem which doesn't support FileIDs, thus I'm pretty much limited to HFS+.
Yea, but then people assume I'm trolling if I say shit too often |-)
My G4 broke some time ago so I'm not in a position to develop anything ATM. A bit frustrated right now. Not that I don't have a long enough dev to-do list as it is.
The master plan is to port this horrible, horrible program to Quartz, then add Aqua-looking widgets. The result will be an app which is organized and behaves the same as it does now. That is if there is any organization to this interface...
C'mon people, this is Sun Microsystems we're talking about! Doesn't anybody remember CDE?
Sun has NO CLUE WHATSOEVER when it comes to human interface design. I mean look at their Swing apps for crissakes! All they do is try to copy current designs, and they aren't even as good at that as Microsoft is!
The current plan SUCKS and nobody should waste their time propping up these pieces of poop AKA OpenOffice's views, controllers, and 'design' (if you can call it that without offending developers who have actually designed interfaces).
What we REALLY want are not the views and controllers which are poop, but rather Open Office's MODEL which can import/export Microsoft formats! Port THIS to Cocoa and then create native views and controllers!
This in turn could be ported back to GNUStep so people trying to use this piece of poop on other platforms don't have to suffer as much.
Apparently you haven't seen other applications Sun has authored!
Nothing is more true than the fact Sun has NO CLUE when it comes to human interface design!
What they should do is port the MODEL to Cocoa then let others write the views and controllers.