I seem to remember reading that iTunes drew the widgets on its own, rather than using the system's facilities for doing so. I don't remember why, but assuming my memory isn't failing me (again), that is probably the reason why iTunes didn't get the new widgets.
Does anyone know if GiTS:Man Machine Interface can be bought stateside yet? I have looked in the places I would expect to see it, but so far I haven't found it.
Thats from PCU. The GB wasn't even out when Animal House was made.
Re:Isn't everything in OS X late-binding?
on
Is Mac OS X Slow?
·
· Score: 1
Right, Aqua (or more correctly Quartz) runs as couple user processes. Namely, WindowServer, and SystemUIServer.
Re:Isn't everything in OS X late-binding?
on
Is Mac OS X Slow?
·
· Score: 2, Informative
microkernal vs monolithic kernal penalty
Um.. not quite. OS X doesn't have a true micro kernal. To speed things up Apple placed the BSD kernal in mach's kernal space, thus mitigating most of the cost of making calls between the two layers.
As far as I know, resource forks do work thorugh nfs, becuase Apple has but kludges in to make them work with non HFS file systems. Basically on a non HFS file system they store the resource data to a file called '._appName' I belive, or something very similar. The api's wrap around this and the App's don't know the difference (assuming they used the api's correctly).
Or atleast that is how it works with UFS, I don't have a nfs server to try this with, but I have heard about plenty of people mounting their $HOME from a nfs server, so I would think it probably works.
Your assessmeYour 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.
nt 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.
Last I heard that on non HFS(+) file systems, FSRefs revert to using path names rather than a file ID, since file ID's don't really exist on UFS (there are inodes, but still not quite the same). Assuming they are still implemented this way they don't provide the same features that they would on HFS(+), but atleast they don't break completely. (and if I am wrong on this, feel free to correct me.)
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.
It's a behavior left over from NeXT. I prefer the old Mac way of selecting, but it would be great if they would atleast unify it to one or the other.
One reason for using the Aqua L&F, though, is that it is better optimized for OS X. Try running a complex application in Metal on OS X and again in Aqua. In my experiance the difference was quite aparent. You have a point though that the feel of java apps on OS X is still not quite right, but using Metal isn't any better (it just makes things more ugly).
Cocoa apps have the same file path problem. NSDocument based apps now use FSRef's as well as NSURL's so they don't, but if you write a Cocoa app that doesn't use NSDocument, its up to you to do the FSRef magic you need to track files based on their HFS+ id number.
Well, you are partialy right. If you run a java app that uses swing and doesn't specify its L&F, you will get the Aqua L&F. Thats not to say its totaly Aqua though, because unless you use some MRJToolbox calls (don't remember which ones) the menu bar will still be part of the App's windows.
Atleast that is my experiance so far in doing cross platform java dev on OS X for my classes. What I would like is a java compiler that can do some pre-processing. That way I could put the MRJ calls in, with #ifdef's (or what ever) around them, and the rest of my team could still compile on windows and linux with out any problems.
Why is having a different (and arguably better) graphics system 'part of the problem'? True it doesn't have network transparency and it necessitates the use of a rootless X server for compatibility with GUI unix apps, but it provides capabilities and features that would be hard, if not impossible to do with X11 (true transparency, pdf based vector graphics, built-in color management all come to mind).
Don't get me wrong, I love some of X11's capabilities, but I just don't see having Quartz rather than X11 being a bad thing.
QuickTime 6 supports JPEG2000, so anyone who installs that will have a viewer for the file format.
Problem is, so far I have yet to see a JPEG2000 file out on the net anywhere. I also don't know how many software packages there are that can write files in the new standard (the aforementioned QuickTime can, but only in the Pro version I believe).
Does anyone know what tools are available on Linux or BSD to view or create JPEG2000 files?
As I understood it, the patent was originally owned by a member of the JPEG group. Assuming this is true, your claim that the JPEG group should have designed around it doesn't hold much water, as it was part of their group's IP. You generally don't have to design around your own IP.
Although, if that is true (that the IP originally came from a member of the group), won't it be hard for them to find prior art?
Well, you are partialy right because Blizzard is going to make part of Battle.Net a for-pay service, but that is for WoW and not for their previous games. The Bnetd people right now only deal with the older games (the would have no idea how to support WoW unless they worked for Blizzard), so the for-pay argument is kinda lacking.
Add to this the fact that everyone I know around my university only used Bnetd to play pirated copies of the War3 beta, and I would said that the piracy argument holds more water than the for-pay does. Obviously just my opinion.
Not at my OS X box right now, but what is diffrent about that download from the one that comes with the OS? Does it have the Quartz patch to allow it to operate outside the terminal?
There was also a demo shown (I can't find it now though) of the OpenGL Teapot and some other figures floating around on the screen. They were infront of a DVD and the DVD was reflecting on them. It was pretty awsome.
The transparent terminals on top of the DVD are pretty cool too, although I think the biggest improvement that QE will bring is the increased speed.
Here in Pheonix Wal-Mart's have them. If you can get the little kids a way and bend over far enough to play the thing (mounted at about 3') its not bad, too small for my hands and the screen doesn't appear to be much better thant he BGC was, but not too bad as a handheld. It looked like the games were for sale alread as well. There were about 10 of them and they had plenty. I personaly thought it was already released here in the US sence I didn't see any comming soon signs.
Slashdot Mirror
My thoughts exactly!
I seem to remember reading that iTunes drew the widgets on its own, rather than using the system's facilities for doing so. I don't remember why, but assuming my memory isn't failing me (again), that is probably the reason why iTunes didn't get the new widgets.
Does anyone know if GiTS:Man Machine Interface can be bought stateside yet? I have looked in the places I would expect to see it, but so far I haven't found it.
OmniDictionary's service rocks too. When ever I see a word in OmniWeb I don't know, just select it and hit Cmd-= and it pops up in OmniDictionary.
Thats from PCU. The GB wasn't even out when Animal House was made.
Right, Aqua (or more correctly Quartz) runs as couple user processes. Namely, WindowServer, and SystemUIServer.
Um.. not quite. OS X doesn't have a true micro kernal. To speed things up Apple placed the BSD kernal in mach's kernal space, thus mitigating most of the cost of making calls between the two layers.
While true, that doesn't really make the browsing experiance all that much better, as IE on OS X still blows, even if it actually obeys the standards.
As far as I know, resource forks do work thorugh nfs, becuase Apple has but kludges in to make them work with non HFS file systems. Basically on a non HFS file system they store the resource data to a file called '._appName' I belive, or something very similar. The api's wrap around this and the App's don't know the difference (assuming they used the api's correctly).
Or atleast that is how it works with UFS, I don't have a nfs server to try this with, but I have heard about plenty of people mounting their $HOME from a nfs server, so I would think it probably works.
Why waste the keystrokes? just use sudo -s:
% sudo -sPassword:
#
Last I heard that on non HFS(+) file systems, FSRefs revert to using path names rather than a file ID, since file ID's don't really exist on UFS (there are inodes, but still not quite the same). Assuming they are still implemented this way they don't provide the same features that they would on HFS(+), but atleast they don't break completely. (and if I am wrong on this, feel free to correct me.)
It's a behavior left over from NeXT. I prefer the old Mac way of selecting, but it would be great if they would atleast unify it to one or the other.
One reason for using the Aqua L&F, though, is that it is better optimized for OS X. Try running a complex application in Metal on OS X and again in Aqua. In my experiance the difference was quite aparent. You have a point though that the feel of java apps on OS X is still not quite right, but using Metal isn't any better (it just makes things more ugly).
Cocoa apps have the same file path problem. NSDocument based apps now use FSRef's as well as NSURL's so they don't, but if you write a Cocoa app that doesn't use NSDocument, its up to you to do the FSRef magic you need to track files based on their HFS+ id number.
Well, you are partialy right. If you run a java app that uses swing and doesn't specify its L&F, you will get the Aqua L&F. Thats not to say its totaly Aqua though, because unless you use some MRJToolbox calls (don't remember which ones) the menu bar will still be part of the App's windows.
Atleast that is my experiance so far in doing cross platform java dev on OS X for my classes. What I would like is a java compiler that can do some pre-processing. That way I could put the MRJ calls in, with #ifdef's (or what ever) around them, and the rest of my team could still compile on windows and linux with out any problems.
Or they could redesign them so they don't, you know, look like ass.
Why is having a different (and arguably better) graphics system 'part of the problem'? True it doesn't have network transparency and it necessitates the use of a rootless X server for compatibility with GUI unix apps, but it provides capabilities and features that would be hard, if not impossible to do with X11 (true transparency, pdf based vector graphics, built-in color management all come to mind).
Don't get me wrong, I love some of X11's capabilities, but I just don't see having Quartz rather than X11 being a bad thing.
QuickTime 6 supports JPEG2000, so anyone who installs that will have a viewer for the file format.
Problem is, so far I have yet to see a JPEG2000 file out on the net anywhere. I also don't know how many software packages there are that can write files in the new standard (the aforementioned QuickTime can, but only in the Pro version I believe).
Does anyone know what tools are available on Linux or BSD to view or create JPEG2000 files?
As I understood it, the patent was originally owned by a member of the JPEG group. Assuming this is true, your claim that the JPEG group should have designed around it doesn't hold much water, as it was part of their group's IP. You generally don't have to design around your own IP.
Although, if that is true (that the IP originally came from a member of the group), won't it be hard for them to find prior art?
Interesting. How long does that cable last outside like that? I would think that the sun/weather and animals would wear it out pretty quick.
Actually SnapsPro can take DVD screen shots if you have a nVidia GPU.
Also, in Jaguar, you can take screen shots of DVD's using grab.
Well, you are partialy right because Blizzard is going to make part of Battle.Net a for-pay service, but that is for WoW and not for their previous games. The Bnetd people right now only deal with the older games (the would have no idea how to support WoW unless they worked for Blizzard), so the for-pay argument is kinda lacking.
Add to this the fact that everyone I know around my university only used Bnetd to play pirated copies of the War3 beta, and I would said that the piracy argument holds more water than the for-pay does. Obviously just my opinion.
Not at my OS X box right now, but what is diffrent about that download from the one that comes with the OS? Does it have the Quartz patch to allow it to operate outside the terminal?
You mean a project to convert X11 into an OpenGL stream (which is basicaly what QE does), or do you want Quartz on Linux?
I seriously doubt there is either going on, although the Berlin Project might bring it closer to reality.
What machine are you running on for this demo? Its possible that the machine in the other video was a top of the line machine or so.
There was also a demo shown (I can't find it now though) of the OpenGL Teapot and some other figures floating around on the screen. They were infront of a DVD and the DVD was reflecting on them. It was pretty awsome.
The transparent terminals on top of the DVD are pretty cool too, although I think the biggest improvement that QE will bring is the increased speed.
Here in Pheonix Wal-Mart's have them. If you can get the little kids a way and bend over far enough to play the thing (mounted at about 3') its not bad, too small for my hands and the screen doesn't appear to be much better thant he BGC was, but not too bad as a handheld. It looked like the games were for sale alread as well. There were about 10 of them and they had plenty. I personaly thought it was already released here in the US sence I didn't see any comming soon signs.
-----