This is Sun we're talking about. Do you think they have a clue about interface design?
What about porting the MODEL to Cocoa instead? You can currently import html into your richtext document, if I could do the same with Microsoft documents all Cocoa apps could easily benefit.
Well there is an issue and that is what to call it. Apple should allow both companies to call it VMX (which was the original name for it) or Velocity Engine (which is a stupid name).
You could also call it the PowerPC's VPU after CPU and FPU, but it's so much better than any other VPU that's on the market and does unique things like the permute operator.
Apple developed the ISA and ABI first and probably had a hand in the silicon too. Apple called it VMX, not IBM. IBM didn't have anything to do with it until now.
If Apple were smart they would allow IBM to call it VMX or VE so there would be less confusion.
Tk doesn't have the abstraction to allow Tk apps to magically behave like Mac apps. You can make them LOOK like Aqua, but that creates the worst possible combination.
Perhaps this could be used to replace Tk. Non-OS X versions could use GNUStep.
whether the interface of your app is going to SUCK.
The NeXT APIs are easier to develop for in my opinion, however speaking as a user I have yet to use a Cocoa app I like. Nearly all apps I use in OS X are Carbon. This is mainly due to the schizophrenic nature of OS X which I believe will only improve if Apple makes the Aqua HI Guidelines more specific. I don't think NeXT even had guidelines, but rather (falsely) assumed the API abstraction would take are of this.
Comparing SimpleText (Carbon) with TextEdit reveals most of the differences (and most of the reasons Cocoa apps get on my nerves, like the behavior of NSLayoutManager).
You should also consider PowerPlant which I still use.
I would also add that Apple shouldn't have adopted Swing unless they could convince Sun to make the API more platform neutral. Don't use it.
FSRefs are an arbitrary 80 byte runtime reference for a file. For HFS+ it may per chance be comprised of a volume name and FileID but that's completely irrelevant because you're not supposed to store FSRefs and with Mac OS X not supposed to pass them to other processes. With UFS, FSRefs behave exactly the same as HFS+. I don't know the internal structure of the FSRef in Mac OS X w/UFS, but I really don't care either. It currently works.
You're probably thinking about Aliases in which case you would be correct. Aliases are anarbitrary description of how to find a file and on UFS volumes they break like symlinks, which again follows the specification. You can make Aliases on HFS+ volumes which also break like symlinks, just store the path and use null for the FileID and host FolderID.
As for selection I find the Mac selection behavior by FAR superior since 19 times out of 20 I don't want the trailing linefeed and when I do I can always add it after pasting (or dragging) by pressing return. The problem is even worse if you try drag+drop text. Even if you removed the insane delay, the linefeeds would get in the damned way.
Apple did change the selection behavior slightly in 10.1 so selecting to the right would be less annoying (it used to be like a bloody Windows app) but it still falls short, and selecting down wasn't imrpoved at all! They also reduced the delay for dragging text in 10.1 which didn't make any more or less sense than the delay in the first place. I swear the AppKit developers just do this to tease me, what other explanation is there?
What they ought to really do is implement the best of both worlds, and also add some standard cursor icons so you know whether you're hovering over a draggable item like selected text. This would eliminate a lot of the confusion former NeXT-heads had.
It has all the interface problems of TextEdit, plus a whole bag more. I mean cripes, it doesn't set the type for the files, it loses track of files if the path changes, its text views don't behave like Mac text views, the menu items ought to be completely reorganized, etc.
The advantage of using a non-Aqua theme for Swing apps is you don't get confused. You see a Metal app you expect Swing behavior, then you see an Aqua app you expect Aqua behavior.
Your assessment of Cocoa apps is correct except I would add that FSRefs also work on UFS volumes (and probably others) with the one caveat that you can't pass an FSRef to another process.
What Apple ought to do is what they did with the Toolbox more then a dacade ago which is to say deprecate functions (methods) which use file paths as arguments. Instead they ought to use something equivalent to an NSFSRef as a simple file primitive. They should also revise the Aqua HI Guidelines to clarify the behavior of "Save" and "Revert" to reflect the proper Mac behavior which can currently be had by using NSDocuments or FSRefs. They should also clarify that a file's path is variable, not constant.
Ironically Swing apps behave more like Cocoa apps in at least one aspect: the behavior of text views. NSLayoutManager doesn't behave correctly. For example selecting down on the right side will select the trailing linefeed of the last line selected which doesn't follow the Mac convention.
Unfortunately these problems are NOT going to be fixed unless more people send Apple feedback and bug reports.
Well I've brought up the two issues I mentioned back in the Rhapsody days, and again when the preliminary Aqua HI Guidelines were released. Nothing has happened except in OS X 10.1 NSDocument behaves a bit better, as if it uses an FSRef internally.
The "standard line endings" issue was resolved a long time ago, at least as much as it'll ever be. Carbon uses CR, Cocoa and UNIX use LF, Windows uses CRLF, and we're moving to XML so this is all moot anyway. The issue I had is when a mouse gesture in MacOS or Carbon apps behaves one way (the superior way) and Cocoa apps behave another way (the crazy doesn't-make-any-logical-sense way).
Ironically Swing apps behave the Carbon way when it comes to text selection. I suspect this is because the MRJ people modified their Swing to Toolbox binding for Carbon rather than any high-level decision to do it this way. The problem with Cocoa however seems to me to be due to old NeXT people who won't let go of their crappy HI.
Anyway if you want any of these issues fixed you have to bitch to Apple about them, because Apple clearly is not taking the initiative.
I'm bearish on the market and wouldn't be surprised if the Dow hit 2000, but that doesn't diminish our opportunity for growth. What DOES diminish it is the government knee-jerk reaction of a market crash which is to waste precious capital propping up businesses which ought to go bankrupt!
Recession is a GOOD thing, trying to prevent it leads to depression!
The best advice I can give Mac OS X users who want to run a Swing app is to change the default L&F to something other than Aqua.
Swing apps are incapable of behaving like Mac apps. Thus using the Aqua theme for Swing apps is the absolute worst possible combination!
One of the key reasons Swing apps will NEVER behave like Mac apps is the Java file primitive. The misnomer File class should really be called FilePath. Since (100% Java) Swing apps use file paths as file primitives this implies that file paths are constant. Thus if you move/rename an open file (or host directory/non-root volume) the Swing app will become confused.
First thing I would do is rip out that NiCad and install a NiMH. NiCads are a scam. They don't last, they are environmentally hazardous, they have memory problems, and they have less capacity.
I have cordless phones, sonicare toothbrushes, shavers, etc. and replaced all the NiCads with NiMH.
Slashdot Mirror
This is Sun we're talking about. Do you think they have a clue about interface design?
What about porting the MODEL to Cocoa instead? You can currently import html into your richtext document, if I could do the same with Microsoft documents all Cocoa apps could easily benefit.
That's a really CRAPPY strategy!
The result will be an app which is even worse than Qt/OSX or Swing/OSX apps!
Nothing is worse than the combination of the Aqua appearance without the Mac behavior.
Widgets do not make an interface!
Then do it!
Hahahahaha, what a laugh...
I especially love the fact that indeed Darwin runs on PC hardware, but he concluded this based on GNU/Hurd as though they use the same kernel.
Darwin uses a kernel called xnu which is based on a lot of technologies including Mach3. It is different than OSF Mach3 and Hurd Mach 3.
Precious...
"386 monster"?!?!
Meanwhile at Apple...
Well there is an issue and that is what to call it. Apple should allow both companies to call it VMX (which was the original name for it) or Velocity Engine (which is a stupid name).
You could also call it the PowerPC's VPU after CPU and FPU, but it's so much better than any other VPU that's on the market and does unique things like the permute operator.
VMX
Hm. Well the original Macintosh had 32bit processing and128k of RAM. I guess you could have used 640k as well |-)
Apple developed the ISA and ABI first and probably had a hand in the silicon too. Apple called it VMX, not IBM. IBM didn't have anything to do with it until now.
If Apple were smart they would allow IBM to call it VMX or VE so there would be less confusion.
There ought to be moderation guidelines so I can mod you down for typing "their"
d'oh!
I just realized that A and B are the same people!
...and vice versa.
Who the hell cares except a) the IRS and b) people who think profit is inherently evil and plan to shoot all profiteers.
Oh no! Billy's tree house club is mowing lawns and fixing bicycles! Call the UN!
Why not let the academic institutions choose their own friggin tools?!
I guess I won't be buying any software from Indian companies |-\
So do you do this within PB? What about syntax coding? (BBEdit might support python, my fav. text editor)
What about mixing with 3rd party ObjC classes?
I've had no interest in Python until now.
Maybe a TOM bridge is next. I could almost giggle.
It could be a multi-platform solution if a similar bridge worked with GNUStep.
No.
Furthermore, never.
Tk doesn't have the abstraction to allow Tk apps to magically behave like Mac apps. You can make them LOOK like Aqua, but that creates the worst possible combination.
Perhaps this could be used to replace Tk. Non-OS X versions could use GNUStep.
whether the interface of your app is going to SUCK.
The NeXT APIs are easier to develop for in my opinion, however speaking as a user I have yet to use a Cocoa app I like. Nearly all apps I use in OS X are Carbon. This is mainly due to the schizophrenic nature of OS X which I believe will only improve if Apple makes the Aqua HI Guidelines more specific. I don't think NeXT even had guidelines, but rather (falsely) assumed the API abstraction would take are of this.
Comparing SimpleText (Carbon) with TextEdit reveals most of the differences (and most of the reasons Cocoa apps get on my nerves, like the behavior of NSLayoutManager).
You should also consider PowerPlant which I still use.
I would also add that Apple shouldn't have adopted Swing unless they could convince Sun to make the API more platform neutral. Don't use it.
In other words it runs on crappy hardware which can't run Mac OS legally.
However if I could run MorphOS on a TiPB, oh the possibilities....
You're wrong.
FSRefs are an arbitrary 80 byte runtime reference for a file. For HFS+ it may per chance be comprised of a volume name and FileID but that's completely irrelevant because you're not supposed to store FSRefs and with Mac OS X not supposed to pass them to other processes. With UFS, FSRefs behave exactly the same as HFS+. I don't know the internal structure of the FSRef in Mac OS X w/UFS, but I really don't care either. It currently works.
You're probably thinking about Aliases in which case you would be correct. Aliases are anarbitrary description of how to find a file and on UFS volumes they break like symlinks, which again follows the specification. You can make Aliases on HFS+ volumes which also break like symlinks, just store the path and use null for the FileID and host FolderID.
As for selection I find the Mac selection behavior by FAR superior since 19 times out of 20 I don't want the trailing linefeed and when I do I can always add it after pasting (or dragging) by pressing return. The problem is even worse if you try drag+drop text. Even if you removed the insane delay, the linefeeds would get in the damned way.
Apple did change the selection behavior slightly in 10.1 so selecting to the right would be less annoying (it used to be like a bloody Windows app) but it still falls short, and selecting down wasn't imrpoved at all! They also reduced the delay for dragging text in 10.1 which didn't make any more or less sense than the delay in the first place. I swear the AppKit developers just do this to tease me, what other explanation is there?
What they ought to really do is implement the best of both worlds, and also add some standard cursor icons so you know whether you're hovering over a draggable item like selected text. This would eliminate a lot of the confusion former NeXT-heads had.
Anyway, file some bug reports |-)
superior interface?
Yech!
It has all the interface problems of TextEdit, plus a whole bag more. I mean cripes, it doesn't set the type for the files, it loses track of files if the path changes, its text views don't behave like Mac text views, the menu items ought to be completely reorganized, etc.
What the hell is so good about it?!
The advantage of using a non-Aqua theme for Swing apps is you don't get confused. You see a Metal app you expect Swing behavior, then you see an Aqua app you expect Aqua behavior.
Your assessment of Cocoa apps is correct except I would add that FSRefs also work on UFS volumes (and probably others) with the one caveat that you can't pass an FSRef to another process.
What Apple ought to do is what they did with the Toolbox more then a dacade ago which is to say deprecate functions (methods) which use file paths as arguments. Instead they ought to use something equivalent to an NSFSRef as a simple file primitive. They should also revise the Aqua HI Guidelines to clarify the behavior of "Save" and "Revert" to reflect the proper Mac behavior which can currently be had by using NSDocuments or FSRefs. They should also clarify that a file's path is variable, not constant.
Ironically Swing apps behave more like Cocoa apps in at least one aspect: the behavior of text views. NSLayoutManager doesn't behave correctly. For example selecting down on the right side will select the trailing linefeed of the last line selected which doesn't follow the Mac convention.
Unfortunately these problems are NOT going to be fixed unless more people send Apple feedback and bug reports.
Well I've brought up the two issues I mentioned back in the Rhapsody days, and again when the preliminary Aqua HI Guidelines were released. Nothing has happened except in OS X 10.1 NSDocument behaves a bit better, as if it uses an FSRef internally.
The "standard line endings" issue was resolved a long time ago, at least as much as it'll ever be. Carbon uses CR, Cocoa and UNIX use LF, Windows uses CRLF, and we're moving to XML so this is all moot anyway. The issue I had is when a mouse gesture in MacOS or Carbon apps behaves one way (the superior way) and Cocoa apps behave another way (the crazy doesn't-make-any-logical-sense way).
Ironically Swing apps behave the Carbon way when it comes to text selection. I suspect this is because the MRJ people modified their Swing to Toolbox binding for Carbon rather than any high-level decision to do it this way. The problem with Cocoa however seems to me to be due to old NeXT people who won't let go of their crappy HI.
Anyway if you want any of these issues fixed you have to bitch to Apple about them, because Apple clearly is not taking the initiative.
I'm bearish on the market and wouldn't be surprised if the Dow hit 2000, but that doesn't diminish our opportunity for growth. What DOES diminish it is the government knee-jerk reaction of a market crash which is to waste precious capital propping up businesses which ought to go bankrupt!
Recession is a GOOD thing, trying to prevent it leads to depression!
The best advice I can give Mac OS X users who want to run a Swing app is to change the default L&F to something other than Aqua.
Swing apps are incapable of behaving like Mac apps. Thus using the Aqua theme for Swing apps is the absolute worst possible combination!
One of the key reasons Swing apps will NEVER behave like Mac apps is the Java file primitive. The misnomer File class should really be called FilePath. Since (100% Java) Swing apps use file paths as file primitives this implies that file paths are constant. Thus if you move/rename an open file (or host directory/non-root volume) the Swing app will become confused.
First thing I would do is rip out that NiCad and install a NiMH. NiCads are a scam. They don't last, they are environmentally hazardous, they have memory problems, and they have less capacity.
I have cordless phones, sonicare toothbrushes, shavers, etc. and replaced all the NiCads with NiMH.
I can't stand TextEdit. You can't move/rename open files (or host directories/non-root volumes) without TextEdit freaking out.