More stuff

Package Browser:
=============

Try this: decide to remove the sample packages (as I always do), click on
the "samples" folder, all the samples are now displayed and ready to remove
(this works well -- very convenient), select all of them (actually a no-op),
choose 'uninstall'.  Then there is a tedium of button clicking and screen
refreshes that feels as if it is never going to end (but was probably only a
couple of minutes, if that).

Suggestion: the full (not '$' relative) pathname of the single selected
package (if any) should be displayed in the status line.

Suggestion: (actually the current behaviour feels so wrong that I'm tempted
to call it a bug), when a folder is selected, then the file open dialog for
installing a new package should start in that folder.

Installing a package should either leave the current selected folder alone,
or change it to the folder where the new package lives; it should not reset
to the root of the tree.  Similarly for uninstalling.

Flippers (nice name):
===============
Not really a bug, but inspecting:
    DATE now
looks decidedly odd.  It's presumably by intent, but I can't interpret
what's happening.

Inspecting:
    DesktopView current
gives a walkback, apparently because DesktopView doesn't override #name back
to:
    ^ nil
(since it has no parent).

CHB and System Browser:
====================
Classes which are not in packages don't show up in the system browser.

The system browser and the various views of CHB still have the "generate
accessors" command in their menus, but #generateAccessors is not defined
(presumably made redundant by the new stuff).

Misc:
====
Is DolphinOAEdition intended to be part of the distro ?

About redist.txt.  I see the list of classes we may not redistribute.  No
problems there (though I'm a little surprised to see Walkback included);
does that list correspond to the contents of some specific set of packages ?

I've just exited D5, copied a backup version of the image files to the
default location, overwriting the existing files, then attempted to restart
D5.  I get the image-file-is-already-open dialog.  This seems to be because
an old version of D5 is still running but has no open windows.  I had some
problems with that instance (the STB version problem and the VC) so some
windows weren't created properly, and I assume that's why that Dolphin
didn't die when it said it would.  Not a major problem, I only mention it
because I don't remember seeing it happen with D4.

(I know this isn't really OA's patch) The list of "suspect" selectors in
BlockLintRule>>badSelectors is not tuned to Dolphin (most of 'em don't even
exist).  I _suggest_ the following list:

    #become: #oneWayBecome: #swappingBecome:
    #becomeA: #becomeAn:
    #isKindOf: #isMemberOf: #includesBehavior: #respondsTo:
    #allReferences
    #instVarAt: #instVarAt:put:
    #isString #isSymbol #isVariableBinding
    #halt

I've now been able to get at least some of my code into the new beta, so I
hope that future reports will be more substantive...

    -- chris

Chris

You wrote in message news:[hidden email]...
> Package Browser:
> =============
>
> Try this: decide to remove the sample packages (as I always do), click on
> the "samples" folder, all the samples are now displayed and ready to
remove
> (this works well -- very convenient), select all of them (actually a
no-op),
> choose 'uninstall'.  Then there is a tedium of button clicking and screen
> refreshes that feels as if it is never going to end (but was probably only
a
> couple of minutes, if that).

Yes, it is implemented in a very simple way (i.e. a loop around uninstalling
a single package), that could certainly be improved upon if there is time.
Defect #508.

> Suggestion: the full (not '$' relative) pathname of the single selected
> package (if any) should be displayed in the status line.

Good idea. #509

> Suggestion: (actually the current behaviour feels so wrong that I'm
tempted
> to call it a bug), when a folder is selected, then the file open dialog
for
> installing a new package should start in that folder.

I agree. #510.

> Installing a package should either leave the current selected folder
alone,
> or change it to the folder where the new package lives; it should not
reset
> to the root of the tree.  Similarly for uninstalling.

I have found that quite maddening as well. #511.

>
> Flippers (nice name):
> ===============
> Not really a bug, but inspecting:
>     DATE now
> looks decidedly odd.  It's presumably by intent, but I can't interpret
> what's happening.

I don't really follow. I think it would look better if we used an
alternative view for dates mind you, because the DateTimePicker control
seems to stretch its checkbox to fit, but nothing else. Unfortunately it is
probably the only specific (i.e. not just simple text) that can be
guaranteed to be available, since the other alternatives are OCXs.

> Inspecting:
>     DesktopView current
> gives a walkback, apparently because DesktopView doesn't override #name
back
> to:
>     ^ nil
> (since it has no parent).
>

We have already modified the inspector for the next release to suppress
errors accessing the values of aspects (be they published or instance
variables) in the same way that the old inspector used to. Without this
feature the inspector is less than useful for inspecting objects in an
indeterminate/invalid state, and during development in general. Nevertheless
you are right that #name (and #name:) should be overridden by DesktopView
(#511).

> CHB and System Browser:
> ====================
> Classes which are not in packages don't show up in the system browser.

True. It probably needs to show the '_Uncommitted' virtual package. Defect
#512.

> The system browser and the various views of CHB still have the "generate
> accessors" command in their menus, but #generateAccessors is not defined
> (presumably made redundant by the new stuff).

This command may still be required for when the refactoring browser is not
installed (e.g. in a lower-end edition of Dolphin). We'll check anyway,
#513.

> Misc:
> ====
> Is DolphinOAEdition intended to be part of the distro ?

No, thanks.

> About redist.txt.  I see the list of classes we may not redistribute.  No
> problems there (though I'm a little surprised to see Walkback included);
> does that list correspond to the contents of some specific set of packages
?

Not entirely. It is the contents of the 'Development' class category,
although this is mainly comprised of the contents of the various packages
under $/Object Arts/Dolphin/IDE.

WalkbackDialog is not used in a runtime application - it wouldn't have
thought it appropriate to display that sort of information to an end user.
Walkback details are written to the error log though.

Licensing remains the same as D4 in this respect, although there will be
differences in the context of redist.txt. If there are specific development
classes any one wishes to distribute we may give permission on request.

>
> I've just exited D5, copied a backup version of the image files to the
> default location, overwriting the existing files, then attempted to
restart
> D5.  I get the image-file-is-already-open dialog.  This seems to be
because
> an old version of D5 is still running but has no open windows.  I had some
> problems with that instance (the STB version problem and the VC) so some
> windows weren't created properly, and I assume that's why that Dolphin
> didn't die when it said it would.  Not a major problem, I only mention it
> because I don't remember seeing it happen with D4.

It could happen in either system, especially if the system failed to start
up properly (and didn't get as far as opening the main system folder).

>
> (I know this isn't really OA's patch) The list of "suspect" selectors in
> BlockLintRule>>badSelectors is not tuned to Dolphin (most of 'em don't
even
> exist).  I _suggest_ the following list:
>
>     #become: #oneWayBecome: #swappingBecome:
>     #becomeA: #becomeAn:
>     #isKindOf: #isMemberOf: #includesBehavior: #respondsTo:
>     #allReferences
>     #instVarAt: #instVarAt:put:
>     #isString #isSymbol #isVariableBinding
>     #halt

Thanks anyway, I'll modify them.

Regards

Blair

Blair,

> > Not really a bug, but inspecting:
> >     DATE now
> > looks decidedly odd.  It's presumably by intent, but I can't interpret
> > what's happening.
>
> I don't really follow. I think it would look better if we used an
> alternative view for dates mind you, because the DateTimePicker control
> seems to stretch its checkbox to fit, but nothing else. Unfortunately it
is
> probably the only specific (i.e. not just simple text) that can be
> guaranteed to be available, since the other alternatives are OCXs.

Oh, is that what it is ?  I hadn't realised, but now you mention it I can
see a painfully stretched button (or is it a drop list) for bringing up a
month calendar.

Just in case you hadn't noticed, I'd better admit that I allowed my dislike
of #isString, etc, to creep into the list -- you may (but I'd cheer you on
if you didn't) want to tone it down in that respect...

> Blair

    -- chris

"Chris Uppal" <[hidden email]> wrote in message
news:[hidden email]...
> ...
> > > (I know this isn't really OA's patch) The list of "suspect" selectors
in dislike
> of #isString, etc, to creep into the list -- you may (but I'd cheer you on
> if you didn't) want to tone it down in that respect...

I think Andy and I have made it pretty clear where we stand on that issue
before :-). I've been thinking about adding a Smalllint Rule that locates
all such "class" tests, but I haven't been able to think how to do it yet.

Regards

Blair

Blair,

> > Just in case you hadn't noticed, I'd better admit that I allowed my
> dislike
> > of #isString, etc, to creep into the list -- you may (but I'd cheer you
on
> > if you didn't) want to tone it down in that respect...
>
> I think Andy and I have made it pretty clear where we stand on that issue
> before :-). I've been thinking about adding a Smalllint Rule that locates
> all such "class" tests, but I haven't been able to think how to do it yet.

Good :)  Actually, I agree with you until forced to resort to #isKindOf::
etc., at which point "loose" methods make a lot more sense.  It's also been
noted that the new message allows multiple types to be recognized
independent of inheritance relations.  Such methods do not necessarily need
to be present in Object to be useful.

Have a good one,

Bill

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

"Bill Schwab" <[hidden email]> wrote in message
news:[hidden email]...
> Blair,
>
> > > Just in case you hadn't noticed, I'd better admit that I allowed my
> > dislike
> > > of #isString, etc, to creep into the list -- you may (but I'd cheer
you
> on
> > > if you didn't) want to tone it down in that respect...
> >
> > I think Andy and I have made it pretty clear where we stand on that
issue
> > before :-). I've been thinking about adding a Smalllint Rule that
locates
> > all such "class" tests, but I haven't been able to think how to do it
yet.
>
> Good :)  Actually, I agree with you until forced to resort to #isKindOf::
> etc., at which point "loose" methods make a lot more sense.  It's also
been
> noted that the new message allows multiple types to be recognized
> independent of inheritance relations.  Such methods do not necessarily
need
> to be present in Object to be useful.

Yes, but if so those methods should be testing for an "interface" rather
than a class, and should be named accordingly. A good example is the
Smalltalk-80 method #understandsArithmetic. #isString is a bad example. Most
of the examples of #is<class name> that one sees are dubious at best -
Visual Smalltalk includes a lot that are worse even than #isString.

Although not supported by all Smalltalks at present (and not fully developed
in Dolphin), the general concept of interfaces/protocols is better used to
perform these type of tests. For example, within the command handling
framework of Dolphin we test potential command targets to see if they
implement the #commandTarget protocol (see e.g.
CommandPolicy>>appendPresenter:). IMHO it is a lot better to provide a
general mechansim for this than ever extending the number of messages
understood by every Object.

Dave Simmons has taken this one step further and in Smallscript
interfaces/protocols are classes. This unified approach allows one to revent
to using #isKindOf:, instead of having a separate #conformsToProtocol:
message, and would seem to be the best way to move the Smalltalk language
forward in this respect.

Regards

Blair