Spotlight indexing: feature request proposal
Ken Ray
kray at sonsothunder.com
Mon Aug 1 12:02:04 EDT 2005
On 7/31/05 8:29 PM, "Sarah Reichelt" <sarahr at genesearch.com.au> wrote:
>> I propose the addition of two new stack properties for telling
>> Spotlight how to index stacks:
>> - the <spotlightScript> of this stack: if true the scripts of the
>> stack is indexed by Spotlight. If false, no script indexing is done
>> for the stack.
>> - the <spotlightText> of this stack: if true the content of fields
>> and titles of objects are indexed by Spotlight. If false, objects
>> content indexing is not done for the stack.
>> By default both properties are true (i.e. when the stack is
>> created). When creating a substack, its spotlight properties are
>> default to the value of its mainstack but they can be changed
>> independantly from the mainstack.
>
> I agree - mostly. Sometimes I would really like the text to be
> indexed but I realize this places an extra burden on the system, so I
> would like the text search OFF by default and restricted to unlocked
> fields.
I agree Sarah - especially in "database"-style stacks (usually HyperCard
ports) that have tons of text... it would be better to default it to OFF so
that there is one less thing for people to have to remember.
Perhaps it shouldn't be a stack-wide property, but a specific field
property? I was thinking of something like "dontSearch" (which we currently
have)... how about "dontIndex" which is a field property that defaults to
true. If you want certain content fields indexed, you just turn it on...
> As regards the password-protected scripts, have you tried this? I
> just tested it and Spotlight does not index password-protected stacks.
I think regardless of whether this is true or not (and I believe you Sarah!)
I think that you may not want to have the scripts of certain stacks indexed
for other reasons, so having the flag there (defaulted to TRUE) is a good
thing anyway, IMHO.
Ken Ray
Sons of Thunder Software
Web site: http://www.sonsothunder.com/
Email: kray at sonsothunder.com
More information about the use-livecode
mailing list