Classical Applications (was Re: 17 new updates)

Stefan Matthias Aust sma at kiel.netsurf.de
Wed Feb 17 20:41:58 UTC 1999


Joachim wrote:
>Stefan Matthias Aust wrote:

>> [don't immitate looks]
>
>Actually I think this is changing. The Java people already have decided

Actually, Sun decided that people should be able to recognize Java programs
:-) As for example once Borland decided that people should recognize
Windows programs compiled by Borland's C compilers using the BWCC DLL or
whatever it was called (that one with the red cross button for cancel and
the green check mark for OK)

>Actually the gaming industry does this all the times.

Actually, some games have better GUIs than most commercial programs.  Most
often they're very easy to understand and to use.  Probably because they're
special tailored for a certain game.  Therefore I like the idea of a
customizable framework that helps me to customize the GUI - something which
(also it can be done) is very painful with native widgets.

>> [A Windows-like feel is still important IMHO]

>Possibly. You still have to placate the Mac, fvwm (sp?), KDE, ...
>people. The feel of these GUIs is *definitely* different (to the point
>that I avoid Unix machines because it would take me weeks to get as
>proficient with its use as I'm with Windows right now).

Well, I really liked KDE it was familiar enough. When I was using a Mac, it
wasn't that different, too.  The only thing which was irritating at the
first moment where the totally different message dialogs which don't ask
yes/no questions but questions like save/don't save.  Otherwise, most GUIs
strive to a common point IMHO.  Of course, the Mac's GUI 3D look looks much
better than Windows :-)

>Interesting. This looks like a call for factoring out the look-and-feel
>aspects of a system. (Though I don't have the slightest idea how to do
>this.)

Yepp.  Different aspects have to be attacked with different technics.  

+ Instead of hard-coding the drawing methods for widgets,  each widgets
knows another object which knows how to draw that widget.  This objects are
instances of a different class hierarchy which has objects for Motif-like
buttons, for Windows-like buttons and so on.  One can probably create a
customizable (and themeable) object which might stimulate people to create
special themes (aka skins) for the whole GUI.  The GTK framework has this
feature.

+ Abstract widget objects aren't created directly but a special factory
object will do this.  This allows one to switch between native widgets and
emulated widgets for example.  This allows also to ignore or add certain
features like accelerator keys for menus (which Windows has but MacOS
doesn't) without affecting the rest of the code.

+ The actual GUI shouldn't be created by a constructor method but using a
specification. This specification is fed into the factory object.
Depending on the requested look, a special specification can be used.  So
on a Mac, the macWindowSpec is used while on a Windows machine, the
winWindowSpec describes the GUI (if available).

+ The GUI should be created using layout managers which allow to base the
layout on the preferred bounds of basic building blocks like labels and
buttons which probably have different sizes on all platforms because of
different fonts.  But even on one platform, fonts can be different,
depending on the personal preferences of the user and the screen resolution.

+ The system should feature a set of keyboard shortcut mappings, again
platform specific if needed.

+ A factory for high-level widgets like requestors, file dialogs and so on
should take care of platform dependent behavior of these things.

+ Special care is needed for a text input widget. It's important to support
the usual shortcut keys and cursor key bindings for every platform. These
bindings should be customizable.

+ As a rule of thumb, everything should be customizable using theme
objects. I bet that users would really like to give their system is very
personal touch. This is especially true for toplevel window decorations.

Actually, these ideas are an extended and idealized version of VisualWorks'
GUI frameworks plus some ideas of Swings and other GUI frameworks.

>I think Rational was seriously hurt by the deficiencies of the GUI. (And
>they reworked it in a recent release. Curiously enough, the regular
>stream of complaints about Rose on comp.lang.object entirely stopped
>after that release.)

Actually [I start to like that], I was referring to Rose 98 which is IIRC
the newest version.  I still don't like the GUI very much.  Probably such a
simple thing like adding more color to the toolbar buttons would already
improve the look.  Its feel is a different story however.

>>[DirectX]

>Seriously, I think DirectX can be used to implement primitives, but I'm
>unsure whether Smalltalk has the primitives that can be mapped to
>DirectX. DirectX is a relatively new concept, and the BitBlt ideas are
>rather old. If Smalltalk hasn't radically changed its underlying
>mechanisms I don't think it can make much use of DirectX.

If I remember the internals of the Windows VM correctly, the VM has its own
private display buffer which is then copied and transformed into the Squeak
window using some Windows-BitBlt variant.  This is a kind of double
buffering here.

Now DirectX provides a way to directly allocate graphics memory and doing a
hardware double buffering.  If also offers access to the hardware blitter
of modern graphics cards.  Using these features might accelerate Squeak.

>Right. But the implementer never knows what contract he should draw up,
>because he doesn't really know his users and their needs. More

He can ask the users or they can tell him ;-)

>importantly, he cannot guess with any certainty which distribution of
>private/public methods will minimize total effort: if too much is
>public, he will impede his own work, if too much is private he will
>impede the work of the users, and the latter is simply unknown.

I want to ease the live of the component provider, you want to ease the
live of the component user.  If the user is free to use everything, he
actually paralyzes the compontent builder has this guy can't change a
single method without risking to break existing code.  

And this isn't good for the component user, too.  Actually, this is one of
the reasons that there aren't more reusable (black-box) components for
Smalltalk.  It's too difficult to write them.


bye
--
Stefan Matthias Aust  //  ...and now something completely different





More information about the Squeak-dev mailing list