[squeak-dev] Search bar, or is it?
ma.chris.m at gmail.com
Thu Apr 29 02:46:56 UTC 2010
> Hi Chris,
> I respect your opinion. Mine is different and I'd like to elaborate a
> bit more. Then you can tell me what you think.
Thanks, after reading your e-mail, I believe our opinions are more
aligned than you thought..
> Historically, I believe Smalltalk UI does not typically provide a menu
> bar. Neither in Morphic, which was permanently adopted in Squeak few
> years ago. Morphic is a considerably less rigid UI and there is a
> learning curve for mainstream users. It has been decided at some point
> that Squeak should have a menu bar. Not my particular cup of tea. It
> does however introduce a familiar element to people who are unfamiliar
> with Morphic, Squeak and Smalltalk.
Aye, I agree with you 100%. I've always been a proponent of Morphic,
even back in the years when Seaside was exploding and Morphic was waay
unpopular. I consider the 4.1 menu bar a detraction to the
object-oriented nature of Squeak and Morphic. I would be so critical
as to say I think it perpetuates the "wrong thinking" about OO systems
because it has users going there for global "commands". However, as
you said, mainstream users will feel comfortable.
> What you are telling me is that there is nothing wrong with a menu bar
> taking an entire screen and hiding everything below because one has
> typed a lengthy expression; it does not make sense to me and it won't
> make sense to mainstream users. Smalltalk is great because we can
> evaluate/print/do anything and everything absolutely everywhere. It's
> still called a search bar rather than an evaluation bar. Everybody are
> free to use the bar as they see fit but a search bar should behave as
> a search bar or otherwise coming off as inconsistent.
> I understand that you have been using it this way for more than 2
> years but there is something you have overlooked: it is now officially
> included in a release and by default. It means others may not use it
> the same way you do and others may not like it the way you do.
Just to clarify: What I have been using for 2 years is actually just
a TextMorph dropped on to the desktop. I found that, sometimes, I
liked the "light-weightness" of just a simple TextMorph. I then
discovered, by keeping a one-line TextMorph at the top of the screen,
next to my WatchMorph, I had all those things I mentioned (bench,
calculator, "search-bar", etc.) all quickly accessible thanks to that
very nice Smalltalk property you mentioned that you can "print-it"
So, when I pushed for the search-bar in 4.1, my goal was to
carry-forward these properties.
Here is the key point behind my motivations: As you can imagine, if
you were to have a "TextMorph workspace" on your desktop (as I do /
did), it makes more sense to have "auto fit" turned on than off.
However, if someone complains about the big size of the menu-bar in
the very rare case that a "search string" extends more than one line,
then someone will come up with the solution to turn off "auto fit".
IMO, this would be a disaster for the utility search bar, because it
loses all of those other really excellent great aforementioned
properties; and all just to satisfy a "non-problem" (I say non-problem
because, again, it is abnormal to type a really-long string in a
So I didn't mean to send the message, there is "nothing wrong with..."
the expansion. I said that it is more "coherent" to not truncate the
user input than to truncate it, while also maintaining protection from
neutering the wonderfully useful "print-it" power of having that up
there... accessible... lurking, for newbies transitioning to power
> I don't know for other Squeakers but I always have at least one
> workspace to evaluate expressions. So far I have used the search
> bar... to search! :)
More information about the Squeak-dev