The Aqua HI Guidelines fall short in my opinion. There are a lot of things which it doesn't address.
For example the behavior of NSLayoutManager still doesn't follow Mac conventions for selecting text. Also the behavior of commands like "Save" and "Revert" change depending if the file primitive you're using is an FSRef or POSIX file path.
As for OpenOffice I warn that the absolute WORST interface is one which looks like a Mac but doesn't behave like a Mac.
You can still write custom WDEFs and similar code fragments in OS X. The original mp3 player in DP4 used a WDEF. The main difference is it used a WDEF bundle instead of a WDEF resource.
Also if you want to patch apps there is a tool available called APE which does exactly this.
I wish the Aqua HI guidelines pointed out the proper behavior of the "Save" command. Currently there is no conformity. The behavior of this and similar commands depends what runtime object is used as the file primitive. Specifically if you use an FSRef or NSDocument it will behave one way, but if you use a POSIX file path it will behave another way. So for example TextEdit behaves differently than SimpleText or Sketch.
Oh well, one of the HI issues which blows over the head of every UNIX user.
You can make X11 apps look like Aqua apps, but you'll never make them BEHAVE like Aqua apps.
Thus you will end up witht he WORST possible combination: Apps that look like Aqua which imply the Aqua behavior but instead behave like craptastic X11 apps.
Most of the problems you talk about are due to UNIX being a piece of crap.
UNIX filesystems don't support file attributes which weren't invented 30 years ago and they follow the stupid methodology that everything-is-a-file-found-at-a-static-path.
Apple however deprecated toolbox functions which used file paths long ago so Mac OS apps don't care where files are located. You can even move the System Folder anywhere you want. No longer however, thanks to UNIX and it's ugly sibling Cocoa |-p
Multiple monitor support has been around a lot earlier than that, I've used it since the MacSE with the Radius 20" b+w monitor adaptor (via a coax cable). It allowed both screens to be used just like now.
NeXTSTEP might be easier to develop for, but I find Cocoa apps a pain to use. The problem is NeXT programmers have been fooled into thinking they don't have to consider HI design when developing their apps, thinking instead that the app framework will take care of that for them.
So it's just a shim? That defeats the whole point |-p
Also, when the hell is GPG going to use CDSA, multiple keychains suck
Re:What does this mean for OS X?
on
GCC 3.2 Released
·
· Score: 1
I think you better read my post again, I didn't talk about the abilities of ObjC. I happen to like ObjC, a lot (although I don't like Cocoa for various reasons).
IIRC the northbridge chip in all new world macs is on the daughtercard and can be replaced along with the CPU. These boards could be next-generation-CPU-ready.
The benchmarks are also poor. They appear to mainly be CPU dependent, not memory bandwidth dependent.
Does GPG use a framework bundle yet, or is it still suck in/usr?
A framework is a lot easier to manage especially since I can put it in my own ~/Library/Frameworks/
Re:What does this mean for OS X?
on
GCC 3.2 Released
·
· Score: 2, Interesting
I'm sure Apple decided to use 3.1 based on the API being stable, so they've gotten the rug pulled from under them!
The problem isn't only system libraries which are based on C++ but their developer tools which use gcc 3.1. This means when Apple moves to 3.2 they will have to inform everybody that all their libraries will also have to be redistributed with their programs.
In the meantime I worry that bugs in 3.1 which are fixed in 3.2 will be difficult to merge with 3.1 which only Apple will be using. What a pain |-\
I'm not sure if drivers are effected because they use a limited C++ subset. If they are Apple will probably maintain 3.1 for a long time, even though they will be the only ones doing it |-\ Anyway, there is no telling if 3.2 is stable either!
Slashdot Mirror
The Aqua HI Guidelines fall short in my opinion. There are a lot of things which it doesn't address.
For example the behavior of NSLayoutManager still doesn't follow Mac conventions for selecting text. Also the behavior of commands like "Save" and "Revert" change depending if the file primitive you're using is an FSRef or POSIX file path.
As for OpenOffice I warn that the absolute WORST interface is one which looks like a Mac but doesn't behave like a Mac.
Use this to patch OS X apps (Carbon and Cocoa):
http://www.unsanity.com/haxies/ape/
Step 2: STOP BITCHING!!!!!
You can still write custom WDEFs and similar code fragments in OS X. The original mp3 player in DP4 used a WDEF. The main difference is it used a WDEF bundle instead of a WDEF resource.
Also if you want to patch apps there is a tool available called APE which does exactly this.
The problem is Cocoa apps in OS X ignore the 'layo' resource making skinning absolutely useless |-p
I wish the Aqua HI guidelines pointed out the proper behavior of the "Save" command. Currently there is no conformity. The behavior of this and similar commands depends what runtime object is used as the file primitive. Specifically if you use an FSRef or NSDocument it will behave one way, but if you use a POSIX file path it will behave another way. So for example TextEdit behaves differently than SimpleText or Sketch.
Oh well, one of the HI issues which blows over the head of every UNIX user.
You can make X11 apps look like Aqua apps, but you'll never make them BEHAVE like Aqua apps.
Thus you will end up witht he WORST possible combination: Apps that look like Aqua which imply the Aqua behavior but instead behave like craptastic X11 apps.
Die X11, DIE
Most of the problems you talk about are due to UNIX being a piece of crap.
UNIX filesystems don't support file attributes which weren't invented 30 years ago and they follow the stupid methodology that everything-is-a-file-found-at-a-static-path.
Apple however deprecated toolbox functions which used file paths long ago so Mac OS apps don't care where files are located. You can even move the System Folder anywhere you want. No longer however, thanks to UNIX and it's ugly sibling Cocoa |-p
The difference is the OS X apps actually behave the same.
Mac OS X has human interface guidelines, the others you mention are just toolkits.
Oh please, drag+drop text is a hell of a lot faster. It doesn't use the keyboard and only requires one button.
Although Cocoa apps are still semi-broken with D+DT. I wish Apple would fix that.
A similar tool for Digital TV to enable recordings would be cool.
Except that would be illegal. Same situation if in the future MOL could run AmigaOS4 and you wanted to runn it on your non-Amiga PPC.
You can use MOL to run LinuxPPC on LinucPPC on a non-Mac however.
Except you can't write to NVRAM without root in the first place.
You moron...
> I won't buy a new one until they change there ways.
Oh please, you just can't afford one with the feature. I've seen posts like this for decades and they're all LIES.
BTW it's their, not there
Multiple monitor support has been around a lot earlier than that, I've used it since the MacSE with the Radius 20" b+w monitor adaptor (via a coax cable). It allowed both screens to be used just like now.
NeXTSTEP might be easier to develop for, but I find Cocoa apps a pain to use. The problem is NeXT programmers have been fooled into thinking they don't have to consider HI design when developing their apps, thinking instead that the app framework will take care of that for them.
I don't see how you can separate the two.
If something is more difficult to use it is inherently less useful.
Apple is just being lazy.
The only time you really need to reboot is if the kernel is updated. You can force quit the updater app if you want to bypass it.
That pretty much kills any interest I could have had with GPG.
OS X has a trust framework which ought to be used or else it's just a 5th wheel. If I wanted Linux chaos I would use it.
"access the functionality of"?!
So it's just a shim? That defeats the whole point |-p
Also, when the hell is GPG going to use CDSA, multiple keychains suck
I think you better read my post again, I didn't talk about the abilities of ObjC. I happen to like ObjC, a lot (although I don't like Cocoa for various reasons).
So AHEM YOURSELF! (fucker)
But will it use CDSA?
I'm not interested in having to open two separate keychains.
IIRC the northbridge chip in all new world macs is on the daughtercard and can be replaced along with the CPU. These boards could be next-generation-CPU-ready.
The benchmarks are also poor. They appear to mainly be CPU dependent, not memory bandwidth dependent.
Does GPG use a framework bundle yet, or is it still suck in /usr?
A framework is a lot easier to manage especially since I can put it in my own ~/Library/Frameworks/
I'm sure Apple decided to use 3.1 based on the API being stable, so they've gotten the rug pulled from under them!
The problem isn't only system libraries which are based on C++ but their developer tools which use gcc 3.1. This means when Apple moves to 3.2 they will have to inform everybody that all their libraries will also have to be redistributed with their programs.
In the meantime I worry that bugs in 3.1 which are fixed in 3.2 will be difficult to merge with 3.1 which only Apple will be using. What a pain |-\
I'm not sure if drivers are effected because they use a limited C++ subset. If they are Apple will probably maintain 3.1 for a long time, even though they will be the only ones doing it |-\ Anyway, there is no telling if 3.2 is stable either!
Mac OS 9 runs on top of Classic. It's a virtual machine. It's similar to VPC on Windows.
I don't know WTF you mean by "the real deal" or "controlled", such terms are meaningless.