Cocoa Modul Serie
Aufräumen...
Sonntag, 3. Februar 2013 von d-bug
Hallo zusammen,
da ich immer mehr das Gefühl bekomme, dass der Einsatz von brl.reflection zwar ein super Sache ist, aber auch zu unkontrollierbarer Inkonsistenz führt, habe ich beschlossen ein wenig aufzuräumen. Events werden z.B. manchmal nur beim zweiten oder dritten mal ausgelöst, was nur unzureichend ist. Außerdem werden Objekte manchmal nicht erstellt, was natürlich überhaupt nicht passieren sollte!
Meine Aufräum-Aktion bezieht sich also hauptsächlich auf den Einsatz von brl.reflection an Stellen, wo es nicht zwingend benötigt wird. Zum einen werde ich die Delegate-Methoden fest in NSObject integrieren. Damit habe ich auch bereits begonnen. Dazu ist es allerdings nötig, das jede Subklasse auf Cocoa-Seite eine korrespondierende BBObject Klasse mit sich führt. Dies habe ich zum Test schon an den NSWindow-und NSPanel-Subklassen ausprobiert und bin begeistert vom Ergebnis. Nicht nur, dass man es mittels Properties recht simpel umsetzen kann, nein, es scheint auch bisher deutlich flüssiger zu laufen. Schade nur, dass ich dazu jede Initialisierungs-Methode einer Klasse auf BlitzMax-Seite anpassen muss. Will heißen, ich muss wirklich jede einzelne, der gefühlten 200 Klassen anpacken... Außerdem muss ich auch noch die ganzen Aufrufe der Delegates im Cocoa-Controller ändern und die passenden Funktionen jeder BlitzMax-Klasse umstricken. Ein Arsch voll Arbeit! (wie man so schön sagt)
Als weiteren Trick lasse ich nun das Target/Action-System und die Notifications per Event-Hook auslösen. Ich verspreche mir davon, dass so schnell nichts mehr verloren geht, da ich ja sozusagen die Events cachen lasse, bzw. macht der Event-Queue das ja schon von Haus aus für mich. In diesen Hook werde ich auch noch die eigentlichen Events einpflanzen, aber das mach ich später. Außerdem kann man durch diesen Umbau wieder auf die gute alte Update-Schleife zurückgreifen, solange man irgendwo ein WaitEvent() einbaut. Das wird ein paar meiner geplanten Features deutlich vereinfachen. So quasi aus Kompatibilitäts-Gründen, löse ich auch gleich noch die ganzen BlitzMax-Events für den Umgang mit MaxGUI und brl.system mit aus.
Als letzte Änderung schmeiße ich alle alloc(), retain(), release_() und autorelease() Methoden und Funktionen raus und lasse das Cocoa-Gadget mit der Initialisierungsmethode seines BlitzMax-Pondons erstellen. Leider musste ich nämlich feststellen, dass sogar ich als Entwickler des Moduls, nicht genug Disziplin besitze um die Garbage-Collector Geschichte von Objective-C verantwortungsvoll zu nutzen. Das erstellen eines Gadgets sieht demzufolge jetzt so aus:
BlitzMax: [AUSKLAPPEN]
So, die ganzen Methoden, die ich im letzten Post rausschmiss werden auch wieder eingebunden, allerdings diesmal ohne Reflection. Am Ende werden nur noch NSNotification und Target/Action - Reflection benötigen. Da bei beiden aber sowieso die passende TMethod in eine Variable gespeichert wird, sollte das ganze deutlich beschleunigt werden.
Grüße
buggy
da ich immer mehr das Gefühl bekomme, dass der Einsatz von brl.reflection zwar ein super Sache ist, aber auch zu unkontrollierbarer Inkonsistenz führt, habe ich beschlossen ein wenig aufzuräumen. Events werden z.B. manchmal nur beim zweiten oder dritten mal ausgelöst, was nur unzureichend ist. Außerdem werden Objekte manchmal nicht erstellt, was natürlich überhaupt nicht passieren sollte!
Meine Aufräum-Aktion bezieht sich also hauptsächlich auf den Einsatz von brl.reflection an Stellen, wo es nicht zwingend benötigt wird. Zum einen werde ich die Delegate-Methoden fest in NSObject integrieren. Damit habe ich auch bereits begonnen. Dazu ist es allerdings nötig, das jede Subklasse auf Cocoa-Seite eine korrespondierende BBObject Klasse mit sich führt. Dies habe ich zum Test schon an den NSWindow-und NSPanel-Subklassen ausprobiert und bin begeistert vom Ergebnis. Nicht nur, dass man es mittels Properties recht simpel umsetzen kann, nein, es scheint auch bisher deutlich flüssiger zu laufen. Schade nur, dass ich dazu jede Initialisierungs-Methode einer Klasse auf BlitzMax-Seite anpassen muss. Will heißen, ich muss wirklich jede einzelne, der gefühlten 200 Klassen anpacken... Außerdem muss ich auch noch die ganzen Aufrufe der Delegates im Cocoa-Controller ändern und die passenden Funktionen jeder BlitzMax-Klasse umstricken. Ein Arsch voll Arbeit! (wie man so schön sagt)
Als weiteren Trick lasse ich nun das Target/Action-System und die Notifications per Event-Hook auslösen. Ich verspreche mir davon, dass so schnell nichts mehr verloren geht, da ich ja sozusagen die Events cachen lasse, bzw. macht der Event-Queue das ja schon von Haus aus für mich. In diesen Hook werde ich auch noch die eigentlichen Events einpflanzen, aber das mach ich später. Außerdem kann man durch diesen Umbau wieder auf die gute alte Update-Schleife zurückgreifen, solange man irgendwo ein WaitEvent() einbaut. Das wird ein paar meiner geplanten Features deutlich vereinfachen. So quasi aus Kompatibilitäts-Gründen, löse ich auch gleich noch die ganzen BlitzMax-Events für den Umgang mit MaxGUI und brl.system mit aus.
Als letzte Änderung schmeiße ich alle alloc(), retain(), release_() und autorelease() Methoden und Funktionen raus und lasse das Cocoa-Gadget mit der Initialisierungsmethode seines BlitzMax-Pondons erstellen. Leider musste ich nämlich feststellen, dass sogar ich als Entwickler des Moduls, nicht genug Disziplin besitze um die Garbage-Collector Geschichte von Objective-C verantwortungsvoll zu nutzen. Das erstellen eines Gadgets sieht demzufolge jetzt so aus:
BlitzMax: [AUSKLAPPEN]
Local gadget:NSGadgetKlasse = (New NSGadgetKlasse).initMethodeDerKlasse()Weiß der Geier, warum ich das nicht von Anfang an so gemacht habe. Nun gut, ich als Geier weiß es natürlich: BLANKE FAULHEIT! Ich war einfach nur zu faul eine entsprechenden Konstruktor in Objective-C zu schreiben. Faulheit zahlt sich eben doch nicht aus!
So, die ganzen Methoden, die ich im letzten Post rausschmiss werden auch wieder eingebunden, allerdings diesmal ohne Reflection. Am Ende werden nur noch NSNotification und Target/Action - Reflection benötigen. Da bei beiden aber sowieso die passende TMethod in eine Variable gespeichert wird, sollte das ganze deutlich beschleunigt werden.
Grüße
buggy
Und weiter gehts...
Sonntag, 27. Januar 2013 von d-bug
Hallo zusammen,
es gibt eine Änderung, die ich selbstverständlich niemandem vorenthalten möchte. Es gibt jetzt kein Subclassing mehr für komplette Cocoa-Klassen.
Z.B. kann jetzt nur noch auf eine NSView gezeichnet werden, wenn man eine neue, auf NSView basierende Klasse in Objective-C und deren Wrapper in BlitzMax schreibt. Der Grund dafür ist recht einfach: Das wurde alles vieeel zu langsam. Stellt euch vor, ihr schreibt eine recht umfangreiche Applikation. Für jede Methode eines Gadgets dieser Applikation wird ein callback gen BlitzMax geschossen, der via brl.reflection Modul die passende BlitzMax-Type-Instanz sucht, dann die BlitzMax-Methode in der Instanz sucht und diese dann ausführt. Das fällt bei wenigen Gadgets noch nicht so auf, aber je mehr Gadgets es werden, desto langsamer wird es.
Das wäre mir wahrscheinlich auch nicht aufgefallen, wenn ich nicht im Zuge der Testphase die IDE wieder zusammen schrauben würde. Es wunderte mich schon heftig, dass eine Animation zweier NSView's so derbe ruckelte. Der Grund dafür wahr einzig und alleine, dass die views einen callback für ihre drawRect Methode nach BlitzMax übergaben. Als ich das ganze subclass-Gedöns auskommentierte, ging plötzlich alles super sauber von statten.
Dann kommen wir auch gleich zur TestApp-IDE.
Bisher hab ich mich eigentlich nur um die den eigentlichen Editor gekümmert. Man kann zwar bisher weder laden noch speichern, aber AutoCompletion usw. gibt es bereits. Vielleicht sind meine Prioritäten ein wenig durcheinander...
Zur Abwechslung gibt es jetzt auch mal ein paar Bilder:
Wo wir gerade von AutoCompletion sprachen... deren Liste:
Wenn man jetzt Enter drücken würde passiert das:
AutoCompletion fügt also die Keywords mit deren Parametern ein. Als wäre das noch nicht genug, kann man sich mittels Tab und Shift+Tab vorwärts und rückwärts durch die Parameter tabben um sie einfacher bearbeiten zu können. ...und als wäre das immer noch nicht genug, kann man beim eingeben des Parameters wieder eine AutoCompletion-Liste anzeigen lassen, die dann allerdings nur noch registrierte Variablen enthält! Man muss allerdings das ganze mit ESC beenden, wenn man mal wieder was normales tippen will.
Dann hätte ich da noch die Suche zu bieten:
Eigentlich eine OS X-Standardsuche... Die Filter sind allerdings etwas anders als normal.
Weiter gehts mit Quick-Help:
Das Popup als solches sieht noch etwas ungeschliffen aus. Da muss ich noch ein wenig mit den Farben spielen. Man kann die Hilfe Wahlweise wie ein Tooltip, nach Ablauf einer Zeitspanne einblenden lassen, oder einfach durch die Tastenkombination CTRL+CMD+? anzeigen lassen.
Weitere Features (ohne Bild):
Es gibt da noch viel dran zu tun, aber als Test für die Module ist es wirklich super geeignet.
Bis dahin...
es gibt eine Änderung, die ich selbstverständlich niemandem vorenthalten möchte. Es gibt jetzt kein Subclassing mehr für komplette Cocoa-Klassen.
Z.B. kann jetzt nur noch auf eine NSView gezeichnet werden, wenn man eine neue, auf NSView basierende Klasse in Objective-C und deren Wrapper in BlitzMax schreibt. Der Grund dafür ist recht einfach: Das wurde alles vieeel zu langsam. Stellt euch vor, ihr schreibt eine recht umfangreiche Applikation. Für jede Methode eines Gadgets dieser Applikation wird ein callback gen BlitzMax geschossen, der via brl.reflection Modul die passende BlitzMax-Type-Instanz sucht, dann die BlitzMax-Methode in der Instanz sucht und diese dann ausführt. Das fällt bei wenigen Gadgets noch nicht so auf, aber je mehr Gadgets es werden, desto langsamer wird es.
Das wäre mir wahrscheinlich auch nicht aufgefallen, wenn ich nicht im Zuge der Testphase die IDE wieder zusammen schrauben würde. Es wunderte mich schon heftig, dass eine Animation zweier NSView's so derbe ruckelte. Der Grund dafür wahr einzig und alleine, dass die views einen callback für ihre drawRect Methode nach BlitzMax übergaben. Als ich das ganze subclass-Gedöns auskommentierte, ging plötzlich alles super sauber von statten.
Dann kommen wir auch gleich zur TestApp-IDE.
Bisher hab ich mich eigentlich nur um die den eigentlichen Editor gekümmert. Man kann zwar bisher weder laden noch speichern, aber AutoCompletion usw. gibt es bereits. Vielleicht sind meine Prioritäten ein wenig durcheinander...
Zur Abwechslung gibt es jetzt auch mal ein paar Bilder:
Wo wir gerade von AutoCompletion sprachen... deren Liste:
Wenn man jetzt Enter drücken würde passiert das:
AutoCompletion fügt also die Keywords mit deren Parametern ein. Als wäre das noch nicht genug, kann man sich mittels Tab und Shift+Tab vorwärts und rückwärts durch die Parameter tabben um sie einfacher bearbeiten zu können. ...und als wäre das immer noch nicht genug, kann man beim eingeben des Parameters wieder eine AutoCompletion-Liste anzeigen lassen, die dann allerdings nur noch registrierte Variablen enthält! Man muss allerdings das ganze mit ESC beenden, wenn man mal wieder was normales tippen will.
Dann hätte ich da noch die Suche zu bieten:
Eigentlich eine OS X-Standardsuche... Die Filter sind allerdings etwas anders als normal.
Weiter gehts mit Quick-Help:
Das Popup als solches sieht noch etwas ungeschliffen aus. Da muss ich noch ein wenig mit den Farben spielen. Man kann die Hilfe Wahlweise wie ein Tooltip, nach Ablauf einer Zeitspanne einblenden lassen, oder einfach durch die Tastenkombination CTRL+CMD+? anzeigen lassen.
Weitere Features (ohne Bild):
- Automatische Groß/Kleinschreibung für Sprachen die das auch unterstützen (BlitzMax z.b.)
- Klammervergleich
- Klammer-und Anführungszeichenvervollständigung
- Blöcke ein/auskommentieren
- Zoom mit Gesten u/o Tastatur
- Automatisches Einrücken (auch Sprachbasierend)
- Tab-basierendes Layout (ebenfalls mit Gestensteuerung)
- außerdem noch vieles was Scintilla von Hause aus zu bieten hat.
Es gibt da noch viel dran zu tun, aber als Test für die Module ist es wirklich super geeignet.
Bis dahin...
Und täglich grüßt....
Sonntag, 30. Dezember 2012 von d-bug
Hallöle,
nach dem ich feststellen konnte, dass TimeMachine auch nicht das Wahre ist (speziell dann, wenn man damit ein Backup macht, seinen Rechner neu aufsetzt und dann tatsächlich glaubt man bekomme seine Daten auch wieder), musste ich mich aufs neue mit Cocoa auseinander setzen! Nicht dass es noch wirklich Spaß machen würde... Weiß der Geier, die wievielte Version das jetzt schon ist.
Diesmal war ich allerdings nicht mehr in der Laune alles per Hand einzuklöppeln, sonderen schrieb mir eine Art Parser für developer.apple.com Seiten. Natürlich ging auch das nicht ohne weiteres vonstatten. ZumBeispiel schaffte ich es nicht mit BlitzMax https Seiten direkt auszulesen. Was macht der findige Schreiberling da? Er kopiert alle Daten von der Seite in ein Textfile und liest dieses dann aus.
Das macht den Parser natürlich unnötig kompliziert, erfüllt aber seinen Zweck.
Also, was kann der Parser:
...und das kann er nicht:
Sprich, ich muss trotzdem noch mal jede Klasse absuchen und berichtigen. Das geht aber immer noch schneller als alles per Hand einzuhacken!
In den letzten paar Tagen habe ich schon mal folgendes vollbracht (auskommentiert gibts noch nicht oder wirds auch nie geben)...
cocoa.appkit BlitzMax: [AUSKLAPPEN]
cocoa.foundation BlitzMax: [AUSKLAPPEN]
Die Kommentare hinter den Include bedeuten nur, dass Klassen-Referenzen noch fehlen, oder ich die Klasse auf später verschoben habe, weil ich noch nicht weiß, ob ichs umsetzen kann. "additions" sind Erweiterungen der eigentlichen foundation Klasse und werden auch da eingetragen... Natürlich sind die Kommentare bei mir schöne eingerückt hinter den Include Anweisungen was aber nicht in die Codeboxen vom BBP übernommen wird.
Wie man sehen kann, habe ich mein Augenmerk momentan auf die das cocoa.appkit Modul gelegt und die Foundation Klassen nur dann umgesetzt, wenn ich sie in Appkit benötigte. Das wird sich aber noch ändern.
Im Großen und Ganzen kann man aber schon ansatzweise erkennen, was das für ein Monster an Modulen wird!
Die cocoa.scintilla, cocoa.psmtabbarcontrol und cocoa.appstorewindow Module hab ich übrigens auch schon wieder neu geschrieben. Diese allerdings per Hand, weil es Drittanbieter Klassen oder Frameworks sind, die nicht auf developer.apple.com dokumentiert sind und mein Parser da schlichtweg versagen würde!
So, das ganze hat bisher ungefähr 2 Wochen in Anspruch genommen. Ich habe wirklich unermüdlich daran rum geschraubt!
Mir ist sogar gelungen ansatzweise Drag&Drop einzubinden, was aber gerade noch in den Kinderschuhen steckt. Das konnte KEINE der alten Versionen! (Man braucht ja schließlich Lichtblicke...)
So, genug des trockenen Geschwafels.
buggy
PS: Voll vergessen das Sample dranzuhängen!
BlitzMax: [AUSKLAPPEN]
Viel Spaß noch
buggy^2
nach dem ich feststellen konnte, dass TimeMachine auch nicht das Wahre ist (speziell dann, wenn man damit ein Backup macht, seinen Rechner neu aufsetzt und dann tatsächlich glaubt man bekomme seine Daten auch wieder), musste ich mich aufs neue mit Cocoa auseinander setzen! Nicht dass es noch wirklich Spaß machen würde... Weiß der Geier, die wievielte Version das jetzt schon ist.
Diesmal war ich allerdings nicht mehr in der Laune alles per Hand einzuklöppeln, sonderen schrieb mir eine Art Parser für developer.apple.com Seiten. Natürlich ging auch das nicht ohne weiteres vonstatten. ZumBeispiel schaffte ich es nicht mit BlitzMax https Seiten direkt auszulesen. Was macht der findige Schreiberling da? Er kopiert alle Daten von der Seite in ein Textfile und liest dieses dann aus.
Das macht den Parser natürlich unnötig kompliziert, erfüllt aber seinen Zweck.
Also, was kann der Parser:
- Eine Klasse auslesen und aus Klassen-Methoden und Instanz-Methoden - Type, Funktionen und Methoden für BMX zaubern, das ganze in ein eigenes Include-File für appkit.mod oder foundation.mod speichern.
- Aus den gewonnenen Methoden und Funktionen Callbacks für die Objective-C runtime extrahieren und in die objc.bmx und objc.m Dateien des objc.mod schreiben .
- String Konstanten automatisch in die String-Übersetzer Funktion des objc.mod einfügen.
- Int Konstanten mit Referenznamen anhand einer Vergleichsliste wieder in Int-Konstanten für BlitzMax umwandeln
- Die Dokumentation gleich mit auslesen (Allerdings mit der falschen Codepage. Statt UTF-8 eben UTF-16)
- Mich ärgern!
...und das kann er nicht:
- NSArray, NSMutableArray automatisch umwandeln. (Woher soll er auch wissen was im Array gespeichert ist?)
- @protocol auslesen und in setter und getter umwandeln
- Delegates schreiben
- Mir die Arbeit 100%ig abnehmen...
Sprich, ich muss trotzdem noch mal jede Klasse absuchen und berichtigen. Das geht aber immer noch schneller als alles per Hand einzuhacken!
In den letzten paar Tagen habe ich schon mal folgendes vollbracht (auskommentiert gibts noch nicht oder wirds auch nie geben)...
cocoa.appkit BlitzMax: [AUSKLAPPEN]
Include "classes/NSActionCell.bmx"
'Include "classes/NSAffineTransform.bmx" 'additions
Include "classes/NSAlert.bmx"
Include "classes/NSAnimation.bmx"
'Include "classes/NSAnimationContext.bmx"
'Include "classes/NSAppleScript.bmx" 'Use LUA instead
Include "classes/NSApplication.bmx" 'NSCoder
'Include "classes/NSArrayController.bmx"
'Include "classes/NSATSTypesetter.bmx"
'Include "classes/NSAttributedString.bmx" 'additions
Include "classes/NSBezierPath.bmx"
'Include "classes/NSBitmapImageRep.bmx"
Include "classes/NSBox.bmx"
Include "classes/NSBrowser.bmx" 'NSDragOperation, delegate
Include "classes/NSBrowserCell.bmx"
'Include "classes/NSBundle.bmx" 'additions
Include "classes/NSButton.bmx"
Include "classes/NSButtonCell.bmx"
'Include "classes/NSCachedImageRep.bmx"
Include "classes/NSCell.bmx" 'NSFormatter
'Include "classes/NSCIImageRep.bmx"
Include "classes/NSClipView.bmx"
'Include "classes/NSCoder.bmx" 'additions
'Include "classes/NSCollectionView.bmx"
'Include "classes/NSCollectionViewItem.bmx"
Include "classes/NSColor.bmx"
Include "classes/NSColorList.bmx"
Include "classes/NSColorPanel.bmx"
Include "classes/NSColorPicker.bmx"
Include "classes/NSColorSpace.bmx"
Include "classes/NSColorWell.bmx"
'Include "classes/NSComboBox.bmx"
'Include "classes/NSComboBoxCell.bmx"
Include "classes/NSControl.bmx" 'NSFormatter
'Include "classes/NSController.bmx"
Include "classes/NSCursor.bmx"
'Include "classes/NSCustomImageRep.bmx"
Include "classes/NSDatePicker.bmx"
Include "classes/NSDatePickerCell.bmx" 'delegate
'Include "classes/NSDictionaryController.bmx"
Include "classes/NSDockTile.bmx"
'Include "classes/NSDocument.bmx"
'Include "classes/NSDocumentController.bmx"
Include "classes/NSDraggingImageComponent.bmx"
Include "classes/NSDraggingInfo.bmx"
Include "classes/NSDraggingItem.bmx" 'imageComponentsProvider
Include "classes/NSDraggingSession.bmx"
Include "classes/NSDrawer.bmx"
'Include "classes/NSEPSImageRep.bmx"
Include "classes/NSEvent.bmx"
'Include "classes/NSFileWrapper.bmx" 'additions
Include "classes/NSFont.bmx"
Include "classes/NSFontCollection.bmx"
Include "classes/NSFontDescriptor.bmx"
Include "classes/NSFontManager.bmx"
Include "classes/NSFontPanel.bmx"
Include "classes/NSForm.bmx"
Include "classes/NSFormCell.bmx"
'Include "classes/NSGlyphGenerator.bmx"
'Include "classes/NSGlyphInfo.bmx"
Include "classes/NSGradient.bmx"
Include "classes/NSGraphicsContext.bmx"
'Include "classes/NSHelpManager.bmx"
Include "classes/NSImage.bmx" 'delegate, pixmap support
Include "classes/NSImageCell.bmx"
'Include "classes/NSImageRep.bmx"
Include "classes/NSImageView.bmx"
Include "classes/NSLayoutManager.bmx" 'delegate, NSTypeSetter, NSGlyph, NSGlyphGenerator
Include "classes/NSLevelIndicator.bmx"
Include "classes/NSLevelIndicatorCell.bmx"
Include "classes/NSMatrix.bmx" 'delegate
Include "classes/NSMenu.bmx"
Include "classes/NSMenuItem.bmx"
Include "classes/NSMenuItemCell.bmx"
Include "classes/NSMenuView.bmx"
'Include "classes/NSMutableAttributedString.bmx"
'Include "classes/NSMutableFontCollection.bmx"
'Include "classes/NSMutableParagraphStyle.bmx"
'Include "classes/NSNib.bmx"
'Include "classes/NSNibConnector.bmx"
'Include "classes/NSNibControlConnector.bmx"
'Include "classes/NSNibOutletConnector.bmx"
'Include "classes/NSObjectController.bmx"
'Include "classes/NSOpenGLContext.bmx"
'Include "classes/NSOpenGLLayer.bmx"
'Include "classes/NSOpenGLPixelBuffer.bmx"
'Include "classes/NSOpenGLPixelFormat.bmx"
'Include "classes/NSOpenGLView.bmx"
Include "classes/NSOpenPanel.bmx"
Include "classes/NSOutlineView.bmx" 'datasource completion, delegate completion
Include "classes/NSOutlineViewDataSource.bmx"
'Include "classes/NSPageController.bmx"
'Include "classes/NSPageLayout.bmx"
Include "classes/NSPanel.bmx"
Include "classes/NSParagraphStyle.bmx"
Include "classes/NSPasteboard.bmx"
Include "classes/NSPasteboardItem.bmx"
Include "classes/NSPathCell.bmx" 'delegate
Include "classes/NSPathComponentCell.bmx"
Include "classes/NSPathControl.bmx" 'delegate, NSDragOperation
'Include "classes/NSPDFImageRep.bmx"
'Include "classes/NSPersistentDocument.bmx"
'Include "classes/NSPICTImageRep.bmx"
'Include "classes/NSPopover.bmx" 'later...
Include "classes/NSPopUpButton.bmx"
Include "classes/NSPopUpButtonCell.bmx"
'Include "classes/NSPredicateEditor.bmx" 'later...
'Include "classes/NSPredicateEditorRowTemplate.bmx" 'later...
Include "classes/NSPrinter.bmx"
Include "classes/NSPrintInfo.bmx"
'Include "classes/NSPrintOperation.bmx"
Include "classes/NSPrintPanel.bmx" 'NSViewController
Include "classes/NSProgressIndicator.bmx"
Include "classes/NSResponder.bmx"
'Include "classes/NSRuleEditor.bmx" 'later...
Include "classes/NSRulerMarker.bmx"
Include "classes/NSRulerView.bmx"
'Include "classes/NSRunningApplication.bmx" 'later...
Include "classes/NSSavePanel.bmx" 'delegate
Include "classes/NSScreen.bmx"
Include "classes/NSScroller.bmx"
Include "classes/NSScrollView.bmx"
Include "classes/NSSearchField.bmx"
Include "classes/NSSearchFieldCell.bmx"
Include "classes/NSSecureTextField.bmx"
Include "classes/NSSecureTextFieldCell.bmx"
Include "classes/NSSegmentedCell.bmx"
Include "classes/NSSegmentedControl.bmx"
Include "classes/NSShadow.bmx"
'Include "classes/NSSharingService.bmx" 'later...
'Include "classes/NSSharingServicePicker.bmx" 'later...
Include "classes/NSSlider.bmx"
Include "classes/NSSliderCell.bmx"
Include "classes/NSSound.bmx"
Include "classes/NSSpeechRecognizer.bmx" 'delegate
Include "classes/NSSpeechSynthesizer.bmx" 'delegate
Include "classes/NSSpellChecker.bmx" 'NSTextCheckingResult, NSOrthography, NSViewController
Include "classes/NSSplitView.bmx"
Include "classes/NSStatusBar.bmx"
Include "classes/NSStatusItem.bmx"
Include "classes/NSStepper.bmx"
Include "classes/NSStepperCell.bmx"
'Include "classes/NSString.bmx" 'replaced by String
'Include "classes/NSTableCellView.bmx" 'later...
Include "classes/NSTableColumn.bmx" 'NSSortDescriptor
Include "classes/NSTableHeaderCell.bmx"
Include "classes/NSTableHeaderView.bmx"
'Include "classes/NSTableRowView.bmx" 'later...
Include "classes/NSTableView.bmx" 'datasource completion, delegate completion, NSSortDescriptor
Include "classes/NSTableViewDataSource.bmx"
Include "classes/NSTabView.bmx" 'delegate
Include "classes/NSTabViewItem.bmx"
Include "classes/NSText.bmx"
Include "classes/NSTextAttachment.bmx"
Include "classes/NSTextAttachmentCell.bmx" 'NSTextAttachmentCell protocol
Include "classes/NSTextBlock.bmx"
Include "classes/NSTextContainer.bmx"
Include "classes/NSTextField.bmx" 'delegate?
Include "classes/NSTextFieldCell.bmx"
'Include "classes/NSTextFinder.bmx" 'later...
'Include "classes/NSTextInputContext.bmx" 'later...
Include "classes/NSTextList.bmx"
Include "classes/NSTextStorage.bmx"
Include "classes/NSTextTab.bmx"
Include "classes/NSTextTable.bmx"
Include "classes/NSTextTableBlock.bmx"
Include "classes/NSTextView.bmx" 'delegate completion, NSOrthography
Include "classes/NSTokenField.bmx"
Include "classes/NSTokenFieldCell.bmx"
Include "classes/NSToolbar.bmx"
Include "classes/NSToolbarItem.bmx"
Include "classes/NSToolbarItemGroup.bmx"
'Include "classes/NSTouch.bmx" 'later...
Include "classes/NSTrackingArea.bmx"
'Include "classes/NSTreeController.bmx" 'later...
'Include "classes/NSTreeNode.bmx" 'later...
'Include "classes/NSTypesetter.bmx" 'later...
'Include "classes/NSURL.bmx" 'additions
'Include "classes/NSUserDefaultsController.bmx" 'later...
Include "classes/NSView.bmx" 'NSLayoutConstraint, NSDraggingSession, NSTextInputContext
Include "classes/NSViewAnimation.bmx"
'Include "classes/NSViewController.bmx" 'later...
Include "classes/NSWindow.bmx" 'NSWindowController
'Include "classes/NSWindowController.bmx" 'later...
Include "classes/NSWorkspace.bmx" 'NSRunningApplication
cocoa.foundation BlitzMax: [AUSKLAPPEN]
Include "classes/NSAffineTransform.bmx"
'Include "classes/NSAppleEventDescriptor.bmx"
'Include "classes/NSAppleEventManager.bmx"
'Include "classes/NSAppleScript.bmx"
'Include "classes/NSArchiver.bmx"
'Include "classes/NSArray.bmx" '- replaced by blitz arrays
'Include "classes/NSAssertionHandler.bmx"
Include "classes/NSAttributedString.bmx"
'Include "classes/NSAutoreleasePool.bmx"
'Include "classes/NSBlockOperation.bmx"
'Include "classes/NSBundle.bmx"
'Include "classes/NSCache.bmx"
'Include "classes/NSCachedURLResponse.bmx"
Include "classes/NSCalendar.bmx"
Include "classes/NSCharacterSet.bmx"
'Include "classes/NSClassDescription.bmx"
'Include "classes/NSCloneCommand.bmx"
'Include "classes/NSCloseCommand.bmx"
'Include "classes/NSCoder.bmx"
'Include "classes/NSComparisonPredicate.bmx"
'Include "classes/NSCompoundPredicate.bmx"
'Include "classes/NSCondition.bmx"
'Include "classes/NSConditionLock.bmx"
'Include "classes/NSConnection.bmx"
'Include "classes/NSCountCommand.bmx"
'Include "classes/NSCountedSet.bmx"
'Include "classes/NSCreateCommand.bmx"
Include "classes/NSData.bmx" 'byte ptr support
'Include "classes/NSDataDetector.bmx"
Include "classes/NSDate.bmx" 'NSCalendarDate
Include "classes/NSDateComponents.bmx"
'Include "classes/NSDateFormatter.bmx"
'Include "classes/NSDecimalNumber.bmx"
'Include "classes/NSDecimalNumberHandler.bmx"
'Include "classes/NSDeleteCommand.bmx"
Include "classes/NSDictionary.bmx"
'Include "classes/NSDirectoryEnumerator.bmx"
'Include "classes/NSDistantObject.bmx"
'Include "classes/NSDistantObjectRequest.bmx"
'Include "classes/NSDistributedLock.bmx"
'Include "classes/NSDistributedNotificationCenter.bmx"
'Include "classes/NSEnumerator.bmx"
Include "classes/NSError.bmx"
Include "classes/NSException.bmx"
'Include "classes/NSExistsCommand.bmx"
'Include "classes/NSExpression.bmx"
'Include "classes/NSFileCoordinator.bmx"
'Include "classes/NSFileHandle.bmx"
'Include "classes/NSFileManager.bmx"
'Include "classes/NSFileVersion.bmx"
Include "classes/NSFileWrapper.bmx"
'Include "classes/NSFormatter.bmx"
'Include "classes/NSGarbageCollector.bmx"
'Include "classes/NSGetCommand.bmx"
'Include "classes/NSHashTable.bmx"
'Include "classes/NSHost.bmx"
'Include "classes/NSHTTPCookie.bmx"
'Include "classes/NSHTTPCookieStorage.bmx"
'Include "classes/NSHTTPURLResponse.bmx"
Include "classes/NSIndexPath.bmx"
Include "classes/NSIndexSet.bmx"
'Include "classes/NSIndexSpecifier.bmx"
'Include "classes/NSInputStream.bmx"
'Include "classes/NSInvocation.bmx"
'Include "classes/NSInvocationOperation.bmx"
'Include "classes/NSKeyedArchiver.bmx"
'Include "classes/NSKeyedUnarchiver.bmx"
'Include "classes/NSLinguisticTagger.bmx"
Include "classes/NSLocale.bmx"
'Include "classes/NSLock.bmx"
'Include "classes/NSLogicalTest.bmx"
'Include "classes/NSMachBootstrapServer.bmx"
'Include "classes/NSMachPort.bmx"
'Include "classes/NSMapTable.bmx"
'Include "classes/NSMessagePort.bmx"
'Include "classes/NSMessagePortNameServer.bmx"
'Include "classes/NSMetadataItem.bmx"
'Include "classes/NSMetadataQuery.bmx"
'Include "classes/NSMetadataQueryAttributeValueTuple.bmx"
'Include "classes/NSMetadataQueryResultGroup.bmx"
'Include "classes/NSMethodSignature.bmx"
'Include "classes/NSMiddleSpecifier.bmx"
'Include "classes/NSMoveCommand.bmx"
'Include "classes/NSMutableArray.bmx" '- replaced by blitz arrays
Include "classes/NSMutableAttributedString.bmx"
'Include "classes/NSMutableCharacterSet.bmx"
'Include "classes/NSMutableData.bmx"
Include "classes/NSMutableDictionary.bmx"
'Include "classes/NSMutableIndexSet.bmx"
'Include "classes/NSMutableOrderedSet.bmx"
'Include "classes/NSMutableSet.bmx"
'Include "classes/NSMutableString.bmx" '- replaced by blitz strings
'Include "classes/NSMutableURLRequest.bmx"
'Include "classes/NSNameSpecifier.bmx"
'Include "classes/NSNetService.bmx"
'Include "classes/NSNetServiceBrowser.bmx"
Include "classes/NSNotification.bmx"
Include "classes/NSNotificationCenter.bmx"
'Include "classes/NSNotificationQueue.bmx"
Include "classes/NSNull.bmx"
Include "classes/NSNumber.bmx"
'Include "classes/NSNumberFormatter.bmx"
Include "classes/NSObject.bmx"
'Include "classes/NSOperation.bmx"
'Include "classes/NSOperationQueue.bmx"
'Include "classes/NSOrderedSet.bmx"
'Include "classes/NSOrthography.bmx"
'Include "classes/NSOutputStream.bmx"
'Include "classes/NSPipe.bmx"
'Include "classes/NSPointerArray.bmx"
'Include "classes/NSPointerFunctions.bmx"
'Include "classes/NSPort.bmx"
'Include "classes/NSPortCoder.bmx"
'Include "classes/NSPortMessage.bmx"
'Include "classes/NSPortNameServer.bmx"
'Include "classes/NSPositionalSpecifier.bmx"
'Include "classes/NSPredicate.bmx"
'Include "classes/NSProcessInfo.bmx"
'Include "classes/NSPropertyListSerialization.bmx"
'Include "classes/NSPropertySpecifier.bmx"
'Include "classes/NSProtocolChecker.bmx"
'Include "classes/NSProxy.bmx"
'Include "classes/NSQuitCommand.bmx"
'Include "classes/NSRandomSpecifier.bmx"
'Include "classes/NSRangeSpecifier.bmx"
'Include "classes/NSRecursiveLock.bmx"
'Include "classes/NSRegularExpression.bmx"
'Include "classes/NSRelativeSpecifier.bmx"
'Include "classes/NSRunLoop.bmx"
'Include "classes/NSScanner.bmx"
'Include "classes/NSScriptClassDescription.bmx"
'Include "classes/NSScriptCoercionHandler.bmx"
'Include "classes/NSScriptCommand.bmx"
'Include "classes/NSScriptCommandDescription.bmx"
'Include "classes/NSScriptExecutionContext.bmx"
'Include "classes/NSScriptObjectSpecifier.bmx"
'Include "classes/NSScriptSuiteRegistry.bmx"
'Include "classes/NSScriptWhoseTest.bmx"
Include "classes/NSSet.bmx" 'NSSortDescriptor, enum methods, testing methods
'Include "classes/NSSetCommand.bmx"
'Include "classes/NSSocketPort.bmx"
'Include "classes/NSSocketPortNameServer.bmx"
'Include "classes/NSSortDescriptor.bmx"
'Include "classes/NSSpecifierTest.bmx"
'Include "classes/NSSpellServer.bmx"
'Include "classes/NSStream.bmx"
'Include "classes/NSString.bmx" '- replaced by blitz strings
'Include "classes/NSTask.bmx"
'Include "classes/NSTextCheckingResult.bmx"
'Include "classes/NSThread.bmx"
'Include "classes/NSTimer.bmx"
Include "classes/NSTimeZone.bmx"
'Include "classes/NSUbiquitousKeyValueStore.bmx"
'Include "classes/NSUnarchiver.bmx"
Include "classes/NSUndoManager.bmx"
'Include "classes/NSUniqueIDSpecifier.bmx"
Include "classes/NSURL.bmx"
'Include "classes/NSURLAuthenticationChallenge.bmx"
'Include "classes/NSURLCache.bmx"
'Include "classes/NSURLConnection.bmx"
'Include "classes/NSURLCredential.bmx"
'Include "classes/NSURLCredentialStorage.bmx"
'Include "classes/NSURLDownload.bmx"
'Include "classes/NSURLHandle.bmx"
'Include "classes/NSURLProtectionSpace.bmx"
'Include "classes/NSURLProtocol.bmx"
'Include "classes/NSURLRequest.bmx"
'Include "classes/NSURLResponse.bmx"
'Include "classes/NSUserAppleScriptTask.bmx"
'Include "classes/NSUserAutomatorTask.bmx"
Include "classes/NSUserDefaults.bmx"
'Include "classes/NSUserNotification.bmx"
'Include "classes/NSUserNotificationCenter.bmx"
'Include "classes/NSUserScriptTask.bmx"
'Include "classes/NSUserUnixTask.bmx"
'Include "classes/NSUUID.bmx"
Include "classes/NSValue.bmx"
'Include "classes/NSValueTransformer.bmx"
'Include "classes/NSWhoseSpecifier.bmx"
'Include "classes/NSXMLDocument.bmx"
'Include "classes/NSXMLDTD.bmx"
'Include "classes/NSXMLDTDNode.bmx"
'Include "classes/NSXMLElement.bmx"
'Include "classes/NSXMLNode.bmx"
'Include "classes/NSXMLParser.bmx"
'Include "classes/NSXPCConnection.bmx"
'Include "classes/NSXPCInterface.bmx"
'Include "classes/NSXPCListener.bmx"
'Include "classes/NSXPCListenerEndpoint.bmx"
Die Kommentare hinter den Include bedeuten nur, dass Klassen-Referenzen noch fehlen, oder ich die Klasse auf später verschoben habe, weil ich noch nicht weiß, ob ichs umsetzen kann. "additions" sind Erweiterungen der eigentlichen foundation Klasse und werden auch da eingetragen... Natürlich sind die Kommentare bei mir schöne eingerückt hinter den Include Anweisungen was aber nicht in die Codeboxen vom BBP übernommen wird.
Wie man sehen kann, habe ich mein Augenmerk momentan auf die das cocoa.appkit Modul gelegt und die Foundation Klassen nur dann umgesetzt, wenn ich sie in Appkit benötigte. Das wird sich aber noch ändern.
Im Großen und Ganzen kann man aber schon ansatzweise erkennen, was das für ein Monster an Modulen wird!
Die cocoa.scintilla, cocoa.psmtabbarcontrol und cocoa.appstorewindow Module hab ich übrigens auch schon wieder neu geschrieben. Diese allerdings per Hand, weil es Drittanbieter Klassen oder Frameworks sind, die nicht auf developer.apple.com dokumentiert sind und mein Parser da schlichtweg versagen würde!
So, das ganze hat bisher ungefähr 2 Wochen in Anspruch genommen. Ich habe wirklich unermüdlich daran rum geschraubt!
Mir ist sogar gelungen ansatzweise Drag&Drop einzubinden, was aber gerade noch in den Kinderschuhen steckt. Das konnte KEINE der alten Versionen! (Man braucht ja schließlich Lichtblicke...)
So, genug des trockenen Geschwafels.
buggy
PS: Voll vergessen das Sample dranzuhängen!
BlitzMax: [AUSKLAPPEN]
'This sample is based on CocoaDragAndDrop sample from developer.apple.com.
'There are tons of modifications, but the base is still the same.
SuperStrict
Framework cocoa.appkit
'This view demonstrates the minimum requirement of accepting drag operations
'It accepts file paths and print it to the output panel of MaxIDE if they where accepted.
Type NSDraggingSampleView Extends NSImageView
Field highlight:Int
'---------------------------------------------------------------------------
' Init method...
'---------------------------------------------------------------------------
Method initWithFrame:NSDraggingSampleView(frameRect:NSRect)
Super.initWithFrame(frameRect)
setImageFrameStyle(NSImageFrameGrayBezel)
'register dragging types for images...
registerForDraggedTypes(NSImage.imagePasteboardTypes())
Return Self
End Method
'---------------------------------------------------------------------------
' NSDraggingDestination protocol methods
'---------------------------------------------------------------------------
'method called whenever a drag enters our drop zone
Method draggingEntered:Int(sender:NSDraggingInfo)
'Check if the pasteboard contains image data and source/user wants it copied
If (NSImage.canInitWithPasteboard(sender.draggingPasteboard())) And (sender.draggingSourceOperationMask() & NSDragOperationCopy)
'highlight our drop zone
highlight = YES
setNeedsDisplay(YES)
Return NSDragOperationCopy
EndIf
Return NSDragOperationNone
End Method
'method called whenever a drag exits our drop zone
Method draggingExited(sender:NSDraggingInfo)
'remove highlight of the drop zone
highlight = NO
setNeedsDisplay(YES)
End Method
'draw method is overridden to do drop highlighing
Method DrawRect(rect:NSRect)
'do the usual draw operation to display the image
'was allready done by the Cocoa part of the framework to avoid glitches.
'It just calls an empty method in this case!
Super.DrawRect(rect)
'highlight by overlaying a red border (the original grey border wasn't very impressive)
If highlight
NSColor.redColor().set()
NSBezierPath.setDefaultLineWidth(5.0)
NSBezierPath.strokeRect(rect)
EndIf
End Method
'method to determine if we can accept the drop
Method prepareForDragOperation:Int(sender:NSDraggingInfo)
'finished with the drag so remove any highlighting
highlight = NO
setNeedsDisplay(YES)
'check to see if we can accept the data
Return NSImage.canInitWithPasteboard(sender.draggingPasteboard())
End Method
'method that should handle the drop data
Method performDragOperation:Int(sender:NSDraggingInfo)
If sender.draggingSource() <> Self
Local pasteboard:NSPasteboard = sender.draggingPasteboard()
'set the image using the best representation we can get from the pasteboard
If NSImage.canInitWithPasteboard(pasteboard)
Local newImage:NSImage = NSImage.alloc().initWithPasteboard(pasteboard)
If newImage Self.setImage(newImage)
newImage.release_()
EndIf
'if the drag comes from a file, set the window title to the filename
Local fileURL:NSURL = NSURL.URLFromPasteboard(pasteboard)
If fileURL <> Null
Self.window().setTitle(fileURL.absoluteString())
Else
Self.window().setTitle("(no name)")
EndIf
EndIf
Return YES
End Method
'method called whenever a drag is updated over our drop zone
Method draggingUpdated:Int(sender:NSDraggingInfo)
'Check if the pasteboard contains image data and source/user wants it copied
If (NSImage.canInitWithPasteboard(sender.draggingPasteboard())) And (sender.draggingSourceOperationMask() & NSDragOperationCopy)
Return NSDragOperationCopy
EndIf
Return NSDragOperationNone
End Method
'---------------------------------------------------------------------------
' NSDraggingSource protocol methods
'---------------------------------------------------------------------------
'catch mouse down events in order to start drag
Method MouseDown(event:NSEvent)
'Dragging operation occur within the context of a special pasteboard (NSDragPboard).
'All items written or read from a pasteboard must conform to NSPasteboardWriting or
'NSPasteboardReading respectively. NSPasteboardItem implements both these protocols
'and is as a container for any object that can be serialized to NSData. */
Local pbItem:NSPasteboardItem = NSPasteboardItem.alloc().init()
'Our pasteboard item will support public.tiff, public.pdf, and our custom UTI (see comment in -draggingEntered)
'representations of our data (the image). Rather than compute both of these representations now, promise that
'we will provide either of these representations when asked. When a receiver wants our data in one of the above
'representations, we'll get a call to the NSPasteboardItemDataProvider protocol method –pasteboard:item:provideDataForType:.
pbItem.setDataProvider_forTypes(Self, ["NSPasteboardTypeTIFF", "NSPasteboardTypePDF"])
'create a new NSDraggingItem with our pasteboard item.
Local dragItem:NSDraggingItem = NSDraggingItem.alloc().initWithPasteboardWriter(pbItem)
pbItem.release_()
'The coordinates of the dragging frame are relative to our view. Setting them to our view's bounds will cause the drag image
'to be the same size as our view. Alternatively, you can set the draggingFrame to an NSRect that is the size of the image in
'the view but this can cause the dragged image to not line up with the mouse if the actual image is smaller than the size of the
'our view.
Local draggingRect:NSRect = Self.bounds()
'While our dragging item is represented by an image, this image can be made up of multiple images which
'are automatically composited together in painting order. However, since we are only dragging a single
'item composed of a single image, we can use the convince method below. For a more complex example
'please see the MultiPhotoFrame sample.
dragItem.setDraggingFrame_contents(draggingRect, image())
'create a dragging session with our drag item and ourself as the source.
Local draggingSession:NSDraggingSession = beginDraggingSessionWithItems_event_source([dragItem], event, Self)
'causes the dragging item to slide back to the source if the drag fails.
draggingSession.setAnimatesToStartingPositionsOnCancelOrFail(YES)
draggingSession.setDraggingFormation(NSDraggingFormationNone)
End Method
'NSDraggingSource protocol method. Returns the types of operations allowed in a certain context.
Method draggingSession_sourceOperationMaskForDraggingContext:Int(session:NSDraggingSession, context:Int)
Select context
Case NSDraggingContextOutsideApplication
Return NSDragOperationCopy
Case NSDraggingContextWithinApplication
End Select
Return NSDragOperationCopy
End Method
'method called by pasteboard to support promised drag types.
Method pasteboard_item_provideDataForType(pasteboard:NSPasteboard, item:NSPasteboardItem, dragType:String)
'I don't get it :O
'DragType is an UTI while the initialization type is a constant string variable...
'How to get an UTI on different systems where different UTIs can occure for each type?
'THIS IS FUCKING HORRIBLE!
'Instead of using this shit, one should use path based dragging!
Select ExtractExt(dragType).toLower()
Case "tiff"
pasteboard.setData_forType(Self.image().TIFFRepresentation(), "NSPasteboardTypeTIFF")
Case "pdf"
pasteboard.setData_forType(Self.dataWithPDFInsideRect(Self.bounds()), "NSPasteboardTypePDF")
End Select
End Method
'---------------------------------------------------------------------------
' subclassing methods
'---------------------------------------------------------------------------
Function alloc:NSDraggingSampleView()
Return New NSDraggingSampleView
EndFunction
Method autorelease:NSDraggingSampleView()
Return NSDraggingSampleView(Super.autorelease())
EndMethod
Method retain:NSDraggingSampleView()
Return NSDraggingSampleView(Super.retain())
EndMethod
End Type
Type NSSampleController Extends NSObject
Method initUI(notification:NSNotification)
Local mask:Int
Local frame:NSRect
Local window:NSWindow
Local view:NSDraggingSampleView
'set window mask
mask = NSTitledWindowMask | NSClosableWindowMask | NSMiniaturizableWindowMask | NSResizableWindowMask
'precalculate window frame from main screen visible frame
frame = NSMakeRect(200.0,200.0,300.0,300.0)
'initialize window
frame = NSWindow.frameRectForContentRect_styleMask(frame, mask)
window = NSWindow.alloc().initWithContentRect_styleMask_backing_defer(frame, mask, NSBackingStoreBuffered, YES).retain()
window.setMinSize(NSMakeSize(100.0, 100.0))
'create dragging destination
view = NSDraggingSampleView.alloc().initWithFrame(window.contentView().frame()).retain()
window.setContentView(view)
'set delegate of the window
window.setDelegate(Self)
'make the window key
window.makeKeyAndOrderFront(Self)
'precalculate window frame from main screen visible frame
frame = NSMakeRect(600.0,200.0,300.0,300.0)
'initialize window
frame = NSWindow.frameRectForContentRect_styleMask(frame, mask)
window = NSWindow.alloc().initWithContentRect_styleMask_backing_defer(frame, mask, NSBackingStoreBuffered, YES).retain()
window.setMinSize(NSMakeSize(100.0, 100.0))
'create dragging destination
view = NSDraggingSampleView.alloc().initWithFrame(window.contentView().frame()).retain()
window.setContentView(view)
'set delegate of the window
window.setDelegate(Self)
'make the window key
window.makeKeyAndOrderFront(Self)
End Method
Method logNotification(notification:NSNotification)
If notification NSLog(notification.name())
End Method
'---------------------------------------------------------------------------
'#pragma mark -
'#pragma mark internal methods
'---------------------------------------------------------------------------
Function alloc:NSSampleController()
Return New NSSampleController
EndFunction
Method autorelease:NSSampleController()
Return NSSampleController(Super.autorelease())
EndMethod
Method init:NSSampleController()
Return NSSampleController(Super.init())
EndMethod
Method retain:NSSampleController()
Return NSSampleController(Super.retain())
EndMethod
End Type
'create controller
Global app:NSApplication = NSApplication.sharedApplication()
Local controller:NSSampleController = NSSampleController.alloc().init().retain()
'bind notifications
Local nc:NSNotificationCenter = NSNotificationCenter.defaultCenter()
nc.addObserver(controller, "initUI", "NSApplicationDidFinishLaunchingNotification", Null)
'start app
app.setDelegate(controller)
app.run()
Viel Spaß noch
buggy^2
35 - Wir können entkäfern
Sonntag, 24. Juni 2012 von d-bug
Hallo zusammen,
weil ChaosEdit ja laut Plan erst mal nur eine feste Sprache unterstützen soll, aber durch LUA-Scripts auch die Unterstützung anderer Sprachen beherrschen soll, hab ich mir erst mal Gedanken gemacht, wie ich das am besten umsetzen kann. Zum einen werden nun Tasks mit view Callbacks gefüttert die beim Starten, bei STDOUT, bei STDERR und beim Beenden des Tasks angesprungen werden. Jede Sprache kann so ihren eigene Build-Chain implementieren. Außerdem wird noch ein Callback zum erstellen der Argumente für den jeweiligen Compiler benötigt. Zu Testzwecken hab ich das erst mal mit der fest implementierten Sprache BlitzMax umgesetzt. Später folgt dann per LUA noch Bismuth und vielleicht auch noch Monkey, wobei ich darin so überhaupt keine Aktien habe.
C-Dialekte werden wahrscheinlich erst mal nicht compilierbar sein. Denn damit hab ich definitiv zu wenig Erfahrung. Den Kopf können sich andere machen...
Die letzten paar Tage hab ich mich mal ein wenig intensiver mit dem Thema "Entkäfern" von Codes auseinander gesetzt. Dazu musste erst mal die NSOutlineViewDataSource Klasse korrigiert werden. Danach habe ich eine allgemein gültige CEDebuggerView mit dazugehörigem CEDebuggerStack (die DataSource für die View) implementiert. Diese sieht momentan wie folgt aus:
Ob die so jetzt endgültig ist wird die Zeit zeigen. Vielleicht fallen mir beim Implementieren anderer Sprachen auch noch andere Anforderungen ein. Auf jeden Fall kann man derzeit noch nicht in den Code springen, oder gar tiefer als einen Level debuggen. Icons fehlen auch noch und die Reihen-Überschriften sind auch noch eher fragwürdig.
Auch auf dem Screen zu sehen ist der Changes-Tracker (In Ermangelung eines besseren Namens so betitelt!) Man kann ihn rechts neben der Zeilennummerierung bestaunen. Grün heißt, die Zeile ist unbearbeitet, Orange heißt, die Zeile ist bearbeitet. Wirklich nichts wildes!
Ein kleines Problem ist noch aufgetaucht: Während ich frohen Mutes meine vier Kerne mit dem Rippen einer mir eigenen DVD quälte, habe ich bei 4x 100% CPU-Auslastung am Debugger gebastelt und mich beim kompilieren übelst gewundert, dass die Ausgabe des Tasks so inkonsistent war. Mal kam nur eine Zeile in der STDERR Pipe an, dann kamen nur ein paar Zeilen... Da muss ich mir noch was einfallen lassen um das zu fixen. Vielleicht Buffern oder so. Mal sehen... Hab mich auch noch nicht schlau gemacht, ob das bei OSX normal ist.
Wenn der Debugger dann soweit ist werde ich wohl mal anfangen mich mit dem Thema "Projekte" auseinander zu setzen. Irgendwann muss die leere, graue View (links auf dem Screen) ja mal verschwinden!
So, anderes ist nicht passiert, denn ich habe meine Zeit eher mit dem Rippen meiner DVD-Sammlung verbracht, als mit Programmieren. Hab mir dafür endlich mal ein Herz gefasst. Aber auch nur, weil ich Filme per itunes jetzt direkt auf den Fernseher streamen kann *hüstel*!
Also dann: GUTE NACHT!
weil ChaosEdit ja laut Plan erst mal nur eine feste Sprache unterstützen soll, aber durch LUA-Scripts auch die Unterstützung anderer Sprachen beherrschen soll, hab ich mir erst mal Gedanken gemacht, wie ich das am besten umsetzen kann. Zum einen werden nun Tasks mit view Callbacks gefüttert die beim Starten, bei STDOUT, bei STDERR und beim Beenden des Tasks angesprungen werden. Jede Sprache kann so ihren eigene Build-Chain implementieren. Außerdem wird noch ein Callback zum erstellen der Argumente für den jeweiligen Compiler benötigt. Zu Testzwecken hab ich das erst mal mit der fest implementierten Sprache BlitzMax umgesetzt. Später folgt dann per LUA noch Bismuth und vielleicht auch noch Monkey, wobei ich darin so überhaupt keine Aktien habe.
C-Dialekte werden wahrscheinlich erst mal nicht compilierbar sein. Denn damit hab ich definitiv zu wenig Erfahrung. Den Kopf können sich andere machen...
Die letzten paar Tage hab ich mich mal ein wenig intensiver mit dem Thema "Entkäfern" von Codes auseinander gesetzt. Dazu musste erst mal die NSOutlineViewDataSource Klasse korrigiert werden. Danach habe ich eine allgemein gültige CEDebuggerView mit dazugehörigem CEDebuggerStack (die DataSource für die View) implementiert. Diese sieht momentan wie folgt aus:
Ob die so jetzt endgültig ist wird die Zeit zeigen. Vielleicht fallen mir beim Implementieren anderer Sprachen auch noch andere Anforderungen ein. Auf jeden Fall kann man derzeit noch nicht in den Code springen, oder gar tiefer als einen Level debuggen. Icons fehlen auch noch und die Reihen-Überschriften sind auch noch eher fragwürdig.
Auch auf dem Screen zu sehen ist der Changes-Tracker (In Ermangelung eines besseren Namens so betitelt!) Man kann ihn rechts neben der Zeilennummerierung bestaunen. Grün heißt, die Zeile ist unbearbeitet, Orange heißt, die Zeile ist bearbeitet. Wirklich nichts wildes!
Ein kleines Problem ist noch aufgetaucht: Während ich frohen Mutes meine vier Kerne mit dem Rippen einer mir eigenen DVD quälte, habe ich bei 4x 100% CPU-Auslastung am Debugger gebastelt und mich beim kompilieren übelst gewundert, dass die Ausgabe des Tasks so inkonsistent war. Mal kam nur eine Zeile in der STDERR Pipe an, dann kamen nur ein paar Zeilen... Da muss ich mir noch was einfallen lassen um das zu fixen. Vielleicht Buffern oder so. Mal sehen... Hab mich auch noch nicht schlau gemacht, ob das bei OSX normal ist.
Wenn der Debugger dann soweit ist werde ich wohl mal anfangen mich mit dem Thema "Projekte" auseinander zu setzen. Irgendwann muss die leere, graue View (links auf dem Screen) ja mal verschwinden!
So, anderes ist nicht passiert, denn ich habe meine Zeit eher mit dem Rippen meiner DVD-Sammlung verbracht, als mit Programmieren. Hab mir dafür endlich mal ein Herz gefasst. Aber auch nur, weil ich Filme per itunes jetzt direkt auf den Fernseher streamen kann *hüstel*!
Also dann: GUTE NACHT!
34 - Hundeklöten
Sonntag, 10. Juni 2012 von d-bug
Hallöle,
ein schönes, langes Wochenende neigt sich dem Ende und ich habe es voll damit verbracht an ChaosEdit und cocoa.appkit rum zu schrauben. Gut das ich mit der IDE angefangen habe, sonst wären mir wohl so einige Bugs in den Modulen durch die Lappen gegangen:
So, das waren mal die wichtigsten Änderungen, denke ich. Aufgefallen sind sie bei:
Lecker Closedialog, der die ganzen offenen und bearbeiteten Dokumente zusammen trägt. Hierbei fiel zumindest die Sache mit den Sheets und mit der NSTableViewDataSource auf.
und bei:
Lecker Konsole. Bestehend aus NSTask, NSTextField und NSTextView. Letztere braucht die Farben in NSAttributedString. (Der Screen erklärt auch den Titel des Worklog-Eintrags!)
Die Konsole selbst kann mittels NSTask alle Terminal Befehle ausführen. Sprich später auch den bmk. Der Task wird gestartet und triggert dann Delegate-Methoden wenns in der stdout pipe was neues gibt. stdin wird auch bereits unterstützt, fehlt eigentlich nur noch stderr. Diese wird im Moment noch mit stdout zusammen gewürfelt.
Trotzdem ist das NSTask um einiges einfacher zu handhaben als TProcess! Das hatte ich nämlich vorher versucht und hab es mal wieder nicht hinbekommen. Am Ende war ich so leid, dass ich mich nach einer Alternative umschaute.
Das wars auch mal wieder.
Bis dann!
ein schönes, langes Wochenende neigt sich dem Ende und ich habe es voll damit verbracht an ChaosEdit und cocoa.appkit rum zu schrauben. Gut das ich mit der IDE angefangen habe, sonst wären mir wohl so einige Bugs in den Modulen durch die Lappen gegangen:
- Farben wurden direkt in eine NSNumber Klasse mit dem RGBA Wert in NSDictionary abgelegt. Ziemlich dumm, wenn man bedenkt das NSAttributedString die NSColor-Klasse direkt benötigen. Hatte ich wohl wegen Scintilla so gemacht?!
- Scintilla musste für den vorherigen Punkt dann auch noch umgebaut werden.
- NSTableViewDataSource funktionierte gar nicht! (NSOutlineDataSource tut es auch immer noch nicht)
- NSTask kam neu dazu. Das ist quasi ein stabiler TProcess Ersatz für Mac OS X. Ich habs nicht komplett eingebaut, aber die wichtigsten Sachen sind drin. (Näheres später)
- NSSavePanel und NSOpenPanel fehlten auch noch komplett!
- NSApplication: Die Methode endSheet musste immer zwei mal getriggert werden. Komische Sache, denn den Fehler hab ich immer noch nicht gefunden, allerdings konnte ich es durch einen Umbau fixen.
- und... und... und...
So, das waren mal die wichtigsten Änderungen, denke ich. Aufgefallen sind sie bei:
Lecker Closedialog, der die ganzen offenen und bearbeiteten Dokumente zusammen trägt. Hierbei fiel zumindest die Sache mit den Sheets und mit der NSTableViewDataSource auf.
und bei:
Lecker Konsole. Bestehend aus NSTask, NSTextField und NSTextView. Letztere braucht die Farben in NSAttributedString. (Der Screen erklärt auch den Titel des Worklog-Eintrags!)
Die Konsole selbst kann mittels NSTask alle Terminal Befehle ausführen. Sprich später auch den bmk. Der Task wird gestartet und triggert dann Delegate-Methoden wenns in der stdout pipe was neues gibt. stdin wird auch bereits unterstützt, fehlt eigentlich nur noch stderr. Diese wird im Moment noch mit stdout zusammen gewürfelt.
Trotzdem ist das NSTask um einiges einfacher zu handhaben als TProcess! Das hatte ich nämlich vorher versucht und hab es mal wieder nicht hinbekommen. Am Ende war ich so leid, dass ich mich nach einer Alternative umschaute.
Das wars auch mal wieder.
Bis dann!
33 - Popover
Sonntag, 3. Juni 2012 von d-bug
Hallo,
da NSPopover mit normalem BlitzMax nicht zu handhaben ist, die Gründe dafür hatte ich ja schon breit gertreten, habe ich mich mal nach einer Alternative umgeschaut. Auslöser war die verkorkste Implementation der CallTips im Cocoa scintilla.framework. Diese reagieren weder auf das setzen des Styles noch werden sie gescheit ein-oder ausgeblendet.
Wie dem auch sei, ich fand schließlich die MAAttachedWindow Klasse. Mit ein Bisschen Design und Spucke kann man aus der einen ziemlich guten NSPopover Ersatz machen!
Das ganze sieht dann so aus:
Außerdem hab ich noch einen ganzen Haufen virtuelle KeyCodes in Konstanten packen müssen. Bin mal gespannt, ob die nach dem Entfall von Carbon noch gültig sind. Die stammen nämlich alle noch von dort.
In ChaosEdit selbst ist nicht viel passiert. Ich hab tatsächlich 2 Tage gebraucht um das Popover-Gedöns zu implementieren und mit Content zu versehen. So viel zum Thema Motivation. Da ich ja unter der Woche nichts mehr mache, wars das dann auch schon wieder.
Als nächstes muss ich mir mal eine gute Lösung zum parsen der Keywords einfallen lassen. Momentan ratter ich da einfach nur die commands.txt aus dem BlitzMax/docs/html/Modules Ordner durch. Diese enthält aber keinerlei Informationen über den Typ des Keywords. Typ im Sinne von: "Ist es ein Type, eine Funktion oder etwa eine Methode?". Wenn ich nun die ganzen Module durchrattern würde, dann würde das ewig dauern. Das kann man ein mal machen, aber nicht bei jedem Start der IDE. Da würde man schon auf Dauer etwas ungehalten werden, wenn man die IDE startet, denke ich. Da das im Moment noch nicht geht, ist das Icon auf dem Bild, oben, auch noch falsch!
cheers
da NSPopover mit normalem BlitzMax nicht zu handhaben ist, die Gründe dafür hatte ich ja schon breit gertreten, habe ich mich mal nach einer Alternative umgeschaut. Auslöser war die verkorkste Implementation der CallTips im Cocoa scintilla.framework. Diese reagieren weder auf das setzen des Styles noch werden sie gescheit ein-oder ausgeblendet.
Wie dem auch sei, ich fand schließlich die MAAttachedWindow Klasse. Mit ein Bisschen Design und Spucke kann man aus der einen ziemlich guten NSPopover Ersatz machen!
Das ganze sieht dann so aus:
Außerdem hab ich noch einen ganzen Haufen virtuelle KeyCodes in Konstanten packen müssen. Bin mal gespannt, ob die nach dem Entfall von Carbon noch gültig sind. Die stammen nämlich alle noch von dort.
In ChaosEdit selbst ist nicht viel passiert. Ich hab tatsächlich 2 Tage gebraucht um das Popover-Gedöns zu implementieren und mit Content zu versehen. So viel zum Thema Motivation. Da ich ja unter der Woche nichts mehr mache, wars das dann auch schon wieder.
Als nächstes muss ich mir mal eine gute Lösung zum parsen der Keywords einfallen lassen. Momentan ratter ich da einfach nur die commands.txt aus dem BlitzMax/docs/html/Modules Ordner durch. Diese enthält aber keinerlei Informationen über den Typ des Keywords. Typ im Sinne von: "Ist es ein Type, eine Funktion oder etwa eine Methode?". Wenn ich nun die ganzen Module durchrattern würde, dann würde das ewig dauern. Das kann man ein mal machen, aber nicht bei jedem Start der IDE. Da würde man schon auf Dauer etwas ungehalten werden, wenn man die IDE startet, denke ich. Da das im Moment noch nicht geht, ist das Icon auf dem Bild, oben, auch noch falsch!
cheers
32 - Hurra, wir leben noch!
Montag, 28. Mai 2012 von d-bug
Hallo zusammen,
als Beweis dafür, dass hier noch fleißig weiter gearbeitet wird, schreibe ich heute mal wieder einen Eintrag.
Eigentlich könnte man sagen, dass ich derzeit eine Leiche ausgrabe und ihr frische Gewänder anziehe! Als Fallstudie zu den Cocoa Modulen habe ich nämlich begonnen ChaosEdit aufzufrischen, bzw. zu klonen!
Momentan sieht das ganze so aus, dass ich ein paar Zeilen an ChaosEdit schreibe und je nach Aufkommen von Bugs, Optimierungsbedarf und Buggies-Hirnrissen die Module fixe und optimiere. Zum Beispiel ist mir beim zusammen hexen eines Bezels, nebst ein/ausfaden, aufgefallen, dass die ganzen Float und Double Übergaben an Cocoa gar nicht funktionieren. Das lag wohl an unzureichender Kenntnis der libobjc. Es bedurfte wieder einiger Stunden Googelei um den nötigen Fix zu finden, aber ich habe es letztendlich geschafft.
Mal kurz ein Screen vom ganzen, damits nicht so langweilig wird...
Die Chrome-Tabs sind übrigens ein Style der PSMTabbar, denn ich da noch rein gehackt habe. Falls sich jemand fragt, was die "'#pragma mark ..." Kommentare da sollen: Die machen lustige Sachen mit der CodeTree für diesen Code. Die mit dem "-" macht einen Separator und die andere macht einen Menü-Eintrag, der quasi als Überschrift gilt.
Nächster Punkt wäre der Stein der die neue Version der Module ins rollen brachte. Vielleicht habt ihr euch bereits gefragt, wozu man denn riesige Texte durchwuseln will um daraus ein Menü zu basteln:
Na klar, der alte Sack bastelt in ChaosEdit wieder eine CodeTree nach Vorlage der älteren XCode IDE!
Gestern habe ich dann das Scintilla Modul auf den neusten Stand gebracht. Eigentlich war nichts berauschendes bei den Updates dabei, außer einer kleinen Sache: Wer OSX kennt, weiß des während einer Textsuche ind Safari oder XCode die Treffer mit gold/gelb hinterlegt werden. Das ging zwar schon seit langem auf eine eher abgespeckte Weise mittels Indicatoren, kann aber nun seit Scintilla 3.1.0 auch in schön dargestellt werden:
(Hier bei der Suche nach "Scintilla" geschnappt)
Vorgestern hatte ich dann noch angefangen den NSTextFinder für Scintilla zu klonen. Daraus entstand dann heute ein tiefer Eingriff in das Scintilla Modul! Erst hatte ich die Suche in ein eigenes Modul packen wollen, hatte mich aber heute Morgen dagegen entschieden und angefangen es direkt ins Scintilla Modul zu integrieren. Daraus erfolgte, dass aus der eigentlich SCNScintillaView jetzt eine Art Container-Klasse wurde die den TextFinder und eine niegel nagel neue, private ScintillaView Klasse enthält. Gott sei dank, hatte ich zum senden der Scintilla Methoden bereits eine eigene Methode implementiert, die von jeder anderen Methode, sei es nun Getter oder Setter, angesprungen wurde. So brauchte ich nur noch diese eine Methode zu ändern.
Wie man sieht fehlt da wohl noch das ganze Replace Zeugs!
Abschließend noch ein paar warme Worte zur IDE:
Sicherlich wird sich das UI das ich hier zeigte noch zig mal ändern. Z.B. bin ich von den Chrome-Tabs nicht so hundert prozentig überzeugt, möchte die Tabs aber gerne in der Titlebar des Fensters behalten. Gestern hab ich ne Mail von Panic über Coda 2 bekommen. Das brachte mich da auf eine Idee...
Natürlich fehlen da noch tonnenweise Features, wie z.B. so vernachlässigbare Sachen wie "Kompilieren"! Wer braucht denn auch so was?! Der Fortschritt an ChaosEdit hängt von meiner Laune ab. Mal hab ich da gar keinen Bock drauf, mal hab ich keine Zeit... Dann bleibt es eben mal ein/zwei Wochen liegen.
Ich schreibe ChaosEdit eigentlich zur Zeit nur zum Testen der Module und um später einen gescheiten, erweiterbaren Editor für mich zu haben. Ob ich das Ding unters Volk werfe ist unklar, nachdem ich der letzte eher ein Disaster war. Selbst wenn ich ihn veröffentliche, dann nur als abgespeckte Version von meiner persönlichen IDE, die ich zuvor unter härtesten Umweltbedingungen getestet habe. Warum der Unterschied? Ganz einfach, Ich hab da nämlich so ein paar Features im Sinn, die eher mit meinen privaten Engines und dergleichen zu tun haben.
Wenn einem eine gescheite Lösung für PlugIns einfällt, die nichts mit Lua zu tun hat, dann immer her damit. Momentan habe ich zumindest schon eine Schnittstelle für Lexer-Abhängige Dingenses per Lua realisiert!
So, genug Geschafel!
als Beweis dafür, dass hier noch fleißig weiter gearbeitet wird, schreibe ich heute mal wieder einen Eintrag.
Eigentlich könnte man sagen, dass ich derzeit eine Leiche ausgrabe und ihr frische Gewänder anziehe! Als Fallstudie zu den Cocoa Modulen habe ich nämlich begonnen ChaosEdit aufzufrischen, bzw. zu klonen!
Momentan sieht das ganze so aus, dass ich ein paar Zeilen an ChaosEdit schreibe und je nach Aufkommen von Bugs, Optimierungsbedarf und Buggies-Hirnrissen die Module fixe und optimiere. Zum Beispiel ist mir beim zusammen hexen eines Bezels, nebst ein/ausfaden, aufgefallen, dass die ganzen Float und Double Übergaben an Cocoa gar nicht funktionieren. Das lag wohl an unzureichender Kenntnis der libobjc. Es bedurfte wieder einiger Stunden Googelei um den nötigen Fix zu finden, aber ich habe es letztendlich geschafft.
Mal kurz ein Screen vom ganzen, damits nicht so langweilig wird...
Die Chrome-Tabs sind übrigens ein Style der PSMTabbar, denn ich da noch rein gehackt habe. Falls sich jemand fragt, was die "'#pragma mark ..." Kommentare da sollen: Die machen lustige Sachen mit der CodeTree für diesen Code. Die mit dem "-" macht einen Separator und die andere macht einen Menü-Eintrag, der quasi als Überschrift gilt.
Nächster Punkt wäre der Stein der die neue Version der Module ins rollen brachte. Vielleicht habt ihr euch bereits gefragt, wozu man denn riesige Texte durchwuseln will um daraus ein Menü zu basteln:
Na klar, der alte Sack bastelt in ChaosEdit wieder eine CodeTree nach Vorlage der älteren XCode IDE!
Gestern habe ich dann das Scintilla Modul auf den neusten Stand gebracht. Eigentlich war nichts berauschendes bei den Updates dabei, außer einer kleinen Sache: Wer OSX kennt, weiß des während einer Textsuche ind Safari oder XCode die Treffer mit gold/gelb hinterlegt werden. Das ging zwar schon seit langem auf eine eher abgespeckte Weise mittels Indicatoren, kann aber nun seit Scintilla 3.1.0 auch in schön dargestellt werden:
(Hier bei der Suche nach "Scintilla" geschnappt)
Vorgestern hatte ich dann noch angefangen den NSTextFinder für Scintilla zu klonen. Daraus entstand dann heute ein tiefer Eingriff in das Scintilla Modul! Erst hatte ich die Suche in ein eigenes Modul packen wollen, hatte mich aber heute Morgen dagegen entschieden und angefangen es direkt ins Scintilla Modul zu integrieren. Daraus erfolgte, dass aus der eigentlich SCNScintillaView jetzt eine Art Container-Klasse wurde die den TextFinder und eine niegel nagel neue, private ScintillaView Klasse enthält. Gott sei dank, hatte ich zum senden der Scintilla Methoden bereits eine eigene Methode implementiert, die von jeder anderen Methode, sei es nun Getter oder Setter, angesprungen wurde. So brauchte ich nur noch diese eine Methode zu ändern.
Wie man sieht fehlt da wohl noch das ganze Replace Zeugs!
Abschließend noch ein paar warme Worte zur IDE:
Sicherlich wird sich das UI das ich hier zeigte noch zig mal ändern. Z.B. bin ich von den Chrome-Tabs nicht so hundert prozentig überzeugt, möchte die Tabs aber gerne in der Titlebar des Fensters behalten. Gestern hab ich ne Mail von Panic über Coda 2 bekommen. Das brachte mich da auf eine Idee...
Natürlich fehlen da noch tonnenweise Features, wie z.B. so vernachlässigbare Sachen wie "Kompilieren"! Wer braucht denn auch so was?! Der Fortschritt an ChaosEdit hängt von meiner Laune ab. Mal hab ich da gar keinen Bock drauf, mal hab ich keine Zeit... Dann bleibt es eben mal ein/zwei Wochen liegen.
Ich schreibe ChaosEdit eigentlich zur Zeit nur zum Testen der Module und um später einen gescheiten, erweiterbaren Editor für mich zu haben. Ob ich das Ding unters Volk werfe ist unklar, nachdem ich der letzte eher ein Disaster war. Selbst wenn ich ihn veröffentliche, dann nur als abgespeckte Version von meiner persönlichen IDE, die ich zuvor unter härtesten Umweltbedingungen getestet habe. Warum der Unterschied? Ganz einfach, Ich hab da nämlich so ein paar Features im Sinn, die eher mit meinen privaten Engines und dergleichen zu tun haben.
Wenn einem eine gescheite Lösung für PlugIns einfällt, die nichts mit Lua zu tun hat, dann immer her damit. Momentan habe ich zumindest schon eine Schnittstelle für Lexer-Abhängige Dingenses per Lua realisiert!
So, genug Geschafel!
31 - Das Grauen hat zwei Namen...
Sonntag, 13. Mai 2012 von d-bug
...NSTableView und NSOutlineView! *grusel*
Zumindest sind die beiden Klassen mein persönliches Grauen, mit dem ich aber soeben abgeschlossen habe! Da sie ja nicht lauffähig sind, wenn man nicht zumindest die dazugehörenden Klassen und Protokolle mit wrappt, artet das ganze gleich in eine riesen Schlammschlacht aus. Bis auf die Sortierung der Einträge habe ich diese allerdings gewonnen! Mit der NSSortDescriptor Klasse, die zum Sortieren notwendig ist, lieg ich noch ein Bisschen im Klinsch, aber auch die krieg ich noch klein, JAWOLL!
Momentan habe ich mich allerdings, zur Entspannung, auf die NSFontManager Klasse gestürzt.
Zeit für ein kleines Update der Liste:
BlitzMax: [AUSKLAPPEN]
Btw. hat das Grauen noch mehr Namen! Ein weiterer Name wäre BlitzMaxIstTotalVeraltetMitSeinemSnowLeopardSDK! So kommt es mir zumindest vor. Manche feinen Neuerungen aus dem 10.7 SDK können einfach nicht realisiert werden. NSPopover z.B., oder die Vereinfachung des Drag&Drop Gedingsels. Bei letzterem wurde es dann auch schwierig die alte Dokumentation zu finden, weil Apple sie teilweise vom Server gefegt hat. Es gibt noch ein paar andere Features von Lion die nicht umgesetzt werden können - z.B. NSTextFinder oder View-basierende TableViews.
Fullscreen-Support funktioniert allerdings tadellos. Wahrscheinlich, weil Apple hier nur vorhandene Methoden mit neuen Konstanten füttert. Die dazu gehörenden Notifications funktionieren sowieso immer. :>
Wie auch immer, sollte Mark sich nicht dazu entscheiden auf die neue SDK umzusteigen, sehe ich keine große Zukunft mehr in BlitzMax auf dem Macces. Ich nehme sogar an, dass es durch den kompletten Wegfall von Carbon in Mountain Lion schon gar nicht mehr funktionieren wird. Warten wir einfach mal ab was die Zukunft bring.
Ich mach trotzdem mal so weiter wie bisher!
Gruße
Zumindest sind die beiden Klassen mein persönliches Grauen, mit dem ich aber soeben abgeschlossen habe! Da sie ja nicht lauffähig sind, wenn man nicht zumindest die dazugehörenden Klassen und Protokolle mit wrappt, artet das ganze gleich in eine riesen Schlammschlacht aus. Bis auf die Sortierung der Einträge habe ich diese allerdings gewonnen! Mit der NSSortDescriptor Klasse, die zum Sortieren notwendig ist, lieg ich noch ein Bisschen im Klinsch, aber auch die krieg ich noch klein, JAWOLL!
Momentan habe ich mich allerdings, zur Entspannung, auf die NSFontManager Klasse gestürzt.
Zeit für ein kleines Update der Liste:
BlitzMax: [AUSKLAPPEN]
Include "classes/nslevelindicator.bmx"
Include "classes/nslevelindicatorcell.bmx"
Include "classes/nstableview.bmx"
Include "classes/nstableheaderview.bmx"
Include "classes/nstablecolumn.bmx"
Include "classes/nstableviewdatasource.bmx"
Include "classes/nsindexset.bmx"
Include "classes/nsoutlineview.bmx"
Include "classes/nsoutlineviewdatasource.bmx"
Include "classes/nsdragginginfo.bmx"
Include "classes/nsdraggingsource.bmx"
Include "classes/nsdraggingdestination.bmx"
Include "classes/nsdraggingsession.bmx"
Include "classes/nspasteboardwriting.bmx"
Include "classes/nsaffinetransform.bmx"
Include "classes/nsfontdescriptor.bmx"
Include "classes/nsfontmanager.bmx"
Btw. hat das Grauen noch mehr Namen! Ein weiterer Name wäre BlitzMaxIstTotalVeraltetMitSeinemSnowLeopardSDK! So kommt es mir zumindest vor. Manche feinen Neuerungen aus dem 10.7 SDK können einfach nicht realisiert werden. NSPopover z.B., oder die Vereinfachung des Drag&Drop Gedingsels. Bei letzterem wurde es dann auch schwierig die alte Dokumentation zu finden, weil Apple sie teilweise vom Server gefegt hat. Es gibt noch ein paar andere Features von Lion die nicht umgesetzt werden können - z.B. NSTextFinder oder View-basierende TableViews.
Fullscreen-Support funktioniert allerdings tadellos. Wahrscheinlich, weil Apple hier nur vorhandene Methoden mit neuen Konstanten füttert. Die dazu gehörenden Notifications funktionieren sowieso immer. :>
Wie auch immer, sollte Mark sich nicht dazu entscheiden auf die neue SDK umzusteigen, sehe ich keine große Zukunft mehr in BlitzMax auf dem Macces. Ich nehme sogar an, dass es durch den kompletten Wegfall von Carbon in Mountain Lion schon gar nicht mehr funktionieren wird. Warten wir einfach mal ab was die Zukunft bring.
Ich mach trotzdem mal so weiter wie bisher!
Gruße
30 - AAAAAAAAAAAAARGGGGLLLL
Mittwoch, 2. Mai 2012 von d-bug
Hallo,
wie dumm kann ein Mensch alleine eigentlich sein? Also von mir kann ich jedenfalls mit Fug und Recht behaupten, dass ich einfach nur noch dumm bin! Ich hatte ja im letzten Post geschrieben, dass ich bei der Bug-Suche diverse Vorgehensweisen durch gespielt und durch getestet hatte... Nur eines hatte ich nie getan und auch nie vermutet:
Es gab da einen Aufruf namens scintilla.lineString(line) in einer For/Next Schleife. Dieser sollte mir eigentlich nur beim Iterieren der Schleife eben immer schön die zur line passenden Text in eine Variable packen, damit ich diese weiter verarbeiten kann. Hat es ja auch gemacht! Dummerweise muss aber in der Methode lineString der String vom CString (nein, kein NSString) in ein BBString konvertiert werden und den Speicher wieder freigegeben werden. Jetzt ratet mal warum die letzte Version 12Sek gebraucht hat. :>
Memo an den zukünftigen User: Lieber vor der Schleife den gesammten Text in ein String[] parken! Geht vieeeel viel schneller!
Nachdem ich das geändert hatte, hat sich nun der Speed drastisch erhöht! Bei den getesteten 150 Menüeinträgen, kam ich nun auf 80ms! Das ist sogar deutlich schneller als MaxGUI bzw. CocoaExt. Wobei ich aber für die Zahlen keine Gewähr übernehme, weil ich nicht weiß, was bei Tests noch im Hintergrund abging.
Jetzt ist es aber eh zu spät um alles wieder Rückgängig zu machen! Ich bin mit der neuen Version in manchen Bereichen schon wesentlich weiter als ich es mit der alten war. Dafür fehlen eben aber auch noch so Hammer-Controls wie NSTextView, NSTableView, NSOutlineView und noch ein paar kleinere wie NSScrollView, NSOpenGLView usw. Was ich allerdings wieder einbaute ist brl.reflections! Da der Schuldige ja nun anderweitig gefunden wurde, hab ich mich offiziell bei Mr.Reflection entschuldigt und ihn wieder in mein Modul-Team aufgenommen!
Also sind Actions nun wieder Methoden, Delegates, Notifications und eigene Actions werden nicht mehr vorgefertigt, sondern können vom Programmierer bei Bedarf im Controller oder in Subklassen implementiert werden usw.
Kurze Liste des aktuellen Gadget Standes (kopiert aus der include Phase des Moduls (man ist ja faul)):
BlitzMax: [AUSKLAPPEN]
Dies sind noch nicht alle 100%ig fertig, aber schon mal als Klasse implementiert, um aus anderen Klassen darauf zugreifen zu können...
Die Todo-Liste muss ich euch nicht vorführen, da die sich eigentlich stündlich verlängert, wenn ich am programmieren bin. Wie man sieht habe ich keinen Masterplan sonder hacke wild vor mich hin!
Die Kompilier-Zeit des cocoa.appkit Moduls (ja, so heißt es nun...) könnte am Ende genau so lang sein wie die von wxMax! Dauert jetzt schon ziemlich. :>
Grüße!
P.S: cocoa.psmtabbarcontrol und cocoa.scintilla sind auch schon fertig!
wie dumm kann ein Mensch alleine eigentlich sein? Also von mir kann ich jedenfalls mit Fug und Recht behaupten, dass ich einfach nur noch dumm bin! Ich hatte ja im letzten Post geschrieben, dass ich bei der Bug-Suche diverse Vorgehensweisen durch gespielt und durch getestet hatte... Nur eines hatte ich nie getan und auch nie vermutet:
Es gab da einen Aufruf namens scintilla.lineString(line) in einer For/Next Schleife. Dieser sollte mir eigentlich nur beim Iterieren der Schleife eben immer schön die zur line passenden Text in eine Variable packen, damit ich diese weiter verarbeiten kann. Hat es ja auch gemacht! Dummerweise muss aber in der Methode lineString der String vom CString (nein, kein NSString) in ein BBString konvertiert werden und den Speicher wieder freigegeben werden. Jetzt ratet mal warum die letzte Version 12Sek gebraucht hat. :>
Memo an den zukünftigen User: Lieber vor der Schleife den gesammten Text in ein String[] parken! Geht vieeeel viel schneller!
Nachdem ich das geändert hatte, hat sich nun der Speed drastisch erhöht! Bei den getesteten 150 Menüeinträgen, kam ich nun auf 80ms! Das ist sogar deutlich schneller als MaxGUI bzw. CocoaExt. Wobei ich aber für die Zahlen keine Gewähr übernehme, weil ich nicht weiß, was bei Tests noch im Hintergrund abging.
Jetzt ist es aber eh zu spät um alles wieder Rückgängig zu machen! Ich bin mit der neuen Version in manchen Bereichen schon wesentlich weiter als ich es mit der alten war. Dafür fehlen eben aber auch noch so Hammer-Controls wie NSTextView, NSTableView, NSOutlineView und noch ein paar kleinere wie NSScrollView, NSOpenGLView usw. Was ich allerdings wieder einbaute ist brl.reflections! Da der Schuldige ja nun anderweitig gefunden wurde, hab ich mich offiziell bei Mr.Reflection entschuldigt und ihn wieder in mein Modul-Team aufgenommen!
Also sind Actions nun wieder Methoden, Delegates, Notifications und eigene Actions werden nicht mehr vorgefertigt, sondern können vom Programmierer bei Bedarf im Controller oder in Subklassen implementiert werden usw.
Kurze Liste des aktuellen Gadget Standes (kopiert aus der include Phase des Moduls (man ist ja faul)):
BlitzMax: [AUSKLAPPEN]
Include "classes/nsobject.bmx"
Include "classes/nsgraphicscontext.bmx"
Include "classes/nserror.bmx"
Include "classes/nsdata.bmx"
Include "classes/nsurl.bmx"
Include "classes/nsdictionary.bmx"
Include "classes/nsattributedstring.bmx"
Include "classes/nsnumber.bmx"
Include "classes/nsvalue.bmx"
Include "classes/nsdate.bmx"
Include "classes/nscolor.bmx"
Include "classes/nscolorlist.bmx"
Include "classes/nscolorspace.bmx"
Include "classes/nsfont.bmx"
Include "classes/nsimage.bmx"
Include "classes/nsnotification.bmx"
Include "classes/nsnotificationcenter.bmx"
Include "classes/nsevent.bmx"
Include "classes/nsresponder.bmx"
Include "classes/nsapplication.bmx"
Include "classes/nscursor.bmx"
Include "classes/nslayoutconstraint.bmx"
Include "classes/nstrackingarea.bmx"
Include "classes/nspasteboard.bmx"
Include "classes/nspasteboarditem.bmx"
Include "classes/nspasteboarditemdataprovider.bmx"
Include "classes/nsfilewrapper.bmx"
Include "classes/nsscreen.bmx"
Include "classes/nsview.bmx"
Include "classes/nscontrol.bmx"
Include "classes/nscell.bmx"
Include "classes/nsactioncell.bmx"
Include "classes/nsshadow.bmx"
Include "classes/nsclipview.bmx"
Include "classes/nsscrollview.bmx"
Include "classes/nsmenu.bmx"
Include "classes/nsmenuitem.bmx"
Include "classes/nsmenuitemcell.bmx"
Include "classes/nswindow.bmx"
Include "classes/nspanel.bmx"
Include "classes/nscolorpanel.bmx"
Include "classes/nstext.bmx"
Include "classes/nsformatter.bmx"
Include "classes/nsbutton.bmx"
Include "classes/nsbuttoncell.bmx"
Include "classes/nspopupbutton.bmx"
Include "classes/nspopupbuttoncell.bmx"
Include "classes/nssound.bmx"
Include "classes/nsdocktile.bmx"
Include "classes/nsdrawer.bmx"
Include "classes/nstoolbar.bmx"
Include "classes/nstoolbaritem.bmx"
Include "classes/nswindowcontroller.bmx"
Include "classes/nsundomanager.bmx"
Include "classes/nssplitview.bmx"
Include "classes/nstabview.bmx"
Include "classes/nstabviewitem.bmx"
Include "classes/nsimageview.bmx"
Include "classes/nstextview.bmx"
Include "classes/nsuserdefaults.bmx"
Include "classes/nsbox.bmx"
Include "classes/nscolorwell.bmx"
Include "classes/nstextfield.bmx"
Include "classes/nstextfieldcell.bmx"
Include "classes/nssecuretextfield.bmx"
Include "classes/nssecuretextfieldcell.bmx"
Include "classes/nssearchfield.bmx"
Include "classes/nssearchfieldcell.bmx"
Include "classes/nstokenfield.bmx"
Include "classes/nstokenfieldcell.bmx"
Include "classes/nsanimation.bmx"
Include "classes/nsviewanimation.bmx"
Include "classes/nsstepper.bmx"
Include "classes/nssteppercell.bmx"
Include "classes/nsslider.bmx"
Include "classes/nsslidercell.bmx"
Include "classes/nsscroller.bmx"
Include "classes/nsgradient.bmx"
Include "classes/nsbezierpath.bmx"
Include "classes/nscharacterset.bmx"
Include "classes/nssegmentedcontrol.bmx"
Include "classes/nssegmentedcell.bmx"
Include "classes/nsrulerview.bmx"
Include "classes/nsrulermarker.bmx"
Dies sind noch nicht alle 100%ig fertig, aber schon mal als Klasse implementiert, um aus anderen Klassen darauf zugreifen zu können...
Die Todo-Liste muss ich euch nicht vorführen, da die sich eigentlich stündlich verlängert, wenn ich am programmieren bin. Wie man sieht habe ich keinen Masterplan sonder hacke wild vor mich hin!
Die Kompilier-Zeit des cocoa.appkit Moduls (ja, so heißt es nun...) könnte am Ende genau so lang sein wie die von wxMax! Dauert jetzt schon ziemlich. :>
Grüße!
P.S: cocoa.psmtabbarcontrol und cocoa.scintilla sind auch schon fertig!
29 - Back to the roots
Dienstag, 10. April 2012 von d-bug
Hallo zusammen,
eigentlich dachte ich cocoa.cocoa wäre so gut wie abgeschlossen und startete einen umfangreichen Test zum Thema Kompatibilität, allgemeines Zusammenspiel und dergleichen. Das hätte ich mal lassen sollen, denn dann könnte ich mit ruhigem Gewissen irgend etwas anderes machen!
Als ich versuchte ein größeres Textfile (den ScintillaView code) einzulesen, auszuwerten und für jede Funktion, jedes Type, jede Methode, jede Konstante und jede Globale einen Menü-Eintrag zu kreieren kam die große Ernüchterung. 12000ms! Wir reden hier vom Erstellen von gefühlten 150 Einträgen (keine Ahnung, habs nicht nachgezählt)... 12sek bei einem Menü, was vor dem Öffnen neu aufgebaut werden muss ist schon ziemlich happig...
Das wollte ich so nicht auf mir sitzen lassen und hab das ganze mit CocoaExt noch mal nachprogrammiert... 100ms! Immer noch lahm, aber doch deutlich schneller als cocoa.cocoa! Also ran ans Werk und Bremsen gesucht. Zwei bis drei Tests später, lieg ich immer noch bei 11000ms! Jetzt weiß ich erst mal keinen Rat mehr. Ich meine, ich hab nun wirklich nicht den lahmsten Mac der Welt, also kann ich das schon mal ausschließen. Ich will gar nicht wissen wie lange das auf meinem MacBook brauchen würde. Meine Vermutungen gehen ganz stark zum übermäßigen Einsatz des brl.reflections Modul. Das hat ja ohnehin den Ruf eine absolute Schnecke unter den Seinen zu sein. Da ich sogar beim Erstellen von Gadgets damit hantiere denke ich mal, dass es daran liegen mag.
Aus Trotz hab ich jetzt angefangen das ganze System umzubauen. Neben dem konsequenten Verzicht auf brl.reflections habe ich auch damit begonnen die ganzen Variablen-und Typenamen wieder mit NS (NextStep) beginnen zu lassen. Noch dazu halte ich mich nun weitestgehend an die original Methoden-Namen (eben bis auf die Doppelpunkte). Dafür verzichte ich allerdings auf das Copy-Paste-Spektakel beim erstellen der Dokumentation. Diese wird es nun nicht mehr geben, immerhin gibt es die ja auf developer.apple.com quasi vorgefertigt und geschenkt! Die Notifications und Delegates, die vorher per Reflections gesucht und ausgeführt wurden sind nun im Basis-Type (NSObject) schon integriert. Actions werden nun als Function-Callbacks übergeben, haben dafür aber einen Parameter mehr als das original. Während in der alten Version eine Action so aussah:
BlitzMax: [AUSKLAPPEN]
Sieht sie jetzt eben so aus:
BlitzMax: [AUSKLAPPEN]
Dies war nötig um die Actions auch an den passenden Plätzen unterbringen zu können. Bei den Vorgefertigten wird da nämlich eine Methode nach Objective-C gebeamt. Das funktioniert aber nur, wenn ich den pointer des targets habe. Da man bei Funktionen so schlecht auf Self zurückgreifen kann, hab ich eben den Parameter target:NSObject dazu geschmiert. Stört ja auch nicht weiter, finde ich...
Zwischenzeitlich habe ich noch versucht die libobjc nebst Wrapper von Nilium zu implementieren um weitestgehend auf das hin-und-her schieben von Funktions-Pointern zu verzichten, aber das scheiterte bereits beim ersten Struct. Ich bin, glaube ich, noch immer nicht gut genug um NSRect mittels objc_msgSend_stret und MemCopy direkt in ein Array oder Type auszulesen! Zumindest scheiterte es genau daran!
Momentaner Stand der Dinge:
Mit kurzen Worten: Alles begann von vorne! Geht aber schneller voran, da die Dokumentations-Kopiererei flach fällt!
Grüße
buggy
eigentlich dachte ich cocoa.cocoa wäre so gut wie abgeschlossen und startete einen umfangreichen Test zum Thema Kompatibilität, allgemeines Zusammenspiel und dergleichen. Das hätte ich mal lassen sollen, denn dann könnte ich mit ruhigem Gewissen irgend etwas anderes machen!
Als ich versuchte ein größeres Textfile (den ScintillaView code) einzulesen, auszuwerten und für jede Funktion, jedes Type, jede Methode, jede Konstante und jede Globale einen Menü-Eintrag zu kreieren kam die große Ernüchterung. 12000ms! Wir reden hier vom Erstellen von gefühlten 150 Einträgen (keine Ahnung, habs nicht nachgezählt)... 12sek bei einem Menü, was vor dem Öffnen neu aufgebaut werden muss ist schon ziemlich happig...
Das wollte ich so nicht auf mir sitzen lassen und hab das ganze mit CocoaExt noch mal nachprogrammiert... 100ms! Immer noch lahm, aber doch deutlich schneller als cocoa.cocoa! Also ran ans Werk und Bremsen gesucht. Zwei bis drei Tests später, lieg ich immer noch bei 11000ms! Jetzt weiß ich erst mal keinen Rat mehr. Ich meine, ich hab nun wirklich nicht den lahmsten Mac der Welt, also kann ich das schon mal ausschließen. Ich will gar nicht wissen wie lange das auf meinem MacBook brauchen würde. Meine Vermutungen gehen ganz stark zum übermäßigen Einsatz des brl.reflections Modul. Das hat ja ohnehin den Ruf eine absolute Schnecke unter den Seinen zu sein. Da ich sogar beim Erstellen von Gadgets damit hantiere denke ich mal, dass es daran liegen mag.
Aus Trotz hab ich jetzt angefangen das ganze System umzubauen. Neben dem konsequenten Verzicht auf brl.reflections habe ich auch damit begonnen die ganzen Variablen-und Typenamen wieder mit NS (NextStep) beginnen zu lassen. Noch dazu halte ich mich nun weitestgehend an die original Methoden-Namen (eben bis auf die Doppelpunkte). Dafür verzichte ich allerdings auf das Copy-Paste-Spektakel beim erstellen der Dokumentation. Diese wird es nun nicht mehr geben, immerhin gibt es die ja auf developer.apple.com quasi vorgefertigt und geschenkt! Die Notifications und Delegates, die vorher per Reflections gesucht und ausgeführt wurden sind nun im Basis-Type (NSObject) schon integriert. Actions werden nun als Function-Callbacks übergeben, haben dafür aber einen Parameter mehr als das original. Während in der alten Version eine Action so aussah:
BlitzMax: [AUSKLAPPEN]
Method action(sender:CCObject)
'mach was tolles
End Method
Sieht sie jetzt eben so aus:
BlitzMax: [AUSKLAPPEN]
Function action(target:NSObject, sender:NSObject)
'mach was total tolles
End Function
Dies war nötig um die Actions auch an den passenden Plätzen unterbringen zu können. Bei den Vorgefertigten wird da nämlich eine Methode nach Objective-C gebeamt. Das funktioniert aber nur, wenn ich den pointer des targets habe. Da man bei Funktionen so schlecht auf Self zurückgreifen kann, hab ich eben den Parameter target:NSObject dazu geschmiert. Stört ja auch nicht weiter, finde ich...
Zwischenzeitlich habe ich noch versucht die libobjc nebst Wrapper von Nilium zu implementieren um weitestgehend auf das hin-und-her schieben von Funktions-Pointern zu verzichten, aber das scheiterte bereits beim ersten Struct. Ich bin, glaube ich, noch immer nicht gut genug um NSRect mittels objc_msgSend_stret und MemCopy direkt in ein Array oder Type auszulesen! Zumindest scheiterte es genau daran!
Momentaner Stand der Dinge:
- NSObject wird zum Dauerläufer und erst gegen Ende fertig
- NSResponder: Events funktionieren schon mal!
- NSEvent: fertig (Alles geht eh nicht, da BMax keine unsigned Datentypen unterstützt (oder?))
- NSColor: fertig
- NSDate: fertig (die gabs nicht mal in der letzten Version ...)
- NSNumber: fertig (ebenfalls ohne unsigned Datentypen)
- NSValue: fertig
- NSImage: fertig
- NSDictionary: Bis die Daten-Typen-Integration auch fertig. Die wächst mit dem Modul.
- NSNotification: fertig (Die Ausführende Funktion mal nicht eingerechnet)
- NSApplication: ca. 50%
- NSMenu: fertig
- NSMenuItem: fertig
- NSWindow: ca. 5%
- NSSchlagMichTot: Also alles andere ... noch nicht mal begonnen! (Bin ja auch erst 2 Tage dran)
Mit kurzen Worten: Alles begann von vorne! Geht aber schneller voran, da die Dokumentations-Kopiererei flach fällt!
Grüße
buggy
Gehe zu Seite 1, 2, 3, 4 Weiter