Beiträge von Thomas S.

Das mit First... und auch mit einer Positionierung an einem anderen Button hatte ich bereits vor Wochen hier gepostet...

Zur Klarstellung: es geht um die Position nach händischer Verschiebung.

Die, die nach Restart auch mal weg ist.

MSFreak

Danke dafür - aber das wollte ich nicht zum wiederholten Male lesen.

Die Frage ging direkt an den Threadersteller...

Wohin das Setup schreibt, ist eher kosmetischer Natur.

Der Programmcode wird dann garantiert nicht von 64 auf 32 "verändert".

Wenn Du ganz gezielt bestimmte Versionen haben willst, kannst Du Dir diese hier auswählen:

http://ftp.mozilla.org/pub/thunderbird/releases/

Zitat von hwww

Thunderbid 68.2.2 64bit Portable

Woher / Quelle? Offiziell gibt es den noch nicht.

Zitat von MSFreak

bei der installierten Version ist es OK, auch ohne das AddOn Phoenity Buttons.

Nö - bei mir nicht - warum auch immer. Das es manchmal geht, ist auch bekannt. Diese Funktionalität ist sehr wackelig...

Das ist als Bug dem Entwickler bekannt und unter Revision.

Zitat von Mapenzi

Wie oder wo kann man das überprüfen? Die Frage habe ich schon mehrfach gestellt.

Ohne Kenntnis der Tiefen von TB (FF) nur indirekt über die oben geschilderten unterschiedlichen Beobachtungen. Ich habe noch nicht einmal heraus gefunden, wo die Positionen der Buttons gespeichert werden (habe schnell aufgegeben, danach zu suchen).

Und genau das ist ja das Problem. Trotz tagelanger Recherche im www habe ich keine Referenz zu diversen Funktionsaufrufen gefunden, die meiner Meinung nach den Begriff Referenz verdient.

Früher war alles besser

Ich kenne noch dicke Printmedien (die nannte man Bücher), in denen das Windows API haarklein beschrieben war - mit allen Funktionen, Parametern und den Besonderheiten der Deklarationen.

Heute wird lieber am Code geschraubt und experimentiert, habe ich den Eindruck. Dokumentation kostet halt Zeit - und die wird gerne eingespart.

Mapenzi

Nicht alles in einen Topf werfen, bitte.

Im Werkzeugkasten werden Stile verändert. Das funktioniert auch über CSS und ein Cache ist nicht zu leeren.

User-Scripte, die in TB 68.x laufen, werden nach meinen Beobachtungen anders geldaden als in FF.

Ebenso werden die User-Buttons aus diesen Scripten anders erzeugt und eingebunden als in FF.

Ist gar nicht miteinander zu vergleichen.

Ich kann nur bestätigen, das dieses Script zum Restarten funktioniert, und zwar mit normalem Click nur als Restart, mit Mausrad-(Mittel-)-click mit Leeren des JS-Cache. Das Script ist hier im Forum in verschiedenen Varianten mit marginalen Änderungen veröffentlicht worden:

//RestartThunderbird.uc.js

"use strict";
(function() {

    if (location != 'chrome://messenger/content/messenger.xul') return;



    // Toolbar
    var newtoolbarbutton = document.createElement('toolbarbutton');
    var currentProfileDirectory = Services.dirsvc.get("ProfD", Ci.nsIFile).path.replace(/\\/g, "/");
    var buttonicon = "restart.png"
    var props = {
        id: 'restartThunderbird-button',
        label: 'Neustart',
        tooltiptext: 'Neustart (Mittelklick leert userChrome.js-Cache)',

        style: 'list-style-image: url("' + ("file:" + currentProfileDirectory + "/chrome/icons/" + buttonicon) + '");',

        class: 'toolbarbutton-1',
        onclick:
        'if (event.button == 1) { \
            event.preventDefault(); \
            Cc["@mozilla.org/xre/app-info;1"].getService(Ci.nsIXULRuntime).invalidateCachesOnRestart(); \
        }; \
        if (event.button == 0 || event.button == 1) { \
            BrowserUtils.restartApplication(); \
        };'
    };

    for (var p in props) newtoolbarbutton.setAttribute(p, props[p]);

    var toolbox = document.getElementById("mail-toolbox");
    toolbox.palette.appendChild(newtoolbarbutton);

    var toolbar = document.getElementById("mail-bar3");
    toolbar.insertItem("restartThunderbird-button", toolbar.lastChild);



    // Menü-Datei (FilePopup)
    var newmenuitem = document.createElement('menuitem');
    var props = {
        id: 'restartThunderbird-popupButton',
        label: 'Neustart',
        tooltiptext: 'Neustart (Mittelklick leert userChrome.js-Cache)',
        style: 'list-style-image: url("' + ("file:" + currentProfileDirectory + "/chrome/icons/" + buttonicon) + '");',
        class: 'menuitem-iconic',
        onclick:
        'if (event.button == 1) { \
            event.preventDefault(); \
            Cc["@mozilla.org/xre/app-info;1"].getService(Ci.nsIXULRuntime).invalidateCachesOnRestart(); \
        }; \
        if (event.button == 0 || event.button == 1) { \
            BrowserUtils.restartApplication(); \
        };'
    };

    for (var p in props) newmenuitem.setAttribute(p, props[p]);

    var popup = document.getElementById('menu_FilePopup')
    popup.insertBefore(newmenuitem, document.getElementById('menu_FileQuitItem'));

})();

Darin enthalten ist der Befehl Cc["@mozilla.org/xre/app-info;1"].getService(Ci.nsIXULRuntime).invalidateCachesOnRestart();, was den JS-Cache verwirft.

Folgendes Verhalten beobachte ich:

1. normales Beenden (Schließen) von TB und späteres neu Starten, ggf. auch nach Reboot des PC: alles Normal wie eingerichtet, Buttonpositionen wie gewünscht.

2. Restart, egal ob über Script oben oder über bereits vorhandene Befehle in TB (z.B. nach Update) verursacht bereits einen Verlust der User-Buttonpositionen (die per User-Script erzeugten). Alle User-Buttons stehen in der Toolbar-/Buttonleiste am Ende rechts. Wahrscheinlich wird beim Anlegen der Buttons die Funktion LastChild ausgeführt, ohne die bereits einmal neu gesetzte Position zu verwenden. Außerdem werden Scriptänderungen ignoriert.

3. Restart mit Mittelclick lädt geänderte Scripte neu und damit auch die Veränderungen in diesen. Ansonsten wie unter 2.

Wenn nach 2. oder 3. einmal 1. angewendet wird, sind die Buttons wieder da wo ich sie hingeschoben habe. Das Ganze ist zZ noch recht "wackelig".

Möglicherweise sind in meinen Scripten auch noch Fehler enthalten, werden die Buttons nicht richtig angelegt.

Ich bin kein Experte. Aber die JS-Konsole zeigt keine Fehler an - außer:

Hin und wieder wird beim Start von TB in dem einem oder anderen Script ein einzelnes angesprochenes Elemente als "nicht vorhanden" zurückgegeben (Rückgabewert ist "Null"), was eigentlich nur sein kann, wenn das Element (noch) nicht existieret. Seltsamerweise funktionieren auch diese Scripte inkl. dem Aufbau der Button trotzdem einwandfrei.

So etwas ist unter FF nicht zu bemerken.

ich kann auch nicht alles erklären, nur meine Beobachtungen wiedergeben.

Das Löschen des Cache ist nur notwendig, wenn man an den Scripten etwas ändert.

Ohne Löschen des Cache wird der alte Code weiter ausgeführt.

CSS-Code ist davon eigentlich nicht betroffen, die Änderungen werden immer gleich angewendet.

Die hier im Forum immer wieder eerwähnten merkwürdigen Effekte (z.B. mit der Buttonposition oder mit MSF) bei verschiedenen Arten des Neu- oder Wiederstarts sind auf Timingprobleme beim Start bestimmter TB-Versionen zurückzuführen.

Es gibt ein grundsätzliches Problem mit dem Laden von AddOns und benutzerspezifischen Scripten / Buttons.

Je nach dem, wie TB neu gestartet wird (direkter Restart nach Änderungen oder normal beendet und nach Pause neu gestartet) erscheinen die Buttons woanders bzw ist die Funktion von AddOns "eine andere". Scheint für mich ein Timingproblem zu sein, z.B. bei der Reihenfolge des Ladens von Teilen TBs.

Ggf. ist TB noch nicht vollständig geladen, dann gibt es bestimmte Elemente noch nicht, werden vom geladenen AddOn aber bereits angesprochen, was natürlich scheitert.

Dies scheint ein Bug zu sein, wird auch hier diskutiert: https://bugzilla.mozilla.org/show_bug.cgi?id=1584160

Die Auswirkungen sind sehr vielfältig und unabhängig von installierten AddOns. Allerdings wird natürlich das Timing beim Start von AddOns beeinflußt, daher hilft vielleicht Poenity Buttons.

Ich sage dazu: Abwarten...

PS: bei mir funktioniert MSF bis auf den Startordner. Linux Mint TB 68.2.x

Zitat von Manu2019

Jetzt habe ich ihn wieder geändert auf den vom Screenshot, aber es ist trotzdem kein Unterordnen da.

Das glaube ich ehrlich eher nicht. Manchmal sieht man den Baum vor Bäumen nicht...

Ich habe mich auch etwas schwerer getan mit den lokalen Ordnern, letztlich ist das aber eher eine einfache Angelegenheit - solange die Dateien noch vorhanden sind.

Workaround:

1. Lege unter "Mail" mit dem Windows Explorer einen neuen Ordner an (z.B. "Archiv").

2. Verweise in den Einstellungen der "Lokalen Ordner" in TB auf diesen neuen Ordner.

3. Schließe TB.

4. Kopiere (nicht verschieben!) alle Dateien aus dem alten Ordner (Bild oben) in den neuen Ordner.

5. Starte TB neu - das sollte es gewesen sein.

Nach der Kontrolle, ob alles wieder da ist, kannst Du den alten Ordner (Bild oben) löschen.

Mapenzi

Ich schon. Header ist doch Header.

Falls nicht:

/* Schrift Spaltenköpfe */
#threadCols {
    font-size: 20px !important;
}

/* Schrift Mail-Liste */
#threadTree {
    font-size: 20px !important;
}

Micha, sehe dir dein oben eingefügtes Bild genau an.

Datenschutz beachten!

Zitat von cmn1964

Da mir aber die Schrift in der Ansicht (z.B. Größe der Schrift der Header der aufgelisteten Mails im Posteingang etc.) zu klein ist

#msgHeaderView {
    font-size: 18px !important;
}

Das hilft...

Das geht auch noch etwas gezielter, wenn nur bestimmte Elemente angesprochen werden sollen.

Wenn man Ordner nicht braucht, kann man sie auch löschen...

Ansonsten ist der Tipp natürlich richtig, zeigt aber eigentlich auch nur, wie relatv einfach "Lokale Ordner" in TB eingebunden sind.

Der umgekehrte Weg dient der Einbindung von aus anderen Email-Clients gewonnenen Nachrichtenordnern (sofern diese kompatibel sind natürlich).

Ich habe mal gFolderTreeController.emptyTrash() gegoogled.

Um da hin zu kommen, wo diese Funktion(en) gelistet sind.

Drittes Ergebnis liefert comm-central: changeset 1089 ... - Mozilla HG

Darin steht möglicherweise das, was Du suchst...

Sehe den Code nach "trash" durch und probiere die Funktionen aus.

Auf eigene Gefahr aber! Ich wars nicht...

gFolderTreeController.emptyJunk()

Allgemeon noch eine Anmerkung. Es kann zu Problemen kommen, da im Script nicht geprüft wird, ob der Junk-Ordner gerade angezeigt wird und andere Abhängigkeiten ignoriert werden. Ob und was dann passieren kann, ist mir aber schleierhaft. So kann es z.B. harmlos sein, das ein in TB bereits vorhandener Löschbutton nicht inaktiviert wird, obwohl der Ordner leer ist, aber es kann auch schlimmer kommen. Das Script ist eben sehr simpel.

Nun ja, dann ist das möglicherweise nicht der Ordner Junk, der da angesprochen wird, sondern alle als Junk markierten Emails, die gerade gelistet werden, die auf einen Schlag weg sind. Egal in welchem Ordner man sich gerade befindet, aber nur im aktuell angezeigten Ordner eben.

Zitat von Harff182

abwarten, bis sich wieder was im Junk-Ordner einfindet

Nö. Irgendeine Email dahin kopieren...

Versuche doch mal goDoCommand("cmd_deleteJunk") anstelle gFolderTreeController.emptyTrash() im Code.

Versuch macht bekanntlich kluch.

In den Tiefen des www

Oder z.B. in einer alten Erweiterung, die das macht, was man will, im Code nachsehen.

Oder die Befehle der Funktion goDoCommand("cmd_xxx")

hier zu finden

Das Problem ist, das ich keine umfassende Referenz gefunden habe, alles setzt sich aus vielen Einzelfundstellen im www zusammen. Googlen, lesen, probieren...

Du brauchst wahrscheinlich cmd_deleteJunk, was ich nicht verwende, weil ich Junk erst liste, den Betreff ansehe und dann mit "Ordner leeren" die Junk lösche. Brauch also keinen zusätzlichen Button dafür.

Gerne, und danke für die Rückmeldung!

Zitat von NumLock

Den Stick zu überwachen, ist nicht Aufgabe der UAC.

So ist es.