XUL-Code: Qualitätsvergleich Firefox/Google-Chrome

  • Moin.

    An diejenigen unter Euch, die außer an Firefox XUL-Code auch an dem von Google-Chrome geschraubt haben:

    Wie bewertet ihr, wenn ihr vergleicht, die Qualität des Codes?
    Zum Beispiel hinsichtlich Konsistenz (der Bezeichner), Redundanz, Schönheit, Wartbarkeit, ...

    Falls Euch der XUL-Code anderer grafischer Bedienoberflächen untergekommen, freue ich mich auch über vergleichende Kommentare dazu.

    Danke.

  • Die Qualität dürfte sich nicht viel nehmen. Wartbar dürfte Chrome eher sein, da er schlanker ist und weniger "Altlasten" hat. Die Basis vom Firefox stammt immerhin noch von 1998. Wobei ich davon ausgehe, dass nicht mehr sehr viel Code aus der Zeit übrig sein dürfte. XUL ist mächtig, aber auch komplex. Chrome ging lieber den Weg über normales HTML/CSS/JS um Erweiterungen fürs UI zu ermöglichen. Auch Mozilla ist mit JetPack jetzt auf dem Trip. Generelle Urteile sind insofern schwer. Je nach Aufgabe/Anforderungen hat da eine oder halt das andere Vorteile. Du musst vermutlich spezifischer werden, wenn du Aussagen mit Substanz erwartest.

  • Ähm. Jein. Firefox basiert weiterhin auf XUL. Mit JetPack wurde nur eine weitere (zusätzliche) Schnittstelle bereitgestellt, um die Erweiterungsentwicklung zu vereinfachen. Vor allem für einfachere Erweiterungen, statt sich in XUL einarbeiten zu müssen, kann man Erweiterungen jetzt auch in HTML, CSS und JavaScript bauen, was also die meisten Webentwickler schon beherrschen (sollten). Man wird aber auch in Zukunft Erweiterungen direkt in XUL schreiben können.

    https://addons.mozilla.org/en-US/developers/

  • Ähm. Doch? Genau dafür ist JetPack gedacht gewesen und seit 4.0 Teil von Firefox? Ich kenn den Umfang zwar nicht und auch nicht was Du genau bauen willst, aber für das allermeiste dürfte die JetPack-API reichen.

  • Hhmm.
    Vielleicht verstehst Du mich noch miss.
    Ich will keine Erweiterung bauen, sondern nur diverse GUI-Elemente von Firefox selbst (nicht von GUI-Elementen von Erweiterungen) ausblenden/anpassen.
    Beispiele:
    http://borumat.de/firefox-browse…efox-veraendern

    Das Ermitteln der passenden Stilregeln ist nicht selten ziemlich mühsam.

    Ganz im Gegensatz zum Ermitteln von Regeln für eine Website, deren Markup klar und gut aufgebaut wurde.

  • Die Struktur vom Firefox ist auch klar und gut aufgebaut. Die Logik hinter XUL aber halt eine andere wie die von HTML. Es gibt zwar viele Ähnlichkeiten, aber die alleine reichen nicht um direkt das Konzept von XUL zu verstehen. Auch nicht, wie viele spezielle XUL-CSS-Befehle, die es so nicht fürs Web gibt, müssen erst verstanden und gelernt werden, damit man sich sicher bewegt.

    Aber wenn es dir nur um Anpassungen geht. Dafür haben wir hier ein spezielles Unterforum. ; )

  • Zitat von bugcatcher

    Die Struktur vom Firefox ist auch klar und gut aufgebaut.


    Der Code, nehmen wir als Beispiel die Tableiste mit zwei Tabs, weckt bei mir Zweifel.
    Das formuliere ich mit aller gebotenen Zurückhaltung, da mir tiefere Kenntnisse in XUL fehlen und auch Vergleichsmöglichkeiten mit dem XUL-Code anderer Anwendungen (dazu wollte ich ja hier im Thread die Bewertungen von GUI-Code-Erfahrenen hören).


    Wird da wirklich sparsam mit IDs und Klassen umgegangen?
    Wird da soviel wie möglich an Angaben zur Gestaltung im Stylesheet erledigt?

    Zitat von bugcatcher


    Die Logik hinter XUL aber halt eine andere wie die von HTML. Es gibt zwar viele Ähnlichkeiten, aber die alleine reichen nicht um direkt das Konzept von XUL zu verstehen. Auch nicht, wie viele spezielle XUL-CSS-Befehle, die es so nicht fürs Web gibt, müssen erst verstanden und gelernt werden, damit man sich sicher bewegt.


    Schätzt Du es so ein, dass unter dem Strich der Einsatz von XUL (und seiner Komplexität) mehr Vorteile als Nachteile für die Weiterentwicklung von FF einbringt?

  • Die GUI eines Browsers ist halt keine Webseite. Da werden erheblich mehr Anforderungen dran gestellt. Ich finde die Bezeichnungen sprechen oft für sich selbst. Aber natürlich ist man am Anfang erstmal überfordert, alles in einen Kontext stellen zu können, der verständlich ist. Auch erlaubt XUL erheblich mehr als normales HTML+CSS.

    Die Vorteile für Firefox waren immer das er extrem anpassbar ist. Fast alles lässt sich wunschgemäss verändern und erweitern. Dadurch das es massenhaft Wechselwirkungen und Abhängigkeiten bestehen, kommt man natürlich nicht um eine entsprechende Einarbeitung rum.

    Ob ich jetzt aber meine, ob XUL unterm Strich mehr Sinn macht für Firefox als was anderes (von welchem "anderen" reden wir überhaupt? Vergleich ohne Vergleichsobjekt ist irgendwie widersinnig...), ist ohnehin müssig. Das würde Mozilla wegen mir eh nicht ändern. ; )

    XULs großer Vorteil ist die generelle Funktionalität. Firefox stellt seine GUI selbst da und ist damit unabhängig vom Betriebssystem. Trotzdem bietet XUL einen vollen Umfang an GUI-Funktionen/Elementen (was HTML & Co. nicht ansatzweise haben. Kannst dir ja mal den Quelltext von z.B. GoogleMail anschauen. Der Code ist erheblich schlechter zu lesen, da alles im Grunde eine <div>-Suppe ist). Die Grundform eines Elements ist direkt durch sein Tag erkennbar.

    Mal ganz nebenbei... schon mal mit dem DOM-Inspector dir Firefox angeschaut? Live-Eingriffe an einer GUI ist auch eine der Stärken von XUL.

  • Zitat von Andreas Borutta

    Wie bewertet ihr, wenn ihr vergleicht, die Qualität des Codes?

    Überhaupt nicht. Abgesehen vom minderen Interesse, das Integral über der verfügbaren Zeit erlaubt das nicht.

    Zitat von Andreas Borutta

    Wenn Du schreibst "Mozilla ist mit JetPack jetzt auch auf dem Trip", meinst Du damit, dass in naher Zukunft Firefox darauf umgestellt wird?

    Nein, denn wie es bereits berichtet wurde …

    Zitat von bugcatcher

    Mit JetPack wurde nur eine weitere (zusätzliche) Schnittstelle bereitgestellt, um die Erweiterungsentwicklung zu vereinfachen.

    Kann man also so als eine Art Schnittstelle fürs Volk ansehen. Die Menge der minderwertigen Erweiterungen wird also eklatant ansteigen.

    Zitat von Andreas Borutta

    Ich will keine Erweiterung bauen, sondern nur diverse GUI-Elemente von Firefox selbst (nicht von GUI-Elementen von Erweiterungen) ausblenden/anpassen.

    Die schlichten Mittel dazu wurden dir bereits in einem anderen Thread genannt, die magst du aber nicht benutzen. Wobei die dir genannten Methoden auch bei den Erweiterungen anwendbar sind.

    Auch sollte man zur Analyse einen nackigen Fx benutzen, denn alle dazu nicht benötigten Erweiterungen, so man meint sie überhaupt zu benötigen, können das Ergebnis heftigst trüben.

    Zitat von Andreas Borutta

    Der Code, nehmen wir als Beispiel die Tableiste mit zwei Tabs, weckt bei mir Zweifel.

    Das Gemansche kann ja auch erstmals kein Mensch lesen.
    Man könnte das XML in eine für humanoide Wesen lesbare Form überführen und dann ist der Text sonnenklar. Die Inhalte vielleicht noch nicht, aber dafür gibt es das MDN.

    P.S. da du bislang von UXL nur geringe Kenntnisse besitzt, sei dir der Grundkurs bei MDN empfohlen.

  • Zitat von .Ulli

    Die schlichten Mittel dazu wurden dir bereits in einem anderen Thread genannt, die magst du aber nicht benutzen.


    Wo soll ich das bitte geschrieben haben?

    Ich verwende den DOM-Inspector seit langem und schreibe darauf basierend eigene Stile für userChrome.css.

    Auf Details des XUL-Codes aus dem Beispiel gehe ich in einer Antwort auf bugcatchers Posting ein.

  • Zitat von Andreas Borutta

    Wo soll ich das bitte geschrieben haben?

    Das war der Teil, bei dem du die Befehlszeile abgelehnt hast und nur innerhalb eines GUI herumfuchteln möchtest.

  • Zitat von bugcatcher

    Die GUI eines Browsers ist halt keine Webseite. Da werden erheblich mehr Anforderungen dran gestellt. Ich finde die Bezeichnungen sprechen oft für sich selbst.


    Das ist mir klar.
    Werden wir konkret anhand des von mir geposteten Beispielcodes, den ich BTW via DOMI extrahiert habe.

    Code
    <tabs id="tabbrowser-tabs" class="tabbrowser-tabs"


    Die Vergabe der zusätzlichen Klasse neben der bereits existierenden ID erscheint mir überflüssig.

    Code
    <tab ... last-tab="true"


    Das Attribut "last-tab" erscheint mir überflüssig, da das letzte Kind eines Elters via Pseudo-Selektor ":last-child" getroffen werden kann.

    Code
    <toolbarbutton id="tabs-closebutton" class="close-button tabs-closebutton"


    Die Vergabe des Class-Attributes erscheint mir überflüssig.

    Solche Dinge meinte ich.

    Zitat von bugcatcher


    XULs großer Vorteil ist die generelle Funktionalität. Firefox stellt seine GUI selbst da und ist damit unabhängig vom Betriebssystem. Trotzdem bietet XUL einen vollen Umfang an GUI-Funktionen/Elementen (was HTML & Co. nicht ansatzweise haben. Kannst dir ja mal den Quelltext von z.B. GoogleMail anschauen. Der Code ist erheblich schlechter zu lesen, da alles im Grunde eine <div>-Suppe ist).


    Danke für den Hinweis.
    Div-Suppen sind in der Tat schlecht lesbar.
    Ich hatte eher an XML gedacht, wo - für eine gute Wartbarkeit/Lesbarkeit - reichlich eigene Elemente mit sprechenden Namen verwendet werden.
    Also statt

    Code
    <div id="foo" ... />


    lieber

    Code
    <foo ... />


    Zitat von bugcatcher


    Mal ganz nebenbei... schon mal mit dem DOM-Inspector dir Firefox angeschaut? Live-Eingriffe an einer GUI ist auch eine der Stärken von XUL.


    Klar, den DOMI kenne und verwende ich schon lange.

    Jedoch liegt seine Stärke nicht darin, dem Verwender - für Tests - temporär zu erlauben, Code zu entfernen, zu deaktivieren oder zu ergänzen.
    Das geht prima mit Firebug, wenn es um Webseiten-Code geht.

  • Zitat von Andreas Borutta

    Falls Du das Posting nennen könntest, wäre das prima.

    Nein, das Spielchen mache ich nicht mit.
    Es begann mit

    Zitat

    $ find -name *.dtd

    danach kam noch etwas …

    Auch die entsprechenden Quellen wurden dir genannt.