Easy Morphic GUI

Hi,

Easy Morphic GUI (EMG) is a framework that allows building Morphic-
based GUIs without actually coding. Developers mainly use halos to  
parametrize morphs to fit the application needs. E-toys can also be  
used to make the GUI even more attractive.

Download EMG at http://csl.ensm-douai.fr/EasyMorphicGUI/
You can find there also a video tutorial :-)

Noury
------------------------------------------------------------------
Dr. Noury Bouraqadi - Enseignant/Chercheur
ARMINES - Ecole des Mines de Douai - Dept. I.A.
http://csl.ensm-douai.fr/noury

European Smalltalk Users Group Board
http://www.esug.org
------------------------------------------------------------------

Thank you Noury!

But your web page is password protected?

/Klaus

On Mon, 12 Feb 2007 18:00:28 +0100, Noury Bouraqadi wrote:

It seems to be username/password protected.

Noury Bouraqadi wrote:

--
brad fuller
www.bradfuller.com
+1 (408) 799-6124

Fixed. Now the page should be accessible.

Thanks for your notification,
Noury
Le 12 févr. 07 à 18:14, Brad Fuller a écrit :

Noury
------------------------------------------------------------------
Dr. Noury Bouraqadi - Enseignant/Chercheur
ARMINES - Ecole des Mines de Douai - Dept. I.A.
http://csl.ensm-douai.fr/noury

European Smalltalk Users Group Board
http://www.esug.org
------------------------------------------------------------------

Noury, thank you for this!

Hi Noury:

Look very interesting.

Cheers.

2007/2/12, Noury Bouraqadi <[hidden email]>:

--
Germán S. Arduino
http://www.arsol.biz
http://www.arsol.net

BTW, I just added the .OGG video version of the tutorial.
Thanks Hilaire Fernandes for doing the conversion.

Noury
Le 13 févr. 07 à 11:37, Germán Arduino a écrit :

Noury
------------------------------------------------------------------
Dr. Noury Bouraqadi - Enseignant/Chercheur
ARMINES - Ecole des Mines de Douai - Dept. I.A.
http://csl.ensm-douai.fr/noury

European Smalltalk Users Group Board
http://www.esug.org
------------------------------------------------------------------

It looks really cool!
Perhaps a something similar for Seaside would be great, if it does  
not exist...

Alexandre


Am Feb 12, 2007 um 5:00 PM schrieb Noury Bouraqadi:

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.cs.tcd.ie/Alexandre.Bergel
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Noury, the calculator examples don't have any GUI (which I suppose
would be in the #serializedPrototype on the class side of the GUI
classes?)

Le 13 févr. 07 à 17:30, Derek O'Connell a écrit :

> Noury, the calculator examples don't have any GUI (which I suppose
> would be in the #serializedPrototype on the class side of the GUI
> classes?)
>
Yes. This is because blocs are not serialized in the current version.  
And, I wanted to show some complex GUI with a list of operations to  
perform which requires blocs... I didn't find a satisfactory solution  
yet, though I didn't spend much time on it.

The roots of the problem is that I want to be able to store on  
monticello repositories the GUI. This question is subject to another  
running discussion thread (topic "How to store live objects in  
Monticello?")

Noury
------------------------------------------------------------------
Dr. Noury Bouraqadi - Enseignant/Chercheur
ARMINES - Ecole des Mines de Douai - Dept. I.A.
http://csl.ensm-douai.fr/noury

European Smalltalk Users Group Board
http://www.esug.org
------------------------------------------------------------------

Noury Bouraqadi wrote:
you can use LambdaMessageSends instead of blocks. they are semantically
equivalent and can be serialized.

see the LambdaMessageSend package on SqueakMap (there is an extensive
documentation in the form of test cases)


Stef

sorry, I meant the FunctionalTalk package !

Stef

Thanks for this Noury.  The interface building side of Morphic needs this kind of thing.

On the matter of serialisation, as alternative it would be nice (also) to be able to generate the objects from code but I don't think this is very easy.  Morphic is inconsistent between how coding works and how scripting works. (E.g. a morph responds to a forward: command in scripting but coding it involves messing around with (assuring) costumes - also the naming of components doesn't link to variable names very conveniently.)  An alternative to byte serialisation could be to generate full Smalltalk initialization code that can build the object fully from scratch - does this sort of code exist?

Yours

Bob

Le 14 févr. 07 à 14:53, Stéphane Rollandin a écrit :

Thanks Stéphane for the pointer. But, the problem is not because EMG  
uses blocks. The problem is that I want to target any kind of  
application, i.e. an application with arbitrary objects including  
blocks. So, I don't want to restrict users.

Noury
------------------------------------------------------------------
Dr. Noury Bouraqadi - Enseignant/Chercheur
ARMINES - Ecole des Mines de Douai - Dept. I.A.
http://csl.ensm-douai.fr/noury

European Smalltalk Users Group Board
http://www.esug.org
------------------------------------------------------------------

Noury Bouraqadi wrote:>
> Thanks Stéphane for the pointer. But, the problem is not because EMG
> uses blocks. The problem is that I want to target any kind of
> application, i.e. an application with arbitrary objects including
> blocks. So, I don't want to restrict users.


ok, sorry for the noise.


Stef

Le 15 févr. 07 à 04:48, Robert Hawley a écrit :

The idea is interesting. I'm not aware of such thing.
 From the discussion about I think that it doesn't exist.

Noury
------------------------------------------------------------------
Dr. Noury Bouraqadi - Enseignant/Chercheur
ARMINES - Ecole des Mines de Douai - Dept. I.A.
http://csl.ensm-douai.fr/noury

European Smalltalk Users Group Board
http://www.esug.org
------------------------------------------------------------------

Noury Bouraqadi a écrit :
A bad candidate is storeOn:
storeOn: is not able to handle complex object graphs...

I prototyped in VW public store a storeOn: like, named ProgramRebuilder.
It handles complex graphs, circularities etc...

You have to define a #rebuildProgramNodeOn: in each class you want to
save (like storeOn:). Otherwise you inherit from ugly instVarAt:put:
basicAt:put: construction messages (like storeOn:). It would be easy to
obtain a generic version based on instVarNames setters.
The difference with storeOn: is that you build a ProgramNode (Abstract
Syntax Tree) with help of a ProgramRebuilder. You can then use arbitrary
messages, loops, temporaries or other constructs...

Simple example:
Complex>>rebuildProgramNodeOn: aProgramRebuilder
     ^aProgramRebuilder
         receiver: real
         selector: #+
         argument: (aProgramRebuilder receiver: imaginary selector: #i)

Unlike storeOn:, you do not have to bother with parenthesis. The AST
printer will manage this for you.

But ProgramRebuilder does not write a single method. Due to byte code
limits, complex object generally cannot be rebuilt in a single
compilable method.
I used chunks and workspace variables (this was targetting saving on files).

The idea could be to replace chunk with methods, and workspace variables
  with another pool...

Maybe something like:
object1From: pool
      ^pool at: #object1 ifAbsentPut: [" code for building object1 "]