Attached is a changeset containing some of the X11R6 75dpi fonts, converted from BDF format. They haven't been tweaked yet. They appear to be quite license-clean. I think someone should stare at the Lucida copyright information to confirm this. In any case, they don't infect your image.
Thanks to Andrew Greenberg for a) pointing out that FontSets work and b) providing text for reuse. :-)
By the way, if you want to ship FontSets through changesets, it looks like the best thing to do is change FontSet class>>acceptsLoggingOfCompilation to always return true while you're packaging.
"Change Set: BDFFontSets-nop Date: 31 January 2000 Author: Jay Carlson
Squeak fonts converted from fonts in BDF format distributed with X11R6.3.
This fileIn installs several FontSets converted from some of the 75dpi Bitmap Distribution Format fonts shipped with X11R6.3. The fonts were downloaded and converted to StrikeFont .sf2 format with the BDFFontReader changeset. Their copyright information is included in the class comment for each FontSet.
On fileIn, the postscript installs these FontSets as Squeak TextStyles, and thus may be selected by using control-K in any text window.
These fonts currently have an underbar instead of a left arrow for the _ character. Also, this changeset only contains basal emphasis. These X11 fonts were designed for use with hand-tuned bold and italic/oblique companions (not included), so Squeak's automatically-derived bold and italic attributes will not look good. Bold emphasis looks somewhat better with the application of the StrikeFontBoldFix changeset. "
Jay
When I try to execute this code in a Workspace, I obtain a MVC white window with a lightYellow subView on the right. But when I minimize the window and then restore it, all the area of the topView (white) is occupied by the subView (lightYellow). Could anyboby tell me, what I'm doing wrong. Thanks in advance.
Francisco.
| aTopView aSubView | aTopView := StandardSystemView new. aTopView window: ( 0 @ 0 extent: 100 @ 100 ); insideColor: Color white; borderWidth: 2; label: ' TopView '. aSubView := View new. aSubView insideColor: Color lightYellow; borderWidth: 1. aTopView addSubView: aSubView window: (0 @ 0 extent: 100 @ 100 ) viewport: ( 50 @ 0 extent: 50 @ 100). aTopView controller open
Francisco -
I don't think you are doing anything wrong. Without getting into the code, it seems that the expand-after-collapse code for MVC views does not deal properly with blank areas. I suggest you put a blank view to the left of the one you care about (3 added lines), since the following code seems to work properly...
| aTopView aSubView | aTopView := StandardSystemView new. aTopView window: ( 0 @ 0 extent: 100 @ 100 ); insideColor: Color blue; borderWidth: 2; label: ' TopView '.
aTopView addSubView: View new window: (0 @ 0 extent: 100 @ 100 ) viewport: ( 0 @ 0 extent: 50 @ 100).
aSubView := View new. aSubView insideColor: Color lightYellow; borderWidth: 1. aTopView addSubView: aSubView window: (0 @ 0 extent: 100 @ 100 ) viewport: ( 50 @ 0 extent: 50 @ 100). aTopView controller open
Hope this helps.
- Dan
PS: If you are interested in actually solving the problem, it is caused by the fact that, when the view gets re-expanded, it calls getViewport which calls getWindow which calls defaultWindow which merges all the view rectangles. In your case this made the window simply be the area of your subview instead of the whole window. It's possible that the code could instead use the reframed (exapanded) rectangle of the StandardSystemView. ---------------------------
When I try to execute this code in a Workspace, I obtain a MVC white window with a lightYellow subView on the right. But when I minimize the window and then restore it, all the area of the topView (white) is occupied by the subView (lightYellow). Could anyboby tell me, what I'm doing wrong. Thanks in advance.
Francisco.
| aTopView aSubView | aTopView := StandardSystemView new. aTopView window: ( 0 @ 0 extent: 100 @ 100 ); insideColor: Color white; borderWidth: 2; label: ' TopView '. aSubView := View new. aSubView insideColor: Color lightYellow; borderWidth: 1. aTopView addSubView: aSubView window: (0 @ 0 extent: 100 @ 100 ) viewport: ( 50 @ 0 extent: 50 @ 100). aTopView controller open
Hi all,
Inspired by a look at the MacOS X dialogs which are attached to windows, not free-floating, I hacked up a quick changeset as a GUI experiment.
What it does is overload the #confirm: #inform: and #confirm:orCancel messages when sent to Morphs so that instead of a free-floating menu popping up near the hand a dialog pops up covering the morph.
This seems to have a few good effects:
(1) It becomes very apparent which confirmations are system modal, which are only modal at a SystemWindow level, and which are modal at a morph level. Thus when trying to close a SystemWindow with unsaved changes, I am not locked out of the rest of the system while trying to decide whether to continue; on the other hand when quitting the image without saving the dialog covers the whole screen, making it pretty obvious that I have to answer the question!
(2) I think it looks pretty funky.
Please save your image before filing this in, as it has had little testing! I am using a 2.8a image with all updates. The three gifs will need to be in the image directory.
What do people think? Is this a massive retrograde step? Is it better then the current system?
:) Russell
---------------------------------------- Russell Allen
russell.allen@firebirdmedia.com
----------------------------------------
On Tue, 16 May 2000, Russell Allen wrote:
What it does is overload the #confirm: #inform: and #confirm:orCancel messages when sent to Morphs so that instead of a free-floating menu popping up near the hand a dialog pops up covering the morph.
I like it. Some comments though: - You should not be using ImageImports but the ScriptingSystem's form dictionary. This is the place were permanent forms live (radio buttons, halo icons, etc.) Maybe this should be moved to a more obvious place? - It doesn't work well with bookmorphs. Try deleting a page ... - Some places use "Menu confirm:" instead of "self confirm:". - It'd be nice if you'd send Base64 encoded attachments
-- Bert
squeak-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Dan Ingalls -
Francisco A. Lizarralde -
Jay Carlson -
Russell Allen