Quo Vadis netrik? (was: [linux-l] Bester Textbrowser?)

[Volker Grabsch]

On Tue, Apr 17, 2007 at 01:53:29AM +0200, olafBuddenhagen at gmx.net wrote:
> - Ausgiebige Nutzung von Farben zur Verdeutlichung von diversen
>   HTML-Konstrukten. (Links, Formulare, Bilder, Tabellen, Listen etc.)
>   w3m macht es vom Prinzip ähnlich, geht aber nicht so weit. Bei Lynx
>   ist es nur in extrem kleinen Ansätzen vorhanden. Soviel ich weiß hat
>   es keiner der links-Abkömmlinge auch nur Ansatzweise.

Ja, das ist mir aufgefallen. Das, was gerendert wurde, sieht cooler
aus als bei w3m.

> - Aktiver Link wird gut sichtbar, gleichzeitig aber wenig aufdringlich,
>   und optisch ansprechend markiert. (Andere Textattribute werden nicht
>   überdeckt.)

Auch das ist mir sehr positiv aufgefallen.

> - Informationen beim Laden von Seiten, einschließlich Warnungen und
>   Fehlermeldungen, werden im Terminal-Modus (scrollender Text)
>   dargestellt -- wesentlich besser zu überblicken und verfolgen als eine
>   Statusleiste

Das empfand ich als Nachteil. Die Grundidee ist gut, und besser als
ne reine Statusleiste. Allerdings verschwindet währenddessen die
angezeigte Seite, wodurch man schnell den Überblick verliert. Vorallem,
bei Seiten, die oben ihr Menü haben, und darunter den Text. Da wäre
es benutzerfreundlicher, wenn die Seite weitestgehens stehen bliebe,
während die nächste geladen wird.

Auf meinem schnellen Laptop flotter Netzanbindung ist das ein nerviges
Flackern immer wenn ne neue Seite aufgerufen wurde. Und der Text im
"Terminalmodus" rast so schnell durch, dass ich ihn nichtmal ansatzweise
lesen kann.

IMHO wurde das schlechteste beider Welten vereint.

> - Wenn man sich in der Page-History vorwärts oder rückwärts bewegt, und
>   die dadurch aufgerufene Seite sich in der Zwischenzeit geändert hat,
>   wird mit einer Heuristik versucht, trotzdem die "richtige"
>   Cursorposition zu erhalten. Sehr praktisch zum Beispiel beim
>   Heise-Newsticker.

Das sollte man auch beim Laden neuer Seiten probieren. Wäre IMHO bei
jeder Webseite mit Menüführung sinnvoll.

> Natürlich könnte man eine ebenso lange Liste von Nachteilen erstellen...
> Das überlasse ich aber dem geneigten Leser ;-)

Ich möchte nur anmerken, dass etliche dieser Features auch bei w3m
vorhanden sind. (z.B. vorwärts-rückwärts-Navigation)

> > Stattdessen ziehen sie einfach nur unspezifisch über andere Projekte
> > her, ohne konkrete Probleme zu nennen. Hier ist, was ich meine:
> > 
> >     http://netrik.sourceforge.net/?intro.html
> 
> Ich habe bewusst etwas dick aufgetragen, um mir selbst Mut zu machen.

Das ist ja okay.

> Als "über andere Projekte herziehen" hätte ich es allerdings nicht
> wirklich gesehen...

Du hättest einfach konkreter werden sollen.

> > | [...] | There is a handful of different text mode browsers (lynx,
> > w3m, and links | being the most popular ones), but each of them is
> > limited in some | regard. Some of them lack the ambition to add
> > advanced features; others | lack the ambition to create real
> > innovations.
> 
> Als ich das geschrieben habe (vor bald sechs Jahren), hatte ich mich auf
> eine Aussage auf der w3m-Seite gestützt,
[...]
> Dass Lynx seit Ewigkeiten nicht mehr weiterentwickelt wird, was
> wesentliche Neuerungen anbelangt, sollte keiner Diskussion bedürfen.
[...]
> Das mit den Innovationen bezog sich übrigens auf links.
[...]

Na bitte! Konkrete Namen und (Mis-)Features. Das hätte IMHO schon in
den ursprünglichen Artikel hinein gehört.

> > | [...] | Ok, it still lacks some important features to make it really
> > nice, and | none of the advanced features are implemented yet... But
> > that is more | than many of the other projects can claim :-)
> 
> Ich hatte seinerzeit bei SourceForge die Liste aller Browser-Projekte
> durchgesehen. Mehr als die Hälfte davon waren Totgeburten.

Konkrete Namen von Totgeburten, und ihnen Positiv-Beispiele (lynx, etc.)
gegenüberstellen, das hätte ich mir an dieser Stelle gewünscht.

> > | [...] | There are also some projects at Sourceforge that are alive
> > and lively, | and may seem promising. The problem is that all of them
> > intend to create | a simple browser. | [...]
> 
> Das bezog sich vor allem auf Dillo.

Dann schreib das doch dahin.

> (Ich glaube es waren noch einige
> Andere dabei, kann mich aber nicht mehr so genau entsinnen.)

Siehste, hättest du sie mal aufgeschrieben!  ;-)

> aber damals war
> erklärtes Ziel des Projekts, einen "simplen" Browser zu schaffen. Das
> ist sicherlich kein falsches Ziel -- aber eben ein anderes als bei
> netrik.

Diese Klarstellung der unterschiedlichen Ziele fand ich auch sinnvoll
und völlig okay.

> > so wäre das ein gutes Beispiel für einen Browser, der alles kann und
> > trotzdem flink ist, quasi die Verbindung von Dillo und Firefox.
> 
> Den Vergleich würde ich nicht wirklich ziehen, nichtmal in Bezug auf die
> erklärten Ziele. Auch wenn ich die Absicht hatte, falls das Projekt gut
> läuft, irgendwann auch einen grafischen Modus zu implementieren, war der
> Schwerpunkt von netrik immer auf Textmodus.

Ja, natürlich. Ich dachte, das wäre klar, dass ich eine Analogie
von der Dillo-Firefox-Diskussionen (früherer Thread) zu den Textbrowsern
ziehen wollte. Nach dem Motto: Was graphischen Browsern nicht gelinkt,
schaffen vielleicht die Textbrowser.

> Die Idee mit dem grafischen
> Modus kam nur daher, weil -- auch wenn ich im Allgemeinen Texmodus
> vorziehe -- es bei manchen Seiten dann doch nützlich ist, mal eben
> einfach zum grafischen Modus wechseln zu können.

Auf die Idee des graphischen Modus von Netrik wollte ich gar nicht
anspielen.

> Das traurige daran ist, dass ich gerade dann die Motivation für netrik
> verloren habe, als die ganze grundlegende Funktionalität weitgehend
> implementiert war, und ich hätte zum Implementieren der genannten
> Zusatzfunktionen übergehen können. Die meisten davon sollten nicht allzu
> schwer sein -- wahrscheinlich hätte es nicht mehr als ein paar Monate
> gebraucht, netrik bei der allgemeinen Benutzbarkeit in eine ähnliche
> Liga zu brigen wie etablierte Textmodus-Browser...

Klingt doch gut.

> Ich überlege deshalb immer mal wieder, die Arbeit an netrik wieder
> ernsthafter in Angriff zu nehmen. Es gibt aber eine ganze Reihe von
> Gründen, die mich zweifeln lassen:
> 
> - Ich habe irgendwie das Gefühl, dass außer mir niemand netrik wirklich
>   benutzt... Wobei die Empfehlung von DSL zu diesem Eindruck nicht ganz
>   passt. Hm.

Henne-Ei-Problem. Die User brauchen HTTPS und HTTP-AUTH, nutzen daher
kein Netrik. Netrik wird kaum benutzt, daher gibt's auch keine neuen
Features wie HTTPS und HTTP-AUTH.

Ist IMHO kein Argument. :-)

> - Eigentlich sollte ich mich auf andere Dinge konzentrieren,
>   insbesondere meine Diplomarbeit. Da ich aber auch so nicht so recht
>   dazu komme, ist das Argument irgendwie zweifelhaft...

hehe.

> - Wie Oben schon angedeutet, können andere Textmodus-Browser mittler
>   Weile viel mehr als damals als ich angefangen hatte. Auch wenn ich die
>   praktische Bedienung von netrik nicht wirklich missen möchte, frage
>   ich mich doch, ob andere Entwicklungen nicht wichtiger sind, als ein
>   besserer Textmodus-Browser...

Das ist ein Argument. Andererseits hast du nun ein paar Beispiele,
von denen du abkupfern kannst.

> - Ich hatte mit der aktiven Weiterentwicklung mitten in der Betaphase
>   aufgehört. Die verbleibenen Probleme, bevor ich das Ganze als "stable"
>   deklarieren könnte, sind nicht groß -- aber irgendwie alles Sachen,
>   auf die ich so recht keine Lust habe :-( Das motiviert natürlich nicht
>   sonderlich dazu, die Arbeit wieder aufzunehmen...

Klaro. Für sowas braucht man auch ein Team, keine Einzelperson. Sehe
ich auch an meinen eigenen Projekten.

> - Ich frage mich, ob es wirklich nützlich ist, netrik als monolithisches
>   Programm weiterzuentwickeln; ob ich die Mühe nicht eher darin
>   investieren sollte, ein modulares Webbrowser-Framework auf Hurd-Basis
>   zu implementieren. (Eventuell mit Linux-Kompatibilitätslayer, siehe
>   http://tri-ceps.blogspot.com/2005/09/welcome-to-hell.html )

Hauptsache, die Komponenten sind sauber getrennt. Ob nun durch separate
Prozesse, oder "nur" durch saubere Unterteilung des Programmes in Module,
die via Funktionsaufrufe kommunizieren, ist IMHO nebensächlich.


Viele Grüße,

    Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR