OS4Welt

@ djbase
Du kannst sowas natürlich anbieten (wobei Github ja auch schon "Issuetracker" bereitstellt .. also zumindest für AmiFTP wäre der Github-Tracker vermutlich die naheliegendere Wahl), aber da ich mehr als nur AutoDocViewer in meinem Tracker habe, wird meiner dennoch bleiben müssen (gibt ja auch private Projekte dort, nicht nur die drei öffentlichen).

@ turbo4.1
In meinem Tracker oder in dem von djbase angedachten OS4Welt-Tracker? Bei mir wäre es kein Problem, mußt Dich nur registrieren und Bescheid sagen

Hier mal für Euch zum schnellen Testen ... falls nix Fatales auftritt, landet die Version später im os4depot:

AutoDocViewer 1.2

kleinigkeit:
das schubladenicon oben - man kann zu-/aufklappen. könnte man da noch die offene schublade (draweropen) anzeigen, wenn aufgeklappt?

gruß...
michael

Man sieht doch automatisch, daß aufgeklappt ist, wenn die enthaltenen AutoDocs angezeigt werden Und ist das Icon nicht eh schon viel zu klein, um wirklich einen optischen Mehrwert bei der Wiedererkennung zu haben? Natürlich kann man sich mit solchen Details verkünsteln, aber ob die wirklich sinnvoll sind?

Ich kann es mal im Hinterkopf behalten, wenn mir wirklich mal sehr langweilig ist. Aber ansonsten würde ich meine Amigazeit lieber in ertragreichere Änderungen investieren.

Nun, wenn aber sonst keine Probleme auftauchten, kann das Ding ja so ins OS4Depot ..

Nun mal nicht so schnell

1. Bei mit hat der Button mit der Lupe ? Keine Funktion, Äh kein Button hat eine Funktion.
Der Pfeil nach links, wird aber nach ein paar Klicks frei geschaltet, aber beim benutzen keine Funktion.
Aus dem Menu, geht Print

2. Im Menu, gibt es dann Search und darunter Find (Deutsch?) und Search ?

3. Es sollte nur der Path neu eingelesen werden, wenn auch Änderungen erfolgt sind,
aber es wird immer neu eingelesen, auch wenn man etwas anderes in den Prefs ändert und speichert.

JoTo hat geschrieben: ↑25. Februar 2020 22:36 1. Bei mit hat der Button mit der Lupe ? Keine Funktion, Äh kein Button hat eine Funktion.
Der Pfeil nach links, wird aber nach ein paar Klicks frei geschaltet, aber beim benutzen keine Funktion.
Aus dem Menu, geht Print

Kann ich nicht nachvollziehen. Die Buttons machen genau das, was sie machen sollen.

2. Im Menu, gibt es dann Search und darunter Find (Deutsch?) und Search ?

Ja, das hat mich auch schon immer verwirrt ... Glenn (der ursprüngliche Autor) hatte die beiden Funktionen so benannt, um sie unterscheiden zu können. Er hat sich damit wohl an den Kommandozeilenprogrammen Find und Search orientieren wollen, aber es tatsächlich irgendwie verdreht:

[*] Find sucht einen Text im gerade offenen AutoDoc
[*] Search sucht einen Text oder eine Sektion in allen Dateien oder nach einem Dateinamen

Die Suchfunktion komplett zu überarbeiten, steht schon auf meiner Todo-Liste. Ich trag das auch mal in Mantis ein ..

3. Es sollte nur der Path neu eingelesen werden, wenn auch Änderungen erfolgt sind,
aber es wird immer neu eingelesen, auch wenn man etwas anderes in den Prefs ändert und speichert.

Seufz ... wieso macht er das noch?! Ich hatte das eigentlich schon in 1.2 implementiert, deshalb steht es ja auch im Changelog ... hmpf. Seh ich mir an.

Habe es eben noch einmal getestet,

in den Versionen, 0.99, 1.0, 1.1 Funktionieren die Buttons !!!

Nur nicht mehr in der Version 1.2 !?!

WTF ... auf Update 1 funktionieren die Buttons tatsächlich nicht Ich bin dran ..

Ok, gefunden... das von mir benutzte SBNA_ButtonID tag gibt es erst in speebar_gc 53.13 und Update 1 hat 53.12 Hotfix kommt gleich ...

Edit: 1.3 ist schon in der Warteschlange vom OS4Depot. Hat aber außer dem speedbar-Fix keine Änderungen.

Ich lehne mich mal weit raus und schlage etwas Radikales vor.

Da es sich ja um einen Anzeiger für ein sehr spezifisches Dokumentformat handelt (auch wenn es nur Text ist), warum dann nicht ALL-IN und gleich richtig?
(ich ignoriere hier mal die anderen Formate, da ich sie noch nicht gesehen habe. Alles ist ASCII hier bei mir.)

Was wir hier sehen:
Wie oben schon angedeutet, es ist ja wohl zu 99% .doc, also filtern wir das raus und machen eine Mappe ála .doc.
Die AutoDocs haben ein spezifisches Format, also macht es eigentlich keinen Sinn, sie als gewöhnliche Texte zu betrachten. Stattdessen parsen wir, was sie hergeben.
z.B. das Inhaltsverzeichnis.
Alle Subs werden oben in der Liste angezeigt, bei Klick darin wird dann zu der Stelle gesprungen.
(Machst du ja schon, nur eben nicht konsequent.)
Hier können wir gleich alles entfernen, was redundant ist, also der Name des docs (dos.library/ usw.).
(Jeder Eintrag könnte auch gleich den jeweiligen Text vom NAME oder SYNOPSIS Part hintendran oder als Tooltip Bubble haben)
Der eigentliche View ist ein vollwertiger Texteditor, sodaß man ein bißchen rumeditieren kann, und dann macht man Copy&Paste oder druckt es aus.
Der Textview selbst (oder: TreeView, ListView osä.) würde es gestatten, einzelne Teile des Docs auszublenden.
Man kann in meinem Beispiel hier die "Fold"-Optionen sehen:
Die einzelnen Unterkategorien würde man ausblenden (können), und so würde man sich durch die Inhaltsliste klicken (können), und immer das Wichtige sehen, nicht den Anfang eines Textfiles.
Alternativ könnte der Viewer auch alle (auswählbar) Segmente (also: Example/Bugs/Function...) immer als einzelne Tabs anbieten. Habe ich gerade kein Beispielbild da, weil ich es z.Zt. suboptimal finde. Ist das was, worüber man diskutieren könnte?

Sicher könnte man auch z.B. alle Subs des Docs gleich in den Datei-Baum als Nodes integrieren, aber, das wäre vielleicht auch nicht soo toll.

Sorry für das Win32 Beispiel, aber , eh, Tabor.....