[Pharo-project] A new GUI visual designer

csrabak at bol.com.br csrabak at bol.com.br
Wed Feb 16 01:16:29 CET 2011


Em 15/02/2011 20:28, Craig Latta < craig at netjam.org > escreveu:

> Hi Cesar--
>
> > Fantastic wishlist! However, maybe because the synthetic nature of
> > the proposal...
>  Well,  I'm  cheating here,  because  I've  already implemented  the
> givens (live method transfer and modules). See [1] and [2].

I see.  I'd a suspition but was too busy when I wrote my reply to
check on Spoon... 

>
> > ...I think I missed something:
> > How can a "...a method  be transferred to another live system." as
> > per your "4." and "Represent the state of that GUI with an object"
> > and even be "amenable to framework change" simultaneously?
>  When  you're done composing  a GUI  with an  editor, you've  got an
> object that represents the GUI, typically a hierarchy of widgets and
> event-handlers (perhaps  similar to  a VisualWorks viewspec,  but an
> original  object instead  of a  transcription of  one).  The precise
> nature  of  the  objects  in  that hierarchy  depends  on  your  GUI
> framework. 

Yes! this was the part that triggered my attention!

> But whatever it is, you can transfer a method using it to
> another live system, because (at least in the stuff I wrote) you can
> transfer any method no matter what its literals are.

I see, but then we have to check if a given message send may end up in 
MNUs, right?

>  So  given that,  you're dealing  with first-class  objects  all the
> time.  

I think you're partially right here: your implementation scheme gives
us an impression of 'first-class' objects.  If underlying framework is
different enough to have the methods that when called end up in
Debugger, I see this only as a kind of Grease or similar mechanism
(perhaps SIXX with a bit more of semantics).  I think I can see this
grand vision working if some kind of 'equivalence' of widgets could be
produced so that a Morphic based GUI design could be used in [say]
wxWidgets based {Pharo,Squeak}.

> That's what  makes  this scheme  adaptable  to GUI  framework
> change.  You can examine GUI objects, ask them to convert themselves
> to  another  framework's structures,  etc.  with familiar  Smalltalk
> tools. 

I understand that in order that be possible they would need to answer
to the become: protocol and need to have in the target image both the
frameworks, right?

> There are no "dead-data"  formats to worry about, because all
> method  literals  get  transferred  as part  of  fundamental  system
> behavior, without any special consideration by the GUI framework.

Well, this seems to me more or less neutral for being compelling. The
representation of a GUI design, if we get a good format, could be one
of the best contributions we could do to the programming comunity.

As we're learning, (slowly) but it is part of our growing pains,
Smalltalk does not lead the way in the design of GUIs anymore.  We
need to fit in an industry.

The same way we needed to accomodate the ORM in order to be able do do
CRUD in Smalltalks, we need to go to the GUI side and go for a more
aligned with the mainstream technology and practice.

With the caveat I may still have not undertood your proposal in full,
I see that in limit, the right mapping would be to the host system GUI
primitives, so the whole issue of having to design a specific widget
hierarchy would vanish.  Correct?

regards, and keep the research in Spoon!

--
Cesar Rabak




More information about the Pharo-project mailing list