Gegen Ende des letzten Jahres habe ich mir endlich einen 3D-Drucker gekauft. Mit den BambuLab-Produkten hatte ich endlich das Gefühl, dass die 3D-Drucktechnologie für den Privatgebrauch so weit war, dass ich mich nicht mehr mit Einstellungen oder Ähnlichem herumärgern müsste, mich nicht mehr mit dem Prozess des 3D-Druckens selber beschäftigen müsste, sondern mich ganz auf die Erstellung der Objekte konzentrieren konnte, die ich drucken wollte.

Und hier sind wir nur. Hier sind die ersten beiden 3D-Objekte, die ich designed und der 3D-Druck-Community zur Verfügung gestellt habe: kleine, aufklappbare Schachteln.

Dies ist nur der Anfang meiner Reise in yet-another Hobby. Ich habe Ideen für viele weitere Dinge, die nun physische Realität werden können.

WordpressIch schreibe meinen Blog hier schon immer zweisprachig, auf Deutsch und auf Englisch. Ganz früher war das noch mein eigener Webcode. Dann bin ich irgendwann auf WordPress umgestiegen. Und die Plugins für die mehrsprachigen Posts, etc., waren schon immer irgendwie … anstrengend.

Und jetzt hat mein bisheriges Plugin für den mehrsprachigen Blog vollends den Geist aufgegeben; vermutlich durch ein WP-Update oder PHP-Update. Wie auch immer. Hilft ja nix. Also, gibt’s jetzt mal wieder ein neues Plugin. Das verwaltet jetzt unterschiedliche Sprachen indem jeder Post genau eine Sprache hat, und dieselben Posts in unterschiedlichen Sprachen „nur“ verlinkt sind. Eigentlich ein ganz nettes Konzept.

Heißt aber auch das meine bisherigen Posts alle, wirklich alle, überarbeitet werden müssen, genau wie die Webseitenstruktur selbst und alle Extraseiten auch. Und das wird dauern.

Also, wird der Inhalt auf meiner Webseite bis auf weiteres immer so ein bisschen Kaputt aussehen. Tschuldigung.


Update 2024-09-15: während ich so dabei bin meine Blog-Artikel zu fixen, d.h. sie nach ihrer Sprache in zwei getrennte Artikel zu splitten, da merke ich dass Links zwischen den Artikeln dabei falsch sein können, im Besonderen bei den englischsprachigen Versionen. Sorry, aber mir ist dieses alte Zeug nicht wichtig genug, dass ich das durchgehend fixe…

Ich bin auf dieses Nuget gestoßen, weil ich WPF-UI-Anwendungen geschrieben habe und einen Folder-Picker brauchte. Irgendwer im Internet schlug vor, die WinForms-Dialoge zu verwenden. Ich hasse es irgendwie, zwei Frameworks zu verwenden. Und dann brachte jemand anderes das Nuget WindowsAPICodePack.Shell ins Spiel, mit seinen Klassen der Windows Common Dialogs, einschließlich der Möglichkeit zur Auswahl von Ordnern im File-Öffnen-Dialogfenster.

Also fing ich an, das Nuget zu benutzen. Irgendwann wies mich ein Freund darauf hin, dass das Nuget-Paket gar nicht wie ein offizielles Microsoft-Paket aussah, sondern wie ein Repackage, das irgendjemand gemacht hatte. Das brachte mich zum Nachdenken. Ich unterstelle niemandem böse Absichten, aber ich fand es sehr, sehr seltsam. Das offizielle Paket war . Und es gibt eine ganze Reihe von Paketen mit seltsamen Namen:

Ich mag das nicht. Selbst wenn keiner der Autoren böse Absichten hegt, gefällt mir das nicht, denn es riecht nach Betrug, Phishing und Schwachstellen. Tut mir leid, aber nein.

Also, wo ist das offizielle Paket? Es scheint verschwunden zu sein, deshalb gibt es die Repackages von Community-Mitgliedern. Warum ist es verschwunden? Keine Ahnung. Vielleicht wurde es bei einer halbautomatischen Bereinigung erwischt, da es verwaist war. Jemand behauptet es wäre Microsoft.Windows.SDK.Contracts ersetzt worden.

Letztendlich habe ich den Code in meinen Projekten ersetzt, indem ich entweder doch den WinForms-Dialog verwendet oder eine sehr kleine P/Invoke-Wrapper-Klasse geschrieben habe, die die Win32-API-Funktion direkt aufruft. Wen es interessiert, der kann sie sich gerne anschauen:

https://github.com/sgrottel/open-here/commit/9de68198e35f0f6dec9386372cc71bada54c2f5b

Die Moral von der Geschichte ist, dass ein Nuget-Paket nur so gut ist wie die Menschen, die es pflegen. Und ich meine Menschen, nicht Organisationen. Denn am Ende kommt es darauf an, ob eine einzelne Person dahinter steht und ihr Bestes geben will oder nicht.

GLM wurde in Version 1.0.0 veröffentlicht, und ich habe das Nuget-Paket entsprechend aktualisiert.

Dabei habe ich auch den Quellcode des Nuget-Pakets von Bitbucket nach Github umgezogen.

Ich bin mir nicht sicher, ob es sich lohnt, über die Aktualisierung von Nuget-Paketen zu schreiben. Ich würde eher sagen, das ist Business as usual. Aber dieser Fall hier ist etwas Besonderes, denn der GLM-Entwickler entschied sich für 1.0.0. Ich möchte zu diesem Anlass besonders gratulieren! Ich finde es peinlich, wie viele Projekte die „Schallmauer“ dieses Schrittes zu fürchten scheinen, um endlich von „Ich weiß nicht“ zu „Das ist irgendwie das, was ich machen wollte und es ist irgendwie in der ersten Version fertig.“ Zu gehen. Ich glaube, viele weitere Projekte sind reif und stabil genug, um diesen Schritt zu gehen. Aber sie tun es nicht. Ich weiß es nicht.

Dies ist mein erster Post im Jahr 2024, und erstaunlicherweise habe ich es geschafft, siebeneinhalb Monate lang nichts zu schreiben. Das sieht aus wie ein trauriger Rekord. Nun, es ist nicht so, dass ich in dieser Zeit nichts für die Community getan hätte. Es zeigt aber, dass meine Prioritäten woanders lagen als in diesem Blog. Aufgeben werde ich den hier aber nicht.

Jedenfalls möchte ich nicht einfach aufgebläht auflisten was ich gemacht habe, indem ich, z.B., mein Github-Journal abschreibe, denn das wäre einfach nur traurig. Wenn Ihr euch dafür interessieren, was in meinen Tiny Tools, Everything Search Client, Checkouts Overview, OpenHere, LittleStarter, MyToDoBoard, aktualisierten Nuget-Paketen, SimpleLog, etc. passiert ist, dann empfehle ich direkt einen Blick in mein Github-Profil zu werfen. Das ist dann wohl die unaufgeblähte Auflistung.

Also, für heute belasse ich es bei dieser kleinen, traurigen „I am still alive“-Nachricht.

Der EverythingSearchClient kann nun seine Suchergebnisse sortiert zurückgeben. Der entsprechende neue Release v0.4 ist auf Github und als NuGet-Packet verfügbar.

Die Funktion die Suchergebnisse sortiert zu liefern zu können war einfach einzubauen, da sie hauptsächlich im Everything-Service selbst implementiert ist. I musste nur die entsprechenden Flags für die Query-v2 Interprozess-Communications-Anfrage in meine CSharp-Client-Bibliothek übernehmen.

Damit habe ich nun keine aktuellen Pläne für weitere Funktionen in meinem EverythingSearchClient. Ich benutze die Library bereits in ein paar meiner eigenen Projekte. Wenn Ihr sie auch benutzt, dann würde ich mich freuen das zu hören. :-)