HolzShots v2.0.0 [2024-03-21]

Hi,

ich habe mich noch einmal dran gesetzt ung HS etwas "entranzt". Das Update gibt es wohl morgen.
Änderungen in der API für die Plugins:

• Es wird nun die neuere HTTPPostLib4 verwendet, nicht mehr die 3er.
  Im Prinzip ist es nur eine Änderung beim Plugin von
  
  

  VB.NET-Quellcode

  1. request.AddVar("input", "file")
  2. request.AddFile("bilddatei", "HolzShots.png", postData, "image/png")
  3. ' Auf
  4. request.Post.Add("input", "file")
  5. request.Files.Add("bilddatei", "HolzShots.png", postData, "image/png")
  
  
  
• Die Referenzen müssen auf die neuen Assemblys aktualisiert werden
  
• Die Standardinstanz des HTTPPostRequests wird in eine Unterklasse ausgelagert
  -> Plugins, die die Standardinstanz des HTTPPostRequests verwenden, müssen von der neuen Unterklasse erben
  
• Das Casing in den Klassennamen verbessert bzw. vereinheitlicht -> Kein Problem für die VB.NETler, allerdings müssen die C#ler Änderungen vornehmen
  
• Typenänderungen an der AuthorInformation-Klasse
  

Ich glaube das war es.

Was sich noch geändert hat:

• Änderungen/Verbesserungen am HolzUIFramework
  
• Internet Änderungen am Pluginsystem. Die Plugin-Schittstelle wurde nur weiter abstrahiert, sodass eventuell Werkzeuge später auch als Plugins geladen werden könnten
  
• Verbesserte Performance und interne Architektur
  
• Wenn die PostLib mal wieder mit einem Strong Name kommt: (Wieder) Strong Names. (;))
  
• Weitere, interne verschönerungen
  
• Kompakterer About-Dialog mit aktualisierten Webseiten
  
• Kein Aero mehr im ShotEditor:
  
  
• Neue Icons, überall; Konsistenteres Aussehen
  

Mal schauen.

@BjöNi: Hab's mir notiert.

Edit:

Eine Frage habe ich noch an Euch:
Wenn ich es einrichten würde, Screenshots direkt nach dem Erstellen in einen Ordner zu Dumpen: Wie soll ich die Bilder benennbar machen? Ich habe über ein Pattern nachgedacht, aber konnte mir noch nichts brauchbares überlegen.
Das habe ich hier im Thread schon mal gefragt (bezüglich HS2). Ich glaube wir kamen damals zu keiner Lösung.
Deshalb bitte ich wieder um Vorschläge: Wie sollten die Screenshots in dem Ordner benennbar gemacht werden?

Es stehen Parameter wie Datum (Tag, Monat (ausgeschrieben/als Zahl), Stunde (24/12h-Format), Minute, Sekunde), Auflösung (Width/Height), HS-Version, Computername und was Euch sonst noch so einfällt dafür zur Verfügung.
Wahrscheinlich würde ich für den Datumskram die MSDN/.NET-Notation (vom String.Format) verwenden. Beim Rest bin ich mir nicht ganz sicher.

Wenn Ihr Bock hat, könnt Ihr Euch ja auch mal Gedanken über eine mögliche GUI dafür machen. Die Power-User werden wohl ein Pattern in Textform haben wollen, aber für die Normalos wäre eine GUI dafür sicher nicht falsch. Auch diesbezüglich nehme ich gerne Vorschläge entgegen.

Aber wer weiß, vielleicht gibt es ja schon einen Standard für sowas (hat bestimmt schon irgendein Linux-Typ standardisiert ;))

Ich halte es für selbstverständlich, dass man selbst entscheiden darf, wie die Dateien benannt werden - deshalb meine Frage.
Eine Option für Unterordner pro Tag wäre auch noch drinne (natürlich ebenfalls personalisierbar).

@Gather: Der Vorschlag ist nicht schlecht. Wobei die <> schöner aussehen als z. B. %. "DayOfWeek" ist mir allerdings zu viel Text für ein Wort. Vielleicht könnte man bei der ersten von dir vorgeschlagenen Variante etwas weiter denken. DayOfWeek könnte man ja auch als Zahl (0-6) oder Wochentagname wollen. Von daher ist das noch nicht ganz so flexibel.
Ich weiß auch nicht, wie ich das mit den führenden Nullen machen werde. Ich glaube das einfachste für mich wären wirklich .NET-Stringformats, was die DateTime-Formatierung angeht.

Ich habe heute den ganzen Tag geschlafen. Von daher gibt es die neuere Light-Version erst morgen oder übermorgen.

Übrigens:
[Beta] HolzShots v0.9.7.9001 - Light Version [26.12.2012]
Das Angebot gilt immer noch. Allerdings brauche ich keine Earbuds mehr. Stattdessen würde ich mich hierüber freuen. Ist zwar etwas teurer, aber falls einer von Euch zu viel Geld hat, kann er es ja sinnvoll in ein Geschenk für mich investieren, anstatt es durch den Club zu schmeissen.

Ich nehme immer noch Vorschläge entgegen, was die Naming-Patterns betrifft.

Edit:

Ich habe mal ein bisschen rumgespielt. Ein Parser/Tokenizer für die Pattern-Sprache steht nun. Das Ganze ist so gemacht, dass es sich in WinForms und WPF benutzen lässt. Wobei es in WPF einfacher auf den Bildschrim zaubern lässt. Wie ich das in WinForms umsetzen werde, weiß ich noch nicht. Ein einfacher TextParser wäre aber auf jeden Fall leicht möglich. Ich kann problemlos zwischen Syntaxbaum und Textform "konvertieren", von daher soltle eine Drag'n'Drop-GUI auch möglich sein, wird aber schwerer.
Im Anhang sind Bilder meines Testprogramms. Der Text kann geändert werden und die Tokens ändern sich dann entsprechen (und die Vorschau auch).

Ich habe mich dazu entschlossen, an der Plugin-Schnittstelle doch noch größeren Änderungen vorzunehmen (und auch am internen Upload-System).
Was habt Ihr für Vorschläge?

Meine Bitte nach Vorschlägen zielte primär auf die Imagehoster-Plugins ab. Da werde ich etwas machen. Bei den anderen weiß ich noch nicht so ganz.
Das, was @Gather: geschrieben hat, ist eigentlich für HS2 geplant, weil es recht anspruchsvoll unter WinForms ist.

Kleines Update:
So sieht die architektonisch verbesserte API aus:


Führt dann erstmal dazu:


Im Moment sehen die Klassen noch so aus: s1.directupload.net/images/130220/2kei3mnc.png
Das ist aber nur ein Grobentwurf. Die werden sich noch etwas ändern.

Vorschläge?

Edit:
Nun kompiliert es wieder. Funktionieren tut alles noch wunderbar, ich habe jedoch sehr viele mehrfach vorhandenden Daten generalisiert. Das werde ich jetzt noch etwas weiter treiben.

Meine nächsten Schritte:
- Das IFilterPlugin-Interface durch eine abstrakte Klasse ersetzen.
- Im IPlugin-Interface ermöglichen, dass jedes Plugin (egal ob Imagehoster oder Filter) einen Einstellungsdialog haben kann. So wird z. B. auch Droplr-Support möglich. (@Samus Aran:)
- Eventuell eine extra ImageHoster-Ableitung für Imagehoster, die Logindaten benötigen (nur so eine Idee).

Edit2:

Bin nun etwas weiter.

Die aktuelle API sieht nun so aus:

Der implizite Casting-Operator beim UploadProgressChangedEventArgs dient dazu, dass man auch den Framework-UploadProgressChangedEventArgs einfach so verwenden kann. Der aus dem Framework hat leider keinen öffentlichen Konstruktor.

Ich werde wohl die Environment-Klasse noch mit Sachen aus dem HolzUIFramework füllen, da da bestimmt auch etwas bei ist, was Pluginentwickler gebrauchen könnten.

Ich bin aber erstmal pennen.

Bisher war es so, dass wenn das Bild zu groß war oder ein sonstiger Fehler beim Uploaden auftrat, kein Link angezeigt wurde (weil es keinen gibt). Das werde ich ändern.

Die Bildgröße ist egal, was das Uploaden angeht. Ich werde auch noch einbauen, dass man für einen Hoster die maximale Größe festlegen kann, damit man nicht unnötig warten muss und dann am Ende nur einen Fehler bekommt.