Cosmetic bug - Using larger font - Class Instance radios wrap

Another small bug - If I crank up the font in the workspace - I chose
MS Sans 12pt bold (both the Default font and the Workspace default
font) - the Class/Instance radio buttons in the browsers don't resize
properly they wrap (even with a maximised window where there is lots of
space).

Its a small point - but typically you do this for a projected demo, and
it just looks bad (in public ;-)


So far all the other GUI elements seem to behave correctly.

Tim

I notice that you get the same kind of problem in the View Composer -
view toolbox (the icons for each categor overlap the text of the icon
above).

Tim

p.s. Is there any way to design UI's in Dolphin that don't do this. Eg.
I remember you could always spot a VB app because of this - but then
they introduced that Rubber Band groupy thing. I know in java you have
layout managers - how do you do that in Dolphin?

e.g. If I have two buttons "Generate Result", and "Preview Result" can
I put them in some stretchy container and let the buttons float in it -
perhaps the second button attached to the right edge of the first?

Tim,

> I notice that you get the same kind of problem in the View Composer -
> view toolbox (the icons for each categor overlap the text of the icon
> above).

I like a larger font as well so I've got a workspace script that I run
on a new image that goes through and readjusts the size of all the views
that exhibit any wrap around.  You have to tell it which views and what
to adjust but it's not that much bother.  Shout if you want a copy.

> p.s. Is there any way to design UI's in Dolphin that don't do this. Eg.
> I remember you could always spot a VB app because of this - but then
> they introduced that Rubber Band groupy thing. I know in java you have
> layout managers - how do you do that in Dolphin?

You use LayoutManagers :-)

> e.g. If I have two buttons "Generate Result", and "Preview Result" can
> I put them in some stretchy container and let the buttons float in it -
> perhaps the second button attached to the right edge of the first?

You would normally do this in the ViewComposer - look at the
#layoutManager aspect of the enclosing view and the #arrangement aspect
of the subViews.  There are a number of different LayoutManagers you can
use but I prefer the FramingLayout one - it seems to give more control
albeit with a bit more effort.  Here's a simple bit of workspace script
that shows it in action ....

c := ContainerView show.
c layoutManager: FramingLayout new.
c addSubView: (p1 := PushButton new).
p1 text: 'Left'.
p1 arrangement
        topFraming: #fixedParentTop;
        topOffset: 30;
        bottomFraming: #fixedParentBottom;
        bottomOffset: -16;
        leftFraming: #fixedParentLeft;
        leftOffset: 8;
        rightFraming: #relativeParentWidth;
        rightOffset: 0.5.
c addSubView: (p2 := PushButton new).
p2 text: 'Right'.
p2 arrangement
        topFraming: #fixedParentTop;
        topOffset: 30;
        bottomFraming: #fixedPreviousBottom;
        bottomOffset: 0;
        leftFraming: #fixedPreviousRight;
        leftOffset: 8;
        rightFraming: #fixedParentRight;
        rightOffset: -8

--
Ian

Use the Reply-To address to contact me (limited validity).
Mail sent to the From address is ignored.

Hey thanks Ian - I would quite like that script... and looking at the
above, if I use the view composer I can sort of work out how I can do
this visually - although what is a FramingLayout in the View Toolbox -
is it a Group Box?

Tim

Tim,

> Hey thanks Ian - I would quite like that script...

OK, here it is.  It is intended to be used in a clean image as part of
my image setup script.  It sets the font sizes than uses the
ViewComposer to edit each of the views that I've noticed wrapping
around.  The script looks a bit messy, all the #firsts and #seconds, but
a lot of the subViews don't have names.  Note that the VC will be
visible while this editing is going on, you can work around that but
I've never seen the point.


SmalltalkSystem current defaultFont: (Font  name: 'Arial' pointSize: 9).
SmalltalkWorkspace defaultFont:  (Font  name: 'Times New Roman'
pointSize: 11).


viewComposer := ViewComposer show: 'Vertical view'.

viewComposer openOn: (ResourceIdentifier class: ResourceToolboxPresenter
name: 'Default view').
subView:= viewComposer composingView viewNamed: 'categories'.
subView viewMode: #list.
viewComposer fileSave.

viewComposer openOn: (ResourceIdentifier class: CodeMentorPlugin name:
'Default view').
subView:= viewComposer composingView subViews second subViews third.
subView preferredExtent: 80@21.
viewComposer fileSave.

viewComposer openOn: (ResourceIdentifier class: AdvancedFindDialog name:
'Default view').
subView:= viewComposer composingView subViews first subViews third
subViews third.
subView extent: 101@85.
subView:= viewComposer composingView subViews first subViews third
subViews first.
subView extent: 144@85.
viewComposer fileSave.

viewComposer openOn: (ResourceIdentifier class: AdvancedFindDialog name:
'Directionless view').
subView:= viewComposer composingView subViews first subViews third
subViews second.
subView extent: 103@87.
subView:= viewComposer composingView subViews first subViews third
subViews first.
subView extent: 143@87.
viewComposer fileSave.

viewComposer openOn: (ResourceIdentifier class: AdvancedFindDialog name:
'Selector view').
subView:= viewComposer composingView subViews first subViews third
subViews second.
subView extent: 103@87.
subView:= viewComposer composingView subViews first subViews third
subViews first.
subView extent: 143@87.
viewComposer fileSave.

viewComposer exit.

 > and looking at the
> above, if I use the view composer I can sort of work out how I can do
> this visually -

It's one of those things that looks a bit complex at first but if you do
a bit of experimentation it does become clearer.  Once you get used to
it you can create quite complicated layouts - you do have to be a bit
inventive at times though :-)

 > although what is a FramingLayout in the View Toolbox -
> is it a Group Box?

I can't see the view you are talking about - could you narrow it down a
bit please.

--
Ian

Use the Reply-To address to contact me (limited validity).
Mail sent to the From address is ignored.

Gosh your patience is absolutely amazing - one day I hope to buy you a
beer!

I hit this on the SmaCC Gui tools in its generate tab. If i load the
view for the Gui into the View Composer, the left hand slidey shows all
the tool categories.

Presumably a framing layout is some grouping mechanism - however the
only ones I can see are in the category Group Box.

Maybe the one you can hand code doesn't appear in this list (which is a
shame) - althought presumably there is some way to add it - unless a
group box can do the trick?

Hmmm one thing seems to unfold into another - there is so much to keep
learning ;-)

Anyway - far too late now.

Thanks,

Tim

Tim,

> p.s. Is there any way to design UI's in Dolphin that don't do this. Eg.
> I remember you could always spot a VB app because of this - but then
> they introduced that Rubber Band groupy thing. I know in java you have
> layout managers - how do you do that in Dolphin?

In general the Dolphin layout managers react to the sub-components' ideas of
how big they should be, and that /may/ take the font size into account.

The details are a little complicated, and they seem to have changed pretty
drastically in D6 (which is a /major/ headache for me).  In D5 the picture
is[*] that the layout manager uses each component's #layoutExtent as a starting
point for computing a new layout.  That in turn looks to see if the sub-view
has #usePreferredExtent set to true.  If not then it just uses the current
extent (whatever that happens to be).  If it was set then another layer kicks
in.  If the #preferredExtent attribute is set (non-nil) then that is used.  If
that is /not/ set, then the view's #calculateExtent is called.  And this is
where the font-size can take effect.  For some view classes (e.g. StaticText),
the font size, and the current text, are used to derive a suggested size.
Other view classes (e.g. PushButton) inherit their #calculateExtent from
View -- which just answers the current extent -- so they are /not/ sensitive to
the font size.

([*] details are from memory, so there will be errors.)

It might be possible to add a #calculateExtent to PushButton (or use a custom
sub-class of PushButton) which took the font size and label into account, but I
haven't tried it.

    -- chris

"TimM" <[hidden email]> wrote in message
news:[hidden email]...
> Gosh your patience is absolutely amazing - one day I hope to buy you a
> beer!
>
> I hit this on the SmaCC Gui tools in its generate tab. If i load the
> view for the Gui into the View Composer, the left hand slidey shows all
> the tool categories.
>
> Presumably a framing layout is some grouping mechanism - however the
> only ones I can see are in the category Group Box.

No, it is not really grouping mechanism, and is certainly not a container.
LayoutManagers are not represented in the view hierarchy as such, but may be
attached to containers within it.

GroupBoxes are a purely visual device (a Windows control) that you can use
to give the appearance of grouping controls.

Regards

Blair