atari-home.de - Foren
Software => Alternative Betriebssysteme => Thema gestartet von: HelmutK am Mi 30.01.2013, 16:16:55
-
Ja, habe ich verstanden, aber noch nicht ausprobiert. Klar ist das Redraw ein anderes Problem. Die Frage ist nur, ist das hinnehmbar so? Sicher ist es das
Klar - das ist eher eine Notlösung, die sich inzwischen quasi etabliert hat.
aufrufende Programm, das wartet. Aber muss da der Fileselector von xaaes nicht was tun, wenn er seine Grüße verändert? Wir können ja gern ein extra thread
Er könnte das was er freigibt, selber neuzeichnen, sofern das als bitmap vorher irgendwo gesichert worden ist. Das wäre aber der gesamte Bildschirm, weil er ja überall hin kann. Alle anderen Programme restaurieren aber ihren Kram selber, so dass sich da schonmal was beißt. Alles was mir spontan dazu einfällt, sind weitere Notlösungen.
Was ich mir viel eher vorstellen kann, ist, den Fileselektor nicht-modal zu machen, also so dass der Aufrufer nicht wartet, und die Kommunikation dann über events erfolgt. Dumm nur, dass das dann kein bestehendes Programm versteht ;-)
dafür aufmachen. ;) Es gibt noch mehr unschöne Effekte, wenn ich den Fileselctor verkleiner, was ich noch nie getan hab, dann werden die Filenamen bis zur Unkenntlichkeit verkürzt, aber die anderen Informationen, die erstmal weniger wichtig sind wei flags und Datum etc. werden in voller Pracht angezeigt. Sehr ungeschickt. Naja das Thema Fileselector in xaaes ist uralt.
Das stimmt auch. Leider ist das Namensfeld das einzige, das diese ...-Schreibweise kann. Ich könnte mir vorstellen, dass vom Listenfenster bei Verkleinerung was abgeschnitten wird (also nicht der Name ..). Mal gucken ...
Solange ist es ja vielleicht ein Trost, dass man immerhin die Textgröße verkleinern kann (mit Alt +/- oder diesen Buttons links unten).
-
Ich bin grad sehr glücklich, da ich durch die Diskussion gestern zum ersten mal kapiert habe das man den Fileselektor ja ändern kann. Zum ersten mal überfordert mich das Ding nicht komplett! ;)
Ein paar Fragen hab ich noch dazu:
-) kann man die Größe/Position auch über einen Reset hinaus irgendwie sichern?
-) kann man die (für mich unnötigen) Infos wie Uhrzeit, Größe/Directory, oder "Rechte" abschalten? Maximal das Datum finde ich interessant, im Fileselector aber eigentlich auch nicht.
-) die "Pfadzeile" scheint eine fixe Größe zu haben (siehe Foto)
-) Wie schwierig wären denn Icons für die ganzen Möglichkeiten einzubauen?
-
- Fenster abspeichern hab ich schon lange vor. Kommt sicher irgendwann.
- Das Format einstellbar machen auch (evtl. die einzelnen Spalten ein/ausschalten, nur Namen, aber auch nebeneinander, usw.) geplant.
- Das mit der Pfadzeile ist ein bug! Hab ich noch gar nicht bemerkt ..
- Sowas mit icons geht dann sicher auch, und auch über das Fileselektor- menu.
PS: Beim Verkleinern wird bereits rechts abgeschnitten, da sehe ich also momentan kein Problem.
-
Nach meiner nicht so ganz naiven Vorstellung, müsste es doch möglich sein, dass der Fileselector seinen eigenen Hintergrund puffert und dann halt bei Verkleinern, Verschieben etc. neuzeichnet. Das ist natürlich Speicherintensiv, aber eigentlich korrekt Dabei ist es dann egal, von welchem Programm oder desktop der Hinter/Untergrund stammt.
Natürlich nonmodaler Filemanager, das ist eine ganz andere Philosophie eines ganz anderen Desktops. Es ist das, was mir schon 30 Jahre vorschwebt. Nämlich überhaupt keinen Unterschied mehr zwischen Desktopfenstern und Fileselector. ich habe nie verstanden, warum alles immer doppelt ist und heutzutage kann ja der Filemanager von Word, KDE usw. fast genauso viel wie der Desktop, nämlich kopieren, verschieben, umbenennen etc. pp. Wenn man also konsequent d&d einsetzt, alles über Events oder threads erledigt, dann braucht man nur Programmfenster und Desktop. Beim Laden oder Speichern wird dann nicht der fileselector aufgerufen, sondern ein weiteres Desktopfenster geöffnet über das man das File auswählt. Die Übergabe erfolgt dann durch d&d oder eben durch anklicken. Ich glaube sowas kann die Desktop-Studie von Norman Feske.
-
Nach meiner nicht so ganz naiven Vorstellung, müsste es doch möglich sein, dass der Fileselector seinen eigenen Hintergrund puffert und dann halt bei Verkleinern, Verschieben etc. neuzeichnet. Das ist natürlich Speicherintensiv, aber eigentlich korrekt Dabei ist es dann egal, von welchem Programm oder desktop der Hinter/Untergrund stammt.
Das bezieht sich nur auf Fenster des aufrufenden Programms, nur die
müssen gesichert werden. Kompliziert kann das werden, wenn andere
Fenster sich über diese schieben, während der Fileselektor offen ist,
oder sich aus irgend einem anderen Grund der Hinterfrund verändert. Es
ist ja Code zum Fenster-Restaurieren seitens XaAES vorhanden, der wird
aber nie benutzt, denke ich. Vielleicht kann man da was verwenden. Evtl.
ließe sich das alles irgendwie lösen, aber so wie ich das zur Zeit
sehe, wäre das ziemlich aufwändig, und da gibt es dringendere Dinge,
als dieses veraltete modale Fileselektor-Konzept über die Zeit zu
retten.
Bei Alerts gibt's übrigens das gleiche Problem.
Natürlich nonmodaler Filemanager, das ist eine ganz andere Philosophie eines ganz anderen Desktops. Es ist das, was mir schon 30 Jahre vorschwebt. Nämlich überhaupt keinen Unterschied mehr zwischen Desktopfenstern und Fileselector. ich habe nie verstanden, warum alles immer doppelt ist und heutzutage kann ja der Filemanager von Word, KDE usw. fast genauso viel wie der Desktop, nämlich kopieren, verschieben, umbenennen etc. pp. Wenn man also konsequent d&d einsetzt, alles über Events oder threads erledigt, dann braucht man nur Programmfenster und Desktop. Beim Laden oder Speichern wird dann nicht der fileselector aufgerufen, sondern ein weiteres Desktopfenster geöffnet über das man das File auswählt. Die Übergabe erfolgt dann durch d&d oder eben durch anklicken. Ich glaube sowas kann die Desktop-Studie von Norman Foster.
Die kenn ich nicht, aber klar: Den Desktop-Fenstern fehlt praktisch nur
die Editier-Zeile, dann kann der Fileselektor wegfallen. Aber dann
müssen auch alle Programm neu geschrieben werden, oder irgend ein Trick
zwischen AES und Desktop her, und das Problem mit dem Hintergrund ist
dann immer noch nicht gelöst.
Ich selbst benutze ja eigentlich gar keinen Desktop, aber so eine Idee
hatte ich auch schon, nur umgekehrt: Den Fileselektor zum Desktop-Fenster erweitern.
Ein paar Funktionen sind ja schon drin: Umbenennen, Löschen, Angucken,
und neuer Ordner.
-
- Fenster abspeichern hab ich schon lange vor. Kommt sicher irgendwann.
Darf ich ganz dumm nachfragen? Das AES merkt sich doch bisher schon "irgendwie" welche Fenstergröße und Position ich eingestellt habe. Wo und wie passiert das? Ich stelle mir vor daß das recht einfach eigentlich nur mehr ein "schreiben auf Platte" ist, weil gespeichert wirds ja jetzt auch schon irgendwo, oder?
-
Klar kann man das so machen, das wären dann ca. 10 Zeilen Programm.
Aber:
- es sollte flexibel sein, so dass spätere Erweiterungen die Datei nicht unbrauchbar machen
- es sollte konfigurierbar sein (immer speichern, auf Nachfrage ...)
- und dann braucht man noch Sicherheitschecks, so dass die Fenster dann nicht beim Nachbarn auf dem Bildschirm landen :)
Das wird dann schon mehr plus Menueintrag und Übersetzung. Und außerdem muss ich mich gerade ausruhen, sonst macht's ja wohl keiner ;-)
-
Ich denke die fehlende Hintergrundspeicherung des fileselectors ist in alternativen vorhanden. Also z.B. Boxkite, von dem ja gesagt wird, dass er ganz gut unter Mint/Xaaes läuft, auch unter aranym und wohl auch auf der firebee, oder? Natürlich ist der ein vollständiges Programm, kann also ne Menge, aber man könnte sich da vielleicht was abgucken für xaaes. Kommt man eigentlich an die Quellen?
-
boxkite ist doch noch viel schlimmer (siehe Bild), und außerdem klaut der Tastendrücke, und scheint sich auf den ersten Blick total unsauber zu verhalten, aber Du kannst das ja gerne nehmen. Das mit dem Hintergrund-redraw geht nicht vernünftig bei modalem Fileselektor, und mit Flickschusterei fang ich jedenfalls nicht an!
-
Moderne Atari-Software scheint richtg gefählich zu sein, Signum4 frisst RAM auf, hier werden Tastendrücke geklaut, whaaa***
Auch haben will!!! ;D Wer installiuert mir das???
-
XaAES ist eh Mist!!! :P
Benutzt stattdessen MyAES! Das ist viel schöner und läuft auch runder. 8)
Andreas
P.S. Sorry. Ich wollte nur mal kurz bashen! ;D
-
Boxkite ist ein Schweineprogramm, das ist seit langem bekannt. Aber nicht das schlechteste. ;D Aber ein vernünftiger Fileselector ala Selectric wäre schon ein Gewinn für xaaes. Schade, dass das mit dem Hintergrund in modalen Dialogen nicht sauber geht. :(
-
@oneSTone o2o: Pass bloß auf, sonst klau ich Dir noch was ganz anderes!
@ Nervengift: Herzlichen Dank, ohne Deine wertvollen Beiträge wüsste bestimmt keiner, dass MyAES viel besser ist - vor allem der Fileselektor.
@Goli: Stimmt: Für ein Schweineprogramm ist boxkite ganz gut, aber trotzdem ..
Kann denn selectric die Fenster des Aufrufers in jeder Situation restaurieren? Das geht nie im Leben!
Natürlich ist beim XaAES-FS noch viel zu verbessern, und das Fileselektor-Protokoll ist eines der Langfristziele, hat aber bestimmt nicht höchste Priorität. Ich hab inzwischen immerhin die Textbeschneidung etwas verbessert, kommt am WE ins CVS, voraussichtlich:
-
Ich hab gerade unter windows mal bei einem java-Programm rumprobiert: Sobald der Fileselktor aufgerufen wird, werden alle Fenster, die eventuell verdeckt sein könnten getoppt, und der Aufrufer ist solange geblockt, also auch modal. Ob das so toll ist? Ich hab mich da immer gewundert, wieso plötzlich irgendwelche Fenster getoppt werden, ich glaub ich komm langsam dahinter.
Ansonsten haben glaub ich windows-Programme immer nur ein Fenster und max. einen Dialog?
-
Windows ist ja nun wirklich kein Vorbild und Java ne Krücke. Ich wüsste gar nicht, ob Selectric was anderes kann, als s/w. Selectric kann man natürlich auch nicht mit Boxkite vergleichen. Es ist nur im Filehandling wohl recht vernünftig gewesen und gilt so als die Urmutter aller alternativen Fileselectoren. Mein spezieller Favorit war immer dieser tolle Fileselcetor, dessen Namen mir nicht mehr einfällt. Das war von den Features und vom Aussehen spitze, aber auch vollständig propritär gestrickt und kam wohl mit Gem nicht sauber klar. Galt letztlich auch als Schweineprogramm und heute kräht kein Hahn mehr danach. Zu dumm, der Name wird mir schon noch einfallen. das fand ich seinerzeit besser als Boxkite. Soweit ich mich erinnere, lief es noch unter Magic ganz gut, nicht aber unter Mint. Weshalb ich, als ich ganz auf Mint umgestiegen war, auf dem Falcon dann Boxkite benutzt hatte.
kann man den FS nicht in ein Fenster legen mit den üblichen Schikanen? Und es wird vom Programm wie ein Popupfenster aufgerufen. Nur so ein Gedanke.
-
Der FS ist doch ein Fenster, genaugenommen sogar zwei! Erklär mal wie Du das meinst.
Es hilft alles nichts: solange der Aufrufer auf das Schließen des FS warten muss, kann das mit dem redraw nicht klappen, oder der Aufrufer braucht einen extra-thread nur für den redraw, das ist aber auch Unfug.. MyAES holt schon so ziemlich alles raus, was geht, es gibt trotzdem noch Fehler.
Weil das Konzept Mist ist.
Dabei wäre das garnicht so schwierig, das richtig zu machen. Nur komisch, dass MS mit ihren 10000+ Leuten das nicht hinkriegen. LOL.
Es gibt auch noch freedom, meinst Du den?
-
Es hilft alles nichts: solange der Aufrufer auf das Schließen des FS warten muss, kann das mit dem redraw nicht klappen, oder der Aufrufer braucht einen extra-thread nur für den redraw, das ist aber auch Unfug.. MyAES holt schon so ziemlich alles raus, was geht, es gibt trotzdem noch Fehler.
Weil das Konzept Mist ist.
Was ist denn so verkehrt daran den kompletten Bildschirm zwischenzuspeichern und dann bei bedarf wiederherzustellen?
-
Weil es nicht geht! MyAES macht das z.B. und es gibt immer noch Fehler (siehe Bild: keyedit war nat. nur einmal aktiv).
-
HelmutK:
Der FS ist doch ein Fenster, genaugenommen sogar zwei! Erklär mal wie Du das meinst.
Ja, Du hast recht. ich dachte, wenn es ein echtes Fenster ist, dann kann man das mit appl_init etc, etc wind_irgendwas irgendwie hinkriegen. Aber das wird ja wahrscheinlich schon gemacht.
Weil das Konzept Mist ist.
Meinst Du das Konzept von GEM?
Dabei wäre das garnicht so schwierig, das richtig zu machen. Nur komisch, dass MS mit ihren 10000+ Leuten das nicht hinkriegen. LOL.
Das liegt daran, dass die nie von vorne anfangen, sondern nur immer noch eins draufgeben. ;D
Es gibt auch noch freedom, meinst Du den?
Genau, meine grauen Zellen. :-[
-
Was ich nicht verstehe, warum muss das aufrufende Programm den redraw übernehmen. Das kann es natürlich nicht, weil es ja in der Warteschleife verharrt. Aber kann nicht der Fileselector, der ja aktiv ist, das übernehmen und eben, aus welchem Zwischenpuffer auch immer, die clippingliste abklappern und geänderte Bereiche (z.B. eben beim Verkleinern) neuzeichnen. Seinen eigenen Inhalt muss es ja auch zeichnen (lassen). Und beim Verschieben, werden ja auch die clippings neugezeichnet. ???
-
Weil das Konzept Mist ist.
Meinst Du das Konzept von GEM?
Und von allen die das so machen. Ich hab jetzt keinen Überblick über die ganzen GUI-Systeme, aber windows kann's ja z.B. eher noch viel schlechter als atari jetzt schon.
Das liegt daran, dass die nie von vorne anfangen, sondern nur immer noch eins draufgeben. ;D
So wird das sein. Aber die hatten ja wohl genug Zeit und Macht, das zu ändern, es kann ja optional gemacht werden, für Programme, die sich nicht so leicht umschreiben lassen. Aber vielleicht hab ich auch irgendwas übersehen, denke aber nicht.
Es ist nunmal so, dass das aufrufende Programm den redraw machen muss, weil es das einzige ist, das immer weiß was im Fenster ist. Das AES kann nur die Teile selber zeichnen, die vor dem Fileselektor-Aufruf zu sehen waren. Wenn bei offenem FS ein Bereich eines Fensters des Aufrufers durch Verschieben eines Fensters eines anderen Programmes frei wird, geht's schief. Das habe ich versucht, mit meinem screenshot zu zeigen.
-
Soweit ich mich erinnere, muss bei GEM der Redraw immer vom (teilweise) verdeckten Programm gemanaget werden. Wenns also Darstellungsfehler gibt, kommt das wahrscheinlich vom teils verdeckten Programm. Ich kann mich nur nicht mehr erinnern, wer diesem Programm zum Redraw senden muss, war das das im Vordergrund befindliche Programm, oder das AES?
-
Hallo Helmut, welchen Status hat denn nun Dein xaaes_1.5.0 und wo kann man es bekommen? Im cvs?
-
Müsste morgen in den daily builds sein.
-
Trunk oder Helmut ???
-
wenn ich hier kurz eine kleine zwischenfrage stellen darf..
muss der aufruf vom fileselektor mit wind_update geklammert werden? wenn ja, reicht ein mctrl?
-
Trunk oder Helmut ???
Egal.
-
wenn ich hier kurz eine kleine zwischenfrage stellen darf..
muss der aufruf vom fileselektor mit wind_update geklammert werden? wenn ja, reicht ein mctrl?
Normalerweise ja. XaAES und auch MyAES ignoriert das aber, sonst ließe er sich nicht verschieben.
-
Ich will nochmal klarstellen, dass es Programme gibt, die haben kein Problem damit den Hintergrund zu redrawen, wenn der FS offen ist. Allen voran der Desktop TeraDesk, dann Programme wie zView, Resourcemaster, andere Programme, wie qed, toswin2, highwire und netsurf haben dieses Problem sehr wohl. Wenn also FS da nichts machen kann aus prinzipiellen Gründen, dann sollte man wenigstens Programmierrichtlinien veröffentlichen, wie es die anderen Programme richtig machen und die Schuld damit den Programmautoren zuschieben. ::)
-
Ich sehe schon, die Breite merkt sich der FS nicht über einen Neustart hinaus. :'( Offenbar merkt er sich die Breite aber innerhalb einer Sitzung für alle Programme, konnte jetzt keinen Fehler mehr erzwingen.
Mir ist es aber gelungen nachdem ich etwa 3 - 4 Programme über xaaes-Programm Starten geöffnet habe, dass der Fileselector, der immer zuerst /u/ auswählt, nicht mehr die Ordner öffnen konnte. Allerdings habe ich einmal die Baumansicht angeklickt, die ja bekanntlich in meiner Version noch nicht wieder funktioniert.
Erledigt, schuld ist die Baumansicht. Nachdem man sie wieder ausschaltet, geht es wieder.
Helmut hat übrigens nicht unrecht, wenn man den FS über Load settings in TeraDesk aufruft, dann gibts auch den Redrawfehler. Warum aber können es einige Programme und andere nicht. (Am Rande, hier beherrscht TeraDesk also das Aufrufen des FS, wieso nicht auch bei Open. Das ist das erste, was ich in dem Quellcode einbauen würde.
-
Komisch, ich nehme alles zurück. Nun treten die Redraw-Probleme auch in den Programmen auf, bei denen es vorher funktioniert hatte. Wie kann das sein? ???
Hängt das damit zusammen, dass ich vorher die Programme über das xaaes gestartet hatte? :-\
-
Wer soll das wissen, das Du da machst? Es ist aber möglich, dass Du das verwechselt hast.
Denn bekanntlich gilt ja das
1. XaAES-Gebot
Das aufrufende Programm kann kein redraw bei offenem FS machen, mit der Ausnahme von XaAES.
-
Ja, das scheint die Erklärung, denn offenbar habe ich immer dann, wenn es funktioniert den FS vom Xaaes aus aufgerufen. Das habe ich nicht protokolliert, nun aber nachvollzogen, reproduziert. Und das scheint die Erklärung. Also doch keine Chance. Sehr unschön ist das aber. Und ein entscheidender Nachteil zu aktuellen Desktops alla gnome, xfce4, windows, kde, OSX und andere. :P
Es funktioniert, wenn Du z.B. netsurf über das xaaes startest, dann zview ebenfalls über das aes startest. Netsurf hat sein Browserfenster offen, aber zview hat kein Fenster offen. Wenn Du jetzt zview den FS aufrufen lässt, kannst Du ihn über den ganzen Desktop schieben auch über das Fenster von netsurf und es gibt kein redraw-problem. Bringt uns das weiter? ???
Mit anderen Worten, ein fremdes Programm kann seine Fenster redrawen, wenn ein anderes Programm den FS offen hat, aber jenes nicht seine eigenen Fenster. So richtig?
-
Dafür kann windows nur 1 Fenster pro Programm, ein Dialog, und bei mehr Fenstern (wie bei java z.B.) toppt es wild irgendwelche Fenster. Das finde ich einen Nachteil, bei XaAES das ist nur optisch.
Wie das bei den anderen ist, weiß ich nicht, aber mit dem atari-FS-Konzept geht es nicht anders. Hab ich doch schon gesagt. Lies Dir den ganzen Thread nochmal durch!
Wenn Du die windows-Lösung als Vorteil siehst, dann wohnen wir auf verschiedenen Seiten vom Mond.
-
Na, nicht gleich so grundsätzlich. Mir ist schon klar, dass Du das so gesagt hast. Aber ich glaub's ja eben nicht. Irgendwelche Kompromisse gibt es immer.
Aber inzwischen merke ich den Unterschied. Wieso kann das AES was, was die Programme nicht können?
-
Wieso kann das AES was, was die Programme nicht können?
Weil's das AES ist :)
Vielleicht bau ich das mit nicht-modalem FS ja mal ein, und die Anwendung dafür in qed oder so. Aber momentan hab ich da keine Lust zu.
Außerdem müssen wir das 1.18-release fertigkriegen dieses Jahr.
-
Ja, ja, verstehe schon. Bin eben so ein Dickkopf. >:D
Warum kann man den About von Resourcemaster verschieben, ohne Redrawfehler? Ist der nonmodal?
Es lohnt sich vielleicht, das freedesktop-Projekt zu studieren. xfce4 hat keine derartigen Probleme. Der sehr umfangreiche fileselector lässt sich immer ohne redrawprobleme verschieben. Gimp kann mehrere Fenster öffnen, allerdings verhindern die Werkzeugfenster das Toppen. Natürlich wird heute viel mit frames und Fächern gearbeitet. aber diese Programm lässt sich schon mit z.B. Chagall vergleichen, was für mich eines der klassischsten GEM-Programme ist.
-
Helmut, hast Du mir verraten, das man in der TeraDesk Eingabe-Dialogzeile mit der EINF (INSERT) - Taste den Fileselector aufrufen kann?
Bin ich aber froh. ::)
-
in der 1.19er gelingt es mir nicht einen anderen fileselektor zu installieren.
-
Mir schon:
(http://forum.atari-home.de/index.php?action=dlattach;topic=10101.0;attach=4104)
Man muss übrigens in teradesk nur Insert drücken, um bei Open den Fileselector aufzurufen!
-
Das habe ich doch eben oben erklärt, oder wolltest Du die Empfehlung jetzt einfach nur nachholen. ;D
Nur weil ich ja so lange gemopt hatte, dass TeraDesk den FS nicht benutzt. Ich wusste das aber schon mal früher, man vergisst sowas einfach. Steht irgendwie nirgendwo, oder habs übersehen.
Egal, ich stelle mit Befriedigung fest, dass die Fransen auch bei Dir erscheinen. wenn auch bei Boxkite. ;D
-
Das der Fileselector sich seine Einstellungen nicht dauerhaft merkt ist ziemlich schwach. Neben den Koordinaten, auch Baumansicht und sowas. >:D
-
Dauert noch mindestens 3 Wochen.
-
Bei mir sieht es nämlich inzwischen so aus. Kann man bestimmt noch besser machen. :D
(http://forum.atari-home.de/index.php?action=dlattach;topic=10101.0;attach=4141)
-
Wie kommt es eigentlich, wenn ich in diesem Zustand den FS aufrufe, ihn verschiebe, dann erfolgt das Hintergund-Redraw im bereich des Desktop einwandfrei, aber die darunterliegende Dialogbox wird nicht neu gezeichnet, außer dem Verschiebebalken.
Das aufrufende Programm zeichnet neu, das AES aber nicht? ???
Ich weiß, ich bin penetrant. >:D
(http://forum.atari-home.de/index.php?action=dlattach;topic=10101.0;attach=4143)
-
Was ich weiters unglücklich finde. Wenn ich aus einem Programm heraus z.B. durch "speichern unter" den fileselector öffne, so hat er den Fokus im Directoryfenster. Meist ist ja eine Datei vorausgewählt, was sicher davon abhängig ist, was das Programm vorgibt. Aber wenn ich nun in der Eingabezeile eine Veränderung vornehmen will (z.B. beim Umbenennen des vorausgewählten Dateinamens), so muss ich erst in die Zeile klicken. D.h., ich fände es besser, wenn der Fokus gleich in der Eingabezeile wäre. Denn wenn man aus dem Directory einen Dateinamen wählen will, muss man ja ohnehin in dieses klicken.
-
Eigentlich muss man nur Cursor-rechts tippen, dann kann man den Namen editieren. Klappt das nicht?
-
Doch, das klappt, aber da der Cursor ja default schon am Ende des Namens steht, wäre ich da nie drauf gekommen. Da wäre ja eher Cursor links oder Backspace logisch. Gewöhnt bin ich eigentlich sofort los zu tippen, dann wird der Name überschrieben, oder eben in den Namen klicken an die Stelle, wo ich ihn verändern will. Im jetzigen Zustand muss man da wohl zweimal klicken.
Mmm Pfeil nach links geht im Directory eine Eben höher. Besser vielleicht der Pfeil links wirkt auf den Cursor und Ebene wechseln mit shift Pfeil links oder sowas.
Wenn der Pfeilname in der Eingabezeile markiert ist, dann kann ich mit dem Mauscursor auch nichts richtig mehr ausrichten.
Alles ist Gewohnheitssache und man kann alles lernen, aber ich bin immer für den intuitiv naheliegendsten Weg.
Ich krieg die Krise, obwohl ich es weis, mache ich es intuitiv immer noch dauernd falsch. Wenn man nämlich gleich 3 x linker Pfeil betätig, landet man irgendwo im Wurzelverzeichnis, jedenfalls drei Ebenen tiefer. Geht gar nicht. Versteh natürlich, dass jetzt eingeschliffenes ändern schmerzhaft ist.
Was noch nicht funktioniert im Fileselector: Das Menü Datei(funktionen) - löschen, umbenennen etc. funktioniert sehr gut und ist ein tolles feature (allerdings springt das Directory-Fenster immer an den Anfang nach Umbenennen), aber die shortcuts funktionieren bei mir nicht. (^R, DELETE, etc.). Das scheint auch Zufall zu sein, mal funktionierts, mal nicht.
-
ich kann mir noch folgendes zusätzliches Feature vorstellen. Da TeraDesk nicht beherrscht den Pfad einer Datei ins Clipboard zu grappen, wäre es nützlich, wenn man den FS per shortcut (z.B. INSERT) auch in einem beliebigen Directory-Fenster auf einer selektierten Datei öffnen könnte. Diese Datei sollte dann übergeben werden und man könnte nun mit dem Datei-Menü im FS den Pfad kopieren.
-
Wenn ich das richtig verstehe, willst Du in einem teradesk-Fenster ein selektiertes Objekt an den Fileslektor übergeben, um dessen Pfad dann ins clipboard zu kopieren?
Das erfordert wohl Änderungen in teradesk, und dann wäre es doch wohl einfacher, wenn teradesk den Pfad gleich selbst ins clipboard kopiert, oder?
-
Aha, verstehe. Das wäre dann in der Tat einfacher. ;)
-
Warum kann man eigentlich in die Fileselector Editzeile keine Pfade eingeben? Ich möchte eine Datei in qed öffnen, rufe den FS auf. Der öffnet standardmäßig mit dem LW U:. Jetzt müsste ich doch mit /u/d/home den Home-Ordner öffnen könne, oder mit /d/home/. qed versucht aber home als file zu öffnen. Liegt das an qed oder an FS?
Klar ich kann das LW d: über die Laufwerksauswahl anwählen. Und mich durch die Ordner hangeln.
Das bedeute aber, dass die Editzeile die Pfadeinstellung nicht beherrscht, oder?
-
Er setzt immer den Startpfad davor.
Also bei qed kommt dann sowas wie:
U:\f\usr\gem\DOWNLOAD\/etc/kshrc.ksh
raus, wenn ich in der Editzeile z.B.
u:/etc/kshrc.ksh
eingebe.
Die Fehlermeldung in qed enthält aber nur: u:/etc/kshrc.ksh, was schon wieder komisch ist.
Könnte man evtl. verbessern. Vielleicht hat das auch mit der Sache bei dem Pfad in teradesk von neulich zu tun.
-
das scheint ein Seiteneffekt zu sein. Ich denke aber, dass der FS das gar nicht unterstützt, dass man sozusagen per Editzeile den Pfad wechseln kann. Denn das RETURN wirkt nicht auf die Editzeile, auch wenn der FOKUS sich dort befindet, sondern auf den OK-Button und QED will dann ein File öffnen.
Ich glaube das ist einfach ein fehlendes Feature. Sollte man irgendwann mal nachrüsten, denn das ist eigentlich allgemein üblich und auch hilfreich, dass man per Editzeile den Pfad einstellen und übergeben kann.
Bis dahin hangele ich mich brav per Closer und Directory-Fenster durch die Ebenen bis ich beim richtigen Pfad angelangt bin. :)
Das mit der Editzeile in TeraDesk lässt sich schnell damit beheben, dass bei Betätigung der INS zuerst ein clear (delete raw) gesandt wird bevor der Pfad übergeben wird. Der übriggebliebene Rest wurde nicht durch den FS übergeben, sondern stand einfach noch in der Zeile und der Pfad wurde angehängt, anstatt überschrieben.
Im FS, wenn ich dort sehr schnell scrole, das geht auf meinem Mousepad ganz fix, dann gibt es in den Zeilen manchmal (so jede zehnte Zeile) weiße Blinker. Schätze, das ist auch das VDI. :-\