D6

Since we are definitely in Q4 of 2004, does any one has any idea of when
we should expect the long-awaited release of Dolphin 6 ???

Thanks!

On Mon, 06 Dec 2004 08:13:49 -0500, Benoit St-Jean
<[hidden email]> wrote:

>Since we are definitely in Q4 of 2004, does any one has any idea of when
>we should expect the long-awaited release of Dolphin 6 ???
>
>Thanks!

I'm afraid the answer is 'soon'. ;-)

> Since we are definitely in Q4 of 2004, does any one has any idea of when
> we should expect the long-awaited release of Dolphin 6 ???

I'm hoping for two Christmas presents this year:

Dolphin 6.
Orbiter Updated.

I've got a week off after christmas. During that break I would love to fly
some space missions and play with a new version of Dolphin. I hope Santa
comes.

Sean Malloy wrote:
Santa's gonna have to carry a HUGE bag this year 'cause a *lot* of us
asked for D6 ...  ;)

Hi,

does anybody have an idea what will be different, I mean D5 is already
pretty good.

Günther

Benoit St-Jean wrote:

Guenther,

> does anybody have an idea what will be different, I mean D5 is already
> pretty good.

True.  But there are rumors of overlapped socket calls (which is great,
but to be honest, I think we should keep the option of asynchronous
sockets as there is literature that suggests they can end up being more
efficient than blocking calls on OS threads), code mentoring from the RB
presented via agents, true block closures, and probably more that I
can't recall.

Have a good one,

Bill

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

Bill Schwab wrote:
> overlapped socket calls...
> keep the option of asynchronous
> sockets...
> code mentoring from the RB
> presented via agents...
> true block closures...

That all sounds good (and rather advanced for me - except maybe the
code mentoring?) but I really hope for more support for building GUIs.
I really get tired (and often confused) writing createComponents and
createSchematicWiring methods -- are there any plans for advancements
in this area?

Patrick,

Not really. The MVP framework is pretty much the same although the
Resource Browser/Toolkbox is being improved.

Best regards,

Andy Bower
Dolphin Support
www.object-arts.com

> That all sounds good (and rather advanced for me - except maybe the
> code mentoring?) but I really hope for more support for building GUIs.
> I really get tired (and often confused) writing createComponents and
> createSchematicWiring methods -- are there any plans for advancements
> in this area?

Especially given Andy's reply, there are two things you should consider.
  First, there is
  http://www.mitchellscientific.com/smalltalk/Dolphin4/PresenterGenTool.htm

which is likely to meet your needs and working style.  Basically, you
draw the view, and it writes the code.

Later on, you might want to try my code and view generator packages.
ViewGenerator is a largely abstract class, but is sufficiently pluggable
to do real work.  The "MVP Generators Base" package in my goodies
includes AspectDrivenViewGenerator as an example of how you might
subclass ViewGenerator.  I use ViewGenerator via a subclass that would
be of no use to you.

Happy Smalltalking!

Bill

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

"Bill Schwab" <[hidden email]> wrote in message
news:cpa5u0$15o6$[hidden email]... ...

There is also an enhanced version for Dolphin 5 here
http://www.mitchellscientific.com/smalltalk/PresenterGenTool.htm .

Chris

Chris,

> There is also an enhanced version for Dolphin 5 here
> http://www.mitchellscientific.com/smalltalk/PresenterGenTool.htm .

Great!  Apologies, I took the first link Google gave me :(

You reminded me of something.  From the above: "If you make a typo in a
view name it can be hard to spot as there will be no error message.".  I
would certainly make it optional and default to current behavior, but it
would be nice to be able to tell any given presenter that missing views
are to be considered an error.  The current behavior is very powerful,
but it can get confusing at times.

Have a good one,

Bill

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

"Bill Schwab" <[hidden email]> wrote in message
news:cpa8s4$15r2$[hidden email]...
>
> You reminded me of something.  From the above: "If you make a typo in a
> view name it can be hard to spot as there will be no error message.".  I
> would certainly make it optional and default to current behavior, but it
> would be nice to be able to tell any given presenter that missing views
> are to be considered an error.  The current behavior is very powerful, but
> it can get confusing at times.

When I first wrote that I think I was new to Dolphin, and still learning
MVP.  Now that does not really represent a problem for me because I use my
presenter generator a lot.  When I don't and something does not work right
the view name is one of the first things I check.  I suppose that is the
"danger" of our experience.  We know the most common things we do wrong, and
can usually spot and fix them quickly.  A new user does not have the
advantage of that experience and I suspect would become frustrated more
easily (as was probably the case with me when I wrote the presenter
generator).  The problem is how to improve the experience for new uses
without annoying users with experience.  Keeping the current behavior as the
default would not bother experienced uses, but I doubt many new users would
know to turn the setting on.

I think that at some point I would really like to see improved MVP
management tools added to Dolphin.  My presenter generator is an attempt at
that.  I think there could be something even better than that.  Someone can
slap together a GUI in VB quickly.  The same thing when done correctly using
MVP in Dolphin requires more typing and special knowledge.  Some will find
that frustrating.  I am not totally sure what the solution should be.  I
wish I had more time to experiment with ideas.

Chris

Chris,

> The problem is how to improve the experience for new uses
> without annoying users with experience.  Keeping the current behavior as the
> default would not bother experienced uses, but I doubt many new users would
> know to turn the setting on.

Probably not, but it's not really them that I am trying to help - it's
us.  You raise a good point that the lesson eventually gets learned, but
we as experienced users (hopefully) do more, and have more things to
consider when looking for problems.  It seems that an optional grump
when a name is missing would be helpful.


> I think that at some point I would really like to see improved MVP
> management tools added to Dolphin.  My presenter generator is an attempt at
> that.  I think there could be something even better than that.

Probably, but it looks fairly slick as it is.  In fact, I probably
should use it myself, and I have _no_ explanation for why I don't use it =:0


 > Someone can
> slap together a GUI in VB quickly.  

True, but VB is world in which early gratification comes quickly, but
that learning does not appear (IMHO) to make the next steps any easier.
  Besides, I quickly tired of getting stuck in all of syntactic sugar.


 > The same thing when done correctly using
> MVP in Dolphin requires more typing and special knowledge.

But I argue that the knowledge is more generically applicable, and to
non-trivial problems.  The learning curve is steeper, but it's worth the
climb.  I understand that you are not suggesting otherwise.



 > Some will find
> that frustrating.  I am not totally sure what the solution should be.  I
> wish I had more time to experiment with ideas.

FWIW, I am trying to do more things along the lines of CodeGenerator's
IDE extension.  Look at the part the generates constructors, and then
(this part is a stretch<g>) imagine it reading your mind about common
MVP programming tasks.  I think (hope is more like it) that a few well
chosen options would make life a lot easier.

I really need to clean up my handling of menus (in IDE extensions)
though.  I started on it a while back and got too busy to finish.  I
will try to return to it soon.  In case you are feeling inspired, I
think it would be a big help to have a few selectors (for the various
IDE tools and their menus) that lazily create and return menus and submenus.

Have a good one,

Bill


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

Chris,

> I really need to clean up my handling of menus (in IDE extensions)
> though.  I started on it a while back and got too busy to finish.  I
> will try to return to it soon.  In case you are feeling inspired, I
> think it would be a big help to have a few selectors (for the various
> IDE tools and their menus) that lazily create and return menus and
> submenus.

Ok, I shamed myself into doing a little work on this.  Below are a few
things that you are welcome to steal if you find them helpful.
#addSeparatorConditional is particularly bothersome for me, because I
have it packaged elsewhere, and will have stripping problems if I move
it to my IDE extensions package.  It might be time to duplicate it :(  I
considered adding IDEExtenderAbstract>>ensureSeparator:, but that would
mess up the cascades.

Having done this and made some progress on propagating it into a couple
of extensions, it is clear that their load (actually, activation) order
will affect the order of items in the menus.

Another option would be to have one extension for each tool, and add
funcionality to them, perhaps by forwarding to "extension plugins"???
Even then, the question of order would arise.  Any ideas?  I suppose I
could add an order to my #activateAllExtensions.  As a pleasant
accident, the order I have right now is really quite logical thanks to
alphabetical order and other details.  Wait until Murphy hears about it :)

Have a good one,

Bill



!IDEExtenderAbstract methodsFor!

classBrowserClassesContextMenu
        "Answer the context menu of the CHB/SB class hierarchy selector.
        Caveat emptor: the I'm not much into system browsers, so this might be
untested for SBs."

        ^((self shell presenterNamed:'classes') view viewNamed:'classes')
contextMenu
! !
!IDEExtenderAbstract categoriesFor:
#classBrowserClassesContextMenu!accessing!menus!public! !

!IDEExtenderAbstract methodsFor!

classBrowserClassesContextMenuSubMenu:aString
        "Lazily answer a named sub-menu of the CHB/SB class hierarchy selector.
        Caveat emptor: the I'm not much into system browsers, so this might be
untested for SBs."

        ^self
                subMenuNamed:aString
                of:self classBrowserClassesContextMenu.
! !
!IDEExtenderAbstract categoriesFor:
#classBrowserClassesContextMenuSubMenu:!accessing!menus!public! !

!IDEExtenderAbstract methodsFor!

packageBrowserPackagesListView
        "Answer the MultipleSelectionListView displaying packages.  This is
intended
        to look inside the PackageSelector to get the actual list view."

        ^(self shell presenterNamed:'packages') view viewNamed:'packages'! !
!IDEExtenderAbstract categoriesFor:
#packageBrowserPackagesListView!accessing!menus!public! !

!IDEExtenderAbstract methodsFor!

viewComposerContextMenu
        ^(self shell view viewNamed:'main') view contextMenu! !
!IDEExtenderAbstract categoriesFor:
#viewComposerContextMenu!accessing!menus!public! !

!IDEExtenderAbstract methodsFor!

viewComposerContextMenuSubMenu:aString
        "Lazily answer a named sub-menu of the VC context menu."

        ^self
                subMenuNamed:aString
                of:self viewComposerContextMenu.
! !
!IDEExtenderAbstract categoriesFor:
#viewComposerContextMenuSubMenu:!accessing!menus!public! !
!IDEExtenderAbstract methodsFor!

subMenuNamed:aString of:ctx
        "Lazily answer a named sub-menu of the indicated menu; test
        for nil (I think that will do more good than harm??)."

                | subMenu |

        ctx isNil ifTrue:[ ^nil ].

        subMenu := ctx items
                                detect:[ :each |
                                        ( each isKindOf:Menu ) and:[ each text = aString. ].
                                ]
                                ifNone:[
                                        ctx addSubmenu:aString.
                                ].

        ^subMenu.
! !
!IDEExtenderAbstract categoriesFor:
#subMenuNamed:of:!accessing!helpers!menus!private! !

!Menu methodsFor!

addSeparatorConditional
        "If the last item is not a divider, add one; do nothing if
        there are no items."

        ( self items notEmpty and:[ self items last isDivider not ] ) ifTrue:[
                self addSeparator.
        ].
! !
!Menu categoriesFor: #addSeparatorConditional!adding!public! !




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

Thanks Chris and Bill, I'll be sure to check out your work. My trouble
is that I only program in Smalltalk occasionally (for fun) and I always
come back after a few months and forget half of what I learned up to
that point.

> Thanks Chris and Bill, I'll be sure to check out your work. My trouble
> is that I only program in Smalltalk occasionally (for fun) and I always
> come back after a few months and forget half of what I learned up to
> that point.

Try Chris' package now.  Try mine after you get hooked and need
something that generates big forms from meta data, or something similar
to that.  For now at least, ViewGenerator only shines when the job is
sufficiently ugly (and/or error prone) to justify doing some programming
to make it easier and more reliable.

I will _eventually_ complete a more user-friendly tool, and will crow
about it here.  You will of course want to drop everything and try it
immediately :)

Have a good one,

Bill


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

"Bill Schwab" <[hidden email]> wrote in message
news:cpakj1$1c8c$[hidden email]...
>> I think that at some point I would really like to see improved MVP
>> management tools added to Dolphin.  My presenter generator is an attempt
>> at that.  I think there could be something even better than that.
>
> Probably, but it looks fairly slick as it is.  In fact, I probably should
> use it myself, and I have _no_ explanation for why I don't use it =:0

I think there is a kind of inertia that applies to programmers.  Once we get
used to doing things a certain way that is below our pain threshold we tend
to keep doing them that way. ;)  I suppose that also explains why I haven't
continued to improve the presenter generator further.

> > Someone can
>> slap together a GUI in VB quickly.
>
> True, but VB is world in which early gratification comes quickly, but that
> learning does not appear (IMHO) to make the next steps any easier.
> Besides, I quickly tired of getting stuck in all of syntactic sugar.

I concur.  Once in a while I have the misfortune of having to work on an old
Access VBA program.  I feel frustrated at not having the kinds of
development tools I have come to expect in Smalltalk.

> > The same thing when done correctly using
>> MVP in Dolphin requires more typing and special knowledge.
>
> But I argue that the knowledge is more generically applicable, and to
> non-trivial problems.  The learning curve is steeper, but it's worth the
> climb.  I understand that you are not suggesting otherwise.

Quite right. With Smalltalk and MVP there is a requisite philosophy one
needs to embrace.  Some people are perhaps more open to new philosophies
than others.

> FWIW, I am trying to do more things along the lines of CodeGenerator's IDE
> extension.  Look at the part the generates constructors, and then (this
> part is a stretch<g>) imagine it reading your mind about common MVP
> programming tasks.  I think (hope is more like it) that a few well chosen
> options would make life a lot easier.

I once had an experimental prototype of a tool that would create a listbox
of all a prototypical objects "attributes".  They could then be dragged and
dropped on a view in a view composer.  It would create a logical view based
on the value class, create  appropriate createComponents code, and even the
model: code to set the models.  Basically it was like the fields list in MS
Access where you can drop databound text boxes on a form.  I got it working
a few years ago, but for some reason never pursued it further.  I should
probably dust it off some time.  If nothing else it was a nifty idea.

I have also thought about trying to make my code completion tool (
http://www.mitchellscientific.com/smalltalk/CJDLookUp.htm ) better.  Now
that there is an accessible parser in Dolphin I could make it even smarter.
Possibly it could display lists of events and view names in appropriate
contexts.

> I really need to clean up my handling of menus (in IDE extensions) though.
> I started on it a while back and got too busy to finish.  I will try to
> return to it soon.  In case you are feeling inspired, I think it would be
> a big help to have a few selectors (for the various IDE tools and their
> menus) that lazily create and return menus and submenus.

I will look at your code in the next message.  Anything that makes it easier
to produce IDE extensions for Dolphin is great.  OA made a big improvement
with version 5.0.  Before that adding anything to existing views always
seemed a little hairy.

Chris

Chris,

> I once had an experimental prototype of a tool that would create a listbox
> of all a prototypical objects "attributes".  They could then be dragged and
> dropped on a view in a view composer.  It would create a logical view based
> on the value class, create  appropriate createComponents code, and even the
> model: code to set the models.  Basically it was like the fields list in MS
> Access where you can drop databound text boxes on a form.  I got it working
> a few years ago, but for some reason never pursued it further.  I should
> probably dust it off some time.  If nothing else it was a nifty idea.

If you have the pieces working, then by all means stay on course, but it
sounds like an interesting ViewGenerator subclass.


> I have also thought about trying to make my code completion tool (
> http://www.mitchellscientific.com/smalltalk/CJDLookUp.htm ) better.  Now
> that there is an accessible parser in Dolphin I could make it even smarter.
> Possibly it could display lists of events and view names in appropriate
> contexts.

Interesting idea.  My thought was to do something along the lines of my
constructor feature, only spread around in the likely context menus.
However, I was wondering whether something that pasted code would be
more appropriate (in other words, change the method vs. replacing it as
CodeGenerator would be inclinded/limited to do).  That ends up being
basically what you are describing, and you have something working in the
general direction.

In favor of the dialog idea, it might be more natural to make some
selections, click ok to see a proposed change, and either copy from it
or just accept and then keep going.  A look at the Window Builder docs
is probably in order, and possibly some review of the VC++ class wizard.


The real problem was that unless one did a really good job of it, the
work was toast at the next image build.  Translation: it didn't happen
because it would likely get lost.  IDE extensions are a great concept.

I just made a long-overdue change to the Code Generator extension.  It
is no longer necessary (not on the web site yet) to select a method and
then choose from the classes list to do things that apply to the method.
  However, I am starting to understand why it was so oddly created.
Take a look at the CHB view structure and see if you don't have trouble
connecting to the method list.  I finally resorted to this:

( self shell view viewNamed:'methods' ifNone:[ ^nil ] ) selfOrReferee

Am I missing a more direct path to it?

Have a good one,

Bill

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