Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Tiger Gold Master?
- Thread starter Superhob
- Start date
- Sort by reaction score
Anything supported by Spotlight will benefit from the fact that Spotlight is database-driven, including the Finder. I don't know what exactly a database-driven Finder would have as far as features.bushgreen said:
Some of you may like to hear the 2 hour long live broadcast
on WAMU Tuesday April 5th, Noon till 2:00 EST from the Washington D.C. FOSE convention with Kojo and The Computer Guys.
http://www.wamu.org
My gut feelings tell me that Tiger will be preloaded into all
Apple's product displays, at least in some form of a demo.
on WAMU Tuesday April 5th, Noon till 2:00 EST from the Washington D.C. FOSE convention with Kojo and The Computer Guys.
http://www.wamu.org
My gut feelings tell me that Tiger will be preloaded into all
Apple's product displays, at least in some form of a demo.
You've got to be kidding me. There's no way gcc, or any compiler for that matter, could do such things without being explicitly instructed how to do so. There's also the possibility that any auto-generated code dependent on OS-level features will break in some future update, which makes the whole idea unreasonable. Basically, if developers want to support Spotlight, they have to write code specifically for that purpose.Lacero said:
not always....
This isn't always true - old code can inherit new features if the old code is calling system functions that are enhanced to support the new features.
Programs (most anyway) don't write their own "open file" dialogs - they use the system supplied "open file" widget. If that widget is enhanced to use Spotlight, then the old code can use Spotlight to find the file to open.
Since the O/S supplies a rich assortment of builtin functions, many enhancements are usable by old code when the builtins are improved.
For example, if you run Netscape 3 on Windows (which I do occasionally to test web pages) - you may notice that it fully understands the latest 5-button scroll mouses. The Netscape code hasn't been changed since 1996, but the old code is calling new XP controls that understand the new features.
wrldwzrd89 said:
This isn't always true - old code can inherit new features if the old code is calling system functions that are enhanced to support the new features.
Programs (most anyway) don't write their own "open file" dialogs - they use the system supplied "open file" widget. If that widget is enhanced to use Spotlight, then the old code can use Spotlight to find the file to open.
Since the O/S supplies a rich assortment of builtin functions, many enhancements are usable by old code when the builtins are improved.
For example, if you run Netscape 3 on Windows (which I do occasionally to test web pages) - you may notice that it fully understands the latest 5-button scroll mouses. The Netscape code hasn't been changed since 1996, but the old code is calling new XP controls that understand the new features.
So, an app written before the advent of 5-botton scroll wheel mice, which inherits this updated API, is magically going to have the capability to use said mouse, without modification? Interesting. I wonder how the old app manages to allow you to assign functions to mouse buttons it doesn't know are available? Of course, we could always have a developer that is so farsighted that he/she would build in the code in anticipation of new mouse capabilities, but how would he/she test those functions at the time of the code release?AidenShaw said:
So, the "open file" dialog had a certain set of properties when the app was written. Now the "open file" dialog has added 5 new properties. Can you tell me how the original app, unmodified, manages to take advantage of that?
Unless new functionality is added in such a way that the API *doesn't* change, there's no way an app can take advantage of those new functions without a new code release. If I'm missing something (always possible), please educate me.
BTW, Aiden, how would the new "open file" widget be enhanced to use Spotlight unless it could assume the file format that the app works on had been updated to include the meta data that Spotlight depends on? Just curious; I'm sure you will tell me.
I'm being a devil's advocate here. I'm old school, so maybe I just don't grook a concept understood by others.
daveL said:
Think about the cabilities built into the widget in 1996.
The widget had "scroll up/scroll down" features back then. The user would click or drag on the scroll bar, and the system widget would tell the application that the user wanted to scroll up or down so many lines.
When the wheel mouse came along, the widget was updated to interpret wheel rotations as scroll bar manipulations.
The user moves the wheel a half turn, and the system widget tells the old application that the user did two trough-clicks. The user moves the wheel a tiny bit, and the system widget sends the message that the user clicked the scroll arrow.
It should be pretty easy to understand that wheel actions can be directly mapped onto scroll bar actions - and that old applications that only understand scroll bar actions can be manipulated with a wheel mouse.
daveL said:
The major property of the "open file" dialog is that it returns (to the application) the name of the file to open. The application is completely ignorant of the mechanism involved - all it knows is that when the dialog returns it give the app the name of the file to open.
This has been a "finder" type of operation - you navigate the file system, find the file, select and click OK.
In Windows, this "open file" dialog really runs the File Explorer - I assume on the Mac that it has some of the Finder capabilities as well.
If so, then maybe inside the dialog we go off into the Spotlight part of the Finder to find the file.
When we click "OK" though, the old application is merely given the name of the file to open. The app is clueless about how we decided which file to open.
This doesn't require any changes to the "open file" dialog - the original API said (perhaps) that the caller suggested a starting directory and a default file type. The API says that the routine returns the fully qualified path to the desired file.
All kinds of magic can happen within the definition of the original API.
daveL said:
"grok", not "grook" (typo assumed ;-) )
A lot depends on the original APIs being defined with some generality.
For example, in the case of Netscape 3.0 on Windows, it's pretty straightforward to understand how to map wheel actions onto an API that's defined for clicking in a scroll bar. Maybe a new wheel-aware API can be defined, but whatever you do to the wheel can be mapped onto a more-or-less equivalent action on the scroll bar.
Similarly, my new 5 button mouse has keys mapped to "forward" and "back". That's new - but the old API had keyboard shortcuts for "forward" and "back". All the new software has to do is "pretend" that when I hit the "back" button on the 5 button mouse, that the program thinks that I hit the keyboard shortcut for "back".
The old program doesn't change - it thinks that I'm clicking the scroll bar and using the "back" shortcut. It doesn't need a new API to understand that I'm really using the wheel and MB5.
__________
ps: The assignment of MB5 -> "back" is done at the O/S level - not at the application level. It's a system-wide mapping of a new hardware button to an existing keyboard shortcut.
That's how the legacy application can get the new feature - the legacy app sees the shortcut.
Of course, new apps can use newer APIs and directly see the buttons being pressed.
However, this thread started as a reply that "maybe old apps will be able to use some of Spotlight's features". We really need someone who's been using the 10.4 betas to comment....