[Pharo-project] A new GUI visual designer

Tobias Pape Das.Linux at gmx.de
Sat Feb 12 18:22:03 CET 2011


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.
I just was astonished that you denied the usability of 
the Gui builder with just few very general words.

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

I know.

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

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

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

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

> 
> 
>>> In the case of the UIBuilder of void,
>> 
>> Void?
> The nikname of the personn

He is called Marcel and posted elsewhere in the thread.

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

No Objection.

> 
> 
>>> May be fixing copy/postcopy,
>> 
>> what?
> 
> in pharo we use postcopy

So does Squeak.

> 
>>> use of _,
>> 
>> what?
> 
> ???
> we should not have _ 
> rob vens told me that there are _ in the BUilder code

I doubt that there are _ assignments.

> 
> 
>>> ...... references to Preferences,....
>> 
>> Then, what about a -PharoCompat package?
> 
> I did not see it.

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

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


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

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

So Long,
	-Tobias





More information about the Pharo-project mailing list