OT: Dolphin smalltalk giving up

> Some of us are already here.  I cannot speak for the others, but I have
> long viewed Squeak as one possible escape plan from Windows, and to a
> lesser extent from disappearance of Dolphin.  To be blunt, I am still
> worried in that order, though that would change over time if Dolphin
> indeed becomes unsupported.
>
> >From a developer's perspective, it is a tough transition.  I can work in
> Squeak, but it is a bitter pill compared to Dolphin.  From an end-user's
> perspective, I fear that Squeak out of the box would cause mutiny.  As I
> have always said, the GUI feel the problem.  I deal with busy users in
> sometimes dire circumstances.  They cannot be expected to remember
> whether they have previously opened a dialog (modality can be a good
> thing).  I think I would be able to design and build around some of the
> limitations.
>
> Tweak scares me a bit.  The capability is fine (even great), but I have
> reservations about dragging the compiler into it.  I would much rather
> see a higher level GUI editor that uses a time-aware variant of a
> traditional event system for routing.  While I am no big fan of native
> widgets, I would probably opt for something like wxSqueak to force the
> point.
>
> ANSI compatibility, or at least friendliness would be a barrier.  My
> favourite example is
> the behaviour of #next, #next:, which "silently" answer nil or truncate.
>  I think these basic reading methods should raise an error on end of
> stream, with truncating variants (#nextOrNil, #nextAvailable:) allowing
> one to be more relaxed.  I do a lot of parsing that needs to be right,
> and "want my bad news early" vs. having something blow up later with no
> clear indication of what went wrong, or worse yet, after incorrect
> results have been obtained.  I could move to my own selectors, but I
> worry about "reverting" and not getting the behaviour I expect.
>
> Underscores.  I have a lot of code that uses them.  Sorry.  I talk to
> databases that use them in field name, and field names make good choices
> for selectors.  Lots of class names too, again thanks to external
> sources.
>
> I am glad to see that Andreas fixed some critical threading bugs.  I am
> somewhat surprised that it took so long for them to surface.  How does
> one square that with the popularity of Swikis and other server uses of
> Squeak?  I would have thought they would stress the VM enough to show
> such bugs, but they apparently did not, or worse yet, the community
> largely ignored the problems???  Insights would be appreciated.

> I am not sure how to copy with the loss(??) of Dolphin's overlapped
> threads.  For those not familiar with them, Dolphin provides a way to
> mark external functions to be called on a separate OS thread such that
> only the calling Smalltalk Process is blocked.  With a really good SSL
> Socket implementation, I should be able to wean from them.  By really
> good, I mean that the image cannot hang when a network wire is pulled or
> a machine or DNS entry does not exist.  The calling process should
> block, but not the entire image.
>
> Another thing that scares me a bit is printing.  I simply have not
> investigated it in Squeak, but will need to do so.
>
> That's one Dolphin user's perspective.
>
> Bill
>
>
>
>
> Igor Stasenko wrote:
>
> Hopefully, some people will join a squeak community.
>
> On 11/08/07, Chris Kassopulo <ckasso@...> wrote:
> > http://www.object-arts.com/content/blog/2007Aug10.html
>
>
>
>
> Wilhelm K. Schwab, Ph.D.
> University of Florida
> Department of Anesthesiology
> PO Box 100254
> Gainesville, FL 32610-0254
>
> Email: [hidden email]
> Tel: (352) 846-1285
> FAX: (352) 392-7029
>
>
>

> Matthew,
>
> Fair enough.  I am mostly thinking of my users.  Suppose I display a
> menu, they click in one of the magic spots, and instead of doing
> something or nothing (which would cause a reflex to click again), it
> gets attached to the hand.  I can hear it now: the menu is "stuck to the
> mouse".  The file/directory picking "dialogs" are not really that at
> all.  They are inconsistent, do not provide a clear way to show/hide
> hidden files (at least on Linux).  As long as Squeak has been in use, it
> seems that there should be a lot more polish in the interaction with the
> user.
>
> The behavior of input focus is a lot better than it once was, but it is
> still not consistent.  I hate to think about putting a clerk in front of
> Squeak-based form.  If they have to touch the mouse, the software is
> broken.  Why care what clerks think?  They enter data that can be turned
> into serious money, but one has to make life easy for them, or they find
> ways not to cooperate.  It can be hard enough when it is easy.  Squeak
> is starting to show some respect for tabbing, but it is again not
> consistent.  It might be far enough along that one could build something
> robust for end users.  For example, in a deployed app, one would not use
> a system window; the main window would be app's shell (MDI fans will see
> it differently of course), and an alignment morph would likely cover the
> entire world, with the widgets living inside it.  I have yet to actually
> do this, but I can imagine that it would hide many of the IDE's
> annoyances.
>
> One of my favorites is the method finder.  Especially with an optical
> mouse (the kind that moves the cursor even when still), one has to
> "balance" the cursor in the selector field, lest the focus fly off to
> some other widget.
>
> Workspace menus: the browse-it command should be on the first menu, near
> inspect, debug-it, and friends.  Many other ergonomic annoyances have
> been posted recently.
>
> The Linux vm will shutdown w/o warning.  It could do a better job with
> virtual keys.  Some of that is Linux culture, but I notice that other
> apps respond as expected to keypad vk messages.
>
> Again, it is mostly feel: how it reacts to keyboard and mouse input.  I
> am of the opinion that Microsoft is losing their collective grip on
> reality, but they did some really good usability testing - what, 20
> years ago??  Scary.  Much of what they learned watching "idiots"
> interact with computers has become widely adopted.  If I am giving them
> too much credit, I apologize, but there is a mechanical vocabulary of
> interaction with computers, with a fine line between being responsive
> and fragile.  I argue that Squeak as packaged is in the latter camp.
>
> Please note that I am trying to remove a barrier to use of Smalltalk.  I
> believe there is nothing one can do to make the masses leave the
> sharp-infested waters(TM) for the power and elegance of Smalltalk.
> However, we can help those who "get it" make their would-be users' life
> as easy as possible, making it just that much easier to apply Smalltalk.
>
> Bill
>
>
>
>
> Matthew Fulmer wrote:
>
> On Sat, Aug 11, 2007 at 04:20:21PM -0400, Bill Schwab wrote:
> > At the risk of becoming a broken record: my complaints about the
>
> Squeak
>
> > GUI are not about look, they are about feel. I can sell funny looking,
> > but I cannot sell clumsy.
>
> Squeak is easy to get used to, so we usually forget what makes
> it clumsy. The only things I can think of is using the Alt
> (rather than Ctrl) key for modifiers (on Linux and Windows), and
> the lack of support for one-click copy/paste (under X11). What
> else bothers you about it? We are not conspiring to make a
> clumsy user interface. I got used to the interface after 1 week
> and never saw it as clumsy.
>
> I want to know. Really. What don't you like?
>
>
> Wilhelm K. Schwab, Ph.D.
> University of Florida
> Department of Anesthesiology
> PO Box 100254
> Gainesville, FL 32610-0254
>
> Email: [hidden email]
> Tel: (352) 846-1285
> FAX: (352) 392-7029

> Bill,
>
> I generally agree with you that out-of-the-box, Squeak's feel (and look)
> are different than what users are used to. And this is a concern for
> deploying applications quickly. We have the unique opportunity to change
> most of these "feel" issues to our heart's content. The 'look' is a bit
> harder, but can be done, too.
>
> I don't worry too much about the 'feel' because it's easy to change.
>
> Having said that, I agree that it would be nice to have a consistent feel
> out-of-the-box for Squeak that travels along all of the releases and bug
> fixes.
>
> Maybe we should have a UI team that addresses that issue. That would be one
> area that I could help on and would surely join the team. There is
> a "Morphic" team, but I don't think they are too active. I wouldn't think
> the morphic team addresses the overall concept of Squeak's UI. It may be a
> matter of setting some guidelines that can be followed that address we we
> collectively agree is the "standard" feel of Squeak. Those guidelines can
> be violated, of course, and should be when one wants to go beyond or even
> invent a better method (which could then be incorporated into the
> guidelines.) But, if developers follow the guidelines, it would keep Squeak
> UI consistent.
>
> Do guidelines, or some such list, exist today?
>
> brad
>
> On Sat August 11 2007 3:30 pm, Bill Schwab wrote:
> > Matthew,
> >
> > Fair enough.  I am mostly thinking of my users.  Suppose I display a
> > menu, they click in one of the magic spots, and instead of doing
> > something or nothing (which would cause a reflex to click again), it
> > gets attached to the hand.  I can hear it now: the menu is "stuck to the
> > mouse".  The file/directory picking "dialogs" are not really that at
> > all.  They are inconsistent, do not provide a clear way to show/hide
> > hidden files (at least on Linux).  As long as Squeak has been in use, it
> > seems that there should be a lot more polish in the interaction with the
> > user.
> >
> > The behavior of input focus is a lot better than it once was, but it is
> > still not consistent.  I hate to think about putting a clerk in front of
> > Squeak-based form.  If they have to touch the mouse, the software is
> > broken.  Why care what clerks think?  They enter data that can be turned
> > into serious money, but one has to make life easy for them, or they find
> > ways not to cooperate.  It can be hard enough when it is easy.  Squeak
> > is starting to show some respect for tabbing, but it is again not
> > consistent.  It might be far enough along that one could build something
> > robust for end users.  For example, in a deployed app, one would not use
> > a system window; the main window would be app's shell (MDI fans will see
> > it differently of course), and an alignment morph would likely cover the
> > entire world, with the widgets living inside it.  I have yet to actually
> > do this, but I can imagine that it would hide many of the IDE's
> > annoyances.
> >
> > One of my favorites is the method finder.  Especially with an optical
> > mouse (the kind that moves the cursor even when still), one has to
> > "balance" the cursor in the selector field, lest the focus fly off to
> > some other widget.
> >
> > Workspace menus: the browse-it command should be on the first menu, near
> > inspect, debug-it, and friends.  Many other ergonomic annoyances have
> > been posted recently.
> >
> > The Linux vm will shutdown w/o warning.  It could do a better job with
> > virtual keys.  Some of that is Linux culture, but I notice that other
> > apps respond as expected to keypad vk messages.
> >
> > Again, it is mostly feel: how it reacts to keyboard and mouse input.  I
> > am of the opinion that Microsoft is losing their collective grip on
> > reality, but they did some really good usability testing - what, 20
> > years ago??  Scary.  Much of what they learned watching "idiots"
> > interact with computers has become widely adopted.  If I am giving them
> > too much credit, I apologize, but there is a mechanical vocabulary of
> > interaction with computers, with a fine line between being responsive
> > and fragile.  I argue that Squeak as packaged is in the latter camp.
> >
> > Please note that I am trying to remove a barrier to use of Smalltalk.  I
> > believe there is nothing one can do to make the masses leave the
> > sharp-infested waters(TM) for the power and elegance of Smalltalk.
> > However, we can help those who "get it" make their would-be users' life
> > as easy as possible, making it just that much easier to apply Smalltalk.
> >
> > Bill
> >
> >
> >
> >
> > Matthew Fulmer wrote:
> >
> > On Sat, Aug 11, 2007 at 04:20:21PM -0400, Bill Schwab wrote:
> > > At the risk of becoming a broken record: my complaints about the
> >
> > Squeak
> >
> > > GUI are not about look, they are about feel. I can sell funny looking,
> > > but I cannot sell clumsy.
> >
> > Squeak is easy to get used to, so we usually forget what makes
> > it clumsy. The only things I can think of is using the Alt
> > (rather than Ctrl) key for modifiers (on Linux and Windows), and
> > the lack of support for one-click copy/paste (under X11). What
> > else bothers you about it? We are not conspiring to make a
> > clumsy user interface. I got used to the interface after 1 week
> > and never saw it as clumsy.
> >
> > I want to know. Really. What don't you like?
> >
> >
> > Wilhelm K. Schwab, Ph.D.
> > University of Florida
> > Department of Anesthesiology
> > PO Box 100254
> > Gainesville, FL 32610-0254
> >
> > Email: [hidden email]
> > Tel: (352) 846-1285
> > FAX: (352) 392-7029

> UI consistent.
>
> Do guidelines, or some such list, exist today?
>
> brad
>
> On Sat August 11 2007 3:30 pm, Bill Schwab wrote:
> > Matthew,
> >
> > Fair enough. I am mostly thinking of my users. Suppose I display a
> > menu, they click in one of the magic spots, and instead of doing
> > something or nothing (which would cause a reflex to click again), it
> > gets attached to the hand. I can hear it now: the menu is "stuck to

> >
> > Bill
> >
> >
> >
> >
> > Matthew Fulmer wrote:
> >
> > On Sat, Aug 11, 2007 at 04:20:21PM -0400, Bill Schwab wrote:
> > > At the risk of becoming a broken record: my complaints about the
> >
> > Squeak
> >
> > > GUI are not about look, they are about feel. I can sell funny

> > > but I cannot sell clumsy.
> >
> > Squeak is easy to get used to, so we usually forget what makes
> > it clumsy. The only things I can think of is using the Alt
> > (rather than Ctrl) key for modifiers (on Linux and Windows), and
> > the lack of support for one-click copy/paste (under X11). What
> > else bothers you about it? We are not conspiring to make a
> > clumsy user interface. I got used to the interface after 1 week
> > and never saw it as clumsy.
> >
> > I want to know. Really. What don't you like?
> >
> >
> > Wilhelm K. Schwab, Ph.D.
> > University of Florida
> > Department of Anesthesiology
> > PO Box 100254
> > Gainesville, FL 32610-0254
> >
> > Email: bschwab@...
> > Tel: (352) 846-1285
> > FAX: (352) 392-7029

> Brad,
>
> I'm sure we did have this conversation.  If anyone is in an infinite
> loop, it's me :)  My only disagreement is that I find feel much harder
> to address that look, or at least look _should_ be relatively trivial.
> Ideally, it should be pluggable, and one simply draws a little more to
> obtain a richer look.  Feel involves routing of messages, managing
> focus, etc.    IMHO, that is a lot more trouble, is it not??
>
> Regardless of relative difficulties, I would be happy to help with an
> effort to improve the situation.
>
> Bill
>