Closed Elmari closed 1 month ago
strengejacke
commented
4 years ago Ich hatte immer Mal vor, JavaFX zu verwenden, weil man mit der Textkomponente mehr Formatierungsmöglichkeiten hat. Ich denke, am einfachsten sind 1) und 2), wenn man nicht grundsätzlich alles neu aufsetzen will.
Nichtsdestotrotz würde ich vorschlagen, in Kürze eine neue Version zu veröffentlichen, die die aktuellen Fixes beinhaltet.
Elmari
commented
4 years ago Okay. Hattest du vor die aktuelle Zettel-Eingabe dann durch einen WYSIWYG-Editor zu ersetzen oder wie meinst du das mit den Formatierungsmöglichkeiten?
Bzgl. neuer Version: klingt gut. Ich könnte mir die Tage mal die Github Actions anschauen, dann könnten wir den Zettelkasten automatisiert über maven bauen lassen. launch4j gibt's auch als maven plugin. Mac app bundles kann man mit diesem Plugin bauen lassen, .deb-Packages mit diesem hier .
strengejacke
commented
4 years ago Hattest du vor die aktuelle Zettel-Eingabe dann durch einen WYSIWYG-Editor zu ersetzen oder wie meinst du das mit den Formatierungsmöglichkeiten
Nein, das nicht. Aber, zumindest unter Java 7 und 8, konnte die Textkomponente kaum CSS rendern.
strengejacke
commented
4 years ago Hier stehen ein paar Infos: https://stackoverflow.com/questions/4117302/swing-jeditorpane-css-capabilities
Soweit ich weiß, kann man mit JavaFX Textkomponenten verwenden, die aktuelle CSS/HTML Standards unterstützen. Das Eingabeformat wollte ich grundsätzlich langfristig auf eine Art "extended Markdown" umstellen.
strengejacke
commented
4 years ago Ich hatte mal mit einem Bekannten, der eine ZKN-App speziell für Mac erstellt, an einem Multimarkdown-Format gearbeitet, aber es ist nie wirklich voran gekommen:
# This is the title
> Quoted text goes here, quoted text goes here. Even more quoted text goes here. This is a quotation that was, for example, highlighted in a PDF document.
Personal comments follow here. These are your comments about the above quotation. More comments follow here…
Metadata that refer to the quotation start with a `<` character and can be entered wherever you like. Syntax coloring helps to identify elements, and these colors can be adjusted in the prefs.
The syntax for keywords and citekeys follows the MultiMarkdown syntax, and keywords & citekeys can be autocompleted.
You can insert cross links to other notes using the regular link syntax, such as [refuting][] or [supporting][]. I.e., cross links are similar to a regular [web][] link. An optional note title and link relationship type can be appended as attributes to the link reference information.
See also [@sea ice]
[refuting]: keypoints://note/1234-abcde-5678-fghjk "Note title" class=refutes
[supporting]: keypoints://note/4321-acegh-9876-jlnpr "Another note title" class=supports
[web]: http://wippp.com/blog/ "Jeff Taekman's blog"
< p.24, highlighted (Important) Jan 12, 2015
< [#Luedecke2006xy]: Lüdecke, D (2006) Reference title goes here. Mar Ecol Prog Ser 112(3):23–29
< keypoints://doi/10.1234/xyz.12345678
< ★★★ [@meteoric ice] [@fast ice] [@Baltic Sea] [@ice temperature] [@ice salinity]
Elmari
commented
4 years ago Soweit ich weiß, kann man mit JavaFX Textkomponenten verwenden, die aktuelle CSS/HTML Standards unterstützen. Das Eingabeformat wollte ich grundsätzlich langfristig auf eine Art "extended Markdown" umstellen.
Verstehe. Vielleicht sollten wir, neben Bugfix-Releases, eine schrittweise Migration nach JavaFX anpeilen. Für's erste würde hier wahrscheinlich die Integration von JavaFX in Swing reichen, also einfach das JEditorPane durch WebView austauschen. Anschließend könnte man dann den Zettelkasten vollständig nach JavaFX porten.
Das Extended Markdown ließe sich evtl. mit flexmark umsetzen. Das unterstützt das Parsing einiger Markdown-Familien.
RalfBarkow
commented
4 years ago Ich hatte immer Mal vor, JavaFX zu verwenden
Erste Versuche zu JavaFX in Bezug auf "Zettelkasten: To migrate to JavaFX, or not to migrate?" hatte ich unter https://github.com/RalfBarkow/ZettelkastenFX unternommen.: feature/ZettelkastenView
RalfBarkow
commented
4 years ago Für's erste würde hier wahrscheinlich die Integration von JavaFX in Swing reichen […]
Im November 2019 hatte ich begonnen, "Lessons Learned in Migrating From Swing to JavaFX" zu recherchieren, bin aber noch nicht dazu gekommen, das richtig zu verzetteln. Ein guter Einstieg scheint mir zu sein:
ROBILLARD, Martin P. und Kaylee KUTSCHERA, 2019. Lessons Learned in Migrating From Swing to JavaFX. IEEE Software. 2019. DOI 10.1109/MS.2019.2919840 `` https://www.cs.mcgill.ca/~martin/blog/2018-11-12.html
Update July 2019: A new and improved version of this essay is available as this paper, published in IEEE Software. ``
Ergebnis meiner Recherche damals war, dass ich mir bei Gelegenheit Vaadin anschauen wollte, siehe auch diesen Blog-Post:
WILSON, Ben, 2019. Technical Erosion and Java Swing. Vaadin [online]. 9 Mai 2019. [Zugriff am: 29 März 2020]. Verfügbar unter: https://vaadin.com/blog/technical-erosion-and-java-swing
Bin mir unschlüssig, ob ich mir nun die Training videos and certifications @ https://vaadin.com/learn/training/v14 anschauen soll …
Elmari
commented
4 years ago Danke für das Paper, das kannte ich noch nicht. Sollten wir nach FX migrieren, hilft es bestimmt, dass im Hinterkopf zu behalten. Vaadin würde dann eher in Richtung Lösung 4 gehen, damit könnten wir dann den Zettelkasten als Web App umsetzen. Das geht natürlich auch. Dann würde ich aber persönlich eher dazu tendieren, dass gleich richtig in Webtechnologien zu schreiben statt das Vaadin von Java nach html, css und JavaScript übersetzen zu lassen. Was mich bei dem Vaadin-Blogartikel etwas stört ist, dass JavaFX so gut wie gar nicht als Alternative erwähnt wird. Es wird nur erwähnt, dass es obsolet sei, was meines Wissens nicht stimmt, weil es Open Source aktiv weiterentwickelt wird.
RalfBarkow
commented
4 years ago @Elmari Ich hatte mich damals für Option 1) "Bei Swing bleiben" plus "klare Trennung zwischen UI und Controller" entschieden (was m.E. unabhängig von der Frage JavaFX bzw. Option 2) angegangen werden könnte, d.h. +1 begzl. "Code neu strukturieren bzw. auftrennen").
Elmari
commented
4 years ago Ah, dein Repository hatte ich vorhin übersehen, sorry. Ja, seh ich auch so, wie du das sagst, dass man eine Migration neben der Pflege des aktuellen Swing-Stands laufen lassen könnte (wenn ich dich da richtig verstanden habe). Von mir aus könnten wir gerne dein ZettelkastenFX-Projekt weiterführen, wenn du das gemeinschaftlich entwickeln wollen solltest. Mit JavaFX hatte ich bisher eigentlich nur gute Erfahrung gemacht.
RalfBarkow
commented
4 years ago @Elmari ZettelkastenFX ist für mich keine Option, das Repo diente mir für erste Experimente mit JavaFX, JAXB und java.xml.bind. Der develop branch in meinem Zettelkasten fork dient mir zur Pflege des aktuellen Swing-Stands.
RalfBarkow
commented
4 years ago IDE Platform verwenden (wie im Archiv angedacht)
* NetBeans
Um mit dem Design View (Stichwort: .form Dateien / Swing) arbeiten zu können, muss man offenbar Apache NetBeans verwenden.
Den Hinweis
NetBeans support of Swing Application Framework has been discontinued. Please, use NetBeans 7.0 if you want to use this framework.
habe ich wohl lange falsch verstanden. Es geht nicht um die Version der IDE, sondern um das Plugin [1] "Swing Application Framework Support", das auch in Apache NetBeans 11.1 die Form Dateien anzeigt!
[1] „Swing Application Framework Support - NetBeans Plugin detail“. Zugegriffen 11. November 2019. http://plugins.netbeans.org/plugin/43836/swing-application-framework-support.
Elmari
commented
4 years ago @Elmari ZettelkastenFX ist für mich keine Option, das Repo diente mir für erste Experimente mit JavaFX, JAXB und java.xml.bind. Der develop branch in meinem Zettelkasten fork dient mir zur Pflege des aktuellen Swing-Stands.
Okay. Als Alternative zu deinem develop branch könnten wir auch hier im Repo das git flow Modell einführen. Dann hätten wir hier einen develop-Branch auf dem wir weiterarbeiten könnten, der master-Branch wäre dann nur noch für getaggte Releases.
Um mit dem Design View (Stichwort: .form Dateien / Swing) arbeiten zu können, muss man offenbar Apache NetBeans verwenden.
Ja, das ist mir auch aufgefallen. Alternativ könnten wir auch IntelliJ Forms per Snapshot erstellen (ich hab in deinem FX repo gesehen, dass du scheinbar auch IntelliJ verwendest). Dann müssten wir aber zuerst das GroupLayout ersetzen, z.B. durch MigLayout o.ä..
Auf jeden Fall sollten wir das Swing Application Framework, bzw. die jdesktop Implementierung davon, loswerden denke ich.
RalfBarkow
commented
4 years ago hier im Repo das git flow Modell einführen
Ja, gerne (denn damit arbeite ich bereits).
Das Zusammenführen meines develop branches mit dem aktuellen master ist mein momentanes 'Problem' (aber aufgrund der aktuellen Situation nicht meine oberste Priorität).
RalfBarkow
commented
4 years ago Okay. Als Alternative zu deinem develop branch könnten wir auch hier im Repo das git flow Modell einführen. Dann hätten wir hier einen develop-Branch auf dem wir weiterarbeiten könnten, der master-Branch wäre dann nur noch für getaggte Releases.
@Elmari Ich arbeite also nun auch mit den develop/master branches hier und habe meinen alten develop bei mir als branch "3.2.8-SNAPSHOT" "gesichert".
strengejacke
commented
4 years ago Als kurze Notiz, wenn man die Querverweise erweitern möchte: https://forum.zettelkasten.de/discussion/comment/4961/#Comment_4961
Die Möglichkeit dieser semantischen Querverweise ist in dem oben gezeigten Screenshot auch z usehen. Also eine Überarbeitung des aktuellen Formats wäre irgendwann sicherlich ein Ziel, denke ich. Die Frage ist, wie man den Übergang gestaltet.
RalfBarkow
commented
4 years ago hier im Repo das git flow Modell einführen
@Elmari Bevor ich mir im feature/gitflow-maven-plugin das gitflow-maven-plugin anschaue, habe ich damit begonnen, etwas aufzuräumen (Stichwort: Keep the build and local configuration files out of our git repository). Dabei ist mir aufgefallen, das unser local-repository etwas Pflege gebrauchen könnte. Vielleicht möchtes Du Dir den feature branch einmal anschauen?
Elmari
commented
4 years ago Oh ja. Hab mir gerade mal deine Commits angeschaut, sieht gut aus 👍 . Da hab ich wohl ein paar Details nicht so richtig sauber gepflegt.
RalfBarkow
commented
4 years ago @Elmari Übernimmst Du das in den develop branch oder soll ich das mergen? Bin mir unsicher, ob wir "Rebase auf Entwicklungszweig" machen …
Elmari
commented
4 years ago @RalfBarkow ich denke, wir können das einfach mergen. Ich hab mal einen pull request erstellt. Siehe #208. Ansonsten kannst du auch gerne bei dir lokal mit git flow feature finish ... wieder in develop mergen :)
rigow
commented
4 years ago Als kurze Notiz, wenn man die Querverweise erweitern möchte: https://forum.zettelkasten.de/discussion/comment/4961/#Comment_4961
Die Möglichkeit dieser semantischen Querverweise ist in dem oben gezeigten Screenshot auch z usehen. Also eine Überarbeitung des aktuellen Formats wäre irgendwann sicherlich ein Ziel, denke ich. Die Frage ist, wie man den Übergang gestaltet.
Meiner Meinung nach ist der Zettelkasten ist eine Vorform von Wissensgraphen. Hier mit einem sehr benutzbaren Interface. Meine Erfahrung ist, dass man mit Dingen wie biblatex und SQL ziemlich schnell an seine Grenzen stösst, wenn man das Wissen wirklich vernetzen und die Verbindungen semantisch aufladen will. Als Mitarbeiter des W3C empfehle ich natürlich standardisierte Formate zu nehmen, nämlich Linked Data. Damit erschließt man sich auch eine große Reichhaltigkeit, was verfügbare Tools angeht. Nur mein Beitrag, weil das noch nicht erwähnt wurde.
RalfBarkow
commented
4 years ago @rigow: Vielen Dank für diesen Beitrag! Nur kurz: ich denke bezgl. "standardisierte Formate" an Topic Maps und experimentiere mit DMX – The context machine (Stichwort: Plugin, welches die Zettelkasten Funktionalität in DMX integrieren soll).
RalfBarkow
commented
4 years ago Für's erste würde hier wahrscheinlich die Integration von JavaFX in Swing reichen, also einfach das JEditorPane durch WebView austauschen. Anschließend könnte man dann den Zettelkasten vollständig nach JavaFX porten.
Das Extended Markdown ließe sich evtl. mit flexmark umsetzen. Das unterstützt das Parsing einiger Markdown-Familien.
simonsan
commented
3 years ago (Neuaufsetzen als Electron Desktop Web app) Vorteil: am zukunftssichersten? Nachteil: am aufwendigsten
Hoert sich am besten an davon, auch weil es fuer die Zukunft mal auf einem Server laufen kann und mit einer Datenbank im Hintergrund Multiuser faehig werden koennte. Gerade was Informationsaustausch und Transparenz angeht finde ich das ganz interessant in diesen Zeiten.
Am liebsten waere mir persoenlich (was ja nischt zaehlt) eher sowas wie ein Rust Library fuer das Zettelkasten-Schema und die Funktionalitaet was dann nach WebAssembly kompiliert werden kann und damit auch als npm-Module zur Verfuegung stehen koennte bzw. von JavaScript aus gecalled werden koennte und dann auch in Electron und React und sonst was damit angestellt werden koennte. Aber eben mit einer Systemprogrammiersprache fuer die Library im Hintergrund und static typing etc. Und vor allen Dingen: performant. Damit wuerde man richtig langfristig was bauen was auch performant skaliert und einfacher zu maintainen (imho). Ich bin aber auch kein sonderlicher Java-Fan wegen runtimes und so.
https://hal.archives-ouvertes.fr/hal-02558983/document https://crates.io/crates/sophia
EDIT: Weiterfuehrend bzw. als Inspiration vielleicht noch YAGO:
YAGO (Yet Another Great Ontology) is an open source[3] knowledge base developed at the Max Planck Institute for Computer Science in Saarbrücken. It is automatically extracted from Wikipedia and other sources.
https://yago-knowledge.org/downloads/yago-4 https://github.com/yago-naga/yago4 (In Rust implementiert)
https://github.com/yago-naga/yago3 (noch in Java implementiert)
github-actions[bot]
commented
2 months ago This issue is stale because it has been open for 30 days with no activity.
github-actions[bot]
commented
1 month ago This issue was closed because it has been inactive for 14 days since being marked as stale.
Ich habe mir den Code vom Zettelkasten nun nochmal im Detail angeschaut. Dabei ist mir aufgefallen, dass einige Libs mittlerweile stark veraltet sind, insb. jdesktop und JGoodies. Wahrscheinlich wäre es auch gut, die Controller stärker von den Views/von der UI-Erstellung zu trennen. Vielleicht wäre auch eine Dependency Injection hilfreich, das könnte man zum Beispiel mit Spring Boot hinbekommen können.
Basierend darauf folgende Lösungsvorschläge:
Die vierte Lösung kommt aber denke ich eher nicht in Betracht. ggf. noch überall bei den Java-Lösungen Swing Boot integrieren.
Ich hab außerdem noch dieses LaF gefunden, das ist vielleicht interessant: https://www.formdev.com/flatlaf/
Was haltet ihr davon @strengejacke @RalfBarkow ? Seht ihr andere, ähnliche oder vielleicht auch gar keine Probleme bzw. gar nicht die Notwendigkeit? Was haltet ihr von den Lösungsvorschlägen? Freue mich auf euer Feedback.