Subviews animiert auf- / zuklappen (macOS, IB)

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Subviews animiert auf- / zuklappen (macOS, IB)

    Hallo zusammen,

    Ich brauche Eure Tipps für die Umsetzung eines UI-Elements:

    Eine macOS-App, deren UI im Interface Builder erstellt wurde, soll ein Panel mit verschiedenen Optionen anzeigen. Da diese Textfelder, Checkboxen, Auswahllisten etc. aufgrund ihrer Anzahl schnell unübersichtlich werden, möchte ich thematische Untergruppen bilden, die dann mittels "Disclosure"-Dreieck versteckt bzw. angezeigt werden können. Das ganze sollte ähnlich wie der "Info"-Dialog für Dateien aussehen:

    Bildschirmfoto 2021-05-04 um 13.53.21.png

    Hat jemand von Euch so etwas schon einmal umgesetzt ... und wie? Ich sehe im Moment nur die Möglichkeit, im IB Container-Views in eine ScrollView einzubinden und deren Höhe zu animieren, wenn das zugehörige Dreieck angeklickt wird. Gibt es da nicht etwas fertiges oder geschickteres?

    Die App unterstützt macOS 10.11 aufwärts, also ist wirklich "heisser Scheiss" keine Option :)

    Hat eine oder einer von Euch so etwas schon gemacht oder eine gute Idee?

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • Prinzipiell bestimmt, aber dann müsste ich quasi für jede Zeile eine spezielle Zelle implementieren ... so mache ich es mit UITableViews unter iOS, würde mir das aber gerne sparen.

    Ich habe nun einige Artikel gefunden, die den o.g. Ansatz mittels Constraints verfolgen, sogar mit Verweis auf Sample Code von Apple. Keine Ahnung, was vorher mit meinem Google-fu los war, "nsview collapse disclosure" half.

    Trotzdem wäre ich sehr an eigenen Erfahrungen interessiert...

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • Michael schrieb:

    Ja, ich habe das vor ewig langer Zeit schon mal gemacht. Da gab es noch kein Autolayout. Heute würde ich das wie im Anhang machen. Einen Scrollview braucht man dabei nicht.
    Danke, @Michael, das zeigt mir, dass ich auf dem richtigen Weg bin. Eine ScrollView habe ich in's Spiel gebracht, da die aufgeklappten Subviews größer als das Fenster werden könnten: Dafür werde ich alle "Klapp-Views" in eine ScrollView einbetten...

    Dann werde ich mal basteln :) Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • Kein Problem, die DisclosureGroup ist auch in SwiftUI noch sehr jung und kam erst im letzten September raus. setz halt aktuell die letzte Oys Version voraus. Wenn man da 3 oder mehr Jahre alte Systeme unterstützen möchte, ist dies natürlich nichts. Hier muss man bereit sein, alte Zöpfe abzuschneiden.

    Da ich aktuell meine Apps für mich entwickle und sie auch anderen zur Verfügung stelle, habe ich hier kein Problem damit. Dass ich hierfür meine älteren Devices nicht mehr verwenden kann, ist leider nicht zu umgehen, aber die Zeit schreitet auch hier voran.

    Für mich kommt bspw UIKit nicht in Frage, hier hatte mich der Picker beinahe Wahnsinnig gemacht. Unter SwiftUi, ist das Peanuts dagegen…
    Dafür ist SwiftUI noch in den Kinderschuhen und es gibt noch einiges was ich mir wünschen würde. Sind wir mal optimal und sagen, in 3 Jahren wäre das da und läuft gut, und ich möcht 3 Jahre alte OS unterstützen, so würd ein Umstieg nix vor 2030…
    Für mich persönlich, so lange möchte ich nicht warten…
  • Siehst, in 6 Jahren sollen meine Apps alle fertig sein. Da darf dann nur noch etwas Pflege anfallen… und zwar für alle Plattformen. Um das zu präzisieren, muss dieser Zeitabschnitt bei mir (geplant) in 3 Jahren eintreten, denn dann kommen andere Projekte hoch, welche die Zeit beanspruchen.

    Wenn wir das mal zusammenfassen, in 6 Jahren werde wohl auch ich 3 Jahre alte OS unterstützen ;)
    Du bist also meiner Zeit bereits 9 Jahre voraus:)

    Da würde ich einfach beim bewährten bleiben und wenig auf innovation. So passen sich eben die Prioritäten dem Zeitgeist an…

    Noch einen schönen Abend
    Wolf
  • Michael schrieb:

    Heute würde ich das wie im Anhang machen.
    Nochmals ein "Danke!" und ich markiere das Thema als erledigt: Ich bin in dem Projekt - wie angedeutet - noch etwas altmodisch unterwegs, aber mit leichten Anpassungen auf Objective C, XIBs und (grösstenteils) Autosizing läuft es bei mir genau so. Ich hatte mir das wesentlich komplizierter vorgestellt.

    Auf zur nächsten Baustelle, Mattes :)
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • Kleine Ergänzung noch: Wenn man - wie ich - eine View hat, deren Größe sich dynamisch (z. B. aufgrund von Attributed Text) ändern kann, bietet sich eine leichte Abwandlung an: Statt die Größe der View explizit über die Konstante des NSLayoutConstraints zu setzen, ändere ich die Prioritäten zweier konkurrierender Constraints:
    • ein height-Constraints mit der Höhe der zusammengeklappten View
    • ein bottom-Constraint der View, das die View mit ihrem untersten Element verbindet
    Klappt 1a, Mattes

    Edit: Leider wird eine Änderung der Priorität nicht animiert ... Im Moment lebe ich damit. Wenn es mich zu sehr nervt, muss ich doch wie oben verfahren und die benötigte Höhe berechnen. Manno :(
    Diese Seite bleibt aus technischen Gründen unbedruckt.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von MyMattes ()

  • Du musst ja nicht die Priorität animieren. Du kannst auch das Constraint mit der höheren Priorität deaktivieren. Aber Achtung, es wird dadurch nicht mehr vom View gehalten und verschwindet im Nirvana, wenn du es nicht stark referenzierst. Ich hatte das auch in meinem Vortrag auf der Macoun 2015 (macoun.de/material2015.php) besprochen.
    „Meine Komplikation hatte eine Komplikation.“
  • Danke, das habe ich gerade gemacht ... und bin natürlich prompt über das strong gestolpert :)

    Allerdings sah es eben so aus, als würden auch Änderungen von active nicht animiert werden ... ich schau' mir das morgen noch mal im Ruhe an, für heute bin ich "durch".

    Grüsse, Mattes

    Edit: Scheinbar lässt sich active eines Constraints nicht über den automator-Proxy animieren (oder ich bin zu blöd): Zumindest zeigt dieser keine Wirkung. Wenn ich allerdings - ohne Verwendung des Proxies - context.allowsImplicitAnimation = YES; setze, funktioniert die Animation wie gewünscht. Ich habe übrigens die beiden o.g. Constraints jeweils explizit aktiviert: Finde ich leichter verständlich als die Abstufung über Prioritäten.

    Nochmals ein dicker Danke!
    Diese Seite bleibt aus technischen Gründen unbedruckt.

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von MyMattes ()