Ein Gradient-Button oder Ähnliches. Die "leeren" Teile bekommst du mit einem Button hin, den du auf disabled stellst.

Vielleicht hilft dir das da -> BlueRope

Original von Tom9811
Ein Gradient-Button oder Ähnliches. Die "leeren" Teile bekommst du mit einem Button hin, den du auf disabled stellst.

Uah!

Buttons fuer reine Container-Zwecke verwenden, das widerstrebt mir z.B. sehr. Wer weiss, ob deaktivierte Knoepfe in zukuenftigen Mac-OS-X-Versionen nicht auf einmal rosa sind oder sich sonstwie deutlich von den aktiven Knoepfen unterscheiden? Du saehest auch alt aus, wenn Du irgendwann mal einen Status-Text vor diesen Hintergrund setzen wolltest -- es ist naemlich ueberhaupt keine gute Idee, sich unter Mac OS X auf die z-Ebene eines Views zu verlassen.

Ich wuerde eher dazu raten, sich einmal eine mehrfach verwendbare Loesung zu basteln, bestehen aus:

- Hintergrund-Custom-View, der sich vermittels NSGradient (wenn >= 10.5) oder sonstwie (z.B. Hintergrundbild) zeichnet.

- als Subviews (!): eigene NSButton/Cell-Subklasse, die ihre Hintergrund-Zeichnung von o.g. Hintergrund-Custom-View uebernehmen kann und gleich noch solche Sachen wie Menues und das mitunter von Standard-Buttons abweichende Highlight-Verhalten erschlaegt.

Ich sprach von Zwischenräumen, nicht von Containern.

Und wenn in der nächsten Version die Buttons rosa sind, dann ist es gewollt, dass die Zwischenräume auch rosa sind. Ich halte es daher gerade für angebracht.

Original von MatzeLoCal
Vielleicht hilft dir das da -> BlueRope

This allows use to easily create shades of gray. As for what shades to use, I used Pixie (in /Developer/Applictions/Graphics Tools) to examine other apps and the square buttons we’ve already added. In fact, I spent an inordinate amount of time in Pixie trying to get these silly colors right.

Um es mit Peter zu sagen: Was machst du, wenn in der nächsten Version Buttons rosa sind?

Rosa weil.

Chris

Original von Chris
Rosa weil.

Ich schaue ja am Wochenende den Grand Prix d'Eurovision de la Chanson. (Ja, bei mir heißt das immer noch so. *röckchenanzieh*)

Ob dem Blue-Rope-Menschen wohl schon aufgefallen ist, dass sein Konstrukt ueberhaupt nicht aussieht wie die entsprechenden Apple-Elemente, z.B. in Mail.app?

Ich jedenfalls wuerde es, wie gesagt, nicht so machen. Man verlaesst sich da auf die Konstanz zu vieler Variablen, auf die man keinen Einfluss hat.

Original von Tom9811

Original von MatzeLoCal
Vielleicht hilft dir das da -> BlueRope

This allows use to easily create shades of gray. As for what shades to use, I used Pixie (in /Developer/Applictions/Graphics Tools) to examine other apps and the square buttons we’ve already added. In fact, I spent an inordinate amount of time in Pixie trying to get these silly colors right.

Um es mit Peter zu sagen: Was machst du, wenn in der nächsten Version Buttons rosa sind?

Und was, wenn mensch das Ding als Bild hinterlegt hat und Apple überlegt sich bei 10.6. die Buttons rosa zu machen? Dann ist ein hinterlegtes Bild ebenso untauglich.

malik wollte wissen wie sowas geht... das wird bei dem BlueRope menschen gezeigt... ob mensch es dann 1:1 so umsetzt steht auf einem anderen Blatt

Original von MatzeLoCal
Und was, wenn mensch das Ding als Bild hinterlegt hat und Apple überlegt sich bei 10.6. die Buttons rosa zu machen? Dann ist ein hinterlegtes Bild ebenso untauglich.

Genau deshalb hab' ich geraten, beides selbst zu zeichnen.

Original von MatzeLoCal

Original von Tom9811

Original von MatzeLoCal
Vielleicht hilft dir das da -> BlueRope

This allows use to easily create shades of gray. As for what shades to use, I used Pixie (in /Developer/Applictions/Graphics Tools) to examine other apps and the square buttons we’ve already added. In fact, I spent an inordinate amount of time in Pixie trying to get these silly colors right.

Um es mit Peter zu sagen: Was machst du, wenn in der nächsten Version Buttons rosa sind?

Und was, wenn mensch das Ding als Bild hinterlegt hat und Apple überlegt sich bei 10.6. die Buttons rosa zu machen? Dann ist ein hinterlegtes Bild ebenso untauglich.

Jo, es gibt viele Wege das ebenso untauglich zu machen. Deshalb würde ich ja auch einen Button nehmen. Wenn der Button in der nächsten Version rosa ist, dann ist der Zwischenraum eben auch rosa. Also passt es wieder.

Original von Tom9811malik wollte wissen wie sowas geht... das wird bei dem BlueRope menschen gezeigt... ob mensch es dann 1:1 so umsetzt steht auf einem anderen Blatt

Deshalb sollte man ja auf die "Gefahren" hinweisen.

Ich habe es mal genau so wie er gemacht, wobei es mir um Plastik mit .4 ging. Die Folgen kannst du dir ja ausmalen …

Selbst malen geht gar nicht. Aber bei einem Button hätte ich auch Bauchschmerzen - wer weiß, was Assistive-Technologien und/oder GUI Skripting damit machen? Und aus ästhetischen Gründen sollte m.E. alles, was von NSControl ableitet, auch ein Control sein (entsprechend von NSButton auch ein Button, also irgend etwas zun Draufdrücken).

Man braucht doch einen View, der so aussieht wie ein bestimmter Button, nur leer. Das lässt sich doch ziemlich gerade implementieren, indem man einen Custom View baut, der sich eine NSButtonCell anhand eines angegebenen Buttons konfiguriert und das Malen dann an seine Cell delegiert.

Original von mattik
Selbst malen geht gar nicht. Aber bei einem Button hätte ich auch Bauchschmerzen - wer weiß, was Assistive-Technologien und/oder GUI Skripting damit machen? Und aus ästhetischen Gründen sollte m.E. alles, was von NSControl ableitet, auch ein Control sein (entsprechend von NSButton auch ein Button, also irgend etwas zun Draufdrücken).

Man braucht doch einen View, der so aussieht wie ein bestimmter Button, nur leer. Das lässt sich doch ziemlich gerade implementieren, indem man einen Custom View baut, der sich eine NSButtonCell anhand eines angegebenen Buttons konfiguriert und das Malen dann an seine Cell delegiert.

Die Gefahr des Skriptings eines disbaled Buttons, dem keine Action und Targets zugewiesen sind, erkenne ich nicht. Da würde ich eher an die funktionierenden Denken …

Der Trick mit der Cell ist zwar fein, aber letztlich macht er ja auch nur einen Button. Okay, okay, formal ist es eine Cell, aber letztlich überlässt du alles der Cell – wie es auch ein Button macht. (Die eigene Funktionalität von Controls ist ja eher gering.)

Aber wenn wir schon dabei sind: Warum nicht einen Button einfach in en Image rendern. Muss man natürlich bei einer Größernänderung erneut machen. (Also letztlich zeichnen lassen, kein großer Unterschied.)

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

Original von Tom9811
Die Gefahr des Skriptings eines disbaled Buttons, dem keine Action und Targets zugewiesen sind, erkenne ich nicht. Da würde ich eher an die funktionierenden Denken …

Klar, die Gefahr ist eher (sprich: sehr) gering. Wenn Apple sich überlegt, den Hintergrund von disabled-Buttons in dieser Art eines Tages anders zu machen, könnte das eigenartig aussehen. Und wenn jemand ein Assistive Tool für Sehbehinderte zu basteln, das um alle aktiven Schaltflächen einen grünen und um alle disabled-Schaltflächen einen roten Rahmen zu malen... aber zugegeben: Das ist a) unwahrscheinlich und b) keine größere Katastrophe. Es ist eine Feinheit.

Original von Tom9811
Der Trick mit der Cell ist zwar fein, aber letztlich macht er ja auch nur einen Button. Okay, okay, formal ist es eine Cell, aber letztlich überlässt du alles der Cell – wie es auch ein Button macht. (Die eigene Funktionalität von Controls ist ja eher gering.)

Eben nicht, das ist ja der Trick. Es gibt zwei Unterschiede: a) in der View-Hierarchie taucht kein Button und keine Control auf, sonder nur ein generischer View. Da kann kein externer Beobachter eine vermeintliche Funktion hineininterpretieren. Und b) ich delegiere eben nicht alles an die Cell - nur das Zeichnen. Insbesondere Events werden nicht weitergeleitet. Das Ding ist von der Außenwelt abgeschnitten.

Original von Tom9811
Aber wenn wir schon dabei sind: Warum nicht einen Button einfach in en Image rendern. Muss man natürlich bei einer Größernänderung erneut machen. (Also letztlich zeichnen lassen, kein großer Unterschied.)

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

Klar kann man das auch machen. Dann hat man einen Image View in der Hierarchie. Auf jeden Fall besser als ein Button, aber auch nicht so wunderschön - es ist ja ein rein dekoratives Element und kein Bildbetrachter. Und es ist m.E. unnötig viel Overhead - bei jedem Resize einen neuen Kontext anlegen und ein zusätzlicher Offscreen-Buffer? Wo liegt da der Vorteil?

Original von mattik

Original von Tom9811
Die Gefahr des Skriptings eines disbaled Buttons, dem keine Action und Targets zugewiesen sind, erkenne ich nicht. Da würde ich eher an die funktionierenden Denken …

Klar, die Gefahr ist eher (sprich: sehr) gering. Wenn Apple sich überlegt, den Hintergrund von disabled-Buttons in dieser Art eines Tages anders zu machen, könnte das eigenartig aussehen. Und wenn jemand ein Assistive Tool für Sehbehinderte zu basteln, das um alle aktiven Schaltflächen einen grünen und um alle disabled-Schaltflächen einen roten Rahmen zu malen... aber zugegeben: Das ist a) unwahrscheinlich und b) keine größere Katastrophe. Es ist eine Feinheit.

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.
Das Gegenteil wäre ein Problem:
Wäre eine andere Farbe irgendwie richtiger? Wie wäre es denn bei dir? Würde die "aktive" Farbe erscheinen? Fändest du das besser, wenn man da gar nichts klicken kann? Hat der User nicht gerade deshalb zwei deutlich unterschiedliche Farben gewählt, damit er die klickbaren Schaltflächen leicht erkennt?

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

Original von mattik

Original von Tom9811
Der Trick mit der Cell ist zwar fein, aber letztlich macht er ja auch nur einen Button. Okay, okay, formal ist es eine Cell, aber letztlich überlässt du alles der Cell – wie es auch ein Button macht. (Die eigene Funktionalität von Controls ist ja eher gering.)

Eben nicht, das ist ja der Trick. Es gibt zwei Unterschiede: a) in der View-Hierarchie taucht kein Button und keine Control auf, sonder nur ein generischer View. Da kann kein externer Beobachter eine vermeintliche Funktion hineininterpretieren. Und b) ich delegiere eben nicht alles an die Cell - nur das Zeichnen. Insbesondere Events werden nicht weitergeleitet. Das Ding ist von der Außenwelt abgeschnitten.

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

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.

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.

Original von mattik

Original von Tom9811
Aber wenn wir schon dabei sind: Warum nicht einen Button einfach in en Image rendern. Muss man natürlich bei einer Größernänderung erneut machen. (Also letztlich zeichnen lassen, kein großer Unterschied.)

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

Klar kann man das auch machen. Dann hat man einen Image View in der Hierarchie. Auf jeden Fall besser als ein Button, aber auch nicht so wunderschön - es ist ja ein rein dekoratives Element und kein Bildbetrachter. Und es ist m.E. unnötig viel Overhead - bei jedem Resize einen neuen Kontext anlegen und ein zusätzlicher Offscreen-Buffer? Wo liegt da der Vorteil?

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

Ich würde ja einfach einen disabled Button nehmen …

Meine zwei Cent:

Daß ausgerechnet Tom dafür stimmen würde, da disabled Buttons reinzutun bereitet mir zwar keine schlaflosen Nächte, aber überrascht mich doch schon.

Ich würde in so einem Fall auf jeden Fall da halt nen eigenen View basteln, der einen Verlauf zeichnet und da meine eigenen Knöpfe draufwerfen. So dramatisch ist das mit den Verläufen ja nun auch nicht.

Zwei Zeilen mehr, um den gleichen Faktor eleganter.

Und wenn ich mir wegen der Farben unsicher bin und für das rosa von 10.6 vorbereitet haben möchte dann greife ich halt zu einer der vielen statischen Methoden von NSColor zurück, da bekomme ich dann bei 10.7 auch türkis und bei 10.8 urksm, die Farbe, die noch erfunden wird.

Nur daß Tom meine NSHannoSeppCornflakes herausposaunt hat –– Freunde nennen mich Hanno Sepp –– ist echt gemeint, die sollten in einer urksm-farbenen Verpackung im Herbst das Licht der Welt erblicken.

Sauerei.

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.

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.

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.

Original von Tom9811

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.

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.

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.

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

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