New Look


	links to this page:

New Look

Last updated at 2:31 am UTC on 11 April 2007

Note: Henrik and I are currently not doing any work on the New Look project below, mostly because there is a new alternateLook preference which is being worked on by Squeak Central, which is a step toward what we were working on. (The New Look project below was never actually started as a coding effort, beyond the original individual looks we came up with.) We may try to incorporate some of our New Look into the current alternateLook of Squeak, by submitting changes to SqC in small increments. - Doug Way

This is the page for coordinating the New Look project, which is meant to merge the previous work of Doug Way and Henrik Gedenryd, and have preferences enough to satisfy almost any hardware and taste.

Doug's stuff : Picture Download (for 3.1alpha): http://www.mindspring.com/~dway/smalltalk/squeakchangesets/NewLook1-3848.1.cs

Henrik's: Pictures Menus Edit window Resize dot Translucency. HowTo: http://squeak.cs.uiuc.edu/mail/squeak/msg04552.html NB: This is for 2.8 or so.

Discussion:

What image level should we be targetting? In lack of a public Stable image, I think we go for the current one (3.1-3910) and adapt it to Stable later. HG
- That's pretty much what I was thinking... sounds good. I assume the goal is to have something with broad appeal and flexible enough so that it will be incorporated into the base image (and relatively soon, so that we won't need to maintain the changes over a long period). -DW
- OK, settled. HG
We need a standard coding pattern for all the places where code is affected and there will be multiple alternatives (like, yours and mine :-).
- Hmm, yes I guess so. Probably something beyond just checking if a preference is true or false? Maybe we could discuss examples as they come up. -DW
- I was thinking of e.g. standardized names for methods that do the work for each alternative, perhaps other things. HG

Some general requirements:

Color depth
- The New Look will be mostly geared toward looking good in 16 and 32-bit depth mode, but it should still look decent in 8-bit depth mode, and should also look reasonable in 1-bit depth mode. (I don't think we should spend any extra effort on 2-bit or 4-bit depth... they can simply default to whatever 1-bit does. Someone else can always tweak these modes to look better after we're finished.) -DW

Discussion/list of features:

Window colors
- 2 Options: Multicolored (DW's scheme), or blue titlebar, white contents (HG's)
  - Sounds good. White with blue titlebars could be the default non-multicolored scheme. (We might also let people pick their own (non-multicolored) window (and titlebar) color scheme, in the Window Colors dialog, perhaps.) -DW
- Scroll bars: DW you need to decide about yours, mine are white/xlucent color-coordinated with selection color. HG
  - I think I may make mine basically the same as yours... possibly a mix of white and the background color for a given window. (I need to try it out first and see.) The only change I might make to yours would be to make the scrollbar thumb a hair darker/deeper... it was almost too hard to see. -DW
  - Perhaps a darker thumb. My LCD makes some things look very different from CRTs, esp. very light shades. HG
Window title bar: (my comments – HG)
- This is the title bar that I experimented with. (Just a proposal for discussion– I wasn't totally happy myself.)
- I think close button should be on the left, and both menu and collapse buttons on the right.
  - Sure, why not. :) (You can also argue that it's good not to have a menu button too close to a close button, so that one doesn't accidentally hit close instead of the menu button.) -DW
  - That was the reason I had in mind. HG
- I was unhappy with the meaningfulness of the icons. I tried a horizontal bar (a "minus") for collapse to suggest the format of the collapsed window.
  - They're not bad. The square is okay... I had a highlighted X shape for the close box which may be more recognizable, but was perhaps a bit busy. For the collapse icon, I think my circle looks a bit nicer (it should probably be bigger, actually)... hmm, I kind of like the idea of the three icons being three simple shapes: a square, triangle and circle. (The circle is reminiscent of the current "O" shape, for whatever that's worth.) On the other hand, the "minus" sign is probably more meaningful, I was considering that shape myself. -DW
  - Right, the X becomes a bit busy with a 3d effect. I think that was the reason, I don't quite remember. The circle has a bit of a problem with 3d too, I think, but for small circles that usually depends a lot on the exact pixel diameter you choose, so perhaps it can be made to look really good. HG
- The menu just holds an arbitrary collection of functionality. No easy meaningfulness there. However I think this icon should be smaller than the others to mark its relative insignificance.
  - Actually, the down-pointing triangle is somewhat well-recognized as a pull-down menu icon, so that may be good. (it could be made smaller) -DW
  - Definitely a little smaller. HG
- Don't inset icons look better than raised ones in the title bar (which is raised itself)? Note that the triangle is raised, that was a bug iirc.
  - I think I agree with you on this (since the titlebar is already raised). I hadn't tried inset icons yet. (Are your icons PolygonMorphs? I tweaked the border-highlighting code in PolygonMorph so that I could use them for my shapes, rather than some kind of bitmap.) -DW
  - The triangle is a Polygon, the others plain Rects. The Polygon's inset was broken IIRC, if your fix does it, then that's great. HG
  - What about a raised title bar with a inset a few pixels wider and higher than the button and then a button raised in the inset ( looking kind of like the mac titlebar) ? Karl
    - Not bad, although there isn't currently a BorderedMorph border style which supports this look. (And I'd sort of prefer to keep things in the spirit of Squeak by having Squeak draw these icons, not have them be pre-rendered forms.) Look-wise, I like this border style about the same as the simple inset one above... I could go either way. -DW
    - You can make it by using two morphs instead of one: first a inset one in the titlebar, then a raised one as the button. Karl
Menus: I take it my menus are to be "it", then. HG
- I think so. (I'll have to try them with multi-colored windows a bit.) -DW
My resize dot? (With non-tranlucent option of course.) HG
- Sure, looks nice. :) -DW
Selection color: Mine is color-coordinated. What about yours? HG
- Haven't worked on it too much yet. At one point I tried switching it to match the darker titlebar color I had, and it looked suprisingly ugly, so I went back to the way it was. -DW
- OK, the current "radioactive green" is a little... intense. HG
Font: Should we change the default font? IMHO it should be a sans font. There are the Exobox ones, plus I can generate ones with FreeType. A smoothened Helvetica may be nice (GNU–no license probs), or Univers like I use (License should not really be a prob with bitmap font but you never know.). HG
- By smoothened do you mean antialiased? If so, absolutely, we should use an antialiased font as a default (and still make non-antialiased fonts available, of course). -DW
- antialiased, yes. I just remembered that AA doesn't support colored text and synthetic underlines etc. So I think we'll have to wait with using that for default, eg. diffing & boldened method headers should really work. Gives an incentive for someone to fix those things... HG
- Maybe we should try to get an antialiased font or two added as alternate fonts (in the system fonts menu) as part of the New Look, if not the default font. That will give people more incentive to make the final fixes needed. (Is there a separate plugin that is still needed to display AA fonts, or is all the necessary support in the base image now? I know there was a new BitBlt mode added...) -DW
- No, just a couple of change sets that allow fonts to have Forms deeper than 1 bit, plus some changes in various places to use this correctly. Once the plugin and all is there, I don't think it is unreasonable to get these into the image. HG
Window shadows: I have that, Bob previously offered to look at the damage stuff. A pref of course. HG
- Sounds good. -DW

A few other issues:

Background color: I think a darker background color would be nice as a default, instead of off-white, especially if we have whitish menus. (Upon further thought, the current menuColorFromBackground setting doesn't really make that much sense.) Maybe something like the blueish background color you had. -DW
- Mm, it is probably no icident that most systems have a darker default. Like someone on the list said, contrast is good. HG
Rounded corners: Should probably make sure they at least work and look good with both window looks and menus. Maybe we'll want to have them off by default, I'm not sure. -DW
- RC's are implemented in such a hacky way. I haven't even tried to touch that code even though it looks ugly with the blue look, it just seemed too strange for me. But they are probably essential to clearing this with SqC ;-) Perhaps the one who did them can lend a hand, unless you're up to it of course. HG
Raised and inset borders: I noticed you used #inset borders for the window panes... I think I will try that with my look, too (mine are currently #raised). (I think we should remove as many gratuitous differences as possible between our two looks.) Also, as part of my earlier changeset, I changed the Color class>>twiceLighter and twiceDarker methods, so that they use a more appropriate algorithm (which is reversible). The new algorithm is similar to dansDarker in the baseImage... it looks better, and the performance is roughly the same as the old methods. We may want to similarly improve the other darker/lighter/muchDarker/etc methods in the base image as part of this. -DW
- gratuitous differences: That might be an idea. My rational was that buttons are raised to afford pushing, while lists and text panes are lowered, I believe this is the convention elsewhere too. I actually have 2 pixels around the text panes etc., the outer is raised and the inner lowered, to simulate a raised edge. HG
  - Sounds like a good rationale. (Unfortunately, this does sort of go against your inset titlebar buttons. :) ) -DW
- color tweaks: I also have some tweaks here. One is to refactor BorderedMorphs to make the code nicer (but perhaps a couple of sends slower, does it matter btw?), another to fix things so e.g. black and white gets both of the raised and lowered border colors different fromn white and black (otherwise they appear to be "invisible"). We should probably combine these. HG

List of proposed additional features:

Left-aligned, more informative window headers: smarterwindowlabels-hg1Jul1929.cs.gz
- Things like browsed class & method in browsers, path name in file list. HG
Less annoying borders around edited, non-saved text panes. This changes the color and removes the indicator completely from panes where you can't save the text anyway, like inspectors. noredline-hg.01Jul1922.cs.gz HG
- These additional features generally sound good. (I'm neutral on whether titlebar text should be center of left-aligned.) -DW
- Yeah, it's that they really become necessary with the more informative window titles, since these are sometimes based on window contents/state eg. in browsers. When a centered text changes it yields a very odd "jumping" effect. HG
- Sounds good... we can try left-aligned as the default. -DW