All,
WELCOME Everyone!
Ok, I'd like to start off by saying thanks to those who previously volunteered their time to help us make a more consistent, modern, and most important, useful user interface for Squeak. Now, all we need to do is figure out what to do ;-)
I want to first bring everyone up-to-date on the email that has crossed our desks that didn't make the archive of this mailing list. I'll try to provide a condensed, but accurate representation, but if I err, please reply and set the record straight.
I request that you do not reply to this email, but start a new email thread on the particular topic that is of interest to you. That way, we can easily search the archives later.
I first sent a message to those who replied to my squeak-dev email regarding the UI. Here it is:
+++++++++++++++++++++++++++ HI All,
Just putting this out there to see if there is interest in starting a UI team for Squeak. Each of you have commented on Bill's email outlining some of the shortcomings of the interface. I would be glad to organize the group and get it running. I have some ideas, and I'm sure you have plenty. Before that, just wanted to know if you are interested and could devote time to the endeavour.
cheers, brad
if you know others that would like to contribute, please let me know. ------------------------------------------------------
+++++++++++++++++++++++++++ There were several replies that wanted to help, and in various ways. Some to code, financial support, test, and just review and comment on discussions. We need help in any way you feel you can contribute. The ones who originally wanted to contribute were (and I'm not holding you to it!):
Jan Hussaarts Jason Johnson Herbert König Douglas Rollwitz Bill Schwab Andreas Wacknitz Brad Fuller ------------------------------------------------------
+++++++++++++++++++++++++++ Here are the messages in condensed format:
=== Hi Brad, Are you working on a new UI for morphic? If that’s the case or even partially so, why not host your topic on the morphic list?
It could use the traffic, and eventually the UI stuff will overlap or conflict with the morphic stuff anyway. Might just as well deal with it as a morphic issue.
And I am interested in seeing progress made and issues defined.
Yours in curiosity and service, --Jerome Peace ---
=== I thought about that. But, I feel that user interface issues go beyond morphic. There is also MVC (don't know who uses it today, though) and native hooks such as wxSqueak. My first suggestion to the group was to decide on UI heuristics or guidelines that applications would follow to help make Squeak more consistent for the user. Some agreed, some didn't say anything.
In any case, that's why I think it's a separate team. But, if others feel it is not, I'd like to hear their thoughts.
brad --- === Actually I don't have a clear idea on what to really do, I strongly advocate for KISS!
Imho we should set up another mailing list and inform Juan (Morphic 3) Noury (easy Morphic GUI), the Ffenestri people and the "Friends of Morphic". They need not donate time but I think they might have valuable opinions and experiences and hopefully an interest in the matter.
And we should take this to SqueakDev.
Let's gather some ideas, find out who is happy with the ideas and after that see who can commit time into it.
Cheers,
Herbert ---
=== Hi Brad and all,
I don't know how to contribute to a UI team. Nevertheless I can spontaneously express what I miss on Squeak's UI: standard widgets. With standard widgets I mean both, standard looking and standard behaving widgets. There have been various attempts to resolve the lack of them. Alas all of them are either unfinished or abandoned. So, IMO the purpose of a UI team would be to create or harvest these standard widgets and maintain them in the future.
Regards Andreas ---
=== Theming implies a lot of refactoring that needed to happen. Of course, my primary concerns are feel more than look. But anyone who can work around the system well enough to do that type of cleanup is someone we should "hire" (or perhaps offer our services as helpers<g>).
Bill ---
=== I want typical input cursor movement and I know my users expect it[*], but some Squeakers really like mouse-over activation. Hopefully we can leave that option in place for those who want it.
As I said before, count me in, and thanks!!
Bill
[*] well, they would complain mightily if the cursor did not move as they have learned to expect. "I pushed the mouse out of the way so I could see, and it started typing over there - fix it." I could go on like this. ---
=== I'll put this idea out there: what if we started with no code, but UI guidelines, consistng of both Look and Feel. For instance:
* all menus should take maximum of 8ms to return to the user with the full menu presented * File dialogs should look and feel consistent. Here are the rules: <etc.> * User's input focus must be consistent. It should not follow mouse but at the last place mouse pointer selected. * The World Menu must only consist of: .... * Critical System Errors should present .... * Errors are broken into the following classifications: Critical System Errors, System Errors..., etc.
Ok, they aren't worded so well (because I'm just thinking as I write) and these may be way off. But, you get the picture. Something simple, clear and easy to implement.
It takes a lot of thought and experiementation to produce these rules. But, there are already plenty of Squeak UI precedences set (where maybe we just gather them by observation and provide the rules as "The State of Today")
There are also plenty of UI precedence in general in the world - some horrible some useful. Jef Raskin's Humane Interface, Usability Heuristics, and even my favorite Donald Norman's "The Design of Everyday things" andhis Neilsen Norman group.
What do you think? It would provide a framework for all else to follow. Maybe if we produce successful heuristics, we could begin implementing in the current squeak (or 3.10) image.
brad ---
=== What you call guidelines sounds much more like requirements. After an initial requirements engineering there should be some modeling / architecturing. But somewhere in time there need to be real coding. And I think a new UI with all of its consequences will need a LOT of it. So I suggest to join forces and, as I have written before, let's have a look what has already been done.
Regards Andreas ---
===
What you call guidelines sounds much more like requirements. After an initial requirements engineering there should be some modeling / architecturing. But somewhere in time there need to be real coding.
Sure. But, guidelines provide general policies for requirements or for a plan of action. My suggestion is that we provide these guildelines first before setting down hard requirements for whatever the team is going to provide. The UI Guidelines provide a foundation to build all the UI projects that we may come up with. If we don't have them, each UI widget/product/application would conform to its own rules. Then, we would be back to where we started and complained about: an inconsistent Squeak.
brad ---
==
- User's input focus must be consistent. It should not follow mouse but at
the
last place mouse pointer selected.
This one is controversial, a lot of people love the old Motif "follow the mouse style". The best would be to make it configurable imo.
Jason ---
===
This one is controversial, a lot of people love the old Motif "follow the mouse style". The best would be to make it configurable imo.
well.. it was only an example. The real suggestion is coming up with UI rules.
brad --- === The recent skinning effort would be a great place to start coding wise. It should at least be evaluated; if we think it's junk, ok, otherwise, we should team up to not waste effort. Beyond not losing an opportunity, I agree that documenting what we want to change is a useful start. That can be done on a wiki or a mailing list.
Bill ---
=== That's a great idea. we could start by putting up a page on the wiki.squeak.org site, unless there's a better idea.
brad ---
=== I did a quick search on the wiki and found the following relative links. Do you know of any work which has been started for Squeak UI?
UIIdeas http://wiki.squeak.org/squeak/5819
The Squeak User Interface http://wiki.squeak.org/squeak/5808
Squeak User Interface http://wiki.squeak.org/squeak/1923
The Humane Interface http://wiki.squeak.org/squeak/3026
Customizing the Squeak UI http://wiki.squeak.org/squeak/1008
Omnniuser http://wiki.squeak.org/squeak/5742
Programming in Morphic http://wiki.squeak.org/squeak/5802
Skins Importer http://wiki.squeak.org/squeak/1797
Zurgle Paper http://wiki.squeak.org/squeak/2949
Fonts http://wiki.squeak.org/squeak/696
MVC http://wiki.squeak.org/squeak/1767
Forms, Views, and Windows http://wiki.squeak.org/squeak/69
Eye Candy http://wiki.squeak.org/squeak/1301
BitBlt http://wiki.squeak.org/squeak/189
Morphic for Dummies http://wiki.squeak.org/squeak/1870
Fun with the Morphic Graphics System I http://static.squeak.org/tutorials/morphic-tutorial-1.html
Morphic Animation II http://wiki.squeak.org/squeak/1262
Morphic Animation III http://wiki.squeak.org/squeak/1264
what's the right tool for text file templates? http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-November/098364....
brad ---
=== I looked at the Wessels skin importer, but it was "just Squeak with skins" and any time a debugger opened, it would revert to the default look. No doubt that was to avoid meltdowns, but since the debugger is our friend, it meant that the skins were pretty much useless for development.
The more recent skinning effort, at least by screenshots and bullet points, adds some more substantial widgets. It is worth a look, and we might form a useful alliance. As a group, we might stand a better chance of getting the results into wide use. Either skinning system will modify a lot of Morphic, which gives us a place to hang the feel changes.
Another suggestion would be to invite Rob Gayvert to join us. I would never suggest that a good look and feel requires native widgets, but they might add some discipline/structure that could be useful.
Bill ---
=== Won't it be more performant with BltBlt or OpenGL? What would stop us from duplicating the native widget look inside the BltBlt/OpenGL? Too much work? Some kind of licensing thing?
Obviously it makes keeping up with the OS'es much easier if we use native widgets, but I don't think looking a little different is a problem. After all, Java apps are starting to pick up a bit in my circle of the word and they don't look so native.
The main thing I see is that the Squeak absolutely must have a way of opening more then one window. After that though I think BltBlt/OpenGL could be good.
The reason I suggest OpenGL or BitBlt is simply because it's faster. It was discussed on a thread on squeak-dev some time back. I believe it was Bill who pointed out that trying to map Window's own message sending mechanisms back into objects is tricky and hard to make it fast. With a more direct rendering it maps much better and runs quite a bit faster.
I know we all say not to worry about speed but someone has to or your stuff will simply be ignored.
I believe what Bill suggested earlier that the look itself isn't so important as how the application responds. It needs to feel consistent and responsive.
Jason ---
=== Jason,
I am not so much thinking about performance as wondering whether there might be benefits to surrendering the feel to wx or another library. One can always do things like Morphic to get better scaling to large numbers of widgets, so I am not looking at it as using native widgets to exclusion of emulation. Right now, we have emulation to the exclusion of native widgets. Recently, I began to wonder whether striking a balance might force us to get the feel right??? By feel here, I mean the more basic focus and mouse gesture responses.
Bill --- === All,
The main goal of our effort should be to enable / facilitate the building of applications with a look and feel that adopts the look and feel of the OS that Squeak is running on. I do not think OpenGL or BitBlt will help very much. Perhaps it is better to stick to browser-based screens or build wrappers for the use of OS-api's.
For me the look is very important. I develop for windows environments and IMHO the looks of the applications must reflect the general looks of the hosting environment. Consistency and responsiveness are prerequisites (that will partially be covered by the application logic).
The look of Gary Chambers effort (see mail from Andreas) seems to be ok.. Is there any info on the progress? If such an interface (or an interface like Zurgle) are easy made using OpenGL, then we could use OpenGL. Perhaps GTK is also an alternative.
Jan ---
=== To adopt the look and feel of the host OS is most likely easier done if there is a hook into the guts of the host OS and not to duplicate the look in Squeak. If so, then image portability is severly hindered because of the need to develop the hooks necessary for the platforms. IMO, one of the top requirements of Squeak, itself, is portability.
brad ---
=== Support of themes could be an option.
I remember that people are working on modularisation of Squeak. Another possibility would be the implementation of a OS dependent UI module. We would then have to take care that there is a common interface, i.e. there would be no difference between linux and windows.
For me personally image portability is not important.
You think it is possible to use dotnet for the UI? Then we would cover Linux (via Mono) and Windows.
Jan ---
=== Jan,
Native widgets are certain a way to achieve platform-specific behavior. One might argue it is the natural way to achieve it. It is not the only way - one can always emulate.
That said, I am starting to warm up to the idea of bringing native widows up into the Squeak GUI, if only to force a refactoring of the input handling.
Whatever you guys want to do to make the interface better is fine by me.
Bill ---
=== Jason,
Guilty as charged :) And I have not changed my mind. Right now, we have a single native window with emulation therein. Squeak should be able to use native widgets to a greater extent, and if we reach a point that allows us to build platform native interfaces, that's great. However, there will always be a time when realizing that the interface is just a dynamic picture with a cursor and caret running around will lead to dramatically better performance than would result from insisting on rendering everything using a library that expects to put a few widgets on a dialog box. Imagine using native widgets to render the cells of a spreadsheet vs. doing it bitblt - no contest IMHO.
We need both, allowing developers to pick the best solution for their task.
Bill ---
===
Jason,
Imagine using native widgets to render the cells of a spreadsheet vs. doing it bitblt - no contest IMHO.
You have much more experience with GUI's then I, I'm sure, which would win?
We need both, allowing developers to pick the best solution for their task.
Bill
I agree, you have my vote. :)
Jason ---
=== Bill and Jan,
I have mixed feelings when it comes to native widgets.One of Squeak's strengths is its portability. The more externals Squeak depends on, the more difficult it will be to do Squeak ports to a new platform (and maintain the existing).You were talking about Linux. But Linux is just a kernel and not an operating system. There are countless Linux distributions. Each of it may have its own versions and hence versions of libraries like GTK or wxWindows. So you will likely get a new kind of dependency and versioning hell. I once was a Linux fan (RedHat, Debian and some other distributions). But then I realized that I was always hunting for new versions and proper libraries. So I stopped using Linux and now I am using Solaris as Sun does not release new versions twice a year, breaking compatibility. And, of course, there is only one Solaris and thus no risk of confusion.
Nevertheless I probably will support OpenGL as it is standardized. But then we will have to define the version of OpenGL to be used.
Andreas
=== Image portability is important to me. My interest in Squeak (and some other Smalltalks) is to get off of Windows and more recently to have an alternative in case Dolphin really does go away. I will long need to run on Windows, so a cross-platform tool is critical.
I am open to a cleaned/themed Morphic with feel options and fixes, and increasingly to native widgets. I have no reverence for native widgets, having long ago realized that they are fine in small numbers and inefficient for large grids, etc. However, I am starting to think that native widgets might be good for Squeak in that interfacing to them might force some needed cleanup. Either way you guys want to go is fine with me.
If we go native, or add native widgets as an option (perhaps the better route), I would not start with .NET/Mono, but wx or GTK. Microsoft's SOP is to kill everything they build, so I think we are better off keeping them at arm's length.
Bill ---