Wider das Grauen!

Du Arme Socke! Das klingt ja so, als ob du die letzten Eingeweide eines verwesenden Kadavers zusammenkratzen und bestimmen musstest :/ Ich hoffe der Aufwand hat sich wenigstens gelohnt und drücke dir weiter die Daumen!

Schön das sich deine Blockade gelöst hat und viel Spaß
weiterhin Freue mich wie immer auf deine Einträge!

Grüße

Micha

Nerven aus Stahl? Ich?? Es ist nur so, dass ich dieses Modul für ein paar geplante Projekte benötige, die ich nicht mit MaxGUI umsetzen möchte. Solange ich nicht immer den selben Ansatz verfolge zählt das für meinen verwirrten Geist als Optimierung. Ich gestehe außerdem, dass es mir einen heiden Spaß bereitet diese Frameworks zu analysieren und einen gesunden Weg zu finden diese dann nach BlitzMax zu portieren. Aber glaub mir, Nerven aus Stahl habe ich ganz sicher nicht! :>

Du hast Nerven aus Stahl, oder? Ich wäre schon längst bei "Fuck this shit" angelangt, wenn ich zum x-ten mal "von vorne" beginnen würde. Andererseits scheint das so ein Projekt zu sein bei dem man einfach nicht aufhören kann weil einem die Arbeit daran oder das Resultat zu sehr gefällt. Viel Erfolg weiterhin und auf das es ein letztes "von vorne" sein möge

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?