A new GUI visual designer

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

It really looks very professional. I made a user interface builder for Polymorph, which I left because I was too complicated for me. I hope that now someone more knowledgeable can really necessary to implement a tool for Squeak / Pharo as a visual designer user interfaces.

Regards

On 1 December 2010 12:48, nullPointer <[hidden email]> wrote:
>
>
> https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/designer
>
> It really looks very professional. I made a user interface builder for
> Polymorph, which I left because I was too complicated for me. 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.


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



--
Best regards,
Igor Stasenko AKA sig.

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

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

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

@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:

@NullPointer: you did a lot of work

Now this is not clear how the code is generated even in this new one.

tobias

Is a windowspec like in VW is used to store?

Can we reopen a interface that was developed with the UI builder?

Stef

Wahooo!!, I didn´t see that screencast:

https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/raw-attachment/wiki/designer/screencast_1.mp4

Really spectacular :))

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?  

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

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?

So Long
        -Tobias

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

Am 2011-02-11 um 14:26 schrieb Stéphane Du casse:
oO did other pharo-development _not_ involve engineering?

>>>
>>
>> I do not understand that.
>> Can you elaborate?
>
> do we want signal?
> 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/signals
https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/signals#FeatureComparison

>
> In the case of the UIBuilder of void,

Void?

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

> May be fixing copy/postcopy,

what?
> use of _,

what?
> ...... references to Preferences,....

Then, what about a -PharoCompat package?

> This kind of work.


Pleas let me quote your initial mail:
>>> We cannot stack libraries.

I'd like to understand that, please.


So Long
        -Tobias

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?
It's just a default set. If you want them
_not_ to be heirs of existing ones, new ones
can be made.
> […]
> use of _,


I am really interested what you meant by this.

So Long,
        -Tobias

Hi.

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

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.

For now, I reused:

- PluggableTextMorph
- TextMorphForEditView
- ScrollBar
- ScrollPane

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

The code itself is MIT licensed as stated 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.

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

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

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

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/signals
> https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/signals#FeatureComparison

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

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

I was rereading that and I will take me time to deeply understand the table.


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

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

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.

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ó: