Someone had to ask ...

... so it might as well be me.

There have been a few comments recently about the next release of Dolphin
(5.0 IIRC) so I was wondering if Andy or Blair might like to comment on a
possible time frame and/or features list.

I'll understand if you don't want to commit yourselves though <g>

Ian

Ian,

> There have been a few comments recently about the next release of Dolphin
> (5.0 IIRC) so I was wondering if Andy or Blair might like to comment on a
> possible time frame and/or features list.
>
> I'll understand if you don't want to commit yourselves though <g>

There are a whole swathe of changes in Dolphin 5.0 to the development
environment. In no particular order, we have:

1) Integration of the Refactoring Browser with the standard Dolphin
browsers. We think we've got a rather good level of integration that is not
necessarily seen in other ST products. We've made plenty of use of dynamic
menus so that the refactoring operations are easy to configure.

2) Modifications to the Package Browser to work with a hierarchy of
packages. Now there is a tree view showing the package directory structure.
Selecting a directory shows all packages below this in an adjacent pane. One
can select multiple packages to display their contents in the other standard
panes. Hence it is very easy to filter the view to see all Object Arts
packages, all Camp Smalltalk packages or just Samples or whatever.
See www.object-arts.com/Beta5/PB.gif.

3) Introduction of a System Browser. Instead of the first filter pane being
based on (rather nebulous) class categories as in the traditional ST80
System Browser, we allow a selection based on packages. Indeed, we employ
the same package hierarchy selection as used in the new Package Browser.
This means it is easier now to choose to work with the classes in a
particular package or group of packages or even by a specific author
(assuming the author sticks to our proposed directory scheme for his/her
packages).
See www.object-arts.com/Beta5/SB.gif.

4) Both the System Browser and the Class Hierarchy Browser allow a display
of inherited methods as an option. There is also an option to omit methods
inherited from Object simply because there are so many of them (and they
tend to pollute the method list somewhat). In the method list, inherited
methods are displayed as "faded" to distinguish them from methods local to
the selected class. When an inherited method is selected, its source is
shown in the source pane but this is disabled to prevent accidental editing.

5) Automatic method reformating. Since the Refactoring engine has a built-in
method rewriter that complies with the formatting "standards" proposed in
Beck's Best Practise Patterns book we've allowed the browsers to make us of
it when compiling new methods. Unfortunately, the formatting style is not
configurable (perhaps we can persuade John Brant to add this feature in
future) but it's use is optional if you don't like it.

6) We're hoping to integrate a diving inspector into the IDE although this
hasn't yet been done so may not make it into the 5.0 release.

Non IDE improvements are:

A) Further division of the base image into separate packages. This divides
the image up for use within the System Browser and also allows improvements
when stripping the image for deployment. For example it is now possible to
deploy a console application with no GUI classes left floating around in it.

B) One can now create and deploy in-process COM server components. The long
awaited ability to create DLLs with Dolphin has now been realized.

C) The plugin can support new customer-specific MIME types. This means that
you can create a custom plugin with your own MIME type so that there is no
chance of a clash with the standard Dolphin plugin. Unfortunately, due to
Microsoft removing plugin support from Internet Explorer, fo the time being,
we have to recommend that plugin users switch to a Netscape compatible
browser.

D) We've done some work on refactoring the MVP Presenter hierarchy (making
extensive use of the RB of course). Most significant is the removal of the
CompositePresenter sub-hierarchy. We now employ the "Composite" pattern more
correctly and all presenters can be composites. This should make it much
easier to judge where to place new presenter classes in the hierarchy since
it is no longer necessary to pre-determine whether they need to be
composites or not.

Take a look at: www.object-arts.com/Beta5/PH.gif. In particular, note that
CompositePresenter still remains as a deprecated stub class for backward
comaptibility. Also notice the new SelectableItemsPresenter sub-hierarchy.
This now encompasses both TreePresenters and ListPresenters and allows them
to share some of the same protocol. With the changes to remove the
distinction between composites and non-composites it is now much easier to
create selection presenters that are composed of several sub-component.

For example, the combination of directory pane, packages pane and classes
pane that make up the top left of the SystemBrowser is now a single
component; a PackagedClassSelector. This was a direct plug-in replacement
for the old ClassHierarchyPresenter in the CHB meaning that it was possible
to add the first flush of the SystemBrowser to the image in about half an
hour. Try that with a Java or C++ IDE! Incidentally, ClassHierarchyPresenter
has also been stubbed and deprecated and replaced by ClassHierarchySelector.

E) We've also made plenty of minor bug fixes and enhancements too numerous
to mention here.

I may have missed some stuff but I think this gives the jist of the new
features in Dolphin 5. I'm afraid we are unwilling to specify a release date
at this stage.

Best Regards

Andy Bower
Dolphin Support
http://www.object-arts.com/Support.htm

Not all Addictions are Bad for you
http://www.object-arts.com/Addiction.htm

Andy,

> There are a whole swathe of changes in Dolphin 5.0 to the development
> environment. In no particular order, we have:
[..]

Thanks Andy - you and Blair have been busy haven't you! - there's a lot of
good looking changes and additions in there.

I'm not 100% convinced about the browser changes  but I expect I'll get used
to them - I just used to find that the VW and VA browsers, with their
multiple lists, tended to make it a bit difficult to find things at times.

The Presenter hierarchy changes sound useful as well.

> I may have missed some stuff but I think this gives the jist of the new
> features in Dolphin 5. I'm afraid we are unwilling to specify a release
> date at this stage.

Fair enough. From the recent comments I thought it might be imminent but
it's not a problem. I expect I'll be able to contain myself - just <g>

Regards
    Ian

Andy,

I would like to add a couple of CHB wish list items.

1) Add to the right-click pop-menu of the methods pane, a choice to
copy the full method definition (with parameters) into the paste
buffer. This would help a lot with typing method names (or having to
hilite, and copy). Given the fact that "intellisense" is not possible,
this can be an alternative.

A CTRL-V would just paste the method name. Even better would be an
alternate key that not only paste's the message but positions the
cursor and hilites the first parameter.

2) Add to the pop-up menu of the Workspace a choice to insert/remove
break points (self halt.). Just add the self halt anywhere the cursor
is positioned. Remove the self halt as long as cursor is over the halt
message.

3) Add to the Method menu a Find similar to the one in the Class. This
would do exactly what the Workspace pop-up menu does under
Browse/Definitions. Its much more convenient and consistent.

4) I wish I could move between methods without the constant message
asking if I should retain.  Sometimes I need to see some other method
before continuing. I know you can open up another browser but you
still have to keep switching.

Instead can Dolphin mark the unsaved methods as incomplete thus making
them unavailable for use? Maybe even show them in some other color in
the CHB methods pane.

Well thats my wish list. Thanks for listening.

Regards

Costas

Ian,

> Thanks Andy - you and Blair have been busy haven't you! - there's a lot of
> good looking changes and additions in there.
>
> I'm not 100% convinced about the browser changes  but I expect I'll get
used
> to them - I just used to find that the VW and VA browsers, with their
> multiple lists, tended to make it a bit difficult to find things at times.

Yes, I agree. The System Browser is probably pretty good for browsing and
getting an overview of how things work. Much of the grunt of developing
probably would still be done in the Hierarchy Browser. Remember the CHB is
still available in the same form as in previous versions except with the
addition of the refactoring menu.

Best Regards,

Andy Bower
Dolphin Support
http://www.object-arts.com
---
Are you trying too hard?
http://www.object-arts.com/Relax.htm
---

Integrated Refactoring Browser- Awesome!
In-proc components- Awesome!

Good work- I know I'm not the only person who's looking forward to this
update!

Jerry

"Andy Bower" <[hidden email]> wrote in message
news:9ohoq8$dc0m7$[hidden email]...
> Ian,
>
> > There have been a few comments recently about the next release of
Dolphin
> > (5.0 IIRC) so I was wondering if Andy or Blair might like to comment on
a
> > possible time frame and/or features list.
> >
> > I'll understand if you don't want to commit yourselves though <g>
>
> There are a whole swathe of changes in Dolphin 5.0 to the development
> environment. In no particular order, we have:
>
> 1) Integration of the Refactoring Browser with the standard Dolphin
> browsers. We think we've got a rather good level of integration that is
not
> necessarily seen in other ST products. We've made plenty of use of dynamic
> menus so that the refactoring operations are easy to configure.
>
> 2) Modifications to the Package Browser to work with a hierarchy of
> packages. Now there is a tree view showing the package directory
structure.
> Selecting a directory shows all packages below this in an adjacent pane.
One
> can select multiple packages to display their contents in the other
standard
> panes. Hence it is very easy to filter the view to see all Object Arts
> packages, all Camp Smalltalk packages or just Samples or whatever.
> See www.object-arts.com/Beta5/PB.gif.
>
> 3) Introduction of a System Browser. Instead of the first filter pane
being editing.
>
> 5) Automatic method reformating. Since the Refactoring engine has a
built-in
> method rewriter that complies with the formatting "standards" proposed in
> Beck's Best Practise Patterns book we've allowed the browsers to make us
of improvements
> when stripping the image for deployment. For example it is now possible to
> deploy a console application with no GUI classes left floating around in
it.
>
> B) One can now create and deploy in-process COM server components. The
long
> awaited ability to create DLLs with Dolphin has now been realized.
>
> C) The plugin can support new customer-specific MIME types. This means
that
> you can create a custom plugin with your own MIME type so that there is no
> chance of a clash with the standard Dolphin plugin. Unfortunately, due to
> Microsoft removing plugin support from Internet Explorer, fo the time
being,
> we have to recommend that plugin users switch to a Netscape compatible
> browser.
>
> D) We've done some work on refactoring the MVP Presenter hierarchy (making
> extensive use of the RB of course). Most significant is the removal of the
> CompositePresenter sub-hierarchy. We now employ the "Composite" pattern
more
> correctly and all presenters can be composites. This should make it much
> easier to judge where to place new presenter classes in the hierarchy
since
> it is no longer necessary to pre-determine whether they need to be
> composites or not.
>
> Take a look at: www.object-arts.com/Beta5/PH.gif. In particular, note that
> CompositePresenter still remains as a deprecated stub class for backward
> comaptibility. Also notice the new SelectableItemsPresenter sub-hierarchy.
> This now encompasses both TreePresenters and ListPresenters and allows
them
> to share some of the same protocol. With the changes to remove the
> distinction between composites and non-composites it is now much easier to
> create selection presenters that are composed of several sub-component.
>
> For example, the combination of directory pane, packages pane and classes
> pane that make up the top left of the SystemBrowser is now a single
> component; a PackagedClassSelector. This was a direct plug-in replacement
> for the old ClassHierarchyPresenter in the CHB meaning that it was
possible
> to add the first flush of the SystemBrowser to the image in about half an
> hour. Try that with a Java or C++ IDE! Incidentally,
ClassHierarchyPresenter
> has also been stubbed and deprecated and replaced by
ClassHierarchySelector.
>
> E) We've also made plenty of minor bug fixes and enhancements too numerous
> to mention here.
>
> I may have missed some stuff but I think this gives the jist of the new
> features in Dolphin 5. I'm afraid we are unwilling to specify a release
date

This all sounds great.  Looks like Dolphin is *really* taking off as
a significant Smalltalk.    

I would like to repeat my regular suggestion for some form of Linux
This all sounds great.  Looks like Dolphin is really taking off as
a significant Smalltalk.

I would like to repeat my regular suggestion for some form of Linux
compatibility.  Thanks mainly to Microsoft's licence changes for
Windows XP and Office XP, Linux is *finally* starting to appear as
a desktop system in many organisations, both in my personal experience
and from stories in the UK computer press.  We are about to start a
migration to Star Office to avoid such licencing fees, and to
allow better Oracle integration than we currently get from MS Access.

Most of our development is in Java, but the user interface side of things
is still slow, even with Java 1.3, so we are using Dolphin for client-side
work.  I'm willing to put some work into Dolphin on Linux using the WINE
system - I have had success with some small apps with Dolphin 3.  I'm
wondering if there is a possibility of using WINE in the same way as
Borland/Inprise have:  Delphi now works on Linux via a customized WINE
library, and is shipped as Kylix.  Maybe the same thing could be done
with Dolphin?  

My humble view is that when the significant Windows -> Linux shift comes on the
desktop, its going to be fast, and the time to start preparing for
it is now.

regards

Steve Zara

"Andy Bower" <[hidden email]> wrote in message news:<9ohoq8$dc0m7$[hidden email]>...

> There are a whole swathe of changes in Dolphin 5.0 to the development

Is there a significant improvement in speed?  Not that speed is a
major problem, but just that I'm curious about it because there was
some speed improvement in version 4 vs 3.

Andy and Blair ,

GOOOOD work!.

For one accustomed  (and still sometime missing) the OLD VSE, this seems a
back to home (SystemBrowser and Package hirarchy).

Nothing about syntax colouring the methods? (or there is a goodies somewhere
I don'tknow)?

Ciao

--
Giorgio Ferraris
Eleven srl
Moncalieri (TO) Italy

"Andy Bower" <[hidden email]> ha scritto nel messaggio
news:9ohoq8$dc0m7$[hidden email]...
> Ian,
>
> > There have been a few comments recently about the next release of
Dolphin
> > (5.0 IIRC) so I was wondering if Andy or Blair might like to comment on
a
> > possible time frame and/or features list.
> >

Giorgio

You wrote in message news:jRIr7.240$[hidden email]...
> ...
> Nothing about syntax colouring the methods? (or there is a goodies
somewhere
> I don'tknow)?

Dolphin has always had syntax colouring, so I'm not quite sure what your are
missing there?

Regards

Blair

in dolphin5, i'd like to see the option to install -all- the
dolphin files in one directory.  one of the nice things
about visual age is just that - all the files are in the
\vast directory.

whenever i move stuff from my laptop to my dekstop, i
invariably forget some of the files that are not in the
\dolphin4 directory.

just my tupence.


Donald

Blair,

Yes, I know, But I was tired from a two days catch against the
W32.Nimda.A@mm virus that killed half of our computers so my englis was
unfinished and worst that usual:-).
Wat I mean is (and you did the first step on, signaling changed packages) a
colouring scheme for modified methods after the last package save (like VA+
VAAssist or VSE) That way you can easily check your modification.

THanks for your work, and good luck for the IE6 problem.

Ciao


--
Giorgio Ferraris
Eleven srl
Moncalieri (TO) Italy



"Blair McGlashan" <[hidden email]> ha scritto nel messaggio
news:9onrpa$ed0ln$[hidden email]...
> Giorgio
>
> You wrote in message news:jRIr7.240$[hidden email]...
> > ...
> > Nothing about syntax colouring the methods? (or there is a goodies
> somewhere
> > I don'tknow)?
>
> Dolphin has always had syntax colouring, so I'm not quite sure what your
are
> missing there?
>
> Regards
>
> Blair
>
>

Donald

You wrote in message news:9ontvl$mel$[hidden email]...
>
> in dolphin5, i'd like to see the option to install -all- the
> dolphin files in one directory.  one of the nice things
> about visual age is just that - all the files are in the
> \vast directory.

Each to his own of course, but that doesn't sound desirable to me. Why would
one want the data files mixed up with the program files? I remember early
versions of MS Office that tended to do this by default, and it made it very
difficult to separate out the stuff one wanted to keep when
upgrading/reinstalling Windows (a regular occurrence until Win2K), etc.
Separation of data files from program files (and in fact the storage of
"data" files in the 'My Documents' tree) is consistent with Microsoft's
"Application Specification for Microsoft Windows 2000"
(http://msdn.microsoft.com/winlogo), and in fact all of the bits you
actually need to copy are in a single directory tree (see below).

> whenever i move stuff from my laptop to my dekstop, i
> invariably forget some of the files that are not in the
> \dolphin4 directory.

Dolphin should be installed using its setup MSI on both machines, then all
you need to move is the 3 image files: <name>.img, <name>.sml, and
<name>.chg. In fact if you don't compress sources you need only move .img
and .chg. The easiest approach, though, is to simply copy the image
directory ('My Documents/Dolphin Smalltalk 4.0') back and forth. This should
contain any packages you've saved out, since these are (by default) stored
relative to the image.

Actually we've often thought about using a "structured storage" file for the
the iimage files, so that all 3 would actually be stored as streams inside
one file. Packages filed out from the image could be stored in the same
structured file too. This would mean one could transfer the image back and
forth as a single file. What has stopped us so far is that one would then
need special tools to be able to read the source files (especially important
for the change log I think), which is inconvenient. I'm sure it could be
made to work, but not sure the complexity is worth it, bearing in mind one
can achieve much the same effect by copying the 'Dolphin Smalltalk 4.0'
sub-directory of 'My Documents' back and forth.

Regards

Blair

Hi Blair,

> Each to his own of course, but that doesn't sound desirable to me. Why
would
> one want the data files mixed up with the program files?

I agree to a point.  I like having the VM as a registered component stored
off by itself somewhere, but, would prefer to have the executable
underfoot - it's a lot more obvious what's going to run, especially when
there's a need to go back a few versions.  How will we go back to a D4.02
image when D6.01 is newly installed on our drives?  So far, it's not obvious
to me how it will be done, and it's an important capability - I still
occaisionally run up 3.06 and have archived images that are much older than
that.


> Actually we've often thought about using a "structured storage" file for
the
> the iimage files, so that all 3 would actually be stored as streams inside
> one file. Packages filed out from the image could be stored in the same
> structured file too. This would mean one could transfer the image back and
> forth as a single file. What has stopped us so far is that one would then
> need special tools to be able to read the source files (especially
important
> for the change log I think), which is inconvenient.

Another reason not to do it is that corrupting one file would then be more
likely to corrupt the whole thing.  I'd hate to see the change log and the
saved packages(!!) get clobbered because something wrote over an object
header and didn't show up until after an image save.  Also, I have a large
number of saved packages that I don't change often and usually don't have
loaded; having them saved as part of one file would increase my already
large output of data to be archived on CD's, which have begun to look
smaller with time :(

Not that it's really related, but, I found it really strange the MS placed
storages inside a database rather than a datbase as one stream in an
otherwise structured file to create .MSI files.  If MSI files were
structured from the top, the whole business of adding and extracting files
could have been a lot easier - the extraction side might be one reason they
did what they did, but, one could always encrypt the streams.

Have a good one,

Bill

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

Hi Blair,

> Another reason not to do it is that corrupting one file would then be more
> likely to corrupt the whole thing.  I'd hate to see the change log and the
> saved packages(!!) get clobbered because something wrote over an object
> header and didn't show up until after an image save.  Also, I have a large
> number of saved packages that I don't change often and usually don't have
> loaded; having them saved as part of one file would increase my already
> large output of data to be archived on CD's, which have begun to look
> smaller with time :(

To the above I'll add that one of my first clues that a particular hard disk
was failing was that a backup utility wanted to copy a file that should not
have changed; I knew it shouldn't have changed, so I opened it and found it
to be corrupted.  It was just a stray text file, but, it could just as
easily have been a package.  With hindsight, there had been one prior
incident involving corrupted network settings (and a lot of learning about
plug and play to enable me to fix it) that was probably the first symptom.

It would have been easy to back up garbage for some time before realizing
that something was wrong.  IMHO, the saved packages should be separate from
the working files.

Have a good one,

Bill

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

Giorgio

You wrote in message news:UJVr7.5093$[hidden email]...
>...
> Yes, I know, But I was tired from a two days catch against the
> W32.Nimda.A@mm virus that killed half of our computers so my englis was
> unfinished and worst that usual:-).

Ah, bad luck. If it is any consoliation, you are far from alone (it seems
that a very large number of users connected on BT Openworld ADSL connections
like the ones that we use also have it judging by the flood of alerts coming
up in my firewall).

> Wat I mean is (and you did the first step on, signaling changed packages)
a
> colouring scheme for modified methods after the last package save (like
VA+
> VAAssist or VSE) That way you can easily check your modification.
>

Dolphin itself does not maintain the necessary "change" information to do
that (it doesn't record change details at that level of granularity).
However I imagine it would be easy to do it with a system like David
Gorisek's Source Tracking System. Changing the colours (or using italic or
bold fonts for emphasis) of the method names listed in the browsers is a
simple matter of modifying the "custom draw" block associated with the
relevant column in the view resource.

Regards

Blair

Blair,

thanks for the hint. I will probably add this in the next release so that it
will behave similar to Team/V in VSE.

Best regards,

David Gorisek
http://www.gorisek.com


"Blair McGlashan" <[hidden email]> wrote in message
news:9ov52t$fo99p$[hidden email]... connections
> like the ones that we use also have it judging by the flood of alerts
coming
> up in my firewall).
>
> > Wat I mean is (and you did the first step on, signaling changed
packages)