Does apple actually ask for developer assistence??
I believe betatesting of osX is done in-house at apple, where the whole leopard (ie with all top-secret stuff) is being tested. The sole purpose of the developer-previews would then be for developers to test THEIR OWN code against osX. That would mean that as long as all necessary bits that interact with developer code are working, these builds are actually just fine for developers. Bugs in other parts would not really matter.
I think getting the developers to test their own code is one face of the problem. As I was never involved in such matters and what I wrote is based on my personal understanding of the issue, I would invite others knowing first hand to talk here and explain more clearly what indeed happens.
The open source pieces that Apple has out in the open, (WebKit, CalDAV Server) are both heavily bugged. I'm not sure how up-to-date the milestones for Calendar Server are, but things are not ready for production from what I see. WebKit is a great product overall and there are only a few Blocker or Critical, but the time required to remove all of them, is not my area.
Just putting that out there. (Doesn't reveal and secret features though, just release date potential.)
what if what you see is what you get...there are no secrets, no unseen features?
boy would that suck to be the reality.
Yet, the reality is what you finally get and there is no reason to rule out what you just described. In the last few years we get more frequently than not bold statements to heat up interest and anticipation.
Automator now has a "Watch Me Do" option, allowing for complete control over Apps that are not designed to work with Automator currently under Tiger. It includes full mouse and keyboard support based on locations inside of the Application Windows, allowing the window to be moved, minimized or even unfocused while the Automator Script is running still allowing full control over your computer in the mean time.
You're right that Apple will not turn everything into vectors. Photo-realistic icons for one thing will remain bitmaps.
But you're wrong about using bitmaps for "complex, lickable widgets". First, even if you use 4x bitmap artwork, scaling them to arbitrary sizes will result in blurriness, especially around the edges, and that even if you use the best interpolation process.
Second, composing variable width buttons with bitmaps is needlessly complicated compared to what you can do with vectors. For a standard button, you need a bitmap for the left part, then another one for the middle part that has a variable size, then another for the right part. Also, like I said, using vectors makes them much easier to colorize, so you don't need two sets of bitmaps for the Aqua and Graphite theme.
Many "complex, lickable widgets" are already vectorized in current Leopard builds.
Regarding the last sentence: are you sure?
The problem with vectors is rendering time. That can be got around by caching, so they only have to be re-rendered when the screen resolution is changed, but even so, bitmaps are easier, and have smaller files at high complexity.
Regarding the arbitrary resizing, it'll be fine if Apple limits the maximum magnification to 4x. Then everything will be scaled down, if at all, and so not lose significant quality.
I believe that many of those are still bitmaps. Just because they're resolution independent does not mean they are vector.
Quote:
The following is extracted from a recent Apple patent. While many Apple patents go unused, this is obviously some version of the tool Apple is using to make the vector Aqua buttons in Leopard.
I reckon the patent is the app they've always used to make Aqua UI elements, and it spits out bitmaps. That's just my gut instinct.
The problem with vectors is rendering time. That can be got around by caching, so they only have to be re-rendered when the screen resolution is changed, but even so, bitmaps are easier, and have smaller files at high complexity.
Regarding the arbitrary resizing, it'll be fine if Apple limits the maximum magnification to 4x. Then everything will be scaled down, if at all, and so not lose significant quality.
I believe that many of those are still bitmaps. Just because they're resolution independent does not mean they are vector.
I reckon the patent is the app they've always used to make Aqua UI elements, and it spits out bitmaps. That's just my gut instinct.
Amorya
No I can't say I'm 100% sure because I don't have access to a Leopard Developer build. But bitmaps for such large buttons will result in bigger files than vectors for these kinds of widgets. I know vector files can be larger than bitmaps in some cases, but I doubt these buttons are complex enough for it to be the case.
Scaling down from 4x bitmaps won't prevent bluriness from happening on lines and edges that are supposed to be crisp. For example, if a black outline is supposed to be 1 pixel thick, displaying it at 170% would create some blurry outline from interpolation. The line would be between 1 and 2 pixels thick and would be interpolated using gray lines.
The screenshot from the UI design tool is from a patent application titled "Resolution Independent User Interface Design".
While you may argue that the tool would be used to create high-resolution bitmaps, and that the tool does include a way to save the widgets as bitmaps, if you read the patent text, you'll see that it's intended to create vector UI elements that are rendered on the fly by the OS.
This is an exerpt from the patent that explains why vectors are a better solution and the limitations of using bitmaps, even with downscaling:
Quote:
[0004] In the past, two general techniques have been used to address the problem associated with displaying objects designed for a first resolution but which are displayed at a second resolution. In the first, an original (low resolution) object is up-sampled to generate a larger image (e.g., through linear or bicubic interpolation). This technique results in blurry edges such that the user interface no longer looks crisp. In the second, an original object is designed for display at a high resolution and is then down-sampled to an unknown target resolution. While useful in some circumstances, it is not possible a priori to know what width to give a line (e.g., an object's edge) at the higher resolution such that when down-sampled it remains crisp. This is particularly true when there are multiple target resolutions. Thus, both up-sampling and down-sampling techniques tend to disturb the designer's specified line width. One of ordinary skill in the art will recognize that line width is a critical factor in GUI design as the width of lines define the edge of graphical objects. If edges appear blurry or ill-defined, the entire GUI design may be compromised.
[0005] Thus, it would be beneficial to provide a means to specify the design of a graphical user interface object independent of its display resolution. Such a description may advantageously be used by a rendering module to display the designed object at substantially any resolution.
I think you overestimate the rendering time for vectors. On a modern computer, the overhead should be minimal, especially if they use caching and Quartz Extreme 2d is enabled. I'm not the kind of guy that thinks that everything should be replaced by vectors, including file icons, but for UI elements, I think it makes sense, for the reasons mentioned above.
To get back on topic, I think that this move to resolution independence is requiring a lot of testing, especially with older applications. Even if all other features were ready, there would still be a lot to test to make sure there aren't cosmetic glitches all over the place.
As I mentioned earlier, another advantage of resolution independency, is the ability to re-color the interface easily. The Blue and Graphite themes currently use two different sets of bitmaps, if they used huge bitmaps for the RI interface, a lot of space would be wasted. I think Apple always wanted the ability to re-color the interface, I don't think they see it as an interface inconstancy problem. The reason they didn't do it before is because of the use of pre-colored bitmaps, and the aging underlying UI display system. Since they have to do an overhaul of the UI display framework because of RI, they may as well implement the possibility to re-shade the UI.
A very recent patent awarded to Apple shows that they are at least experimenting with the idea.
Patent 7,184,056 "Method and apparatus for user customized shading of a graphical user interface "
Interesting tidbits, some images refer to something called "Aqua Pro Evolution". Also, the patent mentions the ability to transition to a dark interface with light colored text. So maybe after all we'll not only see a "black theme", but also intermediary variations.
(Edit: This last patent was filled in 2002, but was recently awarded, it doesn't mean it couldn't find its way in Leopard. The images show Final Cut Pro, but it seems to be aimed at a system-wide feature.)
Since Leopard development is occurring exactly 2 years after Tiger development, it's straightforward to compare the development progress of the two.
I sourced data for the Tiger progress from Appleinsider via Google searching, and data for Leopard from Wikipedia.
The data illustrate that at the current rate of Leopard development, and assuming that early-400 builds will be of GM-quality (as with Tiger), that GM should be hit in mid-late May, giving time to get Leopard to retail by WWDC/end of June.
Thanks for that, Mr. H--how very mathematical of you. And it leaves a rather comfortable margin for error, too.
EDIT: I just realized that may've sounded sarcastic--well, I'm being sincere: this is some of the better speculation on Leopard's date that I've seen (certainly beats "March 24th, because it's the anniversary of Mac OS X"), and given the builds numbering, it looks like Leopard before June is very unlikely even if there is a super-secret build, as has been speculated; and, considering the "spring" release date has been recently reiterated by Apple, I think it'll happen toward the end of it, as this extrapolation precisely points to.
There are a lot of cool things in it that I'd like to see in Leopard. There are a lot of people who want Leopard to look just like Tiger and not have any cool new look to it. Sure they'll say that there'll be some slight changes to look, like what we've seen in iTunes, but those don't impress me. I'm hoping Leopard really changes things up from what we see in Tiger. I'd much rather use the word "daring" to describe Leopard than "conservative". The look of Tiger is getting boring and I don't want this look to continue in Leopard.
The screenshot from the UI design tool is from a patent application titled "Resolution Independent User Interface Design".
While you may argue that the tool would be used to create high-resolution bitmaps, and that the tool does include a way to save the widgets as bitmaps, if you read the patent text, you'll see that it's intended to create vector UI elements that are rendered on the fly by the OS.
The files which accompany the CoreUI framework pretty much confirm that. At least some keys in XML files inside it directly correspond to the patent listings. There's also Aqua.bundle in there which contains a lot of standard icons (mainly button icons) in PDF. It looks like Aqua-style widgets (e.g. a push button shape) are indeed rendered on the fly and vector images (e.g. a plus sign for "Add") are composited on top of them. The framework is private and, I'm sure, will remain private forever. The Aqua.bundle has lead some people to believe that Leopard is going to bring back themes, but I'm not sure. If they introduce themes, most custom widgets which 3rd party developers currently draw will be Aqua-only-compatible, stylistically. Either Apple exposes CoreUI API or gives away the tools described in the patent or chooses to still not use or provide any themes.
Quote:
I think you overestimate the rendering time for vectors.
Well said. Does anybody worry about vector fonts rendering performance these days? On my Mac almost every UI element has some text...
Comments
Does apple actually ask for developer assistence??
I believe betatesting of osX is done in-house at apple, where the whole leopard (ie with all top-secret stuff) is being tested. The sole purpose of the developer-previews would then be for developers to test THEIR OWN code against osX. That would mean that as long as all necessary bits that interact with developer code are working, these builds are actually just fine for developers. Bugs in other parts would not really matter.
I think getting the developers to test their own code is one face of the problem. As I was never involved in such matters and what I wrote is based on my personal understanding of the issue, I would invite others knowing first hand to talk here and explain more clearly what indeed happens.
boy would that suck to be the reality.
what if what you see is what you get...there are no secrets, no unseen features?
boy would that suck to be the reality.
Because I can never take Steve Jobs seriously anymore...I wouldn't be suprised if there was no surprise/secrets.
Just putting that out there. (Doesn't reveal and secret features though, just release date potential.)
what if what you see is what you get...there are no secrets, no unseen features?
boy would that suck to be the reality.
Yet, the reality is what you finally get and there is no reason to rule out what you just described. In the last few years we get more frequently than not bold statements to heat up interest and anticipation.
What are you talking about?
From the release notes:
Automator now has a "Watch Me Do" option, allowing for complete control over Apps that are not designed to work with Automator currently under Tiger. It includes full mouse and keyboard support based on locations inside of the Application Windows, allowing the window to be moved, minimized or even unfocused while the Automator Script is running still allowing full control over your computer in the mean time.
You're right that Apple will not turn everything into vectors. Photo-realistic icons for one thing will remain bitmaps.
But you're wrong about using bitmaps for "complex, lickable widgets". First, even if you use 4x bitmap artwork, scaling them to arbitrary sizes will result in blurriness, especially around the edges, and that even if you use the best interpolation process.
Second, composing variable width buttons with bitmaps is needlessly complicated compared to what you can do with vectors. For a standard button, you need a bitmap for the left part, then another one for the middle part that has a variable size, then another for the right part. Also, like I said, using vectors makes them much easier to colorize, so you don't need two sets of bitmaps for the Aqua and Graphite theme.
Many "complex, lickable widgets" are already vectorized in current Leopard builds.
Regarding the last sentence: are you sure?
The problem with vectors is rendering time. That can be got around by caching, so they only have to be re-rendered when the screen resolution is changed, but even so, bitmaps are easier, and have smaller files at high complexity.
Regarding the arbitrary resizing, it'll be fine if Apple limits the maximum magnification to 4x. Then everything will be scaled down, if at all, and so not lose significant quality.
Check out this image for concrete examples: http://loop.worldofapple.com/wp-cont...indbuttons.jpg
I believe that many of those are still bitmaps. Just because they're resolution independent does not mean they are vector.
The following is extracted from a recent Apple patent. While many Apple patents go unused, this is obviously some version of the tool Apple is using to make the vector Aqua buttons in Leopard.
I reckon the patent is the app they've always used to make Aqua UI elements, and it spits out bitmaps. That's just my gut instinct.
Amorya
what if what you see is what you get...there are no secrets, no unseen features?
boy would that suck to be the reality.
4K78 was the GM...
Regarding the last sentence: are you sure?
The problem with vectors is rendering time. That can be got around by caching, so they only have to be re-rendered when the screen resolution is changed, but even so, bitmaps are easier, and have smaller files at high complexity.
Regarding the arbitrary resizing, it'll be fine if Apple limits the maximum magnification to 4x. Then everything will be scaled down, if at all, and so not lose significant quality.
I believe that many of those are still bitmaps. Just because they're resolution independent does not mean they are vector.
I reckon the patent is the app they've always used to make Aqua UI elements, and it spits out bitmaps. That's just my gut instinct.
Amorya
No I can't say I'm 100% sure because I don't have access to a Leopard Developer build. But bitmaps for such large buttons will result in bigger files than vectors for these kinds of widgets. I know vector files can be larger than bitmaps in some cases, but I doubt these buttons are complex enough for it to be the case.
Scaling down from 4x bitmaps won't prevent bluriness from happening on lines and edges that are supposed to be crisp. For example, if a black outline is supposed to be 1 pixel thick, displaying it at 170% would create some blurry outline from interpolation. The line would be between 1 and 2 pixels thick and would be interpolated using gray lines.
The screenshot from the UI design tool is from a patent application titled "Resolution Independent User Interface Design".
While you may argue that the tool would be used to create high-resolution bitmaps, and that the tool does include a way to save the widgets as bitmaps, if you read the patent text, you'll see that it's intended to create vector UI elements that are rendered on the fly by the OS.
http://appft1.uspto.gov/netacgi/nph-...2+AND+AN/apple
This is an exerpt from the patent that explains why vectors are a better solution and the limitations of using bitmaps, even with downscaling:
[0004] In the past, two general techniques have been used to address the problem associated with displaying objects designed for a first resolution but which are displayed at a second resolution. In the first, an original (low resolution) object is up-sampled to generate a larger image (e.g., through linear or bicubic interpolation). This technique results in blurry edges such that the user interface no longer looks crisp. In the second, an original object is designed for display at a high resolution and is then down-sampled to an unknown target resolution. While useful in some circumstances, it is not possible a priori to know what width to give a line (e.g., an object's edge) at the higher resolution such that when down-sampled it remains crisp. This is particularly true when there are multiple target resolutions. Thus, both up-sampling and down-sampling techniques tend to disturb the designer's specified line width. One of ordinary skill in the art will recognize that line width is a critical factor in GUI design as the width of lines define the edge of graphical objects. If edges appear blurry or ill-defined, the entire GUI design may be compromised.
[0005] Thus, it would be beneficial to provide a means to specify the design of a graphical user interface object independent of its display resolution. Such a description may advantageously be used by a rendering module to display the designed object at substantially any resolution.
I think you overestimate the rendering time for vectors. On a modern computer, the overhead should be minimal, especially if they use caching and Quartz Extreme 2d is enabled. I'm not the kind of guy that thinks that everything should be replaced by vectors, including file icons, but for UI elements, I think it makes sense, for the reasons mentioned above.
To get back on topic, I think that this move to resolution independence is requiring a lot of testing, especially with older applications. Even if all other features were ready, there would still be a lot to test to make sure there aren't cosmetic glitches all over the place.
As I mentioned earlier, another advantage of resolution independency, is the ability to re-color the interface easily. The Blue and Graphite themes currently use two different sets of bitmaps, if they used huge bitmaps for the RI interface, a lot of space would be wasted. I think Apple always wanted the ability to re-color the interface, I don't think they see it as an interface inconstancy problem. The reason they didn't do it before is because of the use of pre-colored bitmaps, and the aging underlying UI display system. Since they have to do an overhaul of the UI display framework because of RI, they may as well implement the possibility to re-shade the UI.
A very recent patent awarded to Apple shows that they are at least experimenting with the idea.
Patent 7,184,056 "Method and apparatus for user customized shading of a graphical user interface "
http://patft.uspto.gov/netacgi/nph-P...le&RS=AN/apple
Interesting tidbits, some images refer to something called "Aqua Pro Evolution". Also, the patent mentions the ability to transition to a dark interface with light colored text. So maybe after all we'll not only see a "black theme", but also intermediary variations.
(Edit: This last patent was filled in 2002, but was recently awarded, it doesn't mean it couldn't find its way in Leopard. The images show Final Cut Pro, but it seems to be aimed at a system-wide feature.)
Since Leopard development is occurring exactly 2 years after Tiger development, it's straightforward to compare the development progress of the two.
I sourced data for the Tiger progress from Appleinsider via Google searching, and data for Leopard from Wikipedia.
The data illustrate that at the current rate of Leopard development, and assuming that early-400 builds will be of GM-quality (as with Tiger), that GM should be hit in mid-late May, giving time to get Leopard to retail by WWDC/end of June.
Here's the graph:
EDIT: I just realized that may've sounded sarcastic--well, I'm being sincere: this is some of the better speculation on Leopard's date that I've seen (certainly beats "March 24th, because it's the anniversary of Mac OS X"), and given the builds numbering, it looks like Leopard before June is very unlikely even if there is a super-secret build, as has been speculated; and, considering the "spring" release date has been recently reiterated by Apple, I think it'll happen toward the end of it, as this extrapolation precisely points to.
That's so very suddle You know.
You mean my sarcasm is subtle? That's because I wasn't being sarcastic
Yeah whatever, You know what I mean.
Actually, I haven't got a frickin' clue what you mean
Actually, I haven't got a frickin' clue what you mean
You're not alone in that.
If you guys wouldn't quote him, it would be easier to just axe the whole thing...
Add me to the list.
If you guys wouldn't quote him, it would be easier to just axe the whole thing...
Go ahead, ax it. You've lost me about 200 posts recently when you did something to the files, what's a few more?
http://www.youtube.com/watch?v=Y6kd42jIaHk
There are a lot of cool things in it that I'd like to see in Leopard. There are a lot of people who want Leopard to look just like Tiger and not have any cool new look to it. Sure they'll say that there'll be some slight changes to look, like what we've seen in iTunes, but those don't impress me. I'm hoping Leopard really changes things up from what we see in Tiger. I'd much rather use the word "daring" to describe Leopard than "conservative". The look of Tiger is getting boring and I don't want this look to continue in Leopard.
The screenshot from the UI design tool is from a patent application titled "Resolution Independent User Interface Design".
While you may argue that the tool would be used to create high-resolution bitmaps, and that the tool does include a way to save the widgets as bitmaps, if you read the patent text, you'll see that it's intended to create vector UI elements that are rendered on the fly by the OS.
The files which accompany the CoreUI framework pretty much confirm that. At least some keys in XML files inside it directly correspond to the patent listings. There's also Aqua.bundle in there which contains a lot of standard icons (mainly button icons) in PDF. It looks like Aqua-style widgets (e.g. a push button shape) are indeed rendered on the fly and vector images (e.g. a plus sign for "Add") are composited on top of them. The framework is private and, I'm sure, will remain private forever. The Aqua.bundle has lead some people to believe that Leopard is going to bring back themes, but I'm not sure. If they introduce themes, most custom widgets which 3rd party developers currently draw will be Aqua-only-compatible, stylistically. Either Apple exposes CoreUI API or gives away the tools described in the patent or chooses to still not use or provide any themes.
I think you overestimate the rendering time for vectors.
Well said. Does anybody worry about vector fonts rendering performance these days? On my Mac almost every UI element has some text...