CocoaExt

Kommentare anzeigen Worklog abonnieren
Gehe zu Seite Zurück  1, 2, 3, 4, 5  Weiter

Worklogs CocoaExt

Quicklook Style Fenster / NSProgressIndicator #2

Donnerstag, 27. August 2009 von d-bug
Jops, wie die Überschrift schon behauptet, ist es seit gestern (war nur zu faul für den Worklog) möglich Fenster auch mit dem aussehen des QuickLook-Features von OSX zu erstellen.

- entfallen / + hinzu / #geändert

+ CreateCocoaQuickLookWindow:TGadget (Title, X, Y, W, H, Parent, Style)
Macht genau das was oben beschrieben wird. Der Flag WINDOW_CLIENTCOORDS scheint nicht zu funktionieren. Lässt sich aber auch nicht beheben, da sowohl das mit WINDOW_TOOL erstellte Fenster als auch dieses QuickLook-Fenster eigentlich gar keine wirklichen Fenster sind, sondern ein NSPanel. Da beseht ein gewisser Unterschied...

Screen:
user posted image


Außerdem gabs noch einen kleinen Bug zu beheben, der dazu führte, dass ProgressIndicator beim vergrößern/verkleinern eines Fensters die Applikation zum Absturz brachten.

# CreateCocoaProgressIndicator (X,Y,W, H, Parent, BezelStyle, Modes)
wurde intern durch ein SetGadgetLayout (gadget, 0, 0, 0, 0) erweitert. Nun funktionierts, aber verstehen tu ich es nicht!

so, das wars für heute.

Neue Version wird gleich ins SVN Repository geladen.

NSProgressIndicator #1 und final

Dienstag, 25. August 2009 von d-bug
Huhu,

hab mal eben den Abend genutzt um den ProgressIndicator von MaxGUI zu vervollständigen.

- entfallen / + hinzu / #geändert

+ CreateCocoaProgressIndicator (X,Y,W, H, Parent, BezelStyle, Modesl)
Kleine Erweiterung des CreateProgBar Befehls. Man kann nun auch die runden Indicator mit dem BezelStyle NSProgressIndicatorSpinningStyle einstellen, ebenso per Modes die einfache, nicht wandernde NSProgressIndicatorIndeterminate-Variante (der gestreifte auf dem Screen). Außerdem kann man noch per Mode NSProgressIndicatorIsNotAnimated die Animationen abschalten.

+ StopCocoaProgressIndicatorAnimation (ProgressIndicator)
Animation eines ProgressIndicators abschalten.

+ StartCocoaProgressIndicatorAnimation (ProgressIndicator)
Animation eines ProgressIndicators einschalten.

# SetCocoaGadgetValue (ProgressIndicator)
Mit dem Einstellwert für die ProgressIndicator gefüttert. Sprich, erweitert... (warum denn bitte auch einen
extra Befehl? Aber keine Panik, UpdateProgBar funktioniert auch weiterhin.

Screen:
user posted image

...gn8



NSSplitView #1

Montag, 24. August 2009 von d-bug
Hallo Gemeinde,

nun hab ich zwei Tage daran gewurschtelt die NSSplitView-Klasse zu implementiern. Das ist wohl die billigste, dümmste, undurchdachteste Klasse die Cocoa zu bieten hat, nehme ich an. Das Vieh hat mich echt extreme Nerven gekostet und kann noch immer nicht alles was es können sollte!

Im Moment muss ich einen kleinen Trick anwenden, damit die Panels, die ich auf jede View der SplitView legte nicht plötzlich zu klein sind, wenn man am Divider (die Linie in zwischen den Views) zupft. Die Panels der unteren View bei horizontaler Anordnung und der rechten View bei vertikaler Anordnung müssen so groß sein, wie beide Views zusammen, damit man die linke bzw. obere View komplett an den Rand ziehen kann. Auf jeden Fall werden die Panels NICHT automatisch der jeweiligen View angepasst. Man schiebt also das Panel in Originalgröße einfach nach links und rechts bzw. hoch und runter. Hat eh keiner verstanden, hm?

kurzum:

- entfallen / + hinzu / #geändert

+ CreateCocoaSplitView (X,Y,W, H, FirstSize, Parent, DividerStyle, Modesl)
Erstellt eine neue SplitView. FirstSize ist die Breite der linken View, oder die Höhe der oberen View.
DividerStyle regelt das Aussehen des Dividers. Mit NSSplitViewDividerStyleThin wird die dünne Linie (Screen) dargestellt und mit NSSplitViewDividerStyleThick die dicke Version mit dem Punkt in der Mitte.
Bei Modes kann man bisher nur einstellen, ob die SplitView horizontal (Modes = 0) oder vertikal, Modes = NSSplitViewIsVertical

+ AddCocoaSplitViewFrame (SplitView)
Erstellt einen zusätzlichen Frame in der SplitView und legt ein Panel darauf welches zurückgegeben wird.

+ TileCocoaSplitView (SplitView)
weist allen Frames einer SplitView die gleiche Höhe (bei horizontaler SplitView) oder die gleiche Breite (bei vertikaler SplitView) zu.

+ GetCocoaSplitViewLeftFrame (SplitView)
Gibt den linken Frame einer vertikalen SplitView als Panel (TGadget) zurück.

+ GetCocoaSplitViewRightFrame (SplitView)
Gibt den rechten Frame einer vertikalen SplitView als Panel (TGadget) zurück.

+ GetCocoaSplitViewTopFrame (SplitView)
Gibt den oberen Frame einer horizontalen SplitView als Panel (TGadget) zurück.

+ GetCocoaSplitViewBottomFrame (SplitView)
Gibt den unteren Frame einer horizontalen SplitView als Panel (TGadget) zurück.

Alle weiteren Frames werden ja nachher mit AddCocoaSplitViewFrame eingefügt, die von Hause aus das Panel zurückgibt. Links/Rechts, Oben/Unten werden allerdings schon beim erstellen der SplitView angelegt und müssen nachträglich abgefragt werden.

Screen:
user posted image
Zu sehen ist eine vertikale SplitView, die als Child auf dem rechten Frame eine horizontale SplitView hat.
das Spielchen lässt sich fortsetzen, bis der Rechner abschmiert.

Doofer Screen, weil voll nicht aussagekräftig, aber wie bitte soll man eine SplitView darstellen. :/

Kein NSGadget heute...

Samstag, 22. August 2009 von d-bug
...denn die Bottom-Bar ist kein wirkliches Gadget:

- entfallen / + hinzu / #geändert

+ CreateCocoaBottomBar (H, Window)
Ich hatte mich schon länger mal gefragt, ob die dicke Zeile am unteren Ende des Fensters von iPhoto, Linkinus und dergleichen den auch eine Toolbar ist... und wie, zum Henker, kommt die da hin... Nun gut, ich begab mich also auf die Suche und fand irgendwann durch Zufall in der HIG (Human Interface Guidelines) einen Hinweis darauf. Bzw. erfuhr ich dort endlich wie das Ding hieß... BOTTOMBAR! Google machte dann den Rest. Entstanden ist daraus eben CreateCocoaBottomBar. Eigentlich ist die BottomBar nichts weiter als die Verbreiterung des unteren Rahmens eines Fensters. um das aber etwas bequemer zu gestalten, wird mit dieser Funktion gleich ein Panel zurück gegeben, dass die Größe der Bar hat und auch automatisch vergrößert/verkleinert wird, wenn man am Fenster zieht.

+ CreateCocoaClientArea (BottomBar, Window)
Kleines Helferlein um den Platz zwischen Bottom-Bar und Title-bzw.Toolbar als Panel zurück zu bekommen. Wird schon benötigt, da die eigentlich Client-Area des Fensters auch mit der Bottom-Bar belegt wird. So ist es einfacher den richtigen Platz zu bekommen. Das zurückgegebene Panel passt sich ebenfalls der Größe des Fensters beim Vergrößern/Verkleinern an.


Nachteil an der ganzen Geschichte: Leider muss man beim erstellen einer Applikation mit Toolbar und BottomBar auf die Reihenfolge der Erstellung achten. Weiß der Geier wieso. Die Reihenfolge wäre wie folgt:
Arrow Fenster
Arrow Bottombar
Arrow Toolbar komplett mit Items
Arrow ClientArea

Achtet man nicht darauf schmiert einem die App mit einer Cocoa-Fehlermeldung ab, die irgendwo bei den Panels liegt, die ich allerdings nicht anfassen werde. Hält man sich allerdings daran läuft alles super.

Noch der Screen
user posted image

... weg ...

NSOpenPanel, NSSavePanel #1

Freitag, 21. August 2009 von d-bug
So, da ich ja heute frei UND sturmfrei habe, kommt ne ganze Menge Zeugs bei rum:

- entfallen / + hinzu / #geändert

+ CocoaRequestFile (Title, Extensions, SaveFlag, InitialPath, Parent, AccessoryView, AccessoryEventCallback)
Sheet-Support der anderen Art. Leider ist es bei diesen Requestern nicht 100%ig möglich sie mit den normalen Fenster-Dialogen konform zu halten. Anders gesagt, die Sheets bieten einfach mehr Möglichkeiten sich auszutoben.

Also hab ich den Sheets mal noch das sogenannte AccessoryView gegönnt und auf Panel limitiert. Jetzt kann man ein Panel erstellen, darauf munter Gadgets verteilen und bei Öffnen einens Requesters mit CocoaRequestFile zuweisen. Spitzen Geschichte, wenn man mehrere Formate zum speichern anbieten will. Leider berdarf es dafür eines Event-Callbacks. Den so ein Sheet ist modal und hat ohnehin schon einen eigenen Event-Loop in dem abgefragt wird ob Okay oder Cancel gedrückt wurden.

So ein Callback sähe dann in etwa so aus:
BlitzMax: [AUSKLAPPEN]
Function AccessoryCallback (Event:TEvent)
Print Event.ToString ()
End Function

(natürlich mit mit Abfragen drin, aber man ist ja faul!)

Da Sheets ja keine Titelbar haben, nutzt CocoaExt die Variable Title jetzt für die Message, die einem Requester bei Cocoa zugewiesen werden kann.

+ CocoaRequestDir (Title, InitialPath, Parent, AccessoryView, AccessoryEventCallback)
Siehe langes BlaBla von oben.

...und natürlich der Screen:
user posted image
Man sieht hier einen mit CocoaRequestFile erstellten NSSavePanel mit Message (oben) und AccessoryView (oberhalb der Buttons)

Leider habe ich noch keine Möglichkeit gefunden die alle Standard-Requester von Cocoa zu lokalisieren. Die FileRequester und der Customize-Requester der Toolbars sind mir da noch ein Dorn im Auge.



Jetzt mal so ein paar generelle Hinweise.
Mir ist aufgefallen, dass jedesmal, wenn ich hier was poste, ein paar Leute die Download-Seite besuchen und die gleiche alte Version von neulich wieder downloaden. Wenn ihr was aktuelles wollt, dann seid ihr da aber eher falsch. Geht lieber her und besorgt euch einen SVN-Client und checkt das Repository auf dem BBP-SVNServer aus. Ihr findet es im scope chaos.mod/cocoaext.mod. Heute hab ich die Download-Version noch mal aktualisiert, aber normalerweise ist die Version immer veraltet.


Letzten wurde ich per PM darauf angesprochen, warum CocoaExt nicht mit normalen 2D-Spiele-Applikation funktionieren würde. Jemand wollte das... Ähm HALLO?! Wie oft soll ich noch schreiben, dass es sich dabei um eine MaxGUI-Erweiterung handelt und als solche auch auf MaxGUI basiert. Kurz: ES GEHT EINFACH NICHT! Auch z.B. wenn RequestFile ein normaler BlitzMax-Befehl ist, der auch ohne MaxGUI lebensfähig ist, so braucht CocoaRequestFile doch die Variable Parent, die eindeutig ein TGadget Objekt ist, dass BlitzMax von Hause aus NICHT hat. Diese Klasse gibt es NUR bei MaxGUI!

So, ich bin raus!

NSAlert #2 / NSMenuItem #2

Freitag, 21. August 2009 von d-bug
Hallo,

ein paar kleine Erweiterungen mussten noch gemacht werden, damit man sagen kann, dass die beiden Themen abgeschlossen sind.


NSAlert #2

- entfallen / + hinzu / #geändert

+ Header Support für alle bisherigen Dialoge
Damit man auch mal was anderes als Header verwenden kann als die vorgegebene Variable AppTitle.


NSMenuItem #2

- entfallen / + hinzu / #geändert

+ GetCocoaApplicationMenuHide ()
Gibt ein TGadget Objekt für das "Hide"-Item im Applikations-Menü zurück um den Text lokalisieren zu können oder dergleichen.

+ GetCocoaApplicationMenuHideOthers ()
Gibt ein TGadget Objekt für das "Hide Others"-Item im Applikations-Menü zurück um den Text lokalisieren zu können oder dergleichen.

+ GetCocoaApplicationMenuShowAll ()
Gibt ein TGadget Objekt für das "Show All"-Item im Applikations-Menü zurück um den Text lokalisieren zu können oder dergleichen.

+ GetCocoaApplicationMenuQuit ()
Gibt ein TGadget Objekt für das "Quit"-Item im Applikations-Menü zurück um den Text lokalisieren zu können oder dergleichen.

+ AppName-Tag für MenuItems
Man kann im Label von Menu-Items jetzt einen Tag angeben, der einem an der Stelle den File-Namen der Applikation einträgt, so wie es im Applikations-Menü häufiger vorkommt. Siehe folgendes Beispiel:
BlitzMax: [AUSKLAPPEN]
CreateCocoaMenu ("Über {AppName}", 1001, GetCocoaApplicationMenu ())
CreateCocoaMenu ("", 0, GetCocoaApplicationMenu (),0,0)
CreateCocoaMenu ("Einstellungen ...", 1002, GetCocoaApplicationMenu (), KEY_COMMA, MODIFIER_SYSTEM)
CreateCocoaMenu ("", 0, GetCocoaApplicationMenu (),0,0)
SetCocoaGadgetText (GetCocoaApplicationMenuHide (), "{AppName} ausblenden")
SetCocoaGadgetText (GetCocoaApplicationMenuHideOthers (), "Andere ausblenden")
SetCocoaGadgetText (GetCocoaApplicationMenuShowAll (), "Alle einblenden")
SetCocoaGadgetText (GetCocoaApplicationMenuQuit (), "{AppName} beenden")

Dies ist der komplette Code um das Applications-Menü lokalisieren und erweitern zu können.

Noch ein Screen des Ergebnisses:
user posted image

Schönen Tag noch!

NSAlert #1

Dienstag, 18. August 2009 von d-bug
Hallöle!

Wir alle kennen ja die BlitzMax-Befehle Notify (), Confirm () und Proceed (), die ja nichts anderes darstellen als eine MessageBox in verschiedenen Ausführungen. Nun hat Cocoa aber zwei Möglichkeiten diese auszuführen. Zum einen ist da das normale Fenster, so wie BRL es implementierte und zum anderen das so genannte Sheet. Ein Sheet ist eine Art Panel, dass von unterhalb der Titelleiste eines Fensters aufscrollt und auch an der Titelleiste hängen bleibt. Ich präsentiere also:

- entfallen / + hinzu / #geändert

CocoaNotify (Message, Critical, Parent, OkayLabel)
Ein normaler Notify-Alert, der bei der Übergabevariable Parent ein mit CreateWindow erstelltes Fenster akzeptiert. Übergibt man dieses Fenster wird daraus ein Sheet-Alert. Außerdem kann man den Text des "OK"-Buttons mit der Übergabevariable OkayLabel anpassen. Message und Critical sind eigentlich die beiden Grund-Variablen die BRL mit Notify () auch bietet.

CocoaConfirm (Message, Critical, Parent, OkayLabel, CancelLabel)
siehe CocoaNotify, aber mit "Cancel"-Button, dessen Text mit CancelLabel angepasst werden kann.

CocoaProceed (Message, Critical, Parent, YesLabel, CancelLabel, NoLabel)
siehe CocoaConfirm, allerdings hier mit Yes und No.



Die Screens:
user posted image
Normaler eingedeutschter CocoaProceed-Dialog der mit...
BlitzMax: [AUSKLAPPEN]
CocoaProceed ("blub",,,"Ja","Abbrechen","Nein")

... erstellt wurde!


user posted image
und hier das ganze noch mal als Sheet, dass mit...
BlitzMax: [AUSKLAPPEN]
Global MyWindow:TGadget = CreateWindow (AppTitle, 0, 0, 300, 200, Null, WINDOW_TITLEBAR | WINDOW_CLIENTCOORDS | WINDOW_CENTER)
CocoaProceed ("bla",, MyWindow,"Ja","Abbrechen","Nein")

... erstellt wurde!


Weitere Sheet-Dialoge, so wie z.B. RequestFile, RequestDir usw. folgen demnächst. Erst aber muss ich einem allseits bekannten Menschen noch einen Wunsch bezüglich der Menüs in der Menüleiste erfüllen.

So, bis dahin...

NSMenuItem #1

Sonntag, 16. August 2009 von d-bug
So quasi als Nachschlag hab ich mich mal an das Problem des Applikations-Menüs begeben.

- entfallen / + hinzu / #geändert

+ GetCocoaApplicationMenu ()
Gibt einem das Applikations-Menü als TGadget-Objekt zurück.


+ CreateCocoaMenu:TGadget (Title, Tag, Parent, HotKey, Modifier)
Ist eigentlich nur eine Art Kopie des CreateMenu Befehls, kann aber mit dem Applikation-Menü als Parent auch was anfangen. Benutzt man nämlich CreateMenu (also der Befehl von BRL) werden alle Items hinter dem "Quit"-Item eingetragen. Mit diesem Befehl allerdings werden alle Items vorne vor dem "Hide"-Item eingetragen. Andererseits kann man mit diesem Befehl aaber auch normale MaxGUI-Menüs erstellen.


BlitzMax: [AUSKLAPPEN]
Global MyAppMenu:TGadget = GetCocoaApplicationMenu ()
CreateCocoaMenu ("About "+AppTitle, 1001, MyAppMenu,0,0)
CreateCocoaMenu ("", 0, MyAppMenu,0,0)
CreateCocoaMenu ("Preferences", 1002, MyAppMenu,0,0)
CreateCocoaMenu ("", 0, MyAppMenu,0,0)



user posted image

Ich weiß, ich bin ein Ar***, weil ich diesen Eintrag nicht in den letzten editierte. Aber hierbei handelt es sich um ein gaaanz anderes Thema!

Das war es aber nun wirklich für heute!

NSTextField #2 oder eher NSSearchField #1

Sonntag, 16. August 2009 von d-bug
So, nachdem ich jetzt mein System von Altlasten befreit habe, sprich es neu aufgesetzt habe, hab ich mich mal wieder frohgemut an CocoaExt begeben.

Erstes Teilprojekt nach der Entrümplungsaktion:

- entfallen / + hinzu / #geändert

# CreateCocoaSearchField (X, Y, W, Parent, Modes, PlaceHolder, RecentAmount, RecentTitle)
Es gibt nun einen neuen Mode für Suchfelder. Dieser lautet NSSearchFieldRecentMenu. Er aktiviert das Menü mit den letzten Such-Tags. Man kann mit der Übergabevariable RecentAmount die Anzahl der anzuzeigenden Tags ändern. Mit RecentTitle wird der Titel der Liste gesetzt.

Eigentlich sollte das in der PList der Applikation, sprich der Config, gespeichert werden. Leider werd ich dafür erst mal die NSUserDefaults Klasse wrappen müssen, denn es wird nicht automatisch gespeichert und ich muss das speichern manuell auslösen können. Wenn die Tags allerdings ein mal drin stehen werden sie wenigstens schon mal automatisch ausgelesen. Da muss ich Apple mal meinen Unmut ausprechen. Das ist bei der NSToolbar Klasse doch wesentlich freundlicher gelöst. Die schreibt automatisch diese PList, wenn die ToolbarItems geändert wurden.

Noch den tollen Screen des Tages:
user posted image

Gehabt euch wohl...

NSStepper #1 / NSTextField #1

Donnerstag, 13. August 2009 von d-bug
Sodele, nach dem ich nun ein paar Tage hab ins Land ziehen lassen, damit die Links aus dem letzten Post nicht nach zu weit nach unten rutschen, stelle ich hiermit ein paar neue Gadgets vor:

- entfallen / + hinzu / #geändert

+ CreateCocoaStepper (X, Y, Parent, Value, Increment, Modes, MinValue, MaxValue)
Ein Stepper ist eigentlich eine Kombination aus zwei Buttons. Sie sind dafür gedacht dem Benutzer eine einfache Möglichkeit zu geben einen numerischen Wert zu erhöhen oder zu verringern. Normalerweise treten sie zusammen mit einem Textfield auf. Soweit bin ich allerdings noch nicht.
Intern bestehen dieser numerische Wert bei CocoaExt aus einem String, der immer fein hin und her gecasted wird. Jaja, ich weiß, dass das langsamer ist als einen IntWrapper beizulegen... Mal ehrlich, wen interessiert das denn nun wirklich bei einer GUI? Ist ja schließlich nicht realtime.
Eine ausführliche Anleitung der Übergabevariablen findet sich, wie immer, in der Dokumentation.

+ Tonnenweise Funktionen zum Casten und Modifizieren von Werten
Da werd ich jetzt mal nicht näher drauf eingehen wollen... Viel zu viel Arbeit das!


+ CreateCocoaTextField (X, Y, W, Parent, BezelStyle, Modes, Placeholder)
Was ein Textfield ist brauch ich wahrscheinlich nicht mehr zu erklären. Im Gegensatz zu dem Original hat dieses hier allerdings einen zusätzlichen Bezel-Style und es unterstützt Platzhalter. Ein Platzhalter ist der Text, der z.B. bei Safari in der Searchbar angezeigt wird, wenn man dort noch nichts eingetippt hat. Außerdem kann man diese Textfields per Modes vorm Markieren und Editieren schützen, oder die Bezel-Styles ganz abschalten... Des weiteren werfen Textfields jetzt auch während des Tippens einen Event mit dem eingegebenen Text aus.

+ CreateCocoaSecureTextField (X, Y, W, Parent, BezelStyle, Modes)
Dieses hier ist ebenfalls ein Textfield. Es zeigt allerdings seinen Text nur als Punkte an und ist für Passwortabfragen gedacht. Im Gegensatz zu normalen Textfeldern posten diese Lümmel auch keine Events mit KlarTexten durchs ganze System sondern müssen per GadgetCocoaText aufegfordert werden ihren Text preis zu geben. Platzhalter gibts auch keine! Man würde sie eh nicht lesen können!

+ CreateCocoaSearchField (X, Y, W, Parent, Modes, PlaceHolder)
So, ich hatte in diesem Eintrag: https://www.blitzforum.de/work...age=2#1595 ... großkotzig ein SearchItem für Toolbars vorgestellt. Diesen hab ich nun wieder getötet! Dafür gibt es jetzt ein Gadget, dass nicht nur in der Toolbar benutzt werden kann. Man kann dieses allerdings per AddCocoaToolbarViewItem auf eine Toolbar kleistern lassen. Generell ist das auch nur ein Textfield mit ein Cancel-Button, der beim Tippen rechts auftaucht und einer Lupe, die links im Feld ist und mehr oder weniger auch nur einen Tastendruck auf "Return" simuliert.


Noch ein Screen:
user posted image
Ich finde den eher langweilig... Smile


Im allgemeinen klingt das alles simpler als es in Wirklichkeit war. Gerade für die Stepper musste ich ein wenig in die BMax und Obj-C Trickkiste greifen. Obj-C sagt seiner Action z.B. nur noch 1 oder -1 und setzt den wert wieder direkt zurück. Alle Berechnungen der Werte werden dann via Callbacks im internen Event-Handler von BMax ausgeführt... Total wirrer scheiß, aber es funktioniert... Ehrlich!... So glaubt mir doch! Smile

cheers

Gehe zu Seite Zurück  1, 2, 3, 4, 5  Weiter