(Update 3.07.2024): UniGetUI (ehem. WinGetUI) ist jetzt in der finalen Version 3.1.0 erschienen. Das Rebranding ist jetzt abgeschlossen und die Änderungen werden jetzt von WinGetUI in UniGetUI gespeichert.
(Original 2.07.2024): Marti hat heute die dritte Beta von UniGetUI 3.1.0 (vormals WinGetUI) bereitgestellt. Gestern kam schon eine Beta, aber da wurden noch einige Korrekturen an den integrierten Installationsprogrammen für Abhängigkeiten notwendig. Mit der Beta 1 kam ein integrierter Abhängigkeits-Manager hinzu.
Sollten also keine gravierenden Probleme mehr auftauchen, könnte die nächste Version dann den finalen Status erhalten. Wer noch mit WinGetUI unterwegs sein sollte, wird mit UniGetUI eine Änderung erhalten. Denn alle Daten werden in neue Ordner migriert (WingetUI -> UniGetUI). Ein Rollback kann dazu führen, dass die Einstellungen zurückgesetzt werden.
Hier aber mal die Änderungen der beiden Betas:
Info aufklappen
– Beta 2
– Korrekturen an den Installationsprogrammen für Abhängigkeiten
– Verbesserungen an der Art und Weise, wie Microsoft.WinGet.Client durch das Installationsprogramm installiert wird
– Verbesserungen an den Einstellungen und Log-Seiten.
-Andere Fehlerbehebungen
– Beta 1
– Diese Version fügt einen eingebauten Abhängigkeits-Manager hinzu, der fehlende Abhängigkeiten für UniGetUI (z.B. Microsoft.WinGet.Client oder Scoop-Search) überprüft und den Benutzer auffordert, diese zu installieren.
– Andere kleinere Probleme wurden in dieser Version korrigiert.
Die wichtigsten Änderungen in WinGetUI Final (Stable)
- Die Package Engine wurde komplett neu gestaltet
- Paketmanager, die dies unterstützen, rufen Pakete über APIs ab (WinGet verwendet COM, NuGet-basierte verwenden REST-Nuget-APIs, usw.). Dies führt zu wichtigen Geschwindigkeitsverbesserungen
- Die Art und Weise, in der Icons geladen werden, wurde erneuert. Paketmanager, die dies unterstützen, stellen die Icons direkt den Paketen zur Verfügung.
- Microsoft Store (winget: msstore) Pakete zeigen ihre Bildschirmfotos auf der Detailseite an.
- System WinGet wird nun standardmäßig verwendet. Gebündeltes WinGet wird nicht mehr verwendet, um Pakete zu holen oder zu installieren.
- Der Lebenszyklus von Packages, PackageDetails und InstallationOptions wurde so geändert, dass keine doppelten Instanzen derselben Daten im Ram vorhanden sind. Paketdaten, die bereits geladen wurden, werden nicht erneut geladen, sondern von einem älteren Ladevorgang wiederverwendet.
- Wenn ein Paketmanager eine Abhängigkeit vermisst, wird der Benutzer aufgefordert, diese zu installieren.
- Die Softwareseiten wurden mit ItemsView zugunsten von ListView neu aufgebaut. Dadurch wird weniger Arbeitsspeicher benötigt (ca. 70~100mb weniger).
- Das Installationsprogramm stellt sicher, dass WinGet und Microsoft.WinGet.Client auf dem System vorhanden sind.
- Das Installationsprogramm erlaubt es dem Benutzer, Chocolatey nicht zu installieren.
- Viele, viele Korrekturen, auch durch die Mithilfe der Beteiligten.
ich setze hier mal den direkt link
https://github.com/marticliment/WingetUI/releases/tag/3.1.0-beta2
Wozu? Ist doch oben drin.
nur so für mich
Achtung holt den PC aus dem Benutzer Sperren Modus.
Die Explorer.exe ist dann beendet.
Müllt einem dieses Programm immer noch das System zu in dem es selbst kein Rücksicht darauf nimmt das erst mal jeder von Haus aus schon Winget installiert hat und dann wohlmöglich sogar einen neuere Beta installiert hat.
Bisher hat man ja seine eigene Version mitgebracht, schön brav in seinem Verzeichnis. Danach die Auswahl ob man die Systemversion oder die meist veraltetete eigene Nutzen will. So weit so gut.
Scoop, Chokolade und Co waren nicht dabei, die konnte man nachinstallieren. die Wurden dann aber ungefragt ins Systemverzeichnis installiert. das ganze dann noch global Systemweit hinterlegt. Null Rücksicht auf bestehende Installationen in anderen Ordnern, man hat danch also alles doppelt aktiv, dazu wurde auch keines der extra Programme nach der deinstallation von WingetUI wieder deinstalliert. Unter „Programme“ zum manuellen deinstallieren von Scoop und Co tauchen die WingetUI Versionen natürlich auch nicht auf. Vom Systemverzeichnis bis zur Registrierungsdatei muss man den Müll komplett selbst löschen! Gehe ich davon aus das es immer noch so ist?
Würde mich ja wundern wenn man mit einer Umbenennung seine schlampige Arbeit plötzlich über Board geworfen hätte.
Ach Ja, wer die Final 3.1.0 installiert hat, es wird beim Autoupdate eine Downgrade auf die vorherige Beta gemacht laut Github, also schnell Auto-Update aus
Tut das eigentlich sehr weh? Und gibt es wirklich keine Heilung?
Versuch es doch einfach mal mit frischer Luft.
Besser wäre es allerdings, wenn Du Deine Tastatur in den Müll entsorgst (und besser keine neue kaufen …).
Die neue Version 3.1 nat keinen Eintrag der Quellen. In der vorherigen Version waren die Einträge „Winget“ und „Local“ vorhanden. Daher findet das Tool keine installierte Programme. Gibt es hierzu eine Lösung ?
Versuch mal Einstellungen –> Allgemeine Einstellungen –> UnigetUI zurücksetzen und danach neu starten.
Alles schon versucht, leider ohne Erfolg. Die Vorversionen hatten hervorragend funktioniert.
Trägt sich UniGetUI auch (immer) noch ungefragt in den Autostart ein?
Tja, die finale Version UniGetUI 3.1.0 arbeitet doch schon mal „perfekt“. 😒
Installiert sich im vorhandenen Verzeichnis
C:\Proramm Files\WingetUI\
und möchte dann, nachdem es nach Updates gesucht hat, „WingetUI 3.1.0“ mit „WingetUI 3.1.0-beta1“ von der Quelle „Winget: winget“ ersetzen.Das nennt man eine echte Glanzleistung.
Erstens packt man das Ding in ein neues Verzeichnis
C:\Proramm Files\UniGetUI\
Zweitens verschiebt man alle vorhandenen Einstellungen dort hin und löscht, gegebenenfalls mit Nachfrage, das alte Verzeichnis und ALLE Einträge von WingetUI aus der Registry, etc.
Drittens, kümmert man sich vorher um seine Repositories und sorgt dafür, dass dort keine Altlasten mehr gefunden werden können.
Nur dann ist das eine saubere Lösung.
Ja genau!
Und mMn noch dämlicher:
Wird UniGetUI neu (portable) in ein neues Verzeichnis UniGetUI installiert, so wird die EXE WingetUI.exe im neuen Verzeichnis UniGetUI installiert und nicht wie erwartet eine UniGetUI.exe. Gibt sich allerdings im gestarteten Programm dann wieder als UniGetUI aus.
Scheint mir eine richtige Bastelei ohne Konzept zu sein, obwohl es nun eine Final und keine Beta mehr ist
Update-Zwang!
Beim Starten von WingetUI Version 3.0.2 kommt:
WingetUI 3.1 is ready to be installed.
The update will be installed upon closing WingetUI
(Zwingt einem zum Update – auch wenn ich das NICHT will)
Obwohl in den Einstellungen Programm-Update deaktiviert ist, also
– WingetUI automatisch aktualisieren
– Regelmäßig auf Updates prüfen
beide ohne Haken
Trotzdem wird jedes Mal beim Start das Update angezeigt, der Updater ungefragt herunter geladen und beim Schliessen wird versucht, das Update zu installieren.
Da die neue Version 3.1 nicht alle Updates der Vorgänger-Version 3.0.2 anzeigt, will ich (noch) nicht Upgraden!
Haben andere Benutzer auch das Gleiche festgestellt?
Vielleicht liest Marti hier ja mit? Wer weiß ………..
**UPDATE**
UniGetUI 3.1.1 Beta 0