das kommt wohl eher auf die Ladezeit an. Solange die kurz ist, lohnt es nicht, eine zweite Nib aufzumachen und wegen einem oder zwei kleinen Fenster mehr wird die Ladezeit nicht merklich länger.

Ich packe alles was nicht voneinander abhängig ist (Warnfenster, Einstellungen, Hauptfenster, Dokumentfesnter, Paletten, etc.) in separate Nibs.

Du musst bei mehreren nibs einfach bedenken, dass du das entweder mit einem WindowController lädst oder aber selber eine Klasse schreibst (so mach ich das immer).

Gruss,
Fabian

Original von Objcler
Hallo,

ich habe mich schon oft gefragt, ob es nicht besser wäre mein Projekt auf mehrere nib-files zu verteilen.

Mein Projekt ist relativ klein. Daher weiß ich nicht, ab wann man es in betracht ziehen sollte mehrere nib-files zu haben.

Eines ist wohl klar: Sobald man ein Projekt hat, welches aus einigen "großen" Teilen besteht sollten diese ja in seperaten nib-files untergebracht werden. z.B ein Hauptfenster in einer nib und das Einstellungen-Fenster in einer nib... Aber ich habe viele kleine Fenster, die ich nicht unbedingt alle in seperaten nib files unterbringen möchte... oder ist dies die Regel?

Ich habe für Testzwecke eine NIB mit 28 Objekten. Die erzeugt ca. 3000 Subobjekte bis sie auf dem Schirm erscheint. Und das alles dauert auf einem alten 400MHz G4 nur ca. 1 Sekunde.

Das Aufteilen auf mehrere NIBs stammt noch aus den Zeiten wo eine Next-Maschine 25MHz und nur 8MB Arbeitsspeicher hatte: en.wikipedia.org/wiki/NeXT#NeXT_Computer

M.E. ist es Zeitverschwendung darüber zu viel nachzudenken (ein bischen schadet aber nie).

Was einen merklichen Unterschied macht, ist ob man die NIB als Text (XML) oder binär speichert. Als XML wird sie viel größer und etwas langsamer.

Wenn sich jemand fragt warum ich solche Tests mache: QuantumSTEP kann inzwischen echte NIB-Files auf einem PDA (Sharp Zaurus) laden und anzeigen

Cocoa für PDAs und Smartphones rückt in winzigen Schritten näher!

-- hns

Um, ich geb mal zu bedenken daß das nicht nur eine Sache der Ladezeit sondern auch des Speicherverbrauchs ist.

Ich mache nur in zwei Fällen neue NIBs:

1) Wenn in den NIBs OS spezifischer Code ist (also z.B. spezieller 10.4 oder 10.3 Code)

2) Wenn es umfangreiche, aber sehr selten genutze Funkionalität enthält

Alex

und manchmal braucht man das selbe fenster oder view oder was weis ich mehrmals im programm, muss es also in ein eigenes nib legen. Auch kann das aufteilen sehr zur übersicht beitragen aber das merkt man schon selber recht schnell wann es zeit ist wegen der übersichtlichkeit das aufzuteilen

Original von seb2
Um, ich geb mal zu bedenken daß das nicht nur eine Sache der Ladezeit sondern auch des Speicherverbrauchs ist.

3000 Objekte zu je 100 Bytes = 300 kByte. Bei 1GB RAM sind das 0,03%...

-- hns

Original von gritsch
und manchmal braucht man das selbe fenster oder view oder was weis ich mehrmals im programm, muss es also in ein eigenes nib legen. Auch kann das aufteilen sehr zur übersicht beitragen aber das merkt man schon selber recht schnell wann es zeit ist wegen der übersichtlichkeit das aufzuteilen

D.h. möglichst alles in 1 NIB packen, außer

* wenn es nicht anders geht (z.B. MainMenu und Document)
* wenn es dadurch deutlich übersichtlicher wird

Ladezeit und Speicher sind in der Praxis nicht (mehr) wirklich bedeutsam.

-- hns

Original von hns
D.h. möglichst alles in 1 NIB packen, außer

Ein dritter Grund könnte die Wiederverwendbarkeit in anderen Projekten sein.

Michael

Oooohhh, wir vermissen alle jede Menge Funktionen im IB.

Wichtig: Mach auf bugreport.apple.com einen Enhancement Request.

Und vielleicht kommt am Montag ja was ...

Alex

ich komme mit den automatisch erstellten Nibs volllommen aus. Wenn ich eine "document based" app schreibe, sind es 2 und wenn ich dann noch lokalisiere, gibt es ein "German.lproj" und darin die Nib Nummer 3.