Hi Stef,

hi diego

I was wondering if you do the widget one by one? Is it correct?

More or less It's true. I'm using the changes I made all the day and I decide where to put my hands based on my own feelings about the interface. The "old" FillInTheBlankMorph is too flat for the current squeak look.

Have you tried to see if you could take an existing UI Builder and plug in your style. This way we could have it for all the widget. I know this is another kind of work.

I'm not creating new widget but modifying the existing ones.

Have you discussed with todd he is building a new way to layout morph (following nextStep)?

Not yet... Tood, are you there?

Stef

Cheers,

Diego

On Tuesday 29 April 2003 01:07 pm, Karl Ramberg wrote:

...

PS: What is the next part to change the look?

I always thought the progress bar for filing in stuff/ re compiling could need a loving hand.

Bob did a better looking one of those, as I recall. I believe that at least one of those isn't actually a Morph, it's just something drawing on the Display. Hence the refresh problems, etc.

What's probably needed is to make all such uses use the ProgressMorph instead.

Hi!

tblanchard@mac.com wrote:

I'm getting a walkback when doing an initial load of SqueakMap (by selecting open...Package Loader from the world menu). Apparently a card is missing or something? The first line cardWithId returns nil and I end up with a partially loaded SqueakMap.

Hmmm, I think there is a bug somewhere (but I haven't had time to find it yet) in SM but you can easily avoid it (I think/hope) by removing the "sm" directory (and its files) and then trying again. This will force a full load from the net, but it isn't very large anyway.

regards, Göran

Hi diego

The problem is that while you will be doing that you will be linking Morph to classes that would not rely on morph but just DisplayScreen.

I would not do this change. I imagine that we should find a much clever way of notifying user. Avi suggested to me that we could have exception that would be caught and letting the used decide if he wants to put a UI or not for headless image for examples.

I do not know if this is reasonable to do that but substituing the old bar with a ProgressMorph is not a good solution. Ask the people who want to have tiny images....

I think that we should remove the unnecessary dependency between unrelated parts of Squeak. So mya be we should introduce an architecture where one object is responsible of the look and feel and that can be changed to put morph or displayScreen objects

Stef

On Wednesday, April 30, 2003, at 12:29 PM, diegogomezdeck@consultar.com wrote:

Hi Karl,

...

I always thought the progress bar for filing in stuff/ re compiling could need a loving hand.

It currently means 2 task:

1. Use ProgressMorph in all the places that make sense
2. Change the ProgressMorph look

I'll made both.

...

Karl

Diego

Prof. Dr. Stéphane DUCASSE http://www.iam.unibe.ch/~ducasse/ "if you knew today was your last day on earth, what would you do different? ... especially if, by doing something different, today might not be your last day on earth" Calvin&Hobbes

"The best way to predict the future is to invent it..." Alan Kay.

Open Source Smalltalks: http://www.squeak.org, http://www.gnu.org/software/smalltalk/smalltalk.html Free books for Universities at http://www.esug.org/sponsoring/promotionProgram.html Free Online Book at http://www.iam.unibe.ch/~ducasse/WebPages/FreeBooks.html

Prof. Dr. Stéphane DUCASSE http://www.iam.unibe.ch/~ducasse/ "if you knew today was your last day on earth, what would you do different? ... especially if, by doing something different, today might not be your last day on earth" Calvin&Hobbes

"The best way to predict the future is to invent it..." Alan Kay.

Open Source Smalltalks: http://www.squeak.org, http://www.gnu.org/software/smalltalk/smalltalk.html Free books for Universities at http://www.esug.org/sponsoring/promotionProgram.html Free Online Book at http://www.iam.unibe.ch/~ducasse/WebPages/FreeBooks.html

Hi Tim and Stef,

Stephane Ducasse ducasse@iam.unibe.ch wrote:

...

The problem is that while you will be doing that you will be linking Morph to classes that would not rely on morph but just DisplayScreen.

Actually Diego would be simply maintaining the current system rather than changing it; though it wuld look a lot nicer after his work!

You are rigth. I'll change only the look of the existing system.

...

I would not do this change. I imagine that we should find a much clever way of notifying user. Avi suggested to me that we could have exception that would be caught and letting the used decide if he wants to put a UI or not for headless image for examples.

So far as I can tell to seems that the mechanism I suggested for the filing out of pooldicts stuff would work quite reasonably. I still want someone to suggest a better name than 'UIDefaultYesNotification' though! A more carefully thought out way to include some information with the exception would be useful; my hack just (ab)uses the messageText. Did anyone have any thoughts on the changeset I proposed (called FileOutUIRemove.1.cs) ?

The key item to separate progress notification from needing the UI classes is to change the defaultAction to do nothing rather than display the progress bar (well, modulo the stuff to make sure the block runs etc). Then one has to find all the place where the exception could need to be handled (which is actually pretty tricky and tedious - tools would be good here) and handle it the right way.

This solution is ok for me only if we need to hock diferents handlers in the same context.

On the other side, if we want to change the "notifiers" only per image (or per project) a global named Notifier (or something like that) holding an implementation of AbstractNofifier (MorphicNotifier, MVCNotifier, StOutNotifier, etc) is enough and more clear to see.

These notifier classes will answer to #notify:, #confirm:, #confirm:options:, etc type of messages.

tim

Cheers,

Diego Gomez Deck

Avi Bryant wrote:

No, per project/image is not enough. One image can be used simultaneously from multiple UIs at the same time. For example, I'm often using at least two of these at once:

• REPL command line
• Web UI
• Morphic UI

Having the Web or REPL UI lock up because Morphic is presenting a FillInTheBlankMorph is really annoying.

The only way to do it right is per process, and the cleanest way to do that is probably to do exactly what Tim suggests, which is to have a Notification subclass signalled for each type of user interaction - #inform:, #confirm:, progress, etc.

I actually think we should go further with this, and have at least Sensor and Display be per process as well.

This is exactly what I wish someone would do with DynamicBindings (as I've said a few times before)...it wouldn't take much work at all. I should also mention that DynamicBindings owes much of it's design to input from Avi and Anthony Hannan on this list. DynamicBindings really just builds on the exception handling mechanism and facilitates propogating variable bindings when forking processes. I've recently been using the following convention for accessing dynamic bindings (shown using Sensor as an example):

EventSensor class>>current ^ #'EventSensor.current' binding

EventSensor class>>current: anEventSensor #'EventSensor.current' binding: anEventSensor

In this example, rather than refer to the global 'Sensor', you would use 'EventSensor current'. The io process might look something like:

EventSensor>>ioProcess "Run the i/o process" | eventBuffer type | EventSensor current: self. eventBuffer _ Array new: 8. [true] whileTrue:[ [self primGetNextEvent: eventBuffer. type _ eventBuffer at: 1. type = EventTypeNone] whileFalse:[self processEvent: eventBuffer]. inputSemaphore waitTimeoutMSecs: EventPollFrequency. ].

Combined with Colin's native-Squeak VNC server, for example, this could lead to some very cool possibilities.

Yes, indeed.

- Stephen