IDE suggestion

Blair,

I might have made this suggestion before, but I'd rather err toward
ensuring that you've seen it.  When dragging a method to another class
(to copy it), it is common to have compiler errors, which result in a
message box that must be cleared before going to the site of the
problem.  My suggestion is to simply activate the drop target browser on
the compilation failed method; it's glowing red, so there is little
difficulty with recognizing the error condition.  If it can be done (and
does not cause other problems), it would save a few clicks.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill Schwab wrote:

> When dragging a method to another class
> (to copy it), it is common to have compiler errors, which result in a
> message box that must be cleared before going to the site of the
> problem.  My suggestion is to simply activate the drop target browser on
> the compilation failed method; it's glowing red

Seconded.  Or at least have the option to get no popup warnings in this case (I
see lots of them and they get tiresome quickly -- especially as I know they are
going to appear).

On a somewhat releated note, I think the behaviour is wrong when
drag-and-dropping a groups of methods, and one of them would overwrite another.
What currently seems to happen is that it asks you if you want to overwrite it,
and if you say 'yes' then it does so and continues with the rest of the
methods.  That's OK, but if you say 'no' then it doesn't overwrite the method,
but also aborts the copy loop, so /some/ of the methods are copied, but you
don't know which.  That means that in practise I always have to answer 'yes'
and then go back later and resurect any methods that I didn't want to have
overwritten.

I think that, at minumum, the prompt should be a yes/no/cancel choice, where
either 'yes' or 'no' would continue the loop.  Ideally it'd also have 'yes to
all' and 'no to all' options.

Please ?

    -- chris

Bill,

> I might have made this suggestion before, but I'd rather err toward
> ensuring that you've seen it.  When dragging a method to another
> class (to copy it), it is common to have compiler errors, which
> result in a message box that must be cleared before going to the site
> of the problem.  My suggestion is to simply activate the drop target
> browser on the compilation failed method; it's glowing red, so there
> is little difficulty with recognizing the error condition.  If it can
> be done (and does not cause other problems), it would save a few
> clicks.

I recall when we were first implementing drag and drop that the user
interface guidlines (I can't remember where now) indicated that the
source window should always remain active, rather than the target
window becoming active on the drop.

However, now I look at a number of applications that use D&D I see that
this is not necessarily the case. Hence we could look at implementing
you suggestion or something similar.

Best regards

Andy Bower
Dolphin Support
www.object-arts.com

Andy,

> I recall when we were first implementing drag and drop that the user
> interface guidlines (I can't remember where now) indicated that the
> source window should always remain active, rather than the target
> window becoming active on the drop.
>
> However, now I look at a number of applications that use D&D I see that
> this is not necessarily the case. Hence we could look at implementing
> you suggestion or something similar.

Chris' point of simply removing the message box would be a big help, as
the target window is going to be at least partially visible, or it would
have been a tricky drop target :)

It occurs to me that the guildelines (however often ignored) are
probably much preferred when the operation is successful, as the user
might want to drag something else from the same source.  Perhaps you
could add an #activateDropTargetOnError or something like it for the
browsers??

IIRC, you or Blair mentioned that D6 will provide easy (easier)
customization of the colors used for syntax highlighting.  A while back,
I took the time to find the error color and replace it with the symbol
color: much nicer.  A couple of weeks later, you issused a new release
and I never propagated the change.  The uniform color sill maked the
error very obvious, but was much easier on the eyes.  If for some reason
you can't get the the slick customization in D6, please consider toning
down the error color.

Thanks!!

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill,

> A while back,
> I took the time to find the error color and replace it with the symbol
> color: much nicer.  A couple of weeks later, you issused a new release
> and I never propagated the change.  The uniform color sill maked the
> error very obvious, but was much easier on the eyes.

In case it helps anyone, here's an extract from my customisation scripts.
Turns off italic comments, and replaces the error colour with the maroon that's
used for literals.  Other pre-defined colour values are 0: black, 1: blue, and
of course, 3: red.  (4 seems to be black too, I don't know why.)

    "see Compiler class>>defaultSyntaxColors for the defaults"
    Compiler
        syntaxColorAt: #InError put:  '\cf2 ';
        syntaxColorAt: #Comment put:  '\cf4 '.


Presumably there's some way of using other colours, but maroon is Good Enough
for me.

    -- chris

"Bill Schwab" <[hidden email]> wrote in message
news:ckudp1$14im$[hidden email]...
>...
>
> IIRC, you or Blair mentioned that D6 will provide easy (easier)
> customization of the colors used for syntax highlighting.

This is configurable through User Preferences - there is a special presenter
for the published aspect inspector. This can also be used (and a related
dialog) in one's own applications should one wish to employ the Scintilla
edit control in those.

>...A while back, I took the time to find the error color and replace it
>with the symbol color: much nicer.  A couple of weeks later, you issused a
>new release and I never propagated the change.  The uniform color sill
>maked the error very obvious, but was much easier on the eyes.  If for some
>reason you can't get the the slick customization in D6, please consider
>toning down the error color.

There is no error colour*. In D5 and earlier syntax colouring was done by
the compiler, and so was unable to complete when the method could not be
parsed - although it could have been made more tolerant than it was, there
would always have been cases where the method could not be coloured, so it
would have been inconsistent to handle some error cases differently. In D6
syntax colouring is done dynamically as you type, or as a method is
displayed. This is done entirely by lexical analysis at present, although
some nasty cases (the ambiguity between unary selectors and variable names
for example) require some noddy parsing to sort out. This work has not been
done yet, incidentally, but the experience of using it is still much better
than having to wait to run the compiler - one can identify certain errors
such as missing comment delimiters immediately.

Compilation errors are now identified in two ways - 1) The error icon in the
method list, and 2) The use of squiggly underlines.

Regards

Blair

*Actually this is not strictly true, there is an error colour for invalid
tokens, but you are unlikely to see it in practice, and certainly not for an
entire method.

Blair,

> This is configurable through User Preferences - there is a special presenter
> for the published aspect inspector. This can also be used (and a related
> dialog) in one's own applications should one wish to employ the Scintilla
> edit control in those.

Sounds good.


>>...A while back, I took the time to find the error color and replace it
>>with the symbol color: much nicer.  A couple of weeks later, you issused a
>>new release and I never propagated the change.  The uniform color sill
>>maked the error very obvious, but was much easier on the eyes.  If for some
>>reason you can't get the the slick customization in D6, please consider
>>toning down the error color.
>
>
> There is no error colour*. In D5 and earlier

I realize that you have been working an (and therefore with) D6 for some
time, but for the rest of us, D5 is the current version, and...


 > syntax colouring was done by
> the compiler,

which turns the whole thing red on any compilation error.

I'm glad to hear that this will be improved in D6, and while I have not
yet tried it, **profusely** thank Chris for his script on the subject.
The last time I changed the color, it was a LOT more work.  No doubt,
you have been gradually moving in the direction of configurability.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Chris,

> Presumably there's some way of using other colours, but maroon is Good Enough
> for me.

Agreed, it makes the point, but is a lot easier to read than bright red.

THANKS!!

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"Bill Schwab" <[hidden email]> wrote in message
news:cl0vj6$147q$[hidden email]...
I realise that too. But your final sentence contains a direct reference to
D6. I therefore took your suggestion to be for D6, and I was merely pointing
out that, helpful as it was, it would no longer be relevant. At this stage
in the product life-cycle we will not be making much in the way of
enhancements to D5, although there will be a final 5.1.5 Dolphin release in
this quarter.

> > syntax colouring was done by
>> the compiler,
>
> which turns the whole thing red on any compilation error.
>
> I'm glad to hear that this will be improved in D6, and while I have not
> yet tried it, **profusely** thank Chris for his script on the subject. The
> last time I changed the color, it was a LOT more work.  No doubt, you have
> been gradually moving in the direction of configurability.

Erm, I don't think it could ever have been that hard to change the colours
(if indeed it is not now), since as far as I recall we haven't significantly
changed the way in which the compiler colours could be changed since they
were introduced. If we have been moving "gradually" towards configurability
in that respect then the movement has been so gradual as to be unobservable
:-).

Regards

Blair

Blair,

> I realise that too. But your final sentence contains a direct reference to
> D6. I therefore took your suggestion to be for D6, and I was merely pointing
> out that, helpful as it was, it would no longer be relevant.

I wondered about that - please chalk it up as a different form of "when
will we see D6?" :)


 > At this stage
> in the product life-cycle we will not be making much in the way of
> enhancements to D5, although there will be a final 5.1.5 Dolphin release in
> this quarter.

Sounds good.


> Erm, I don't think it could ever have been that hard to change the colours
> (if indeed it is not now), since as far as I recall we haven't significantly
> changed the way in which the compiler colours could be changed since they
> were introduced. If we have been moving "gradually" towards configurability
> in that respect then the movement has been so gradual as to be unobservable
> :-).

I wondered about that too, but it occurs to me that: (1) it was a really
long time ago (in Dolphin years anyway); (2) I might have made it harder
than it needed to be.  However, I recall crawling through a very ugly
RTF string to find the correct slot.  Necessary or not, I did it that way.

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]