Button-Tutorial

Hi Chris,

danke für das Tutorial, aber ich hab es ein wenig umbenannt...
Es heisst jetzt Einführung in Events (oder so)

Der Grund: Es gibt zumindest zwei Wege, einen Button einfacher
zu machen, als Du ihn beschreibst:

Zum einen via E-Toys, das habe ich zunächst mal erklärt (Bilder lade
ich up,
sobald ich das Upload-Kennwort wieder weiß), zum zweiten, wenn Du es
"textprogrammatisch" machen möchtest, brauchst Du "nur" die
handlesMouseDown: und handlesMouseOver: in
Morph zu überschreiben und kommst dann ganz ohne when:... aus.

Anbei ein Beispiel.

Viele Grüße,

Markus

p.s. Ich habe mal ein Video gemacht, ich brauche momentan
10 MB Quicktime um das "E-Toy Rechteck-Rahmen wird rot wenn Maus-drüber"
mit Sprache zu erklären. Ich lade es drauf, wenn ich an der Uni bin.

p.p.s. Hat schon jemand angefangen, die Texte in der World auf Deutsch
zu übersetzen? Wir könnten dann das Framework der Japaner benutzen,
um alles(!) in der E-Toy-Welt auf deutsch zu haben.
Bitte einfach auf http://swiki.squeakfoundation.org/squeak-ev/7 
weitermachen...

Super wäre natürlich auch ein Screenshot und eine Erklärung der
jeweiligen
Werkzeuge.


 

Hi Markus,

> Der Grund: Es gibt zumindest zwei Wege, einen Button einfacher
> zu machen, als Du ihn beschreibst:

Darüber kann man streiten ;-)

> Zum einen via E-Toys, das habe ich zunächst mal erklärt (Bilder lade
> ich up, sobald ich das Upload-Kennwort wieder weiß), zum zweiten,
> wenn Du es "textprogrammatisch" machen möchtest, brauchst Du "nur"
> die handlesMouseDown: und handlesMouseOver: in
> Morph zu überschreiben und kommst dann ganz ohne when:... aus.

Schon, schon, aber die Frage ob #handlesMouseDown: einfacher ist als
"on:send:to:" ist schwierig zu beantworten. Es gibt zumindest zwei Probleme
damit: Zum einen muss man sich an fünfhundert verschiedene #handlesFooBar:
Methoden erinnern, und wenn man eine vergisst passiert rein gar nix (und
solche Sachen sind wirklich schwer zu finden). Demzufolge ist das "explizite
Setup" mittels #on:send:to: u.U. einfacher zu merken - es hat weniger
Constraints (die Methode kann irgendwie heissen) und man muss sich nur ein
Konzept merken. Zudem ist das Setup zentralisiert, was bedeutet das wenn
jemand rausfinden möchte "was dieses Ding macht" kann er in die
Initialisierung reinschauen und muss nicht wild durch die Klasse browsen.

Zum anderen, ist die Implementation von #mouseDown: o.ä. Methoden eigentlich
eine Modifikation des Frameworks, was bedeutet, man muss zwangsläufig die
"super" Methoden verwenden, was für mich eine (unnötige) Verkomplizierung
des Tutorials darstellt. Du bist Dir übrigens bewusst, dass Dein Beispiel
buggy ist, oder?! ;-) Weder #mouseEnter:, noch #mouseLeave:, noch #mouseUp:
verwenden die "super" Implementationen, was sie eigentlich müssten (nicht so
in Chris' Beispiel).

Der einzige echte "Nachteil" der Verwendung von #on:send:to: ist, dass der
Eventtrigger "zu weit entfernt" von der Methode ist, die darauf reagiert
(und die Syntax ist auch nicht unbedingt trivial). Hier sind die eToys weit
überlegen. Selbiges übrigens für #triggerEvent: etc.

Ob es aber "einfacher" ist, eine korrekte Implementation der Eventhandler zu
schreiben oder #on:send:to: zu benutzen kann man also bezweifeln.

Ciao,
  - Andreas

Am Samstag, 29.03.03 um 17:30 Uhr schrieb Markus Gaelli:
> p.p.s. Hat schon jemand angefangen, die Texte in der World auf Deutsch
> zu übersetzen? Wir könnten dann das Framework der Japaner benutzen,
> um alles(!) in der E-Toy-Welt auf deutsch zu haben.
> Bitte einfach auf http://swiki.squeakfoundation.org/squeak-ev/7 
> weitermachen...

Um gute Begriffe zu finden ist Kontext nötig. Dabei kann uns der Swiki
ungemein helfen. Um auch "Butter bei die Fische" zu tun habe ich das
mal eben probiert:

http://swiki.squeakfoundation.org/squeak-ev/62

Um zu sehen wie "Schublade" statt "Leiste" für "Flap" wirkt, braucht
man nur den Seitentitel zu ändern, und schwupp ändert sich das überall
:-)

Und nebenbei entsteht so gleich eine deutsche allgemein-verständliche
Anleitung.

-- Bert

Hi Leute,
>
>> Der Grund: Es gibt zumindest zwei Wege, einen Button einfacher
>> zu machen, als Du ihn beschreibst:
>
> Darüber kann man streiten ;-)
Here we go... :-) Nein, im Ernst, an alle zu posten, dass ich gleich
zwei einfachere Lösungen wüsste, und dann auch noch Chris Seite
umzubenennen, war ein wenig großspurig von mir. Ich hätte mich
natürlich vorher mit ihm darüber abstimmen müssen, sorry,
soll nicht mehr vorkommen.

Ich denke, die Diskussion wirft aber eine wichtige Frage auf:

An wen richten sich unsere Tutorials? Haben wir eine Hauptzielgruppe?
Chris hat eher Smalltalk-Entwickler im Sinn, die eine gute
open-source Entwicklungsumgebung suchen, ich dachte eher an
Kinder/Eltern/Lehrer oder "Omniuser" (was war da gleich die beste
deutsche Übersetzung?)

Vielleicht sollten wir da mehrere Zweige aufmachen und in der
Überschrift klar machen,
für wen das Tutorial gedacht ist.

>> Zum einen via E-Toys, das habe ich zunächst mal erklärt (Bilder lade
>> ich up, sobald ich das Upload-Kennwort wieder weiß), zum zweiten,
>> wenn Du es "textprogrammatisch" machen möchtest, brauchst Du "nur"
>> die handlesMouseDown: und handlesMouseOver: in
>> Morph zu überschreiben und kommst dann ganz ohne when:... aus.
>
> Schon, schon, aber die Frage ob #handlesMouseDown: einfacher ist als
> "on:send:to:" ist schwierig zu beantworten.

Das Tutorial für den E-Toy Button nebst Screenshots und Filmaufnahme
ist mir wichtiger,
als die Antwort auf die Frage, welche der Smalltalk-Lösungen
tatsächlich einfacher
ist oder nicht. Trotzdem die längere Antwort zum anderen Teil:

> Es gibt zumindest zwei Probleme
> damit: Zum einen muss man sich an fünfhundert verschiedene
> #handlesFooBar:
> Methoden erinnern, und wenn man eine vergisst passiert rein gar nix
> (und
> solche Sachen sind wirklich schwer zu finden).
Stimmt, ein Problem was ich hatte, war, dass ich erstmal
#handlesMouseEnter:
anstatt #handlesMouseOver: überschrieben hatte, da tat sich auch erst
mal
nicht viel.
Wenn man mittels leerer Templatemethoden a la Morph >> #fooBar
die #handlesFooBar ganz loswürde, wäre das noch besser.
Aber die Schwierigkeiten, Morph zu vereinfachen,
sind genug diskutiert worden, vielleicht gibt es ja da demnächst was
besseres...

> Demzufolge ist das "explizite
> Setup" mittels #on:send:to: u.U. einfacher zu merken - es hat weniger
> Constraints (die Methode kann irgendwie heissen)
Könnte man in mouseDown: umleiten...
> und man muss sich nur ein
> Konzept merken. Zudem ist das Setup zentralisiert, was bedeutet das
> wenn
> jemand rausfinden möchte "was dieses Ding macht" kann er in die
> Initialisierung reinschauen und muss nicht wild durch die Klasse
> browsen.
Das Argument kommt mir schon vom Visitior-Pattern bekannt vor, ich mag
es
nicht so gern, weil wir ja sonst bei OO immer der Verteilung das Wort
reden,
bin wohl eher der wilde Typ :-) ...solange die Methodennamen sprechend
genug
sind, aber das ist vielleicht Mentalitätssache.

Vielleicht finde ich es auch einfach schwieriger, den richtigen
Event-Namen zu finden,
als die Methode, die ich überschreiben muss.

Wir sind uns einig, dass der E-Toy-Weg da der eleganteste ist. Ich verstehe aber nicht, warum ich super rufen muss.
Ich muss es dann rufen, wenn ich event-handling, wie Ihr es vorschlagt,
benütze.
Will ich ja nicht, alles was der Morph nach click tun soll, definiere
ich in mouseDown:
Oder was übersehe ich? YAGN.

Folgendes Snippet zeigt, dass der Prozentsatz von "super-rufern"  in
3.4 eher gering
ist:

#(#mouseDown: #mouseEnter: #mouseLeave:) collect: [:aSymbol |
someMethods := Morph allSubclasses select: [:e | e methodDict
includesKey: aSymbol].
someSuperCallers := someMethods select: [:e | (e methodDict at:
aSymbol) sendsToSuper
and: [(e superclass lookupSelector: aSymbol) = (Morph compiledMethodAt:
aSymbol)]].
someSuperCallers size / someMethods size]

#((11/71) (1/21) (1/18))

Wenn es denn falsch ist, bin ich zumindest nicht alleine... ;-)
Ist das dann was für die MorphCleaningGroup?

Viele Grüße,

Markus

Guten Morgen

Markus Gaelli wrote:
Korrekt! Ich richte mich eher an Entwickler, die im Sourcode arbeiten
und versuche immer so viel wie möglich 'Schnickschnack' zu vermeiden.
Das mag an meinem Unix Hintergrund liegen. Kann Vor- und Nachteil sein.
Deswegen hoffe ich auch auf ein kleines Image. Wenn ich mal eine
Netzwerkapplikation in Squeak baue, will ich nicht ständig Morphic oder
E-Toys bei Runtime mitschleppen.

> Vielleicht sollten wir da mehrere Zweige aufmachen und in der
> Überschrift klar machen,
> für wen das Tutorial gedacht ist.

Ich werde meine Squeak Sachen immer auf meiner Website pflegen. Von
daher ist es vielleicht sinnvoll, ein paar Worte auf dem Swiki zu
schreiben, wo die jeweilige Zielgruppe zum Ziel kommt, oder den Swiki in
der Kategorie eben zu untergliedern.

Genau! Ich krieg immer einen Hals, wenn ich mich durch manchmal 5
verschiedene Methoden durchklicken muss, bis ich die Funktionalität
finde, die ich suche.

Manchmal habe ich den Eindruck das Smalltalk Lernen zwar das Denken in
OO extrem fördert, aber einem noch lang nichts über Design beibringt.

Es kommt halt darauf an, ob der owner des Morph bei einem Event auch
noch etwas tun will und den Event noch haben will. Wie Andreas sagt,
sind es zwei verschiedene Frameworks.

Es ist nicht falsch, es schränkt nur eventuell noch benötigte
Funktionalität ein.

Ich bin sowieso der Meinung, das das Morphic Eventsystem auf das in
Object umgestellt werden sollte. Das ist zwar Arbeit, aber es schafft
mehr Übersicht. Ich hoffe auf MCP. Wenn Morph die gleiche Funktionalität
zur Verfügung hat, sollte es den kleinsten gemeinsamen Nenner nutzen ...
und der liegt semantisch gesehen in Object.

Ich habe mal versucht, in das Morphic Eventsystem einzutauchen und es
besser zu verstehen um es umzustellen, aber das habe ich nach zu viel
Klickerei im Browser aufgegeben.

schönen Sonntag
            Chris Burkert
--
------------------------------------------------------------------------
Student of applied Computer Science at Chemnitz University of Technology
      http://www.chrisburkert.de/            [hidden email]
------------------------------------------------------------------------
"I invented the term Object-Oriented, and I can tell you I did not have
  C++ in mind." - Alan Kay --> http://www.whysmalltalk.com/

Hallo Markus,

> Ich denke, die Diskussion wirft aber eine wichtige Frage auf:
>
> An wen richten sich unsere Tutorials? Haben wir eine Hauptzielgruppe?
> Chris hat eher Smalltalk-Entwickler im Sinn, die eine gute
> open-source Entwicklungsumgebung suchen, ich dachte eher an
> Kinder/Eltern/Lehrer oder "Omniuser" (was war da gleich die beste
> deutsche Übersetzung?)

Otto Normalbenutzer?! ;-) Ich hatte aber ganz deutlich den Eindruck, das
Chris' Tutorial doch eher an den Smalltalk-Interessierten Benutzerkreis
gerichtet ist (was völlig in Ordnung ist).

> > Schon, schon, aber die Frage ob #handlesMouseDown: einfacher ist als
> > "on:send:to:" ist schwierig zu beantworten.
>
> Das Tutorial für den E-Toy Button nebst Screenshots und
> Filmaufnahme ist mir wichtiger, als die Antwort auf die Frage,
> welche der Smalltalk-Lösungen tatsächlich einfacher
> ist oder nicht.

Das habe ich vermutet. Deswegen sagte ich auch man "kann" darüber streiten.

> > Zudem ist das Setup zentralisiert, was bedeutet das wenn
> > jemand rausfinden möchte "was dieses Ding macht" kann er in die
> > Initialisierung reinschauen und muss nicht wild durch die Klasse
> > browsen.
> Das Argument kommt mir schon vom Visitior-Pattern bekannt
> vor, ich mag es nicht so gern, weil wir ja sonst bei OO
> immer der Verteilung das Wort reden, bin wohl eher der
> wilde Typ :-)

Ich meinte mit dem "wilden Rumbrowsen" viel eher die Problematik, dass es
schwer für einen Benutzer ist die "relevanten" Information zu finden.
Typischerweise geht vieles bei der Benutzerinteraktion los, weswegen
Interaktionsmethoden oft der kritische Einstiegspunkt für das Verständnis
sind. Diese schnell finden zu können macht es deutlich einfacher, ein
generelles Verständnis der Funktionsweise eines Objektes zu erhalten.

> Wir sind uns einig, dass der E-Toy-Weg da der eleganteste ist.

Völlig.

> Ich verstehe aber nicht, warum ich super rufen muss.
> Ich muss es dann rufen, wenn ich event-handling, wie Ihr es
> vorschlagt, benütze. Will ich ja nicht, alles was der Morph
> nach click tun soll, definiere ich in mouseDown:
> Oder was übersehe ich? YAGN.

Ja, Du übersiehst hier was und zwar "remote trigger". Zum Beispiel, wenn ich
einen Morph mit #on:send:to: benütze und Du dann reingehst und das
#mouseDown implementierst, dann geht mein Teil nicht mehr. Ohne, dass Du das
notwendigerweise mitkriegst.

> Folgendes Snippet zeigt, dass der Prozentsatz von "super-rufern"  in
> 3.4 eher gering ist:

Genau einer der Gründe warum mir bei Morphic regelmäßig der verlängerte
Rücken explodiert.

> Wenn es denn falsch ist, bin ich zumindest nicht alleine... ;-)
> Ist das dann was für die MorphCleaningGroup?

Nicht solange kein vernünftiges Benutzermodell da ist. Eines der
grundlegende Probleme hier ist, dass die Leute "mouseDown" sehen und dann
sagen "aha, so macht man das" - also die Framework-Implementation mit der
Framework-Benutzung verwechseln.

Ciao,
  - Andreas