Re: Smile [well, it was about that, but not anymore]
Re: Smile [well, it was about that, but not anymore]
- Subject: Re: Smile [well, it was about that, but not anymore]
- From: cris <email@hidden>
- Date: Wed, 31 Jan 2001 21:37:33 +0100
on 30.01.2001 11:55 Uhr, Cal at email@hidden wrote:
>
and when
>
you want all those extra power tools, they are accessible with a
>
extra key (option, shift, etc.) held down when double-clicking, etc.
>
It's my preference for design (and it's not everyone's).
Do you do Scripter just for yourself or also for other people?
Scripter already do waste screen space. You have to put the app bar and the
toolbar somewhere. I don't know what to do with the space that these
palettes left unused free. Why not more buttons, for opening the various
windows, for example? Why do i have to study the manual to learn how some
windows open?
>
After all, there have to be some discoveries when you read the manual
>
or the help system. :^)
Great...
>
>>> Scripter doesn't compile a script automatically when the user
>
> choose to run
>
>> or save it, instead giving always an error message. Script Debugger and
>
>> Script Editor does.
>
>
>
> Scripter does not save an uncompiled script without asking the user if
>
> that's what they want to do. It's not an error message, it gives you a
>
> option to save as text or compile and then save. With Script Editor you can
>
> only save a script as text if it won't compile. I prefer having the option
>
> to save an uncompiled script as text.
>
>
I've been looking into alternative ways to handle this in Scripter.
>
I feel that the Script Editor's way produces unnecessary extra
>
compiling and warnings if you have a compile error and you try to
>
save it again, you'll compile the script again and get warned again.
>
The idea was to avoid that extra compilation (particularly annoying
>
on scripts that are 500-1000 lines).
Maybe that was a problem years ago, as machines where much slower.
>
> It does automatically compile a script when you Step or Run.
>
>
>
> Even so, is automatic compiling such a big issue? It's a difference of
>
> hitting a single keystrong (the enter key) before running/saving.
>
>
This to me is the point. It's one keypress.
Yes, how often a day it is only a keystroke... And in fact it is a click
into the cancel button (because command-d doesn't work), then you have to
hit enter, then you have to wait, and THEN you can hit command-s to save...
It's just wrong. If i decided once to save this script code as a compiled
script, the editor should do what's neccessary to save it in that format. Is
compiling is neccessary, hell, just do it.
If you think your opinion is valid as mine is, just make it a preference for
you and me. Scripter has very few prefs, it's no problem to have 20
checkboxes more. After all, this claims to be a development tool, so i think
the people that are using it, are able to setup things as they need it.
>
>> Scripter does not compile larger lists or &-statements. Script Debugger and
>
>> Script Editor do.
>
>
>
> I've compiled scripts with huge lists in Scripter, I'm not sure what you're
>
> claiming here. Could you send me an example offline?
>
Yes, and could you send that to me, along with an example of the
>
&-statements (in private email) as well? Thanks.
I already did, and you replied me already long time ago that you know of
this. It is the "statement contains too many characters problem". It affects
lists, statements with ampersands or just plain text.
>
>> But more important as an comparison how close an editor is on Apples Script
>
>> Editor is the fact that Main Event is very unresponsive in removing all the
>
>> small bad things that bother scripters every day. The 2.5 update (fee) has
>
>> covered nothing what was really important for the daily use. Very
>
>> disappointing to see an actually really good tool in such a state.
>
>
Cris, I think it's fair to say that these "small bad things" bother
>
_you_ every day. If there were problems that bothered everybody than
>
our product would not be in such wide use.
The "problem" is that Scripter is quite good in debugging, so people want to
use it for that. But that means not that they are happy with everything of
it. I believe many people gived up making suggestions because of wasting the
time.
Beside this, people do not always immediately know what disadvantages a
product has. Even a trial don't let you everthing know what bothers you
probably later. So the claimed "wide use" is not a proove for a good
interface.
A good interface let the user choose (surely not in all cases) how he want
to do something or the behaviour of something. There are always more ways to
do the things and at the end they are all valid. In Scripter one well known
man has decided what is good and what is not good or neccessary for the
user. Many thanks for taking these hard decisions from the users!
>
I know you've emailed me
>
before with a few problems...I am going back to review your list
>
again.
>
>
[I feel it prudent to let the readers of this list know that, in the
>
past, if Cris had problems with Scripter, he would only publicly
>
wrote about the problems
Yes, two reasons:
a) Writing to MainEvent ends in a nice talk with a smiling wall. The wall is
hearing you, the wall is even answering you (good wall!), but after all it's
a wall. Did you ever wrote to www.trashcan.go ?
b) Talking about such things on a list makes much sense since other people
can agree, disagree or add their own ideas to others. This is very effective
and can be a good chance for the vendor to get opinions (if it's that what
they want..).
>
and would not mention that he liked the
>
product; he felt that it's not his job.
Right, advertising is in first line one of your jobs. I did was my job is
and payed you for Scripter. I even continued this payjob as i buyed the 2.5
update. At some point it's your turn to do your job... No, sorry, no more
advertising - better usability is what i talk about.
>
Fair enough, that's his
>
choice...I just wanted the readers of this list to be aware of this.]
Thank you. So we also don't want keep the secret that i'm now looking for
Script Debugger because Scripter is not usable for larger Scripts and the
other things that bother _me_, right me, the user (the one who paid and is
even willing to pay for updates that only contain bugfixes).
>
And as far as the 2.5 update goes, it has the Object Prober for
>
looking at live objects and their properties (roughly equivalent to
>
SD's Inspector but operates differently),
Yes, obviously. Script Debugger's Explorer shows more and looks far better.
>
the ability to search
>
dictionaries looking for terms, and a few other improvements. These
>
may not make a difference to you, Cris, but you can bet that they do
>
to others.
Sure.
(...)
>
Most good scripters can get most of what they want done in scripts
>
each containing several hundred lines or less.
Yes, and very good scripters do environment checking and error handling.
That can be more than 50% of a script.
>
As I've said in past
>
months, many scripts that are 32K are longer can be distilled down to
>
a much smaller size.
Yes, start removing your code comments for example, a very good idea...
>
So I'd amend your statement to say "and
>
Scripter for all but the hugest projects or to seriously debug."
Cal, you can say what you want, it is my experience that a script with good
error handling and a middle large code documentation has not much space for
the actual code left. 32KB was yesterday if not even the day before.
Of course is it enough for many scripts, but if you reach the limit only one
time and really need to debug a problem you already have to switch to
another editor, that's the point. So for a newbie it is surely a good
question why not using an unlimited thing like Smile or Script Debugger from
the beginning!?
>
Both Scripter and SD have debuggers with different features. Not
>
everyone needs to use everything, but there are advanced things you
>
can do very simply in debugging with Scripter that you can't do
>
anywhere else.
What about adding variables automatically to the observe window like in
Script Debugger? That would be one improvement in usablility!
What about fixing the cgi-editing-path issue?
What about fixing window managment?
Continue?
Greetings
cris
--
English is my second language and Scripter is great.
www.cooc.de