If Pharo is meant to be a 'professional' environment then IMO you
should concentrate on implementing known and tested solutions for
layout, rather than inventing a new system.
By professional I am assuming people mean interfaces as you see in
Windows and OSX applications e.g. fields, buttons, checkboxes etc.
Your example of functional relationships between ordinates has been
well studied in the field of constraint satisfaction - specifically in
Smalltalk. There is a package, cassowary (sp?) that is designed to do
this. However, IMO this idea i's overly general for 'professional' UIs.
I've implemented a layout manager for VW based on the Java layout
manager using in Matisse, that allows you to achieve slick looking UI
layouts in a declarative fashion. You should look to Java for ideas
about layout and dimensioning. The Java ecosystem is well in front of
Smalltalk in this area, given that Java is focussed on those kinds of
applications.
Regarding geometric properties of controls, the key characteristics
are those that allow for visual alignment, recognizing that the visual
bounds of a control in it's various states is not always the same as
it's alignment points. Two examples of this are 1) the focus indicator
of OSX which is outside of the visual/alignment dimensions of the
control and 2) the borders of controls that use dark/light line pairs
for boundaries usually want to align to other controls using the dark
line, which is often above the lighter line - hence the alignment
geometry of the control even in it's unfocussed state is not the same
as it's draw bounds.
Thus OSX controls have both bounds and alignment insets.
A key alignment point is the text baseline. This is the most common
problem with UIs. Basically, if you don't align on baselines then
everything looks crap.
There are various spacing and dimensioning relations between controls,
between non-control elements and to the window border. These are
dependent on the platform, the types of controls and whether the
controls are semantically related. Thus these spacing constants need
to be symbolic.
Finally, professional looking interfaces really require that you
eliminate configurability from controls. Colors, fonts, borders etc
are all designed to harmonize in OSX, and IMO this is a primary reason
that Squeak looks like a toy, and VW on OSX looked so appalling before
I fixed it. Google for 'ASBAqua' for details.
All of this I have done (sans a few corner cases) and published (for
VW). I've detailed a lot of this on my VW blog: http://www.cincomsmalltalk.com/userblogs/antony/blogView
. IMO the best approach for Pharo is to focus on solving specific
issues, and the best way to do that is to try and implement UIs that
look at home on e.g. OSX, and hence discover what techniques/tools/
frameworks you need to do that, rather than try to invent new ways of
doing things. Squeak is already littered with the result of that, and
Smalltalk's poor modularity and packaging means that such abandoned
projects stick like bubblegum in carpet.
I'm now in the early days of a (commercial) product, preliminary name
'Stardust Smalltalk' (based on Squeak, not VW), that implements the
ideas from my blog - better UI, alternative forms of code navigation,
new packaging/deployment tools including GIT integration and
modularity enhancements, WebKit integration, LLVM/Clang integration. A
very early screenshot is here: http://linkuistics.com/ftp/Stardust-2008-10-03.png
. I mention this to show that my comments above are not abstract
opinions. I'm in the trenches with these issues.
BTW: I mean no disrespect to Squeak. Looking like a toy is great for
an education product, which in the scheme of things is a more
important tool than yet another commercial IDE.
On 03/10/2008, at 11:32 AM, Igor Stasenko wrote:
The idea behind ordinates is to deal with morphic layouts.
Any morph , can define an arbitrary set of ordinates, then another
morph can say - lets my ordinate 'center' be a function which
calculates its position by taking another morph ordinate into account.
There can be infinite number of combinations how one morph's layout
can depend on another one. And ordinate system can allow any of them -
its up to you to define a function which calculates morph's position
based on another coordinates.
Example:
morph A is rectangle and defines following ordinates:
- origin = coordinate(x1 @ y1)
- corner = coordinate(x2 @ y2)
- center = function(origin + corner / 2 )
- topright = function (corner x , origin y)
- bottomleft = function (origin x, corner y)
- width = function ( x2-x1 )
- height = function ( y2-y1)
Now morph B , is a circle and defines following ordinates:
- center
- radius
now suppose i want that morph B should always be drawn in a center of
morph A, with diameter = height of morphA :
center = function( morphA center)
radius = function (morphA height / 2 )
Now, if you try to play with morphA, by dragging it over desktop or
resizing it - the morphB will automagically update its position as
well.
2008/10/2 Gary Chambers <[EMAIL PROTECTED]>:
Well, I've done a bit with CSS (3.0) not fully looked though, just
enough
that our Report Builder file format (XML) is roughly equivalent.
Just a thought about states of "widgets" I've seen in the wild...
base
Morphic doen't honour any of them by default... hence lots of extra
code for
dealing with interactive states in eveyone's subclasses/overrides.
To be
fair it is not appropriate to every Morph... just more common with
"standard" (if you like) styles of widgets.
As for ordinates, it was on IRC with Sig... tricky to track down
logs, did
find a link for a related dev-list email part of it though:
http://www.nabble.com/Re:--squeak-dev--Subcanvas-p18270830.html
Gary.
----- Original Message ----- From: "Michael Rueger"
<[EMAIL PROTECTED]>
To: "An open mailing list to discuss any topics related to an
open-sourceSmalltalk" <[email protected]>
Sent: Thursday, October 02, 2008 6:42 PM
Subject: Re: [Pharo-project] Formalised UI
Gary Chambers wrote:
Just some thoughts picked up over the years. Things that all Morphs
should have, at least, defaults for...
UI States:
how does this list compare to the list of possible CSS states?
Transitions would be nice, but might be a bit overboard... Igor
and I
discussed a framework based on 4 dimensional representations
being function
based (I think we coined the phrase "Ordinates").
Can you say more about this?
Michael
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
--
Best regards,
Igor Stasenko AKA sig.
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
It is as useless to argue with those who have renounced the use of
reason as to administer medication to the dead.
-- Thomas Jefferson
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
