Dolphin 98 question

Hi,

1)
Is there a document somewhere that describes which widgets (for lack of a
better word) trigger which types of events, and when (i.e., what do they
mean)?

2)
Same question for the widget properties. Plus what issues exist as to which
combinations of properties are valid, or don't go together.

3)
If you crash your image, is ther a way of automatically or manually
(selectively) replaying the changes since the last image save?

4)
Is there a way of reloading a package from its .pac file?

5)
Is there a way of asci-ing out a package, and if so, what are the
limitations?

6)
Is there any refactoring support available?

7)
Is there any documentation on building user interfaces with resizing
behavior that resizes widgets, from the view composer, as well as by hand
(I'm not al all sure I need the user interface framework)?

Thanks in advance for any answers.

Regards,

Peter van Rooijen

Peter,

> Thanks in advance for any answers.

OK, I'll have a shot at some of them. The lack of other responses is
probably because most people who would be comfortable answering question
like these haven't used D2 "in anger" for a couple of years now.

> Is there a document somewhere that describes which widgets (for lack of a
> better word) trigger which types of events, and when (i.e., what do they
> mean)?

The class browser displays a, manually created, list of events that a class
triggers (Published events from the context menu) but there is no full list
that I know of. It is easy enough to generate a list yourself though, by
iterating through all the #publishedEventsOfInstances methods.

What they mean?. Apart from the event names, which are usually quite
explanatory, and any odd method comments I don't know of any other
documents.

> Same question for the widget properties. Plus what issues exist as to
which
> combinations of properties are valid, or don't go together.

Same answer as above.  For aspects, and to some extent this also applies to
events I suppose, you can look at Windows documentation or MSDN for hints as
in a lot of cases they correspond quite closely.

> If you crash your image, is ther a way of automatically or manually
> (selectively) replaying the changes since the last image save?

There's a ChunkBrowser goodie available from my web site that browses any
chunk format file (as in the change file) and allows you to restore one or
more methods/class definitions. It's not fully automatic though, you need to
select what you want to restore.

> Is there a way of reloading a package from its .pac file?

Not quite sure what you mean?. If you want to look inside a pac file without
installing it then you can either use a normal text editor, ignoring the
binary bits, or use the ChunkBrowser, which ignores the binary bits for you
<g>.

> Is there a way of asci-ing out a package, and if so, what are the
> limitations?

If you want to include any ViewResources then, pre Dolphin 4, no it's not
possible. You can save classes and methods individually as text files (in
all versions of Dolphin) and the views as separate binary 'vu' files

> Is there any refactoring support available?

No

> Is there any documentation on building user interfaces with resizing
> behavior that resizes widgets, from the view composer, as well as by hand
> (I'm not al all sure I need the user interface framework)?

Sorry, don't know what you mean. here.  Dolphin makes intensive use of
Windows and the framework, that I think you might mean, is the interface
between the two. I would say that no UI framework equates to no UI.

 From another post -
> - There is a problem with the dependencies. I don't know how to fix this.
> When we load the top level package, it automatically loads several
packages,
> but it has the order wrong. We changed the dependency structure at some
> point (we inserted a package at some point, and may have made other
> changes). We now get methods that didn't compile because a class they
> reference is undeclared.

That sounds very much like a problem I recently reported with Dolphin 4. It
should be fixed in 4.01 but I don't know, but rather doubt, if OA will
retrospectively fix V2 (if it is indeed the same problem!).

Ian
http://www.iandb.org.uk

Peter,

> Thanks in advance for any answers.

OK, I'll have a shot at some of them. The lack of other responses is
probably because most people who would be comfortable answering question
like these haven't used D2 "in anger" for a couple of years now.

> Is there a document somewhere that describes which widgets (for lack of a
> better word) trigger which types of events, and when (i.e., what do they
> mean)?

The class browser displays a, manually created, list of events that a class
triggers (Published events from the context menu) but there is no full list
that I know of. It is easy enough to generate a list yourself though, by
iterating through all the #publishedEventsOfInstances methods.

What they mean?. Apart from the event names, which are usually quite
explanatory, and any odd method comments I don't know of any other
documents.

> Same question for the widget properties. Plus what issues exist as to
which
> combinations of properties are valid, or don't go together.

Same answer as above.  For aspects, and to some extent this also applies to
events I suppose, you can look at Windows documentation or MSDN for hints as
in a lot of cases they correspond quite closely.

> If you crash your image, is ther a way of automatically or manually
> (selectively) replaying the changes since the last image save?

There's a ChunkBrowser goodie available from my web site that browses any
chunk format file (as in the change file) and allows you to restore one or
more methods/class definitions. It's not fully automatic though, you need to
select what you want to restore.

> Is there a way of reloading a package from its .pac file?

Not quite sure what you mean?. If you want to look inside a pac file without
installing it then you can either use a normal text editor, ignoring the
binary bits, or use the ChunkBrowser, which ignores the binary bits for you
<g>.

> Is there a way of asci-ing out a package, and if so, what are the
> limitations?

If you want to include any ViewResources then, pre Dolphin 4, no it's not
possible. You can save classes and methods individually as text files (in
all versions of Dolphin) and the views as separate binary 'vu' files

> Is there any refactoring support available?

No

> Is there any documentation on building user interfaces with resizing
> behavior that resizes widgets, from the view composer, as well as by hand
> (I'm not al all sure I need the user interface framework)?

Sorry, don't know what you mean. here.  Dolphin makes intensive use of
Windows and the framework, that I think you might mean, is the interface
between the two. I would say that no UI framework equates to no UI.

>From another post -
> - There is a problem with the dependencies. I don't know how to fix this.
> When we load the top level package, it automatically loads several
packages,
> but it has the order wrong. We changed the dependency structure at some
> point (we inserted a package at some point, and may have made other
> changes). We now get methods that didn't compile because a class they
> reference is undeclared.

That sounds very much like a problem I recently reported with Dolphin 4. It
should be fixed in 4.01 but I don't know, but rather doubt, if OA will
retrospectively fix V2 (if it is indeed the same problem!).

Ian
http://www.iandb.org.uk

[snip]
> 6)
> Is there any refactoring support available?

the refactoring browser *code* was ported to dolphin at
camp smalltalk san diego. i am currently putting a gui on
it, and it should be ready real soon now.

any of you with rb experience in other dialects who want
to help shake it down should email me.

Donald

[hidden email]

Donald,

If I recall correctly, the parse tree for Dolphin Smalltalk is not
accessible within Dolphin.  The parsing all takes place in a DLL.  I
also thought that the RB does much of its work based on a parse tree.
If this is all true, how does the Dolphin version of the RB go about
parsing the code?  Does it include its own parser?  Where did it come
from?

Keith Alcock


Donald MacQueen wrote:

"Keith Alcock" <[hidden email]> wrote in message
news:[hidden email]...
> Donald,
>
> If I recall correctly, the parse tree for Dolphin Smalltalk is not
> accessible within Dolphin.  The parsing all takes place in a DLL.  I
> also thought that the RB does much of its work based on a parse tree.
> If this is all true, how does the Dolphin version of the RB go about
> parsing the code?  Does it include its own parser?

Yes.

> Where did it come from?

It's a port of the one John Brant wrote for VA.

Donald

"Ian Bartholomew" <[hidden email]> wrote in message
news:hlwl6.5354$[hidden email]...
> Peter,
>
> > Thanks in advance for any answers.
>
> OK, I'll have a shot at some of them. The lack of other responses is
> probably because most people who would be comfortable answering question
> like these haven't used D2 "in anger" for a couple of years now.

Understandable.

> > Is there a document somewhere that describes which widgets (for lack of
a
> > better word) trigger which types of events, and when (i.e., what do they
> > mean)?
>
> The class browser displays a, manually created, list of events that a
class
> triggers (Published events from the context menu) but there is no full
list to
> events I suppose, you can look at Windows documentation or MSDN for hints
as
> in a lot of cases they correspond quite closely.

The point is that the event and property names are not so explanatory for
me, probably as I'm missing some context. MSDN may be that context. What is
the best way to inform oneself about the information contained in MSDN?

> > If you crash your image, is ther a way of automatically or manually
> > (selectively) replaying the changes since the last image save?
>
> There's a ChunkBrowser goodie available from my web site that browses any
> chunk format file (as in the change file) and allows you to restore one or
> more methods/class definitions. It's not fully automatic though, you need
to
> select what you want to restore.

Thanks. May look at that in the future. Right now, I'm focusing on portable
coding, which will reduce the need to spend time in other environments than
the on eI find most powerful and know best (VA Smaltalk).

> > Is there a way of reloading a package from its .pac file?
>
> Not quite sure what you mean?. If you want to look inside a pac file
without
> installing it then you can either use a normal text editor, ignoring the
> binary bits, or use the ChunkBrowser, which ignores the binary bits for
you
> <g>.

I mean, the package is already loaded, and won't reload from file (saying;
package already loaded). That's one of the simplest ways to back out
changes, and it's not allowed from the package browser. So I'm looking for
another way. Note that unloading first doesn't work if there are dependent
packages.

O, and has anyone written an extension to the package saving that backs up
all saved versions by numbering/timestamping them? It's so simple I can't
believe it's not there.

> > Is there a way of asci-ing out a package, and if so, what are the
> > limitations?
>
> If you want to include any ViewResources then, pre Dolphin 4, no it's not
> possible. You can save classes and methods individually as text files (in
> all versions of Dolphin) and the views as separate binary 'vu' files

Then how can I ever examine the code I'm generating in the view composer?
Are you saying I can't? Does that mean I also can't dynamically generate
UI's?

> > Is there any refactoring support available?
>
> No

Don MacQueen's stuff will be something to look forward to.

> > Is there any documentation on building user interfaces with resizing
> > behavior that resizes widgets, from the view composer, as well as by
hand
> > (I'm not al all sure I need the user interface framework)?
>
> Sorry, don't know what you mean. here.  Dolphin makes intensive use of
> Windows and the framework, that I think you might mean, is the interface
> between the two. I would say that no UI framework equates to no UI.

I mean not using presenters. Most of the included development tools have
their GUI layout in hand built methods which I can examine. In the case
where one is using a portable GUI-logic framework that is adapted to
layout-only visual GUi objects, it doesn't pay to use the Presenter
framework.

With the resizing behavior I mean that you can specify what areas widgets
will occupy onder resizing of their parent. There don't seem to be any
options for that in the View Composer. Does everybody just build GUIs that
can't resize, or do people build their GUIs by hand? (llike the base
development browsers). I hope of course that it's neither, and I just
haven't found the relevant options.

> From another post -
> > - There is a problem with the dependencies. I don't know how to fix
this.
> > When we load the top level package, it automatically loads several
> packages,
> > but it has the order wrong. We changed the dependency structure at some
> > point (we inserted a package at some point, and may have made other
> > changes). We now get methods that didn't compile because a class they
> > reference is undeclared.
>
> That sounds very much like a problem I recently reported with Dolphin 4.
It
> should be fixed in 4.01 but I don't know, but rather doubt, if OA will
> retrospectively fix V2 (if it is indeed the same problem!).

No offense, but how come these things are still there in version 4? I
thought there was a rather large user base of Dolphin Smalltalk, and growing
all the time. I now have another problem of this type, where one package
will fail to compile all its methods when automatically loaded, but works
fine when I load everything by hand in the correct order. This is in a
really simple project with only half a dozen packages. Surely anyone who
builds anything of any significance must be bitten by this type of bug?

Thanks

"Donald MacQueen" <[hidden email]> wrote in message
news:978k63$8tm$[hidden email]...
Don, could you send me what you have? I have some RB experience, and access
to some wonderful examples of integration with the host browsers (which have
a framework for doing this easily) in VA Smalltalk. Based on available time,
I will happily see what I can do.

Regards,

Peter van Rooijen

Peter.

> > > Is there a way of reloading a package from its .pac file?

No, you have to unload it and re-install it.

> O, and has anyone written an extension to the package saving that backs up
> all saved versions by numbering/timestamping them? It's so simple I can't
> believe it's not there.

Not as far as I know. However, in Dolphin 4 there is a package file format
(PAX) which is suitable for checking in to a file based source code control
system such as MS SourceSafe or CVS. We use this all the time in-house and
it gives versioning down to the class level and of course the ability to
mark release "slices". If you want a more advanced solution then the answer
is to use STS (Source Tracking System) which gives nearly all of the
advantages of ENVY (for $69.95!!!!). STS is available from:

http://www.geocities.com/SiliconValley/Software/8887/sts.html

> > > Is there a way of asci-ing out a package, and if so, what are the
> > > limitations?

Dolphin 4 packages (PAC and PAX) are in an ASCII format.

> Then how can I ever examine the code I'm generating in the view composer?
> Are you saying I can't? Does that mean I also can't dynamically generate
> UI's?

The View Composer does not generate Smalltalk code. It creates instances of
view objects. These are saved by streaming them to a byte array through a
binary filing mechanism called STB (for Smalltalk Binary). This is Dolphin's
equivalent of VW's BOSS.

> > > Is there any documentation on building user interfaces with resizing
> > > behavior that resizes widgets, from the view composer, as well as by
> > > hand

The Dolphin 4 class comments explain the layout manager classes in
reasonable detail.

[snip]

> With the resizing behavior I mean that you can specify what areas widgets
> will occupy onder resizing of their parent. There don't seem to be any
> options for that in the View Composer. Does everybody just build GUIs that
> can't resize, or do people build their GUIs by hand? (llike the base
> development browsers). I hope of course that it's neither, and I just
> haven't found the relevant options.

What you want is a FramingLayout manager. Unfortunately, this is was only
fully supported from Dolphin 3 onwards.

> > From another post -
> > > - There is a problem with the dependencies. I don't know how to fix
> > > this.
[snip]

> No offense, but how come these things are still there in version 4? I
> thought there was a rather large user base of Dolphin Smalltalk, and
growing
> all the time. I now have another problem of this type, where one package
> will fail to compile all its methods when automatically loaded, but works
> fine when I load everything by hand in the correct order. This is in a
> really simple project with only half a dozen packages. Surely anyone who
> builds anything of any significance must be bitten by this type of bug?

In fact this problem occurs rarely. Here at OA we have only witnessed it
occurring once in the last few years. Some people have also been bitten by
the problem but it is generally rare. I guess you have just been unlucky to
come across it so quickly. In any case it has been fixed for Dolphin 4.01.

Now, I imagine that you are becoming steadily more and more annoyed when the
answers to your questions come back as, it's only fixed/available in Dolphin
4 rather than 2.1. The fact that you are putting so much work into the free
version of Dolphin prompts me to bring forward an announcement that we
weren't planning to make until the release of 4.01.

It is our intention, following the 4.01 release, to formally discontinue
support for the free version of Dolphin Smalltalk (in this case 2.1). The
download will remain available but a link to it will not appear prominently
on the Object Arts site. We have no plans to remove the download completely.
There are several reasons for this decision, but perhaps the most
significant is that we no longer feel that Dolphin 2.1 is a good
advertisment for the commercial product (which is, after all, what we are
trying to sell here). Indeed, your questions in this thread demonstrate that
this is really the case.

The free version has effectively been in "maintenance mode" (actually
slightly below this) for two years now so the change should actually make
little real difference. The perception of there being a free version of
Dolphin will probably disappear fairly soon, however.

On the flip side, to replace the idea of a completely free offering, we are
intending to release a 30 day trial version of the Dolphin Value Edition
(which is our entry level version 4 product). We believe that this, coupled
with the low price ($69.95) of DVE will be sufficient to attract those
people who have a genuine interesting in learning, or playing with,
Smalltalk.

Best regards,

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

---
Visit the Dolphin Smalltalk Wiki Web
http://www.object-arts.com/wiki/html/Dolphin/FrontPage.htm
---

Peter,

> The point is that the event and property names are not so explanatory for
> me, probably as I'm missing some context. MSDN may be that context. What
is
> the best way to inform oneself about the information contained in MSDN?

I can see what you are saying, but I don't know the answer as it's a
chicken/egg situation. My "technique" was to have a rough idea of what the
control I wanted to use did and how it did it - usually from books, articles
or just a vague recollection from the past. I would then have a look on MSDN
to get a more detailed background, leading onto an understanding of the
what? and why? for the Dolphin aspects and events.

If you don't have some initial knowledge of the way Windows, and the various
widgets, work then I can see that it will be difficult. However, looking
through the names of the events and aspects in Dolphin I can't see many that
wouldn't enable me to get a pretty good idea of what it did.  I'm not in the
best position to judge though, having used nothing but Dolphin (plus a
little bit of Delphi and 8008 assembler) for the last 5 years.

> I mean, the package is already loaded, and won't reload from file (saying;
> package already loaded). That's one of the simplest ways to back out
> changes, and it's not allowed from the package browser. So I'm looking for
> another way. Note that unloading first doesn't work if there are dependent
> packages.

Right - with you now. No. You can't install a package if classes defined in
the package are already in the image, you would have to use separate cls
files for this. Later versions of Dolphin do make it easier to unload a
package with all it's dependent packages.

There is a source control package available for Dolphin but I don't know if
it goes back as far as D2. David?

> O, and has anyone written an extension to the package saving that backs up
> all saved versions by numbering/timestamping them? It's so simple I can't
> believe it's not there.

I posted one in the newsgroup for Dolphin 4 a few weeks ago. Yes, it is easy
and yes, it is something that probably should be available in the base
image.

> Then how can I ever examine the code I'm generating in the view composer?
> Are you saying I can't? Does that mean I also can't dynamically generate
> UI's?

The ViewComposer doesn't generate any code - it creates binary resources
that get reloaded if and when a view is needed.

You can compose methods that will dynamically create a view for you at run
time, and there are occasions when it is useful to do this, but normally
(90% of the time?) it is easier to use the ViewComposer.

> I mean not using presenters. Most of the included development tools have
> their GUI layout in hand built methods which I can examine.

This confused me a bit until I remembered the #emergencyView methods in V2.
Is this what you are referring to?. If so then the disappeared in V3 as they
were (IIRC) just what the selector indicated - for use in case the normal
ViewResource mechanism broke. As far as I know all the development tools are
built with the ViewComposer.

>                   In the case
> where one is using a portable GUI-logic framework that is adapted to
> layout-only visual GUi objects, it doesn't pay to use the Presenter
> framework.

So you're wanting the Dolphin UI framework to work in a way that is
compatible with the way that another UI framework (VA?) works, by separating
the Presenter/View link?. Might be possible but Presenters will, I would
have thought, have to come into it somewhere in the Dolphin end.

> With the resizing behavior I mean that you can specify what areas widgets
> will occupy onder resizing of their parent. There don't seem to be any
> options for that in the View Composer.

Have a look at the layoutManager aspect in the ViewComposer. This allows you
to set and configure the resizing behaviour for it's subviews.

> No offense, but how come these things are still there in version 4? I
> thought there was a rather large user base of Dolphin Smalltalk, and growi
ng
> all the time. I now have another problem of this type, where one package
> will fail to compile all its methods when automatically loaded, but works
> fine when I load everything by hand in the correct order. This is in a
> really simple project with only half a dozen packages. Surely anyone who
> builds anything of any significance must be bitten by this type of bug?

I can only answer for myself but the problem never hit me before the other
month, probably because I don't tend to use packages in a way that would
have exposed the problem. I tend to keep all associated classes, loose
method and resources in a single package and use the package mechanism at a
higher "black box" level.  That's just what works for me and what I want to
do though, probably wouldn't work for everyone.

Ian

"Andy Bower" <[hidden email]> wrote in message
news:97gpod$p4t3p$[hidden email]...
> Peter.
>
> > > > Is there a way of reloading a package from its .pac file?
>
> No, you have to unload it and re-install it.

Is that requirement fixed at some deep level, or is it more that you don't
have an option for it? I mean, is it possible to do programmatically?

> > > > Is there a way of asci-ing out a package, and if so, what are the
> > > > limitations?
>
> Dolphin 4 packages (PAC and PAX) are in an ASCII format.

Good decision!

> > Then how can I ever examine the code I'm generating in the view
composer?
> > Are you saying I can't? Does that mean I also can't dynamically generate
> > UI's?
>
> The View Composer does not generate Smalltalk code. It creates instances
of
> view objects. These are saved by streaming them to a byte array through a
> binary filing mechanism called STB (for Smalltalk Binary). This is
Dolphin's
> equivalent of VW's BOSS.

I understand. There is Smalltalk code that achieves the same effect, yes?

> > > > Is there any documentation on building user interfaces with resizing
> > > > behavior that resizes widgets, from the view composer, as well as by
> > > > hand
>
> The Dolphin 4 class comments explain the layout manager classes in
> reasonable detail.

Did you use those mechanisms to implement the development toolset in 4?

> [snip]
>
> > With the resizing behavior I mean that you can specify what areas
widgets
> > will occupy onder resizing of their parent. There don't seem to be any
> > options for that in the View Composer. Does everybody just build GUIs
that
> > can't resize, or do people build their GUIs by hand? (llike the base
> > development browsers). I hope of course that it's neither, and I just
> > haven't found the relevant options.
>
> What you want is a FramingLayout manager. Unfortunately, this is was only
> fully supported from Dolphin 3 onwards.

So, how is the resizing behavior done in the development tools? Do they
actually get generated from Smalltalk methods? And how did people make
resizing windows in the days that D2 was all there was?

> Now, I imagine that you are becoming steadily more and more annoyed when
the
> answers to your questions come back as, it's only fixed/available in
Dolphin
> 4 rather than 2.1.

Not at all. The reason I'm using D2.1 is that I want people to be able to
use what I'm creating. I see the free Dophin as a great way to start
Smalltalking. Easy to download, easy to install, quick to start up,
packages, GUI builder, free. Anything that I design to be portable to all
dialects (which is what I'm doing), I should easily be able to build on 2.1
as well (here its basicness is a definite plus). I also imagine that anyone
wanting any D2.1 stuff I create in a newer version, will be easily able to
port it, much more so than the other way around. Does that sound like
reasonable thinking?

> The fact that you are putting so much work into the free
> version of Dolphin prompts me to bring forward an announcement that we
> weren't planning to make until the release of 4.01.

I'm not sure how it is that you relate one to the other. Is it that you'd
feel uneasy about 'letting me put in all this work', when you know you're
going to pull the plug, and fear my wrath? Don't worry, I think what you
have done with the free versions is great for the entire community (as well
as for your company), and I'd suggest you release a 3.1 for free to replace
the 2.1. You have benefitted greatly from your free version policy as a
company, I am quite sure.

> There are several reasons for this decision, but perhaps the most
> significant is that we no longer feel that Dolphin 2.1 is a good
> advertisment for the commercial product (which is, after all, what we are
> trying to sell here). Indeed, your questions in this thread demonstrate
that
> this is really the case.

I have to agree wholeheartedly. I've worked with the D4 Beta, with STS
(thanks David), and it's a much more powerful system. D2.1 is not
representative of what Dolphin is today.

> On the flip side, to replace the idea of a completely free offering, we
are
> intending to release a 30 day trial version of the Dolphin Value Edition
> (which is our entry level version 4 product). We believe that this,
coupled
> with the low price ($69.95) of DVE will be sufficient to attract those
> people who have a genuine interesting in learning, or playing with,
> Smalltalk.

I respectfully disagree. With your pricing levels, anyone who has some money
to make from using Dolphin, can easily buy the fullest possible version. 99%
of the rest will invest their learning time on a free more basic tool that
they can use forever, but not on a limited-time eval or spend any money (10
USD or 70 USD doesn't really matter there). In any case that is my opinion.

Best regards,

Peter van Rooijen

Peter,

> > > > > Is there a way of reloading a package from its .pac file?
> >
> > No, you have to unload it and re-install it.
>
> Is that requirement fixed at some deep level, or is it more that you don't
> have an option for it? I mean, is it possible to do programmatically?

It's certainly possible but I'm not sure how easy it would be. You'd need
some way to difference the contents of the two packages so that the one on
disk could be merged with the one in the image (sort of like a change set, I
suppose). Anyway, IIRC, the reason why we didn't do it was because we
couldn't work out a simple algorithm.

> > The View Composer does not generate Smalltalk code. It creates instances
> of
> > view objects. These are saved by streaming them to a byte array through
a
> > binary filing mechanism called STB (for Smalltalk Binary). This is
> Dolphin's
> > equivalent of VW's BOSS.
>
> I understand. There is Smalltalk code that achieves the same effect, yes?

Yes. As Ian suggests, take a look at the various #emergencyView: methods in
Dolphin 2.1. These were used to programmatically build views using Smalltalk
code. They don't appear in Dolphin 3 or 4, however.

> > The Dolphin 4 class comments explain the layout manager classes in
> > reasonable detail.
>
> Did you use those mechanisms to implement the development toolset in 4?

Yes.
only
> > fully supported from Dolphin 3 onwards.
>
> So, how is the resizing behavior done in the development tools? Do they
> actually get generated from Smalltalk methods? And how did people make
> resizing windows in the days that D2 was all there was?

Sorry, perhaps I was a bit too terse with my reply. The FramingLayout is the
most general purpose of the Dolphin layout managers. The effect is a bit
like FramingConstraints (if that is what they were called) in WindowBuilder.
They do what GridBagLayout does in Java only without all of the
unpleasantness. I don't think FramingLayouts were fully functional in 2.1.
However, all of the other layout managers (sublcasses of LayoutManager) *do*
work and it is these that the development tools use to get the auto-resizing
effect. They are very similar to the Java layout managers of the same name.
The difficulty comes (in 2.1) in setting them up. There is no
straightforward presentation in the View Composer of a user interface onto
the layout manager properties. This was added in Dolphin 3, IIRC.

For any container view (or shell view) you have to choose a
#layoutManagerClass in the View Composer. This creates a default instance of
that manager and you can then go to the #layoutManager aspect ("property")
to fill in the parameters if required. When you add a subview to the
container, its #arrangement aspect parameterizes the layout manager and
tells it how the particular subview should be arranged. The arrangements are
different depending on what type of layout manager is installed.

For programmatic building of a view with a layout try this:

shell := ShellView new create.
shell layoutManager: (ProportionalLayout new vertical: true).

"Top pane fills 1/3 shell"
top := shell addSubView: ListView new.
top arrangement: 1 / 3. "Relative size of this view"
top backcolor: Color yellow.

"Splitter between top and bottom panes"
splitter := shell addSubView: Splitter new.
splitter arrangement: 0. "Not automatically sized"

"Bottom pane fills 2/3 shell by default"
bottom := shell addSubView: ContainerView new.
bottom arrangement: 2 / 3. "Relative size of this view"
bottom layoutManager: GridLayout new.

"Add some contents to the bottom pane"
button1 := bottom addSubView: PushButton new.
button1 text: 'Button1'.
button2 := bottom addSubView: PushButton new.
button2 text: 'Button2'.
button3 := bottom addSubView: CheckBox new.
button3 text: 'Check3'.

"Separate the views in the bottom pane"
bottom layoutManager horizontalGap: 15.

"Provide a gap around all views in bottom pane"
bottom insets: (20@20 corner: 20@20).

"Display the finished shell"
shell show.

This doesn't demonstrate the BorderLayout (a very useful layout manager, use
#north, #south, #east, #west and #center as arrangements) or the CardLayout
(which is automatically installed by a CardContainer view) but it should be
enough to get you started.
2.1
> as well (here its basicness is a definite plus). I also imagine that
anyone
> wanting any D2.1 stuff I create in a newer version, will be easily able to
> port it, much more so than the other way around. Does that sound like
> reasonable thinking?

I suppose so. It depends what you are creating. I take it that you are
building a more advanced development tool. If it was an end-user application
then I'd recommend going straight for D4 and deploying it as an EXE.

> > The fact that you are putting so much work into the free
> > version of Dolphin prompts me to bring forward an announcement that we
> > weren't planning to make until the release of 4.01.
>
> I'm not sure how it is that you relate one to the other. Is it that you'd
> feel uneasy about 'letting me put in all this work', when you know you're
> going to pull the plug, and fear my wrath? Don't worry, I think what you
> have done with the free versions is great for the entire community (as
well
> as for your company), and I'd suggest you release a 3.1 for free to
replace
> the 2.1. You have benefitted greatly from your free version policy as a
> company, I am quite sure.

Ted Bracht is working on a Dolphin book for release around the middle of
this year (I believe) that will include a fully woring copy of Dolphin 3.0.
Apart from this we don't currently have plans to replace 2.1 with 3.0.
money
> to make from using Dolphin, can easily buy the fullest possible version.
99%
> of the rest will invest their learning time on a free more basic tool that
> they can use forever, but not on a limited-time eval or spend any money
(10
> USD or 70 USD doesn't really matter there). In any case that is my
opinion.

Well it's a tricky decision. Our aim originally with having a free Dolphin
was two fold. The first was to spread Smalltalk to a wider audience (we were
the first free "complete" Smalltalk if I remember correctly- not counting
GNU and Little ST) and the second was, of course, to provide a platform that
would guide people into the commercial version. Since that time a number of
free STs have appeared; STExpress, Squeak and, of course VWNC. These have
stolen most of the educational "market" share (that we hoped to foster) away
from the free Dolphin because, with the exception of STExpress, they are
multi-platform and the educational sector seems to have a greater
disaffinity with Windows than the public in general.

As you say, there are a great many people who will want a "free tool that
they can use forever without spending any money". These people are of little
interest to us, however. We really want to reintroduce the notion that
quality software should not (or really cannot) be free and it is my
perception that with the demise of the .com frenzy that perpetuated for the
last half decade or so, this is no longer so "politically incorrect" as it
was then.

By not having a free version, there will be a number of people who will
decide to pay for an entry level Smalltalk. Those that do not will go to
Cincom or Squeak and we will have lost little.

Best Regards,

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

---
Visit the Dolphin Smalltalk WikiWeb
http://www.object-arts.com/wiki/html/Dolphin/FrontPage.htm
---

Andy,
>
> > > > > > Is there a way of reloading a package from its .pac file?
> > >
> > > No, you have to unload it and re-install it.
> >
> > Is that requirement fixed at some deep level, or is it more that you
don't
> > have an option for it? I mean, is it possible to do programmatically?
>
> It's certainly possible but I'm not sure how easy it would be. You'd need
> some way to difference the contents of the two packages so that the one on
> disk could be merged with the one in the image (sort of like a change set,
I
> suppose). Anyway, IIRC, the reason why we didn't do it was because we
> couldn't work out a simple algorithm.

The way I do it programmatically is just the way I'd do it by hand:

1) Identify the dependants.
2) Unload them (in the proper order).
3) Unload the target package.
4) Reload the target package.
5) Reload the dependants (in the reverse order).

Works a treat...

    -- chris

Chris,

[Talk about reloading packages snipped]

> > It's certainly possible but I'm not sure how easy it would be. You'd
need
> > some way to difference the contents of the two packages so that the one
on
> > disk could be merged with the one in the image (sort of like a change
set,
Yes, that would be a labour saver certainly. The difficulty I was referring
to was the ability to be able to "refresh" a package in-situ. This would
avoid any problems with having to destroy instances of classes contained in
any of the packages that have to be removed and then reloaded.

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,

> > 1) Identify the dependants.
> > 2) Unload them (in the proper order).
> > 3) Unload the target package.
> > 4) Reload the target package.
> > 5) Reload the dependants (in the reverse order).
[...]
> Yes, that would be a labour saver certainly. The difficulty I was
referring
> to was the ability to be able to "refresh" a package in-situ. This would
> avoid any problems with having to destroy instances of classes contained
in
> any of the packages that have to be removed and then reloaded.

I supose it depends how you work and what you work on.  I don't normally
have long-lived instances kicking about (unless their package contains code
to unload/restore them too).  So that's hasn't yet been an issue for me.
(Except for the tool that actually does the package reinstalls for me --
getting it to reinstall *itself* is not so easy!)

I prefer the simple certainty of the brute force approach (in this case) to
a sophisticated algorithm that (as you've said) is difficult to specify, and
would probably be even harder to implement correctly.

> Andy Bower

    -- chris