On Oct 15, 2006, at 1:33 AM, David Niemeijer wrote:
The reason I never really realized this is because they have
another system with application-wide licensing instead of system-
wide licensing where the voice will nag but will then speak. That's
the system I was used to, however those voices won't offer a full
trial when not licensed.
Ah, fair enough.caussssssssssssssssssssssssssssssssssssssssssssssssss
Of course you are free to discuss this topic here and I think it
was a good idea to warn other blind users to take care when using
the demo. However, as you like to speak about what is good and bad
form, you could have first sent an email to Infovox iVox support to
bring up the issue to get the other side of the story before
posting the issue.
Again, fair enough, and I do apologize for having taken that
approach. At the time I was quite upset at having my work stalled,
spending a few hours trying to fix the problem via SSH then
eventually realizing that I could use the other computer to duplicate
the steps. And, while I do sympathize with your position, I don't
respond well to others telling me what I should have done/known when
the situation was quite frustrating for me to begin with, so my
subsequent responses were fueled by my annoyance at my perceptions of
those statements. Thanks for explaining matters, and I should have
handled things differently, but I didn't quite appreciate the "you
should have known better" approach after having made an honest
evaluation then trying to fix things on my end. :)
Anyway, given that you clearly have well outlined ideas about how
demos should function, what would be your ideal and second to ideal
scenarios for the Infovox iVox demo. I will then take these two
suggestions as a starting point in my discussions with Acepale on
how we can resolve this issue. Though bare in mind that I cannot
promise the solution you suggest will actually be implemented as it
may cause too many technical headaches at Acapela's end (the core
code of iVox is multi-platform and they are very careful when it
comes to making changes to the evaluation system). But, I fully
agree they need to come up with a better solution that going from
full use to no use when the demo expires.
Sure. Here are a few of varying levels of possibility, though they're
given without much knowledge of the core technologies:
Have the installer queue a launchd task at day 29 of the evaluation.
The task would pop up a dialogue warning the user that the evaluation
will soon expire and lock up VoiceOver.
Does the voice have any facilities for registering callbacks? If so,
is there one for expiration, and might it be hooked such that some
other voice is selected automatically? Or, failing that, could the
above launchd method be used to simply switch the voice to some other
default before the Acapela voice locks?
Could a 31-day evaluation of the voice itself be secured while
Infovox continues with a 30-day evaluation? Then, at 30 days, the
voice could be changed with a notice that the demo has expired? I'd
have no sympathy for someone trying to run a demo after and having a
locked-up computer with which to deal. :)
They're a bit hackish, but I think those solutions should be
independent of the voice itself (at least, the first two should,)
though admittedly they don't handle the case of someone leaving their
computer off during or beyond day 29. Does launchd let you hook into
system startup as cron does? Perhaps this check logic could be
inserted into the startup procedure to handle that case as well.
Again, sorry for taking things as far as I have, and again, most of
my frustrations are currently directed at my perceptions of the
implication that I shouldn't have made a full 30-day evaluation, that
I should have been counting down the days, etc., and I don't regret
or change those frustrations. I do regret letting them bleed over
into rants about good and bad form, however, and am glad to see that
you read this list and are aware of the problem. Good to see
companies with engineers/developers in the trenches, as it were. I'm
used to submitting developer-oriented brainstorms/bug reports/feature
requests and having them brushed aside. :)
I'll continue responding to this thread in a technical capacity, and
would be happy to help brainstorm about how this might be changed,
but I'll not continue any discussion with regard to the above non-
Infovox frustrations. :) Agreeing to disagree seems wisest.
