Software > Alternative Betriebssysteme

Xaaes bugrepoort

<< < (30/53) > >>

rastr:
das logo beim start interessiert mich eigentlich nicht weiter. hat ja keine sonderlich große funktion.

HelmutK:
Ich hab das mit den 256 Farben doch schon erklärt! Es ist eben so. Bei 8 bit und weniger ist die Farbe palettenbasiert, also jede Farbe wird über Indices addressiert, bei True-Color stehen die Farben so wie sie sind, im Speicher (daher True-Color nehme ich an).
Das TOSi-VDI kennt nur max. 256 Farben außer Falcon oder so.

Ich glaub ich schmeiß die 256 Farben bei >8 bit raus, das stiftet nur Verwirrung, oder?

Zu den Paletten-files: fvdi und NVDI glaub ich verwenden ein leicht anderes Format - XaAES verwendet das gleiche wie die Matrix-Software, da steht am Anfang PA01 oder sowas. Zur Sicherheit! Deswegen knallt fvdi auch, wenn man da irgendwas angibt - der frisst alles.

Ich sehe gerade: bei fvdi.sys hab ich palette nvdi5.pal, d.h. was ich
als fvdi.pal benutze, ist in Wirklichkeit wahrscheinlich nvdi5.pal.  Ist
auch egal, wenn man XaAES die Palette laden lässt.

Goli:
Ne, ne, so einfach ist das nicht. Denn die mit xaaes kommen, knallen in der fvdi.sys. Aber die nvdi5.pal funktioniert in der fvdi.sys, wie @rastr schon richtig sagt. Was das bringt, werden wir sehen. Einstweilen habe in xaaes nicht auf fvdi.pal gestellt, werde das aber auch noch versuchen.

Zum Logo, natürlich hat das keine große Bedeutung, es ist aber naheliegend, dass der Effekt sich auch auf die Icons in den Alerts auswirkt, was schon wesentlich unschöner ist. Daher ist das Logo ein Testcase für mich und Vincent legt natürlich auch Wert darauf, dass die kommende Release ordentlich aussieht und nicht so stümperhaft.  ;D

Jetzt bin ich mal gespannt, was Clocky und clockytools so anrichtet.  ;)

Goli:
JA, also es ist leider so, wie ich es sage, das Entfernen von Clocky hat nichts gebracht. Die geladene table hat keinerlei Einfluss auf meine Tastatur. So als wäre da ein hardcodet Verbindung zwischen Tastatur und GUI. Nur, dass da nicht mein Tastaur-Layout des Notebooks zu Grunde liegt, sondern irgendein rudimentäres ATARI-Layout, das allerdings die Alt-Shift- Kombinationen nicht kennt. Wie bei ATARI üblich, sind die Tasten ^ und # gegenüber PC vertauscht.

Allerdings, und nun wirds noch merkwürdiger, einige von mir definierte Kombinationen von AltGr-Shift funktioneren (hybröische Zeichen). Also wird die Table geladen, aber funktionert auf wichtigen Tasten nicht, wie eben ^ #..

Ergänzung: Ich werde also jetzt erstmal den Backslash auf ein hebräisches Zeichen setzen und das auf AltGr.  ;D

Juhu, und genau das funktioniert. Schon mal ein Problem gelöst. und damit bewiesen, die keyboard.tbl wird geladen und auch benutzt, aber irgendetwas blendet wichtige Keymaps aus, aber nicht alle!!!!!!!!!!! Ich denke da legt sich was drüber oder blockt. :-\

By way im Aranym Hauptdialog ist Alt-Gr auf Milan Alt-Gr gelegt, nicht auf Atari-alt. Also gibt es dort irgendwo eine Schnittstelle, wo doch Aranym an der key-table mapped. Es scheint so, als würde nur die Alt-Gr-Eben meiner notebook.tbl übernommen werden und alle anderen Ebenen verbleiben irgendwie auf default.

Mit dem keyboard-Problem mache ich mal auf dem keyboard-thread weiter.

Goli:

--- Zitat ---auch egal, wenn man XaAES die Palette laden lässt.
--- Ende Zitat ---

Das ist eben die Frage. Wir haben also nun alle nvdi5.pal in der fvdi.sys.  :D
Die Frage ist aber, woher holt sich rsm die Palette und da kann es doch durchaus von Bedeutung sein, was vor xaloader.prg passiert, oder bevor xaaes die Palette einstellt.

Ich hatte aber jetzt lange Zeit die nvdi5.pal auch auskommentiert. Also mit reinem default in fvdi gearbeitet. Und wie mir scheint, habe ich sofort wieder den blue-Icon-Bug, den ich jetzt nur noch ganz selten zu sehen bekam. Und ich bin noch nicht hundert davon überzeugt, dass das ein reiner aranym-Bug ist, wenn er so von der fvdi-palette abhängt.  ::)

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete