Here's some more window frame code. This is just some simple mockups with three different window types; a browser, a file list and a workspace. It's at:
http://people.we.mediaone.net/trade/Zurgle/Mock.htm
You can file in the code and play with the window and their resizing bits. This is just an exploration of what the window resizing interactions might look like. Take a look, see what you think.
Note that I just gathered threw some buttons together , and this isn't serious attempt at getting a frame look just right. However, I'm at a point where it would be nice to hear some suggestions as to what a 'stock' frame might look like. I need to come up with a 'default theme'.
One area I'm pretty confused about is what the menu icon should look like and how to interact with it. As it stands now, the current menu doesn't seem to interact in a very natural way. My initial feeling is that it needs to be more of a pulldown menu, rather than just popping up over the menu icon.
This is just experimental code. Use it in a throw away image. I'm not really looking for any bug reports yet, but if something glaring comes up feel free to mention it.
Next up, refactoring SystemWindow to refactor the frame elements into another class.
Jim
Jim Benson wrote:
You can file in the code and play with the window and their resizing bits. This is just an exploration of what the window resizing interactions might look like. Take a look, see what you think.
Well, I like it!
Note that I just gathered threw some buttons together , and this isn't serious attempt at getting a frame look just right. However, I'm at a point where it would be nice to hear some suggestions as to what a 'stock' frame might look like. I need to come up with a 'default theme'.
Just go with what you are using now. It doesn't burn in the eyes, so it's all right ;-)
One area I'm pretty confused about is what the menu icon should look like and how to interact with it. As it stands now, the current menu doesn't seem to interact in a very natural way. My initial feeling is that it needs to be more of a pulldown menu, rather than just popping up over the menu icon.
I don't understand. Can you explain that? Alternatively, I suggest to drop the icon altogether and bring up the menu when you do a right (that's what confuses *me*, those colored buttons) click on the frame (like a context menu in windows).
Joern
Alternatively, I suggest to drop the icon altogether and bring up the menu when you do a right (that's what confuses *me*, those colored buttons) click on the frame (like a context menu in windows).<<<
I agree--within morphic, we already have context menus and halos. Let's use those, instead of having menu icons and menu bars. They're better, anyway.
While we're at it, let's get rid of resize handles, too. I have trouble clicking them when I want, yet I seem to click them all the time when I don't mean to. Instead, I'd rather a SystemWindow's panes are real morphs. Then, I can resize a SW pane the same way I'd resize any other morph: blue-click then use the yellow handle.
BTW, on Linux blue-click is right-click, on Windows it is middle-click, and on Macs it is apple-click. That's why people say "blue-click" instead of "middle-click". Also, many lefty's reverse their mouse button orders, anyway....
-Lex
I agree--within morphic, we already have context menus and halos. Let's use those, instead of having menu icons and menu bars. They're better, anyway.
I think a menu bar is a very good UI concept...but you're right, they should be part of the same framework as context menus...a menu bar should be like a context menu that you've instructed to stay up. The menu can then have wordy items (like today), shortened one word items, just icons, or some combination of these (all of these things would be morphs of course, but the person designing the menu could decide how it should look in all of these states). You could even allow these menu bars to snap to the edges of a system window, or be contained within the borders of a system window.
While we're at it, let's get rid of resize handles, too. I have trouble clicking them when I want, yet I seem to click them all the time when I don't mean to. Instead, I'd rather a SystemWindow's panes are real morphs. Then, I can resize a SW pane the same way I'd resize any other morph: blue-click then use the yellow handle.
But they are real Morphs. The handles work just fine on system windows. I don't think that's a good reason against some morphs having more convenient ways of resizing. I would prefer not to have to pull up the halo just to resize a system window. (but I agree that those resize balls must be banished)
BTW, on Linux blue-click is right-click, on Windows it is middle-click, and on Macs it is apple-click. That's why people say "blue-click" instead of "middle-click". Also, many lefty's reverse their mouse button orders, anyway....
The complaint is none the less valid. It would be nice if there was a mouse configuration tool on the desktop of the base image that would associate the colors with the actions (I can never remember which is which without diving into the code, or someone reminding me).
- Stephen
On Tuesday 31 July 2001 01:57 pm, you wrote:
While we're at it, let's get rid of resize handles, too. I have trouble clicking them when I want, yet I seem to click them all the time when I don't mean to. Instead, I'd rather a SystemWindow's panes are real morphs. Then, I can resize a SW pane the same way I'd resize any other morph: blue-click then use the yellow handle.
Absolutely. The handles don't work at all on pen-based systems; they depend on mouse-over detection!
BTW, on Linux blue-click is right-click,
Unless you've fixed it like I have (a couple of times).
on Windows it is middle-click
Unless you've fixed it by choosing "two button mapping".
Ned Konz wrote:
While we're at it, let's get rid of resize handles, too. I have trouble clicking them when I want, yet I seem to click them all the time when I don't mean to. Instead, I'd rather a SystemWindow's panes are real morphs. Then, I can resize a SW pane the same way I'd resize any other morph: blue-click then use the yellow handle.
Absolutely. The handles don't work at all on pen-based systems; they depend on mouse-over detection!
One aspect of this window frames project is that it will make the resizing frame/handles easier to grab in pen-based systems. It should be possible to configure it to use different thicknesses of frames, too, to accommodate different screen resolutions and such.
One problem with using halos for resizing is that they're totally inappropriate for many deliverable applications. They're also more inconvenient, requiring at least one additional UI gesture. I agree that it would be nice to be able to use them for resizing window subpanes, but (a) I think that would be tricky to implement, and (b) it would be especially annoying to have to drill through many submorph layers just to be able to resize a pane. (Look at a browser's code pane. Do you resize the AlignmentMorph, or the PluggableTextMorph? Since you can only resize at the bottom right-hand corner, what effect would this even have?) So morphic halos as the *only* resizing option would be, IMO, a UI disaster.
Perhaps what is needed to make the UI easier for pen-based systems is instead a new PenHand which maintains its own button state, toggling it based on the penUp/penDown cues from the raw event stream.
-Jesse
How can my morph receive keyboard events even when the mouse pointer is not hovering above this morph? I defined handlesKeyboard: ^true and now keyStroke: gets invoked only when the mouse pointer is over my morph...
Anyyway, is ther some detailed documentation about this stuff? There is almost nothing in the sources and I tried browsing the swiki but found nothing about input events.....
Frantisek Fuka wrote:
How can my morph receive keyboard events even when the mouse pointer is not hovering above this morph? I defined handlesKeyboard: ^true and now keyStroke: gets invoked only when the mouse pointer is over my morph...
I think the problem is probably that your morph isn't requesting the keyboard focus. If you request the keyboard focus on mouseEnter or mouseDown (see, eg, PluggableTextMorph>>mouseEnter and TextMorph>>mouseDown:), and don't let go of it on mouseLeave (see PluggableTextMorph>>mouseLeave), you should be happier with the results.
Anyyway, is ther some detailed documentation about this stuff? There is almost nothing in the sources and I tried browsing the swiki but found nothing about input events.....
I don't think there is any good documentation of Morphic event handling, and it is tricky to trace it out in the source because the logic can be somewhat convoluted. It really helps to be able to trace it forward and backward using 'implementors of' and 'senders of'; and look especially at HandMorph, in this case the 'event handling' and 'focus handling' categories.
Ignore the following if it pushes you to overload.
It took me a little while to figure out why, without asking for the focus, you would be able to receive keyboard events at all. Tracing forward from HandMorph>>HandleEvent: and sendKeyboardEvent:, one finds that if the hand does not have any focus, it sends processEvent: to its owner. This trickles down to MorphicEventDispatcher>>dispatchDefault:with:, which dispatches the event to the topmost submorph of the world containing the event's position.
So an alternative for the future might be to make an application-specific PasteUpMorph (ie, world) subclass which sends all unfocused events to your primary morph of interest. But that's probably crazy; it's probably better just to make sure you always have a sensible focus set.
-Jesse
I seem to have lost the ability to resize a book morph, whether one that I create or one created in another project. The same thing happens with a clean copy of Squeak. The yellow halo moves, but snaps back as the morph does not resize.
Anybody else experiencing this?
Squeak 3.1 alpha #4022.
--
R. Kenyon
|T|h|i|n|k|L|i|n|k: http://www.riverwoodpub.com/educatio.htm Not everything is black & white: some things have to be read.
The BookMorph has a nonintuitive feature (which we should fix) that a resize of the BM as whole does nothing, it is only when you cmd-click once again to get the page that you can resize. This is probably the difficulty (and I apologize in advance if this is so). It *is* useful to have pages of different size, and there *is* a menu item that will make all pages the size of a given page ........
Cheers,
Alan
----
At 10:39 AM -0400 8/1/01, Roger Kenyon wrote:
I seem to have lost the ability to resize a book morph, whether one that I create or one created in another project. The same thing happens with a clean copy of Squeak. The yellow halo moves, but snaps back as the morph does not resize.
Anybody else experiencing this?
Squeak 3.1 alpha #4022.
--
R. Kenyon
|T|h|i|n|k|L|i|n|k: http://www.riverwoodpub.com/educatio.htm Not everything is black & white: some things have to be read.
Perhaps some of you know of other articles in this series.
While building up a bit of a personal database on learning Smalltalk, I came across Peskin and Walther, "Learning Smalltalk by Examples" in MacTech.
http: //www.mactech.com/articles/mactech/Vol.10/10.10/LearningSmalltalk/
The article opens with: "This is the first in a series of articles aimed at those who want to learn something about programming in Smalltalk." That would be me alright. Unfortunately, I cannot find any subsequent articles -- probably because of the difficulty accessing the mactech database.
Does anybody know of subsequent articles in this series?
--
R. Kenyon
|T|h|i|n|k|L|i|n|k: http://www.riverwoodpub.com/educatio.htm Not everything is black & white: some things have to be read.
Roger Kenyon wrote:
Perhaps some of you know of other articles in this series.
While building up a bit of a personal database on learning Smalltalk, I came across Peskin and Walther, "Learning Smalltalk by Examples" in MacTech.
http: //www.mactech.com/articles/mactech/Vol.10/10.10/LearningSmalltalk/
The article opens with: "This is the first in a series of articles aimed at those who want to learn something about programming in Smalltalk." That would be me alright. Unfortunately, I cannot find any subsequent articles -- probably because of the difficulty accessing the mactech database.
Does anybody know of subsequent articles in this series?
I can't even access mactech.com.
I found this tutorial good for getting the hang of it: http://kaka.cosc.canterbury.ac.nz/~wolfgang/cosc205/STtutorial/index.html
Karl
There are 5 PDF modules for a decent introduction to Smalltalk at: ftp://ftp.cs.uni-magdeburg.de/pub/Smalltalk/Smalltalk/Squeak/docs/BHoran/
These might have been part of a textbook, but I am not sure.
I found this tutorial good for getting the hang of it: http://kaka.cosc.canterbury.ac.nz/~wolfgang/cosc205/STtutorial/index.html
Karl
--
R. Kenyon
|T|h|i|n|k|L|i|n|k: http://www.riverwoodpub.com/educatio.htm Not everything is black & white: some things have to be read.
Frantisek Fuka fuxoft@terminal.cz wrote:
How can my morph receive keyboard events even when the mouse pointer is not hovering above this morph? I defined handlesKeyboard: ^true and now keyStroke: gets invoked only when the mouse pointer is over my morph...
Anyyway, is ther some detailed documentation about this stuff? There is almost nothing in the sources and I tried browsing the swiki but found nothing about input events.....
Ah, I didn't know you could ever get automatic keyboard events. Are you sure you didn't implement a mouseEnter: as well, while you were sleepwalking or something? :) Anyway, you can explicitly grab the focus with code like this:
someHand newKeyboardFocus: myMorph
(One way to access a hand is "World currentHand".) I haven't tested it, but this ought to work regardless of where the mouse is. Just be aware that as the mouse moves around, any other morph might grab the focus back -- there is only one morph at a time with keyboard focus.
By the way, I've written a short tutorial on morphic basics in the "Learning Morphic" project on Bob's Superswiki. It's not detailed, but it gets you through the basic steps. Actually, I'm not sure that *detailed* is very useful, anyway, because once you have the general ideas, you can look directly in the code. In there, I give about a 5-step process for getting keyboard events, because I wasn't aware of a way to get them directly.
More generally, check out the "Morphic" page on the Swiki if you haven't already. I cleaned it up a bit recently, and it should be more approachable now.
Lex
On Tue, Jul 31, 2001 at 04:29:04PM -0500, Lex Spoon wrote:
Alternatively, I suggest to drop the icon altogether and bring up the menu when you do a right (that's what confuses *me*, those colored buttons) click on the frame (like a context menu in windows).<<<
I agree--within morphic, we already have context menus and halos. Let's use those, instead of having menu icons and menu bars. They're better, anyway.
While we're at it, let's get rid of resize handles, too. I have trouble clicking them when I want, yet I seem to click them all the time when I don't mean to. Instead, I'd rather a SystemWindow's panes are real morphs. Then, I can resize a SW pane the same way I'd resize any other morph: blue-click then use the yellow handle.
BTW, on Linux blue-click is right-click, on Windows it is middle-click, and on Macs it is apple-click. That's why people say "blue-click" instead of "middle-click". Also, many lefty's reverse their mouse button orders, anyway....
The Windows VM now allows you to select whether you have a 1, 2, or 3 button mouse. You just have to press F2 to bring up the menu. (if that doesn't work, try other F-keys in the vicinity; I'm in Linux right now).
Joshua
-Lex
squeak-dev@lists.squeakfoundation.org
-
Alan Kay -
Frantisek Fuka -
Jesse Welton -
Jim Benson -
Joern Eyrich -
Joshua 'Schwa' Gargus -
Karl Ramberg -
Lex Spoon -
Ned Konz -
Roger Kenyon -
Stephen Pair