<strong>The aim of 10.2 was bug-hunting, *nix part upgrades AND speed improvements. Apart from a few specific areas, speed is NOT a major objective in 10.3 - Apple's belief is that hardware improvements will take care of that.</strong><hr></blockquote>
The focus of 10.2 was additional features for the digital hub, and other such improvements. Speed optimizations were on the list, but lower than feature enhancements for 10.2.
I stand by what I said re: 10.3, I wouldn't be surprised if it has speed as a focus.
One, I never liked the whole Copy, Cut, and Paste metaphor for files and folders. It seems those commands were just balatantly ripped off from Windows. What happens if you Cut a bunch of Files, then shut your computer down? I wouldn't want to go searching for them, if they haven't been deleted. Those commands should at least be under the File menu, not Edit, when dealing with Files.
Just because there's key commands for doing something, doesn't mean there shouldn't be a GUI element as well. With a drawer, the files would stay there until you moved them, so you'd never lose them if you Copied something else after you Cut some files.
What if you want to take a bunch of files and put them into different directories? cmd-c and cmd-v would be totally useless then.</strong><hr></blockquote>
NEXTSTEP/OpenStep had a great interface element called the Shelf. A file or group of files could be dragged to the Shelf (actually, it was just a proxy to those objects -- the objects themselves didn't move) for later action. Those actions could include moving, copying, deleting, opening, or otherwise manipulating the files. A group selection would show up as a single icon (specifically: a hand with some fanned cards). The best thing about the Shelf is that it could hold any number of selections for action at any future point. So immediate action wasn't necessary.
The multiple-item icon only needed a few enhancements to make it even more useful. For instance, it should have been possible to change the members of a multiple-item selection, or to get properties on a selection to determine existing members, but it wasn't.
Maybe these features will find their way into future OS X versions. The primary problem is that a Shelf would require yet-another interface element OR an expansion of the already-overloaded Dock.
One, I never liked the whole Copy, Cut, and Paste metaphor for files and folders. It seems those commands were just balatantly ripped off from Windows. What happens if you Cut a bunch of Files, then shut your computer down? I wouldn't want to go searching for them, if they haven't been deleted. Those commands should at least be under the File menu, not Edit, when dealing with Files.
Just because there's key commands for doing something, doesn't mean there shouldn't be a GUI element as well. With a drawer, the files would stay there until you moved them, so you'd never lose them if you Copied something else after you Cut some files.
What if you want to take a bunch of files and put them into different directories? cmd-c and cmd-v would be totally useless then.</strong><hr></blockquote>
*shrug* I don't care if they're from Windows or not; they are convenient and help me with file management. I also never use the Cut command if I'm not sure that I'm going to be instantly pasting the contents somewhere (I've never had a problem properly using the Clipboard for text, i.e., losing or overwriting a text fragment).
I think it would be neet if you could have multiple clipboard entries. I don't know how they would work it to make it fast and easy like now while still allowing the user to easily choose which fragment in the clipboard they want to paste.
I didn't even know you could Copy and Paste files just like in Windows. That's kinda cool but scary at the same time. I'm used to having it just copy the name of the file when I press cmd-c with a file selected.
And taking things from Windows isn't bad at all. They've borrowed plenty from the Mac, why not borrow from them? Contextual menus, window-specific toolbars, and sticky menus all came from Windows, and I don't see anyone complaining about those. Well, the window-specific toolbars could use some improvement, but the other two are essential to streamlining the way you use the computer.
Actually, the pasteboard (aka, clipboard) in OS X can handle multiple items now, it's just not user-controllable. Services make use of this, and I think any text copied to the pasteboard gets copied in a couple of formats. It would be nice to enhance the clipboard for more user interaction, feedback and control though. Right now, you can hcoose to view the clipboard contents, but that window alone could be much more powerful.
The focus of 10.2 was additional features for the digital hub, and other such improvements. Speed optimizations were on the list, but lower than feature enhancements for 10.2.
I stand by what I said re: 10.3, I wouldn't be surprised if it has speed as a focus.</strong><hr></blockquote>
The focus of 10.2 was additional features for the digital hub, and other such improvements. Speed optimizations were on the list, but lower than feature enhancements for 10.2.
I stand by what I said re: 10.3, I wouldn't be surprised if it has speed as a focus.</strong><hr></blockquote>
The features supporting the digital hub idea that came to fruition in the course of 10.2's development did not stem from work done by the basic OS development team but were developed by other teams that referred to it. Certainly, a number of extremely far reaching technologies related to digital hub connectivity were introduced in 10.2 and enhanced in the follow-up minor updates, but they were parallel efforts.
As for 10.3 speed enhancements, they will to a large extent rely on hardware features in present and upcoming models.
<strong>The features supporting the digital hub idea that came to fruition in the course of 10.2's development did not stem from work done by the basic OS development team but were developed by other teams that referred to it. Certainly, a number of extremely far reaching technologies related to digital hub connectivity were introduced in 10.2 and enhanced in the follow-up minor updates, but they were parallel efforts.
As for 10.3 speed enhancements, they will to a large extent rely on hardware features in present and upcoming models.
</strong><hr></blockquote>
*sigh* I can't argue any further (on either issue) without saying things I shouldn't. Suffice it to say that I disagree with both of your assessments.
I think Moki just lives for those I can't say more than that without saying things I shouldn'ts.
Apple has made it very clear that QuartzGL (I know, I know, "Quartz Extreme") is just a beginning. I'd expect some impressive improvements in this area, and some really interesting features.
[quote] Apple has made it very clear that QuartzGL (I know, I know, "Quartz Extreme") is just a beginning. I'd expect some impressive improvements in this area, and some really interesting features.
<hr></blockquote>
After seeing Steve Jobs demo' 'Keynote', I can't wait to see how far Apple can take Quartz Extreme in software generally and specifically for many visual enhancements in 'X'.
I'm sure there are speed 'eeks' they can get out of 10.3. But if its running on a 970, we may not notice. I'm sure it will be faster than running it on an iBook!
The next half a year can't come quick enough for me. For more than a couple of reasons...
The focus of 10.2 was additional features for the digital hub, and other such improvements. Speed optimizations were on the list, but lower than feature enhancements for 10.2.
I stand by what I said re: 10.3, I wouldn't be surprised if it has speed as a focus.</strong><hr></blockquote>
Cool... integration, now matter what stage of development, makes things behave much better. Copying and pasting between applications has made publishing much easier, and you are only limited by memory and speed of the hardware.
Increasing speed for the system as a whole, regardless of the hardware you are using, would be very useful. Updating the finder to Carbon would optimize the speed of the system that much more.
For me, the separation of Sherlock from the 'Find File' (Cmd-F) tool on the computer made things much easier and quicker.
If they can do something similar for 10.3 I will be happy. If they can do it without charging $200 CDN, I will be even happier.
Increasing speed for the system as a whole, regardless of the hardware you are using, would be very useful.
</strong><hr></blockquote>
I agree; unfortunately, the present economy makes it even more of a no-no than before: Apple HAS to increase the turnover rate among those that already own Macs, and the classical way to do that is by, 1) increase the workload on the processor so the newest code runs irritatingly slow on two-year old machines; 2) Include support for new hardware features (including peripherals) in the new code.
[quote]Originally posted by nosey:
<strong>
Updating the finder to Carbon would optimize the speed of the system that much more.
<strong>Perhaps I should have used the term 'built so that it is native to Mac OS10'... is that more correct?</strong><hr></blockquote>Unfortunately, some of the ill-informed masses have put out the idea that Carbon is inherently inferior to Cocoa. This is completely false. Carbon and Cocoa are near complete peers today for developing software. The problem is that the "quick ports" of software are usually done in Carbon and are poorly done, giving Carbon itself a "bad rap".
For the most part, the choice of Carbon or Cocoa is simply a case of using the right tool for the right job. Some things can be done quicker and easier in Cocoa, others in Carbon.
The Finder is a Carbon app. Though, a lot of it was written from scratch for Mac OS X. If Apple had to start all over by trying to rewrite the Finder in Cocoa, performance gains could be negligible or nonexistant until any current optimizations could be redesigned or new ones discovered.
Cocoa is not a magic cure-all for slow or buggy apps. Don't believe all the Cocoa hype.
I just meant -- and keep in mind here I have absolutely NO information from Apple to back this up, it is purely my speculation -- that I'd expect 10.3's focus to be on speed enhancements.
10.0 was the initial "proof of concept" release -- it had to ship
10.1 was focused on speed
10.2 was focused on additional features/functionality
It makes sense to me that 10.3 would be a regrouping release focused again on speed... there are plenty of things in Mac OS X that can be optimized further...</strong><hr></blockquote>
That sounds very logical and feasible and I had thought the same thing before reading this.
I know one area where speed can be found is in the code generated by the compiler. I read that gcc 3.1 (which was included with 10.2 for those who don't pay attention to such things), focused more on laying the foundation for PPC optimizations than in actually implementing the optimizations. Now that the foundation has been laid out, gcc3.3 should produce much better code when it is available. (Assuming that Apple's engineers haven't been sitting on their butts playing Quake all day.)
Watching the improvments in the 10.2.x updates suggests that they are putting a lot of work into speed lately. With a major system update like 10.3, they can make a lot more changes to the code and structure of things which can lead to much improved speed.
Apple wants to be the speed kings when the 970 ships. They can't allow the software to make the hardware look slow. Part of that means having good 64-bit support, but also general PowerPC optimizations will help improve speed on all machines.
I just hope the optimizations don't rely too much upon Velocity Engine because I'm still using a G3 and I know it's capable of more than it's showing right now.
<strong>Cocoa is not a magic cure-all... ...Don't believe all the Cocoa hype.
</strong><hr></blockquote>
But I thought Cocoa cured everything... I'm drinking a cup right now while typing this on a PC at work... It makes me feel marginally better... Maybe it will make this machine feel better... Her ya go...
<strong>The Finder is a Carbon app. Though, a lot of it was written from scratch for Mac OS X. If Apple had to start all over by trying to rewrite the Finder in Cocoa, performance gains could be negligible or nonexistant until any current optimizations could be redesigned or new ones discovered.
Cocoa is not a magic cure-all for slow or buggy apps. Don't believe all the Cocoa hype.</strong><hr></blockquote>
All true, but they could at least move the interface to .nib and no longer fake the NSToolbar. Right now, it has a strange behaviour:
- it "takes over" the window and resizes it when customizing it. What are drawers for?
- Grey text is supposed to mean "disabled" or in background? Well, let's see.
1. Open a new Finder window. Back and Forward will be greyed out the right way. When not in focus, all toolbar buttons will be greyed out.
2. Focus the window again. Right-click on a disabled button, for example either "Back" or "Forward". Ignore the context menu, just click somewhere else. Notice how the button you right-clicked is now black.
3. Defocus the window again. The clicked button still has a black label. This bug doesn't happen for enabled buttons.
- In Toolbar Customization, the "Show:" label in the bottom left is black when in background. Also, some toolbar buttons are.
I didn't try these things in an English OS X, so it may be localization bugs, but even so, they should just rather use NSToolbar which won't confuse the heck out of normal users.
Sure, this stuff is minor, but shouldn't exist in any stable release in one of the most important apps.
Comments
<strong>The aim of 10.2 was bug-hunting, *nix part upgrades AND speed improvements. Apart from a few specific areas, speed is NOT a major objective in 10.3 - Apple's belief is that hardware improvements will take care of that.</strong><hr></blockquote>
The focus of 10.2 was additional features for the digital hub, and other such improvements. Speed optimizations were on the list, but lower than feature enhancements for 10.2.
I stand by what I said re: 10.3, I wouldn't be surprised if it has speed as a focus.
<strong>
Three reasons.
One, I never liked the whole Copy, Cut, and Paste metaphor for files and folders. It seems those commands were just balatantly ripped off from Windows. What happens if you Cut a bunch of Files, then shut your computer down? I wouldn't want to go searching for them, if they haven't been deleted. Those commands should at least be under the File menu, not Edit, when dealing with Files.
Just because there's key commands for doing something, doesn't mean there shouldn't be a GUI element as well. With a drawer, the files would stay there until you moved them, so you'd never lose them if you Copied something else after you Cut some files.
What if you want to take a bunch of files and put them into different directories? cmd-c and cmd-v would be totally useless then.</strong><hr></blockquote>
NEXTSTEP/OpenStep had a great interface element called the Shelf. A file or group of files could be dragged to the Shelf (actually, it was just a proxy to those objects -- the objects themselves didn't move) for later action. Those actions could include moving, copying, deleting, opening, or otherwise manipulating the files. A group selection would show up as a single icon (specifically: a hand with some fanned cards). The best thing about the Shelf is that it could hold any number of selections for action at any future point. So immediate action wasn't necessary.
The multiple-item icon only needed a few enhancements to make it even more useful. For instance, it should have been possible to change the members of a multiple-item selection, or to get properties on a selection to determine existing members, but it wasn't.
Maybe these features will find their way into future OS X versions. The primary problem is that a Shelf would require yet-another interface element OR an expansion of the already-overloaded Dock.
[edit: fixed spelling, added a bit]
[ 01-16-2003: Message edited by: Zarafa ]</p>
<strong>
Three reasons.
One, I never liked the whole Copy, Cut, and Paste metaphor for files and folders. It seems those commands were just balatantly ripped off from Windows. What happens if you Cut a bunch of Files, then shut your computer down? I wouldn't want to go searching for them, if they haven't been deleted. Those commands should at least be under the File menu, not Edit, when dealing with Files.
Just because there's key commands for doing something, doesn't mean there shouldn't be a GUI element as well. With a drawer, the files would stay there until you moved them, so you'd never lose them if you Copied something else after you Cut some files.
What if you want to take a bunch of files and put them into different directories? cmd-c and cmd-v would be totally useless then.</strong><hr></blockquote>
*shrug* I don't care if they're from Windows or not; they are convenient and help me with file management. I also never use the Cut command if I'm not sure that I'm going to be instantly pasting the contents somewhere (I've never had a problem properly using the Clipboard for text, i.e., losing or overwriting a text fragment).
I didn't even know you could Copy and Paste files just like in Windows. That's kinda cool but scary at the same time. I'm used to having it just copy the name of the file when I press cmd-c with a file selected.
And taking things from Windows isn't bad at all. They've borrowed plenty from the Mac, why not borrow from them? Contextual menus, window-specific toolbars, and sticky menus all came from Windows, and I don't see anyone complaining about those. Well, the window-specific toolbars could use some improvement, but the other two are essential to streamlining the way you use the computer.
<strong>
The focus of 10.2 was additional features for the digital hub, and other such improvements. Speed optimizations were on the list, but lower than feature enhancements for 10.2.
I stand by what I said re: 10.3, I wouldn't be surprised if it has speed as a focus.</strong><hr></blockquote>
On time..
<strong>
The focus of 10.2 was additional features for the digital hub, and other such improvements. Speed optimizations were on the list, but lower than feature enhancements for 10.2.
I stand by what I said re: 10.3, I wouldn't be surprised if it has speed as a focus.</strong><hr></blockquote>
The features supporting the digital hub idea that came to fruition in the course of 10.2's development did not stem from work done by the basic OS development team but were developed by other teams that referred to it. Certainly, a number of extremely far reaching technologies related to digital hub connectivity were introduced in 10.2 and enhanced in the follow-up minor updates, but they were parallel efforts.
As for 10.3 speed enhancements, they will to a large extent rely on hardware features in present and upcoming models.
engpjp
<strong>The features supporting the digital hub idea that came to fruition in the course of 10.2's development did not stem from work done by the basic OS development team but were developed by other teams that referred to it. Certainly, a number of extremely far reaching technologies related to digital hub connectivity were introduced in 10.2 and enhanced in the follow-up minor updates, but they were parallel efforts.
As for 10.3 speed enhancements, they will to a large extent rely on hardware features in present and upcoming models.
</strong><hr></blockquote>
*sigh* I can't argue any further (on either issue) without saying things I shouldn't. Suffice it to say that I disagree with both of your assessments.
Apple has made it very clear that QuartzGL (I know, I know, "Quartz Extreme") is just a beginning. I'd expect some impressive improvements in this area, and some really interesting features.
[ 01-17-2003: Message edited by: Hobbes ]</p>
<strong>I think Moki just lives for those I can't say more than that without saying things I shouldn'ts.
Actually, it really sucks... but that's just the way it is.
<strong>
Actually, it really sucks... but that's just the way it is.
Would you rather live our lives; Ranting about whatever MOSR comes up with and making strange predictions on whatever tiny bit of info we get?
I would.
<hr></blockquote>
After seeing Steve Jobs demo' 'Keynote', I can't wait to see how far Apple can take Quartz Extreme in software generally and specifically for many visual enhancements in 'X'.
I'm sure there are speed 'eeks' they can get out of 10.3. But if its running on a 970, we may not notice. I'm sure it will be faster than running it on an iBook!
The next half a year can't come quick enough for me. For more than a couple of reasons...
Lemon Bon Bon :cool:
<strong>
The focus of 10.2 was additional features for the digital hub, and other such improvements. Speed optimizations were on the list, but lower than feature enhancements for 10.2.
I stand by what I said re: 10.3, I wouldn't be surprised if it has speed as a focus.</strong><hr></blockquote>
Cool... integration, now matter what stage of development, makes things behave much better. Copying and pasting between applications has made publishing much easier, and you are only limited by memory and speed of the hardware.
Increasing speed for the system as a whole, regardless of the hardware you are using, would be very useful. Updating the finder to Carbon would optimize the speed of the system that much more.
For me, the separation of Sherlock from the 'Find File' (Cmd-F) tool on the computer made things much easier and quicker.
If they can do something similar for 10.3 I will be happy. If they can do it without charging $200 CDN, I will be even happier.
<strong>
Increasing speed for the system as a whole, regardless of the hardware you are using, would be very useful.
</strong><hr></blockquote>
I agree; unfortunately, the present economy makes it even more of a no-no than before: Apple HAS to increase the turnover rate among those that already own Macs, and the classical way to do that is by, 1) increase the workload on the processor so the newest code runs irritatingly slow on two-year old machines; 2) Include support for new hardware features (including peripherals) in the new code.
[quote]Originally posted by nosey:
<strong>
Updating the finder to Carbon would optimize the speed of the system that much more.
</strong><hr></blockquote>
.. to Carbon?
engpjp
<strong>
.. to Carbon?
engpjp</strong><hr></blockquote>
Whatever. I just read that everyone is tired of the finder being -something- it shouldn't be. I am supposing that Carbon is something it shouldn't be?
Perhaps I should have used the term 'built so that it is native to Mac OS10'... is that more correct?
<strong>Perhaps I should have used the term 'built so that it is native to Mac OS10'... is that more correct?</strong><hr></blockquote>Unfortunately, some of the ill-informed masses have put out the idea that Carbon is inherently inferior to Cocoa. This is completely false. Carbon and Cocoa are near complete peers today for developing software. The problem is that the "quick ports" of software are usually done in Carbon and are poorly done, giving Carbon itself a "bad rap".
For the most part, the choice of Carbon or Cocoa is simply a case of using the right tool for the right job. Some things can be done quicker and easier in Cocoa, others in Carbon.
The Finder is a Carbon app. Though, a lot of it was written from scratch for Mac OS X. If Apple had to start all over by trying to rewrite the Finder in Cocoa, performance gains could be negligible or nonexistant until any current optimizations could be redesigned or new ones discovered.
Cocoa is not a magic cure-all for slow or buggy apps. Don't believe all the Cocoa hype.
[ 01-20-2003: Message edited by: Brad ]</p>
<strong>
I just meant -- and keep in mind here I have absolutely NO information from Apple to back this up, it is purely my speculation -- that I'd expect 10.3's focus to be on speed enhancements.
10.0 was the initial "proof of concept" release -- it had to ship
10.1 was focused on speed
10.2 was focused on additional features/functionality
It makes sense to me that 10.3 would be a regrouping release focused again on speed... there are plenty of things in Mac OS X that can be optimized further...</strong><hr></blockquote>
That sounds very logical and feasible and I had thought the same thing before reading this.
I know one area where speed can be found is in the code generated by the compiler. I read that gcc 3.1 (which was included with 10.2 for those who don't pay attention to such things), focused more on laying the foundation for PPC optimizations than in actually implementing the optimizations. Now that the foundation has been laid out, gcc3.3 should produce much better code when it is available. (Assuming that Apple's engineers haven't been sitting on their butts playing Quake all day.)
Watching the improvments in the 10.2.x updates suggests that they are putting a lot of work into speed lately. With a major system update like 10.3, they can make a lot more changes to the code and structure of things which can lead to much improved speed.
Apple wants to be the speed kings when the 970 ships. They can't allow the software to make the hardware look slow. Part of that means having good 64-bit support, but also general PowerPC optimizations will help improve speed on all machines.
I just hope the optimizations don't rely too much upon Velocity Engine because I'm still using a G3 and I know it's capable of more than it's showing right now.
<strong>Cocoa is not a magic cure-all... ...Don't believe all the Cocoa hype.
</strong><hr></blockquote>
But I thought Cocoa cured everything... I'm drinking a cup right now while typing this on a PC at work... It makes me feel marginally better... Maybe it will make this machine feel better... Her ya go...
>BBZZZzzzttt...<
[ 01-21-2003: Message edited by: nosey ]</p>
<strong>The Finder is a Carbon app. Though, a lot of it was written from scratch for Mac OS X. If Apple had to start all over by trying to rewrite the Finder in Cocoa, performance gains could be negligible or nonexistant until any current optimizations could be redesigned or new ones discovered.
Cocoa is not a magic cure-all for slow or buggy apps. Don't believe all the Cocoa hype.</strong><hr></blockquote>
All true, but they could at least move the interface to .nib and no longer fake the NSToolbar. Right now, it has a strange behaviour:
- it "takes over" the window and resizes it when customizing it. What are drawers for?
- Grey text is supposed to mean "disabled" or in background? Well, let's see.
1. Open a new Finder window. Back and Forward will be greyed out the right way. When not in focus, all toolbar buttons will be greyed out.
2. Focus the window again. Right-click on a disabled button, for example either "Back" or "Forward". Ignore the context menu, just click somewhere else. Notice how the button you right-clicked is now black.
3. Defocus the window again. The clicked button still has a black label. This bug doesn't happen for enabled buttons.
- In Toolbar Customization, the "Show:" label in the bottom left is black when in background. Also, some toolbar buttons are.
I didn't try these things in an English OS X, so it may be localization bugs, but even so, they should just rather use NSToolbar which won't confuse the heck out of normal users.
Sure, this stuff is minor, but shouldn't exist in any stable release in one of the most important apps.