Setting font

OK, I give up. How do I change the font for all the windows in Dolphin?

And b: how did you find out?

Thanks!

Ron

Further:

We figured out how to chenge it in D4, probably not in the best possible
way, using the Resource Browser to edit the CHB Shell. We drilled down
to the cards and set the font and it changed pretty much all the fonts
in the CHB. In D5, this trick doesn't work.

So still wondering how to do it in D5, and how to figure out how to do it.

Thanks,

Ron Jeffries wrote:

Ron,

> So still wondering how to do it in D5, and how to figure out how to do it.

You can change the workspace fonts using Dolphin
Options/Workspace/defaultFont.

Beta 1 had another option (Dolphin Options/SystemFolder/defaultFont) that
used to change the font used in trees/lists as well. In Beta3 you have to do
this manually

SmalltalkSystem current defaultFont: (Font name: 'Arial' pointSize: 16)

> And b: how did you find out?

I think it was mentioned in one of Kent's books wasn't it <g>   Dolphin has
always had some way of changing fonts, it's just a matter of tracking it
down in new releases.

Ian

BTW, I've got a little app that can rewind through method
definitions/deletions to a given point. Having a bit of bother with class
definitions though - I'll get back to you (hopefully)

Hi Ian and Ron,

> Beta 1 had another option (Dolphin Options/SystemFolder/defaultFont) that
> used to change the font used in trees/lists as well. In Beta3 you have to
do
> this manually

It is still there, but has been moved under "a RefactoringSmalltalkSystem".

I agree that it is way too hard for a new user to change fonts. One of the
first things I usually do when working in a new program is to change the
font. A new Dolphin user has to deal both with a published aspect inspector,
and with the changes in D5 where each ToolShell has an Tools/Options/Inspect
command, they have to open the right one (ie from the SmalltalkSystemShell).

I think the font aspects should be special cases and given their own menu
commands. It might also help if a Tool's Tool/Options/Inspect command opened
the "Dolphin Options" shell with that tool's aspect selected and expanded,
rather than just it's publishedAspects.

An alternative would be to have a new "Dolphin Options" Shell with a
cardContainer. The first pane could provide some hand-holding for common
options, the second would be the current publishedAspectInspector.

> BTW, I've got a little app that can rewind through method
> definitions/deletions to a given point. Having a bit of bother with class
> definitions though - I'll get back to you (hopefully)

Sounds great!, another of your tools that will be permanently in my image!
Thanks,
Steve

Ian Bartholomew wrote:

> Ron,
>
>
>>So still wondering how to do it in D5, and how to figure out how to do it.
>>
>
> You can change the workspace fonts using Dolphin
> Options/Workspace/defaultFont.


Cool, thanks. Andy pointed me to that. Chet and I looked at that thing
and couldn't figure out what it was, let alone how to use it. ;->



Yes. Had no doubt it was there. But couldn't find it. Thanks again!


>
> Ian
>
> BTW, I've got a little app that can rewind through method
> definitions/deletions to a given point. Having a bit of bother with class
> definitions though - I'll get back to you (hopefully)


That'd be way cool. Thanks!


R

"Steve Waring" <[hidden email]> wrote in message
news:[hidden email]...
> Hi Ian and Ron,
>
> > Beta 1 had another option (Dolphin Options/SystemFolder/defaultFont)
that
> > used to change the font used in trees/lists as well. In Beta3 you have
to
> do
> > this manually
>
> It is still there, but has been moved under "a
RefactoringSmalltalkSystem".

In the release this will be entitled 'Development System', where all
"global" development system options are now lodged.

> I agree that it is way too hard for a new user to change fonts. One of the
> first things I usually do when working in a new program is to change the
> font.

True perhaps, but something that is easily addressed in the FAQ.

>... A new Dolphin user has to deal both with a published aspect inspector,
> and with the changes in D5 where each ToolShell has an
Tools/Options/Inspect
> command, they have to open the right one (ie from the
SmalltalkSystemShell).

Ah, but think how much they've learned as a result of the experience. You
now know how to change any option, or at least where to start looking.

BTW: It has always been the case that the Tools/Options/Inspect opened the
PAI on just that tool's options, with the system folder (i.e. the launcher)
as the place to open all options. The class browser (in fact any tool with a
MethodBrowser embedded) was an exception because it had a bug in its command
routing.

>
> I think the font aspects should be special cases and given their own menu
> commands. It might also help if a Tool's Tool/Options/Inspect command
opened
> the "Dolphin Options" shell with that tool's aspect selected and expanded,
> rather than just it's publishedAspects.

I think that would certainly be appropriate for a normal application, but
Dolphin is a development tool. It is going to be necessary to learn how to
use the PAI and Dolphin Options anyway, and changing the font is a
relatively gentle introduction. We think it is very much within the
Smalltalk philosophy to provide a generic mechanism for all options that may
require some initial effort up front, but once learned is of general
applicability. Furthermore the "cost" of adding new options is very low
since no custom UI is needed (the benefit of that being that we are more
likely to respond positively to requests to add options), and any additional
tools that a user writes can benefit from the general capability with the
little more than the addition of a class side #publishedAspects method.

Regards

Blair

Hi Blair,

I dont want to belabor the point, it is very subjective and not important to
me personally.

Smalltalk and Dolphin are beautiful, but IMO Times New Roman is not.

I am not sure how receptive I as a new user would be in learning the tools
while trying to eliminate Times New Roman from my screen :)

I know the argument that it is/was the "best" font, I just personally find
it hard to read on a screen, harder at 8/10pt, and harder when bold or
italics.

So in my previous message where I wrote: "way too hard to change fonts", I
was thinking: "way too hard to quickly get rid of TNR".

FWIW!
Steve

Steve Waring wrote:
This is my $0.02 worth, which I only thought worth posting because:

a) I'm coming at this fresh, D5 is my first ST; and
b) A large part of my job is GUI design/analysis.

---------------------------

It's not completely subjective - consistency with the native environment
re: fonts and colors, has objective benefits.

As a new user of Dolphin, I found it very easy in D5 to switch
everything to Tahoma except the views showing code, which I switched to
Lucida Console. I did this by changing the font in the Options for
RefactoringSmalltalkSystem to Tahoma 8pt, and the font in the Options
for Workspace to Lucida Console 9t. Apart from the Transcipt which ends
up in Tahoma, everything's cool. Of course, if you're using an earlier
version of Windows (and don't have Office), then you won't have Tahoma.
Tahoma is used extensively in the later Windows GUI, so it looks more
consistent. Is there any way to pick up the system menu font and use
that automatically?

I'm going to change the SmalltalkWorkspace views once D5 ships to inset
the text - it looks far better with 1 or 2 pixels inset left and top. I
think this requires wrapping the existing RichText using a BorderLayout
and modifying the class in a number of places.

I intend to modify the list presenters to use the system highlight color
- currently they use grey even though I use a lovely light sky blue in
WIndows :)

Although the use of italics for comments is traditional, italic anything
is harder to read. I'm going to change that to roman (as in non-italic,
not TNR).

The default class icon (and it's derivatives) is too big for the list -
I'm going to redo a number of those icons in slightly smaller antialised
forms, with richer colours for > 8 bit displays.

Finally, given the mixin nature of the private/public categories, I'm
going to add a checkbox above the method list to allow you to only show
public methods. Maybe one of the goodies I have seen already does this
kind of thing (filtering?) in which case I'll be spared that effort.

-------------------------
Antony Blakey
mailto:[hidden email]
Linkuistics Pty Ltd
Adelaide, South Australia

Anthony,

> Finally, given the mixin nature of the private/public categories, I'm
> going to add a checkbox above the method list to allow you to only show
> public methods. Maybe one of the goodies I have seen already does this
> kind of thing (filtering?) in which case I'll be spared that effort.

Though not a true filter, if you click on the 2nd column heading in the
methods listview (the column showing green and red "m"s), it will sort the
methods, showing public methods first.

-- Louis

Louis Sumberg wrote:
I know, but still I prefer a filter. I'm not keen on the conceptual
conflation of public/private with the other categories. Public/private
is acknowledged to be special, as is deprecated (hence the existance of
the list sorting mechanism and icon changes). You would presume that all
category memberships that alter the icon shown in that column are on the
same conceptual axis; a different conceptual axis to  than those that
dont modify the icon. Note further that a method *is* either public _or_
private, and that that particular categorisation is orthogonal to other
memberships. In practice the deprecated category forms another
independent axis, and hence there is a problem with the list in that
case because the ability to identify public vs. private is lost if the
method is deprecated. Overall I think the category mechanism needs to be
recast (or at least specified in some _formal_ way), and the interface
definitely needs reworking.

A start would be to determine the axes, initially:

   a) public _or_ private; and
   b) deprecated _or_ not; and
   c) arbitrary membership(s) of other categorical sets.

In fact, now that I think of it, I think the problem for me really is
the conflaction of attributes (public/private, deprecated/not) with the
set membership that is categorisation. The attributes don't need to be
binary. In implementation terms it's the difference between a map and a
multimap. I'm sure there's a better interface for that, even in the face
of arbitrary extensiblity.

FWIW - and guys - feel free to completely ignore this ;> - I agree with
Steve.  Since Dolphin is MS Windows oriented, I would leave the fonts
setting capability exactly the way it is, but default to a well known
Windows font - perhaps ms sans-serif since tahoma isn't always there, and
perhaps courier for code font (personal preference there).

I do always change the fonts as part of building my personal base
development image.  So this is no big deal to me, but it might highlight the
Windows integration a little more to have the font familiar to Windows
programmer types -

My "not sure it is even worth" $0.02 ;> -

jlo

"Steve Waring" <[hidden email]> wrote in message
news:[hidden email]...
> Hi Blair,
>
> I dont want to belabor the point, it is very subjective and not important
to