Tipp: SeaMonkey für Nutzer mit HiDPI-Bildschirm brauchbar machen
SeaMonkey ist der Name einer Anwendung, welche unter anderem Browser und E-Mail-Client vereint und aus der Mozilla Application Suite hervorgegangen war. Für Nutzer eines hochauflösenden Bildschirms ist SeaMonkey nur bedingt brauchbar. Eine kleine Anwendung ändert dies für Nutzer von Apple macOS.
Viele Jahre ist es her, da gab es mit der Mozilla Application Suite eine Anwendung, welche Browser, E-Mail-Client und noch ein paar Werkzeuge mehr vereinte. Zugunsten von Firefox und Thunderbird hatte Mozilla die Entwicklung daran im April 2006 eingestellt. Seit dem wird die Mozilla Application Suite als Community-Projekt unter dem Namen SeaMonkey fortgeführt.
SeaMonkey gibt es auch heute noch und findet vor allem bei Nostalgikern Zuspruch, weil sich das Design seit damals so gut wie überhaupt nicht geändert hat. Allerdings leidet die Suite unter vielen Defiziten, allen voran die viel zu lange Auslieferungsdauer für Sicherheits-Updates. So basiert die aktuelle Version SeaMonkey 2.46 noch immer auf Gecko 49. Sicherheitslücken, die seit dem in Firefox und Thunderbird behoben worden sind und von denen SeaMonkey ebenfalls betroffen ist, sind in SeaMonkey noch immer vorhanden. Nicht zum ersten Mal. Eine Synchronisation von Browser-Daten, für Millionen von Firefox-Nutzern unverzichtbar, suchen SeaMonkey-Nutzer vergebens. Und wer einen modernen HiDPI-Bildschirm nutzt, wie sie immer verbreiteter werden, findet in SeaMonkey ein kaum benutzbares Produkt, da SeaMonkey selbst und sogar der Inhalt von Webseiten vollkommen verpixelt sind. Die Unterstützung für sogenannte HiDPI-Bildschirme existiert in Firefox und Thunderbird bereits seit vielen Jahren.
Zumindest letztgenanntes Defizit lässt sich für Nutzer von Apple macOS dank einer kleinen Anwendung (1,7 MiB) namens Retinizer beheben. Nach Start des Retinizers muss hierfür die SeaMonkey-Anwendungsdatei ganz einfach in die Oberfläche des Retinizers geschoben und SeaMonkey anschließend normal gestartet werden.
Natürlich macht dieser Tipp die nicht für HiDPI-Bildschirme optimierten Grafiken nicht schöner, aber zumindest wird SeaMonkey damit wesentlich benutzbarer. Ein Unterschied wie Tag und Nacht, der in der realen Benutzung noch viel deutlicher hervorsticht als durch den Screenshot deutlich wird.
Weitere aktuelle Artikel aus der Kategorie „Mozilla“
- 15.11.2024Quellcode von Pocket für Android als Open Source veröffentlicht
- 14.11.2024Quellcode von Mozilla Didthis als Open Source veröffentlicht
- 06.11.2024Mozilla Foundation entlässt 30 Prozent der Mitarbeiter
- 16.10.2024Didthis: Einstellung des Projekts, Code wird Open Source
- 21.09.2024Mozilla veröffentlicht Common Voice Corpus 19.0
Erstmal vielen Dank für eine SeaMonkey News 🙂
Die zuletzt leider lange Dauer von Releases hat zum einen mit Personalmangel zu tun, zum anderen ist Mozilla auch nicht gerade hilfreich was das Projekt betrifft…
Afair gibt es die HiDPI Problem bei Windows mit Seamonkey nicht, von den leider nur unschön hochskalierten UI Bitmaps abgesehen :/.
Stimmt nicht so ganz. SM kann nur das alte Sync-Protokoll, dessen Server Mozilla abgeschaltet hat. Man muß sich seinen eigenen Server aufsetzen.
Das neue Sync ist durchaus gewünscht, nur auch hier fehlt es leider an Entwicklern :(.
Insgesamt steht dem Projekt leider eine sehr schwere Zukunt bevor nachdem Mozille auf dem Weg ist XUL… wegzuwerfen :(.
Das Problem mit dem Personalmangel ist: es ist zwar ein Grund, aber keine Entschuldigung. Meine Kritik richtet sich ja nicht gegen die Dauer, bis neue Feature-Releases erscheinen, sondern dem Schließen von Sicherheitslücken. SeaMonkey steckt voller Sicherheitslücken, die längst durch Firefox und Thunderbird bekannt und dort geschlossen sind. Für jemanden, der Böses im Sinn hat, ist es damit unnötig einfach, SeaMonkey-Nutzer anzugreifen.
Was Mozilla betrifft, Mozilla ist sehr viel hilfreicher als es selbstverständlich ist. Man darf bitte nicht vergessen, dass Mozilla mit der SeaMonkey-Entwicklung rein gar nichts zu tun hat. Es ist ein Community-Projekt. Trotzdem stellt Mozilla Infrastruktur, Add-on-Verzeichnis usw. zur Verfügung. Das trifft auf die wenigsten Community-Projekte zu.
Wenn eine Community einen Browser entwickelt, hat diese auch eine Verantwortung, Sicherheitslücken zeitnah zu schließen. Ansonsten sollte man es – meiner Meinung nach – ganz lassen. Sicherheit ist einfach nicht optional. Thunderbird – ebenfalls ein reines Community-Projekt mit sehr stark begrenzten Ressourcen, bekommt das auch hin. Sogar Features werden implementiert. Keine Unmengen, aber immerhin.
Da hast du natürlich Recht. Allerdings ist ein eigener Sync-Server nicht das, was realistisch gesehen die meisten Nutzer machen, also hängt es dann doch wieder an einer fertigen In-Produkt-Lösung. Und wie du richtig schreibst, hat Mozilla die Server für Sync 1.1 bereits abgeschaltet. Das heißt, die Entfernung aus den Mozilla-Repositories kann jederzeit erfolgen. Und spätestens dann müssen wieder Ressourcen seitens SeaMonkey investiert werden, denn dann muss man den Code selbst wieder integrieren und pflegen. Dazu kommt ja, dass Sync 1.1, egal wie viele Ressourcen reingesteckt werden, das alte Sync bleiben wird. All die Verbesserungen, die Mozilla implementiert, wie eine verbesserte Lesezeichen-Synchronisation in Firefox 53, bleiben SeaMonkey selbst mit einer funktionierenden Sync-Lösung vorenthalten, wenn nicht Sync 1.5 implementiert wird.
Definitiv richtig, dass SeaMonkey eine schwere Zukunft bevorsteht. Ich sehe die Abkehr von XUL aber nicht als Grund dafür. Das ist viel mehr als Notwendigkeit, die aus viel größeren Änderungen hervorgeht, auf die sich Firefox-Nutzer freuen können. Ein Stichwort hier wäre die Rendering-Engine Servo. Ich bin ehrlich froh, wenn XUL und XBL endlich aus Firefox verschwunden sind. Das hatte alles seine Berechtigung. Zu einer Zeit, als Webstandards noch nicht weit entwickelt waren. Langsam ist aber die Zeit gekommen, wo man als Mozilla, der eigenen Mission entsprechend, Webtechnologie vertrauen und nutzen sollte statt eine Eigenerfindung. Das ist ja auch eine Riesen-Hürde für Entwickler, beispielsweise verhält sich das Boxmodell anders im Vergleich zu HTML. Sowas führt immer wieder zu Problemen.
Und das ist längst nicht das einzige Architektur-Problem von SeaMonkey. Es wird auch keine Multiprozess-Architektur geben. Das ist für sich alleine genommen schon sehr blöd. Aber noch schlimmer: darauf basiert das gesamte Sandboxing, also entsteht hier auch wieder ein Riesen-Sicherheits-Nachteil für SeaMonkey-Nutzer.
Kaum schreib ich es: der Code für Sync 1.1 wurde nun von Mozilla aus dem Produkt entfernt.