Default TextEdits and StaticTexts are too tall...

I can't believe I never mentioned this before.  It has annoyed me for a
while but I never took the time to mention it here.  I _think_ that at some
point Dolphin used a taller default font.  It now uses a more standard
Windows font height.  However the default height of TextEdit and StaticText
views was never reduced.  Currently the text floats higher than in other
Windows programs.  It is not vertically centered in the text box or static
text.  That makes it imposable to align a StaticText with the middle of a
TextBox.  If the controls are aligned then the static text will always be at
the top of the text box, not in the middle.

Is there any reason to retain this extra room bellow the text?  If not, I
would propose changing the default height of TextEdit, StaticText and any
other relevant resources from 25 to 19 pixels.  I think this is the height
most Windows programs use.  Evaluate the code bellow to see what I am
talking about.
=========
s := ShellView show.
s extent: 400@200.
te := TextEdit new.
s addSubView: te.
te position: 10@10.
te2 := TextEdit new.
s addSubView: te2.
te2 position: 120@10.
te text: 'Default is floating'.
te2 text: 'Fixed is good'.
te2 extent: (te2 extent y: te2 calculateExtent y).
==========

Chris

Christopher J. Demers wrote:

> I can't believe I never mentioned this before.  It has annoyed me for a
> while but I never took the time to mention it here.

Me too.  For years in fact ;-)

I think I got used to it back in the days when text in Dolphin defaulted to
TimesRoman-11 (iirc) but I used MSSans-8 everwhere.  And I never really
focussed on the issue when the default changed.

In an ideal world, I suppose, the components would (be able to) scale
themselves to the actual font in use, but this -- sadly -- is a less than ideal
world...

Can be *done*, of course, with some extra effort, but I've not (yet) found it
worthwhile going to those lengths.

    -- chris

[Sorry if you see this twice -- news server playing up again]

Christopher J. Demers wrote:

> I can't believe I never mentioned this before.  It has annoyed me for a
> while but I never took the time to mention it here.

Me too.  For years in fact ;-)

I think I got used to it back in the days when text in Dolphin defaulted to
TimesRoman-11 (iirc) but I used MSSans-8 everwhere.  And I never really
focussed on the issue when the default changed.

In an ideal world, I suppose, the components would (be able to) scale
themselves to the actual font in use, but this -- sadly -- is a less than ideal
world...

Can be *done*, of course, with some extra effort, but I've not (yet) found it
worthwhile going to those lengths.

    -- chris

Chris,


You're right, it annoys the hell out of me too. However, unless I'm
missing something, this (i.e. the alignment of static text and single
line edits) is really a Windows issue and not one that can just be
fixed by changing the the default height of the boxes as you suggest.
If you extend your example above with the following, you'll see what I
mean:

========
te3 := StaticText new.
s addSubView: te3.
te3 position: 240@10.
te3 extent: te2 extent.
te3 text: 'Static is still bad'.
========

I've just tried the same thing in the Visual Studio .NET dialog editor
and this exhibits the same problem. For some brain-dead reason MS chose
to give static texts and editable texts different margins and this
carries through to any editor that does its placement based on the
bounding box rather than relative to the baseline of the text. A
disadvantage to using native widgets I suppose.

It might be possible to alter the way the VCs gridding works so that it
asks for a grid origin of each object as it positions them and this
could then be the text baseline for all text type views. I've opened an
issue #1515 to suggest this. Until then it looks like we'll have to
carry on using the nudge buttons in the View Composer (from Ian's
extensions) to align the fields.

I also agree that the default size of the static and editable text view
resources is wrong as per your report. However, I think this is more of
a cosmetic issue and won't address the underlying alignment problems.
I've recorded this as #1516.

Best regards,


Andy Bower
Dolphin Support
www.object-arts.com

"Andy Bower" <[hidden email]> wrote in message
news:4056eeee$[hidden email]...
> Chris,
>
> > I can't believe I never mentioned this before.  It has annoyed me for
> > a while but I never took the time to mention it here.  I think that
> > at some point Dolphin used a taller default font.  It now uses a more
> > standard Windows font height.  However the default height of TextEdit
> > and StaticText views was never reduced.  Currently the text floats
> > higher than in other Windows programs.  It is not vertically centered
...
> You're right, it annoys the hell out of me too. However, unless I'm
> missing something, this (i.e. the alignment of static text and single
> line edits) is really a Windows issue and not one that can just be
> fixed by changing the the default height of the boxes as you suggest.
> If you extend your example above with the following, you'll see what I

Yes, you are quite right.  However I think it looks less noticeable if the
TextEdit is smaller.

> It might be possible to alter the way the VCs gridding works so that it
> asks for a grid origin of each object as it positions them and this
> could then be the text baseline for all text type views. I've opened an
> issue #1515 to suggest this. Until then it looks like we'll have to
> carry on using the nudge buttons in the View Composer (from Ian's
> extensions) to align the fields.

Here is an idea to consider: If one makes the StaticText height 13, and the
TextEdit height 19 then one can align middles and the text looks fairly
close.  Try this:
=======
s := ShellView show.
s extent: 200@100.
te := TextEdit new.
s addSubView: te.
te position: 67@30.
te text: 'Default is floating'.
te text: 'Fixed is good'.
te extent: (te extent y: te calculateExtent y). "y= 19 here."
st := StaticText new.
s addSubView: st.
st position: 20@30.
"Note that the bottom of the g is still visible."
st text: 'Better?g:'.
st extent: 45 @ st calculateExtent y . "y = 13 here"
"Similar to align middles in VC."
st rectangle: (st rectangle centerY: te rectangle centerY).
s backcolor: Color dialog.
=============

> I also agree that the default size of the static and editable text view
> resources is wrong as per your report. However, I think this is more of
> a cosmetic issue and won't address the underlying alignment problems.
> I've recorded this as #1516.

The only potential issue I can think of might be if there were a foreign
language that had taller characters.  However in that case I would expect
that the developer could just make the default view taller if needed.

Chris

"Christopher J. Demers" <[hidden email]> wrote in
message news:c37roq$252018$[hidden email]...
>
> The only potential issue I can think of might be if there were a foreign
> language that had taller characters.  However in that case I would expect
> that the developer could just make the default view taller if needed.

Can you check the point size of the default font?

"Mark Wilden" <[hidden email]> wrote in message
news:[hidden email]...
> "Christopher J. Demers" <[hidden email]> wrote in
> message news:c37roq$252018$[hidden email]...
> >
> > The only potential issue I can think of might be if there were a foreign
> > language that had taller characters.  However in that case I would
expect
> > that the developer could just make the default view taller if needed.
>
> Can you check the point size of the default font?

Yes. The default font seems to be Microsoft Sans Serif 8pt.

Chris

Andy,

> I've just tried the same thing in the Visual Studio .NET dialog editor
> and this exhibits the same problem. For some brain-dead reason MS chose
> to give static texts and editable texts different margins and this
> carries through to any editor that does its placement based on the
> bounding box rather than relative to the baseline of the text. A
> disadvantage to using native widgets I suppose.

When emulating, one can make things more friendly, but (lack of) scalability
is my primary objection to native widgets.  Of course anything built into
the image is then much easier to deploy, and less vulnerable to oddities of
the target machine and OS.


> It might be possible to alter the way the VCs gridding works so that it
> asks for a grid origin of each object as it positions them and this
> could then be the text baseline for all text type views. I've opened an
> issue #1515 to suggest this. Until then it looks like we'll have to
> carry on using the nudge buttons in the View Composer (from Ian's
> extensions) to align the fields.

Some time ago, we discussed alternatives to the general problem of using
static controls to label edit controls, and you favored a customized layout
manager and/or arrangement.  Sounds good to me.

Have a good one,

Bill

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

Bill,

In general, I much prefer native widgets (which, presumably is one of
the reasons why Dolphin ended up supporting them :-)). One of the
things Microsoft do every few years is to change the "look" of the
widget set to make the OS feel new. Regardless of whether you consider
this to be a good thing (actually, I quite like it) the amount of work
this would involve if you were trying to emulate the widget set and
keep up to date would be prohibitive. And, of course, if you decide not
to follow the trend then your users are bound to moan about the
outdated look.

I think I said that I would prefer the idea of combining a text field
and its label within some sort of container (controlled by a
specialized layout manager) rather than creating a new combined text
field/label field combined control. I've had experience with the latter
in a previous life and it didn't work too well.

Actually, in this case, I prefer the idea of making the grid smarter.
If we give each view the option of specifying the alignment origin then
text fields and static fields can have the option of providing an
origin that is relative to the font's baseline. I'm not exactly sure
how it will work but, if the grid was more effective, it would making
laying out text field and associated static labels a snap and would
probably obviate for the need for a specialized layout manager. Anyway,
I've entered a support issue so we'll look at this in due course.

Best regards,

Andy Bower
Dolphin Support
www.object-arts.com

Andy,

> In general, I much prefer native widgets (which, presumably is one of
> the reasons why Dolphin ended up supporting them :-)). One of the
> things Microsoft do every few years is to change the "look" of the
> widget set to make the OS feel new. Regardless of whether you consider
> this to be a good thing (actually, I quite like it) the amount of work
> this would involve if you were trying to emulate the widget set and
> keep up to date would be prohibitive.

Would it?  I doubt I will get too much argument if I assert that Smalltalk
is vastly more productive than most other languages.  Given that it seems
that we spend a great deal of time responding to things that we wish
Microsoft had done more like we would have done it, one might ask (I did<g>)
why not simply put our clock cycles where our speaker is and beat Microsoft
to the punch when it makes sense to do so?

I am not suggesting that you should toss out every native widget in favor of
emulate ones, but I think if you had started out emulating in a big way, you
would by now have a very flexible framework such that keeping up with (even
ahead of) Microsoft's changes would be relatively simple.  Imagine a heavily
refactored version of your Moen Tree (which BTW, I would put up against
anything Microsoft has done in the way of widgets), with reusable
abstractions of nodes/selections/etc.


> And, of course, if you decide not
> to follow the trend then your users are bound to moan about the
> outdated look.

My experience is that users don't care much about the look.  They don't see
controls - they see "screens", and they quickly figure out that my software
is _much_ more robust than other systems they use.  That is in part because
I keep the machines as lean as possible, and of course, writing "the"
program in Smalltalk is a huge factor.

BTW, I do use native widgets - lots of them.  However, there are places in
my various user interfaces that involve several hundred (or more) hot spots,
and my experience is that those simply must be emulated for good performance
and stability.


> Actually, in this case, I prefer the idea of making the grid smarter.
> If we give each view the option of specifying the alignment origin then
> text fields and static fields can have the option of providing an
> origin that is relative to the font's baseline. I'm not exactly sure
> how it will work but, if the grid was more effective, it would making
> laying out text field and associated static labels a snap and would
> probably obviate for the need for a specialized layout manager. Anyway,
> I've entered a support issue so we'll look at this in due course.

Even if the controls won't tell you the location of the baseline, you can
probably guess well enough to improve the situation.  Is there a way to make
a window draw on a memory device context?  If so, you might be able to
capture the graphical output and look for the baseline.

Have a good one,

Bill

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

"Andy Bower" <[hidden email]> wrote in message
news:[hidden email]...
>
> In general, I much prefer native widgets

As a pretty well-experienced Visual FoxPro user (which uses emulated
widgets), I agree. Now matter how good the emulation and speed (or lack of
both, viz. Java Swing), it's not the same as native.

> (which, presumably is one of
> the reasons why Dolphin ended up supporting them :-)). One of the
> things Microsoft do every few years is to change the "look" of the
> widget set to make the OS feel new.

Microsoft also sometimes adds functionality, that users and developers
often/usually get for free.

Bill,

[SNIP].

> Even if the controls won't tell you the location of the baseline, you
> can probably guess well enough to improve the situation.  Is there a
> way to make a window draw on a memory device context?  If so, you
> might be able to capture the graphical output and look for the
> baseline.

Hmm.. it should be possible to calculate the baseline used by the
Windows controls from the font metrics and some guesses as to how the
control handles the border on/off aspect.

Best regards,

Andy Bower
Dolphin Support
www.object-arts.com

"Christopher J. Demers" <[hidden email]> wrote in
message news:c37tml$23vr75$[hidden email]...
> "Mark Wilden" <[hidden email]> wrote in message
> news:[hidden email]...
> > "Christopher J. Demers" <[hidden email]> wrote in
> > message news:c37roq$252018$[hidden email]...
> > >
> > > The only potential issue I can think of might be if there were a
foreign
> > > language that had taller characters.  However in that case I would
> expect
> > > that the developer could just make the default view taller if needed.
> >
> > Can you check the point size of the default font?
>
> Yes. The default font seems to be Microsoft Sans Serif 8pt.

Yes, that is true. To my slight surprise it is set in
SmalltalkSystem>>inititalize system, though of course it can be overridden
subsequently by setting the user preference 'defaultFont' of 'Development
System'. If you nil that setting (which I thought was the default), then the
default font will be picked up from the host's desktop font (actually the
Desktop Icon font). On most versions of Windows this is either Microsoft
Sans Serif 8pt, or something very like it (e.g. Tahoma 8pt).

Regards

Blair