Beiträge von Herzmann

Zitat von Sören Hentzschel

Ja, in Firefox ist in den letzten 14 Jahren viel dazu gekommen.
......
Aber wenn du eine Firefox-Version von damals und heute unter exakt gleichen Bedingungen vergleichen würdest, wäre die heutige Version ohne Zweifel deutlich schneller.

Danke für die historischen Details.
Also bei mir ist er seitdem eher langsamer geworden, vor allem nochmal im letzten halben Jahr, auch wenn ich ihn mit quasi leerer Tab-Leiste benutzt habe.
Aber Deine Ausführungen machen dennoch Sinn. Vielleicht liegt es auch daran, dass Webseiten in der Zeit ja auch viel komplexer geworden sind, z.B. durch die immer ausgefeilteren Tracking-Anstrengungen und den Umwegen um die DSGVO herum.
Dass beim Starten nicht mehr alle Tabs geladen werden, sondern nur noch der zuletzt angeschaute, hat tatsächlich einen großen Gewinn gebraucht.

Zitat von Herzmann

Die Änderung werde ich mal einbauen.

Da habe ich ein bisschen mit rumexperimentiert, leider ohne Erfolg. Das Skript von BrokenHeart ist in Teilen einfach zu weit hinten an.
So werde ich meine Verbesserungen damit dann auch mal einstellen und vielleicht mit den Skripten von Endor weiter experimentieren.
Und bis zur V 131 sind es ja auch nur noch 8 Wochen. Bis dahin kann ich ja auch noch ohne Vertikale Tab-Leiste auskommen.

Zitat von milupo

Leider funktioniert da nur der absolute Pfad:

CSS

@import url("file:///C:/Users/Lenovo M58/AppData/Roaming/Mozilla/Firefox/Profiles/id1ko6na.testnightly88/chrome/CSSShadow/tabs_mittig.css");

Das müsste doch mit einem relativen Pfad gehen. Z.B:

@import "./CSSShadow/tabs_mittig.css";

oder evtl. (je nachdem wo die Basis CSS steht):

@import "../CSSShadow/tabs_mittig.css";

Zitat von Sören Hentzschel

Das ist die originale Version der oben gezeigten Funktion in Firefox 129:

https://searchfox.org/mozilla-releas…nt/tabs.js#1980

Das ist ja sehr interessant. Die hatten die gleiche Idee, wie ich, nämlich dass die for-Schleife verdammt viel Performance schluckt, und weg muss.

Danke für den Link. Die Änderung werde ich mal einbauen.

Zitat von FuchsFan

Nun probiere ich natürlich auch immer dein Script, aber das läuft zumindest hier nicht rund, weil es einfach keine zweite Tabreihe öffnet (ist auf 2 gestellt).

Ich habe nun eine extra Variable `nVerticalTabPaneExtraWidth` (Zeile 179) eingeführt, mit der man extra Platz für Extras schaffen kann mit Fx129. Wie weit das auch für andere Versionen funktioniert, kann ich nicht sagen.

src/MultiRowTabs.uc.js · master · Ulf Zibis / MultiRowTabs for Firefox · GitLab

GitLab.com

gitlab.com

Zitat von BrokenHeart

Zitat von Herzmann

Ich fand's unpraktisch, mit der Tabbar-Breite herumexperimentieren zu müssen, ....

Das ist ja auch nachzuvollziehen, allerdings ist das Ergebnis bei mir so, dass jetzt, je nach zusätzlichen eingefügten Steuerelementen, eine sehr große, ungenützte Lücke am rechten Rand [5] erscheint (z.B. Wenn die Scrollbar erscheint). Durch Anpassen der Tabbar-Breite über die vorhandene Variable lässt sich dies wie gesagt viel passgenauer realisieren. Wenn man das automatisiert machen möchte, dann müsste man den Platz/Anzahl der zusätzlichen Elemente nach eine User-Anpassung ...

Mit der neuesten Version müsste das jetzt über die zusätzliche Variable machbar sein.

Zitat von grisu2099

Wenn du auf einen Beitrag direkt über deinem antwortest, brauchst du gar nichts zu zitieren...

Wenn Du genau hingeguckt hättest, wüsstest Du , dass das hier nicht der Fall ist.

Zitat von 2002Andreas

Kannst du dir bitte angewöhnen, nicht kompl. Beiträge zu zitieren, danke.

Mache ich ja im allgemeinen. Hier hatte ich keine richtige Idee, was ich da sinnvoll wegstreichen kann, da ich mich ja auf fast alles beziehe.

Zitat von Sören Hentzschel

Sowohl aktueller Code als auch vorgeschlagene Korrektur haben das Problem, dass hier eine Firefox-interne Funktion überschrieben wird und Mozillas aktuelle Änderungen an dieser Funktion nicht berücksichtigt sind. Der Aufruf von _getDragTargetTab() entspricht sogar schon seit 1 1/2 Jahren nicht mehr dem Original-Code und übergibt einen Parameter, den es so lange schon nicht mehr gibt. Gleiches gilt für die _getDropIndex-Funktion selbst auch.

Wenn man Firefox-interne Funktionen überschreibt, ist es wirklich wichtig, darauf zu achten, dass man möglichst synchron mit dem Original-Code bleibt. In diesem Fall entsteht durch die falsche Funktions-Signatur kein Schaden. Aber das ist die klassische Quelle für Bugs aller Art, die durch Scripts verursacht werden.

Die Nicht-Berücksichtigung der aktuellen Änderungen wiegt schon schwerer, weil die Nutzer-Einstellung für vertikale Tabs ignoriert wird. Das Script unterstützt ja auch vertikale Tabs. Ich empfehle in jedem Fall, hier die bereits vorhandene Nutzer-Einstellung zu berücksichtigen statt das über eine nicht veränderbare Option im Script zu steuern.

Gute Hinweise, danke!

Ich finde es halt immer wieder spannend, wie sehr sich bestehender Code oft vereinfachen lässt, und dass ich bei der Beschäftigung auch oft auf unentdeckte Bugs stoße. Die Alte Weisheit – je mehr Zeilen, je mehr Bugs – beweist sich immer wieder.

Insofern verstehe mein Gebastel eher als Übung. Gerade weil nun vertikale Tab-Leisten im Anmarsch sind, und damit vielleicht auch mehrzeilige nicht mehr weit weg, erübrigt sich das ganze dann. Ich bin halt etwas frustriert, weil die an sich guten Aris-CSS meinen FF so verlangsamen, und die Script-Variante hier einfach performanter ist.

Gibt's die vorhandene Nutzereinstellung schon in V 129?
Um mir das Suchen zu ersparen, kannst Du bitte mitteilen, wie die heißt, bzw. wo sich die Doku darüber befindet.

Zitat von BrokenHeart

Hier das Script (Inhalt kopieren und als Text-Datei 'MultiRowTabs.uc.js' ins 'chrome'-Verzeichnis einfügen):

JavaScript: MultiRowTabs.uc.js

    gBrowser.tabContainer._getDropIndex = function(event, isLink) {
        var tabs = this.allTabs;
        var tab = this._getDragTargetTab(event, isLink);
        if (!RTL_UI) {
            for (let i = tab ? tab._tPos : 0; i < tabs.length; i++) {
                if (
                    event.screenY <
                    tabs[i].screenY + tabs[i].getBoundingClientRect().height
                ) {
                    if (
                        event.screenX <
                        tabs[i].screenX + tabs[i].getBoundingClientRect().width / 2
                    ) {
                        return i;
                    }
                    if (
                        event.screenX >
                        tabs[i].screenX + tabs[i].getBoundingClientRect().width / 2 &&
                        event.screenX <
                        tabs[i].screenX + tabs[i].getBoundingClientRect().width
                    ) {
                        return i + 1;
                    }
                }
            }
        } else {
            for (let i = tab ? tab._tPos : 0; i < tabs.length; i++) {
                if (
                    event.screenY <
                    tabs[i].screenY + tabs[i].getBoundingClientRect().height
                ) {
                    if (
                        event.screenX <
                        tabs[i].screenX + tabs[i].getBoundingClientRect().width &&
                        event.screenX >
                        tabs[i].screenX + tabs[i].getBoundingClientRect().width / 2
                    ) {
                        return i;
                    }
                    if (
                        event.screenX <
                        tabs[i].screenX + tabs[i].getBoundingClientRect().width / 2
                    ) {
                        return i + 1;
                    }
                }
            }
        }
        return tabs.length;
    }

Alles anzeigen

In der Funktion gBrowser.tabContainer._getDropIndex (ab Zeile 1358) ist ein Fehler drin.
Wenn sich die Maus in X-Richtung genau auf der Mitte des Tabs befindet – also wenn event.screenX == tabs[i].screenX + tabs[i].getBoundingClientRect().width / 2 , wird der "Drop" des Tabs nicht ausgeführt.

Die Korrektur (incl. Verschlankung) müsste so aussehen:

    gBrowser.tabContainer._getDropIndex = function(event, isLink) {
       let tabs = this.allTabs;
       let tab = this._getDragTargetTab(event, isLink);
       for (let i = tab ? tab._tPos : 0; i < tabs.length; i++) {
           if (event.screenY < tabs[i].screenY + tabs[i].getBoundingClientRect().height) {
               if (event.screenX <= tabs[i].screenX + tabs[i].getBoundingClientRect().width / 2)
                   return i + (RTL_UI ? 1 : 0);
               else if (event.screenX < tabs[i].screenX + tabs[i].getBoundingClientRect().width)
                   return i + (RTL_UI ? 0 : 1);
           }
       }
       return tabs.length;
   };

Zitat von FuchsFan

Herzmann

Nun probiere ich natürlich auch immer dein Script, aber das läuft zumindest hier nicht rund, weil es einfach keine zweite Tabreihe öffnet (ist auf 2 gestellt). Den Newtab-Button habe ich farblich geändert (zur besseren Erkennung), ist nun die erste Tabreihe gefüllt, so wird dieser ausgeblendet, und es erscheint der originale. Dadurch wird natürlich auch keine zweite Reihe geöffnet.

Was könnte da schief laufen?

Ersteres könnte daran liegen, dass es zwischen Windows und Linux Unterschiede bzgl. der Breite des Firefox-View-Button und der Scroll-Leiste gibt. Da könntest Du mal probieren, die Schätzwerte, die ich da eingesetzt habe, zu verändern.
EDIT: obiges wirkt sich aber nur auf die Breite vertikaler Tab-Spalten aus.

Warum farbliche Veränderung des Newtab-Button was durcheinander bringt, habe ich jetzt keine Idee.

Aber beziehst Du Dich auf 2 horizontale Tab-Reihen, oder auf 2 vertikale Tab-Spalten?

Und super danke für's Testen.

Zitat von Sören Hentzschel

PS: Apropos Branches, in deinem einen Branch solltest du hoover noch in hover umbenennen.

Soweit ich weiß ist das in GIT nicht möglich, oder weißt Du wie das geht?

Und das Problem mit den Zeilennummern tritt auch auf, wenn jemand sein Skript im Forum nachträglich bearbeitet, wie z.B. hier. In GIT hat man dann immer noch das DIFF und die History zur Verfügung.

Zitat von Sören Hentzschel

Wenn du den Code extern verlinkst statt hier im Forum zu posten, dann empfehle ich die Verwendung der Funktion „Permanenter Link“ auf GitLab. Denn ansonsten ändert sich der Inhalt mit jeder Änderung und die Zusammenhänge sind später nicht mehr nachvollziehbar, weil Code und Beiträge nicht mehr zusammenpassen.

Gute Idee.
Allerdings habe ich Änderungen immerhin schon mal jeweils in Branches ausgelagert und entsprechend verlinkt um genau dem zu dienen.
Wo konkret ist Dir das Problem begegnet?

Eingebettet habe ich den Code hier nicht, um die Ladezeiten der Forumsseiten nicht unnötig zu verlangsamen. Bei mehreren > 80 kB je Script auf einer Forumsseite macht das zumindest bei mir hier schon einiges aus.

Außerdem hat man mit dem GitLab-Link auch gleich dessen spezielle Funktionalität wie History und Diff zur Verfügung.
Ein Diff zwischen 2 hier im Forum eingebetteten Codes ist da schon viel aufwendiger.

Zitat von Herzmann

Ich habe nun das Zusammenbauen der CSS mal erheblich kompaktiert. So ist der Code übersichtlicher und dürfte besser performen:
https://gitlab.com/UlfZibis/multi…?ref_type=heads

Die Perma-Link-Funktion erzeugt hier exakt denselben Link:

src/MultiRowTabs.uc.js · compacted_beautified · Ulf Zibis / MultiRowTabs for Firefox · GitLab

GitLab.com

gitlab.com

Zitat von 2002Andreas

Dann mach dir mal schon weitere Gedanken

Danke für den Hinweis.
Ich bin mir schon im klaren, dass die Bastelei an den Tab-Leisten nicht wirklich nachhaltig sein kann, in Anbetracht, dass nun vertikale Tab-Leisten nun auch von offizieller Seite im Anmarsch sind.

Von daher macht mein nun übersichtlicherer CSS-Zusammenbau durchaus Sinn, um spätere Anpassungen einfacher zu machen.

Ich habe nun das Zusammenbauen der CSS mal erheblich kompaktiert. So ist der Code übersichtlicher und dürfte besser performen:

src/MultiRowTabs.uc.js · eacb14dd9a562fba615002b31b981527f7984b0d · Ulf Zibis / MultiRowTabs for Firefox · GitLab

GitLab.com

gitlab.com

Zitat von BrokenHeart

Zitat von Herzmann

Bitte entschuldige dass ich mir mit dem Thema erst mal nicht so viel Mühe gegeben habe.

Ich glaube spätestens jetzt hat jeder verstanden, dass du das ganze wohl ins Lächerliche ziehen möchtest. Wie gesagt, lassen wir das Thema!

Wie kommst Du denn darauf?
Ich nehme das sehr ernst, und deshalb habe ich mich für meinen laxen "Schnellschuss" entschuldigt.

So hoffe ich, dass Dir die neue Version des Headers jetzt gefällt.

Zitat von BrokenHeart

Das ist ja auch nachzuvollziehen, allerdings ist das Ergebnis bei mir so, dass jetzt, je nach zusätzlichen eingefügten Steuerelementen, eine sehr große, ungenützte Lücke am rechten Rand [5] erscheint ......

Natürlich ist der Source-Code sehr unschön. War mein allererstes JS und ich hatte weder von der Sprache (komme von C++/C#) viel Ahnung, .....

Ja zusätzliche Steuerelemente passen jetzt nicht mehr so elegant rein. Vielleicht finden wir zusammen ja eine Lösung, wie man das schick miteinander verheiraten kann. Dafür könnte ich Dir auch Schreibrechte im GIT einräumen. Aber Änderungen bitte erst mal in einem eigenen "Branch" beheimaten.

Ja so ähnlich wie bei mir, ich komme noch aus der Assembler-Welt und bin über C(++) dann schließlich beim echten Java gelandet.
Für die mehr oder weniger ersten Schritte in JavaScript habe ich hier gute Inspirationen bekommen.

Wie Du ab Zeile 286 sehen kannst, habe ich mal angefangen, das CSS auf andere Weise zusammenzubauen. Ich denke, das ist so übersichtlicher, logischer und spart Code-Zeilen.
Außerdem schlucken die mehrfachen replace()-Operationen sicher richtig Performance.

Dann würde mich noch interessieren, wofür die Anweisung (jetzt) in Zeile 312 gut sein soll. Das Icon dürfte doch egal sein, wenn es sowieso nicht gebraucht wird.

Auch denke ich, dass es ökonomischer wäre, die Grafiken aus Dateien zu laden, statt sie durch den base64-Dekoder zu quälen. So sind sie dann auch leichter austauschbar.

Auch die Kommentare könnte man aus dem CSS rausnehmen und stattdessen in den JS-Code schreiben, was die CSS-Abarbeitung beschleunigen könnte.

So, jetzt hab' ich auch noch das "Tab-Schließen-Knopf per Mouse-Hoover" nach der Idee von 2002Andreas eingebaut.

src/MultiRowTabs.uc.js · close_button_on_hoover · Ulf Zibis / MultiRowTabs for Firefox · GitLab

GitLab.com

gitlab.com

var nTabCloseButton  = 1   // [0] Tab-Schließen-Button verbergen
                           // [1] Tab-Schließen-Button bei Maus-Berührung anzeigen
                           // [2] Tab-Schließen-Button immer auf allen Tabs anzeigen

Könnt Ihr gerne mal testen.

Zitat von BrokenHeart

Herzmann :

Ich finde es wirklich toll, dass du versuchst das uralte Skript von mir für deine Zwecke anzupassen (keine Ironie oder Sarkasmus!) .

Aber was ich nicht so toll finde, ist die Tatsache, dass du ......

Erst mal dicken Dank für die Rückmeldung.

Die Änderung im Header war ein Schnellschuss. So wie Du Alice in die "Danke-Zeile" gesetzt und Dich als Autor nach oben, hab' ich das einfach auch so gemacht.
Ich ändere das aber gerne nach Deinen Wünschen, denn Deine Vorarbeit soll ja nicht unter den Tisch fallen.
Kannst Du bitte mal grob oder genau skizzieren, wie Du es gerne hättest.

Bitte entschuldige dass ich mir mit dem Thema erst mal nicht so viel Mühe gegeben habe.

Wo siehst Du da Löschungen im Änderungsverlauf? Ich habe lediglich die Reihenfolge chronologisiert, weil das schon mal zur Verwirrung beigetragen hat. Zusätzlich fände ich es gut, diesen Einträgen noch den Autor zu verpassen (dann sieht man auch wer wieviel Arbeit da reingesteckt hat.

Im übrigen kannst Du alle Änderungen, teils ausgelagert in Branches, per GIT-Diff und in der GIT-Historie genau nachverfolgen, was bei Deinen Änderungen nicht so leicht ist.

Ich fand's unpraktisch, mit der Tabbar-Breite herumexperimentieren zu müssen, um herauszufinden, wie man auf 2 oder mehr Spalten kommt. Außerdem hatte das Auswirkung auf die Existenz des Scoll-Balkens und auf die Erscheinung und Position des Plus-Button, der dann teilweise gar nicht mehr erschien und das war obendrein noch abhängig vom Firefox-View-Button.

Die Autohide-Variable habe ich eingeführt, weil ich im Hinterkopf habe, auch für die anderen Ansichten Autohide zu ermöglichen. Wie weit ich damit komme .... ??? Außerdem wurden so manche Abfragen einfacher, und es kann vermutlich noch manches einfacher gemacht werden.

Zitat von 2002Andreas

Teste mal:

nglayout.enable_drag_images

auf false stellen.

Danke für den Versuch, ist aber doch genauso nicht hilfreich und störend. Rote Linie an der potentiellen Einfügestelle wäre da doch viel nützlicher.

Zitat von Mira_Belle

Auch gerade kurz getestet!

Wäre aber schön, oder nützlich, wenn dies auch direkt im Skript eingestellt werden könnte.
Muss aber nicht

Dankeschön.

letzteres stört mich auch, deshalb ist das schon in Planung.
Ich hoffe, ich kann da was passendes von Endor8 abkupfern/anpassen.

Beim Hoovern kommt bei mir ein hässlicher 3-zeiliger Tool-Tipp, wo dennoch fast alles abgeschnitten wird. Die früheren simplen schwarzen Einzeiler waren mir da lieber.
Vorschaubild kommt bei mir nur beim Anfassen und Verschieben, was ich an der Stelle ziemlich überflüssig finde, ich weiß ja, was ich verschieben will.

Zitat von 2002Andreas

So sieht das mit dem Skript aus Beitrag Nr. 2 hier aus:

Den Viewbutton habe ich dabei ausgeblendet, und immer nur 1 Tab pro Reihe.

Das Verschieben der Tabs funktioniert in beiden Richtungen hier nicht einwandfrei. Es braucht jeweils mehrere Versuchen für rauf oder runter.

Danke für's Testen. Oben jetzt auch ein Screen-Shot von mir.

Was ist das für ein Schiebebalken links von der Tab-Leiste?
Bei mir ist links nur noch Bildschirmrand.

An der Verschiebe-Logik habe ich nichts geändert, insofern komisch, dass das jetzt schlechter funktioniert.
(Und bei mir funktioniert es auf der rechten Seite ja von Anfang an nur nach unten, aber ansonsten gut, auch bei 1000 Tabs.)

Ich habe nur die Größen der Elemente bearbeitet und rechnerisch voneinander abhängig gemacht, damit sowohl rechts als auch links die Tab-Buttons zuverlässig voll sichtbar sind, genauso wie der Scrollbalken und der Plus-Button ganz unten.
.... und das mit/ohne Firefox-Button, mit/ohne Autohide, mit/ohne Scrollbalken.