Autor Thema: Xaaes bugrepoort  (Gelesen 150804 mal)

0 Mitglieder und 2 Gäste betrachten dieses Thema.

Goli

  • Gast
Re: Xaaes bugrepoort
« Antwort #20 am: Mi 06.02.2013, 00:32:41 »
Iconify_orient ist nichts aktiv. Ich habe nur

icnfy_bottom = 16
gesetzt.

Zitat
zu lange Eingabezeile
Ok habe ich gemerkt, ist in allen Programmen so.

Es gibt aber noch ganz andere Dinge die nicht mehr funktionieren. So ist es mir bisher nicht gelungen toswin2 automatisch zu starten, wie bisher. Mit keiner Methode. Wenn ich in toswin2 jetzt auf shell starten gehe, passiert gar nichts.

Ich habs immer mal wieder geschafft, dass der Fileselector ganz verschwindet und das Programm sich dann aufhängt. z.B. mit QED.

Offline HelmutK

  • Benutzer
  • Beiträge: 676
Re: Xaaes bugrepoort
« Antwort #21 am: Mi 06.02.2013, 00:46:29 »
Iconify_orient ist nichts aktiv. Ich habe nur

icnfy_bottom = 16
gesetzt.


Immer noch das selbe (siehe Bild).

Zitat

Zitat
zu lange Eingabezeile
Ok habe ich gemerkt, ist in allen Programmen so.

Es gibt aber noch ganz andere Dinge die nicht mehr funktionieren. So ist es mir bisher nicht gelungen toswin2 automatisch zu starten, wie bisher. Mit keiner Methode. Wenn ich in toswin2 jetzt auf shell starten gehe, passiert gar nichts.


Da stimmt wieder irgendwas mit den Pfaden/passwd nicht.

Zitat

Ich habs immer mal wieder geschafft, dass der Fileselector ganz verschwindet und das Programm sich dann aufhängt. z.B. mit QED.

Das müsste man mal genauer wissen.

So, treeview geht jedenfalls in 1.5.2 wieder.

Goli

  • Gast
Re: Xaaes bugrepoort
« Antwort #22 am: Mi 06.02.2013, 10:08:35 »
Zitat
a stimmt wieder irgendwas mit den Pfaden/passwd nicht.

Was soll da nicht stimmen, was für passwd, da ist bei mir nichts eingestellt. Ich starte aranym als user und muss mich nicht weiter anmelden. Passwörter sind nicht festgelegt. Mit den Rechten komme ich eh nicht klar. Manche Dateien haben user-rechte andere root. Root ist bei mir Gruppe root, nicht wheel.

Offline HelmutK

  • Benutzer
  • Beiträge: 676
Re: Xaaes bugrepoort
« Antwort #23 am: Mi 06.02.2013, 11:00:45 »
In /etc/passwd muss die Start-shell für toswin angegeben werden, z.B.:

root:0mAmSJi508qN6:0:0:Operator:/home/root:/bin/ksh

Das letzte ist die shell. Je nachdem, welcher user Du bist, weiß ich ja nicht.

Wenn toswin sich von xaaes.cnf nicht starten lässt, stimmt der Pfad für toswin2.app evtl. nicht, oder es ist nicht ausführbar. Da fehlen eigentlich noch Meldungen im bootlog.

Kannst Du ja mal überprüfen.

Goli

  • Gast
Re: Xaaes bugrepoort
« Antwort #24 am: Mi 06.02.2013, 13:02:16 »
Ja, ich bastle daran herum. Ich hatte aber so einen Eintrag in passw garnicht. Ich weiß selbst nicht welcher user ich in Aranym bin, ich vermute root. Die shell ist bei mir /bin/bash und das hatte ich irgendwo auch eingetragen, keine Ahnung mehr wo. Ich habe aber an dem UNIX-LW d:/ nichts verändert. Notfalls nehme ich conholio einstweilen. ich habe versucht toswin aus xaaes.cnf sowohl auf c:/toswin2/toswin2.app, als auch /d/usr/gem/toswin2.app aufzurufen. Beides klappt nicht. Wenn ich tw-call innerhalb des gleichen Ordners vom Desk starte, findet es toswin2 nicht. Ich überprüfe aber noch die permissions, vielleicht habe ich ja beim Überschreiben das Programm nicht ausführbar gemacht, oder sowas.

Was anderes, warum nutzt TeraDesk noch immer nicht den FS, das dürfte doch nicht so schwer sein, den aufzurufen anstelle des primitiv-Dialogs. Da TeraDesk ja der Standard in der Distribution ist, sollte man ihn doch auch mit xaaes besser verknüpfen. Auch im AES könnte er doch den TOS-FS nutzen.

Andere Frage, warum bindet man jetzt so konsequent das Mint-LW d:/  in die Konfiguration ein. Es ist doch für die Firebee eines der Vorraussetzungen, dass sie auch ohne Mint-LW funktionieren soll = reine ATARI Umgebung, ohne UNIX-Kenntnisse?

Gratuliere zum Erfolg mit FS und treeview. Ich hatte übrigens nicht den Eindruck, dass die Einstellug thin=NAES irgendwas bewirkt bei mir. Der Schatten scheint mir genauso dick, wie vorher. Aber kannst Du ja mal an den snaps vergleichen, weil ich nicht weiß, wie das aussehen muss.

Goli

  • Gast
Re: Xaaes bugrepoort
« Antwort #25 am: Mi 06.02.2013, 13:15:17 »
conholio funktioniert einwandfrei, und öffnet auch gleich mit der bash. :D

In toswin2 kommt bei shell starten Fehler: beim öffnen des Xconout2-Device.  ???

edit: Das kam nur einmal, sonst passiert nichts.
« Letzte Änderung: Mi 06.02.2013, 21:27:32 von Goli »

Offline HelmutK

  • Benutzer
  • Beiträge: 676
Re: Xaaes bugrepoort
« Antwort #26 am: Mi 06.02.2013, 13:26:03 »
Dann fehlt wohl xconout2.xdd. Gibt es /dev/xconout2?

Was sagt denn jetzt whoami?

Goli

  • Gast
Re: Xaaes bugrepoort
« Antwort #27 am: Mi 06.02.2013, 21:11:03 »
Erstmal harmlos, es war ein Tippfehler im Pfad zu Toswin2. D.h. er startet wieder automatisch beim booten. Aber die Shell lässt sich immer noch nicht starten. :-[

Warum ist nur toswin2 immer so zickig, mit conholio gibts gar keine Probleme? :-X

xconout2.xdd ist da und auch /dev/xconout2  8)

shell startet nicht und wenn ich in toswin2 den FS aufrufe (TOSprogramm starten), erscheint der FS in voller breite, will ich ihn schmalerstellen, geht er ins iconify. Ist eine Console geöffnet, gibt es das Loch in der Console und tw2 hängt sich auf. Aber vermutlich muss ich es erst wieder schaffen, dass die shell startet. Aber wie?  ???

übrigens whoami sagt root.

Ich habe aber jetzt wieder
sln c:\         u:/boot
#sln d:/boot     u:/boot
Wie ich es vom Hades her gewohnt bin. Ich habe kein /root, sondern nur ein /home in das alle Einstellungen wie beim user gespeichert werden.
Ich versuch jetzt mal die permissions von toswin2 auf root zu setzen.

Wenn ich den about von conholio öffne und solche Verschiebespielchen mache, auch im Hintergrund, also ein Desktopfenster toppen und trotzdem den About verschieben, Passiert kein Fehler, alles spielt so wie es soll.  ::)
« Letzte Änderung: Mi 06.02.2013, 21:31:15 von Goli »

Goli

  • Gast
Re: Xaaes bugrepoort
« Antwort #28 am: Mi 06.02.2013, 21:55:15 »
Es ist ja immer viel simpler, als man denkt. Ich hatte den alten toswin2.cfg im Ordner belassen. Aber 1-19 kommt mit ohne cfg daher. Also habe ich den toswin2.cfg entfernt und siehe da, alles spielt. Irgendwie hatte sich in die Datei ein Fehler eingeschlichen, alle Werte waren doppelt, als ob die Datei gemerged wurde, aber die Einträge differierten voneinander. keine Ahnung wie das passiert ist. Vermutlich hat toswin2 versucht in die configdatei neue Einstellungen zu speichern. Nun muss ich nur die Werte wieder anpassen, aber das wars erstmal.

Danach teste ich nochmal die Effekte mit dem FS.

Goli

  • Gast
Re: Xaaes bugrepoort
« Antwort #29 am: Mi 06.02.2013, 22:05:56 »
So der Effekt ist nun in Reinkultur. FS öffnen, schmaler stellen => Iconify und tw2 friert ein.

Die korrupte cfg ist natürlich beim Absturz entstanden, wird auch manchmal ganz gelöscht. Außerdem wird toswin2.cfg natürlich jetzt nach /home gespeichert. auch das muss man erstmal wissen.
« Letzte Änderung: Mi 06.02.2013, 22:24:39 von Goli »

Offline HelmutK

  • Benutzer
  • Beiträge: 676
Re: Xaaes bugrepoort
« Antwort #30 am: Mi 06.02.2013, 22:21:46 »
Erstmal harmlos, es war ein Tippfehler im Pfad zu Toswin2. D.h. er startet wieder automatisch beim booten. Aber die Shell lässt sich immer noch nicht starten. :-[


Warum ist nur toswin2 immer so zickig, mit conholio gibts gar keine Probleme? :-X


Weil es fies ist und den Nutzer ärgern will!

Du kommst aber auch fast täglich mit neuen Komischheiten.

Mit der cfg-Datei ist toswin2 schon kritisch.

Das redraw-Loch müsste weg sein, und die Edit-field-Breite stimmen im morgigen build.

Das mit dem iconify krieg ich jetzt auch hin. Aber nur mit dem trunk-toswin2.7. Mit meiner Spezialversion:

http://home.arcor.de/zabruder/atari/tools/toswin26.zip

passiert das nicht (die ist sowieso besser). Das müsste wahrscheinlich in toswin2 repariert werden. Du kannst aber immer den FS mit Ctrl-Alt-Cursor-down verkleinern, das klappt auch mit der trunk-Version. Ich guck evtl. mal ob ich da in XaAES was finde.

Die shell startet jetzt?

Goli

  • Gast
Re: Xaaes bugrepoort
« Antwort #31 am: Mi 06.02.2013, 22:29:13 »
Die shell startet jetzt. Die Fehler waren Tipper im Pfad und cfg korrupt. Klingt alles vielversprechend. Habe mir den Link gekrallt. Liegt denn der Iconify-bug am toswin?

ist doch klar, wennich was mache, dann gründlich. Nicht das jemand übermütig wird und denkt sein Programm ist bugfrei.  ;D

Wenn man bedenkt, dass ich parrallel einmal von Berlin nach Mönchengladbach und dann wieder zurück gefahren bin.
« Letzte Änderung: Mi 27.02.2013, 12:45:56 von Goli »

Goli

  • Gast
Re: Xaaes bugrepoort
« Antwort #32 am: Mi 06.02.2013, 22:44:37 »
Ich denke nun tut toswin2.7 auch wieder, was es soll. Mal vom FS-verschiebe-bug abgesehen. Der Tipp mit Ctrl-Alt-Pfeil ist gut. CFG gehört nach home, durch editieren konnte ich auch den log-pfad sauber einstellen und auch die Farbe.

Hoffe, wir haben das soweit geknackt.

So nun wüsste ich noch gerne wie man den Boot-Log speichern kann (ich meine nicht xa_boot.log).

Wenn hypview in xaaes eingestellt ist, aber trotzdem st_guide.acc gestartet ist, dann wird st_guide benutzt. Warum? Anders gesprochen, muss ich st_guide deaktivieren, damit hypview aufgerufen wird?

Offline HelmutK

  • Benutzer
  • Beiträge: 676
Re: Xaaes bugrepoort
« Antwort #33 am: Mi 06.02.2013, 22:53:05 »
Die shell startet jetzt. Die Fehler waren Tipper im Pfad und cfg korrupt. Klingt alles vielversprechend. Habe mir den Link gekrallt. Liegt denn der Iconify-bug am toswin?


Ist erstmal naheliegend, weil das sonst keiner macht - oder? An fVDI liegt's diesmal nicht, am TT mit NVDI passiert das auch! Also ehrlich: sowas Bescheuertes hab ich noch nie gesehen!

Zitat

ist doch klar, wennich was mache, dann gründlich. Nicht das jemand übermütig wird und denkt sien Programm ist bugfrei.  ;D

Wenn man bedenkt, dass ich parrallel einmal von Berlin nach Mönchengladbach und dann wieder zurück gefahren bin.

XaAES ist auch speziell zum während des Autofahrens-Benutzen konzipiert!!

Welcher boot-log? Der auf der host-Konsole? Kann man doch umlenken!

Mit st-guide/hypview weiß ich auch nicht.

Goli

  • Gast
Re: Xaaes bugrepoort
« Antwort #34 am: Mi 06.02.2013, 23:46:48 »
Nix umlenken, nix host, das sehe ich ja im benachbarten Terminal, ich meine das, was man auf dem Aranym-Bildschirm als log zu sehen bekommt beim Booten.

Was funktioniert denn nun in deinem toswin2 2.6 besser als in der 2.7?

Ich geb mir mal große Mühe, den bescheuerten Bug auch in anderen Programmen zu erzeugen. Wenn das nicht hilft, dann ist es toswin2.  ;D

Offline HelmutK

  • Benutzer
  • Beiträge: 676
Re: Xaaes bugrepoort
« Antwort #35 am: Mi 06.02.2013, 23:57:06 »
Die MiNT-Meldungen kann man in mint.ini umlenken, wenn Du die meinst:

WRITE_BOOT=1

Mit bootstrap ist das nicht so einfach, da muss man das im config angeben:

BootstrapArgs = DEBUG_LEVEL=1 BOOT_DELAY=0 MEM_PROT=NO WRITE_BOOT=1

Das kommt dann nach c:/mint/boot.log. Ich hab den Eindruck, ich wiederhole mich, man müsste mal die docs aktualisieren ...

Bei meinem toswin funktioniert alles besser als in der 2.7. Z.B: Console- und andere Optionen abspeichern, Geschwindigkeit, und was weiß ich, ist schon zu lange her.

Goli

  • Gast
Re: Xaaes bugrepoort
« Antwort #36 am: Do 07.02.2013, 00:43:05 »
Hab ich schon dem anderen thread entnommen, funktioniert aber nicht

WRITE_BOOT=1

ist der Pfad c:/mint fest?

Ich muss mal ganz blöd fragen, was ist denn bootstrap? Schon oft von gelesen,  aber keine Ahnung. Wo schreibe ich die BootstrapArgs hin?

Goli

  • Gast
Re: Xaaes bugrepoort
« Antwort #37 am: Do 07.02.2013, 01:05:12 »
Zitat
Ich geb mir mal große Mühe

Also der bescheurte Iconify-bug von FS ist auch ohne tw2 mit qed reproduzierbar, bei mir. Man muss nur den FS (öffnet der sich bei jedem Programm mit eigener Breite?) schmaler schieben.

Nicht aber in  z.B. Resourcemaster oder Zview. Offenbar macht es eben doch einen Unterschied, wie sauber ein GEM-Programm programmiert ist.  ;D

Bei highwire passiert das zwar auch nicht, aber der Hintergrund wird nicht restauriert. Das lässt sich auch mit Ctrl-Alt-Pfeil erzeugen.
In diesem Zustand (geöffneter FS) machen auch die dropdown-Menüs Flecken.

Bei Netsurf passiert das nur im eigenen Fenster (bei Highwire auch???), der Desktop wird immer redrawed. Allerdings wenn FS geöffnet ist, dann machen auch hier  die Dropdownmenüs Flecken.

Ebenso graaftool, nur in seinem logfenster. nur in seinen eigenen Fenstern.
« Letzte Änderung: Do 07.02.2013, 01:38:24 von Goli »

Offline HelmutK

  • Benutzer
  • Beiträge: 676
Re: Xaaes bugrepoort
« Antwort #38 am: Do 07.02.2013, 10:11:35 »
Die FS-Breite ist immer gleich, also so wie sie beim letzten Schließen war,  sonst ist da irgend ein Fehler.

An dem screenshot kann ich keinen Fehler erkennen, außer die Fransen, aber das kommt wohl von fVDI, schätze ich.

Dass der Hintergrund nicht restauriert wird, ist Absicht, und das haben wir doch erst kürzlich lang und breit diskutiert!

Ach ja: Die mint.ini-Sachen mit dem bootstrap ins aranym-config (also da wo auch GrabMouse usw. steht), falls MiNT per bootstrap geladen wird.
« Letzte Änderung: Do 07.02.2013, 10:19:02 von HelmutK »

Goli

  • Gast
Re: Xaaes bugrepoort
« Antwort #39 am: Do 07.02.2013, 17:53:04 »
Die FS-Breite ist immer gleich, also so wie sie beim letzten Schließen war,
Das kann ich nicht ganz richtig bestätigen. Ich habe den FS auf eine bestimmte Größe geschoben, beim öffnen einiger Programme, wird das auch beibehalten, andere Programm wiederum öffnen den FS trotzdem mit der Ursprungsbreite, also breit. Ich würde das noch mal reproduzieren und sage Dir dann ganz genau , welche Kandidaten das sind.

Zitat
Dass der Hintergrund nicht restauriert wird, ist Absicht, und das haben wir doch erst kürzlich lang und breit diskutiert!

Achso, aber dazu ist zu sagen, dass einige Programme damit klar kommen, d.h. es gibt keine Hintergrundfehler, und andere aber nicht - da gibt es die angezeigten Flecken, also kein redraw. Das habe ich versucht aufzuzählen. Beim Desktop passiert es ja auch nicht. (Vom Desktop auf xaaes umschalten und dann Programm starten aufrufen).

Das hat aber nichts mit dem "Bescheuerten" Bug zu tun, wie Du es genannt hast, dabei springt der FS ins iconify. Das passiert nur bei den beschriebenen Programmen und Fällen.

Zitat
Ach ja: Die mint.ini-Sachen mit dem bootstrap ins aranym-config (also da wo auch GrabMouse usw. steht), falls MiNT per bootstrap geladen wird.

Ok, das Aranym-config heist einfach config. Geht klar.

Warum wird der xa_help.txt nicht mehr geladen? Ist das Absicht?
« Letzte Änderung: Do 07.02.2013, 18:34:15 von Goli »