Auch mal was zu 1.
Wrapperfunktionen/Methoden für andreframeworks sind natürlich voll-legal.
Da Cocoa ja kostenlos ist und man es ja auch nicht "mit gibt".

So Amboss! :>

@ChaosCoder
Danke, ich geb mein Bestes!

@Midimaster
Auch dir meinen Dank! Ich versuch mal deine Fragen zu beantworten:

1.
Meine Rechte: Wenn ich es wirklich unters Volk werfen sollte, dann werde ich keinerlei Rechte beanspruchen.
Apples Rechte: Es gibt bereits diverse Wrapps von Cocoa in diverse Sprachen, also gehe ich einfach mal davon aus, dass Apple darüber hinweg sieht.
Dritte: Alle Frameworks, die ich geplant habe zu wrappen sind Freeware bzw. OpenSource usw. Also werden auch hier keine Rechte verletzt.

2.
Man kann dieses Modul in BlitzMax einbauen OHNE original Module verändern zu müssen. Da lege ich großen Wert drauf. Man verliert allerdings den Bezug auf das original Menü und die original Applikation, da ich Marks Delegate-Controller für die NSApplication Klasse mit meinem eigenen Überschreibe. Dies passiert aber von meinem Modul. Das Menü wird von cocoa.cocoa neu geschrieben, so dass es weiterhin benutzbar ist. Ich tat das ganze um BlitzMax Apps abzugewöhnen das Herunterfahren des Rechners zu blockieren, was mich extrem nervte. Dies kann man mittels Methode kontrollieren. Die einzige Schwachstelle sind derzeit die Event-basierenden Befehle wie KeyHit, KeyDown, MouseHit, MouseDown... Die funktionieren so nicht mehr. Dazu habe ich aber geplant eine Abhilfe zu schaffen. Momentan muss man die Key-und Maus-Events auf Apples Weg abfragen: Neue Klasse von, auf CCResponder basierenden Klasse vererben und die Methoden leftMouseDown(event:CCEvent), rightMouseDown(event:CCEvent) usw. oder keyDown(event:CCEvent), keyUp(event:CCEvent) verarbeiten.

Sollte Mark wirklich mal Updates veröffentlichen ist dieses Modul davon nicht betroffen.

Ich plane halbherzig einen MaxGUI-Treiber zu schreiben, dieser steht aber noch in den Sternen, da ich persönlich MaxGUI verabscheue. Das Modul als solches benötigt MaxGUI nicht!

3.
Langjährigen Support kann ich nicht garantieren, aber jeder halbwegs findige Programmierer mit ein wenig OBJ-C Erfahrung sollte schnell durch das System durchsteigen und behilflich sein können.

Da ich nie kommerzielle Projekte in Betracht gezogen habe wohl eher nicht, allerdings hatte ich ein/zwei freie Projekte ins Auge gefasst. Ansonsten würde sich die Mühe nicht lohnen. :>

4.
Bisher gibt es auch für "Hirnis" eine ausführliche Dokumentation, in der ich jede relevante Funktion oder Methode dokumentiert habe. Was allerdings wirklich nützlich wäre, wäre etwas Erfahrung mit Cocoa. Muss man zwar nicht haben, aber hätte Vorteile.

Außerdem liegen all die Samples aus dem Worklog im Ordner /Samples im Modul-Scope! Vielleicht werde ich ein kleines Projekt beisteuern, in dem ich ChaosKnuffel (findet man im ShowCase) noch mal mit diesem Modul neu schreibe.

Aber wie schon mehrfach erwähnt (glaube ich): Hauptsächlich schreibe ich dieses Modul für mich! Ich werde es wohl unters Volk werfen, wenn ich soweit bin, aber erwartet nicht mehr als ihr seht!

Grüße

So Hammer!

hey d-Bug,

das ist so toll, was Du da machst. Das sieht so schön aus! Ich würde dass gerne in meine Programme einbauen. Dazu einige Fragen:

1. wie wird das mit den Rechten sein? Deinen? MacOs? Dritte?

2. kann man das in ein BlitzMax-Programm einbauen ohne die Original-BMax-Module zu manipulieren? Was, wenn Mark Updates veröffentlicht? Wie mit MaxGui kombinieren? Oder kompletter Ersatz?

3. Wirst Du dafür langjährig einen BugFix-Support bieten? Wirst du es selbst in einem kommerz. Projekt verwenden?

4. Kann das ein Hirni wie ich in seine eigene Programme einbauen? Wird es eine "Anleitung" geben?

Super Arbeit d-bug! Mach weiter so!

Hallo,

so aufwendig ist Fullscreen nicht. Einen Flag in der Fenster-Klasse von cocoa.maxgui.m mittels setCollectionBehavior setzen und dem Controller zwei neue Notifications beibringen um Events in MaxGUI triggern zu können. Das sollte auch schon alles gewesen sein. Allerdings ist der Fullscreen Modus recht instabil. Es kommt schon mal zu Konflikten mit Custom-Toolbars (wie bei MaxGUI) und anderem Gezücht. Ich werde das aber nicht in MaxGUI implementieren, falls du das jetzt lesen wolltest!

Die OpenGL-View ist auf meiner Todo-Liste, wird aber wohl nur über Umwege mit Max2D laufen. Allerdings hab ich mich da noch nicht richtig schlau gemacht also sind meine Angaben ohne Gewähr. Mal gucken wie die das in MaxGUI gelöst haben.

Hey,

wie aufwendig wäre es dem normalen MaxGUI Fullscreen beizubringen (für 10.7 Apps)?
Ist da nur eine bestimmte flag setzen oder ist mehr nötig?

Hast du auch vor einen GLView zu integrieren der mit Max2D angesprochen werden kann?

Nein, das mit dem Mistview meinte ich nicht
Eher so algemein deine Worklog-Posts.
Aber schon ok.

@Macintosh
"Stures Mistvieh!" <-- Meinst du den Ausdruck?
Ich glaube da reagierst du etwas sensibel, oder? Ich habe absolut gar nichts gegen Cocoa! Im Gegenteil! Wenn ich etwas gegen Cocoa hätte, dann würde ich mich wohl nicht andauernd damit beschäftigen wollen, oder? Mir rutschen allerdings schon mal ein paar "Kraftausdrücke" raus. Soweit mir bekannt ist gibt es auf dieser, unseren schönen Erde, so gut wie keinen dem das nicht passiert...

@ich
Kein Problem. Immer wieder gern!

J a es gibt in 10.7 keinen Toolbar seperator mehr (er sieht ja auch furchtbar aus).
Hat Cocoa dir irgendwas getan? Ich finde deinen Ausdruck eigentlich ziemlich unangebracht.

Sehr schön

Habe die cocoaext wirklich sehr gerne genutzt und werde die Modul Serie wohl auch für einige Projekte benutzen. Danke für deine Mühe. So macht das Entwickeln mit BlitzMax auf dem Mac wieder Spaß .