A new GUI visual designer

For me I do not know. Just want to get educated. Building my taste and after I will be able to have a point of view.

Stef
On Feb 15, 2011, at 9:24 PM, Richard Durr wrote:

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 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. 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.

     So given that, you're dealing with first-class objects all the
time. 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. 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.


     thanks,

-C

[1] http://netjam.org/spoon (main site)
[2] http://thiscontext.wordpress.com (blog)

--
Craig Latta
www.netjam.org/resume
+31  06 2757 7177
+ 1 415  287 3547

On 02/14/2011 09:59 AM, Sven Van Caekenberghe wrote:
Sure! :) But it was still evolving, although slowly, when I got
distracted by other things. So I hadn't come to the "let's put it in BNF
stone"-phase.

> - there does not seem to be a way to deal with non-ascii strings like 'Göran', shouldn't there be something like JSON escapes ?

Ehm... my memory is weak here - I actually don't know what the code does
- but I agree with people saying UTF8.

> - should there not be some kind of convention to note the expected reader (in a comment as meta data maybe)

Sure, might be nice! :) Or one could say that in order to work nicely
with "known readers" the first message could be:

reader: #CoolFormatReader.

...there are endless ways to do that.

> - has this since 2009 been used anywhere ?

I am using it in Deltastreams (although that project is not usable yet
and has been dormant) and a collegue actually used it in one of his
little projects - other than that I have no idea.

> - how about inter Smalltalk interoperability ?

Sure, one might investigate that. If so then I think that number parsing
is the most brittle part. The code is very small and I wrote it using
vanilla Squeak I think so porting would probably be quite simple.

>
> Sven
>
>

regards, Göran

PS. You could use Tirade for simple inter-Smalltalk communication too -
since over a Socket it would constitute an RPC mechanism.

Em 15/02/2011 20:28, Craig Latta < [hidden email] > 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...

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

> > But whatever [your GUI widgetry model] 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?

     No; it's still up to the author of the code to create modules which
contain all the methods required for the application. There are ways to
automate that, though. (For example, creating modules by noting all the
methods which get run by the application's unit tests.)

> 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}.

     I'm not suggesting anything (yet) about what the GUI object model
should be, just that we don't need to resort to transcribing the objects
into a textual ("dead") form in order to deploy it.

> > ...you're dealing  with first-class  objects  all the time. 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 to be possible they would need to
> answer to the become: protocol and need to have in the target image
> both the frameworks, right?

     Not necessarily, no (on both issues).

> With the caveat I may still have not understood your proposal in
> full...

     I'm just suggesting that representing GUI structures
non-programmatically can be done by using objects directly, without
transcription (without viewspecs, XML, etc.).

> 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?

     Again, I'm not saying anything yet about what a good GUI object
model would be.

> regards, and keep the research in Spoon!

     Thanks!

-C

--
Craig Latta
www.netjam.org/resume
+31  06 2757 7177
+ 1 415  287 3547

On 02/14/2011 11:14 AM, Craig Latta wrote:
[SNIP]
>       This scheme is readable, editable, easy to store, and amenable to
> framework change (the four things you were after).

Thinking about this a bit more I realize one interesting aspect:

Your stuff is basically low level serialization support - right? So...
it all boils down to what kind of object model you pick. Now... come to
think of it - readable and editable? Not sure how you mean there,
counting the designer tool as the editor is kinda cheating :)

But that was not what I was thinking about - you say that it is
"amenable to framework change", and I just wrote that serialization
generally is really bad for that.

Thinking more closely, as I said, it boils down to the object model. On
nice way to make a GUI description to be very robust against change is
to let it be the representation of "a sequence of commands aimed at a
builder API". Thus, the actual UI framework can change all it wants, as
long as the builder API still works.

So, if your object model is such a "command sequence" then I agree, it
would be as robust as the same thing in Tirade. But... if your model is
the actual built UI then I don't agree that it is as robust - supporting
"migration" from one object model to a new one is kinda complex.

Anyway, I was not really meaning to argue against Spoon - my main point
was that representing a UI as a "recipe" for constructing it is probably
the most robust way to do it. And isn't VW specs actually something like
that?

And the corollary is that representing UIs as "snapshots" of them when
they are constructed (using serialization schemes) is IMHO not at all as
robust.

regards, Göran

Hi Göran--

> Thinking about this a bit more I realize one interesting aspect:
>
> Your stuff is basically low level serialization support - right?

     It is, but what makes it interesting is that it's *interactive*
serialization; the producing and consuming systems interact.
Traditionally, you serialize to a file, and at the time the consuming
system reads it, the producing system is long gone. The consumer can't
ask the producer anything about it if finds something confusing, and the
producer can't take any information about the consumer into account when
creating the bits.

     Speaking of recipes, imagine following a recipe from a cookbook.
You might wonder if you can leave some ingredient out (because you
forgot to go the store), but you're on your own figuring that out. All
you have is the recipe. But if the author of the recipe were there with
you, telling you what to do, you could just ask. And the author might
not even bother mentioning the missing ingredient, because he can
already see when you start that you don't have it.

     It's this sort of synchronization that Naiad (Spoon's module
system) supports. It's important when transferring individual method
literals, entire methods, and entire modules. It's all messages going
across the wire between producer and consumer, and their precise content
may vary significantly from one consumer to another. Expecting one set
of bits to convey the correct thing to all consumers, in a system as
dynamic as Smalltalk, always struck as me a bit crazy. :)

> So... it all boils down to what kind of object model you pick. Now...
> come to think of it - readable and editable? Not sure how you mean
> there...

     I meant it in the sense that I thought you did... the way I'd store
GUI information is even more readable than viewspec arrays or XML
because it's just the original objects from which we derived the
viewspecs and XML. It's more editable for the same reason; we can use
the same powerful inspectors and browsers that we used during development.

> ...counting the designer tool as the editor is kinda cheating :)

     Hey, if it's useful, why not? :)

     Well, builder APIs can change, too. But sure, I'm not attached to
any particular GUI object model, or style of model (declarative or
otherwise). I do think, though, that using the actual built UI becomes
an interesting option when you have live synchronization. I view the
complexity as similar to writing correct "postCopy" methods (not too
bad). You could ask a UI object to spit out builder commands, for
example, as I suggested in an earlier message. Builder commands could be
an exchange format, used occasionally when necessary.


-C

--
Craig Latta
www.netjam.org/resume
+31  06 2757 7177
+ 1 415  287 3547

Craig,

If I am following this correctly, it's over-engineered and will back fire.  You are setting up some of the same mistakes that were made in SmartReferenceStream, only with both sides involved.  This is a simple problem calling for a careful solution.

Dolphin has this right: version the serialized streams, and the consumer either knows how to read it or not; errors result in the latter case.  What you are doing *could* be ok with the developer of both systems on hand to monitor it, but that will be rare.  In fact, one might assert that serializers are useful precisely when one of the parties is absent: otherwise one would simply pass the object and be done with it.

What you want are tools that make it easy to write the converters (which belong in the affected classes, not the serializer - another SmartReferenceStream oddity).

SIXX *might* avoid some of this by focusing on messages rather than instance variable layout, but even then, some attention to legacy data would be required.

Bill




________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Craig Latta [[hidden email]]
Sent: Thursday, February 17, 2011 8:04 PM
To: [hidden email]
Subject: Re: [Pharo-project] A new GUI visual designer

Hi Göran--

> Thinking about this a bit more I realize one interesting aspect:
>
> Your stuff is basically low level serialization support - right?

     It is, but what makes it interesting is that it's *interactive*
serialization; the producing and consuming systems interact.
Traditionally, you serialize to a file, and at the time the consuming
system reads it, the producing system is long gone. The consumer can't
ask the producer anything about it if finds something confusing, and the
producer can't take any information about the consumer into account when
creating the bits.

     Speaking of recipes, imagine following a recipe from a cookbook.
You might wonder if you can leave some ingredient out (because you
forgot to go the store), but you're on your own figuring that out. All
you have is the recipe. But if the author of the recipe were there with
you, telling you what to do, you could just ask. And the author might
not even bother mentioning the missing ingredient, because he can
already see when you start that you don't have it.

     It's this sort of synchronization that Naiad (Spoon's module
system) supports. It's important when transferring individual method
literals, entire methods, and entire modules. It's all messages going
across the wire between producer and consumer, and their precise content
may vary significantly from one consumer to another. Expecting one set
of bits to convey the correct thing to all consumers, in a system as
dynamic as Smalltalk, always struck as me a bit crazy. :)

> So... it all boils down to what kind of object model you pick. Now...
> come to think of it - readable and editable? Not sure how you mean
> there...

     I meant it in the sense that I thought you did... the way I'd store
GUI information is even more readable than viewspec arrays or XML
because it's just the original objects from which we derived the
viewspecs and XML. It's more editable for the same reason; we can use
the same powerful inspectors and browsers that we used during development.

> ...counting the designer tool as the editor is kinda cheating :)

     Hey, if it's useful, why not? :)

     Well, builder APIs can change, too. But sure, I'm not attached to
any particular GUI object model, or style of model (declarative or
otherwise). I do think, though, that using the actual built UI becomes
an interesting option when you have live synchronization. I view the
complexity as similar to writing correct "postCopy" methods (not too
bad). You could ask a UI object to spit out builder commands, for
example, as I suggested in an earlier message. Builder commands could be
an exchange format, used occasionally when necessary.


-C

--
Craig Latta
www.netjam.org/resume
+31  06 2757 7177
+ 1 415  287 3547

Hi Bill--

> You are setting up some of the same mistakes that were made in
> SmartReferenceStream, only with both sides involved.

     What mistakes were those?

> This is a simple problem calling for a careful solution.

     I agree, and this seems a lot simpler to me than what has come before.

> What you are doing *could* be ok with the developer of both systems
> on hand to monitor it, but that will be rare.

     Hm, I don't think that's true. In my use so far, this system has
reduced the number of situations requiring human intervention, not
increased them (mostly to do with missing prerequisites, out-of-date
class definitions, and class name conflicts).

> What you want are tools that make it easy to write the converters
> (which belong in the affected classes, not the serializer - another
> SmartReferenceStream oddity).

     Naiad (Spoon's module system) is indeed implemented that way; there
is no "serializer".


-C

--
Craig Latta
www.netjam.org/resume
+31  06 2757 7177
+ 1 415  287 3547

Craig,

You and SmartReferenceStream are effectively assuming that user==programmer; I submit it is in our interest to many ordinary users of Smalltalk applications.   All that should be required is to have code that is newer than the stream, and neither user nor developer should be bothered with conversions.  What you are doing on the fly should be done at the time of the layout change by the developer of the class(es) being serialized.

Bill


________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Craig Latta [[hidden email]]
Sent: Friday, February 18, 2011 6:42 PM
To: [hidden email]
Subject: Re: [Pharo-project] A new GUI visual designer

Hi Bill--

> You are setting up some of the same mistakes that were made in
> SmartReferenceStream, only with both sides involved.

     What mistakes were those?

> This is a simple problem calling for a careful solution.

     I agree, and this seems a lot simpler to me than what has come before.

> What you are doing *could* be ok with the developer of both systems
> on hand to monitor it, but that will be rare.

     Hm, I don't think that's true. In my use so far, this system has
reduced the number of situations requiring human intervention, not
increased them (mostly to do with missing prerequisites, out-of-date
class definitions, and class name conflicts).

> What you want are tools that make it easy to write the converters
> (which belong in the affected classes, not the serializer - another
> SmartReferenceStream oddity).

     Naiad (Spoon's module system) is indeed implemented that way; there
is no "serializer".


-C

--
Craig Latta
www.netjam.org/resume
+31  06 2757 7177
+ 1 415  287 3547