Ian's ViewComposer package for Dolpin version 4

Ian, I have not delayed in asking you to port your ViewComposer package to
Dolpin 4 because of disinterest.  I have MISSED having it available.
Instead, I have delayed because I thought I ought to contribute to the
effort myself.

I have managed to convert and import it into Dolphin 4.  To get the bitmap
images to show up on the 'Toolbar.Align tools' I had to reselect the bitmap
file name for each button.  It took me a while to figure this out, so at
first I just turned off the #hasFlatAppearance so that, even though
imageless, I could see where to click, relying on the tool tips to remind me
what each blank button did.  The main thing I changed to get the package to
load was to disable the preuninstall and postinstall scripts (they referred
to the missing ShowShellManager).  Then, I changed
ViewComposer>>onViewOpened so it would send itself the #installSpread
message, so that it no longer needs ShowShellManager to put the new toolbar
into the ViewComposer.

Finally, I added a delta instance variable and #delta, #delta:,
#increaseDelta, and #decreaseDelta methods.  I also added a context menu to
the align toolbar containing the #increaseDelta and #decreaseDelta commands.
This lets me change the number of pixels moved at a time by #moveBy: when
clicking on the Nudge-Nudge buttons (Beth says I should call it Shove-Shove
now that I'm moving by larger distances).  Increase multiplies the current
delta by 10 and decrease divides
the current delta by 10, clamping it between 1 and 500.

Any, I have saved it as FcsViewComposer.pac and zip'd it up along with your
bitmap and put it on my Smalltalk web page

http://www.canyon-medical.com/smalltalk/smalltalk.html

for your downloading convenience in case it gives you a head start in
converting your package to Dolphin 4.

I also put a few other suggestions on that same web page.

(If anyone is using the ViewComposer without Ian's enhancements, he is
working too hard.)


-- Frank
[hidden email]

Frank,

> Ian, I have not delayed in asking you to port your ViewComposer package to
> Dolpin 4 because of disinterest.  I have MISSED having it available.

Yes. Having to scroll down through the aspects list every time to get at the
name aspect is the one that is getting to me.

The decision to stop using the ShellShowManager[1] is what caused the delay.
I was a bit unsure about how to proceed and because of that kept putting it
off.

The obvious solution is to subclass ViewComposer, add a new view,
override/add any required methods and change the Dolphin options to make the
new class the default for the ViewComposer. I'm a bit loathe to go down this
route though, from a more general point of view, as it means that anyone
else, either writing their own tool enhancements or getting some from
another source, who used the same technique would have to decide which set
to use - they would not coexist. Anyone got any thoughts on that?

I'll probably have a go at this over the next few days anyway, after
checking out your suggestions and updated version of course. Thanks for that
by the way anyway.

I've had a few thoughts myself
- The spread stuff will probably go - I never really used it much and you
can do most of it with the standard layout managers anyway.
- Rather than specifying, programmatically, which aspects should be at the
top I will try to copy the Win2000 method of remembering which ones are used
the most and position those at the top.

Thanks for the Nudge (or Shove) <g>

Ian

[1] Mainly because very few of the goodies would need it now, ViewComposer
is probably the only one. I am also not 100% sure that it would fit in with
the new Dolphin options where you can specify which class is used for each
tool.

"Ian Bartholomew" <[hidden email]> wrote in message
news:91ttkn$5hbef$[hidden email]...
> Frank,
> The decision to stop using the ShellShowManager[1] is what caused the
delay.

Sounds good.  I'm happy to have it go away.

> The obvious solution is to subclass ViewComposer, add a new view,
> override/add any required methods and change the Dolphin options to make
the
> new class the default for the ViewComposer. I'm a bit loathe to go down
this

I was a bit reluctant to add an instance variable to ViewComposer.  I nearly
set up a separate class with a class variable and class-side method to
answer (or set) its value just so I wouldn't need to add an instance
variable to ViewComposer.  I took the easy way out, though, and just added
it to ViewComposer.  (I have no reluctance to add my own methods to
ViewComposer, of course.)  I'm sure you and Object Arts know I am happy for
any of my changes/suggestions to be incorporated directly into the official
Dolphin.  I imagine you feel the same.  So, perhaps Object Arts will so
incorporate the better of our changes and suggestions and we won't need to
worry too much about subclassing, etc.  It is interesting to think how
closely we (Dolphin) can approach the goal of having the best GUI builder of
any Smalltalk.  I think we are well on the way.

> route though, from a more general point of view, as it means that anyone
> else, either writing their own tool enhancements or getting some from
> another source, who used the same technique would have to decide which set
> to use - they would not coexist. Anyone got any thoughts on that?

Hand merge and feed our ideas back to you to as the central release point
for the "unofficial" ViewComposer, with O-A adopting freely from this as
they wish?

> I've had a few thoughts myself
> - The spread stuff will probably go - I never really used it much

Funnily enough, although I seldom use it, I did use it a number of times a
few days ago.  I'd be inclined to leave it in for whenever it might be
useful.  It takes up cheap space (on a menu) rather than expensive space (on
a tool bar).  One thing that catches me now and then is the right-to-left
nature of it rather than the more "intuitive" left-to right nature.  That
is, I would prefer the first widget clicked on wind up on the left and the
last widget click on wind up on the right, rather than the current way it is
done.

> - Rather than specifying, programmatically, which aspects should be at the
> top I will try to copy the Win2000 method of remembering which ones are
used
> the most and position those at the top.

Ok.  I can live with either.  I don't know which I prefer.  I know I *hate*
Microsoft's changing (some) menus to put only the favorites at the top and
replacing the rest with a funny down arrow (e.g. Favorites in Internet
Explorer).  There is something to be said for finding things exactly where
you left them.

-- Frank
[hidden email]

Frank,

> Hand merge and feed our ideas back to you to as the central release point
> for the "unofficial" ViewComposer, with O-A adopting freely from this as
> they wish?

Yes. I was thinking more from the "add-on goodies" point of view where I
feel it is best to avoid the complicated installation that hand merging
might entail. An installable/uninstallable package with no extra steps
involved is what I usually try for - it's just a bit difficult with
something like VC additions.

> > - The spread stuff will probably go - I never really used it much
>
> Funnily enough, although I seldom use it, I did use it a number of times a
> few days ago.

Fair enough. It's just as easy to leave it in.

>             One thing that catches me now and then is the right-to-left
> nature of it rather than the more "intuitive" left-to right nature.  That
> is, I would prefer the first widget clicked on wind up on the left and the
> last widget click on wind up on the right, rather than the current way it
is
> done.

I raised exactly the same point myself as I also find it very un-intuitive.
It's a bit vague now but it was all to do with the way that Dolphin orders
the items, the last item selected is the one that the operation is based on.
I checked with Blair (as I recall) as it was a behavioural change made
between Dolphin Versions (2 to 3?) and was told that it was intentional as
this is the standard Windows UI way of doing things (don't bother - I know
your views on that <g>)

> Ok.  I can live with either.  I don't know which I prefer.  I know I
*hate*
> Microsoft's changing (some) menus to put only the favorites at the top and
> replacing the rest with a funny down arrow (e.g. Favorites in Internet
> Explorer).  There is something to be said for finding things exactly where
> you left them.

Am I the only person in the world who thinks the dynamic menus a brilliant
idea - it seems like it <g>. My  *hate* is when I do something that makes
the whole menus appear again and I can't find the thing I was looking for.

Anyway, I can make it an option. I was going to give each aspect a "starting
value" anyway, defining it's initial place in the list. If I make updating
this value every time an aspect is edited an option then the aspect list
will stay in the original order.

Ian

"Ian Bartholomew" <[hidden email]> wrote in message
news:92221u$5r7k7$[hidden email]...
> Frank,
>
> > Hand merge and feed our ideas back to you to as the central release
point
> > for the "unofficial" ViewComposer, with O-A adopting freely from this as
> > they wish?

> Yes. I was thinking more from the "add-on goodies" point of view where I
> feel it is best to avoid the complicated installation that hand merging
> might entail. An installable/uninstallable package with no extra steps
> involved is what I usually try for

I surely agree with this.  I guess what I was thinking of was an
installable/uninstallable package from you, which others might possibly
modify and feed back to you for consideration.  Your method of saving
(effectively renaming) system class methods that need to be modified (during
preinstallation), loading your replacement, then restoring the original
(during postuninstallation) seems to solve the problem of modifying a system
class method.  This takes care of installing the additions (e.g. modifying
#onViewOpened to send #installSpread).  The other point would be how to add
instance variables.  Can you do this also with some preinstall and
postuninstall magic?  If not, what about a utility class whose only purpose
is to hold instance variables (e.g. I nearly added an FcsViewComposer just
to hold the class variable delta)?  Maybe just plain subclassing
ViewComposer would be best after all.  Eventually the base Dolphin will
remove the hardcoded references to #ViewComposer and all will be fine.
Well, I should delete this rambling as I'll be glad with whatever approach
you decide upon.

> - it's just a bit difficult with something like VC additions.

> > That is, I would prefer the first widget clicked on wind up on the left
and the
> > last widget click on wind up on the right, rather than the current way
it
>
> I raised exactly the same point myself as I also find it very
un-intuitive.
> It's a bit vague now but it was all to do with the way that Dolphin orders
> the items, the last item selected is the one that the operation is based
on.

Somewhere, I forget, perhaps in WindowBuilder Pro for VA?, there is a
setting for whether the model widget is to be the one first selected or the
one last selected.  But, we still might draw a distinction between the
action of matching other widgets' lengths, widths, tops, etc. to the model
widget and the action of spreading across.  Left to right or right to left
is not overly important to me; I can live with it either way.

> I checked with Blair (as I recall) as it was a behavioural change made
> between Dolphin Versions (2 to 3?) and was told that it was intentional as
> this is the standard Windows UI way of doing things (don't bother - I know
> your views on that <g>)

Oh, it's no bother.  I'm glad to discuss those views at length!  ;)

> Am I the only person in the world who thinks the dynamic menus a brilliant
> idea - it seems like it <g>. My  *hate* is when I do something that makes
> the whole menus appear again and I can't find the thing I was looking for.

Fair enough.  Probably Microsoft's extensive user testing showed that the
majority are with you on this.  I would happily settle for knowing how to
turn it off (maybe there is a way to turn it off?).

> Anyway, I can make it an option. I was going to give each aspect a
"starting
> value" anyway, defining it's initial place in the list. If I make updating
> this value every time an aspect is edited an option then the aspect list
> will stay in the original order.

Sure, that sounds perfect to me.


-- Frank
[hidden email]

Frank,

> Fair enough.  Probably Microsoft's extensive user testing showed that the
> majority are with you on this.  I would happily settle for knowing how to
> turn it off (maybe there is a way to turn it off?).

IIRC, you're using Win2000?

If so

Windows -
Start Menu/Settings/Task Bar & Start Menu/Use personalized menus

Internet Explorer -
Tools/Internet Options/Advanced/Enable Personalised Favorites Menu

I think some other apps have individual settings as well

Ian

"Ian Bartholomew" <[hidden email]> wrote in message
news:[hidden email]...
> > turn it off (maybe there is a way to turn it off?).

> IIRC, you're using Win2000?

Yes.

> Windows -
> Start Menu/Settings/Task Bar & Start Menu/Use personalized menus

Thanks.  It looks like I already had it turned off at this level.  I guess
it is in Internet Explorer (favorites) that I notice it.

> Internet Explorer -
> Tools/Internet Options/Advanced/Enable Personalised Favorites Menu

Great!  Now I have it turned off.  It will be funny if I find I don't like
it that way as much and go back to personalized menus!  At least I have the
option now.


-- Frank
[hidden email]