Notizen zum FreeCommanderXE 0.0.0.528

Hans Bauer

treuer Stammgast
Nachfolgend ein paar Anmerkungen, die mir beim Testen der neuen Version aufgefallen sind. Ich hoffe, ich kann damit ein wenig zur weiteren positiven Entwicklung beitragen:

1.) Wenn man den FreeCommanderXE schließt und sich gerade in einem Unterordner eines Tabs mit "Lock - navigation to subfolders" befindet, dann wird bei einem Neustart des FreeCommmanderXE ein neuer Tab mit ebendiesem Unterordner geöffnet und aktiviert. Ich fände es besser, wenn man sich im entsprechenden Unterordner des 'alten' Tabs wiederfände.

2.) Wenn man sich in einem Unterordner eines Tabs mit "Lock - navigation to subfolders" befindet, zu einem anderen Tab wechselt und dann wieder in den vorherigen Tab zurückkehrt, dann findet man sich dort im obersten Verzeichnis des Tabs wieder. Ich fände es besser, wenn man wieder in dem zuvor genutzten Unterordner wäre.

3.) Wenn bei den Einstellungen für "Drives" die "Show occupied space progress bar" aktiviert ist und die Drivebar gleichzeitig für beide Panels gilt (no drivebar per panel), dann führt bei mir (Win7x64) eine Vergrößerung/Verkleinerung des FreeCommanderXE-Programmfensters mit der Maus zu einer sehr unruhigen Darstellung: Die Tabs und Panels scheinen dabei zu hüpfen.

4.) Und noch eine winzige Kleinigkeit: Ich nutze Bildschirme mit einer relativ feinen Auflösung. Die neuen Icons für "Pack" und "Unpack" sind zwar sehr schön, aber ich kann darauf nur mühsam erkennen, ob der Pfeil nach oben (->unzip) oder unten (->zip) zeigt. Das war bei den 'alten' Icons deutlich einfacher zu sehen.

5.) Ansonsten hat die Version 0.0.0.528 nach meinem Eindruck einen Riesensprung in Richtung Stabilität und Zuverlässigkeit gemacht.

@Marek: Für Deine große Mühe bei der Entwicklung dieser neuen Version möchte ich mich hier ganz herzlich bedanken. Ich glaube das wird ein ganz großer Wurf. :)
 
Zuletzt bearbeitet:
ad 2.)

Das würde meiner Meinung nach dem Sperr-Prinzip widersprechen. Es geht doch genau darum, dass genau ein bestimmter Ordner geöffnet bleibt, und "navigation enabled" bzw. "navigation to subfolders" ermöglichen eben nur die Navigation. Was wäre der Unterschied zu einem gewöhnlichen Tab, wenn man bei einem gesperrten Tab mit "navigation enabled" auch zum zuletzt benutzten Ordner zurückkehren würde?
 
ad 2.)
Das würde meiner Meinung nach dem Sperr-Prinzip widersprechen.
Das verstehe ich nicht, vielleicht reden wir auch aneinander vorbei. Ich versuche meine Intention deshalb anhand meiner Nutzung zu erläutern:

Bei mir stehen die gesperrten Tabs für einzelne Projekte. Jedes Projekt liegt in einem eigenen Verzeichnis und hat seinerseits Unterordner über teilweise mehrere Ebenen z.B. für ein-/ausgehenden Schriftverkehr, Zeichnungen, etc. Ein gesperrter Tab bezieht sich deshalb stets auf das oberste Verzeichnis eines Projekts und erlaubt eine Navigation in dessen Unterordner.

Wenn ich nun z.B. gerade dabei bin Zeichnungen zu erstellen und mehrfach zwischen den Zeichnungsverzeichnissen unterschiedlicher Projekte wechseln muss, dann muss ich mich bei jedem Tabwechsel stets auch wieder in das entsprechende Unterverzeichnis durchklicken, weil ja bei jedem Tabwechsel das jeweils oberste Verzeichnis des Projekts aktiviert wird. Dieses Durchklicken ist auf Dauer etwas lästig...

Wird es jetzt etwas deutlicher? Ich sehe darin keinen Widerspruch zum Sperrprinzip.
 
Zuletzt bearbeitet:
Ich sehe darin keinen Widerspruch zum Sperrprinzip.
Ich muss da Hannes Recht geben, "Navigation in die Unterordner" kann ja auch in den 27. verschachtelten Unterordner bedeuten. Wenn beim nächsten Start dann diese Unterordner wieder aufgehen würde, wird eben nicht der eigentlich eingestellte Tab wieder geöffnet, sondern ein ganz anderer.

Wenn dann bei einem Neustart des FreeCommmanderXE ein neuer Tab mit ebendiesem Unterordner geöffnet wird ist das doch genau hilfreich, um ihn wieder zur Verfügung zu haben.

Wenn Du einen Unterordner häufig benutzt, kannst Du den ja auch schon vorher aus dem Tree auf die Tableiste ziehen und hast ihn direkt im Zugriff.
 
Wenn beim nächsten Start dann diese Unterordner wieder aufgehen würde, wird eben nicht der eigentlich eingestellte Tab wieder geöffnet, sondern ein ganz anderer.
Wenn Du zum obersten Order des Tabs gehen willst, dann gibt es im FreeCommanderXE im Kontextmenü der Tabs die Option "Go to locked path". Ich finde, dass die Option "Navigation to Subfolder" die Nutzung eines Teilbaums des Gesamtverzeichnisses beschreibt und leite daraus nicht unbedingt eine hervorgehobene Stellung des obersten Verzeichnis des Teilbaumes ab. Vielleicht bin ich mit meinem Nutzungsverhalten ja auch nur eine Ausnahme und wir diskutieren hier schon politisch :)

Wenn Du einen Unterordner häufig benutzt, kannst Du den ja auch schon vorher aus dem Tree auf die Tableiste ziehen und hast ihn direkt im Zugriff.
Entsprechend meinem vorstehend gegebenen Beispiel wäre das nicht nur ein häufig genutztes (Zeichnungs-)Verzeichnis, sondern es wären gleichzeitig die Zeichnungsverzeichnisse mehrerer Projekte. Mit dieser Interpretation wäre für mich die Sinnhaftigkeit der Zuordnung von Tabs zu einzelnen Projekten (wie zuvor beschrieben) nicht mehr gegeben und ich müsste mir je Aufgabenstellung neue und nur dafür zugeschnittene Tabs anlegen.

----------

Mir scheint, es gibt für den FreeCommander sehr unterschiedliche Arten der Nutzung. Das spricht für das Programm und für Marek. (y)

Vielleicht wäre ja auch eine Option in "Einstellungen" möglich, die entweder das oberste Verzeichnis eines Teilbaums oder das zuletzt verwendete Verzeichnis als "Default" vorgibt. Es lebe das SOWOHL als AUCH :)
 
Wenn jeweils das zuletzt benutzte Verzeichnis jedes Tabs wieder aufgerufen werden soll, bräuchtest Du den Tab gar nicht zu sperren.
Dann hast Du genau das gewünschte Verhalten.
Automatisches Löschen nicht gesperrter Tabs in den Einstellungen natürlich vorausgesetzt.


Für mich hat das Sperren von Tabs den Sinn, dass ich mich bei jedem Programmstart in einer fest definierten Arbeitsumgebung befinde.
Nicht gesperrte Tabs werden beim Schließen automatisch gelöscht.
Wenn ich während einer Sitzung ein oder mehrere Verzeichnisse öfter brauche, ziehe ich sie einfach auf die Tableiste und habe sie bis zum Schließen der Sitzung zur Verfügung.

Gegen eine zusätzliche Option hätte ich auch nichts, ich denke das wäre aber erst mal was für die Weiterentwicklung des noch nicht fertigen FreeCommanderXE.
 
Wenn jeweils das zuletzt benutzte Verzeichnis jedes Tabs wieder aufgerufen werden soll, bräuchtest Du den Tab gar nicht zu sperren.

Genau das meinte ich. Die Sperre ist dazu da, um immer im gesperrten Verzeichnis zu bleiben. Die verschiedenen Optionen (Unterordner, Navigation ermöglicht), dienen nur dazu, dass nicht bei jedem Verzeichniswechsel sofort ein neuer Tab geöffnet wird, das Verzeichnis aber dennoch wiederhergestellt wird.

Was du jetzt suchst, ist eben nur diese Option ohne die Sperre selbst. Deshalb habe ich das als empfohlenes Standard-Verhalten bei Sperrung eines Tabs abgelehnt.
 
Hallo ralfso sowie Hannes Rannes und Danke für die Klarstellung,

genau da sind wir im Unterschied des Nutzerverhaltens:
Wenn jeweils das zuletzt benutzte Verzeichnis jedes Tabs wieder aufgerufen werden soll, bräuchtest Du den Tab gar nicht zu sperren. ... Automatisches Löschen nicht gesperrter Tabs in den Einstellungen natürlich vorausgesetzt... Für mich hat das Sperren von Tabs den Sinn, dass ich mich bei jedem Programmstart in einer fest definierten Arbeitsumgebung befinde.
Für mich hat der FreeCommander inzwischen eine ganz zentrale Rolle bei meiner freiberuflichen Arbeit eingenommen und wird bei jedem Hochfahren des Rechners automatisch geladen. Er stellt sozusagen die Schaltzentrale zu meinen aktiven Projekten und zu meiner täglichen Arbeit dar. Die gesperrten Tabs des obersten Panels zeigen mir dabei stets die aktuell in Bearbeitung befindlichen Projekte, die ich nicht täglich bei jedem Systemneustart neu einrichten möchte. Und altersgemäß bin ich inzwischen auch etwas vergesslich und will kein Projekt allein aus Dusseligkeit und Überforderung so vor sich hingammeln lassen, nur weil es dort nicht mehr steht... *vor mich hin pfeif*

Das benannte Verhalten ist mir bislang (das war ja bereits in der aktuellen und offiziellen Version 2009.02b so) auch gar nicht so furchtbar schlimm aufgefallen. Ich habe mich nur immer wieder gewundert was ich falsch gemacht habe, wenn ich einen Tab hin und her wechelte und mich dann anschließend in einem anderen Verzeichnis des Projekts (dem obersten des Tabs) wiederfand. Es war dann eben das vorgenannte Durchklicken angesagt, was ja auch lästig werden kann, wenn man überlegt, dass es ja auch anders ginge.

Deshalb mein Vorschlag bzw. meine Bitte an Marek dies als Option in den "Einstellungen" zu verankern. Dann wäre uns allen gedient. Ich will Euer Nutzerverhalten keinesfalls in Frage stellen, versteht mich bitte nicht falsch. :)
 
Fortsetzung der Notizen zur Version 0.0.0.528:

6.) Unabhängig davon, ob in den "Einstellungen->View->Tree" die Option "Splitter hot spot visible" aktiviert ist oder nicht wird beim Start des FreeCommanderXE stets dieser Splitter-hot-spot angezeigt.
 
Hallo Hans,

auch wenn ich das schon 100 mal in verschiednen Foren geschrieben habe, mache ich mich gerne damit auch weiter unbeliebt:

Wie in Fachforen üblich und zur Diskussion, Abarbeitung und Suche auch unbedingt sinnvoll, bitte pro Vorschlag, Fehlermeldung oder Disskussionspunkt immer einen neuen Thread eröffnen.
Der Threadtitel sollte immer gleich deutlich machen worum es geht.
Auch nachträgliche Änderungen des Threadtitels durch den Threadstarter mit Ergänzungen wie z.B. [Gelöst] sind sehr wilkommen.
Threads mit 60 Antworten zu 7 Themen sind zur Problemlösung für User, die die Suche verwenden nämlich absolut untauglich.

Trotzdem zum Thema:
Bei mir wird der gepunktete Schalter mit den kleinen Pfeilen wie gewünscht in den Einstellungen ein- bzw. ausgeblendet. Der kleine Abstand zum Verändern der Fensterbreiten bleibt natürlich immer sichtbar.
 
Hallo ralfso,

auch wenn Du das vielleicht nicht so gerne liest, aber der Thread war von mir eigentlich nur zur Rückmeldung von Bugs und Auffälligkeiten der aktuellen Betaversion gedacht, um damit Marek die weitere Entwicklung zu erleichtern.

Auch die unter 1.) und 2.) beschriebenen Auffälligkeiten hielt ich für Bugs, bis ich von Euch aufgeklärt wurde, dass Ihr dieses Verhalten tatsächlich als ein Feature betrachtet. Wenn Du dich noch erinnerst, hatte ich dieses Feature "Navigate to subfolders" zur Entwicklung vorgeschlagen und das genau auf die vorstehend von mir beschriebene Nutzung bezogen. Deswegen war für mich zunächst auch überhaupt nicht nachvollziehbar, dass das oberste Verzeichnis als "Default" wirken sollte und Ihr das Navigate tatsächlich nur auf die mögliche Navigation und nicht auch auf die gleichwertige Nutzung und Auswahl der Unterverzeichnisse bezieht. ;)

Für reine Bugreports und die Mitteilung von Auffälligkeiten hielt ich hier zur Vermeidung einer Threadschwemme die Auflistung in einem einzelnen Thread für sinnvoll, auch weil ich hierfür keine Unterbrechung des Aufzählcharakters durch eingeschobene Diskussionen erwartet habe. Da habe ich mich wohl kräftig getäuscht. :) Bei größeren Entwicklergruppen, bei denen noch eine nachlaufende Diskussion (z.B. wer ist zuständig, was ist zu tun,...) anspringt, hast Du sicher recht und es sollte je Fehler ein Thread eröffnet werden. Aber kein Problem, dann gibt es eben ab jetzt pro Bug/Auffälligkeit einen neuen Thread - einverstanden.

Wenn Du meine früheren Threads liest, dann wirst Du feststellen, dass ich für Verbesserungsvorschläge und Wünsche, bei denen tatsächlich eine Diskussion zu erwarten war, die von Dir empfohlene Vorgehensweise gewählt habe.

Aber wenn wir schon dabei sind: Auch bei mir lässt sich der Splitter-hot-spot wie gewünscht in den Einstellungen ein- und ausblenden. Nur unmittelbar nach dem Programmstart ist er stets sichtbar, unabhängig von den zuvor gemachten Einstellungen.
 
Zuletzt bearbeitet:
Oben