@Tobias: Hi, what is the license because the wiki does not say it or I could not find it. On Dec 1, 2010, at 6:38 PM, Tobias Pape wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Am 2010-12-01 um 16:13 schrieb Igor Stasenko:

...

On 1 December 2010 12:48, nullPointer <epicfan@gmail.com> wrote:

...

https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/...

It really looks very professional. I made a user interface builder for Polymorph, which I left because I was too complicated for me.

@NullPointer: you did a lot of work Now this is not clear how the code is generated even in this new one.

...

...

I hope that now someone more knowledgeable can really necessary to implement a tool for Squeak / Pharo as a visual designer user interfaces.

+1 that's really important stuff. And this project looks very promising. Hope, author(s) can shed a light on it, in what stage it is, what license etc etc.

Its all on that wiki. Feel free to contact me, anyways.

So Long -Tobias -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAkz2iCMACgkQcPVIrP6PLKuiowCeNAFhjRdcFFYlxpaVGqHqBGml dkQAoKVVzSy6H6ycRuZw0UXIjAW0uHvY =Pv5I -----END PGP SIGNATURE-----

Hi geert The problem is not simply the license. The problem is: - integrating widgets - integrating extra libraries We cannot stack libraries. So there is an engineering effort needed. Stef

Stéphane Ducasse wrote:

...

@Tobias: Hi, what is the license because the wiki does not say it or I could not find it.

I reckon the GUI designer would be a nice addition to Pharo? Did you end up hearing from Tobias about the license? -- View this message in context: http://forum.world.st/A-new-GUI-visual-designer-tp3067111p3300892.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Hi all

Am 2011-02-11 um 09:58 schrieb Stéphane Ducasse:

...

Hi geert

The problem is not simply the license. The problem is: - integrating widgets - integrating extra libraries

We cannot stack libraries. So there is an engineering effort needed.

I do not understand that. Can you elaborate?

do we want signal? How do they compare with announcements and event and #changed In the case of the UIBuilder of void, there are new widgets that extend existing ones but It would be better to not subclass and get better widgets. May be fixing copy/postcopy, use of _,...... references to Preferences,.... This kind of work.

So Long -Tobias

tobias if you want to think that I'm an asshole and I do not want to have a better UI, you are free to think that. Now this is not the case. So if you can read my mail with the eyes of somebody that fight daily to make the system nicer, better, smaller....

...

...

...

So there is an engineering effort needed.

oO did other pharo-development _not_ involve engineering?

Yes so who is standing up and saying ok I will allocate one month to make sure that this is well integrated?

...

...

...

How do they compare with announcements and event and #changed

Had you read the Wiki, you would know. “convenient, lightweight and thread-safe callbacks” https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/... https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/...

Yes. Now the question is do we want that in addition to - event, - announcement - changed We are working ***HARD*** to remove event and system changenotifier. Design is not layering, it is about bringing the right infrastructure in place. So if signals are important/good then they should be not in competition to other but either integrated into or we should migrate the code to the other abstractions.

...

In the case of the UIBuilder of void,

Void? The nikname of the personn

...

there are new widgets that extend existing ones but It would be better to not subclass and get better widgets.

Interesting, Because it is what polymorph has done for years.

Yes and this is why we do not want that. Even for polymorph the goal is to merge everything and get one set of excellent widgets based on an excellent core.

...

May be fixing copy/postcopy,

what?

in pharo we use postcopy

...

use of _,

what?

??? we should not have _ rob vens told me that there are _ in the BUilder code

...

...... references to Preferences,....

Then, what about a -PharoCompat package?

I did not see it.

...

This kind of work.

Pleas let me quote your initial mail:

...

...

...

We cannot stack libraries.

I'd like to understand that, please.

As I said, we do not want to have four ways to emit announcements, we need one cool widgets set (merging the best of what exist), in the past we had 4 different ButtonMorph. I want one excellent one. So to get there it will take engineering time. Just to evaluate solution. Stef

...

...

...

In the case of the UIBuilder of void,

Void? The nikname of the personn

He is called Marcel and posted elsewhere in the thread.

I think that Stef is refering to nullPointer that also worked on a GUI Builder Cheers -- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

On Feb 12, 2011, at 6:22 PM, Tobias Pape wrote:

Am 2011-02-12 um 09:54 schrieb Stéphane Ducasse:

...

tobias

if you want to think that I'm an asshole and I do not want to have a better UI, you are free to think that.

Please rest assured that this is _not_ the case.

ok good

I just was astonished that you denied the usability of the Gui builder with just few very general words.

No I just evaluate MY time and what I'm able to achieve

...

...

...

...

...

Yes so who is standing up and saying ok I will allocate one month to make sure that this is well integrated?

However, if you want it in Pharo, thats the way to go. Think of Seaside on any non-Pharo. It is just the same.

Yes so this is why I said about my time.

...

...

...

...

...

Yes. Now the question is do we want that in addition to - event, - announcement - changed

We are working ***HARD*** to remove event and system changenotifier. Design is not layering, it is about bringing the right infrastructure in place. So if signals are important/good then they should be not in competition to other but either integrated into or we should migrate the code to the other abstractions.

Probably. However, cirticising initially other goals for not being Pharo’s isn’t fair, IMHO.

This is not what I did. I just evaluate: ok if I want that I need X, Z, K so my message was ok guys do not dream we cannot just include the builder that you and me would love to have. There is a lot of work to be done to arrive to that stage.

...

...

...

In the case of the UIBuilder of void,

Void? The nikname of the personn

He is called Marcel and posted elsewhere in the thread.

Ok this was nullPointer that I wanted to say. Not marcel because I know the first name of marcel.

...

...

...

Yes and this is why we do not want that. Even for polymorph the goal is to merge everything and get one set of excellent widgets based on an excellent core.

No Objection.

...

...

...

in pharo we use postcopy

So does Squeak.

Ok good to know one less point to check.

...

...

...

I doubt that there are _ assignments.

I do not know. Rob ask me how to load code without _

No, I mean, What about _creating_ a PharoCompat package that matches your style of preferences.

Ah this would be good.

...

Thats quite clear and I concur. The point is, you would have to do this with or without the builder.

yes except that I have to check the widgets and check that.

Oh, and for this and my previous emails: No offence meant.

No problem just a question: are the new widgets relying on signal? Because I would have to really study signal to imagine what we can do? Or are signal use to plug together widgets?

So Long, -Tobias

Feel free to ask if some phrasing of a feature is not as clear as it should be. Maybe I should add more elaborate descriptions. :) Marcel -- View this message in context: http://forum.world.st/A-new-GUI-visual-designer-tp3067111p3302561.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

I'm sorry but I disagree. XML as a meta-language is old, bad and shit. readable=good xml=really bad (and not-readable either, most of the times... unless you are some kind of cyborg) El 12/02/2011, a las 7:35a.m., nullPointer escribió:

My knowledge of Smalltalk/Squeak/Pharo is limited, but I believe somethings.

1- I believe Pharo/Squeak needs a different way for "render" the morphs. I suppose Rome go to that direction.

2- A language, human readable, for define the UI. I believe than XAML or XUL, based on XML, be good examples. And connect the UI to Controller/Presenter/ViewModel of same way, through bindings, Commands etc like WPF.

The code generated for designer of VW or Smalltalk/X don´t readable and updatable for a human, only for the same designer mechanism. Don´t works of example. It´s a OLD way, is a BAD way, is a shit way.

3- Implements a set of widgets. That is not difficult I believe. The main problem is the way of connect that widgets with data. I repeat above, bindings mechanism from WPF is a good-good example. Perhaps exists some controls for build... numeric controls with formatable values, datatime controls, grids (nobody needs a grid control on Pharo/Smalltalk?? I´m unique? How I can create a enterprise app without that?)

4- Implement the designer. BUT, that step don´t is needed if the language for define the UI is a standard. Exists many designers of XAML and some for XUL languages. Somebody could use that designers for build the UI, and add the XML in a spec method on Smalltalk image. We need only a "reader" for interpret the XAML code and build the morphic structure (or HTML render structure)

My conseil is: if we need implement set of widgets and a language for design UI is much more recommend base us in the new "way of do", don´t the old.

Regards. -- View this message in context: http://forum.world.st/A-new-GUI-visual-designer-tp3067111p3302570.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Le 12/02/2011 14:14, Norbert Hartl a écrit :

On 12.02.2011, at 13:57, Esteban Lorenzano wrote:

...

I'm sorry but I disagree. XML as a meta-language is old, bad and shit.

If you say XML is no-go shouldn't you present an alternative at the same time?

Lisp, Scheme or even Smalltalk :)

Yes, Smalltalk :) You can do exactly the same in a much better way. Last 10 years the world tried to use XML to... well, pretty much everything: as a meta-language to many DSLs, like XUL, XAML, but also for configurations, state-machines, etc. And it was a big failure... and the best example is that even in communities where the overcomplicated stuff is "the way to go" (like java), are leaving that, replacing it for most "in-code" ways (for example, using "scripting" languages). So... why are we going to go back on something the world is leaving? Of course, as much other "dead" things, XML is going to be around a lot of time... but is not anymore in the innovation line, and everybody can note that. think on something like: <StackPanel> <TextBlock Margin="20">Welcome to the World of XAML</TextBlock> <Button Margin="10" HorizontalAlignment="Right">OK</Button> </StackPanel> how it would be in Smalltalk? there are several ways... let's take the "Seaside way": xaml stackPanel: [ xaml textBlock margin: 20; with: 'Welcome to the World of XAML'. xaml button margin: 10; horizontalAlignment: #right; with: 'OK'. ] what's better? and that's only "wrapping" xaml... of course we can have something a lot better than just render xaml (like really composing objects)... but that was just an example :) Cheers, Esteban El 12/02/2011, a las 10:14a.m., Norbert Hartl escribió:

On 12.02.2011, at 13:57, Esteban Lorenzano wrote:

...

I'm sorry but I disagree. XML as a meta-language is old, bad and shit.

If you say XML is no-go shouldn't you present an alternative at the same time?

Norbert

...

readable=good xml=really bad (and not-readable either, most of the times... unless you are some kind of cyborg)

El 12/02/2011, a las 7:35a.m., nullPointer escribió:

...

My knowledge of Smalltalk/Squeak/Pharo is limited, but I believe somethings.

1- I believe Pharo/Squeak needs a different way for "render" the morphs. I suppose Rome go to that direction.

2- A language, human readable, for define the UI. I believe than XAML or XUL, based on XML, be good examples. And connect the UI to Controller/Presenter/ViewModel of same way, through bindings, Commands etc like WPF.

The code generated for designer of VW or Smalltalk/X don´t readable and updatable for a human, only for the same designer mechanism. Don´t works of example. It´s a OLD way, is a BAD way, is a shit way.

3- Implements a set of widgets. That is not difficult I believe. The main problem is the way of connect that widgets with data. I repeat above, bindings mechanism from WPF is a good-good example. Perhaps exists some controls for build... numeric controls with formatable values, datatime controls, grids (nobody needs a grid control on Pharo/Smalltalk?? I´m unique? How I can create a enterprise app without that?)

4- Implement the designer. BUT, that step don´t is needed if the language for define the UI is a standard. Exists many designers of XAML and some for XUL languages. Somebody could use that designers for build the UI, and add the XML in a spec method on Smalltalk image. We need only a "reader" for interpret the XAML code and build the morphic structure (or HTML render structure)

My conseil is: if we need implement set of widgets and a language for design UI is much more recommend base us in the new "way of do", don´t the old.

Regards. -- View this message in context: http://forum.world.st/A-new-GUI-visual-designer-tp3067111p3302570.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Create the UI with plain Smalltalk code have problems... my UIBuilder use that system and have limitations for limit of lityerals in a spec method, and other problems. Another alternative is the VW or Smalltalk/X mechanism, no readable, no updatable; only could be modified for the same designer routine. XAML is a standard (or XUL). Allow define the UI, but too allow define bindings, templates, commands etc for work with the controller/presenter/viewmodel. For do the same in any language, with plain code, you need much more code lines. A example with only a textbox and a label don´t works. Try build a view with three grids, many fields, bindings, events, tranmsformations, styles... and then compare the number of code lines from a way and another. And compare too the readable result...!!! And is possible create it with external designers; a Smalltalk designer is not needed. Only a XAML reader-builder is needed, and a set of widgets for work of that way. Ahhhhh! I see the problem!!!. Now I see. It´s a Microsoft product, then anyway is bad. Los programadores de Smalltalk, somos cangrejos ermitaños. Estamos tan acostumbrados a pensar que somos lo mejor y tenemos la mejor herramienta que nos hemos quedado anquilosados. Estoy hasta las pelotas de esta mentalidad. Lo digo en castellano porque no sé expresarlo en inglés. Regards. -- View this message in context: http://forum.world.st/A-new-GUI-visual-designer-tp3067111p3302962.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

xml is good a simple interexchange format. Now when you have you xml stream you have to map your nodes (different to objects) so for UISPec you can just get a parser and object builder for free. NO need to load XMLSupport. read my VW examples to understand. In VW you can click on a button and see the spec or see the rendering of the spec in your code pane and this is just based on spec objects that are stored in arrays. Simple! This is not because the world does not have a nice synatx with can be used to get xml description that we should use xml everywhere. (Book title: 'Zorro'; year: 1969; pages: 230) Is better than <xml tage \xml> why because I can do doit and get a book object on the first expression with the second I have to do XMLDomParser on ::.... parse..... map to books..... I know I'm saving some of my projects in XML and mapping is boring. Stef On Feb 12, 2011, at 7:13 PM, Esteban Lorenzano wrote:

No, I don't believe anything except smalltalk is bad. Just XML. I worked with Java, C# and a lot of XML to know that. Don't be confused... I'm not talking against XML alternatives because of microsoft or anything, I have serious technical complains against it. Also, XUL is not microsoft's and I'm opposing to it as strongly as XAML (but Seaside-XUL is cool, he).

Said so... i'm not against build an XAML importer or so, but I think you'll find a lot of several issues to solve, and it will maybe impossible :)

<Spanish here> (yeah... bad joke) Además... no lo defiendo porque crea que Smalltalk es mejor siempre, solo que en este caso, es mucho mejor que usar XML. Trabajo en la industria desde hace 18 años y solo hace 4 con Smalltalk, y además todavía hoy trabajo haciendo consultoría de arquitectura de proyectos hechos en Java o C#... se perfectamente de que estoy hablando... no estoy en contra ni de Oracle ni de Microsoft... simplemente, creo que usar XML es una mala alternativa, no te vayas por las ramas, plis :) </Spanish here>

Cheers, Esteban

El 12/02/2011, a las 2:59p.m., nullPointer escribió:

...

Create the UI with plain Smalltalk code have problems... my UIBuilder use that system and have limitations for limit of lityerals in a spec method, and other problems.

Another alternative is the VW or Smalltalk/X mechanism, no readable, no updatable; only could be modified for the same designer routine.

XAML is a standard (or XUL). Allow define the UI, but too allow define bindings, templates, commands etc for work with the controller/presenter/viewmodel. For do the same in any language, with plain code, you need much more code lines. A example with only a textbox and a label don´t works. Try build a view with three grids, many fields, bindings, events, tranmsformations, styles... and then compare the number of code lines from a way and another. And compare too the readable result...!!!

And is possible create it with external designers; a Smalltalk designer is not needed. Only a XAML reader-builder is needed, and a set of widgets for work of that way.

Ahhhhh! I see the problem!!!. Now I see. It´s a Microsoft product, then anyway is bad.

Los programadores de Smalltalk, somos cangrejos ermitaños. Estamos tan acostumbrados a pensar que somos lo mejor y tenemos la mejor herramienta que nos hemos quedado anquilosados. Estoy hasta las pelotas de esta mentalidad. Lo digo en castellano porque no sé expresarlo en inglés.

Regards. -- View this message in context: http://forum.world.st/A-new-GUI-visual-designer-tp3067111p3302962.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Just a comment: :) The Interface Builder of Nextstep and Mac OS X – a closely Smalltalk-related and inspired system – creates the objects making up the user interface (it instantiates them) and then saves the state of everything into a nib/xib file (binary/xml) using the general object-persistency mechanism of Cocoa (NSKeyedArchiver). This file is then loaded when the application in question starts, all the freeze-dried objects in the UI-file are revived (awakened – not created) and then loaded into the object space of the app. This reminds me of the way, the Smalltalk Image works – except that the image stores the whole application object space where the nib/xib only stores the objects the interface is composed of. With Morphic there even exists an easy way to compose an interface with using original objects directly like or better than Interface Builder. But instead of using the image as a storage mechanism for the instantiated objects of a morphic-designed interface we are stuck with the textual distribution mechanism and discussing how we can for example use xml to do that. That is ironic, I think ^^ -- Sent from my DynaBook.

Am 2011-02-13 um 17:58 schrieb Richard Durr:

Btw, why the use of qt's signals and slots and not Cocoas outlets?

Because the author of the Morphic Builder has had more experience with qt and likes it. He hasn't done Mac programming until now, afaik.

not right now. argh! On Mon, Feb 14, 2011 at 7:06 PM, Richard Durr <richard.durr@googlemail.com>wrote:

Ah okay I thought this to be a deliberate design decision. I would advise then to adopt it right now.

On Sun, Feb 13, 2011 at 8:44 PM, Tobias Pape <Das.Linux@gmx.de> wrote:

...

Am 2011-02-13 um 17:58 schrieb Richard Durr:

...

Btw, why the use of qt's signals and slots and not Cocoas outlets?

Because the author of the Morphic Builder has had more experience with qt and likes it. He hasn't done Mac programming until now, afaik.

You cite an example very similar to what Dolphin does, and we could do with SIXX. Dolphin serializes things not to avoid the image but to allow packaging. SIXX could do the same for us. I favor the idea of SIXX more to avoid falling into a trap of being subliminally influenced by (aka stealing from) Window Builder than because I think it is the correct thing to do. If we had something that could read and rewrite Smalltalk code that is truly independent of WB, then class methods would be nice way to store GUI designs. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Richard Durr [richard.durr@googlemail.com] Sent: Sunday, February 13, 2011 11:56 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] A new GUI visual designer Just a comment: :) The Interface Builder of Nextstep and Mac OS X – a closely Smalltalk-related and inspired system – creates the objects making up the user interface (it instantiates them) and then saves the state of everything into a nib/xib file (binary/xml) using the general object-persistency mechanism of Cocoa (NSKeyedArchiver). This file is then loaded when the application in question starts, all the freeze-dried objects in the UI-file are revived (awakened – not created) and then loaded into the object space of the app. This reminds me of the way, the Smalltalk Image works – except that the image stores the whole application object space where the nib/xib only stores the objects the interface is composed of. With Morphic there even exists an easy way to compose an interface with using original objects directly like or better than Interface Builder. But instead of using the image as a storage mechanism for the instantiated objects of a morphic-designed interface we are stuck with the textual distribution mechanism and discussing how we can for example use xml to do that. That is ironic, I think ^^ -- Sent from my DynaBook.

I'll leave in the middle whether or not the "Morphic UI Designer" is the right solution for Pharo, but looking at the number of posts in this thread I do have a feeling that: 1. most do agree that a better way to create the user interface really is needed 2. there are strong opinions on how this UI designer should and/or should not be implemented As most applications require a UI, having a powerful UI builder is extremely important for any development environment to succeed. If Pharo were to have an intuitive UI builder, I think even more people would give Pharo a go and probably improve Pharo's existing development environment along the way. Göran just constructively summarized and grouped some groups and optiobs for the "how". So rather than arguing what "not" to do, let's try and focus on how it will be done and who is able to help. Having said all that, I think Smalltalk could benefit even more if Smalltalk had a powerful UI builder for web applications, but I guess that's outside Pharo's scope and is something the frameworks like AIDA, Seaside or Iliad need to address. -- View this message in context: http://forum.world.st/A-new-GUI-visual-designer-tp3067111p3304566.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Hi Göran, On 14 Feb 2011, at 00:18, Göran Krampe wrote:

Hi!

Sorry, this post turned out long. But hopefully interesting anyway.

On 02/13/2011 06:36 PM, Schwab,Wilhelm K wrote:

...

You cite an example very similar to what Dolphin does, and we could do with SIXX. Dolphin serializes things not to avoid the image but to allow packaging. SIXX could do the same for us. [SNIP]

...

If we had something that could read and rewrite Smalltalk code that is truly independent of WB, then class methods would be nice way to store GUI designs.

Bill

Just wanted to chip in here - IMHO there is a loooong history when it comes to how to "save" UIs. We have seen (and in many different programming languages) various ways through the years:

- Build them with code each time we want them Pros: Resilient against framework/library changes Very readable and editable Easy to "store" in the language (just save as a method) Cons: Very hard to use as a "save format" Has too much freedom if we hand edit it

I actually favor the above since I normally dislike UI Designer tools :). But I can of course see the value of a really good UI designer (WB Pro is one of the best I have ever used, and the one in VisualAge was also superb).

- Save them in "dumb" data structures (like VW specs) Pros: A bit resilient since it relies on a builder, but not as good as code because it is just dumb data Similar easy to store in the language Cons: Not readable and editable

VW has used this for a long time and it is indeed pretty slick since you just "store" it in a method. That is one very nice characteristic, and if you have good options to dig into the builder after it has read the spec - then having the spec be "non readable/editable" is not that painful. But still, it is a bit of a serialization hack and ... doesn't feel quite right.

- Save them in a more advanced (than an Array) non Smalltalk langauge like XML Pros: Quite resilient against framework/library changes, if grammar is made to be declarative in style Easy to use as "save format" Cons: Get's complex and icky Not so easy to "store" in language (a String literal?) Not so readable and editable

IMHO using XML is "nice" (well...) for inter system and inter language communications/interchange. But realistically, how much interplay can we expect when we are talking about Morphic UIs? AFAIK the rest of the world haven't been able to gather around a single format either. If there indeed was a format that all the Gtk/Qts and whatnots out there used - then by all means. But is there?

- Serialize (in binary or whatever language like XML etc) them as they are in their object form and deserialize to instantiate Pros: Simple as save format, just smack it out Cons: Not resilient against framework/library changes, in fact very brittle Not readable nor editable Not so easy to "store" in langauge (ByteArray? String literal?

Serialization (as in "storing the object model exactly as it is") IMO almost only has drawbacks. It is very brittle when systems change and it is not readable nor editable etc. I just don't like it at all :)

Excellent summary/writeup !

Ok, sooo... not sure if I made the Pros/Cons clear enough to be understood here. Anyway, in my quest earlier to build Deltas and Deltastreams I ended up investigating "formats" and then I created Tirade:

http://goran.krampe.se/blog/Squeak/Tirade.rdoc http://goran.krampe.se/blog/Squeak/Tirade2.rdoc http://goran.krampe.se/blog/Squeak/Tirade3.rdoc

(sorry for lack of nice CSS there)

NOTE: Since those articles I have simplified it a bit - I scratched the complicated "stack" logic around figuring out the receiver.

Anyway, Tirade is in short a very long cascade that only allows arguments in literal forms. So basically Tirade doesn't serialize objects - it serializes a *sequence of messages*. And then when we "deserialize it" we replay those messages onto a receiver.

Thus, in syntax it is very Squeakish - it even uses the same number parser etc as the Compiler does. But it is a very restricted subset of Smalltalk which makes it fast and secure.

So, given the Pros/Cons above, let's see how Tirade would fit:

* Easy to read and edit: yes, it looks like Smalltalk, but without a receiver to the left.

* Easy to store in a method: yes, quite simple, the easiest way may be to save it as "Smalltalk" like this:

tiradeOn: recorder "Create Tirade by sending messages to a Tirade recorder." recorder message1; message2; message3

In that way you can still use senders/implementors etc of the message selectors.

* Easy to store outside of the language: yes, trivial, and fast to write and read

* Very resilient against framework/library changes if we use a declarative style.

Tirade looks cool, very nice idea, simple and powerful. Nice name too. Some questions: - don't you need a more formal (BNF) spec (I like the drawings on the http://json.org/ site) ? - 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 ? - should there not be some kind of convention to note the expected reader (in a comment as meta data maybe) ? - has this since 2009 been used anywhere ? - how about inter Smalltalk interoperability ? Sven

On 14 Feb 2011, at 10:28, Igor Stasenko wrote:

...

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

No. Wake up. Its 2011 outside. Use unicode encodings (like UTF-8) for reading/writing source streams. Just don't use ascii, then you won't need to escape non-ascii characters. :)

I know what UTF-8 encoding is and I know the date. However, then the Tirade spec should say, all data is encoded in UTF-8 by default, leaving it open like this is asking for problems. But even then, for a data interchange format I think that ASCII + enscaping is a better deal that will cause less problems. Sven

On 02/14/2011 09:59 AM, Sven Van Caekenberghe wrote:

On 14 Feb 2011, at 00:18, Göran Krampe wrote:

...

Ok, sooo... not sure if I made the Pros/Cons clear enough to be understood here. Anyway, in my quest earlier to build Deltas and Deltastreams I ended up investigating "formats" and then I created Tirade:

http://goran.krampe.se/blog/Squeak/Tirade.rdoc http://goran.krampe.se/blog/Squeak/Tirade2.rdoc http://goran.krampe.se/blog/Squeak/Tirade3.rdoc

(sorry for lack of nice CSS there)

NOTE: Since those articles I have simplified it a bit - I scratched the complicated "stack" logic around figuring out the receiver.

Anyway, Tirade is in short a very long cascade that only allows arguments in literal forms. So basically Tirade doesn't serialize objects - it serializes a *sequence of messages*. And then when we "deserialize it" we replay those messages onto a receiver.

Thus, in syntax it is very Squeakish - it even uses the same number parser etc as the Compiler does. But it is a very restricted subset of Smalltalk which makes it fast and secure.

So, given the Pros/Cons above, let's see how Tirade would fit:

* Easy to read and edit: yes, it looks like Smalltalk, but without a receiver to the left.

* Easy to store in a method: yes, quite simple, the easiest way may be to save it as "Smalltalk" like this:

tiradeOn: recorder "Create Tirade by sending messages to a Tirade recorder." recorder message1; message2; message3

In that way you can still use senders/implementors etc of the message selectors.

* Easy to store outside of the language: yes, trivial, and fast to write and read

* Very resilient against framework/library changes if we use a declarative style.

Tirade looks cool, very nice idea, simple and powerful. Nice name too.

Some questions:

- don't you need a more formal (BNF) spec (I like the drawings on the http://json.org/ site) ?

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.

Craig, Fantastic wishlist! However, maybe because the synthetic nature of the proposal, 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? -- Cesar Rabak Em 14/02/2011 08:14, Craig Latta < craig@netjam.org > escreveu: Hi Göran-- Thanks for the summary! I think there's another option as well. If you have... - the ability to transfer methods directly between live systems, without having to recompile source code - a way of specifying groups of methods ("modules"), and prerequisite relationships between those groups ...then you can... 1. Compose a GUI using a direct-manipulation editor. 2. Represent the state of that GUI with an object (which probably makes references to several other objects). 3. Create a method that refers to that object. (One way to store the object would be as a class variable.) 4. Transfer that method to another live system. The method is probably little more than asking the GUI object to render itself. If you want to know more about how the GUI object was created, you can ask it that too. The method's module specifies at least of the GUI framework as a prerequisite. You can have as many different GUI frameworks around in a system as you like, perhaps introducing some as others are phased out. Perhaps message interfaces common to all of them will emerge over time. All along the way one uses familiar tools to inspect and change state and behavior. Although source code isn't necessary for transferring behavior from one system to another, it's all still readable. This scheme is readable, editable, easy to store, and amenable to framework change (the four things you were after). thanks again, -C -- Craig Latta www.netjam.org/resume +31 06 2757 7177 + 1 415 287 3547

Em 15/02/2011 20:28, Craig Latta < craig@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

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

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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Craig Latta [craig@netjam.org] Sent: Thursday, February 17, 2011 8:04 PM To: pharo-project@lists.gforge.inria.fr 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? :)

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

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, 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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Craig Latta [craig@netjam.org] Sent: Friday, February 18, 2011 6:42 PM To: pharo-project@lists.gforge.inria.fr 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

In Dolphin, one can cope with that fairly easily - most of the time. The trick is to change the affected class' serializing version number, which causes the loader to seek help reading old serialized data, which arrives as an array. Streams work well for adapting the old array into an array that is correct for the current version. I have not used SIXX long enough to encounter this in a significant way. SIXX appears to depend on messages/apsects, where Dolphin's serializer deals directly in instance variables. My guess is that SIXX will be tolerant of changes that would clobber Dolphin's serializer, but that Dolphin provides tools to handle it. SIXX has something too; I have not needed it yet. One thing about SmartReferenceStream: the conversion methods go in the serializer itself; they belong in the affected class, or in its proxy if one is used. SmartReferenceStream also assumes that user==developer :( Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Monday, February 14, 2011 3:41 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] A new GUI visual designer What is happening if the class of your application UI gets a new variables or if a superclass changes its structure? May be in objective-C you have to resave your nib? Stef DynaBook.

tx!

Here is more information:

http://stackoverflow.com/questions/596382/what-describes-an-outlet-best-in-o... http://developer.apple.com/library/mac/#documentation/DeveloperTools/Concept...

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:

I do not really like QT and would prefer somethink more mac like.

On Tue, Feb 15, 2011 at 9:21 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: tx!

...

Here is more information:

http://stackoverflow.com/questions/596382/what-describes-an-outlet-best-in-o... http://developer.apple.com/library/mac/#documentation/DeveloperTools/Concept...

...

no updatable;

???

...

only could be modified for the same designer routine.

???

Can you modify manually the code generated for the UI Painter of VW? I´m not; I´m not mutant :) The use of XAML or XUL is for portability. Exists many tools for design a GUI in XAML or XUL. The perfect GUI designer already exists. In all Smalltalks implementations, ALL, don´t exists a best GUI Builder of that tools. I don´t understand how we can think could create one easily, of the same level, if not exists in any Smalltalk, include commercials. The UI Painter and widgets of VW is pathetical... that is the example to copy??? Well, we can still dreaming. And talking. Regards. -- View this message in context: http://forum.world.st/A-new-GUI-visual-designer-tp3067111p3303152.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

WindowBuilder is impressive. I'm not sure how to clean room it though. If the concern is over the serialization of objects, has anyone considered SIXX for that? Doing that could give us something similar to the Dolphin ViewComposer but clearly of distinct origin. To the result, we could add some features of WindowBuilder (adding event handlers, etc.). Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Hernán Morales Durand [hernan.morales@gmail.com] Sent: Saturday, February 12, 2011 5:04 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] A new GUI visual designer 2011/2/12 nullPointer <epicfan@gmail.com>:

...

...

no updatable;

...

???

...

...

only could be modified for the same designer routine.

...

???

Can you modify manually the code generated for the UI Painter of VW? I´m not; I´m not mutant :)

The use of XAML or XUL is for portability. Exists many tools for design a GUI in XAML or XUL. The perfect GUI designer already exists. In all Smalltalks implementations, ALL, don´t exists a best GUI Builder of that tools. I don´t understand how we can think could create one easily, of the same level, if not exists in any Smalltalk, include commercials. The UI Painter and widgets of VW is pathetical... that is the example to copy???

Take a look at WindowBuilder Pro, is the most professional GUI Builder for Smalltalk. Cheers, Hernán

XML suxxx.... XAML or XUL suxxxs too? regards. -- View this message in context: http://forum.world.st/A-new-GUI-visual-designer-tp3067111p3303424.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

On Feb 11, 2011, at 5:23 PM, Tobias Pape wrote:

Hi again

Am 2011-02-11 um 14:26 schrieb Stéphane Ducasse:

...

...

How do they compare with announcements and event and #changed

In the case of the UIBuilder of void, there are new widgets that extend existing ones but It would be better to not subclass and get better widgets.

What prevents you from making new widgets?

Nothing and this is the point in the case of I would prefer to have totally new widgets instead of long list of hiearchy like PluggableButtonMorphPlus. So I did not check the code of Builder so may be you do not do that and this is good. But it requires TIME to have a real look: not just load and say this is loading.

It's just a default set. If you want them _not_ to be heirs of existing ones, new ones can be made.

can you explain because may be my english does not catch it correctly?

...

[…] use of _,

I am really interested what you meant by this.

- vs := use Apparently rob vens tried to load your code in pharo and he could not. I did not have the time to check that.

So Long, -Tobias

Hi marcel thanks for this post

Hi.

I wrote these Widgets and the Morphic Designer mostly from scratch. There is almost no stacking of libraries. ;)

Good news. Now do they replace in functionality existing ones? I mean - do they are new? - can/should they replace existing ones? - in such a case are the API compatible?

Widgets need Signals and Animations which I also wrote from scratch and which do not have any dependencies other than Squeak 4.1 and later.

I saw that but did not get the time to look deeply in the code.

For now, I reused:

- PluggableTextMorph - TextMorphForEditView - ScrollBar - ScrollPane

These I plan to replace them with new ones as well.

The code itself is http://www.opensource.org/licenses/mit-license.php MIT licensed as stated https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki here .

I did the whole thing, because I did not like, how the classic tool builder works or how pluggable morphs are meant to be used.

I'm too bad with UI to access that. I know that this is not really good. So I would be happy to get a better solution. Alain if you have some **cough** *cough** time can you have a look at this project?

Signals could definitely be integrated into Squeak (trunk) because I fixed the last serious bugs back in the last months as I worked with signals in several projects in a productive way.

Obviously, I adapted the API and some great ideas of the http://qt.nokia.com/ Nokia/Qt Framework . So you could say that some widgets or the signals are just a port from C++ to Squeak. There shouldn't be any licensing issues.

All widgets use several icon packages that are also meant to be used for community purposes and reflect the correct license at source code level just now:

applicationCascadeIcon

...

"Auto-generated.

Silk Icons © 2005-2006 Mark James Website: http://www.famfamfam.com License: http://creativecommons.org/licenses/by/2.5"

^ Icons at: #silkApplicationCascade ifAbsentPut:[ Form fromBinaryStream: (Base64MimeConverter mimeDecodeToBytes: self applicationCascadeIconContents readStream) ].

-- View this message in context: http://forum.world.st/A-new-GUI-visual-designer-tp3067111p3302461.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.