Benutzerdefinierte Bottom Bar

Original von mattik

Original von Tom9811
Es ist überhaupt kein Problem, sondern das richtige Verhalten. Weil dann in der Buttonzeile ohnehin rote und grüne Buttons sind und die Leiste eben die Farbe eines disabled zeigt.

Nein, rot wäre nicht richtig. Richtig wäre, da gar keinen Rand drum zu zeichnen, weil es kein Button ist. Es ist eine passive Fläche.

Und bei einer Buttoncell wäre das anders? Du meinst einen aktiven Button zu zeichnen sieht irgendwie passiver aus? Irgendwie kann ich dir hier nicht folgen.

Original von Tom9811
Also, gerade dieses Beispiel zeigt mir, dass die Farbe eines diabled gerade richtig ist!

Nur sieht die disabled-Version des Button dummerweise nicht so aus wie vom OP gewünscht.

Die Fläche zeigt etwas Passives. Bei dir zeigt sie etwas Aktives.

Original von Tom9811
Welche Events außer dem Neuzeichnen-Event sollen denn an einen disabled Button weitergeleitet werden?

Keine Ahnung. Es interessiert mich auch nicht. Button und ButtonCell können meinetwegen untereinander machen, was sie wollen. Ich rate nicht, ich weiß, dass in meinem View nichts anderes weitergeleitet wird.

Ich rate auch nicht. Ein disabled Button ist disabled.

Original von Tom9811
Ein Button-Control dürfte kaum Sourcecode besitzen, der sich nicht damit beschäftigt, irgendwas an seine Cell weiterzuleiten. Sonst würden nämlich Buttons in Tableviews nicht funktionieren. Mir fällt jetzt jedenfalls keine Funktionalität ad hoc ein, die einee reine Cell in einem Tableview weniger hätte.

Ich möchte eben nicht darüber spekulieren müssen, was die Innereien von Cocoa wohl tun. Ich baue mir lieber eine Lösung, in der mich das nicht interessieren muss.

Ich spekuliere nicht.

Ich möchte aber nicht spekulieren müssen, was Apple irgendwann mit irgendwelchen Cells in irgendwelchen Buttons macht. Deshalb nehme ich einen Button. Dann weiß ich: Das sieht aus wie ein Button.

Du hingegen spekulierst ganz schön darauf los, dass eine einzelne Buttoncell so aussieht wie ein Button.

Als nächstes spekulierst du darauf, dass das reine Zeichnen nur ein View verlangt, kein Control. Immerhin siehht das die Dokumentation anders. Die spricht nämlich davon, dass der "Besitzer" eine Instanz von NSControl oder einer Subklasse ist.

Original von Tom9811
Du willst also in deiner eigenen Klasse etwas herausnehmen, was ohnehin keine Funktionalität bietet. Ob ob das Ding in der Hierarchie NSButton oder NSHannoSeppCornflakes heißt, dürfte von keinem Interesse sein.

Wie das Ding heißt ist mir egal (außer in dem Fall von NSHannoSeppCornflakes - siehe seb2). Aber die Vererbungshierarchie hat eine Semantik: <Unterklasse> IS A <Oberklasse>. Das ist elementares OO-Prinzip und lässt sich nicht wegdiskutieren. Und die Fläche ist kein Button. Es ist eine passive Fläche.

Und eine Buttoncell verlangt ein Control und keine Fläche. So rein vom elementaren OO-Prinzip aus betrachtet.

Original von Tom9811
Damit hat man dann garantiert das Aussehen und garantiert keine Funktionalität.

Stimmt. Genau wie mit der anderen Lösung, nur komplizierter und ineffizienter.

Stimmt, sich einen Button im IB in ein Fenster zu ziehen, ist ziemlich unkompliziert.
(Falls du es noch nicht bemerkt hast: Das war ein Witz, wie kompliziert man es sich machen kann.)

Original von Tom9811
Ich würde ja einfach einen disabled Button nehmen …

Dann mach das - und schalt' mal beim Testen VoiceOver ein...

Und?

Original von Tom9811
Du meinst einen aktiven Button zu zeichnen sieht irgendwie passiver aus? Irgendwie kann ich dir hier nicht folgen.

Sie sieht so aus wie im Bild des OP. Und die Frage dazu war, wie man einen solchen View erstellt, nicht ob das sonderlich affordant oder Guideline-konform ist.

Original von Tom9811
Ich rate auch nicht. Ein disabled Button ist disabled.

Und Du schließt daraus, dass dann irgend eine Kommunikation nicht stattfindet. Das ist aber nicht Deine Sache, sondern einzig und alleine die zwischen Button und Cell.

Original von Tom9811
Du hingegen spekulierst ganz schön darauf los, dass eine einzelne Buttoncell so aussieht wie ein Button.

Das ist keine Spekulation, sondern die definierte Aufgabe der Cell:

NSButtonCell Class Reference
The NSButtonCell class implements the user interface of NSButton.

Original von Tom9811
Als nächstes spekulierst du darauf, dass das reine Zeichnen nur ein View verlangt, kein Control. Immerhin siehht das die Dokumentation anders. Die spricht nämlich davon, dass der "Besitzer" eine Instanz von NSControl oder einer Subklasse ist.
[...]
Und eine Buttoncell verlangt ein Control und keine Fläche. So rein vom elementaren OO-Prinzip aus betrachtet.

Dann hast Du eine andere Dokumentation als ich. Bei mir steht:

NSButtonCell Class Reference
It can also be used for any other region of a view that’s designed to send a message to a target when clicked.

Einen Dummy-Message-Teil kann man noch implementieren, allerdings _weiß_ ich, dass niemals ein Klick bei der Cell ankommen wird.

Original von Tom9811
(Falls du es noch nicht bemerkt hast: Das war ein Witz, wie kompliziert man es sich machen kann.)

Nee, das hatte ich in der Tat nicht bemerkt - wenn Du etwas sagst, nehme ich es immer für bare Münze... aber im Nachhinein: Ziemlich witzig

Original von Tom9811
Ich würde ja einfach einen disabled Button nehmen …

Dann mach das - und schalt' mal beim Testen VoiceOver ein...

Und?[/quote]
Zumindest bei mir sagt er, dass da ein Button wäre, wo nur eine passive Fläche ist. Richtig geht anders.

darf ich mal fragen warum das eine passive fläche ist? schließlich macht sie ja was wenn man drauf klickt. also aus meiner sicht ist das durchaus ein "button-ähnliches" Element. es würde wie ich finde sogar sinn machen wenn man es "eindrücken" kann. aber vllt seh ich das auch falsch, also nicht guideline konform.

Schau einfach mal eine Superklasse (NSActionCell) höher.

Aber ich verstehe immer noch nicht, warum eine Buttoncell, die enable hat, sich passiver und konformer zu einem Button verhalten soll als ein Button.

Ich habe einfach den festen Glauben daran, dass sich Buttons von Apple immer so verhalten werden wie Butttons von Apple.

Schau einfach mal eine Superklasse (NSActionCell) höher.

Aber ich verstehe immer noch nicht, warum eine Buttoncell, die enable hat, sich passiver und konformer zu einem Button verhalten soll als ein Button.

Ich habe einfach den festen Glauben daran, dass sich Buttons von Apple immer so verhalten werden wie Butttons von Apple. Shcon gar nicht verstehe ich, warum ich, um dieses Ergebnis zu erreichen, etwas anderes nehmen soll, was dann auch noch so tut, als ob es ein Control wäre,

Also:
Ich nehme kein Control.
Davon habe ich nichts.
Aber ich leite mir meine eigene Klasse ab.
Davon habe ich immer noch nichts.
Und dann fake ich dort (teilweise) einen Control.

Hmmm …

Und gleich einen Faktor inkonfomer. Wie sieht denn der Verlauf in .6 aus? Wie heißt sie denn? topGradientButtonColor und bottomGradientColor? Oder gibt es dann noch ein left/right/middle/center?

Was ist eigentlich der Vorteil der Methode, etwas, was wie ein Button aussehen soll, nicht durch einen Button darzustellen?

Original von karrade
darf ich mal fragen warum das eine passive fläche ist? schließlich macht sie ja was wenn man drauf klickt. also aus meiner sicht ist das durchaus ein "button-ähnliches" Element. es würde wie ich finde sogar sinn machen wenn man es "eindrücken" kann. aber vllt seh ich das auch falsch, also nicht guideline konform.

Es geht nur um die Zwischenräume. Und offenbar fühlen sich einige dazu berufen, unbedingt etwas eigenes zu machen, in das man dann doch wieder ein Standardelement legt, wobei man das eigene faken muss, damit das Ganze nicht mit der Doku kollidiert.

Oder man nimmt einen Button. Weil: Der sieht aus wie ein Button. Aber mutmaßlich ist das zu einfach.

Original von Tom9811
Und offenbar fühlen sich einige dazu berufen, unbedingt etwas eigenes zu machen, in das man dann doch wieder ein Standardelement legt, wobei man das eigene faken muss, damit das Ganze nicht mit der Doku kollidiert.

Es ist doch in diesem Thread schon mehrfach deutlich gemacht worden, dass es dumm waere, auf die Blue-Ribbon-Art den Hintergrund manuell zu zeichnen und darauf zu hoffen, dass er Standardelementen aehnlich sieht. Mit dem Argument verkaufst Du uns Disabled-Button-Ablehner ein bisschen zu billig.

Original von Tom9811
Oder man nimmt einen Button. Weil: Der sieht aus wie ein Button. Aber mutmaßlich ist das zu einfach.

"Einfach" ist abhaengig vom real existierenden Programm: Neulich wollte ich in so einem Hintergrund-View einen Subview haben, wie neulich schon angedeutet, der sich nicht durch die von Dir vorgeschlagene "Wir stellen den NSButton-Hintergrund neben den NSButton-Vordergrund"-Taktik haette verwirklichen lassen. Da haett' ich, wenn ich einen Button verwenden haette wollen, einen Custom-View zum NSButton umdeklarieren und seine Eigenschaften per Code festlegen muessen. Die Knoepfe andererseits sind am Ende eh meistens Eigengewaechse (guter alter PMContextButton und Nachfahren), wie gesagt, wegen der Highlighterei und der Position der Pop-Up-Menues (Buendigkeit mit dem linken Rand) und so weiter.

Sowas vermeide ich, indem ich ein paar Standardklassen habe, die fuer solche Knopfleisten immer wieder zum Einsatz kommen. Manchmal moegen sie NSKanonenAufSpatzen sein, aber dafuer muss ich nur selten darueber nachdenken, weil's immer funktioniert.

Da faellt mir noch ein klarer Folklore-Schwank ein: Ich weiss noch, als ich die erste nicht-oeffentliche Quicksilver-Beta gesehen hab'. Die war voll von solchen Hintergrund-NSButtons, und ich bin Nick damit auch gehoerig auf die Nerven gegangen. Am Ende hat er sich von den NSButton-Hintergruenden aber tatsaechlich verabschiedet.

Original von karrade
darf ich mal fragen warum das eine passive fläche ist? schließlich macht sie ja was wenn man drauf klickt.

Was soll die leere Fläche neben den Knöpfen denn machen, wenn man drauf klickt?

Original von Tom9811
Schau einfach mal eine Superklasse (NSActionCell) höher.

Ich glaube fest daran, dass für NSButtonCell die Doku zu NSButtonCell ausschlaggebend ist. NSActionCell mag strengere Vorgaben haben, NSButtonCell hat sie nicht. Hatten wir ja schon mal: DBC und das Liskovsche Substitutionsprinzip.

Original von Tom9811
Also:
Ich nehme kein Control.
Davon habe ich nichts.
Aber ich leite mir meine eigene Klasse ab.
Davon habe ich immer noch nichts.
Und dann fake ich dort (teilweise) einen Control.

Ich will etwas haben, was kein Button ist, aber so aussieht. Also baue ich mir etwas, was kein Button ist, aber so aussieht. Und das mache ich, indem ich den gleichen Zeichenmechanismus benutze, den auch ein Button nutzt. Fertig.

Du kannst einen Button so oft disablen, wie Du willst. Es bleibt ein Button.

Original von mattik

Original von karrade
darf ich mal fragen warum das eine passive fläche ist? schließlich macht sie ja was wenn man drauf klickt.

Was soll die leere Fläche neben den Knöpfen denn machen, wenn man drauf klickt?

anzeigen das man sie geklickt hat und nun bewegen kann? ich dachte dafür wäre sie da, ich finde das sogar in gewisser weise inkonsequent das man sie nicht "drucken" kann.

Original von Peter Maurer

Original von Tom9811
Und offenbar fühlen sich einige dazu berufen, unbedingt etwas eigenes zu machen, in das man dann doch wieder ein Standardelement legt, wobei man das eigene faken muss, damit das Ganze nicht mit der Doku kollidiert.

Es ist doch in diesem Thread schon mehrfach deutlich gemacht worden, dass es dumm waere, auf die Blue-Ribbon-Art den Hintergrund manuell zu zeichnen und darauf zu hoffen, dass er Standardelementen aehnlich sieht. Mit dem Argument verkaufst Du uns Disabled-Button-Ablehner ein bisschen zu billig.

Es gibt ja zwei Kategorien der Gegner, also insgesamt drei Ansichten:
1) Diabled Button (ich)
2) Custom-View + Button-Cell (mattik)
3) Custom-View mit Gradient (einige, zuletzt (nach 15.00 Uhr) doch auch seb2, wenn ich ihn richtig verstanden habe)

Es gibt daher nicht die Gruppe der Pros und Cons. Ganz im Gegenteil. Die Gruppe 3 unterscheidet sich in der Implementierung deutlich von 1 (ich) und 2 (mattik). Das hat mattik auch schon ausdrücklich gesagt.

Dieser Beitrag bezog sich 2): Ein reines View kann nicht "Besitzer" einer Action-Cell sein. Nachdem man also eine Action-Cell nimmt, die den View so aussehen lässt, wie ein Control, muss man dann noch für die Cell das Action-Target-Muster im View simulieren. Das ist dann aber ein Control.

Original von Peter Maurer

Original von Tom9811
Oder man nimmt einen Button. Weil: Der sieht aus wie ein Button. Aber mutmaßlich ist das zu einfach.

"Einfach" ist abhaengig vom real existierenden Programm: Neulich wollte ich in so einem Hintergrund-View einen Subview haben, wie neulich schon angedeutet,

Mein Beitrag war eine Antwort auf malik.

Original von Peter Maurer
der sich nicht durch die von Dir vorgeschlagene "Wir stellen den NSButton-Hintergrund neben den NSButton-Vordergrund"-Taktik haette verwirklichen lassen. Da haett' ich, wenn ich einen Button verwenden haette wollen, einen Custom-View zum NSButton umdeklarieren und seine Eigenschaften per Code festlegen muessen. Die Knoepfe andererseits sind am Ende eh meistens Eigengewaechse (guter alter PMContextButton und Nachfahren), wie gesagt, wegen der Highlighterei und der Position der Pop-Up-Menues (Buendigkeit mit dem linken Rand) und so weiter.

Ich kann dir hier zwar nicht folgen, was du meinst. Aber ich hatte auch auf malik geantwortet.

Original von Peter Maurer
Sowas vermeide ich, indem ich ein paar Standardklassen habe, die fuer solche Knopfleisten immer wieder zum Einsatz kommen. Manchmal moegen sie NSKanonenAufSpatzen sein, aber dafuer muss ich nur selten darueber nachdenken, weil's immer funktioniert.

Ich nehme auch eine Standardklasse: NSButton.

Original von Peter Maurer
Da faellt mir noch ein klarer Folklore-Schwank ein: Ich weiss noch, als ich die erste nicht-oeffentliche Quicksilver-Beta gesehen hab'. Die war voll von solchen Hintergrund-NSButtons, und ich bin Nick damit auch gehoerig auf die Nerven gegangen. Am Ende hat er sich von den NSButton-Hintergruenden aber tatsaechlich verabschiedet.

Original von mattik

Original von Tom9811
Schau einfach mal eine Superklasse (NSActionCell) höher.

Ich glaube fest daran, dass für NSButtonCell die Doku zu NSButtonCell ausschlaggebend ist. NSActionCell mag strengere Vorgaben haben, NSButtonCell hat sie nicht. Hatten wir ja schon mal: DBC und das Liskovsche Substitutionsprinzip.

NSButton hat die auch, weil sie auch das Action-Target-Pattern verlangt. Das ist der Relativsatz in deinem Dokuauszug. ("Der dumme Message-Teil" …)

Wie nennt man eigentlich gemeinhin so ein View, welches dem Action-Target-Muster folgt? Control?

Übrigens zitierst du auch ansonsten ganz richtig: Die Button-Cell implementiert das User-Interface eines Buttons. Nicht: Die Zeichnerei eines Buttons. Damit dieses User-Interface funktioniert, musst du nur noch aus deinem View einen Control machen, ach was, diesen "dummen Messsage-Teil" implementieren.

Und wozu das Ganze? Damit am Ende die Leiste so aussieht, wie ein aktiver Button, obwohl es das nun ganz gewiss nicht ist.

Original von mattik

Original von Tom9811
Also:
Ich nehme kein Control.
Davon habe ich nichts.
Aber ich leite mir meine eigene Klasse ab.
Davon habe ich immer noch nichts.
Und dann fake ich dort (teilweise) einen Control.

Ich will etwas haben, was kein Button ist, aber so aussieht. Also baue ich mir etwas, was kein Button ist, aber so aussieht. Und das mache ich, indem ich den gleichen Zeichenmechanismus benutze, den auch ein Button nutzt. Fertig.

Du kannst einen Button so oft disablen, wie Du willst. Es bleibt ein Button.

Ja, und ein View, welches eine ActionCell besitzt und das Action-Target-Muster implementiert, ist ein Control.

Du kannst das ganze auch von NSProxy ableiten, wenn du lustig bist. Glaube bloß nicht, dass nachdem du alles fakst, damit es funktioniert, du keinen Control hättest.

Original von Tom9811
Wie nennt man eigentlich gemeinhin so ein View, welches dem Action-Target-Muster folgt? Control?

Nein. Man nennt das View, das beim Klicken eine Mitteilung weiterleiten kann. Zumindest macht Apple das in der Doku so - lies nochmal: Da steht eben NICHT "It can also be used for other controls".

Für das AppKit ist ein Control etwas, was von NSControl ableitet. Ein Custom View, das etwas kann ist ein Custom View, das etwas kann.

Wenn Du einen Scheibenwischer an Dein Fahrrad baust, wird daraus nicht automatisch ein Auto.

Du vermischst Außen- und Innensicht. Von außen gesehen ist mein View ein View. Wie mein View das Zeichnen implementiert, ob es selbst einen Verlauf malt, das delegiert oder einen Regentanz aufführt geht die externe View-Hierarchie nichts an.

Der andere Teil ist die Innensicht. Das ist in meinem Fall die Sache zwischen meinem View und der NSButtonCell. Im Übrigen hatte ich nicht vor, einen Action-Target-Mechanismus zu implementieren. Ich hatte geschrieben, dass man leere Implementationen der Methoden schreiben könnte, wenn man es richtiger findet, es aber nicht notwendig sei, weil ich weiß, dass die NSButtonCell niemals einen Klick-Event bekommt und der Mechanismus somit niemals aktiv wird.

Original von Tom9811
Übrigens zitierst du auch ansonsten ganz richtig: Die Button-Cell implementiert das User-Interface eines Buttons.

Wozu auch das Zeichnen gehört. Diesen Teil nutze ich.

Original von Tom9811
Und wozu das Ganze? Damit am Ende die Leiste so aussieht, wie ein aktiver Button, obwohl es das nun ganz gewiss nicht ist.

Exakt das, na endlich! Genau das war die ursprüngliche Frage.

Original von Tom9811
Es gibt ja zwei Kategorien der Gegner, also insgesamt drei Ansichten:
1) Diabled Button (ich)
2) Custom-View + Button-Cell (mattik)
3) Custom-View mit Gradient (einige, zuletzt (nach 15.00 Uhr) doch auch seb2, wenn ich ihn richtig verstanden habe)

Grundsätzlich ist eine Entscheidung zu treffen:

1. Sollte man einen Button nehmen oder nicht?

Wenn man zu dem Ergebnis kommt, dass man statt eines Buttons einen Custom View nehmen sollte, ergibt sich eine zweite Frage:

2. Wie sollte man den Inhalt malen? a) Selbst zeichnen, b) an eine NSButtonCell delegieren, c) einen Regentanz aufführen.

Aber zu dieser Frage kommst Du ja gar nicht erst.

Original von mattik

Original von Tom9811
Es gibt ja zwei Kategorien der Gegner, also insgesamt drei Ansichten:
1) Diabled Button (ich)
2) Custom-View + Button-Cell (mattik)
3) Custom-View mit Gradient (einige, zuletzt (nach 15.00 Uhr) doch auch seb2, wenn ich ihn richtig verstanden habe)

Grundsätzlich ist eine Entscheidung zu treffen:

1. Sollte man einen Button nehmen oder nicht?

Wenn man zu dem Ergebnis kommt, dass man statt eines Buttons einen Custom View nehmen sollte, ergibt sich eine zweite Frage:

2. Wie sollte man den Inhalt malen? a) Selbst zeichnen, b) an eine NSButtonCell delegieren, c) einen Regentanz aufführen.

Aber zu dieser Frage kommst Du ja gar nicht erst.

Nö, ich habe mir die Frage als erstes gestellt und gleich mit "nicht selbst malen" beantwortet. Damit verbleiben nur noch 1 und 2.

Und die dortige frage ist es, einen Control mit Button-Cell (aka Button) zu nehmen oder ein View zu nehmen, welches selbst eine Button-Cell verwaltet und sich als Control tarnt.

Da habe ich mich fürs Original entschieden.

Original von mattik

Original von Tom9811
Wie nennt man eigentlich gemeinhin so ein View, welches dem Action-Target-Muster folgt? Control?

Nein. Man nennt das View, das beim Klicken eine Mitteilung weiterleiten kann. Zumindest macht Apple das in der Doku so - lies nochmal: Da steht eben NICHT "It can also be used for other controls".

*Räusper* NSControl implementiert das bereits, nicht erst NSButton. Damit haben sämtliche Controls das Action-Target!

Original von mattik
Für das AppKit ist ein Control etwas, was von NSControl ableitet. Ein Custom View, das etwas kann ist ein Custom View, das etwas kann.

Für das gesamte Laufzeitsystem kommt es für die Typisierung ausnahmslos auf das Können an. Ich habe noch nie erlebt, dass das Laufzeitsystem von sich aus fragt, was denn die Klasse ist.

Original von mattik
Wenn Du einen Scheibenwischer an Dein Fahrrad baust, wird daraus nicht automatisch ein Auto.

Nein, du nimmst aber einen Scheibenwischer und baust dann selbst so lande daran herum, bis es aussieht wie ein Auto. WEil du du dann damit nicht fahren darfst, fakst du auch noch die Zulassung. Und am Ende sagt du:
Ich halte jetzt so lange an, bis du sagst dass es ein Scheibenwischer ist!

Ich nehme halt ein Auto. Wie gesagt: Das ist mutmaßlich zu einfach.

Original von mattik
Du vermischst Außen- und Innensicht. Von außen gesehen ist mein View ein View.

Mal abgesehen davon, dass du ein Control fakst,
¢Quote]Wie mein View das Zeichnen implementiert, ob es selbst einen Verlauf malt, das delegiert oder einen Regentanz aufführt geht die externe View-Hierarchie nichts an.

Der andere Teil ist die Innensicht. Das ist in meinem Fall die Sache zwischen meinem View und der NSButtonCell.

Ich würde gegenüber der Cell von der Außenansicht sprechen.

Original von mattik
Im Übrigen hatte ich nicht vor, einen Action-Target-Mechanismus zu implementieren. Ich hatte geschrieben, dass man leere Implementationen der Methoden schreiben könnte, wenn man es richtiger findet, es aber nicht notwendig sei, weil ich weiß, dass die NSButtonCell niemals einen Klick-Event bekommt und der Mechanismus somit niemals aktiv wird.

Das weißt du woher? Du weißt, dass sich die Cel nicht mal vorab die Action merkt? Woher?

Die Doku verspricht das nicht.

Original von mattik

Original von Tom9811
Übrigens zitierst du auch ansonsten ganz richtig: Die Button-Cell implementiert das User-Interface eines Buttons.

Wozu auch das Zeichnen gehört. Diesen Teil nutze ich.

Aber es gehört eben mehr dazu.

Original von mattik

Original von Tom9811
Und wozu das Ganze? Damit am Ende die Leiste so aussieht, wie ein aktiver Button, obwohl es das nun ganz gewiss nicht ist.

Exakt das, na endlich! Genau das war die ursprüngliche Frage.

Nein, die Frage war, wie man das ähnlich macht.

Und ein aktiver Button hat nicht nicht so auszusehen, wie ein inaktiver Hintergrund! Er ist nämlich – richtig – inaktiv. Also hat er inaktiv auszusehen.

Das mit der Zweifarbigkeit war übrigens dein Beispiel, nicht meines.

Original von Tom9811
*Räusper* NSControl implementiert das bereits, nicht erst NSButton. Damit haben sämtliche Controls das Action-Target!

Genau. Deshalb steht das da eben NICHT. Lies noch einmal.

Original von Tom9811
Für das gesamte Laufzeitsystem kommt es für die Typisierung ausnahmslos auf das Können an. Ich habe noch nie erlebt, dass das Laufzeitsystem von sich aus fragt, was denn die Klasse ist.

Objective-C hat Elemente dynamischer Typisierung, aber es ist keine vollständig dynamisch typisierte Sprache. Dass Du das noch nicht erlebt hast, ändert das nicht.

Original von Tom9811
Nein, du nimmst aber einen Scheibenwischer und baust dann selbst so lande daran herum, bis es aussieht wie ein Auto. WEil du du dann damit nicht fahren darfst, fakst du auch noch die Zulassung. Und am Ende sagt du:
Ich halte jetzt so lange an, bis du sagst dass es ein Scheibenwischer ist!

Nö.

Original von Tom9811
Ich würde gegenüber der Cell von der Außenansicht sprechen.

Sprich von was Du willst. Das macht es nicht richtiger. Die Cell ist privat.

Original von Tom9811
Das weißt du woher? Du weißt, dass sich die Cel nicht mal vorab die Action merkt? Woher?

"... of a view that’s designed to send a message to a target _when clicked_". Wenn nie ein Klick be der Cell ankommt, ist die Vorbedingung nie erfüllt und somit die Aussage immer wahr.

Und wie sollte sie auch? Sie kennt den View vorab gar nicht.

Original von Tom9811
Aber es gehört eben mehr dazu.

Und?

Original von Tom9811
Und ein aktiver Button hat nicht nicht so auszusehen, wie ein inaktiver Hintergrund! Er ist nämlich – richtig – inaktiv. Also hat er inaktiv auszusehen.

Ja, aber das hat nichts mit der Frage nach der technischen Realisierung zu tun.

Langsam werde ich es leid. Ich weiß nicht, ob Du die grundsätzliche Problematik nicht sehen willst. Wir faseln hier über Kinkerlitzchen herum. Das ist wenig fruchtbar.

Wenn Du der Meinung bist, dass es schön ist, für solche Flächen NSButtons zu nehmen, tu das. Aber bitte sieh auch, dass es hier anscheinend Menschen gibt, die das für nicht schön halten. Zu denen gehöre ich.

Original von mattik

Original von Tom9811
Für das gesamte Laufzeitsystem kommt es für die Typisierung ausnahmslos auf das Können an. Ich habe noch nie erlebt, dass das Laufzeitsystem von sich aus fragt, was denn die Klasse ist.

Objective-C hat Elemente dynamischer Typisierung, aber es ist keine vollständig dynamisch typisierte Sprache. Dass Du das noch nicht erlebt hast, ändert das nicht.

Es ist vollständig dynamisch typisiert mit Ausnahme von super, was rein technische Gründe hat. Da gibt es nun wirklich gar keinen Zusammenhang zum Verhältnis von Cells und Controls.

Mir zeigt dieses "Argument" aber, dass mir die Diskussion eindeutig – sagen wir – zu blöd wird.

Viel Spaß noch!

Original von Tom9811

Original von mattik

Original von Tom9811
Für das gesamte Laufzeitsystem kommt es für die Typisierung ausnahmslos auf das Können an. Ich habe noch nie erlebt, dass das Laufzeitsystem von sich aus fragt, was denn die Klasse ist.

Objective-C hat Elemente dynamischer Typisierung, aber es ist keine vollständig dynamisch typisierte Sprache. Dass Du das noch nicht erlebt hast, ändert das nicht.

Es ist vollständig dynamisch typisiert mit Ausnahme von super, was rein technische Gründe hat. Da gibt es nun wirklich gar keinen Zusammenhang zum Verhältnis von Cells und Controls.

Lieber Tom, keine Sorge, kein Wort mehr zu Buttons und Cells und so.

Nur ein kleiner Hinweis, dass Deine Vorstellung von der vollständigen dynamischen Typisierung nicht so ganz richtig ist: Projekt starten, Konsole angucken, staunen.