Hi antony
Yes I like your look.
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.
By professional we mean: clean and robust, Of course we would like to
have a good layout and UI. But someone has to do it. :)
What is also important is that people get the fredom to invent new
things and that pharo keeps making progress even at the price to be
incompatible.
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.
Is your code free?
Lot of people in the past started and never finished (Bricks for
example was one of these attempts).
Now may be you could join gary effort with polymorph?
There is also Miro, ISqueak...
One of the key aspects is that the underlying infrastructure should be
able to easily switch between UI. We expect the clean of mike
to fix issues to that respect.
A key important message of pharo is
if you do something good we will not let it aside (I remember the
blue look of Hneryk with antialiased fonts before mac os X, or the new
compiler
that if marcus would not have invested was lost).
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.
Oh yes!!!!!!!!!!!
Samuel Morello proposed us to design a user interface for pharo and he
discussed with Gary.
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.
:) We are slowly fixing that
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,
Did you check the way newspeak does it with hopstoch
new packaging/deployment tools including GIT integration
Interesting. What do you mean by new packaging. We are thinking about
a module system but for milestone 4 or 5 (one year or two from now).
Can you bootstrap the kernel?
One which version of Squeak are you based?
and modularity enhancements,
If you want to share code let us know.
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.
We are in sycn there. Do not worry. We love the idea in etoy for Kids
but the implementation makes me sick.
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
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
