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
