
Beitrag von Mira_Belle (24. April 2025 um 14:46 )
Dieser Beitrag wurde vom Autor gelöscht (24. April 2025 um 14:47 ).
So liebe Leute,
In #432 hätten wir jetzt den aktuellen Code, wieder in der Hoffnung daß sich keine Fehler eingeschlichen haben .
Es gibt einen Code mit einem Satz von Varianten für die Icon - Zähler Reihenfolge, je mit und ohne Trennstrich.
Ich hätte da auch noch eine weiter automatisierte Version mit Variablen die selbständig die Trennlinie inkl. Abständen einbauen, aber dann blickt keiner mehr durch.
Dann gibt es den einfacheren Code den ich selber benutze, mit einer festgelegten Icon - Zähler Reihenfolge; wer etwas den Überblick hat, sollte sich aus dem kompletten Code bedienen können, um seine eigenen Reihenfolgen und Trennstriche in eine vereinfachte Version einzubauen.
Oder einfach fragen.
Vielen Dank nochmals an alle Beteiligten!
PS:
Ein Hinweis noch: bei den Extra Einstellungen für den Fall daß ein Zähler auf 0 steht - will ich unbedingt - konnte ich bei mir einen Performance Unterschied feststellen zw. opacity und fill bzw. color mit reduzierter Deckkraft im Farbcode.
ZB ist opacity: 0.5 deutlicher langsamer als etwa color: hsl(0, 0%, 50%, 0.5) !important; und fill: hsl(0, 0%, 50%, 0.5) !important;.
Das macht sich uU nicht bei jedem bemerkbar, evtl. nur bei vielen 0 Einträgen, und man braucht in dem speziellen Fall auch ein .svg Icon mit der korrekten fill Definition im Code, etc..
für den Fall daß ein Zähler auf 0 steht - will ich unbedingt
Man könnte die "Nuller" auch einfach ausblenden...
ZB ist opacity: 0.5 deutlicher langsamer als etwa color: hsl(0, 0%, 50%, 0.5) !important; und fill: hsl(0, 0%, 50%, 0.5) !important;.
Dass der Unterschied für dich wahrnehmbar ist, finde ich ein wenig überraschend in Anbetracht dessen, um wie wenige Elemente es eigentlich geht. Aber grundsätzlich ist es nicht überaschend, dass opacity langsamer ist, weil sich das auf sämtliche Eigenschaften auswirkt und das andere eben nur auf color und fill. Außerdem verändert opacity nicht nur die Deckkraft für das Element selbst, sondern auch für sämtliche Kindelemente. Das ist also mit wesentlich mehr Arbeit für den Browser verbunden.
Man könnte die "Nuller" auch einfach ausblenden...
Mach ich doch auch in den Codebeispielen, für den ersten Ordner Zähler - aber wenn ein Ordner keine Lesezeichen drin hat, aber Ordner - dann will ich den Ziffern Zähler nur verblasst haben!
Etwas anal, ich weiss, aber einfach kann jeder.
Den aktuellen Code habe ich übrigens auch angepasst, um wahlweise einen oder beide 0 Zähler mit display: none ausblenden zu können, wie du es bei dir gemacht hast, ohne weitere Änderungen, also flexibler als vorher.
So zumindest der Plan, bin schon ganz verunsichert nach meinen ganzen Pannen.
Dass der Unterschied für dich wahrnehmbar ist, finde ich ein wenig überraschend in Anbetracht dessen, um wie wenige Elemente es eigentlich geht. Aber grundsätzlich ist es nicht überaschend, dass opacity langsamer ist, weil sich das auf sämtliche Eigenschaften auswirkt und das andere eben nur auf color und fill. Außerdem verändert opacity nicht nur die Deckkraft für das Element selbst, sondern auch für sämtliche Kindelemente. Das ist also mit wesentlich mehr Arbeit für den Browser verbunden.
Bin auch überrascht, aber es passiert deutlich merkbar nur bei vielen Einträgen mit opacity in einem einzelnen Popup.
In diesem Fall ist das mein - wenig realistischer - Test Setup im Testprofil, der teils Dutzende Lesezeichenordner mit keinen Ordnern und/oder keinen Lesezeichen drinnen hat; also eine Menge Pseudoelemente mit opacity < 1.
Deine Erklärung macht auch Sinn; ich kenne es aus mehreren (Render) Anwendungen, daß Transparenz teils massive Leistungseinbrüche mit sich bringen kann, wenn sie nicht sehr gezielt/lokalisiert eingesetzt wird.
Mh, was sind die Vor- bzw. Nachteile, wenn man das meiste davon direkt in JavaScript umsetzt?
Ich frag' nur aus Neugierde!
Mh, was sind die Vor- bzw. Nachteile, wenn man das meiste davon direkt in JavaScript umsetzt?
Was mich angeht, manche Sachen kann ich einfach nicht...
Was mich angeht, manche Sachen kann ich einfach nicht...
Ok, ich tu mir mit CSS ziemlich schwer, was so "Funktionen angeht.
Da bist Du der Fuchs.
Aber es ist, war eine generelle Frage!
Ein grosser Unterschied wäre noch die Möglichkeit, separate CSS Dateien live editieren und speichern zu können in den Browser Werkzeugen, und auch sofort ein Ergebnis zu sehen.
Damit kann man über mehrere verbundene CSS Dateien parallel arbeiten, idealerweise mit einer zentralen Kontroll CSS plus darin importierten CSS Dateien für grössere Varianten, und dabei alle Styling Elemente aufeinander abstimmen ohne Restarts etc..
Ausserdem fällt damit ein Menge zusätzlicher Code weg im JS, das ganze Dateipfad Gedöns und die Einbindung von CSS allgemein, was bei Fx Code Veränderungen das eventuelle Troubleshooting weiter kompliziert.
Horstmann Stimmt, das sind durchaus Punkte, die für ein ausgelagertes CSS sprechen.
Für CSS im Skript spricht "für" mich, es ist variabler.
Mann hat alles unter "Dach und Fach", und wenn man geschickt die Variablen setzt,
hat man so etwas wie ein Konfigurationsbereich, wie ich schon mit dem Hinweis auf das Scrollbar-Skript beschreiben wollte.
Auch hat man mit JavaScript Möglichkeiten, die einem nur in CSS so nicht so einfach, oder auch gar nicht, zur Verfügung stehen.
Für einen Benutzer ist ein JavaScript, so denke ich, in der Anwendung einfacher, er muss nicht mehrere Dateien in verschiedene
Verzeichnisse ablegen.
Die Konfiguration des Skriptes, wenn geschickt gemacht, sollte auch für einen Laien einfach sein, weil er ja dann,
nichts am eigentlichen Code verändern muss und brauch.
Nachteil, es werden Monster, wenn man alles Mögliche abdecken will.
Kann man ja hier in diesem Thread mit "meinem" Skript nachvollziehen.
Hatte das ursprüngliche Skript ca. 150 Zeilen,
hat die letzte funktionierende Version schon ca. 200 Zeilen.
Ich finde Javascript einfach spannend und in Kombination mit CSS steht einem der Firefox offen.
Ob nun Funktionen und Layout getrennt oder, wie ich es lieber mag, Funktionen und Layout kombiniert in einer Datei,
ist wohl eine Frage der persönlichen Vorlieben. Denke ich.
Was sagt DIhr dazu Sören Hentzschel und BrokenHeart ?
Interessiert mich, bitte einen kleinen Kommentar.
Was sagt DIhr dazu Sören Hentzschel und BrokenHeart ?
Interessiert mich, bitte einen kleinen Kommentar.
Es kommt immer darauf an, was man möchte.
Ich bin grundsätzlich dagegen, Dinge zu vermischen, die nicht zusammen gehören. Weder CSS noch JavaScript gehört in HTML-Dateien und CSS gehört auch nicht in JavaScript-Dateien. Denn das verhindert eine effektive CSP, es erschwert Linting und man bekommt noch nicht einmal Syntax-Highlighting für die „fremde“ Sprache. Für die Wartbarkeit und damit letztlich auch Code-Qualität ist das schlecht.
Wenn einem das egal und dafür wichtiger ist, möglichst alles mit einer einzelnen Datei teilen zu können, sind das halt andere Voraussetzungen.
Aber als kleiner Inspirations-Ansatz, weil eine Konfiguration angesprochen worden ist: Das eine sind CSS-Variablen. Damit kann man schon viel anpassbar machen. Und wenn man größere Abhängigkeiten benötigt, könnte man im Script eigene Optionen in about:config setzen. Diese kann man dann im CSS wiederum auslesen. Auf diese Weise kann man if/else-Kontrukte auch im CSS simulieren.
Es kommt immer darauf an, was man möchte.
So schaut's aus.
Dein Einwand kann ich durchaus verstehen, wenn man große Projekt pflegt,
wie den Onlineauftritt eines Unternehmens würde es auf jeden Fall sehr schnell unübersichtlich und kompliziert werden.
Wir reden hier aber nur von kleinen Anpassungen des Firefox.
Und man muss auch bedenken, dass weniger visierte Anwender solche Anpassungen vornehmen möchten.
Einige sind ja schon fast überfordert, die richtigen Vorbereitungen zu treffen, damit der Firefox überhaupt anpassbar wird.
Nun bin ich gespannt, was BrokenHeart zu dem Thema meint.
Eventuell trenne ich in Zukunft ja doch CSS und JavaScript, aber ich weiß es noch nicht.
Nun bin ich gespannt, was BrokenHeart zu dem Thema meint.
Habe eigentlich keine dezidierte Meinung dazu, sehe das so ähnlich wie du. Bei der hier üblichen Größe spielt es wohl keine große Rolle, ob man sein CSS auslagert oder direkt im Skript verwurstet. Aber übertreiben sollte man es wirklich nicht mit dem eingebundenen CSS - so wie ich es bei den MultiRowTabs gemacht hatte .
Bei größeren (professionellen) Projekten hat Sören sicher mit seinen Hinweisen recht.
Mich interessiert die Thematik aber nicht sonderlich, da ich die Beschäftigung mit den "Formalismen" von JavaScript/CSS nicht so wichtig finde. Für mich steht das Verstehen des Firefox-Quellcodes im Vordergrund: z.B. die Aufrufe über die idl-Schnittstelle und die Funktionalität aus den importierten Modulen. Was nützt es mir mit sauberem Code "in Schönheit zu sterben", wenn ich nichts über die Firefox-spezifischen Möglichkeiten von CSS/Javascript weiß und das auch anwenden kann?
OT: Viel wichtiger finde ich, dass endlich mal jemand (zumindest für Windows) ein (PowerShell-)Skript schreibt, welches das Herunterladen und Entpacken der zum Ausführen von User-Skripten notwendigen Dateien übernimmt. Ich kenne mich leider nicht mit dem Scripting aus und eine ausführbare Anwendung in C++ zu schreiben halte ich für übertrieben. Außerdem hat man nachher eine .exe Datei, die auch noch mit Administrator-Rechten ausgeführt werden muss. Auch wenn man Quellen und make-File mitliefert, kann ich jeden verstehen, der so was nicht nutzen möchte. Ein Skript wäre da schon geschmeidiger.
Ich bin mir sicher, wenn so ein Skript existiert, würden auch mehr Menschen die User-Skripte nutzen.
Mira_Belle Du beherrscht das doch, wenn ich mich nicht täusche. Na, wie wär's ...
Du beherrscht das doch, wenn ich mich nicht täusche. Na, wie wär's ...
Würde ich ja gerne, aber so wirklich fit bin ich da auch nicht!
UND wäre auf jeden Fall auf Hilfe angewiesen.
Und dann wäre ja noch das Problem mit dem Testen!!
In einer VM sollte das kein Problem sein, aber bisher habe ich auf meinem System
es einfach noch nicht hinbekommen, so ein Ding zu starten. Ums verrecken nicht!
Da steh' ich mir wohl selbst im Weg, warum auch immer.
Nachtrag!
Ich überrasche mich immer mal wieder selber!
ABER ich scheitere am Profilpfad.
Runterladen, ok. Entpacken, ok.
Kopieren der "config.js" ins Programmverzeichnis, auch ok,
Anlegen des Ordners "userChromeJS", auch kein Ding.
Kopieren der Dateien, die da rein sollen, abgehakt.
Und dann kommt das Profilverzeichnis
Ende. Da verließen sie sie! Ich bin in einer Schaffenskrise.
"$env:APPDATA "Mozilla\Firefox\Profiles" bis hier her komme ich, und dann "xxx..default"!?
Ich muss ja in diesen Ordner um darin den "chrome"-Ordner erstellen zu können.
Jemand eine Idee?
Ein grosser Unterschied wäre noch die Möglichkeit, separate CSS Dateien live editieren und speichern zu können in den Browser Werkzeugen, und auch sofort ein Ergebnis zu sehen.
Geht wohl fast hiermit:
// cssLive.uc.js
(function() {
if (location.href !== 'chrome://browser/content/browser.xhtml') return;
//if (location !=AppConstants.BROWSER_CHROME_URL) {
// return;
/*** OPTIONEN START *******************************************************/
var cssLiveOptions = {
/* Falls sich die Testdatei in einem Unterverzeichnis von "chrome"
befindet, bitte hier zwischen Anführungszeichen eintragen, ansonsten
nur die Anführungszeichen */
subdir: 'css',
/* Name der Testdatei */
file: 'Test.css'
};
/*** OPTIONEN ENDE ********************************************************/
var buttonPath = '';
var testFile = Services.dirsvc.get('UChrm', Ci.nsIFile);
if( cssLiveOptions.subdir != '' ) {
testFile.append( cssLiveOptions.subdir );
buttonPath += cssLiveOptions.subdir + "/";
}
testFile.append( cssLiveOptions.file );
buttonPath += cssLiveOptions.file;
var buttonTxt_1 = buttonPath + " aufrufen";
var buttonTxt_2 = buttonPath + " ausführen";
var errorTxt = "Die Datei \n" + testFile.path + "\n existiert nicht.";
ChromeUtils.importESModule("resource:///modules/CustomizableUI.sys.mjs");
try {
CustomizableUI.createWidget({
id: "fp-get-css-file",
defaultArea: CustomizableUI.AREA_NAVBAR,
removable: true,
label: buttonTxt_1,
tooltiptext: buttonTxt_1,
onClick: function() {
if( testFile.exists() ) {
testFile.launch();
} else {
alert( errorTxt );
}
},
onCreated: function(aNode) {
aNode.style.listStyleImage = 'url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAADJklEQVR4Xi3Pb0yVdRjG8e/ze57ncDrAOWwRhDQ7xYAMlAgIBW2txaio5TvMzZa68oWtzRdKbXbIpWyOzcWLWqXkFjUtsIksW72wuTVx+EJHCxhkSCNoKLYDwuH8e66eNV98dr24t/u+LwsAoKsucqg4tFS4kiTtge4PFAkRksADGdsyua4JXJ7ITH0yQw+ABTB3sHGipGNjJX8MgzGw6oEBQi5kPYinQBYEbDDAX5PEulJXPhqn2bQE2Fayfa2S8THOfu/wzTkDzmOQV8nAkOHMoIFgmS9K3w/i5DmP1fwqdrbRFIR6euqJ6btc2Y4jsGWM0emOWrU2FAtQRTSiid7n9EJtkQCVlebrUle9lnuLVA3v09/G8diLCFxp+DVprF2a2KHqsrACtqVbQy9L8T2qq4goaKOpz5uka22Kn1yn2gBHOPMSx9o3obJokbS8R/p3txTfK918Q+2tjwrQYPcWaW6Xdj5fKkB9B2uks+v1VICYSWXQjia4eWuB8z2/0//pGMMD04yP3qFzfzXBoE3sszGmR27Tubuc3KDDsf4ZsME2iO4GjuqXQh1orxDwv1OxBsX2VQlQcWGObnzdog/3bhCg0uIHNPLFVqnf/8DlA2ctDSTgxNFnOHFgE7jAg7kQcjnS8TRgQcCiprGQzncrIZ0i/u0so7lLODlgsh6QSMNCAix8BhJJNH6b5NwyFNhwLwWuB/NxEoemudi9wMT8Cq4LBrDwgLUULK/BPR9+jC4ytPUC17/8DR6CpYEplt+eJTX7OH9HbEL5NvKwjGvj4AHprC8DSZ+/zHJgI+uI+xdvbL9E+JRLJr+Sr5LXKd8foqY8QjqN7fxzlzhaAy8LGYHnQTxJ3hNhFlptCi4XsP7PEoaD4mr4KlveeZjNG4qYvDbKyipJolCXOI70U630Y6uvRfrZzyuvSKOvavK9Kp2OFqv3zagWLzb7s21aubBZ519HFjzrg8NP8utbu2hWMIyyHpYBYwyOa2Hn2cwuJAiHAthp+e087s4n6e5LjwzeodECAKiAffk5PJLOkJKFACzLZ8B27jfMYgUM7mKSuzPwMcB/6Jh/V5xUni0AAAAASUVORK5CYII=)';
return aNode;
}
});
} catch (e) {
Components.utils.reportError(e);
};
try {
CustomizableUI.createWidget({
id: "fp-register-css-file",
defaultArea: CustomizableUI.AREA_NAVBAR,
removable: true,
label: buttonTxt_2,
tooltiptext: buttonTxt_2,
onClick: function() {
if( testFile.exists() ) {
var CI = Components.interfaces;
var CC = Components.classes;
let sss = CC["@mozilla.org/content/style-sheet-service;1"].getService( CI.nsIStyleSheetService );
let ios = CC["@mozilla.org/network/io-service;1"].getService( CI.nsIIOService );
let fileURL = Services.io.getProtocolHandler( 'file' ).QueryInterface( Ci.nsIFileProtocolHandler ).getURLSpecFromFile( testFile );
let uri = ios.newURI( fileURL , null , null );
sss.loadAndRegisterSheet( uri , sss.AGENT_SHEET );
} else {
alert( errorTxt );
}
},
onCreated: function(aNode) {
aNode.style.listStyleImage = 'url(data:image/gif;base64,R0lGODlhEAAQAPcAAAQCVISChMTCtOTizNTSxERCRAQCZJSW1MzGzNTW1Ozq7CwqdKyqlMzKxERCjMTCxNzavLy6vMzKzPz67HRypCQiJJyahAQCdOTe1CQinLy65Pz2/PT23NTSzNzW3Ly6tExGnMTGxMS+xMzK1JSWpAQCXMTGvOzmzAQCbMTC1Nza1DQ2dKyqnNTOxExOfOTezLy+vMzOzPz+7Hx+rDQyNKSehAQCfCwqlPz+/NzWzMzGxAD/AOQA2C8A6iQAEgAAAACAAAAAAAAAAAAAAAACAAAAAAAAAAAAAADMAkPpACYSAAAAAKAVCC+LACQ/AAB3AADQhADq7QASEgAAAACwTkPqACYSAAAAAOgACAcAACgACgAAAACwnADqjAASPwAAd/8CBP8AAP8AAAAAAABwAADqAAASAAAAADB6QwSBAAA/OgB3AIQSXAGSAAE/UAF3ABDUcugdABITbwB3AHQAZ40AADQAcnYAAMwIYfsCABIAbQAAAPo4X5m1jDknN3cAdlQASLoA7z8AnAAB1f4sAP/pAP8SAP8AABIAB3UAAD8AAHcAAEWEAHXtAD8SAHcAAABOAAAAEABQKAAAAACwAENDACYmAAAAAAD+AEP/ACb/AAD/AHA4AGbqAD8SAHcAADQAAAAAAAAAAMAAAAQANOoBiBIAuQAAo29l/ogm/zQ0/3Z2/wA4XwDqjCQSNwAAdgBPJQAgAAA0AAB2APhcJULqACYSAAAAAAAAoAABuwAAUAAAAGVl/yYm/zQ0/3Z2/wAAAAEAAAAAAAAAAKAYZB0A6xMAEncAAADnRgAlgyQ0TAB2AAAARAAA6wAAEgAAAKRgdwPrUCQSTwAAAEgieAEm6yQ0EgB2AA/U5wBsJQBPNAAAdh7gHQB37QBPEgAAAHQA2QEB/yQA/wAAfy1c+ADq7AASEgAAAEgAAAEBACQAAAAAAABD5wAmJQA0NAB2dg4BAAAAAAAAAAAAAAAAPAAA7wAAnAAB1Ui4GAHtFCQSKAAAAFP6AQCZLQA5SAB3ACH5BAAAAAAALAAAAAAQABAABwi3AAsEGEiwYEEaARQk8MCQ4UIPCxNsEJhABIwIGE08wAhDxAMFFB/gGCkjhkgcEwh8DEkBQIkSAkzMcPlhZYAEDwjguLCCgw4cIGrgBBnAwwMRAzKggNBCgwsVIWxWzDkCBQkcNxhIeCCV6wMZBlDgKIEhqgiiUx+8OIBiAYsOXoka5dogBQoHJhDEpejxQYgTNizk8NrVK4EcH6JyPRuyb9/FXIluUEC5smXKOArQKMC5s2fPFQICADs=)';
return aNode;
}
});
} catch (e) {
Components.utils.reportError(e);
}
})();
Alles anzeigen
Geht wohl fast hiermit:
Danke für den Tip.