ein wunsch an den autor fuer die version 7.5

[JustAnotherTCUser]

mein plugin legt die farbe der files nur einmal, und zwar beim eintritt in ein verzeichnis fest.

genau dann werden _alle_ mp3-files innerhalb eines verzeichnisses miteinander verglichen (deren album-tag). das bool-ergebnis wird mit dem pfad des verzeichnisses im plugin gepuffert.

nun wird fuer jedes file die farbe vom TC abgefragt. da liefere ich bei allen weiteren abfragen der anderen mp3-files den zuerst ermittelten bool-wert zurueck. denn diese eine true/false-value trifft immer auf _alle_ mp3-files eines verzeichnisses zu. die ermittlung der farbe findet deshalb logischerweise nur einmal statt. und eben dieser zeitpunkt ist der wechsel in ein 'neues" verzeichnis. und den bekomme ich eben nicht immer mit...

wuerde ich diesen vergleich bei der farb-abfrage von TC _jedesmal erneut_ durchfuehren, dann wuerde es gehen. nur waere das grauenhaft langsam, da statt n files pro verzeichnis n*n files pro verzeichnis geoeffnet und gelesen werden muessten...

[HolgerK]

...das bool-ergebnis wird mit dem pfad des verzeichnisses im plugin gepuffert.
....
wuerde ich diesen vergleich bei der farb-abfrage von TC _jedesmal erneut_ durchfuehren, dann wuerde es gehen. nur waere das grauenhaft langsam, da statt n files pro verzeichnis n*n files pro verzeichnis geoeffnet und gelesen werden muessten...

Hallo?!?
- Die erste Abfrage zu einem File, das nicht in dem gepufferten Verzeichnis liegt....

Ist das nicht vielleicht der Trigger den du suchst?

Gruß
Holger

[JustAnotherTCUser]

- Die erste Abfrage zu einem File, das nicht in dem gepufferten Verzeichnis liegt....

Ist das nicht vielleicht der Trigger den du suchst?

ob du's glaubst oder nicht: ich ahnte dass genau dieser einwand noch kommt! *g*

ich hab es ja schon so implementiert. aber eben _das_ funzt nicht 100%ig! kann es nicht!

beispiel:

dir x:\mp3 enhaelt nur unterverzeichnisse und kein einziges mp3

dir x:\mp3\hoerbuch1, dir x:\mp3\hoerbuch2 usw. liegen darunter und enthalten mp3-files.

wenn ich nun aus x:\mp3\hoerbuch1 eine ebene hoeher wechsle wird mir das _nicht!_ mitgeteilt (da kein mp3-file hier). wechsel ich wiederum in das unterverzeichnis wird mir das nur mitgeteilt, wenn ich in der ansicht in mindestens einer spalte einen wert des plugins anzeige.

bei einem neuerlichen wechsel in hoerbuch1 aus einer ebene hoeher werden also wieder die mp3-files einzeln ans plugin uebergeben, inkl. pfad, aber der ist der selbe wie bei der letzten abfrage im selben verzeichnis beim ersten 'besuch'. ich bekomme den verzeichniswechsel nicht immer mit!

ich geh sogar noch nen schritt weiter: ich puffere alle files eines directories inkl. pfaden und anderen mp3-infos. wird dann im folgenden ein file eines pfades abgefragt welches _nicht_ zum zuletzt gespeicherten dir gehoert, wird ebenfalls ein erneuter vergleich angestossen und die interne liste neu aufgebaut. ich glaub _noch_ naeher kommt man an mein ziel nicht dran, es sei denn, h. ghisler wuerde diese schnittstelle erweitern

bei einem reload eines verzeichnisses funzt es auch nicht so wie gewuenscht. da eben auch nur wieder an der ansicht beteiligte plugins informiert werden.

waere im beispiel oben im verzeichnis x:\mp3 mindestens _ein_ mp3-file enthalten, dann wuerde es auch mein plugin erkennen dass ein wechsel stattgefunden hat. so meintest du es wohl.

und ausserdem sollte mein plugin die farbe unabhaengig von der ansicht ermitteln koennen...

[HolgerK]

... bei einem neuerlichen wechsel in hoerbuch1 aus einer ebene hoeher werden also wieder die mp3-files einzeln ans plugin uebergeben, inkl. pfad, aber der ist der selbe wie bei der letzten abfrage im selben verzeichnis beim ersten 'besuch'. ich bekomme den verzeichniswechsel nicht immer mit!

Na und. Der Cache ist doch dann immer noch gültig und das Einfärben erfolgt wie beim ersten Besuch des Verzeichnisses.

bei einem reload eines verzeichnisses funzt es auch nicht so wie gewuenscht. da eben auch nur wieder an der ansicht beteiligte plugins informiert werden.

Cache immer noch gültig!
Wenn nicht (z.B. ein Tag hat sich im gecachten Verzeichnis geändert) dann sind deine Kriterien für Überprüfung der Cache-Konsitenz noch nicht ausreichend.

waere im beispiel oben im verzeichnis x:\mp3 mindestens _ein_ mp3-file enthalten, dann wuerde es auch mein plugin erkennen dass ein wechsel stattgefunden hat. so meintest du es wohl.

Cache ungültig -> Neu einlesen:
Die (mindestens) eine Datei im Vaterverzeichnis möchte ja auch gefärbt werden.

und ausserdem sollte mein plugin die farbe unabhaengig von der ansicht ermitteln koennen...

Und genau das bekommst du mit deinem Wunsch nicht hin:

Suchergebnisse <Alt+F7> nach Namen sortiert?

Branch view <Ctrl+B>?

Einmal das linke, einmal das rechte Panel aktiviert/refresht?

Ist das hin- und herschalten zwischen Tabs auch ein Verzeichniswechsel?

Fragen über Fragen, über die du noch stolpern wirst und dazu passende Antworten finden musst.

Ob das von dir Gewünschte diese Probleme lösen würde, glaube ich nicht.

Gruß
Holger

[JustAnotherTCUser]

... bei einem neuerlichen wechsel in hoerbuch1 aus einer ebene hoeher werden also wieder die mp3-files einzeln ans plugin uebergeben, inkl. pfad, aber der ist der selbe wie bei der letzten abfrage im selben verzeichnis beim ersten 'besuch'. ich bekomme den verzeichniswechsel nicht immer mit!

Na und. Der Cache ist doch dann immer noch gültig und das Einfärben erfolgt wie beim ersten Besuch des Verzeichnisses.

woher weisst du dass der cache noch gueltig ist?!?

wenn ich die album-tags der files aendere oder dateien ersetze oder was weiss ich, dann wird das nicht erkannt! (wenn ich im verzeichnis bin und tc dann ne tag-aenderung nicht mitbekommt, damit kann ich leben. selbst mit nem reload klappts da nicht (wegen der evtl. farbaenderung der files, TC ueberprueft die farbgebung beim reload nicht, soweit ich mich entsinne)

waere im beispiel oben im verzeichnis x:\mp3 mindestens _ein_ mp3-file enthalten, dann wuerde es auch mein plugin erkennen dass ein wechsel stattgefunden hat. so meintest du es wohl.

Cache ungültig -> Neu einlesen:
Die (mindestens) eine Datei im Vaterverzeichnis möchte ja auch gefärbt werden.

wenn im vaterverzeichnis _kein_ mp3-file ist, dann gehts nicht. steht ja auch da...

was die unabhaengigkeit der ansicht angeht: mir genuegt die lange ansicht in einem der panels. wenn man mein ziel der uebung verstanden hat, dann ergibt sich, dass ich auf andere spezialitaeten zu meinem zweck nicht angewiesen bin.

man kann _alles_ zerreden, wenn man sich nur genug muehe dazu gibt *g*

in der zeit in der man so nen wunsch (ungerechtfertigt) "auseinandernimmt" kann man so ne kleine aenderung leicht & locker implementieren. wer die funktion dann benutzen moechte, kann es, wer es in frage stellen will, kann es auch!

ich fuer meinen teil haette _mehr_ als eine sinnvolle anwendung dafuer

Ob das von dir Gewünschte diese Probleme lösen würde, glaube ich nicht.

das musst du auch nicht glauben. ich _weiss_ dass es mein 'problem' loest.

fuer glaubensfragen sind wir wohl auch nicht im richtigen forum... *g*.

gruss

[HolgerK]

woher weisst du dass der cache noch gueltig ist?!?

Dein Plugin muss es wissen. Nicht ich.
Das meinte ich mit unzureichenden Kriterien zur Überprüfung der Cache-Konsitenz

wenn ich die album-tags der files aendere oder dateien ersetze oder was weiss ich, dann wird das nicht erkannt! (wenn ich im verzeichnis bin und tc dann ne tag-aenderung nicht mitbekommt, damit kann ich leben. selbst mit nem reload klappts da nicht (wegen der evtl. farbaenderung der files, TC ueberprueft die farbgebung beim reload nicht, soweit ich mich entsinne)

Aha, und dein Workaround ist dann, dass der Benutzer einmal aus dem Verzeichnis raus und dann wieder rein geht, um den Cache als ungültig zu erklären?

wenn im vaterverzeichnis _kein_ mp3-file ist, dann gehts nicht. steht ja auch da...

Die Frage, die du hier beantworten solltest, ist, ob es notwendig ist in diesem Fall den Cache zu invalidieren?

was die unabhaengigkeit der ansicht angeht: mir genuegt die lange ansicht in einem der panels. wenn man mein ziel der uebung verstanden hat, dann ergibt sich, dass ich auf andere spezialitaeten zu meinem zweck nicht angewiesen bin.

Egoist

man kann _alles_ zerreden, wenn man sich nur genug muehe dazu gibt *g*

Ich gebe mir Mühe, dir zu helfen dein Problem zu verstehen und selbständig zu lösen.

in der zeit in der man so nen wunsch (ungerechtfertigt) "auseinandernimmt" kann man so ne kleine aenderung leicht & locker implementieren. wer die funktion dann benutzen moechte, kann es, wer es in frage stellen will, kann es auch!

Du hast keine Ahnung von professioneller Softwareentwicklung (ich sage jetzt bewusst nicht, dass ich das glaube).
"Machen wir doch mal einfach" führt zu einem Wirrwar von unspezifischen Interfaces die dokumentiert und gepflegt werden müssen.
Rapid Prototyping kannst du zuhause an deinem PC betreiben, aber bitte nicht mit einem Produkt, das millionenfach im Einsatz ist.

ich fuer meinen teil haette _mehr_ als eine sinnvolle anwendung dafuer

Anscheinend, hast du noch niemanden sonst davon überzeugen können.

das musst du auch nicht glauben. ich _weiss_ dass es mein 'problem' loest.

Wäre es dir lieber, wenn ich sage würde das ich das weiß?

fuer glaubensfragen sind wir wohl auch nicht im richtigen forum... *g*.

Nein, um uns gegenseitig zu helfen, und manchmal auch Meinungen zu äußern.

Gruß
Holger

[JustAnotherTCUser]

mit deiner aussage dass ich mit professioneller software-entwicklung wenig zu tun und davon keine ahnung habe, da muss ich dich nun enttaeuschen, holger.
ich bin anwendungsentwickler und betreibe das programmieren darueberhinaus schon seit rund 25 jahren.

deshalb kann ich den aufwand um die bereits bestehende schnittstelle etwas zu erweitern recht gut einschaetzen.

entweder es wird meinetwegen eben jedes, oder aber nur inhalts-plugins, konsequent mitgeteilt (es gibt ja ne funktion, welche man nur um parameter erweitern muss, welche diverse infos uebermitteln kann. die infos werden dann nur in plugins angenommen, die von diesen infos gebrauch machen moechten, die andern ignorieren diese einfach. also besteht keine notwendigkeit bestehende plugis zu aendern.

und zur beschreibung, das sind zwei bis 3 saetze zur funktion der jeweiligen schnittstellenfunktion.

ich will doch keine voellig _neue_ schnittstelle wo's anfangs immer wieder mal klemmt und so.
das geruest dazu ist doch schon voll implementiert!

der aufwand das zu implementieren (und die aenderung des schnittstellen-hlp-files) sind sicher in einer stunde sorgfaeltig zu erledigen. das framework fuer die TC zu plugin-schnittstelle besteht ja bereits und wird um ein bis zwei laeppische funktionen erweitert. und wenn man generell jedes plugin ueber die aenderung informiert, ist es noch einfacher und schneller zu implementieren. auch wenn es viele plugins nicht braeuchten. der funktionsaufruf geht dann halt ins leere.

es waer schoen wenn sich herr ghisler dazu mal aeussern wuerde:

hauptwunsch um einige neue moeglichkeiten zu eroeffnen ist der:

entweder _jedem_ geladenen inhaltsplugin _jeden_ verzeichniswechsel mitteilen. unabhaengig ob es bei aktueller ansicht beteiligt ist oder nicht,
oder aber:
beim laden aller plugins fragen, ob sie denn _jeden_ verzeichniswechsel erfahren moechten.

und schon lassen sich (neben meinem mp3-albumtag-plugin) viele weitere schoene verzeichnisabhaengige ansichten basteln!

nochmal die explizite bitte an ch. ghisler das einzubauen!

[HolgerK]

bisher ist es eben so, dass ich das immer von hand switchen muss. und da kommts dann oft vor dass ich das aus bequemlichkeit sein lasse und die, in diesen faellen, unguenstigere normalansicht verwende, die ich i.d.r. auch sonst verwende.

und mein spezielles mp3-plugin wird weiterhin nicht so funktionieren wie gewuenscht. denn so hab ich's nicht in der hand...

Aha, und dein Workaround ist dann, dass der Benutzer einmal aus dem Verzeichnis raus und dann wieder rein geht, um den Cache als ungültig zu erklären?

Und du bist sicher, dass die von dir gewünschte Erweiterung, dein (händisches) Problem lösen würde?

was die unabhaengigkeit der ansicht angeht: mir genuegt die lange ansicht in einem der panels. wenn man mein ziel der uebung verstanden hat, dann ergibt sich, dass ich auf andere spezialitaeten zu meinem zweck nicht angewiesen bin.

Könnte es sein das du übersiehst, dass andere Pluginentwickler da vielleicht ein etwas stimmigeres Konzept erwarten?
Aber wenn du willst halte ich mich ab jetzt da raus (ich habe bis jetzt noch kein Content Plugin geschrieben).

Gruß
Holger

PS 25 Jahre können mich nicht abschrecken. Da halte ich noch locker mit.

[Lefteous]

Der Total Commander verfolgt mit jedem Plugintyp ein bestimmtes Ziel:
- Inhaltsplugins: Einen Wert zu einer Datei ermitteln
- Listerplugins: Eine Vorschau einer Datei
- Packerplugins: Hierarchische Strukturen (Dateisystem) in einer Datei anzeigen und erstellen
- Dateisystemplugins: Andere (virtuelle) Dateisysteme oder Servertypen anzeigen

Wo würde das reinpassen? So wie ich deinen Vorschlag verstanden habe, passt er nicht in eines der bestehenden Pluginsysteme.

[JustAnotherTCUser]

eindeutig das inhalts-plugin!

es geht ja um den inhalt von mp3-files.
oder eben einen verzeichnisabhaengigen ansichtswechsel.


btw: gibts eigentlich ne moeglich die aktuelle sortierung einer ansicht zu erfahren. programmatisch meine ich. bei einem befehl cm_SrcByName kann man ja nicht angeben ob auf oder absteigend sortiert werden soll.

[Lefteous]

und welche Felder hätte dann dieses Plugin?

[JustAnotherTCUser]

bei mir bietet es einige mp3-tags an.

hauptaufgabe meines speziellen plugins ist aber, eine von 2 farben zu ermitteln. die eine wenn album-tags eines verzeichnisses identisch sind, die andere wenn nicht.
und um das auch dann ermitteln zu koennen, wenn kein feld meines plugins angezeigt wird, dafuer bitte ich um die info eines jeden verzeichniswechsels.
dann arbeitet mein plugin 'nur' als farbgeber fuer mp3-files. und dann auch korrekt!
es wird u.a. ein true/false in einer spalte zurueckgegeben. und dieser wert wird als farbfilter verwendet. und diese spalte moechte ich ja nicht im fenster ausgeben, das ergebnis seh ich ja an der farbe der files.

dass ich mit diesem (oder einem separaten) plugin auch auf beliebige verzeichniswechsel reagieren kann, ist der super nebeneffekt! )

[Lefteous]

2JustAnotherTCUser
So wie du es jetzt erklärt hast, sehe ich keinen zwingenden Grund solch eine Benachrichtigung zu nutzen. Es würde es zwar etwas bequemer machen, aber zwingend notwendig ist es nicht. Oder habe ich was übersehen?

[JustAnotherTCUser]

ich versuchs nochmal in kurzform (es ist eben nicht so einfach die diversen fakten kurz und knapp darzulegen):

1. mein plugin soll hauptsaechlich dazu dienen, dass die mp3-files eines verzeichnisses entweder orange oder rot angezeigt werden. dies ist abhaengig davon, ob alle mp3's eines verzeichnisses den selben album-tag haben oder nicht.

deshalb muss ich alle album-tags gegeneinander vergleichen. die farbe muss ich also bereits dann kennen, bevor der erste eintrag von TC in einem panel ausgegeben wird. das geht ueber einen farbfilter, der ein feld meines plugins abfragt. zur einwandfreien funktion ist also ein trigger notwendig, der genau beim eintritt in ein verzeichnis ausgeloest wird.
und genau _dieses_ ist eben nicht immer gewaehrleistet.
mein plugin wird nur ueber den verzeichniswechsel informiert, wenn auch die aktuelle _ansicht_ mein plugin benutzt.

2. ausserdem kann ich mir beliebige verzeichnisabhaengige aktionen programmieren, wenn denn gewehrleistet ist, dass ich _jeden_ verzeichniswechsel irgendwie 'abfangen' koennte.

ich weiss echt nicht mehr was ich noch alles anders formulieren soll, nur um diesen wunsch darzulegen...

fakt ist: es gibt keine moeglichkeit ueber _alle_ verzeichniswechsel informiert zu werden wenn ein plugin das moechte.
genau _diese_ funktion wuerde mir ermoeglichen mein plugin zu nahezu 100% so zum funktionieren zu bekommen wie ich will (derzeit muss ich halt mehrere einschraenkungen hinnehmen) und ausserdem koennte man wunderbar absolut beliebige verzeichnisabhaengige aktionen ausloesen. hab ich ja bereits mal geschrieben.

derzeit gibt es nur dieses script (siehe anderen beitrag), eine ziemliche kruecke...
und das wurde vermutlich im wiki aufgenommen weil bedarf dafuer besteht.

es gibt bestimmt jede menge TC-nutzer die verzeichnisabhaengige aktionen nur so begruessen wuerden!!
und genau _die_ koennte man dann ueber plugins wunderbar einbauen! fuer den autor ist es ne kleinigkeit diese funktionen zur bestehenden schnittstelle hinzuzufuegen, fuer alle nutzer die das schon laenger moechten, wuerde das einen moeglichen loesungsweg eroeffnen. alles weitere bastelt man in ein plugin.

ich weiss echt nicht mehr wie ich den wunsch und den nutzen so einer kleinigkeit noch weiter hin und her formulieren soll...

wenns mein plugin und der quellcode sein darf.... bitte! was aber wie geht oder nicht geht steht alles schon mehrfach da.

den wunsch der "verzeichnisabhaengigen funktionen" muss man jetzt auch nicht mehr in allen varianten ausbreiten. wenn ich an _jeden_ verzeichniswechsel komme, dann ist da alles offen. ohne weitere arbeit des autors... (es sei denn man baut spaeter noch etwas luxus dazu ein).

[JustAnotherTCUser]

mein wunsch erfordert einen recht geringen aufwand.

dadurch koennte man, ohne eine aufwendige implementierung im TC selbst, als plugin-schreiber viele wuensche erfuellen. die duskussion scheint ja schon aelter zu sein... dabei koennts recht einfach sein und die nutzer wuerden sich freuen:

http://www.ghisler.ch/board/viewtopic.php?p=66775
http://www.ghisler.ch/board/viewtopic.php?p=112240
http://www.ghisler.ch/board/viewtopic.php?t=14890
http://www.ghisler.ch/board/viewtopic.php?t=18498
http://www.ghisler.ch/board/viewtopic.php?t=13941

"kommandos" an TC senden, sie also in einem plugin oder script an tc zu uebermitteln klappt ja ganz gut. nur der trigger fehlt...