[Pharo-project] A new GUI visual designer
Das.Linux at gmx.de
Sat Feb 12 18:22:03 CET 2011
Am 2011-02-12 um 09:54 schrieb Stéphane Ducasse:
> 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....
>>>>> 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”
> 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,
> 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.
>>> May be fixing copy/postcopy,
> in pharo we use postcopy
So does Squeak.
>>> use of _,
> 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.
More information about the Pharo-project