Suchergebnisse

Ich bin mal gespannt, was Du herausbekommst über die Vor/Nachteile von NSThreads gegenüber puren Python Threads. Vielleicht gibt es aufgrund der PyObjC Implementierung überhaupt keinen Unterschied. Der GIL verhindert --soweit ich weiß-- dass der Python Interpreter/VM selbst beim Ausführen der Bytecodes in verschiedenen Threads gleichzeitig läuft. Was das genau bedeutet, kann ich nicht sagen -- ich bin nur dummer Python User Jedenfalls gab es wohl große Diskussionen in der Python Gemeinde, wie ma…

@MCDan: Ich mache das, indem ich nachgucke, ob Core Animation auf dem System läuft. (Geht einfach, wenn man den View fragt, welche Methoden er kennt)

Die Einwände bzgl. des Plugins kann ich natürlich verstehen. Da muss es eine bessere Möglichkeit geben. Threads jedoch sind sehr einfach in PyObjC zu machen: Quellcode (1 Zeile) ruft in Python die Methode myThreadMethod auf. In dieser kann man jetzt alles mögliche tun. (Wie das mit dem Python GIL (Global Interpreter Lock) aussieht, habe ich noch nicht getestet) z.B. Quellcode (19 Zeilen) Mit den üblichen NSAutoreleasePool Geschichten (dürfte wohl unter Leopard wegfallen). Die Funktion AppHelper.…

Mit diesem Thema habe ich mich auch noch nicht so beschäftigt. Warum genau, möchtest Du keinen Plugin generieren? Ist vielleicht nicht die schönste Möglichkeit, funktioniert aber. Wenn Du über die Python-C Schnittstelle gehen möchtest, so gibt es da Swig oder Boost-Python, was Dir dir Arbeit erleichtern könnte. Wahrscheinlich kann man auch im PyObjC Sourcecode fündig werden, wie man direkt den Python Interpreter aufruft und mit diesem von Cocoa aus kommuniziert. Da habe ich aber noch nie reinges…

Hier bin ich Hi Rainer, was möchtest Du denn genau machen? Ich hab zwar jetzt nicht soooo viel mit PyObjC gearbeitet, aber ein bisschen kann ich sicherlich helfen. Hast Du Dir schon das Beispiel "PyInterpreter" auf pyobjc.sourceforge.net/examples/index.php angeschaut? Gruß Tim

Ich kann mich dem allgemeinen Lobgesang nur anschließen: Ein großes Lob an die Gastgeber und vielen Dank für den netten Abend!

Also ich benutze für sowas die Apple ImageAndTextCell Klasse aus dem Developer Verzeichnis im Beispiel DragNDropOutlineView. Das klappt ganz ausgezeichnet. Aber wahrscheinlich kennst Du diese Klasse auch, da Du ja genau denselben Namen verwendest

Was eventuell noch ginge, wäre die Daten dem Pasteboard in tableView:writeRowsWithIndexes:toPasteboard: nicht vollständig zur Verfügung zu stellen, sondern nur mit declareTypes:owner: zu deklarieren. Wenn dann die Destination per pasteboard:provideDataForType: nachfragt, kann Deine Source entscheiden, ob sie eher einen Move oder ein Copy durchführen möchte. Könnte klappen, habe ich aber noch nicht ausprobiert...

Ah, jetzt verstehe ich das Problem! Die Source (also der NSTableView) wird wahrscheinlich per draggingEnded: (wie Du schon geschrieben hast) benachrichtigt. Scheint leider keine Methode im normalen (NSTableView) Data Source Protokoll dafür zu geben. Bleibt wohl nichts anderes über, als NSTableView abzuleiten.

Zitat: „Original von Tom9811 -tableView:acceptDrop:row:dropOperation Invoked by aTableView when the mouse button is released over a table view that previously decided to allow a drop. Hiermit kann ich entscheiden, ob jemand auf mich droppen (Target) kann. Ich will aber als Source wissen, wohin gedroppt wurde. “ Aber genau das kann man doch mit -tableView:acceptDrop:row:dropOperation? Das ist doch auch der Punkt, wo man als Data Source das Modell entsprechend der Drop Operation anpasst, also z.B.…

Scheint leider nicht anders zu gehen (es sei denn, man liebt das Risiko In meiner aktuellen Entwicklung benutze ich auch einen NSOutlineView zusammen mit Core Data und das Ganze auch noch eher ungewöhnlich. Da habe ich mich sehr schnell vom NSTreeController verabschiedet und weine dem auch keine Träne hinterher. So viel Arbeit ist die Implementierung einer Datasource auch nicht und man hat viel mehr Kontrolle über die dargestellten Objekte und ihre Relationen.

NSTreeController und Core Data ist wohl immer etwas instabil. Hast Du schon den Artikel von Rentzsch zu diesem Problem gelesen? Hat vielleicht nicht soviel mit Deinem aktuellen Problem zu tun, könnte aber trotzdem interessant sein: rentzsch.com/cocoa/foamingAtTheMouth

Interessanter Artikel. Hatte bisher noch keine Probleme mit dem setPropertyList, werde aber mal besser aufpassen. Wahrscheinlich ist bei mir alles gut gegangen, weil ich nicht NSURLs in das Array packe, sondern NSStrings von den URLs (weiß nicht mehr genau, warum ich das gemacht habe...) Eine Frage: wie schreibst Du denn ein NSArray in's Pasteboard, ohne setPropertyList zu nehmen? Ich habe in der Doku zu NSPasteboard nur setPropertyList, setData und setString gefunden.

Hmm, bei mir geht das ganz einfach. Ich habe meine NSManagedObjects in einem NSArrayController liegen, den kann ich dann ganz einfach in der fraglichen Methode um die entsprechenden Objekte bitten: Quellcode (11 Zeilen)

Aha, so lernt man immer wieder was dazu

Hast Du mal die Zeiten mit NSStrings drawInRect:withAttributes: verglichen, oder ruft diese Methode nur intern genau die Methoden von NSLayoutManager auf, die Du auch benutzt?

Ist eigentlich ganz einfach (wenn ich das Problem richtig verstanden habe) Du baust Dir zunächst ein NSArray zusammen: Quellcode (1 Zeile) und das schickst Du dann an den NSTableView: Quellcode (1 Zeile) klappt zumindest in meiner App...

Die NSView Klasse bietet eine Methode inLiveResize an. Frag die einfach in der drawRect Methode ab. Außerdem gib es noch viewDidEndLiveResize von NSView. Mit einer dieser Methoden sollte es klappen.

Ich kenn mich da leider nicht so aus. Gibt es keine bessere Möglichkeit, die Verbindung zum Internet zu überprüfen als ein Ping? Keine Ahnung, wie viel Last das auf den Servern erzeugt (landet der Ping überhaupt bei den Servern?), aber wenn nur 1000 Leute Dein Programm gleichzeitig verwenden, sendet es ja im Durchschnitt schon 200 Pings pro Sekunde an apple.com. Aber vielleicht mache ich da auch unnötig Panik und der Aufruf von SCNetworkCheckReachabilityByName bewirkt überhaupt keine Last auf de…

zunächst solltest Du nicht apple.com pingen, das kann ganz übel enden, wenn die app weit verbreitet wird... dann sollte der Autoreleasepool in der Methode checkInternetConnection angelegt und wieder geschlossen werden, denke ich. Dann sollte es klappen. (in der Methode, die den Thread startet ist das überflüssig)