Ich habe mir die „Notes“ und die „Help“ mal angeschaut und mir erscheint, dass es zwischen denen einen grossen „Ueberlap“ gibt. Macht es denn nicht Sinn, die „Core“ Klassen und die dazugehoerigen Unterstuetzungsklassen in DockingFrames direkt zu uebernehmen und damit den Rumpf fuer eine Anwendung so zur Verfuegung zu stellen, dass der Programmierer noch seine Menues hinzufuegt und dann alle anderen Dinge (wie zB Toolbars und andere Elemente zur Interaktion) dann von Dockable ableitet und lokal implementiert. Davon muss der Rumpf der Applikation ja eigentlcih gar nichts wissen.
Was halten Sie davon?
Ihr Projekt fiel nach endlosen Google Sessions mal raus. Ich weiss die Abfrage aber nicht mehr, die ich benutzt habe. Es gibt noch ein paar Konkurenten, die ich aber alle nicht soo gut finde:
Eclipse: SWT ist kein Standard; hat auf Firmenrechnern keine Installationsbasis; das Drag and drop funktioniert nicht so gut wie bei DockingFrames
NetBeans: Ich habe es nicht begriffen, wie es funktioniert (Doku ist irgendwie schlecht, oder ich bin zu bloed); es funktioniert auch nicht so recht nach meinem Geschmack
Flexdock, XUI Docking Framework, jdocking: alle irgendwie nicht nach meinem Geschmack
mfg
Uwe
PS: Referenz ist diese email von Ihnen:
Hallo
Da ich nicht weiss, an welcher Stelle Sie stecken geblieben sind, und
was genau Sie implementieren möchten, kann ich Ihnen leider nicht direkt
helfen.
Wenn Ihnen der Quellcode nicht weiterhilft, dann schicken Sie mir noch
ein Mail.
(Oder was mir fast noch lieber wäre: besuchen Sie http://forum.byte-welt.de/ . Dort einfach zu „Java > Gui Programmierung“
gehen und ein neues Topic eröffnen. In so einem Forum ist ein Dialog
einfacher zu führen als per Mail)
Zu den anderen Fragen:
Ich arbeite nach dem Prinzip „it’s done when it’s done“
Aber ich hoffe bis Ende August ein paar Bugs zu eliminieren, die Demos
aufzuräumen, sie auch zu dokumentieren und im Guide die besten
Codeschnippsel der Demos zu präsentieren. Das soll dann alles in einem
grossen Download, Demos inklusive, als Release Candidate 2, angeboten
werden.
Danach kommt nochmal eine Runde Bugfixing, vielleicht eine weitere Demo,
und schliesslich das Final Release.
Wie es später weiter geht, ist noch offen.
Reine Neugier meinerseits: wie haben Sie von dem Projekt erfahren?
[QUOTE=uwh1][…]Macht es denn nicht Sinn, die “Core” Klassen und die dazugehoerigen Unterstuetzungsklassen in DockingFrames direkt zu uebernehmen […]
Was halten Sie davon?[/QUOTE]
Ich finde die Grundidee gut. Es gibt Überschneidungen, auch mit anderen Applikationen, welche ich nicht veröffentlich habe. Ich habe dies bis jetzt ignoriert, da ich diese Core-Klassen immer ziemlich schnell geschrieben hatte.
Ich denke, ich werde bei Gelegenheit ein Unterprojekt starten, das solche Dinge als Erweiterung anbietet. Dann kann ich mir auch mal Gedanken machen, wie ich diese “Core”-Klassen ein bisschen abstrahieren kann.
Direkt in die DF möchte ich das nicht integrieren. Es würde die Library nur aufblähen, und die Übersicht ist jetzt schon mittelmässg.
(Wie das zeitlich aussieht, kann ich nicht sagen. Ich sollte noch für ein paar Prüfungen lernen…)
ich fang dann schon mal an damit, mal sehen, wie weit ich komme. Bitte nicht zu viel erwarten, ich habe 2 kleine Kids und arbeite Vollzeit. Wenn ich was habe, melde ich mich wieder … auch, wenn ich Fragen habe
Gruessle
Uwe
wie bringe ich es hin, dass ein Flap ein Dockable akzeptiert, das aus eine Flap kommt? Das funktioniert in Deiner Notes App, aber ich finde es nicht, wo Du das einrichtest. Bei mir muss ich immer ueber eine Dockstation gehen, wo das ganze dockable zu sehen ist. Direkt kann ich nicht von einem Flap in ein anderes ziehen.
Kannst Du mir einen Hinweis geben, wo ih das in der Notes App finde, damit ich mir das im Code anschauen kann?
Die Reihenfolge, wie die Stationen bei dem Frontend/Controller angemeldet werden, könnte allenfalls eine Rolle spielen. Bei den Notes sieht es folgendermassen aus:
(aus “bibliothek.notes.view.ViewManager”)
east = new FlapDockStation();
west = new FlapDockStation();
south = new FlapDockStation();
north = new FlapDockStation();
screen = new ScreenDockStation( owner );
frontend.addRoot( east, "east" );
frontend.addRoot( west, "west" );
frontend.addRoot( south, "south" );
frontend.addRoot( north, "north" );
frontend.addRoot( split, "split" );
frontend.addRoot( screen, "screen" );
frontend.setDefaultStation( split );```
Ich habe die CENTER - Split Geschichte zuerst zum Controller added. Das hat das komische Verhalten ausgeloest. Wenn ich die gleiche Reihenfolge nutze, wie Du, dann funktioniert es.
Ist das ein Bug, oder ein Feature? Ich haette es als Bug gesehen… weil es auch in der API nicht beschrieben ist.
ich bin’s wieder. Wenn ich eine SimpleButtonAction erzeuge und sie an viele Dockables anhaenge, wie bekomme ich dann heraus, an welchem Dockable ich den Knopf gedrueckt habe? Naja, cih kann ja auch fuer jedes Dockable eines erzeugen…
Noch iene Frage zu den Actions. Als Default kommt ja der Maximizer Button mit hoch. Wie bekomme ich den los? Wenn ich es so mache wie im Guide:
DefaultDockActionSource source = new DefaultDockActionSource();
dockable.setActionOffers( source );
SimpleButtonAction action = new SimpleButtonAction();
source.add( action );
und danach nur noch die Action configuriere, dann behalte ich trozdem den Maximizer. Ich meine, das ist ja nett, wenn ich nur rects davon noch den “x” Button fuer das Schliessen erzeugen koennte…
Zur SimpleButtonAction: überschreibe die Methode “action”, die erhält das Dockable.
Zum Maximizer: überschreib bei der SplitDockStation die Methode “createFullScreenAction”, und gib null zurück. Allerdings folgt gleich der Weg, wie du das x rechts ranbringen kannst:
Zum x rechts: Du kannst auch einen “ActionGuard” implementieren, und bei dem DockController mit “addActionGuard” registrieren. Bei “getSource” des ActionGuards gibts du dann eine DockActionSource zurück, die den Location-Hint “ganz rechts” hat:
new LocationHint(
LocationHint.ACTION_GUARD,
LocationHint.RIGHT_OF_ALL ));```
Zu Schreibfehlern: *hust*, das nachträglich ändern würde einigen Code durcheinanderbringen, deshalb lasse ich die lieber drin... aber danke für den Hinweis.
Ne, du hast mehr als eine DockActionSource. Ein Dockable kann zwar nur eine Source direkt angeben, aber mit einem ActionGuard kann man leicht mehrere Sources pro Dockable verwenden.
Ich geb auf. Ich suche seit Ewigkeiten, wie ich ein Dockable, das irgendwo sichtbar ist, in einen Flap verschieben kann. Einfach droppen geht nicht, da sich das Dockable nicht automatisch von seiner alten Station loest (waere das nicht nett?). In der Help-Applikation machst Du die Operation ja schon irgendwie, aber die ganzen Manager und Minimizer und Maximizer sind mir einfach zu verwirrend. Hilfee!!
Hallo Beni,
wenn ich mit dockable.getDockParent().drag(dockable);
ein Dockable unsichtbar mache und dann die Variable dockable loesche, wird dann das dockable Garbage collected, oder muss ich das noch irgendwo abmelden?
Die kommen in den Garbage. Du kannst die “finalize”-Methode überschreiben und gucken ob sie aufgerufen wird, falls du nicht sicher bist (bei mir wird sie jedenfalls aufgerufen).
Lediglich die Root-DockStationen müsste man abmelden.
in der Beschreibung fuer CombinerWrapper steht folgendes:
Parameters:
old - a Dockable which sits on the DockStation parent
drop - a Dockable that has currently no parent, and that was dragged over old
parent - a DockStation which will become the parent of the returnvalue of this method
Returns:
The combination of old and drop
Wenn ich combine aufrufe und old haengt noch an parent (sits on) dann wird eine Exception geworfen: darf nicht an parent haengen…