Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Kann mir jemand sagen wie ich eine Componente (Quicktime View, JPanel, etc) unter Open GL anzeige. Ich habe sowas schon mal irgendwo gesehen. Da wird wohl die Graphics2D der Componente in eine Textur geschrieben und dann bei Clicks an das AWT weitergeleitet (vermute ich einfach mal :rtfm: ).
Wäre nett, wenn mir jemand einen kurzen Codeschnipsel hier ins Forum hängen könnte, damit ich das Prinzip in Live-Code sehen könnte (AWT Component Copy => Texture => Clicks)
Für Swing hatte ich mal Swogl gebastelt. Leider hatte ich schon lange, lange (viel zu lange ) keine Zeit mehr, daran wirklich produktiv weiterzumachen, aber die Priorität erhöht sich ständig. Für reine AWT-Components funktionierte das aber nicht, die werden ja "vom Betriebssystem spendiert".
Werd ich mir gleich mal ansehen und damit ein wenig rumspielen.
Hast Du damit schon erfolgreich auch Videos auf eine Textur abspielen können (mit einem Java-Video-Codec oder von einer Quicktime-Componente)?
Ja, ist aber noch in einem frühen Stadium. "Intern" habe ich schon einige (deutliche) Umstrukturierungen angefangen, aber davon ist noch nichts final.
Ein Video wollte ich schon ewig mal darauf abspielen. Könnte in bezug auf die Performance schwierig werden, aber mit einem einigermaßen modernen Rechner sollt's klappen Ich hätte mir dazu erstmal ein bißchen was aus dem Java Media Framework angeschaut, dort gibt es ja schon eine Video-Componente. DIE ist zwar AWT, aber vielleicht könnte man die ja anpassen...
Das hört sich gut an. Ja JMF (wegen dem Video -> Jogl) habe ich mir angesehen, nur läuft das nicht unter Mac.
Eine Frage, kannst Du mir sagen warum Swogl eine hohe CPU Auslastung produziert?
Bei meinen Versuchen habe ich eine CPU Auslastung von ca. 50-60% (wenn ich nichts mache, System: MacMini 2009 late, 2.2 Ghz CPU NVidia 9400M Grafikkarte, 4 GB Ram)
Kommt das daher weil die Componenten eben aufwendig gezeichnet werden müssen?
Ok, den Quellcode habe ich mir angesehen. Du benutzt den TextureRenderer wie ich gesehen habe.
Mal ein paar Gedanken zu Swogl...
Was ich mir wünschen würde ist ein sehr schmales System ohne jeglichen Schnickschnack (3DLayout, 3D Animatied, etc).
Sprich ich baue mir ein JPanel mit ein paar Swing komponenten, mache ein paar ActionListeners drauf, und dann mit einem Funktionsaufruf: dropIntoOpenGL(SwingCompomponente) kann ich das in meine OpenGL3D Welt einbauen. Dann kann man im OpenGL 3D Raum die Swing-Komponente bedienen (ohne Verschieben und Resize im 3D Raum).
Ich meine, das 3D Handling etwa wie: verschiebe 3D Objekt im Raum, macht man meistens sowieso selber, weil man da eigene Vorstellungen hat, oder es zwangsläufig anders machen muss. Weiss nicht wie ich es genau ausdrücken soll, aber es geht ja bei Swogl darum das Problem Swing Componenten auf OpenGL anzuzeigen, und darauf sollte man sich beschränken. Und nicht Lightning, Camera, Movement.
Alternativ könnte man noch eine "generelle" Beispiel-Picking/Resiziung Demo machen, wo im 3D Raum ein Objekt von der Maus gepickt und im 3D Raum bewegt/Resized werden kann. Ich denke das ist sinnvoller als eine eigene 3D Welt mit Swing aufzubauen, wobei 80% davon für die meisten Einsätze nicht gebraucht werden.
Was hälst Du davon? Übrigens sollte man auf GLPanel verzichten und alles in GLCanvas rendern, weil wenn schon OpenGL, dann richtig :toll:
Ich werde mir auch mal den TextureRenderer von Jogl mal ansehen, denn ich glaube nicht das es den in LWJGL gibt... dann muss ich mir wohl das was ich oben beschrieben habe, irgendwie selber zusammenbasteln, da ich genau sowas kleines flexibles für mein System brauche. Mal schaun. ob ich das gebacken bekomme :rtfm:
Alternativ dazu, wenn Du Zeit und Lust dazu hast, könnte man das zusammen realisieren (Zeitplan ca. 1 Monat zur Fertigstellung und Optimierung). Im Prinzip braucht man ja nur eine Funktion: dropMyJPanelIntoOpenGL3D(SwingCompomponente)
Wie schon gesagt: Swogl liegt schon länger "brach" als mir recht sein kann. Ich glaube, dass es eine ganze coole Bibliothek sein/werden könnte, wenn ich die Möglichkeit hätte, mehr Zeit zu investieren. Einige der Punkte, die du angedeutet hast, liegen schon in der Pipeline und wurden auch schon ansatzweise umgesetzt, aber um sie "gut" umzusetzen müßte ich mal wieder richtig ranklotzen. (Ich werd' wohl wirklich auf Teilzeit umstellen. Jeden Tag 8 Stunden sinnlos im Büro rumhängen ist ätzend....)
Was ich mir wünschen würde ist ein sehr schmales System ohne jeglichen Schnickschnack ...
Sprich ich baue mir ein JPanel ... mit einem Funktionsaufruf: dropIntoOpenGL(SwingCompomponente) kann ich das in meine OpenGL3D Welt einbauen.
Ich meine, das 3D Handling etwa wie: verschiebe 3D Objekt im Raum, macht man meistens sowieso selber...
Alternativ könnte man noch eine "generelle" Beispiel-Picking/Resiziung Demo machen...
Diese Punkte sind genau die Ziele des "Refactorings": Es sollte mehrere Schichten geben, auf denen man Swogl verwenden kann. Einerseits einfach eine Methode, wo man eine Swing-Component reinsteckt und ein OpenGL-Objekt rausbekommt. Darauf aufbauend (aber soweit das sinnvoll möglich ist, getrennt davon) eine Bibliothek, mit der man 3D GUIs basteln kann, mit 3D Layout & Co.
Im Moment ist die Richtung ja eher die umgekehrte: Es gibt Swogl, mit dem man 3D-GUIs bauen kann, und mit ein bißchen Getrickse könnte man vielleicht noch eigene Sachen dazurendern, aber Swogl selbst ist die "Hauptanwendung". Das entspricht eigentlich nicht den meisten potentiellen Anwendungsfällen...
Aber das ganze so als "add on" für beliebige 3D-Szenen umzusetzen ist wirklich nicht einfach. Wenn du dir den Code schon angesehen hast, hast du vielleicht gesehen, dass da ziemlich "getrickst" wird. Das Event-Handing und Repainting bei Swing ist nicht so trivial, wie es bei reiner Verwendung von Swing vielleicht aussieht. Da hat man einen Listener hier und einen Repaint-Aufruf da, alles schön einfach. Aber in Wirklichkeit muss ein JButton eben gehighlightet werden, wenn man mit der Maus drüberfährt, und ein Cursor muss blinken, und z.B. für letzteres gibt es praktisch keine Events, die man dafür abgreifen könnte...
Was hälst Du davon? Übrigens sollte man auf GLPanel verzichten und alles in GLCanvas rendern, weil wenn schon OpenGL, dann richtig
Ich werde mir auch mal den TextureRenderer von Jogl mal ansehen, denn ich glaube nicht das es den in LWJGL gibt... dann muss ich mir wohl das was ich oben beschrieben habe, irgendwie selber zusammenbasteln, da ich genau sowas kleines flexibles für mein System brauche. Mal schaun. ob ich das gebacken bekomme
Das wäre das erste, was ich in Angriff nehmen würde: Eine Verallgemeinerung in bezug auf die OpenGL-Anbindung! Im Moment wird noch JOGL 1.1.1a verwendet, mit OpenGL 1.x - sprich, glBegin, glPushMatrix, und all die Späße. Erstens sollte das ganze in Zukunft auf OpenGL 3.2 aufbauen: Man muss sich nur überlegen, was man mit ein paar schönen Shadern alles machen könnte. Zweitens (ganz wichtig) sollte es unabhängig(er) von JOGL werden, weil JOGL nicht ganz so straff weitergepflegt wird. Als erstes sollte es natürlich auch LWJGL unterstützen, aber das ganze natürlich so schön allgemein beschrieben und strukturiert, dass man irgendwann sowas hat wie
Java:
// Swogl.useRenderer(new JOGLRenderer()); // Och nö, heute mal nicht
Swogl.useRenderer(new LWJRLRenderer());
// TODO: Swogl.useRenderer(new JMERenderer());
Auch der TextureRenderer gefällt mir nicht so, erstens natürlich weil er sehr speziell für JOGL ist, und zweitens weil er zwar einfach zu verwenden, aber für manche Sachen doch zu unflexibel ist. (Wobei es genau der TextureRenderer war, der überhaupt die Initialzündung für Swogl dagestellt hatte: "Hey, da gibt's ein 'paint(Graphics)' - da kann man ja Swing in Texturen rendern ... :reflect: ... " ). Zu diesem Punkt gab es hier im Forum auch schon gelegentlich Diskussionen. Insbesondere würde ich gerne mal einem BufferedImage einen DataBuffer unterjubeln, der direkt in den Grafikkartenspeicher führt.
Alternativ dazu, wenn Du Zeit und Lust dazu hast, könnte man das zusammen realisieren (Zeitplan ca. 1 Monat zur Fertigstellung und Optimierung). Im Prinzip braucht man ja nur eine Funktion: dropMyJPanelIntoOpenGL3D(SwingCompomponente)
Jein. Natürlich würde ich mich über Unterstützung freuen (und es wäre ein willkommener Anlass, selbst mal wieder richtig an Swogl zu arbeiten. Aber 1 Monat ist nicht. Sorry. Allein die Fragen, wie man von der Ziel-Engine abstrahiert und wie sie verwaltet werden, und wie man das Event-Handling (ohne den im Moment in Swogl verwendeten "Trick") macht, werden deutlich (!) mehr Zeit benötigen. (Z.B. ist die Umstellung zwischen GLJPanel und GLCanvas wegen heavy/lightweigt-Problemen nicht so einfach).
Wie die Geometrie repräsentiert wird, welche Shader verwendet werden, WO und WIE man die Trennlinie zieht zwischen der "machMir3D(panel)"-Bibliothek und dem 3D-Swing wären dann Fragen, die teilweise später geklärt werden könnten, aber darüber Gedanken machen sollte man sich schon vorher.
Es gibt übrigens ein (englisches) Forum zu Swogl: Swogl - Byte-Welt Forum und wenn man HIER im Forum nach "Swogl" sucht, findet man etliche Threads zu den oben genannten Themen, und Dingen, die noch darüber hinaus gehen.
So. Das letzte Update auf der Website stammt von 2009 - so kann das nicht weitergehen! Inzwischen bin ich wieder auf dem Stand, dass ich in der kommenden Woche endlich mal wieder an Swogl weiterzumachen werde :toll:
Ich habe auch herausgefunden warum Swogl so langsam ist... das liegt am "setLookAndFeel"
Alles ausser "Nimbus" braucht zu viel Renderzeit. Ich denke das liegt einfach an den vielen Images die da drinstecken und die bei jedem Update neu gerendert werden müssen. Da scheint "Nimbus" wohl nicht so viel drin zu haben.
Ich würde "Swogl" auch einen anderen Namen geben, etwa "SwingGLProjektor" und dann mir die Funktionen ansehen:
- TextureRenderer
- 3D Picking
... dann den ganzen Kram ohne den ganzen Ballast coden (alles endlos verschachtelte raus).
Ich für meinen Teil habe schon überlegt den ganzen Listener Kram in meinem 3D Projekt wegzulassen und das alles zu vereinfachen. Die Mausabfragen selber zu verarbeiten und den Code immer weiter zu vereinfachen. Man glaubt garnicht was da alles möglich ist. Mein Projekt hatte vorher ca. 20 Java Dateien, übriggeblieben sind nur noch 6. Und wenn man sich den Code ansieht: sehr leicht verständlich, übersichtlich, klein, universell.
Ich habe mir die letzten 2 Tage CyberDuck (FTP Programm für Mac) angesehen... oh mein Gott... Librarys ohne Ende... Codezeilen ohne Ende. Ich meine, Librarys verwenden schön und gut, aber das bläht das Projekt dermassen auf und keiner steigt mehr so richtig durch... und Fehler finden, naja (das dauert). Hatte mir CyberDuck wegen Rococoa/Cocoa NS Objekte angesehen, da in Rococoa nur das notwendigste implementiert ist und CyberDuck die Cocoa Library um ca. 60% erweitert
Jedenfalls ist es der Wahnsinn was einige mit Java und Bliotheken anstellen :shock:
Tip: Man darf nicht "schauen" was einen an Arbeit erwartet, sondern mit der kleinsten Einheit "anfangen".
So würde ich es auch machen und anfangen bei::rtfm:
[Java]
SwingGLProjektor {
Vector<Box3D> boxes = new Vector<Box3D>();
buildSwing3DBox(JPanel swingPanel) {
Box3D box = new Box3D();
box.buildTextureFromJPanel(swingPanel);
boxes.add(box);
}
Ach ja die Rechenzeit: Bezog sich das auf das Beispiel mit der "Rumswogelnden" (animierten) Component? Die hat auch eine ziemlich hohe Auflösung und so, das ist wohl nicht repräsentativ... Normalerweise sollte, wenn man nichts macht, auch keine Rechenzeit verbraten werden, abgesehen von Neuzeichnen bei Cursorblinken und solchen Sachen. Es gibt im Quellcode an ein paar Stellen aber auch noch Kommentare, was noch optimiert werden könnte. Aber erstmal sollte es alles einigermaßen funktionieren...
Das mit dem Code... klingt... ... ... ohne dir zu nahe treten zu wollen... schon ein bißchen naiv. Natürlich schüttelt man so eine Bibliothek nicht from scratch komplett einfach aus dem Ärmel. Irgendwo muss man anfangen. Und so ein paar Zeilen aufschreiben, um sich klar zu werden, wie man das ganze gerne verwenden können wollte, ist ja gut. Aber von der Frage, was eine "Box3D" sein soll, über die Frage, wie und wo Texturen repräsentiert werden, bis hin zu der Methode "mousePickCheckAndForwardToBox3D" (die auch [c]doEverythingThatSwoglDoes[/c] heißen könnte ) gibt es da etliche Punkte, die man nicht mal so an einem nachmittag hin-hackt. Und wenn, dann kommt da mit Sicherheit nichts raus, was man anderen zumuten kann.
Ich denke der Fehler ist schon in denken von Bibliotheken (da schaltet das Gehirn schon automatisch auf "bombast" = Haufen Arbeit).
Aber von der Frage, was eine "Box3D" sein soll, über die Frage, wie und wo Texturen repräsentiert werden, bis hin zu der Methode "mousePickCheckAndForwardToBox3D" (die auch doEverythingThatSwoglDoes heißen könnte ) gibt es da etliche Punkte, die man nicht mal so an einem nachmittag hin-hackt. Und wenn, dann kommt da mit Sicherheit nichts raus, was man anderen zumuten kann.
Sollte man denken, muss es aber nicht zwangsläufig. Man kann auch an einem Nachmittag ziemlich schnell geniale Sachen machen, wenn man sich auf das notwendigste und nicht auf das kompletteste konzentriert.
Bei Nimbus läuft beim Zeichnen intern einiges anders. Mit den Details habe ich mich noch nicht sooo weit auseinandergesetzt, aber bei den anderen LAFs wird alles vom jeweiligen UI selbst gezeichnet, und beim Nimbus wird eher "beschrieben" wie das GUI aussehen soll, und es werden dann generische Zeichenmethoden verwendet (da kann man wohl sinngemäß sein LAF mit XML beschreiben...). Wo genau der Performanceunterschied herkommt, weiß ich aber auch nicht...
Wenn es nun um die Frage geht, ob das eine Bibliothek werden soll, oder eine kleine Hilfsklasse: Letzteres wird nicht reichen. Man kann zwar mit wenig Aufwand an einem Nachmittag ein Programm schreiben, das eine Swing-Component als Textur auf eine JOGL-Geometrie klatscht. Und natürlich ist die "Kernidee" ganz einfach:
Java:
public void paint(Graphics g)
{
super.paint(texture.getGraphics());
}
...
public void mouseMoved(MouseEvent e)
{
passTo(targetComponent(), e);
}
Aber das kann eben aufwändig umzusetzen sein. Wenn man dann in der Event-Queue rumwerkeln muss, damit die Events da ankommen, wo sie hinsollen, und man dem RepaintManager klar machen muss, wo die Textur aktualisiert werden muss, und auf einmal eine ComboBox aufklappt, deren Menü über die Component, wo sie eigentlich drinliegt, hinausragt, und bei der Scrollpane nicht richtig gezeichnet wird, weil sie intern diese cleveren bit-blit-Tricks verwendet, und man nach stundenlangem Wühlen im Swing-Quelltext festellt: "Mensch, der Separator von einem JSplitPane ist heavyweight - aber nur, während man ihn bewegt :autsch: ", merkt man: Das ist nichts für eine Utility-Klasse.
Sicher könnte man bei Swogl etliches weglassen, wenn man keine animierten Layouts will, und keine Interaktion mit den Components, die über die reine Bedienung der Swing-Elemente hinausgeht. Auch das hätte noch genug Stolperfallen. Aber Swogl sollte eben all diese Möglichkeiten bieten. In einer anderen (sauberer getrennteren und aufgeräumteren) Form als jetzt, aber es sollte sie geben.
Du kannst ja mal versuchen, ein Utility zu schreiben, das so funktioniert, wie du es angedeutet hast (Ohne bei Swogl zu klauen ). Und wenn du zum fünften oder zehnten mal denkst: "Ach eigentlich wollte ich das so-und-so machen, aber dazu muss ich erst das-und-das machen, und dafür brauche ich erst dies-und-jenes (mal googlen ob's da nicht schon was fertiges gibt ) und so-und-so funktioniert das eh nicht....", und dein Utility sich dann langsam in eine Bibliothek verwandelt, wirst du merken: Das ist nicht so einfach, wie es aussieht. Dann kann man nur versuchen, es (durch eine "gute" API) für den Benutzer der Bibliothek einfach aussehen zu lassen....
Du kannst ja mal versuchen, ein Utility zu schreiben, das so funktioniert, wie du es angedeutet hast (Ohne bei Swogl zu klauen ). Und wenn du zum fünften oder zehnten mal denkst: "Ach eigentlich wollte ich das so-und-so machen, aber dazu muss ich erst das-und-das machen, und dafür brauche ich erst dies-und-jenes (mal googlen ob's da nicht schon was fertiges gibt ) und so-und-so funktioniert das eh nicht....", und dein Utility sich dann langsam in eine Bibliothek verwandelt, wirst du merken: Das ist nicht so einfach, wie es aussieht. Dann kann man nur versuchen, es (durch eine "gute" API) für den Benutzer der Bibliothek einfach aussehen zu lassen....
Da ist was wahres dran. Klar. Man kann das auch nicht von der 1. Version verlangen. Denke das ist ganz normal. Die Probleme mit den Swing Elementen, da hast Du sicher mehr Erfahrung und kennst die ganzen Probleme. Die ganzen Stolperfallen kenne von vielen anderen Sachen und Du hast recht, gerade da verbrät man manchmal Tage nur um ein kleines Problem zu lösen
Aber ich bin auch immer der Meinung... da geht immer was besser, und es muss nicht immer das sein was einem andere weiss machen wollen :rtfm: denn ich habe schon so oft erlebt, dass andere in ganz anderen Bahnen denken, und genau deshalb nicht auf die Lösung kommen, die Du aber siehst, oder Dir zumindest durch andere Denkweise erarbeiten kannst.
Naja, bleib auf jeden Fall dran, ich bin jedenfalls beeindruckt von Swogl. Und ich denke wenn Du die ganze Sache noch mehr Handy machst, dann werden Dir viele dafür sehr dankbar sein.
Achso... anstatt die Textur zu resizen von einer 3D Box (wenn man mit ALT-Taste und mit dem Mauszeiger am Box-Rand ist), solltest Du die 3D Box selber in der Größe ändern.
Ja, das stimmt natürlich: Es kann leicht mal passieren, dass man sich in eine Problematik (oder ganz speziell: in ein spezifisches Problem, das man glaubt, unbedingt lösen zu müssen) "verrennt", und damit Zeit verschwendet, und jemand anderes vielleicht sagen würde: "Das ist doch gar nicht wichtig", oder (was noch deprimierender ist) sagt: "Dazu kannst du einfach die Methode [c]com.sun.java.secret.Magic#doesWhatYouWant()[/c] aufrufen und fertig!"
Aber wie schon gesagt: Der Teufel steckt im Detail. Swing sieht einfach aus (wenn man es anwendet), und Swogl sieht einfach aus (wenn man es anwendet und sowas wie den TextureRenderer kennt), aber das beides zu verheiraten IST NICHT einfach. Mit den verwendeten "Tricks" ist es zwar auch kein überirdisches Hexenwerk, aber eben auch nicht trivial.
Das mit dem Resizen ist eines der Probleme, die AUCH bei dem Refactoring gelöst werden sollen. Wenn man das ganze (wie du es angedeutet hast) darauf reduziert, eine Textur auf ein Objekt zu legen und Events weiterzureichen, stellt sich diese Frage zwar nicht, aber für den allgemeinen Fall tritt das Problem auf, dass einem einfach die Buttons ausgehen. Linke und Rechte Maustaste sind ohnehin belegt, und einige Swing-Components verwenden schon Modifiers wie STRG oder SHIFT um bestimmte Aktionen auszulösen. ALT macht unter Windows immer Probleme. Und wenn nun für den Fall des "SpaceLayouts" nach dazukommt, dass man sowohl
- die Geometrie der SwoglComponent als auch
- den Inhalt der SwoglComponent
in der Größe ändern können will, und dann noch drehen und verschieben, wird's eben knapp. Ansätze, wie man das lösen könnte, gibt es schon, aber die müssen noch genauer evaluiert (und im Hinblick auf eine bessere Trennung von Layout und Bedienung und die Möglichkeit, diese Interaktionen möglichst frei konfigurieren zu können(!) ggf. auch revidiert) werden. Im Moment kann man die Größe der Geometrie einer SwoglComponent, wie du es angedeutet hast, durch STRG+SHIFT+ZiehenMitMittlererMaustaste ändern (soweit ich mich erinnere). Ja, man sieht, das Refactoring ist dringend notwendig
Das mit den vielen Tastekombinationen... da musst Du aufpassen. In absehbarer Zeit bedient kein Mensch mehr seinen Computer mit der Maus/Keyboard.
Ich würde den ganzen kram ummodelieren in ein TouchMenu. In etwa irgendwo auf dem Screen einen Button setzen, und wenn man dort draufdrückt, dann kann man Optionen wählen (Drehen/Zoomen/ etc.)
Ich rüste mein Projekt auch gerade auf Touch only um, und behalte nur die linke Maustaste für noch Maus-Computer-Benutzung (Touch-Emulation) bei. Multi-Touch macht man dann mit Touch-ALT festhalten (1 Punkt), noch einen Punkt anklicken (2 Punkt) => Zoomen/Drehen.
Auch DAS ist schon in der "Queue", wenn auch relativ weit hinten. Bis Maus und Keyboard wirklich tot sind, wird es noch eine Weile dauern. Und im Moment würde man dafür noch etliche externe Bibliotheken benötigen, weil die Unterstützung noch nicht sooo verbreitet ist. Aber wie man an dieser "iPhone-Musik-Browse-Demo" schon sieht, gibt es ja Sachen, bei denen sich Touch schon allein aus Prinzip aufdrängt
Aber ein wichtiger Punkt dabei ist der, der ohnhin (auch bei Muassteuerung) schon ansteht, nämlich die Möglichkeit, das ganze besser konfigurieren zu können. Im Moment gibt's da nur so ein paar (zugegeben "halbärschige") Abfragen, ob die gewünschten Modifier-Tasten gedrückt sind, aber um das ganze flexibler zu machen, muss man sich was richtiges überlegen. Dazu gab's in diesem Beitrag schon einiges, aber alles noch sehr grob.
(Und wie du jetzt (Multi)touch noch zusätzlich in eine einzlene, kleine Utility-Klasse packen wolltest, würde mich mal interessieren )
Naja, bei mir läuft das so... ich such mir mögliche Lösungen. Stopf die in den Quellcode (sieht schrecklich aus, aber läuft ) Dann beginnt die Optimierungsphase... und dann wird so lange optimiert bis es klein und schmal ist. Wenn dann die Struktur nicht mehr stimmt schreib ich's mit den neuen Erkenntnissen einfach neu. Und dann ist die Lösung nahezu perfekt für mich.
Ist zwar nicht professionell... und dauert manchmal 1-2 Jahre, aber ich bekomm das was ich will
(Ich bin leider kein Freund von tiefschürfenden und bis ins kleinste Detail ausgearbeiteten Konzepten ... ich weiß, das ist ein Problem :rtfm: ... ich mach mir einfach ne Skizze und programmierer drauf los. Das hat auch einen Vorteil, ich mache mir keine Gedanken über den "Aufwand" den ich für das Projekt betreiben muss, wo andere es aus Zeitangst erst garnicht beginnen)
Ich finde auch, dass es keinen Sinn macht, ein Jahr lang zu planen und dann zu versuchen, das Ergebnis innerhalb eines Monats runterzuschreiben. Auch wenn manche Softwareingenieure das propagieren. Iteratives verbessern ist spätestens dann notwendig, wenn man die Software schon allein deswegen nicht planen kann, weil man vorher gar nicht weiß, ob das ganze überhaupt funktionieren wird. Und Swogl hat auch als ein verkümmerter JTree auf irgendeinem hackig reingeladenen OBJ angefangen. Aber spätestens wenn man gedenkt, das zu veröffentlichen, und andere das verwenden sollen, kann man eben nachher nicht mehr "einfach so was wegnehmen". Da gilt IMHO eher Gauss' Motto "Pauca sed matura".
Aber spätestens wenn man gedenkt, das zu veröffentlichen, und andere das verwenden sollen, kann man eben nachher nicht mehr "einfach so was wegnehmen". Da gilt IMHO eher Gauss' Motto "Pauca sed matura".
) keine Zeit mehr, daran wirklich produktiv weiterzumachen, aber die Priorität erhöht sich ständig. Für reine AWT-Components funktionierte das aber nicht, die werden ja "vom Betriebssystem spendiert".
