atari-home.de - Foren
Software => Alternative Betriebssysteme => Thema gestartet von: Goli am Mo 04.02.2013, 10:24:12
-
Ich fasse mal die Dinge hier unter neuem thread zusammen. Ich bin glaube ich nun auf dem neuesten Stand, wie man den snaps entnehmen kann.
Ist die Versionsnummer rechts oben im About-Dialog richtig?
Es gibt jetzt absolut keine redrawflecken mehr beim kombinieren von Dialogen und Fenstern unter TeraDesk/xaaes. Auch das Verkleinern des Fileselectors in ico2rsc.prg macht nun keine Flecken mehr.
Aber trotzdem kann man das Programm nicht benutzen, weil der Programmdialog (teilweise) verschwindet.
Das Verkleinern der Zeilen im Fileselector ist jetzt wesentlcih freundlicher, dennoch werden die Namen gelegentlich verkürzt. Der Bug: Eingabezeile wird abgeschnitten ist noch da.
Das Xaaes-Logo kommt jetzt immer (nahezu) ohne blauen Balken. Einzig provozieren konnte ich den Fehler noch, wenn man aus TeraDesk auf XAAES wechselt (türkiser Desktop). Dann auf XAAES beenden geht und Alle Programme killen anklickt. Es kommt der bekannte Dialog, dass noch Programme laufen und wenn man dann auf Alle Killen geht, ist das kaputte XAAES-Logo wieder unter dem Dialog (Blauer Balken).
Was ebenfalls nicht funktioniert, der von mir geschilderte Iconify-Fehler ist bei mir reproduzierbar. Ein globaler Wechsel der Fenster mit Ctrl-Alt-W funktioniert nicht. Das obere Fenster wird kurz untopped und dann wieder topped. Mit Ctrl-W kann ich nur die Fenster in TeraDesk wechseln, auf andere Fenster hat das keinen Einfluss.
Getestet unter Aranym 0.1.4 und mintara.prg v. 1.2.13
-
So ich bin wieder am Laptop. Jetzt noch einige snaps, die die merkwürdigen Redraw-Verstrickungen zeigen, die immer noch vorhanden scheinen.
Ein besonderer Kandidat ist auch Toswin2. Wenn tw2 den FS aufruft und man diesen verschiebt, dann wird der Hintergrund nicht restauriert, es kann passieren, dass der FS ganz verschwindet, dass er beim erneuten Verschieben einfach aus dem unteren Bildschirmbereich herausspringt und nur noch seine Kopfleiste zu sehen ist. Er lässt sich meist dann auch nicht mehr hochschieben. Tw2 friert dann ein und lässt sich nicht mehr beenden, nur noch killen.
Schön ist auch das Loch, dass beim Doppeldialog entsteht, wenn man den About von TeraDesk beendet und darunter befindet sich der About von XAaes.
Wobei dieser Tera Desk Info Dialog immer das oberste Fenster bleibt, anders als der von Xaaes, den man untoppen kann und andere Fenster darüber schieben.
Der blue-icon bug kommt wieder heftiger zum Vorschein, der Blue Balken über dem AES-Logo ist leider auch wieder da.
Ist was anders im Trunk?
Mal sind im FS die Namen gestaucht, mal werden sie hinten abgeschnitten (was besser ist).
Fileselector. was man ihm noch beibringen sollte, ist, dass das Directoryfenster d&d verstehen sollte (AV-Protokoll). Dann ist nämlich der Unterschied zu einem Desktopfenster nicht mehr groß.
Ich weiß leider nicht, wie man die jpgs einbettet.
-
Weitere Beispiel-jpgs
-
Das neueste XaAES ist 1.5.1 ( da geht im FS aber treeview nicht).
Wegen dem blue-icon-bug an die aranym-Leute wenden, der ist aber m.W. behoben.
Den toswin-FS-Verschieben-Fehler kann ich nicht nachvollziehen. Was muss ich dazu genau machen? toswin braucht bei fVDI übrigens noleft=true, das macht dem FS aber nichts aus.
Auch nicht das mit dem teradesk-about (v4.01).
Die gestauchten Namen bekomm ich auch nicht hin, auch nicht bei minimaler FS-Breite.
Ausnahme:
NetSurf-m68k-atari-mint-gcc-jsoff-852.zip
Der ist zu lang. Und dabei gibt's auch einen redraw-Fehler in der Eingabezeile.
Mach alle Zusätze (Gradienten, Texturen, ...) aus probeweise.
-
Bevor ich mich in das vertiefe, versuche doch mal bitte das zu reproduzieren: (ich versuche es nachzuvollziehen - gar nicht so einfach, was ich da gemacht habe):
Ich starte in TeraDesk, öffne oder toppe Toswin2. Ich öffne den Menüpunkt "TOS-Programm starten". FS erscheint. Dann öffne ich den About-Dialog von Xaaes. Mit geöffentem Dialog versuche ich jetzt den FS zu verschieben, auch im ungetoppten Zustand (also im Hintergrund). Der FS springt in die untere DesktopEcke und lässt sich nicht mehr hochschieben.
Manchmal habe ich auch noch zusätzlich den TeraDesk About Dialog geöffnet. Die genaue Reihenfolge der Schritte müsste ich protokollieren, ich kann's mir nicht merken. Aber nach einem bischen herumspielen mit diesen Schritten, müsste man es forcieren können.
So jetzt klappere ich mal Deine Antwort ab.
Kann es sein, dass xaaes ein altes noch vorhandenes xaaes.rsc lädt? Eingestellt ist bei mir xaaes016.rsc (oder geht das automatisch?). Aber das ältere ist noch vorhanden. Ich hab's jetzt mal deaktiviert, vielleicht war das ja das Problem für die Blue-Icons etc.
-
toswin braucht bei fVDI übrigens noleft=true, das macht dem FS aber nichts aus.
Wo stell ich das ein? in fvdi.sys?
ich habe teraDesk 4.04.
Der toswin2 lässt sich regelmäßig reproduzieren. Das Programm hängt sich auf, bzw. friert ein - killen.
Mach alle Zusätze (Gradienten, Texturen, ...) aus probeweise.
Au backe, wenn ich jetzt wieder wüsste wie das geht. Aber ich habe nur minimal Gradienten an, Texturen gar nicht, denke ich.
Wie komme ich an die xaaes 1.5.1 habe das ganze Trunk-archiv ausgepackt. Bei mir steht immer 1.4.6 Beta.
Was bedeutet denn rechts oben die 0.1.6? ???
toswin2 lässt sich absolut reproduzieren, auch ohne den About-Dialog, einfach Programm starten, Console öffnen, FS aufrufen - verschieben.
Aber ich brauche erstmal das neueste xaaes, bei mir geht der treeview nämlich noch.
-
noleft in xaaes.cnf unter app_options für toswin2.
Ohne hängt sich toswin2 bei mir mit aranym auch auf, wenn ich ein Fenster links rausschiebe.
Die anderen Sachen krieg ich nicht hin, der teradesk-about blockt ja, da kann man nichts anderes verschieben.
Nimm am besten das example.cnf aus dem neuesten trunk, und setz da noleft=true für toswin2. textures ist bei Dir an, das lässt sich mit textures=0 abstellen, sollte alles im example.cnf stehen.
XaAES 1.4.6 ist jedenfalls irrelevant ;-)
Das ist dann aber jetzt MiNT 1.19!
-
[steht bei mir an
app_options = toswin2, nohide = true, noleft=true
Ich suche schon wieder verzweifelt nach dem Link zum trunk. Ich brauche erstmal die neue Version.
der teradesk-about blockt ja, da kann man nichts anderes verschieben
Das stimmt nicht, zumindest nicht mit 4.04. Man kann den About von xaaes hinter dem About von Teradesk verschieben und auch toppen. Mit Fenstern geht das wohl auch, z.B. mit dem system-fenster von xaaes. Natürlich blockt der Tera-about das Teradeskprogramm und man kann keine Fenster öffnen. Ein anderes Programm habe ich jetzt nicht gestartet, das müsste ich noch testen. Theoretisch geht das aber über xaaes oder, wenn schon eins parrallel läuft über das ACC-Menü.
-
http://www.fairlite.co.uk/FreeMiNT/builds/freemint/trunk-05022013.tar.bz2
-
Das mit dem teradesk-Loch hab ich jetzt auch: Man muss erst auf Fenster-dialog umstellen. Guck ich mir mal an.
-
Achso, Du hattest nicht Fensterdialog, das ist bei mir an. Inzwischen habe ich noch mal die Trunk ausgecheckt. Und den gesamten xaaes-Ordner gelöscht und durch den aktuellen ersetzt. Mal schaun.
Hab nun auch den Trunk gebookmarkt, hatte ihn aber schon gefunden in der bash-history. Danke.
Ich habe jetzt bei den Tests immer das toswin2 aus dem trunk verwendet. Aber ich habe auch eine Version von Vincent von Mitte Januar. Spielt das eine Rolle?
-
Wieso löschst Du XaAES vom MiNT 1.18? Das kommt doch alles woanders hin für 1.19!
Bzgl. toswin2 weiß ich nicht, aber es sollte wohl die trunk-Version getestet werden.
-
Es sind doch nur diverse Byneries auf das unix-LW verschoben. Das mache ich natürlich nicht und habe die Pfade in der xaaes.cnf angepasst. Ich organisiere doch nicht meine gesamte Mint-Installation plus aranym um. Und so läuft es bei mir auch ganz ohne das Mint-Unix-LW. Ist auf einem Linux-System mit nur host-LW doch eh palle, wo was liegt, alles wird gleich schnell erreicht, insbesondere ich keine Festplatte habe, sondern nur eine SSD und eine schnelle SD-Card. Die verschiedenen Programme schiebe ich natürlich dahin, wo die alten Versionen bei mir liegen. Ich kann doch nicht gleich eine leere Festplatte besorgen, um alles neu und nicht doppelt zu installieren. Da würde ich durchdrehen. Ich hab doch noch nen Ordner 1-17 mit vollständiger Installation liegen, also mehr als zwei Verisionen werde ich nicht installieren.
Muss der Ordner jetzt zwingend 1-19-cur heißen? Es hat erst geklappt, nachdem ich ihn in der mint.cnf umbenannt hatte und natürlich den Ordner so benannt.
-
Was hast du in der mint.cnf umbenannt?
Man braucht nur im auto-Ordner den kernel auszutauschen, und alles andere läuft automatisch. Der 1.19-kernel hat .../1-19-cur als SYSDIR, der 1.18 .../1-18-cur, usw. Das kann alles gleichzeitig drauf sein.
Aber ich werde ohne zwingenden Grund das release (da wäre SYSDIR dann .../1-18-0) wohl auch nicht installieren, bin auf aranym schon bei 1.19 :)
Ja: Es muss 1-19-cur heißen!
-
Na in der mint.cnf steht der Pfad nach 1-19-cur. Ansonsten habe ich ja sonst auch immer nur die geänderten Files ausgetauscht. Egal, es läuft ja, kleinere Korrekturen sind halt noch nötig.
Ok, nun ohne texture und gradient. :'( Die Fehler konnte ich bisher nicht wiederholen. :) Das Mausrad funktioniert noch nicht, bin bedient. :o Aber das kann ja nur an der Einstellung liegen, wahrscheinlich muss ich mous.adi wieder deaktivieren. Beides geht eben nicht. Der About-Text fehlt mir nun auch, vermutlich mitgelöscht. ::) Den TosWin2 konnte ich nicht reproduzieren, scheint zu funktionieren. Aber den Icon-Sortier-Bug schon. Siehe snapshot. Console iconify, dann ein Teradesk-Fenster iconifizieren. Es schiebt sich unter das Console-Icon. Im snap habe ich es ein wenig verschoben, damit es sichtbar ist. Die Blue-Icon und xaaes-Logo-Fehler tauchten nicht wieder auf. Schaun mir mal was noch so auffällt.
Mmmh, schau Dir mal Iconify und Salat.jpg an. Der Teradesk-About blockt natürlich das teradesk und ist immer oberstes Fenster, nicht aber, wenn man Aranym XAaes aufruft, das About oder das System-Fenster öffnet oder beide. Da passieren dann die merkwürdigsten Sachen, wenn man jetzt Fenster verschiebt. Oft verschwand auch das LW-R (Ramdisk) einfach mal so ins Nirvana. Mit dem FS habe ich noch nicht viel experimentiert.
Aber xaaes spricht deutsch.
Bei Xaaes_über_Tera.jpeg gibt es Pixelmüll an den Fensterkanten beim verschieben, unwesentlich.
-
In meiner mint.cnf, ich habe natürlich die alte angepasst, steht
GEM=u:/c/mint/1-19-cur/xaaes/xaloader.prg
Und da hatte ich ursprünglich nooh 18-cur, weil ich es ja nicht wusste, dass es nur mit 19-cur funktioniert. Den Ordner habe ich natürlich dann auch umbenannt. Dass alles von alleine funktioniert, das glaube ich aber nicht. Die vielen Programme, die am richtigen Ort sein müssen etc.
-
Hm, der xaloader müsste sich dann natürlich woanders (am besten c:/mint) befinden. Das müsste man evtl. mal verbessern Dann braucht man in mint.cnf nur GEM=c:/mint/xaloader.prg, und alles andere sollte automatisch laufen. ist jedenfalls so gedacht.
Solange der xaloader mit allen Versionen klar kommt, der sollte aber immer abwärtskompatibel sein, also neuer xaloader lädt altes XaAES.
-
XAueberTERA.jpg: fVDI-Fehler (nehme an, die Fransen im teradesk-about sind gemeint).
Das mit dem iconify krieg ich nicht hin. Hast Du irgendwelche Sachen in xaaes.cnf mit iconify? .Z.B. icnfy_orient? Ich nicht.
Salat muss ich noch gucken, das hatten wir doch schon.
Mit blue icons brauchst Du auch nicht mehr zu kommen, das ist nicht XaAES, sonder aranym.
-
XAueberTERA.jpg: fVDI-Fehler (nehme an, die Fransen im teradesk-about sind gemeint).
Ja, tritt aber auch an anderen Fenster/Dialogrändern auf und verändert sich mit schieben.
Das mit dem iconify krieg ich nicht hin. Hast Du irgendwelche Sachen in xaaes.cnf mit iconify? .Z.B. icnfy_orient? Ich nicht.
Ja, ich habe 16 Punkt höher gesetzt, damit Taskbar frei bleibt, aber sonst nichts.
Salat muss ich noch gucken, das hatten wir doch schon.
Ja, hatten wir schon, aber ich habe ja jetzt updated und nun endlich die richtigen Programme und hatte erst gedacht, es ist fort.
Mit blue icons brauchst Du auch nicht mehr zu kommen, das ist nicht XaAES, sonder aranym.
Ist schon klar, offenbar war bei mir zwischenzeitlich ne alte Version hineingerutscht, denn es war schon mal vollkommen weg bei mir. Nun ist es gut und das freut ja dann.
Dein FS ist viel besser jetzt, das Stauchen kommt nicht mehr vor, die Eingabezeile passt sich nun auch an. Aber mach mal zview auf. Beim ersten aufrufen über "datei öffnen" ist die abgeschnittene Eingabezeile wieder da, erst wenn man denn FS verbreitert und dann wieder staucht, funktioniert es.
-
Was steht denn im xaaes.cnf genau für iconfy_orient?
Die zu lange Eingabezeile hat nichts mit zview zu tun, sondern damit, dass diese Korrektur nicht beim Öffnen, sondern nur beim Verkleinern/Vergrößern gemacht wird.
Wird repariert. Das ist sowieso provisorisch, letztlich sollte das scrollen, aber das ist mir momentan zu viel.
Wenn ein zu langer Name drinsteht, gibt's ja auch noch redraw-Fehler.
-
Iconify_orient ist nichts aktiv. Ich habe nur
icnfy_bottom = 16
gesetzt.
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.
-
Iconify_orient ist nichts aktiv. Ich habe nur
icnfy_bottom = 16
gesetzt.
Immer noch das selbe (siehe Bild).
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.
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.
-
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.
-
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.
-
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.
-
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.
-
Dann fehlt wohl xconout2.xdd. Gibt es /dev/xconout2?
Was sagt denn jetzt whoami?
-
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:/bootWie 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. ::)
-
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.
-
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.
-
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?
-
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.
-
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?
-
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!
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.
-
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
-
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.
-
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?
-
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.
-
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.
-
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.
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.
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?
-
Dein Toswin2 läuft gut, es heist prg und nicht app, die cfg musste auch erst gelöscht werden, weil meine eine falsche Farbe einstellte. Aber sonst alles paletti. Wenn Du da gepached hast, dann sollte das auch in den trunk. 8)
boot.log geht jetzt. Mal schaun, was da noch für Fehler erkennbar.
Soll ich eigentlich mal Memoryprotection anstellen? (aranym)
-
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.
Den Fehler mit dem springenden FS hab ich gefunden. Der ist morgen weg. Vielleicht hat das ja auch was damit zu tun, dass die Breite sich ändert, allerdings ist mir das auch mit dem Fehler noch nie begegnet.
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 kann gar nicht - ausgeschlossen! Wenn Programm starten ausgeführt wird, ist es XaAES, das den FS aufruft, und das hat mit dem redraw natürlich nicht die Probleme wie die Programme.
Warum wird der xa_help.txt nicht mehr geladen? Ist das Absicht?
Wenn XaAES deutsch ist, muss das xa_help.de heißen. Überprüf mal Deine Installation!
-
Den Fehler mit dem springenden FS hab ich gefunden. Der ist morgen weg. Vielleicht hat das ja auch was damit zu tun, dass die Breite sich ändert, allerdings ist mir das auch mit dem Fehler noch nie begegnet.
Das liegt daran, dass so verrückte DInge wie ich sie mache, niemand macht. ;D
Das kann gar nicht - ausgeschlossen! Wenn Programm starten ausgeführt wird, ist es XaAES, das den FS aufruft, und das hat mit dem redraw natürlich nicht die Probleme wie die Programme.
Gut, das gilt vielleicht für den Desktop, obwohl mir das nicht einleuchtet. Der ist doch auch nur ein Programm.
Wenn XaAES deutsch ist, muss das xa_help.de heißen. Überprüf mal Deine Installation![
Ok, das war vorher anders, oder ich hatte xaaes englisch.
Sehr gut kann man die unterschiedlichen Fähigkeiten der Programme testen, bezüglich des redraws, wenn man zwei Programme gleichzeitig den FS öffnen lässt. z.B. netsurf und resourcemaster. FS schön klein machen und nebeneinander anordnen, dann verschieben wahlweise. Hab keine Lust jetzt auf screenshot.
-
Dein Toswin2 läuft gut, es heist prg und nicht app, die cfg musste auch erst gelöscht werden, weil meine eine falsche Farbe einstellte. Aber sonst alles paletti. Wenn Du da gepached hast, dann sollte das auch in den trunk. 8)
Das ist aber 2.6, ich fand 2.7 immer Mist, und da würde ja alles durcheinander kommen. Und dann darf ich da auch noch Wünsche erfüllen ...
Soll ich eigentlich mal Memoryprotection anstellen? (aranym)
Da muss die MMU initialisiert werden, ist kompliziert und läuft nur noch 1/20 so schnell.
-
Achso. Also nix so für Aranym. Ich wusste nicht, dass der Unterschied zwischen 2.6 und 2.7 so groß ist. Du sagst ja selbst, man müsste die Änderungen in die 2.7 einpflegen. :D
-
Oder umgekehrt: Die Änderungen von 2.6->2.7 in meins. Aber das ist viel Arbeit, vor allem den Mist wegzulassen.
-
Übrigens mit Deinem toswin2 gibts auch kein iconify Reihenfolge-bug. Es scheint also an 2.7 zu liegen. :)
-
Ich bin jetzt auf 1.5.3 Beta und muss sagen, es spielt alles sehr schön und zu meiner Zufriedenheit. :D Elegant wäre natürlich wirklich, wenn der FS auch nach einem Neustart mit einer voreingestellten Größe starten würde, nicht in voller Breite, respektive sich die Einstellungen über den Reset merken würde. Dann fällt das Redraw-Unvermögen nicht so auf ;D
Teufel auch, konnte keinen bescheuerten Bug mehr erzwingen. >:D
Folgender lustiger Effekt: Wenn ich Conholio über das AES starte (Programm starten), dann kommt er bei mir mit einem schwarzen Fensterhintergrund daher. Wenn ich aber Conholio über Toswin2 starte (TOS-Programm starten), abgesehen mal von der Parameter Abfrage, erscheint conholio dann mit einem gelb gefüllten Fenster. ::)
Ich habe auch noch nicht heraus, welche Version am besten läuft conholio.app, conholio020.app oder conholio060.app unter aranym. Was ist der Unterschied? ???
Zu früh gefreut, jetzt ist der Iconify-Fehler von toswin2 wieder da (ich habe Deine 2.6), Helmut. Ich schicke zuerst das Fenster von conholio ins iconify, dann das von Toswin2. Letzteres schiebt sich unter ersteres. Und alle anderen auch. :o
Wenn man mit TeraDesk beginnt, ist die Iconifyreihe sauber.
-
Einen habe ich noch Beim Iconify ergibt sich bei zwei Icons die falsche palette, oder ein ähnlicher Effekt, wie mit dem XAaes-Logo bei falscher palette. Ich habe palette=nvdi und 256 Farben.
-
Das mit dem iconfy bei conholio hab ich auch. Kann ich mal gucken.
An der Palettenproblematik bin ich gerade am Basteln, allerdings sollte bei nvdi-Palette alles paletti sein :)
Welche Icons meinst Du genau, und welche CICONS benutzt Du in teradesk?
Der Fileselektor sollte nie in voller Breite anfangen, sondern mit max. 560 pixeln, sonst ist da was faul.
Wenn du die Grauzonen nicht sehen willst, kannst Du ihn ja einmal von XaAES öffnen (z.B. Ctrl-Alt-K), einstellen und wieder schließen.
-
ja mit palette=nvdi sollte es richtig sein, ist es auch meist. Ich meinte die Icons von highwire und netsurf im iconify. Diese Icons kommen nicht aus der cicon.rsc sondern bringen die Programm wohl selber mit. Meine cicon.rsc habe ich mir selbst zusammengebastelt, es sind icons dabei, die sind in 256 Farben und solche mit nur 16 Farben. Wie welche Version jeweils ausgewählt wird, das weiß ich auch noch nicht so genau. Die verdorbenen Icons sehen so aus, wie bei Vincent das XAaes Logo aussah, bevor das gefixed wurde. So mit vielen schwarzen Pixeln. Mit meiner cicons.rsc habe ich sonst keine Probleme, wie man ja an meinen Deskicons erkennen kann. Verwende ja eh nicht viele und in den Fenstern benutze ich fast immer die Textdarstellung. Ich habe aber zusätzlich diese Zeile in der cnf:
app_options = aessys, thinwork = true, winframe_size = 3, xa_nomove = false, nolive = false, rsc_lang = 1, icn_pal_name = nvdi
Der Fileselektor sollte nie in voller Breite anfangen, sondern mit max. 560 pixeln, sonst ist da was faul.
Na, die Pixel habe ich nicht gezählt ;) Er wird schon so öffnen, wie Du es eingestellt Breit, aber nicht Bildschirmbreit Mir wäre schmaler aber lieber.
einstellen und wieder schließen.
Ja, das habe ich mir auch schon überlegt Etwas fricklig. ::)
-
Zur Palette: kommentiere ich palette=nvdi, dann wird ja wohl palette=gem eingestellt. Jedenfalls sieht das nicht so gut aus das XAaes Logo sieht sofort wieder so aus, wie Vincent es auch gezeigt hat (verpixelt) und auf einige wenige Icons hat das ebenfalls einen schlechteren Einfluss. Die Vorschaubildchen in den Iconify von Highwire und Netscape sehen aber genau so falsch aus, wie unter palette=nvdi. :-\
-
Das remap funktioniert in den aktuellen snapshots nicht richtig.
Jetzt bin ich aber schon einen Schritt weiter:
Truecolor und 8bit müssten komplett klappen, also 8bit- und 4bit-icons sollten korrekt dargestellt werden, egal ob als Palette nvdi oder gem eingestellt ist.
4bit-Auflösung hab ich damit noch nicht probiert, das lass ich erstmal außen vor.
Schick mir mal icon-Dateien für teradesk (oder links dazu), die momentan nicht richtig dargestellt werden, und wie Du zu der falschen Darstellung gekommen bist.
Das Highwire-icon in 8bit mit gem-Palette erscheint z.B. wie im Bild. Ist das richtig?
-
Hallo Helmut, gratuliere erstmal zu dem "Schritt weiter". Handelt es ich bei dem Iconify überhaupt um Icons? Aus der CICON.RSC kommen sie nämlich nicht. Ich will meine und andere ICON.RSC durchforsten nach Fehldarstellungen, das wird aber dauern.
Was Du mir geschickt hast, hw8gem.png ähnelt meinem Fehler. Einfach mal Dein Bild mit meinem Iconyreihe.jpg vergleichen. Bei netsurf ist es ähnlich. Ich hänge hier mal ein Icon an, das unter palette=gem geringfügig anders aussieht, als unter palette=nvdi. Muss ich nur noch schnell erzeugen, es dauert ein wenig.
Es würde mir helfen, wenn Du mir mal die Aufstellung ergänzt
truecolor = hochaufgelöste Farben
16bit = highcolor
8bit = 256 Farben
4bit = 16 Farben
2bit = 4 Farben
1bit = schwarz/weiß
Stimmt das so? Wie wählt das Programm die richtige Farbtiefe aus, wenn im cicon.rsc bestimmte Icons mit 4bit und 16 bit vorliegen?
Es kommen gleich die Icons, später liefere ich noch mehr Beispiele. Strange ist, dass es noch ein Unterschied macht, ob man
palette=nvdi
palette=gem
#palette=[kommentiert]
einstellt. Im dritten fall müsste ja eigentlich die Defaulteinstellung geladen werden. Allerdings habe ich noch die Zeile über das remap nach nvdi aktiv und ich habe auch noch eine teradesk.pal im teradesk-Ordner.
nacheinander hier das gleiche Icon
1. in resourcemaster
2. auf TeraDesktop in nvdi-palette
3. auf TeraDesktop in gem-palette
4. auf TeraDesktop #palette= -kommentiert in der cnf
Bei palette=gem haben alle Icons und auch Fenster auf Teradesk noch eine ein-pixel-Kontur in schwarz zusätzlich. Ansonsten sieht man an den Icons, dass teilweise weiße Konturen schwarz erscheinen u. umgekehrt.
Bei kommentierter Palette tritt der Blue-Icon-Bug in alerts auf, bei nvdi, oder gem nicht (oder fast nie). Bei kommentiert und bei gem ist das XAAes-Logo korrupt. Bei nvdi ist es gut.
Ist alles sehr verwirrend und schwer zu merken.
Als nächstes werde ich mir mal die cicons.rsc vornehmen, mal sehen ob ich da was zusammenstellen kann.
-
die icons in den iconifyfenstern sind immer von den applikationen selbst, nicht vom desktop.
-
Danke rastr und sie befinden sich nicht immer in einer extra icon.rsc.
-
genau. die app entscheidet was im iconifizierten fenster dargestellt wird. könnte auch einfach nichts, oder eine animation sein zb.
wenn die app aber das iconifizieren selbst nicht unterstützt, dann gibt es nichts...
-
Helmut, ich häng hier nochmal eine rsc-Datei von dem floppy-icon an. Einfach in .rsc umbenennen. Erstellt mit Resourcemaster.
-
Zur Palette: kommentiere ich palette=nvdi, dann wird ja wohl palette=gem eingestellt. Jedenfalls sieht das nicht so gut aus das XAaes Logo sieht sofort wieder so aus, wie Vincent es auch gezeigt hat (verpixelt) und auf einige wenige Icons hat das ebenfalls einen schlechteren Einfluss. Die Vorschaubildchen in den Iconify von Highwire und Netscape sehen aber genau so falsch aus, wie unter palette=nvdi. :-\
Wenn palette nicht gesetzt ist, findet auch kein remap statt, weil XaAES dann nicht weiß, welche Palette von wo wohin gemapt werden soll.
Das kann man aber später evtl. noch hinbekommen.
-
Das heißt, es gibt einen dritten Zustand. Ich habe aber immer noch diese Zeile aktiv, die hat dann keine Auswirkung?
app_options = aessys, thinwork = true, winframe_size = 3, xa_nomove = false, nolive = false, rsc_lang = 1, icn_pal_name = nvdi
Soll ich die lieber erstmal #-kommentieren?
-
Was Du mir geschickt hast, hw8gem.png ähnelt meinem Fehler. Einfach mal Dein Bild mit meinem
Dieses icon sollte eigentlich jetzt richtig dargestellt sein, also grün. in rsm (die große Darstellung) sind die selben Farben (100% geht nicht immer, weil in der Ziel-Palette nie immer genau die selben Farben wie in der Quell-Palette enthalten sind). Wenn man das png stark vergrößert, kommt's schon hin, finde ich. Die Vorschaubilder von rsm sind oft irreführend.
Iconyreihe.jpg vergleichen. Bei netsurf ist es ähnlich. Ich hänge hier mal ein Icon an, das unter palette=gem geringfügig anders aussieht, als unter palette=nvdi. Muss ich nur noch schnell erzeugen, es dauert ein wenig.
Mach das nochmal mit XaAES 1.5.4.
Es würde mir helfen, wenn Du mir mal die Aufstellung ergänzt
truecolor = hochaufgelöste Farben
16bit = highcolor
8bit = 256 Farben
4bit = 16 Farben
2bit = schwarz/weiß
Stimmt das so? Wie wählt das Programm die richtige Farbtiefe aus, wenn im cicon.rsc bestimmte Icons mit 4bit und 16 bit vorliegen?
schwarz/weiß ist 1bit, sonst stimmt die Liste. XaAES wählt immer das "beste", also wenn der Bildschirm 8 bit oder mehr hat, und ein 8bit-Icon vorhanden ist, wird das genommen. Bei anderen Konstellationen entsprechend.
Es kommen gleich die Icons, später liefere ich noch mehr Beispiele. Strange ist, dass es noch ein Unterschied macht, ob man
palette=nvdi
palette=gem
#palette=[kommentiert]
einstellt. Im dritten fall müsste ja eigentlich die Defaulteinstellung geladen werden. Allerdings habe ich noch die Zeile über das remap nach nvdi aktiv und ich habe auch noch eine teradesk.pal im teradesk-Ordner.
Mit ohne palette= kann ich für nichts garantieren (siehe oben).
zusätzlich. Ansonsten sieht man an den Icons, dass teilweise weiße Konturen schwarz erscheinen u. umgekehrt.
Das sollte jetzt alles besser klappen in 1.5.4.
Ist alles sehr verwirrend und schwer zu merken.
Das ist Metaphysik :)
-
Dieses icon sollte eigentlich jetzt richtig dargestellt sein, also grün.
Schau ich mir an, aber ob das heute noch klappt?
Mach das nochmal mit XaAES 1.5.4.
Stöhn! Ei, ei, Sir. >:(
schwarz/weiß ist 1bit, sonst stimmt die Liste. XaAES wählt immer das "beste", also wenn der Bildschirm 8 bit oder mehr hat, und ein 8bit-Icon vorhanden ist, wird das genommen. Bei anderen Konstellationen entsprechend.
Ok, danke.
Mit ohne palette= kann ich für nichts garantieren (siehe oben).
Aha, ich dachte, es gibt sowas wie default-palette. Ok.
Das sollte jetzt alles besser klappen in 1.5.4.
Ich staune.
Das ist Metaphysik :)
Ah, jetzt weiß ich endlich, was Metaphysik ist. ;D
-
Auf jeden Fall sieht das icon von Highwire auch im resourcemaster unter 1.5.3 krank aus (palette=nvdi). Das gleiche gilt für das netsurf-Icon.
Kriegst Du eigentlich den Pixelmüll weg im Blockmenü des Iconeditors in resourcemaster? Ich hatte mich vergeblich gemüht und nur einen Teilerfolg. Es wird dort das kleine Floppyicon sowohl für speichern und laden nicht sauber dargestellt.
-
Was meinst Du jetzt: Die icons im rsm-Bildeditor? Oder wie das Floppy-Symbol dargestellt wird?
Bei mir jedenfalls sieht das Floppysymbol gut aus, mit rsm hab ich nichts am Hut :)
-
Nein, die kleinen Floppy-Icons in der Werkzeugleiste des rsm-bildeditors.
Nicht das floppy-Symbol von oben. Ist schon klar, dass du mit rsm nichts am Hut hast, ich aber auch nicht. ;D
Die 1.5.4 wird ja sicher erst heut Nacht oder morgen im trunk sein. Habe übrigens Deine 1.5.3 Helmut-branch mal geladen. das enorm viel größere mintara.prg. Ist noch was anderes anders? Und sind da so viele debugings drin? Oder was ist eigentlich anders und warum gibt es diese branch überhaupt, die Entscheidung damals hatte ich nicht verstanden.
Läuft jedenfalls und genauso schnell. Unterschiede sind nicht auszumachen.
-
Stimmt, das ist eine DEBUG-Version, ist mir wohl mal so durchgerutscht, aber macht ja nichts.
Der Grund für die 2 branche ist, dass ich immer alles doppelt einpflegen darf, und immer den Änderungen von Alan hinterherrennen muss.
Hat aber auch den Vorteil, dass man im einen oder anderen mal was probieren kann. Bei mir gibt's jetzt z.B. Esc-Sequenzen für alles. Probier mal z.B.
Ctrl-V Ctrl-Cursor-rechts (gibt Esc[C;)
Aber irgendwas fehlt bei mir: Das Archiv ist immer etwas kleiner als trunk, muss ich mal gucken.
Und im trunk ist irgend ein Fehler: Wenn ich in XaAES mit Ctrl-C was ins clipboard kopier, stürzt er ab ...
Aber nicht wenn ich den trunk-kernel selbst kompiliere.
Hm, auf einmal klappt auch der snapsot ...
-
Ich bin ja noch nicht auf der 1.5.4. Durchgerutscht ist auch ne schöne Erklärung. :) Das mit Ctrl-V und Cursor bin ich skeptisch und gespannt.
Ich bin eigentlich ziemlich irritiert, dass es immer noch so wenig Programmier-Richtlinien oder Design-Richtlinien und Standards gibt für GEM. Jedes Programm hat andere shortcuts. Selbst die fürs Clipboard und andere Standardfunktionen sind mal mit Ctrl- mal mit Alt-. Ist schon klar, dass die Terminals die Ctrl-Codes reservieren, aber dieses Durcheinander? Stadt Alt- wäre da eigentlich dann schon Shift-Ctrl oder Alt-Ctrl besser, weil es dann nicht vollständig anders und konträr ist. Naja...
In dem Zusammenhang, snapshot geht bei mir schon ewig, gibt es unter XAaes ein globales Clipbrd? Bisher funktioniert das Clipboard bei mir nur in wenigen Programmen, eben solche die eine Clipboard-Funktion haben, aber nicht global. D.h. Programme, die das Clipboard nicht unterstützen kann auch XAaes nicht helfen? Also kein Clipboard.prg, das global wirkt? ???
Aber, damit Du nicht aus der Puste kommst und statt zu theoretisieren, wir uns praktischen DIngen zuwenden. Schau mal hier
-
Ctrl-V Ctrl--> ergibt auf der bash:
^[[C;
Ist das jetzt das selbe?
An den Anfang der Zeile kann ich mit Pos1 [d.i. Home] springen, aber leider nicht ans Ende. Weder mit End noch mit irgendwelchen Pfeil-Kombinationen. Hängt natürlich auch mit meiner Non-ATARI-Tastatur zusammen.
Sonderzeichen sind sowieso ein Kapitel für sich. Während in Schreibprogrammen, wie QED und überhaupt unter GEM die Sonderzeichen noch leidlich so, wie auf der tastatur (Notepad-Computer) sind, sind sie in der bash wohl nach englischer Tastatur. Da muss ich doch bestimmt irgendwo in der bash die keytable wechseln?
Das beste ist die META-Taste, praktisch ne Windows-Taste, die gibt einen endlos-repeat von AAAAAAAAAAAAAA aus, der erst durch ESC gestoppt wird. Es ist das A mit Akzent, finde es gerade nicht unter Linux.
-
conholio iconify-bug commited (sagt man so?). Es ist noch immer so, dass wenn man in tw2 oder qed ein Fenster schließt, automatisch die Menüleiste auf den Desktop wechselt.
Icons - besser, aber bist Du damit zufrieden? Oder liegt's an den Icons selber. Vergleiche mal das Floppy mit der Resource in rsm.
Versuchsweise die Zeile kommentiert, kein Unterschied.
#app_options = aessys, thinwork = true, winframe_size = 3, xa_nomove = false, nolive = false, rsc_lang = 1, icn_pal_name = nvdi
Was passiert, wenn ich remap deaktiviere?
Ich habe die Iconifyreihe noch etwas höher gesetzt bottom=32. Von der letzten Sitzung lagen aber noch einige Iconify auf dem Desktop. Nach dem Neustart beginnt die Iconify-Reihe aber wieder bei x=0. So werden die Iconifies bunt durcheinander gewürfelt. Ist das nur ein feature?
Nochwas: Lege ich das Ramdisk-fenster ins iconify und beende Aranym, startet in der nächsten Sitzung ja TeraDesk mit dem Iconify der ramdisk (R:/). Wenn ich jetzt de-iconify, öffnet sich das Fenster. Gehe ich jetzt auf das icon ".." um das directory zu wechseln, verschwindet das Fenster vom Desktop. Das passiert normalerweise nicht.
Am Rande, wie macht man eigentlich unter TeraDesk ein Directory refresh?
-
Also ...
1. Das HW-Icon ist natürlich falsch.Du musst auch angeben, dass für HW umgemappt werden soll. Also am besten unter app_options=default ...
Aber beim Floppy-Icon kann ich keinen Fehler erkennen. Wie sollte es denn aussehen?
2.Wenn teradesk mit ikonifizierten Fenstern startet, gibt's offenbar Fehler mit der Positionierung. Guck ich mal. Das passiert wohl nur, wenn man zwischendurch die Position verändert, naja ein kleiner bug.
3.Das mit der ramdisk: Das Fenster mit R:\ ist bei mir komplett leer. Wo willst Du da klicken?
4, Die Esc-Sequenz ist richtig. Ich würde Zeile Anfang/Ende auf Shift-Cursor legen (also Esc-c, Esc-d), und next/previous word auf Ctrl-Cursor. Spezielle Sondertasten wie windows-Taste gehen nicht.
5.Warum setzt Du nicht clipbrd=/host/clipbrd oder so? Dann kann man zwischen host und atari hin-und her-kopieren.
6. Das mit dem Menu kann ich nicht reproduzieren.
7. Mit snapshot meinte ich die snapshots von freemint.org.
-
Also ...
1. Das HW-Icon ist natürlich falsch.Du musst auch angeben, dass für HW umgemappt werden soll. Also am besten unter app_options=default ...
Verstehe ich nicht wirklich, muss ich denn für jedes Programm ne extra Palette angeben, oder was soll ich da einstellen
Aber beim Floppy-Icon kann ich keinen Fehler erkennen. Wie sollte es denn aussehen?
Das siehst Du doch, wenn Du es mit dem Floppy aus rsc-Datei vergleichst, bzw. mein Bild mit dem grünen Untergrund. Der untere rote Strich ist doch kurrupt. Er muss durchgehend rot sein, in meinem Anhang hat er eine weiße Unterbrechung. Nur der genaue Vergleich mit der rsc zeigt, wo noch was verstellt wird beim remapping.
2.Wenn teradesk mit ikonifizierten Fenstern startet, gibt's offenbar Fehler mit der Positionierung. Guck ich mal. Das passiert wohl nur, wenn man zwischendurch die Position verändert, naja ein kleiner bug.
Ich dachte sogar, dass das ein feature ist.. Dass es gar nicht vorgesehen ist, dass sich die Iconify-Reihe über einen Neustart hinaus gemerkt wird.
3.Das mit der ramdisk: Das Fenster mit R:\ ist bei mir komplett leer. Wo willst Du da klicken?
Nein, ich habe doch dieses Icon in jedem Fenster für eine Ebene zurück ".." Manche haben dafür auch einen geschwungenen Pfeil. Das heißt irgendwie unix-style. Ich klicke meist darauf, um eine directory refresh zu erzwingen. Etwas umständlich erst eine Eben höher und dann wieder rein in den Ordner. Weil ich halt nicht weiß, wie man einen refresh macht. Automatisch kriegt ja leider TeraDesk garnichts mit.
Mmmmh, scheint auch ein feature zu sein, da es ja bei der ramdisk keine höhere Ebene gibt, schließt sich das Fenster. Es sollte höchstens u:/ kommen. Aber das funktioniert ja bei keinem anderen LW so (außer u:/ natürlich). Ich hänge trotzdem mal nen snap davon an.
Zur Erläuterung: ich mache filemanagement oft auf der Console, oder sogar im Host und das Fenster von TeraDesk bekommt Veränderungen von Außen nicht mit. Es gibt also kein autorefresh oder sowas.
4, Die Esc-Sequenz ist richtig. Ich würde Zeile Anfang/Ende auf Shift-Cursor legen (also Esc-c, Esc-d), und next/previous word auf Ctrl-Cursor. Spezielle Sondertasten wie windows-Taste gehen nicht.
Was heißt denn legen, wie mache ich das? Und bash ist ja wohl noch eine andere Geschichte. Deine Shortcuts finde ich gut, weil alte Atari-Gewohnheit.
5.Warum setzt Du nicht clipbrd=/host/clipbrd oder so? Dann kann man zwischen host und atari hin-und her-kopieren.
Das habe ich nie verstanden, wie das geht - wäre natürlich die Wucht. aber ich wäre schon froh, wenn das Clipboard in allen Programmen funktionieren würde.
6. Das mit dem Menu kann ich nicht reproduzieren.
Du meinst diesen Satz Es ist noch immer so, dass wenn man in tw2 oder qed ein Fenster schließt, automatisch die Menüleiste auf den Desktop wechselt.? Bei Dir springt der Focus nicht auf den Desktop, wenn Du ein Fenster schließt? Das ist bei mir immer so. Und meiner Meinung nach dürfte das erst dann passieren, wenn man in den Desktop klickt. Ansonsten sollte man schon in dem Programm bleiben, indem man ein Fenster geschlossen hat.
7. Mit snapshot meinte ich die snapshots von freemint.org.
Du meinst die daily builds von freemint org. Achso, das geht bei DIr jetzt, schön.
-
Hat vielleicht das was mit dem Fokusproblem zu tun?
# clwtna = <value> default: 1
# (Close Last Window Tops Next App)
#
# Selects what to do when the last window of a client on top is closed.
# This argument takes a value, 0, 1 or 2, which have the following
# meaning;
#
# 0 - This keep the client whose last window is closed from being
# untopped. This prevents XaAES from topping another
# application when the last window it owns is closed.
# 1 - This will top the owner of the window below the closed
# window. That is, the owner of the window previously ontop
# will be topped. This is the normal behaviour found on
# other AESs.
# 2 - This will top the previously topped client, regardless
# of windows. Even when the previously active client dont
# have any windows, it will get topped.
#
-
Jap, das ist Dein Punkt 6 mit dem wechselnden Fokus.
Und einen manuellen Refresh kann man normalerweise mit [Esc] erzwingen.
Ich würde mal annehmen, daß auch TeraDesk das kann.
-
Bei mir unter Aranym erzeugt ESC kein refresh. Das war natürlich das erste was ich versucht habe.
edit: Das geht jetzt, man muss manchmal etwas beherzter drücken.
So, was also muss ich unter Punkt 6 nun einstellen in der xaaes.cnf damit dieses Verhalten nicht eintritt?
Mmmh, clwtna=0 sollte default sein. Finde ich jedenfalls. 1 und 2 sind Mumpitz.
Helmut zum R:\-LW: Es ist tatsächlich so, dass alle discs im Wurzelverzeichnis keinen " . . " - Eintrag haben, nur bei R:\ ist das so in TeraDesk. Ist das ein bug?
Was ist eigentlich mit dem png mit den Popupmenüs und der verrutschten Überschrift?
Ich habe jetzt die Zeile app_options default, ..., icn_pal...=nvdi aktiviert. Überhaupt kein Unterschied. das Highwire-Icon und das netsurf-Icon sehen krank aus (ich kenne ja das richtige netsurf-Icon, denn netsurf läuft bei mir auch auf dem Host. Achso remap_cicon, schaun wir mal.
Bringt auch nichts, keine Veränderung. Muss ich noch irgendwas laden, oder hast Du was verändert gegenüber 1.5.3 außer mintara.prg, xaaes040.km. Was noch?
Hmm, bringt alles nichts, habe sogar highwire und netsurf eine eigene app_options spendiert. Muss ich da gem-palette einstellen?
Auch clawtna=0 bringt überhaupt keine Änderung, nach dem letzten Fenster landet man auf dem Desktop.
-
Also ...
1. Das HW-Icon ist natürlich falsch.Du musst auch angeben, dass für HW umgemappt werden soll. Also am besten unter app_options=default ...
Verstehe ich nicht wirklich, muss ich denn für jedes Programm ne extra Palette angeben, oder was soll ich da einstellen
Genau! Mit default erwischst Du alle, wie von mir erwähnt, und wie auch in example.cnf dokumentiert.
Aber einige Programme (Highwire, rsm sowieso) nutzen das AES nicht zum icon-mapping, jedenfalls kommt die Funktion garnicht zum Einsatz, da hilft alles nichts, und es ist Glücksache, aber bei 32 bit wird es trotzdem richtig, nur nicht bei 8 bit. Und ich such mir da den Wolf, wieso da nichts gemappt wird :(
Aber beim Floppy-Icon kann ich keinen Fehler erkennen. Wie sollte es denn aussehen?
Das siehst Du doch, wenn Du es mit dem Floppy aus rsc-Datei vergleichst, bzw. mein Bild mit dem grünen Untergrund. Der untere rote Strich ist doch kurrupt. Er muss durchgehend rot sein, in meinem Anhang hat er eine weiße Unterbrechung. Nur der genaue Vergleich mit der rsc zeigt, wo noch was verstellt wird beim remapping.
Der rote strich besteht aus 3 verschieden roten Strichen. Der mittlere ist heller, und so stellt XaAES das auch dar. in pixel_icons ist die Floppy richtig (zumindest der Strich), in cicons falsch. Siehe Bild.
2.Wenn teradesk mit ikonifizierten Fenstern startet, gibt's offenbar Fehler mit der Positionierung. Guck ich mal. Das passiert wohl nur, wenn man zwischendurch die Position verändert, naja ein kleiner bug.
Ich dachte sogar, dass das ein feature ist.. Dass es gar nicht vorgesehen ist, dass sich die Iconify-Reihe über einen Neustart hinaus gemerkt wird.
Das klappt jetzt.
3.Das mit der ramdisk: Das Fenster mit R:\ ist bei mir komplett leer. Wo willst Du da klicken?
Nein, ich habe doch dieses Icon in jedem Fenster für eine Ebene zurück ".." Manche haben dafür auch einen geschwungenen Pfeil. Das heißt irgendwie unix-style. (außer u:/ natürlich). Ich hänge trotzdem mal nen snap davon an.
Also bei mir ist das immer noch leer (4.01). Aber mit teradesk kann ich Dir wirklich nicht auch noch helfen.
4, Die Esc-Sequenz ist richtig. Ich würde Zeile Anfang/Ende auf Shift-Cursor legen (also Esc-c, Esc-d), und next/previous word auf Ctrl-Cursor. Spezielle Sondertasten wie windows-Taste gehen nicht.
Was heißt denn legen, wie mache ich das? Und bash ist ja wohl noch eine andere Geschichte. Deine Shortcuts finde ich gut, weil alte Atari-Gewohnheit.
Über inputrc, haben die doch gerade auf der mintlist durchgekaut. Ich schätze, da muss dann sowas wie:
"\e[C;": forward-word
rein, aber ich benutze keine bash, und ich kann Dir auch da nicht helfen.
5.Warum setzt Du nicht clipbrd=/host/clipbrd oder so? Dann kann man zwischen host und atari hin-und her-kopieren.
Das habe ich nie verstanden, wie das geht - wäre natürlich die Wucht. aber ich wäre schon froh, wenn das Clipboard in allen Programmen funktionieren würde.
Das ist ein echt geiles feature von aranym, müsste auch unter linux gehen, weiß aber nicht genau.
6. Das mit dem Menu kann ich nicht reproduzieren.
Du meinst diesen Satz Es ist noch immer so, dass wenn man in tw2 oder qed ein Fenster schließt,
Nee, ich meinte das mit dem fileslektor hypviewFS.
-
Lies mal nochmal meinen thread, habe einiges ergänzt. Mit der bash ist mir klar, da weiß ich mir selbst zu helfen und werde auch die mailinglist studieren, hinke etwas hinterher.
TeraDesk dürfte zum Release gehören und jeder bug-fix ist nicht für mich! Das gleiche gilt ja für Toswin2, nicht aber für conholio oder rsm - ist schon klar.
Das mit dem " . . " hängt vielleicht mit Aranym zusammen und der ramdisk selbst (/u/ram) und nicht unbedingt ein TeraDesk-Problem.
default habe ich inzwischen eingestellt, app_options auch - wie Du schon sagst highwire schert sich nicht drum.
cicons ist eigentlich das Bild von rsm. Im rsm ist der rote Balken durchgehend. aber ich schau mir das nochmal genau an. Natürlich sieht das Icon jetzt viel richtiger aus, als früher unter gem-palette oder ohne palette.
echt geiles feature
ja, ja, ich weiß, ich muss das aranym-wiki noch durcharbeiten. :-X
Nee, ich meinte das mit dem fileslektor hypviewFS.
Achso, da habe ich wiedermal irgendwohin geklickt. Typisch. Und weiß nicht genau, was ich da gemacht habe. Ich glaube ich habe auf den FS-Close-Button oben links geklickt, aus alter Gewohnheit, ich wollte eigentlich nur eine Eben höher, nicht den FS schließen. Könnte sein, dass ich aus versehen die rechte Maustaste betätigt habe, obwohl das auf meinem mousepad garnicht so einfach ist. Da kamen diese Popups und die verschobene Überschrift (blaue). Aber ich kann das auch nicht reproduzieren. Vielleicht begegnet es mir ja mal wieder.
-
.
Mach mir mal einen screenshot, wie das icon wie es Deiner Meinung nach aussehen soll, und wie es asusieht. Ich hab mal screenshots gemacht mit gem-Palette, und nvdi-Palette. Also ich sehe keine Unterschied!
Ist stelle gerade fest, dass remap_cicons auf das netsurf-icon auch keinen Einfluss hat, kann man nichts machen! Es sieht immer gleich aus. Ich weiß auch nicht, ob die iconify-icons überhaupt dieser Prozedur unterzogen werden.
-
rsmfloppynvdi32.png
Du hast zwar recht mit dem dreifach geteilten Balken, aber bei mir sieht der im Resourcemaster-Editor so aus
(die starke Rasterung muss irgendwie vom xa_snap.prg herrühren, die ist nicht im rsm) Aber die Farbe ist grün zu meiner Überrschung. Denn in der Vorschau im rsc ist sie rot.
edit: Die Rasterung ist nur ein moiré-Effekt in der verkleinerten Darstellung von Gimp. Hat keinen Einfluss auf die Datei selbst.
-
Ja - und rot ist auch richtig, oder? Ich hatte immer nur rot.
-
Doppelpost gelöscht
-
Mach mir mal einen screenshot, wie das icon wie es Deiner Meinung nach aussehen soll, und wie es aussieht. Ich hab mal screenshots gemacht mit gem-Palette, und nvdi-Palette. Also ich sehe keine Unterschied!
Ist stelle gerade fest, dass remap_cicons auf das netsurf-icon auch keinen Einfluss hat, kann man nichts machen! Es sieht immer gleich aus. Ich weiß auch nicht, ob die iconify-icons überhaupt dieser Prozedur unterzogen werden.
Das habe ich doch auch gemacht in allen Varianten. Aussehen dachte ich soll es mit einfachem roten Balken, aber ich sehe, dass Du recht hast. Ich glaube, es hat keinen Sinn, dass Du 32bit Icons erzeugst, die Palette-Fehler sind ja gerade in 256 Farben seit langem bekannt. Ich kenne das noch vom Falcon her.
Mit netsurf sage ich doch die ganze Zeit. Liegt das daran, dass netsurf kein iconremapping macht?
Und so sieht ja das Icon auch gar nicht aus, wie Du auf meinem Linux-Desktop erkennen kannst (Du siehst dort ist alles wie unter ATARI ;)
-
Und wo soll da jetzt ein Unterschied zu meinem screenshot sein?
-
Sprichst Du von netsurf? Vermutlich siehts unter 32 k gleich aus, denn unter Linux habe ich natürlich truecolor. Es ist eine hellblaue leuchtende Farbe mit gleichmässigen übergängen und dem Lichtreflex, während auf aranym und in Deinen Snapshots bei mir (die Snaps gucke ich mir aber auf dem Linux an) das Hellblau eher graublau ist und die Übergänge mit schwarzen Pixeln verpixelt sind.
mach mal jpgs.
-
Das geht eben mit 8 bit nicht besser, hat nichts mit der Farbtiefe zu tun, icons sind immer max. 8 bit beim atari.
Den Unterschied sehe ich natürlich auch!
Wieso soll ich ein anders Format nehmen, was soll das bringen?
Ich muss mich übrigens korrigieren: NS wird doch umgemappt, ich hatte eine veraltete Version probiert, auf die Icons hat das aber offenbar immer noch keinen Einfluss.
-
Weis ich auch nicht. Ich denke ja auch, dass die Icons nicht besser gehen unter 256 Farben. Sie sollten dafür neu designed werden.
Hier noch mal nebeneinander im Bildschirmfoto. Leider kann ich unter Linux keine Ausschnitte machen. Bin froh, dass ich den Bildsnapshot beherrsche und mit Gimp komme ich auch nicht so zurecht. Bin halt Photoshopverdorben.
-
So ist das korrekt.
Mit snapsaver kann ich unter windows ganz prima snapshots machen. Sind gleich ein paar Anregungen für XaAES drin :)
Soeben stelle ich auch noch fest, dass ns selbständig die Farbpalette umstellt nach seinen Vorstellungen, da kann man natürlich alle Klimmzüge in XaAES vergessen.
-
Apropos. Ich weiß, es hat nichts mit XAaes zu tun. Darf ich das icon von highwire verändern?
Wie kommt es, dass im rsm das Icon in der Objektvorschau noch einigermaßen aussieht, im Bildeditor aber nicht mehr, sondern irgendwie verpixelt? Ich würde hier ein verbessertes 256-Farben-Design herstellen.
-
Das Highwire Start-Icon sieht bei mir unter verschiedenen Konfigurationen (MagiC/ MiNT/ Jinnee/ Gemini/ Nvdi3/ 4/ 5) nicht immer optimal aus.
Die verschiedenen Konfigurationen scheinen sich mit unterschiedlichem Erfolg um das Vorrecht, die Grafikpalette setzen zu dürfen, zu streiten.
Mit MagiC/ Jinnee sieht es immer gut aus, wenn MiNT ins Spiel kommt, wird's problematisch, weil MiNT anscheinend NVDI den Vortritt läßt. Ganz sicher bin ich aber nicht, wer denn nun letztendlich welche Palette setzt.
Ich habe das schon vor Jahren mit AltF4 ausprobiert, weil ich keinen Bock auf Grünstich in Gesichtern hatte und wissen wollte, woran das liegt.
Grundsätzlich scheint es an der Systempalette von Nvdi zu liegen, die sich zwischen 3, 4, und 5 jeweils verändert. MagiC scheint das zu korrigieren, MiNT eher egal zu sein, wobei auch Jinnee nochmal einzugreifen scheint, so daß es unter MiNT doch vernünftig aussieht.
Alles sehr merkwürdig...
-
Absolut Nein! Wir haben ja herausklabüsert, dass das Icon unter XAAES, egal welche Palette geladen wird, auch mit app_options nicht besser aussieht.
Einfacher workaround: In der Icondarstellung die 256 Farben-Version löschen und stattdessen evtl. das 256-Farben-Icon aus dem 4-Bit-Icon neu erzeugen. Damit hatte ich Erfolg und nun zumindest für das Desktop-Icon unter TeraDesk eine passable Lösung erzeugt.
Aber für das iconify scheint das nicht zu funktionieren. ich bastle noch dran. Ich kann nicht herausfinden, woher das iconify sich das Bildchen holt? Ich finde es nirgendwo, nachdem ich in der deskicon.rsc das 256-Farb-Icon entfernt habe. Dennoch sieht es im Iconify so aus wie früher. Wird da noch was remapped?
Helmut wird bestimmt mehr dazu sagen können. Im Falle von Netsurf befindet sich das Deskicon nur in der globalen Resource-datei netsurf.rsc (im Ordner res). Der zweite Tree enthält das Icon. Merkwürdiger Weise wird das vorhandene 256-Farb-Icon garnicht verwendet unter xaaes, sondern nur das 4-Biticon das entsprechend mau aussieht.
Das ist bei highwire anders, wo, jedenfalls bei mir, das schlecht aussehende 256-Farb-Icon verwendet wurde, während das 4-Bit-Icon zumindest richtiger aussieht.
-
Einen habe ich noch, wenn ich rsm beende und er nachfragt, ob er Änderungen speichern soll, ich dann verneine. Gibt es einen feinen Buserror. Siehe Anhang. Kommt manchmal, nicht immer vor. :-\
FS-Designfehler:
Wenn in der FS Editzeile eine konkrete Datei steht. Ich nun einen weiteren Ordner öffne (abtauche), wird die Editzeile gelöscht. Dieses Verhalten ist nicht sehr hilfreich, da man oft noch den Pfad ändern will, obwohl der filename bereits stimmt, z.B. beim Speichern. So hat sich in modernen GUIs eingebürgert, die Editzeie nicht automatisch zu löschen, wenn das Directory gewechselt wird. :-*
Wegen der Icons, habe ich einstweilen aus der rsc das icon als Deskicon.rsc abgespeichert und daraus das icon der cicon.rsc hinzugefügt, sodass ich es auf dem teraDesk anzeigen kann (4-Bit-icon).
Xaaes scheint sich zu weigern, das 256-Farb-Icon anzuzeigen (netsurf), im Falle von Highwire wird aber offenbar das 256-farb-Icon angezeigt, welches halt sehr unglücklich aussieht. Hier bringt das 4-Bit-Icon mehr.
Gleich kommen die Snapshots. Und siehe da, das Netsurf-Icon sieht plötzlich so aus wie unter Linux. wie ich das hinbekommen habe, ist hier beschrieben. Warum das aber so ist, verstehe ich nicht.
(http://forum.atari-home.de/index.php?action=dlattach;topic=10117.0;attach=4049)
huch, jetzt kann ich es auch. :D
Im iconify aber erscheint das icon in falscher Palette, d.h. das hellblau ist falsch und die weißen Pixel erscheinen grau.
(http://forum.atari-home.de/index.php?action=dlattach;topic=10117.0;attach=4057)
-
Was auch noch grauenhaft aussieht, insbesondere das 48er Icon ist die anhängende deskicon.rsc von gemclip. Das 32er Icon ist wohl palettemäßig i.O., aber kein schönes 3D-Icon. das 48er erscheint wieder in verpixelter oder vermüllter Palette.
Einfach pdf in rsc umbenennen.
-
Noch einer. Es ist ein schönes Feature, dass FS den Pfadgrap beherrscht. Also Datei: Pfad und Filename kopieren. Was ist aber mit dieser Baumdarstellung. Schon, dass ich es ungewöhnlich finde, dass man unter dem ". ." eine Baumdarstellung des Eltern-Directory sieht, wenn man den Pfad einer Datei dort graped, dann ergibt sich diese etwas merkwürdige, wenn auch nicht falsche Pfadschreibweise, hier im Beispiel
C:\rsmaster\patterns\..\rsm.rsc
schöner, korrekter, besser wäre doch aber
C:\rsmaster\rsm.rsc
(http://forum.atari-home.de/index.php?action=dlattach;topic=10117.0;attach=4055)
-
Helmut, kannst Du dich nicht doch dazu durchringen, etwa diese Breite als Default im FS ein zu stellen? Oder kann man da nicht einen Parameter angeben? :-*
-
Wie hast Du das mit dem .. denn hinbekommen?
Häng doch mal die cicons.rsc mit den HW-und NS-icons (in 8 bit) an. Und ein snapshot wie es richtig ausshen sollte.
Dass iconify-icons nicht umgemappt werden, haben wir ja schon erkannt.
-
Lies es nochmal, ich hab's beschrieben. Trial and Error oder sowas, verstehen kann das niemand. Metaphysik halt.
Entscheidend war, dass ich das icon aus der netsurf.rsc extraiert habe und als desicon.rsc abgespeichert. dann in cicon.rsc importiert. alles unter rsm. Vielleicht macht der's ja richtig. Dann das icon in TeraDesk ausgewählt. Es hat nur leider keine auswirkung auf das Iconify. Und es ist das 4-Bit-icon, das 8-Bit im rsm hat noch rot und orange mit drinne, wird aber von TeraDesk gar nicht geladen.
-
Häng doch mal die cicons.rsc mit den HW-und NS-icons (in 8 bit) an.
Im falle highwire muss ich Dich bitten aus dem Originalarchiv die Datei Deskicon.rsc zu nehmen, da ist ein 8-Bit und ein 4-bit drin. Das 8-Bit sieht bei mir scheußlich aus, genau wie im iconify, das 4-bit sieht so aus wie auf dem snapshot oben.
netsurf hänge ich Dir an als pdf, einfach in rsc umbenennen.
snapshots siehst Du weiter oben und hier:
oben richtig, unten falsch, aber wer weiß, vielleicht soll das H-icon so aussehen? ???
(http://forum.atari-home.de/index.php?action=dlattach;topic=10117.0;attach=4060)
-
Ich brauch das aber in der Form cicons, da das ja sonst sowieso nicht umgemappt wird.
Das untere HW-Icon ist bei Dir wohl falsch, bei mir sieht es aus wie das obere (nach iconify).
Mit palette=nvdi bekomme ich dann:
(http://forum.atari-home.de/index.php?action=dlattach;topic=10117.0;attach=4063)
Mit palette=gem:
(http://forum.atari-home.de/index.php?action=dlattach;topic=10117.0;attach=4065)
Die filenamen sind durcheinander, man sieht es aber an der Titelfläche und der Hintergrundfarbe.
-
So, dann funktioniert das also nur bei mir nicht richtig. Was heißt in der Form cicon.rsc, das ist doch nur der Name für die TeraDesk Resourcedatei? Die desicon.rsc ist doch genau das selbe. Ich kann Dir jetzt meine cicon.rsc geben, aber die ist schon bearbeitet. Beim highwire ist nicht mehr das originale highwire-8-bit drin. Das musst Du Dir dann selbst einbauen.
Verstehe wer will.
-
Ich bin hartnäckig und kehre zum Floppy-Icon zurück.
Genaugenommen sieht es im rsm in der 4-Bit Darstellung so aus:
(http://forum.atari-home.de/index.php?action=dlattach;topic=10117.0;attach=4070)
mit durchgehendem roten Balken.
Und als 8-Bit-Icon mit unterbrochenem Balken in 3 Farben (Atari-Disk-Label). welche wohl rot/orange/rot sein müssen im rsm bei mir unter 256 Farben aber irgendwas mit grüntönen sind.
(http://forum.atari-home.de/index.php?action=dlattach;topic=10117.0;attach=4072)
Ergo, irgendwann früher hatte ich auf meinem Desk das 4-Bit-Icon, später stellte es sich aber als 8-bit dar, nachdem ich wahrscheinlich das Mapping eingeschaltet, app_option?
(Das raster von dem ich sprach, man sieht es hier nicht, war nur ein moiré Effekt von der verkleinerten Darstellung (66%) in gimp.)
-
Wen es interessiert, das hier funktioniert großartig:
#####################################################################
# xa_bubble (default:0)
# if you want to use the XaAES-builtin bubble-help (since 1.1.21) set
# this.
# 1: windows-tooltip-style
# 2: apple-ballon-help-style
xa_bubble = 2
#####################################################################
# describe_widgets (default:0)
# if set not 0 display name/function of a widget when the mouse is
# placed (not moved) twice above a widget.
# 1: windows-tooltip-style (recommended)
# 2: apple-ballon-help-style
describe_widgets = 2
#####################################################################
-
Hier läuft was ganz verquer, und zwar vermutlich mit dem rsm, der scheint seine eigene Palette zu wollen. Dieses Icon selbstgebastelt, ich habe gewiss gelb ausgewählt. Es erscheint aber olivegrün. Nun ist nur die Frage, ob hier das 4-bit oder das 8-bit-icon geladen wird. Vermutlich letzteres wegen der 256 Farben. Es ist natürlich essentiell, wenn der rsm was anderes macht, als TeraDesk
(http://forum.atari-home.de/index.php?action=dlattach;topic=10117.0;attach=4074)
Nach einigen Wiederholungen und Proben wars schon besser, aber grün
(http://forum.atari-home.de/index.php?action=dlattach;topic=10117.0;attach=4075)
Das selectierte Icon sieht nun korrekt aus. Kann das was mit der cicon.rsm Datei zu tun haben? Berücksichtigt TeraDesk die?
(http://forum.atari-home.de/index.php?action=dlattach;topic=10117.0;attach=4076)
-
Der blaue Schatten könnte von dem aranym-Fehler kommen, den hab ich ja nicht.
Aber das Grün im floppy-icon ist wirklich komisch. Auch die Palette, die rsm rechts zeigt, ist anders als bei mir. Keine Ahnung, wo das herkommt, bei Truecolor dürfte sowas nicht vorkommen.
(http://forum.atari-home.de/index.php?action=dlattach;topic=10117.0;attach=4077)
-
Der blaue Schatten war auch im select-Icon. Und es ist kein Schatten, sondern genau die Grenze der Fläche, die ich mit Hilfe des Kännchens gefüllt habe in einer Farbe die 100% identisch aussah wie das umliegende Gelb (das blaue Fragezeichen hatte ursprünglich einen weißen Hintergrund und wurde mit Hilfe der Blockfunktion aus einem anderen icon ausgeschnitten, daher die farbgrenze). Aber offenbar ist es eben nicht genau die gleiche Farbe in den 256 Farben, nur dass man das in rsm nicht sieht. Beim zweiten Versuch habe ich dann die gesamte gelbe Fläche mit dem Kännchen nochmal gefüllt. Prompt war alles olivgrün, aber nicht im rsm. Es gibt, und das haben wir ja schon früher festgestellt, einfach einen Unterschied in der Darstellung zwischen rsm und TeraDesk. Man müsste nun Tests mit think machen, Konsorten. dazu bin ich aber derzeit nicht in der Lage. Geenee soll es ja nochmal anders machen. Siehe auch Beitrag von Jens.
Es hat auch gar keine Ähnlichkeit mit dem Blue-Icon-Bug.
Deine Palette im Bild ähnelt dem, was ich von der gem-palette beim Hades her in Erinnerung habe (oder war's auf dem Falcon?), während bei der nvdi-palette gleichmäßige Übergänge sichtbar sind, keine Farbsprünge, sind beim gem-palette Treppen sichtbar. Die Farbanordnung ist grundsätzlich verschieden und ist am Muster erkennbar. Mir scheint auch, dass das Farbspektrum verkehrt herum angeordent ist.
man müsste Tests mit einem Farbkeil, bei dem die 256 Farben nummeriert sind, machen, um zu sehen, dass genau die gleichen Nummern ausgewählt werden, von Teradesk und rsm, sowie Interface. Habe ich derzeit nicht zur Verfügung, schlummert aber irgendwo auf einem Atari-Medium hier.
-
Floppy-Icon:
So wie Dein Floppy-icon erscheint, sieht es auch ungefähr auf meinem Desktop aus (jetzt, war früher anders, wohl fehlendes Mapping). Aber in rsm sieht es so aus, wie ein paar Bilder weiter oben mit olivgrünen Farben.
Was meine Theorie bestärkt.
-
Die da lautet? Nach meiner Theorie zeigt rsm immer die gleiche Farbpalette rechts an bei true-color. Er kann doch da einstellen was er will, technisch gesehen. Oder ändert sich bei Dir da was, je nachdem was bei palette= in xaaes.cnf steht?
Bei Dir zeigt er die fvdi-default-Palette, die man erhält, wenn man in xaaes.cnf kein palette= setzt.
(http://forum.atari-home.de/index.php?action=dlattach;topic=10117.0;attach=4079)
-
Meine Theorie heißt, dass ein Unterschied in der Darstellung zwischen rsm und TeraDesk besteht (schrieb ich oben mehrfach). Mit einem anderen Programm habe ich ja keine Tests gemacht.
In rsm habe ich keinen Unterschied bemerkt, insofern hast Du vielleicht recht. Nur getestet habe ich das nicht. Das Problem besteht immer nur in 8-bit. Mir ist das generelle Palette-Problem seit langem bekannt, das war unter dem Hades genau so. Beim Falcon mit CT60 hatte ich wohl schon truecolor.
Macht der rsm überhaupt 16bit oder 32bit Icons?
fvdi-default: Also doch eine default-palette, eine dritte? Wie hast Du die denn dargestellt, mit welchem Programm?
in meiner xaaes.cnf ist aber
palette = nvdi
app_options = default,thinwork = true, winframe_size = 2, xa_nomove = false, nolive = true, icn_pal_name = nvdi
app_options = xasys, thinwork = true, winframe_size = 2, xa_nomove = false, nolive = false
app_options = aessys, thinwork = true, winframe_size = 2, xa_nomove = false, nolive = false, rsc_lang = 1, icn_pal_name = nvdi
app_options = highwire, winframe_size = 0, icn_pal_name = nvdi
app_options = netsurf, winframe_size = 0, icn_pal_name = nvdi
Muss ich das nun noch für TeraDesk setzen?
-
Bei Dir zeigt er die fvdi-default-Palette, die man erhält, wenn man in xaaes.cnf kein palette= setzt.
Stimmt genau, sehr merkwürdig. Mag rsm vielleicht keine andere Palette? Oder verhindert aranym oder Fedora das Verstellen der Palette?
Ich teste das mit dem rsm nochmal.
-
Meiner Meinung nach liegt das erstmal an rsm. Der zeigt bei mir rechts immer das selbe bei true-color, egal welche Palette ich eingestellt hab, auch wenn ich sie gar nicht setze.
Natürlich kann rsm nur max. 8bit-icons.
Ich weiß leider nicht mehr, wie genau ich die erzeugt hab, aber ich meine ich hab sie mal irgendwie ausgelesen.
Angezeigt hab sie oben mit cxsu_pcn aus dem Matrix-Paket.
Wäre natürlich auch möglich, dass der host da irgendwie reinfunkt, dann wäre aber grundsätzlich was falsch, oder fehlend.
-
Neuigkeit:
Wenn ich nur palette= wegkommentiere, also gar keine palette, = default fvdi,
Ist das icon auf dem Desktop gelb (und nicht olive).
Ich meine auch, dass es an rsm liegt, der berücksichtigt einfach die xaaes Palette= Einstellung nicht, steht permanent auf fvdi, was unter palette=nvdi bei TeraDesk natürlich zu Problemen führt. Unter default-palette ist sofort wieder das Xaaes-Logo Problem da.
Vermutung, wir haben es hier nicht mit einem Xaaes-Problem zu tun, sondern mit einem rsm-Problem. Hat jemand Interface und kann das nachvollziehen?
Das Matrix-Paket habe ich natürlich nicht, hatte ich nie.
Unter der fvdi-palette habe ich sofort auch Netsurf-Icon in bunt (8-Bit) und das floppy und das clipboard hat falsche farben.
(http://forum.atari-home.de/index.php?action=dlattach;topic=10117.0;attach=4081)
rsm zeigt die Palette unverändert.
-
Mit ohne palette= wird ja nicht umgemappt, und somit ist das Ergebnis zufallsbedingt.
Man sollte irgendwie die Palette, die rsm benutzt, in rsm einstellen können, aber da kenn ich mich nicht aus.
Die Matrix-Software kann man irgendwo komplett runterladen, das tool hab ich mal hier:
http://home.arcor.de/zabruder/atari/tools/cxsu_pcn.gz
abgelegt. Das funktioniert aber nur bei 8 bit und kleiner richtig, aber zum Anzeigen reicht es immer.
Resource-file:
http://home.arcor.de/zabruder/atari/tools/cxxsetup.rsc.gz
-
Danke erstmal, werde ich mich mit beschäftigen.
Nächster Schritt: palette = gem
(Aber bei app_options nichts verändert , also nvdi)
XAAES Logo ist korrekt, genau wie nvdi.
auf dem Desk sind die Icons wie nvdi, also floppy, clipbord ist ok rot/orange und netsurf ist korrekt hellblau. HYP ist olive, aber nicht ganz das gleiche.. (offenbar durch app_options werden hier die Icons auch auf nvdi eingestellt)
rsm hat die gleiche Palette unverändert
(rsm scheint in seiner Vorschau, also die box wo alle Icons sichtbar sind, in 4-bit anzuzeigen, daher meine Verwirrung früher mit dem durchgehend roten Balken, netsurf sieht in 4-bit nicht gut aus! Das rot ist bei allen Icons eine Nummer zu rot im rsm)
Mit rsm und ob evtl. app_option bei rsm was bringt, teste ich später.
(http://forum.atari-home.de/index.php?action=dlattach;topic=10117.0;attach=4083)
-
Bei palette=nvdi sehe ich keinen Unterschied zu gem. In rsm erscheint die Palette unverändert.
Das kann aber nun mit app_options zusammenhängen und das teste ich noch.
Setze ich auch app_options auf icn_pal_name = gem, so gibt es geringfügige Unterschiede. schwärzere Konturen, clipbrd ist falsch, netsurf sieht schlechter aus. Das XAAES-Logo erscheint ebenfalls falsch (pixelig und schmutzig). HYP ist olivegrün. rsm ist unverändert.
app_options = rsm, thinwork = true, icn_pal_name = nvdi
bringt keine Veränderung.
-
Tja, kann ich rsm wegwerfen. Ich bin ziemlich ratlos. Der Hypertext gibt nichts her über die Behandelung der Palette. Eine Einstellmöglichkeit finde ich nicht, einen anderen Iconeditor habe ich nicht.
Werde ich wohl drauf verzichten müssen.
-
WORKAROUND:
Auch hier umgeht man das Problem, wenn man nur Farben aus der 4-Bit Palette benutzt. Das scheint zu funktionieren. Jedenfalls ist mein HYP-Folder-Icon jetzt gelb. 8)
-
Starte mal fvdi in 8 bit. Dann zeigt rsm im Bildeditor die Systempalette an, und benutzt die auch. Lade ich fvdi.pal, sieht das floppy-icon genauso grün aus, wie bei Dir. Vielleicht kannst Du ja in 8 bit die 8 bit-Icons editieren, wenn die Ziel-Palette als Systempalette geladen ist.
Wie man rsm sagt, welche Palette er jetzt nehmen soll, würde mich allerdings schon interessieren.
-
Starte mal fvdi in 8 bit.
Wie mache ich das? Die eingestellte Auflösung ist bei mir 256 Farben.
Dann zeigt rsm im Bildeditor die Systempalette an, und benutzt die auch.
Das haben wir ja nun herausgefunden.
Lade ich fvdi.pal, sieht das floppy-icon genauso grün aus, wie bei Dir.
commited. 8) Aber woher hast Du fvdi.pal? Ich hab nur nvdi.pal, nvdi5.pal, gem.pal (das nvdi5 ist wohl eine Varianate vom Hades)
Vielleicht kannst Du ja in 8 bit die 8 bit-Icons editieren, wenn die Ziel-Palette als Systempalette geladen ist.
Das entspricht der Stecknadel im Heuhaufen. Da muss ich die Farben raten. Bei Problemfällen hilft nur die 16-Farben-Palette. Ansonsten nur Icons der Zielpalette verwenden = nvdi.pal
Wie man rsm sagt, welche Palette er jetzt nehmen soll, würde mich allerdings schon interessieren.
Mich auch. Der Farbkeil im Iconeditor ist nicht einmal in der rsc zu finden. Er wird also irgendwie im binary erzeugt.
Was passiert eigentlich, wenn man fvdi die Palette laden lässt? Ich glaube bei mir wird dann die ganze Auflösung verstellt (Größe).
Kennt jemand noch einen anderen Icon-Editor?
-
Irgendwo in fvdi.sys steht sowas:
01r aranym.sys mode 1280x1024x8@72 assumenf irq accelerate xxxxxxx
Entscheidend das x8, der Rest ist egal glaub ich.
Dann z.B. nvdi als Systempalette laden, Icons editieren, in 32 bit mit nvdi-Palette booten, es soll dann genauso wie in 8 bit aussehen. Vielleicht klappt's ja.
rsm muss irgendwo die Information über die icon-Palette hernehmen, vielleicht nimmt es irgendwas von C:\.
fvdi.pal kann man mit dem Matix-tool erzeugen, ich hab sie angehängt.
-
Nein, das geht garnicht, wenn ich in fvdi.sys die Palette lade, z.B. nvdi, dann wird meine ganze Aranym-Einstellung verstellt, die config nicht richtig ausgewertet. grapmouse ist plötzlich wieder da, der Bildschirm ist zu klein, die Maus viel zu schnell usw. Geht nicht, werde ich krank. Ich habe es bisher ja auch nicht geschafft die Bildschirmgröße individuell einzustellen, ich brauche es etwas kleiner als 800x608 und das kriege ich nicht hin. Autozoom ist aber aktiv. Hier müssten mal Aranym-Experten ran.
Ich muss ja eigentlich die Auflösung über den Aranym-Dialog einstellen und in der config gibt es sowas:
[VIDEO]
FullScreen = No
BootColorDepth = 8
Irgendwo in fvdi.sys steht sowas:
01r aranym.sys mode 1280x1024x8@72 assumenf irq accelerate xxxxxxx
Entscheidend das x8, der Rest ist egal glaub ich.
Ja hab ich gefunden und ist bei mir auf 16 eingestellt. Aber das gibt es insgesamt drei mal, wohl für OpenGL, was ich noch nicht probiert habe. Dort ist dann 32 angegeben. Bei mir steht auch 32, die 16 war auskommentiert.
Dann z.B. nvdi als Systempalette laden, Icons editieren, in 32 bit mit nvdi-Palette booten, es soll dann genauso wie in 8 bit aussehen. Vielleicht klappt's ja.
in xaaes.cnf?
In 32bit habe ich Aranym noch nie laufen lassen. In Aranym ist 256 Farben eingestellt. Aber ich habs ausprobiert mit 8 in fvdi.sys. Ist die Iconübersicht in rsm zumindest wohl unter 256 Farb-Icons, denn nun sind all die roten Kreuze und Striche orange, und das ist in bestimmten Icons die 256-Farbdarstellung. Nun schau ich mal weiter
Juhu!!! iconedit hat die Treppen, also wohl nvdi-palette aus xaaes.cnf.
Sieht irgendwie alles noch besser aus. :o
rsm muss irgendwo die Information über die icon-Palette hernehmen, vielleicht nimmt es irgendwas von C:\.
Ich nehme mal an das ist hardcoded im binary. Und nichts vom system.
fvdi.pal kann man mit dem Matix-tool erzeugen, ich hab sie angehängt.
Danke erstmal, ich muss mich wohl vorher intensiver mti Aranym beschäftigen, bevor ich das alles bewältige. :-[
-
Das sieht schon recht schick aus, das hätte ich gerne auch so auf meinem TT laufen, aber keine Ahnung ob ich die Installation hinbekäme, ich weiß ja nichtmal was für Files ich dafür bräuchte...
-
Also leider ist es dann wieder essig, wenn ich auf 32 zurücksetze. Vorher machte TeraDesk den Auswahlbalken in den files blau, jetzt ist er wieder schwarz. Und rsm hat wieder die fvdi.pal im Farbkeil. >:(
Kann man vielleicht rsm beibringen mit 8 zu starten? So über app_options oder so was? Dann wäre man ja aus dem Schneider, was die Icons betrifft. Und sicher hat das für die andern Widgets und Objekte auch keine negative Auswirkung, oder gibt's dann Probleme mit texture? ???
Die CICONS.RSC habe ich natürlich gespeichert, das ist ein umständliches aber mögliches Verfahren.
Auf jeden Fall geht es nicht in fvdi.sys die palette einzustellen. ::)
-
@oneSTone o2o hast Du denn freemint am laufen? Du musst das neueste Paket aus dem daily bild downloaden. Link findest Du im Firebee Thread oben. Da ist auch das neueste XAaes drin, Vorstufe zum nächsten release 1.18. Läuft unter Beta, die 1.19-cur
-
Damit's nicht langweilig wird. Gemclip macht komische Redraw Sachen. Schätze aber, ist selbst dran schuld.
(http://forum.atari-home.de/index.php?action=dlattach;topic=10117.0;attach=4086)
-
Also leider ist es dann wieder essig, wenn ich auf 32 zurücksetze. Vorher machte TeraDesk den Auswahlbalken in den files blau, jetzt ist er wieder schwarz. Und rsm hat wieder die fvdi.pal im Farbkeil. >:(
Kann man vielleicht rsm beibringen mit 8 zu starten? So über app_options oder so was? Dann wäre man ja aus dem Schneider, was die Icons betrifft. Und sicher hat das für die andern Widgets und Objekte auch keine negative Auswirkung, oder gibt's dann Probleme mit texture? ???
Die CICONS.RSC habe ich natürlich gespeichert, das ist ein umständliches aber mögliches Verfahren.
Auf jeden Fall geht es nicht in fvdi.sys die palette einzustellen. ::)
Die Farbtiefe lässt sich nur in fvdi.sys einstellen, das geht nicht für jedes Programm extra, ist doch wohl klar!
Bei 8 bit-video zeigt rsm die Systempalette an. Man kann die auch nachträglich jederzeit mit Ctrl-Alt-Shift-P laden, und die Farbpalette im Bildeditor ändert sich entsprechend.
Welche Farbtiefe aktiv ist, sieht man im Systemfenster (Ctrl-Alt-B) unter System->Video.
-
Was ein Krampf mit den Paletten. Für jede Farbtiefe eine eigene Resourcedatei würde das Problem ja auch nicht ändern, oder?
-
Nein. Man kann entweder die Resourcen für höhere Auflösungen durch die für niedrige Auflösungen ersetzen, oder man muß basteln, bis es paßt.
-
Die Farbtiefe lässt sich nur in fvdi.sys einstellen, das geht nicht für jedes Programm extra, ist doch wohl klar!
Klar!
Bei 8 bit-video zeigt rsm die Systempalette an.
Aber warum nur da?
Man kann die auch nachträglich jederzeit mit Ctrl-Alt-Shift-P laden, und die Farbpalette im Bildeditor ändert sich entsprechend.
Passiert bei mir garnichts. D.h. im Vorschaufenster von rsm tut sich sehr wohl was (hellroter Rasterhintergrund wird zu weinrotem Raster), aber der farbkeil im Iconeditor bleibt immer auf fvdi.pal, egal ob ich nvdi.pal oder gem.pal nachlade, d.h. rote Kreuze im Icon werden unter 256 Farben grün dargestellt. Und in der Vorschau verändern sich dei Icons geringfügig, rote teile werden z.B. dunkler unter nvdi.pal
Das System gibt aus:
video: 800x608x32, 256 Farben, Format MOT
Welche Farbtiefe aktiv ist, sieht man im Systemfenster (Ctrl-Alt-B) unter System->Video.
stimmt genau.
-
video: 800x608x32, 256 Farben, Format MOT
Das ist 32 bit. Da muss 800x608x8 stehen!
-
Das habe ich doch längst wieder umgestellt, um zu sehen, ob es irgendeine dauerhafte Wirkung hat. Ich kann doch nicht von jetzt ab mit 8 leben. Dass es mit 8 funktioniert habe ich ja schon gesagt. Aber da muss man die Palette auch nicht nachladen, denn rsm stellt gleich die systempalette ein, nur eben nicht unter 32. Und das dürfte ein Bug von rsm sein. Genaugenommen steckt der nicht in rsm sondern nur im Editor.
-
Meine Idee war eben, die icons in in 8bit zu erzeugen mit rsm und der gewünschten Palette, und das Ergebnis mit 32 bit zu nutzen, mit der selben Palette, sonst nichts.
-
Das ist problematisch:
8 bit ist Palette (die man selbst einstellen kann), True Colour ist nicht Palette und funktioniert anders.
-
Meine Idee war eben, die icons in in 8bit zu erzeugen mit rsm und der gewünschten Palette, und das Ergebnis mit 32 bit zu nutzen, mit der selben Palette, sonst nichts.
Das habe ich auch verstanden und das haben wir ja auch bewiesen, dass das geht. Sobald ich reduziere, aber ehrlich gesagt habe ich immer auf 16 Farben reduziert, um ein brauchbares Ergebnis zu erzielen. Das ist ein Weg, wenn auch ein umständlicher, um Icons zu erzeugen, oder bestehende zu korrigieren.
Aber ich bin langsam von diesem Aranym bedient, denn nichts funktioniert richtig wie es soll. Jetzt habe ich mir eine keyboard.tbl erzeugt, aber die wird garnicht vom Systempfad geladen. Keine ahnung wo das Tastaturlayout herkommt, wird wohl einfach vom Host durchgereicht? Wobei die Atarianordnung erzeugt wird. Nur meine keyboard.tbl wie ich sie mit KeyEdit erzeugt habe, wird nicht geladen. Ich vermute nun auch, dass auch die normale Keyboard.tbl von xaaes garnicht geladen wurde.
Weiß jemand noch einen anderen Pfad oder muss ich da auch wieder in xaaes.cnf irgendwas eintragen? Bei mir liegt sie in c:/mint/1-19-cur/
-
MiNT lädt keyboard.tbl aus $SYSDIR, was es da macht, müsste im bootlog von MNT stehen.
XaAES erlaubt, die Belegung per hotkey umzuschaten, wie im about-Fenster und in example.cnf angegeben.
Von alleine macht XaAES nichts an der Tastatur.
Das sollte eigentlich alles klar dokumentiert sein.
Ich hab übrigens für aranym die '-Taste mit | belegt, und anderes.
Ich würde in 8 bit die icons erzeugen, und sie dann in einer höheren Farbtiefe benutzen, wenn das geht, was ich ja immer noch nicht sicher weiß.
-
ich werde das noch mehrmals testen. Ich denke, dass es geht, aber sicher kann man nur mit 16 Farbicons sein, wegen der verschiedenen Paletten. Jedoch hatten wir wohl Erfolg damit unter 8-Bit bei richtgier Palette (systempalette) ein Icon zu erzeugen und es dann bei gleicher Palette unter 32 anzuzeigen, ohen Veränderung der Farben.
Das Probelm ist hier nicht xaaes, sondern rsm. Aus welcher Ecke holt sich rsm die fvdi-Palette unter 32-bit, obwohl das system längst eine andere Palette geladen hat? ???
Die keytable sache werde ich weiter untersuchen, aber wieso lädt xaaes nicht automatisch die vorhandene table? Ich dneke aber auch heir, dass es nicht xaaes ist, aondern aranym das klemmt.
z.B. war mir überhaupt nicht bewusst, dass ich ständig unter 32-Bit gearbeitet habe, wie xaaes ja auch richtig ausgibt, weil im aranym-Dialog, wo die Grundeinstellungen vorgenommen werden, die dann in die config-Datei gespeichert werden, immer 256 Farben angezeigt wird (und manchmal nicht einmal das) und auch so von mir ausgewählt wurde. Wer kümmert sich hier um Aranym, da stecken doch die bugs drin. Muss ich da Peter Stelik oder Vincent verständigen?
-
Also Moment mal, dokumentiert in xaaes.cnf ist doch nur, wie man die keyboard.tbl switched, was ich aber gar nicht will und was auch default (aus)kommentiert ist. In dem Fall muss man ja auch die tbl z.B. german.tbl nennen. Was aber ist default?, wird denn da nicht standardmäßig die keyboard.tbl geladen? Wozu muss ich ein shortcut definieren, den ich gar nicht nutzen will? Auch in keyedit steht, dass man die erzeugte table in "keyboard.tbl" umbenennen soll. Hypertext.
Aus dem Hypertext von keyedit:FreeMiNT >= 1.16 will look for a file called keyboard.tbl
in the current system directory, and load this during boot as the
default keyboard layout.
-
Das war doch Sinn der ganzen remap-Geschichte, dass man eben mit jeder Palette alle icons mit jeder anderen Palette laden kann. Müsste mit 8- und 4 bit-icons klappen.
Also ich würde an Deiner Stelle einfach aranym zweimal starten: einmal in 8 bit, einmal in 32 bit, sofern das mit linux möglich ist (24 und 16 würde ich nicht unbedingt nehmen).
Wieso rsm welche Palette benutzt, ist unklar, aber vielleicht findet sich das ja auch irgendwann.
Das mit der keyboard-Tabelle hat nichts mit aranym zu tun. Wenn keyboard.tbl in $SYSDIR ist, wird es auch geladen von MiNT. Falls nicht, poste doch mal die boot.log.
Das VDI versteht eben nur 256 Farben, da bin ich auch schon drüber gestolpert. Alles darüber sind Erweiterungen (NVDI, fvdi).
Und die aranym-Entwicklung würde ich als klinisch tot bezeichnen, da kommt m.E. nicht mehr viel.
Das Umschalten per XaAES dient in erster Linie den Ausländern, die für Spezialzeichen mehrere layouts brauchen.
Mach doch jetzt erstmal die Sache mit den Icons!
-
Poste doch bitte mal, ob und wie ich $SYSDIR definieren kann. Ins boot.log schau ich noch.
Mach doch jetzt erstmal die Sache mit den Icons!
Ja, natürlich, aber versteh bitte auch, dass ich mir so langsam mein System einrichte, damit ich flexibel damit arbeiten kann. Das erleichtert ja auch beim Testen ungemein. Z.B. muss ich mit Tricks bisher immer umschiffen, dass ich nirgends den Backslash auf der Tastatur habe (oder aber irgendwo, wo ich ihn nicht finde). Wenn es irgendwie überall klemmt, dann dreht man sich bald im Kreis.
Aranym zweimal starten, das will ich versuchen, von verschiedenen Konsolen aus, vielleicht geht das ja. aber ich kann's auch so ganz gut vergleichen.
-
Ist alles wie auf der Atari-Tastatur sofern möglich, \ ist also Shift-Alt-ü (sollte zumindest). Stelle gerade fest, dass das default (also ohne keyboard.tbl) nicht klappt.
Also in c:/mint/1-19-cur (das ist $SYSDIR) muss keyboard.tbl stehen (hab meine mal angehängt).
-
In meinem $HOME gibt es eine rsm.inf. Vielleicht kann man damit was anfangen? Man müsste natürlich ne doku haben.
Die keyboard.tbl liegt schon lange in meinem $SYSDIR und jetzt auch noch überall zusätzlich wo nur irgendwie freemint hinschauen könnt. ;D
Aber, wie Du schon sagst, es klappt nicht. Fragt sich nur wie FreeMint überhaupt die deutsche Tastatur einstellt. lang=de ist natürlich gesetzt.
shift-alt-Ü klappt bei mir im Grundzustand nicht. Da wäre ich doch schon empirisch drauf gekommen. Außerdem sehe ich das nun ja auch in KeyEdit. Nun habe ich mir ne feine notebook.tbl gebastelt, für meine kleine Tatstatur und wollte sie schon veröffentlichen, aber ohne Test - geht gar nicht.
-
Also im boot.log steht
Starting up the update daemon ... done!
Starting up the idle process (pid 0) ... done!
Installing keyboard table `u:/c/mint/1-19-cur/keyboard.tbl' ... AKP 1, ISO 0.
Reading `u:/c/mint/1-19-cur/mint.cnf' ... 5847 bytes done.
Aber erst danach wird xaloader Programm gestartet. Vielleicht wird da die tbl wieder rausgeschmissen?
Hier noch die letzte Session von xaaes (v. 10. Febr., jetzt ist ja wohl das logging abgeschaltet):
size=[800,608], colours=256, bitplanes=32
Also habe ich ja doch 256 Farben bei 32 Bit.
-
Was zeigt keyedit denn, wenn Du $SYSDIR/keyboard.tbl lädst bei Alt+Shift?
Laut boot.log wird sie geladen, und XaAES dreht da nichts dran.
Das mit den 256 Farben hab ich doch eben erklärt!
-
Hi
Also ich persönlich hatte probs mit den Icons in Alerts.
Ich habe das so gelöst:
In fvdi.sys habe ich
palette c:\nvdi5.pal
gesetzt. Diese nvdi5.pal ist nur 1536 byte groß
in der xaaes.cnf folgendes eingestellt
palette = nvdi
die palette nvdi.pal im xaaes home dir ist 1540 byte groß.
remap_cicons = yes
und weiter
app_options = default ..... icn_pal_name = nvdi
app_options = xasys ...... icn_pal_name = fvdi
app_options = aessys .... icn_pal_name = fvdi
Das funktioniert für mich zZ
-
Aber das mit den 256 Farben habe ich immer noch nicht verstanden. Ich dachte bitplan = 8 ist identisch mit 256 Farben und bitplane=32 ist truecolor.
Die keyboard.tbl wird geladen, aber hat keine Wirkung.
Jetzt habe ich erstmal in KeyEdit meine feine Notebook.tbl geladen. Wird auch korrekt angezeigt, aber wenn ich auf temporär gehe, hat es keine Auswirkung auf den geschriebenen Text. Ausprobiert unter qed und im Eingabefeld von TeraDesk/open, um qed-artefakte auszuschalten.
Gehe ich auf permanent, wird ja eine neue keyboard.tbl gespeichert und es muss ein reboot erfolgen. Was ich ja alles schon getestet habe und nicht funktioniert. Auch nicht über keyboard.tbl speichern.
Die Table wird geladen, aber es wird doch irgendeine abgespeckte ATARI-Default Tastatur verwendet, die vielleicht noch irgendwo intern steckt.
-
Kapier ich nicht! Wenn Du in keyedit Alt-Shift auswählst, müssten \,{ und } angezeigt werden.
Hab eben mal auf Alt-Shift-. das Pfund-Zeichen gelegt, uselayout angeklickt, und hatte sofort in toswin auf Alt-Shift-. das Pfund-Zeichen.
Beim booten wird sonst nichts geladen, das default-layout wird von keyboard.tbl überschrieben.
Da fällt mir ein: Du verwendest doch clocky: Schmeiß das mal raus!
Das mit den 256 Farben brauchst Du nicht zu verstehen, ignorier es einfach, entscheidend ist das x8 oder x32 im Systemfenster.
-
Schöne Antwort, "brauchst Du nciht verstehen". Jedenfalls hatte ich jetzt wochenlang gedacht, dass das identisch ist und nun weiß ich immerhin, dass das so nicht ist. Ich habe 32-Bit und 256 Farben im System und nicht einige Millionen. Wenn ich das Wesentliche nicht verstehe, kann ich das mit dem testen lassen.
So kannst Du mir auch glauben, dass Keyedit keiner Einfluss hat. Auf Systemebene wird keyboard.tbl geladen, aber hat keinerlei Effekt. ich habe es jetzt mehrfach getestet. Kann man ganz einfach daran sehen, dass diese Taste links oben direkt unter der ESC bei mir immer, egal welche table geladen ist:
#####
ergibt. Auf meiner Tastatur steht aber ^^^^^ was ich natürlich auch in KeyEdit entsprechend umgemapt habe. Mit einer einfachen Milan_PC.tbl sollte da ~~~
rauskommen, was auch nicht funktioniert. Da steckt also irgendwo eine ATARI-Grund-Table drin, denn die hat auf dieser Taste
####
Ok, Clocky rausschmeißen.
-
In fvdi.sys habe ich
palette c:\nvdi5.pal
gesetzt. Diese nvdi5.pal ist nur 1536 byte groß
Ja, die Palette habe ich auch auf meiner Platte. Aber palette in fvdi.sys hat bei mir katastrophale Auswirkungen auf Aranym, daher geht es nur vernünftig, wenn dort palette auskommentiert ist. Ich wills aber gern nochmal mit der nvdi5 testen.
Zu Deiner xaaes Lösung. Wie sieht denn das XAaes Logo bei Dir aus. Wenn sich darauf default auch auswirkt, wäre das eine Möglichkeit. Denn mit fvdi sieht es grausam aus und das gilt auch für die icons teilweise in Alerts.
-
das logo beim start interessiert mich eigentlich nicht weiter. hat ja keine sonderlich große funktion.
-
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.
-
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. ;)
-
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.
-
auch egal, wenn man XaAES die Palette laden lässt.
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. ::)
-
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.
So, Helmut, nun hör mal auf mich. das ist der Knackpunkt. Mit palette=nvdi5.pal in der fvdi.sys,
lädt der Editor von rsm die NVDI-Palette. So wie er es bei Dir wohl immer schon gemacht hat. (ich bin auf 32bit).
Vorher mit palette=fvdi.pal, bzw. auskommentiert, hatte ich immer den Farbkeil in fvdi-palette. Das war ja mein Problem und nun wissen wir auch, dass sich rsm um xaaes nicht schert, sehr wohl aber die system-palette von fvdi.sys lädt. Daher, ganz wichtig, palette=nvdi5.pal in fvdi.sys einstellen.
Das blue-Icon-Problem muss auf anderer Eben geklärt werden. Nun aber, kann man davon ausgehen, dass das was in Iconedit erzeugt wird, auch auf dem Desktop so angezeigt wird. Egal welche Farbtiefe eingestellt ist.
Problem gelöst.
Das einzige, was Du verbessern kannst, ist, dafür zu sorgen, dass xaaes die Systempalette auch wirklich auf allen Ebenen verstellt. Mit den Einstellungen dort spiele ich noch, unabhängig vom rsm-Problem.
-
Zu rsm:
Ich bastle an einem Test-Palette-Icon. So wie meine Einstellungen jetzt vorliegen, ist das verhalten von rsm so:
1. Es lädt die Palette aus fvdi.sys.
2. DIe Icon Box (mit den vielen Icons) zeigt die Icons in 16 Farben.
3. Der Icon-Editor natürlich in 256 Farben, wenn eine solche Fassung des Icons vorliegt, oder man erzeugt es.
Wie man nun noch erreicht, dass die Icon-Box, die icons auch in 256 Farben darstellt, kriege ich noch heraus. Denn diesen Zustand hatte ich auch schon mal im Laufe unserer Test-Arie.
-
Wenn das wirklich so ist, dass rsm die fvdi.sys ausliest (müsste man ja in der MiNT-debug-Ausgabe sehen können), dann wäre das immerhin kontrollierbar. Oder es gibt da noch eine geheime Kommando-Schnittstelle, die sonst keiner kennt ..
Was meinst Du mit "auf allen Ebenen"? Das sind alles VDI-Funktionen, da gibt's nur eine Ebene.
-
Ebenen, gut, davon verstehe ich zu wenig. Ich meine tief im System oder in allen Schichten. Keine Ahnung, ob da fvdi noch irgendwo anders rummacht, als nur auf vdi-Ebene. Aber wenn Du glaubst, dass rsm direkt in die fdi.sys-datei schaut, dann würde das auch einiges erklären.
Oder anders gesagt, über welche Schnittstelle rsm das macht, weiß ich natürlich nicht.
Ich hab jetzt mal ein Icon gebastelt, das sieht in 16 Farben ganz normal aus und kennt jeder, wenn man aber den Bildeditor in 256 Farben öffnet oder das Icon in 256 Farben darstellt, dann hat man ein Palettenrechteck, das besteht aus den ersten 16 Farben (wie wohl jede Palette am Anfang) plus der 6 Zeilen vom Ende des Palettenkeils (mehr passt schlecht rein).
Man sollte auf den ersten Blick erkennen, in welcher Palette das icon dargestellt wird. Dabei muss ich ergänzen, dass die nvdi5.pal, so weit ich mich erinnere aus Hades-Zeiten, einige besondere Farben auf die letzten zwei Zeilen gelegt hat, wo wohl sonst der Graukeil liegt. Man hat ein paar, ich nenne sie mal Widget-Farben dorthin gepackt, die man wohl für den Desktop verwendet. So kam es bei mir ja auch vor, dass unter 8-Bit der schwarze Auswahlbalken, oder die Auswahlfarbe nicht schwarz, sondern dunkelblau war. Ein Effekt wie ich ihn vom Hades erinnere. Es kann also sein, dass diese zwei letzten Zeilen noch beliebig von der echten NVDI.pal abweichen. Das muss ich erst noch alles testen. Du hast recht, dass das interne Format etwas differiert, daher auch die 4 Byte kürzer. Das ist wohl entscheidend dafür, dass fvdi.sys nicht verrückt spielt. Das hat aber natürlich nix mit der Farbanordnung zu tun.
-
@rastr, wenn Du hier fvdi eingestellt hast, dann bedeutet das doch aber, dass hier auch nur die nvdi5.pal geladen wird.
Vermutung: dass das Auswirkungen auf die Alert-icons hat, hängt mit den widget-Farben in nvdi5 zusammen. [/ungeprüft]
Es tritt auch wieder massiv der Blue-Icon-Bug auf, der aber gefixed sein soll. Hab nur leider noch keine neue binary von Aranym. Er ist bedeutend schwerer unter nvdi5, als unter fvdi.pal und palette=nvdi in xaaes.cnf.
app_options = xasys ...... icn_pal_name = fvdi
app_options = aessys .... icn_pal_name = fvdi
Das funktioniert für mich zZ
-
So nun prankt es auf meinem Desktop in 256 Farben
(http://forum.atari-home.de/index.php?action=dlattach;topic=10117.0;attach=4092)
16 Farben (http://forum.atari-home.de/index.php?action=dlattach;topic=10117.0;attach=4096) 256 Farben (http://forum.atari-home.de/index.php?action=dlattach;topic=10117.0;attach=4097)
Die Resource-Datei als pdf hängt an, einfach pdf abschneiden, versteht sich.
Für zukünfige Palettentests vielleicht nützlich. ;-)
-
Ich mühe mich mit dem cxsu_pcn, da kommt immer der Fehler "rsc nicht gefunden". Wie kriege ich das zum laufen? Was braucht das programm?
-
Klappt das nicht mit der hier:
http://home.arcor.de/zabruder/atari/tools/cxxsetup.rsc.gz
Hatte ich doch mit angegeben!
-
Achso, ich dachte das sind die sourcen. Hatte mich shcon gewundert. Mein Fehler, sorry.
Ja, funktioniert, aber mehr, als die Palette anzeigen kann es wohl nicht mehr. z.B. abspeichern funktioniert überhaupt nicht. So brauche ich mir auch nicht die Mühe machen erneut die originale fvdi-default-palette einzustellen.
Wenn ich jetzt über die short-cuts die Palette nachlade, finde ich keinen Unterschied zwischen nvdi und gem, weder in dem Matrix-Programm noch im IconEdit, weder an dem Palette-Farb-keil, noch an meinem Icon, auch nicht am Desktop. Den gravierende Unterschied zur fvdi-default-palette kann ich ja im Moment nicht anzeigen. Möglich, dass app_option verhindert, dass die gem-palette angezeigt wird.
Jetzt habe ich Deine fvdi.pal wieder gefunden und nun geht's wohl.
Nein, da tut sich auch nichts. Kann es sein, das das schon die nvdi5.pal war?
Unsere Fehlersuche ist aber nachvollziehbar. Wenn ich nvdi5 wieder auskommentiere, dann ist mein Palette-Icon auf dem Desktop sofort ganz anders. und die Icons Floppy und Clipbrd sind ebenfalls wieder verändert, irgendwie farblos, und netsurf wieder bunt, wie neulich schon. Ich schau mir das jetzt noch mal mit den Palette-Tools an.
Das Umschalten der Palette mit den short-cuts funktioniert nicht, bzw. ergibt keine Änderung. Und xaaes.cnf stellt die Palette auch im Matrix-Tool nicht um. Sieh selbst.
(http://forum.atari-home.de/index.php?action=dlattach;topic=10117.0;attach=4106)
-
Ich habe das Gefühl, dass xaaes.cnf bei mir gar nichts bewirkt (in Bezug auf die Palette) sondern nur die Einstellung in fvdi.sys. :-\
Und wenn das Problem nicht nur rsm betrifft, dann kann es durchaus mit aranym zusammenhängen, dass vielleicht das Laden der Palette durch xaaes irgendwie nicht unterstützt. Sondern sich ausschließlich auf die system-palette von fvdi stützt.
-
kurze zwischenfrage:
wieso bekomm ich diesen alert angezeigt?
(http://forum.atari-home.de/index.php?action=dlattach;topic=10117.0;attach=4108)
andere anwendungen erhalten diesen nicht. egal ob 1.18 oder 1.19er
-
Was ist denn agentinfo?
Schweineprogramme fliegen halt raus!
Kannst Du nicht ein neues Thema für sowas anfangen?
-
Ich habe das Gefühl, dass xaaes.cnf bei mir gar nichts bewirkt (in Bezug auf die Palette) sondern nur die Einstellung in fvdi.sys. :-\
Und wenn das Problem nicht nur rsm betrifft, dann kann es durchaus mit aranym zusammenhängen, dass vielleicht das Laden der Palette durch xaaes irgendwie nicht unterstützt. Sondern sich ausschließlich auf die system-palette von fvdi stützt.
Sicher bewirkt das was. Außer Du machst was falsch (bzw. richtig). Die teradesk-Icons werden in jedem Fall beeinflusst, aber diesen Einfluss soll ja remap_cicons ausgleichen.
Nach Neuladen der Palette muss man die Programme neustarten, damit man eine Änderung sehen kann. Außer bei.8 bit-video - da sieht man alles gleich. Das gilt auch für cxsu_pcn: Wirkt nur bei 8 bit, so hab ich die Nummern der falsch dargestellten Farben gefunden: Durchprobieren, bei welcher Nummer sich was verändert!
In cxsu_pcn kann man die Icons verschieben, und so laden/speichern usw. Aber mit fvdi ist das manchmal komisch, also nicht zu viel erwarten!
Wo kommt denn das netsurf-icon von Deinem screenshot her, das sieht ja nicht gerade toll aus. Ist das aus cicons.rsc?
-
Was ist denn agentinfo?
Schweineprogramme fliegen halt raus!
Kannst Du nicht ein neues Thema für sowas anfangen?
ich habe etwas in gbe rumgespielt. sorry
-
So nun prankt es auf meinem Desktop in 256 Farben
Die Resource-Datei als pdf hängt an, einfach pdf abschneiden, versteht sich.
Für zukünfige Palettentests vielleicht nützlich. ;-)
In der Tat! Kannst Du das irgendwie in cicons.rsc von teradesk reinfummeln?
Ich hab mir auch Test-icons gebastelt, die nur aus den ersten 16 Farben bestehen, aber das ist sicher auch praktisch.
Dein Icon sieht in rsm bei mir übrigens so aus (32bit):
(http://forum.atari-home.de/index.php?action=dlattach;topic=10117.0;attach=4110)
Meine Test-Icons:
(http://forum.atari-home.de/index.php?action=dlattach;topic=10117.0;attach=4112)
In fvdi lade ich nvdi5.pal (angehängt, ebenso cicons.rsc für teradesk).
-
für mich habe ich das paletten problem nun endgültig folgendermaßen gelöst.
in fvdi.sys lade ich angehängte fvdii.pal (extra 2tes i, damit ich die nicht verwechsel)
in xaaes.sys setz ich palette = fvdi
app_options für default palette fvdi
app_options für xasys palette nvdi
app_options für aessys palette nvdi
remap_cicons = yes
damit sieht das xaaes-logo gut aus und auch die icons.
die pal 1536 byte groß und entspricht der fvdi.pal mit 1540 byte, nur die 4 byte am anfang habe ich entfernt.
-
Mist - man kann nur 4 Dateien anhängen ...
Ich hab jetzt mal in fvdi.sys palette auskommentiert, und die Farben sind falsch! Die teradesk-icons stimmen allerdings, was beweist, dass XaAES seine Sache richtig macht. Evtl. könnte man auch die anderen Farben irgendwie noch reparieren, vielleicht sind das Deine "Ebenen".
(http://forum.atari-home.de/index.php?action=dlattach;topic=10117.0;attach=4117)
-
Danke erstmal für alles. Bei meinen Versuchen/Snapshots oben ist es so, dass die letzte Fassung mit dem etwas dunklen Testicon enstand unter (aus)kommentierter palette in fvdi.sys. Wir haben da wieder die fvdi-system-Palette mit den gleichmässigen Übergängen und echten Farbspektren.
Eine Fassung weiter oben, wo ich das Test-Icon vorgestellt habe, war palette=nvdi5.pal in fvdi.sys. Hier sieht dann alles so aus wie bei Dir und in Deiner Widergabe des Test-Icon (rsmtst.png). Deine Test-Icon sind ja wirklich Produkte unserer Versuche. Sehr gut.
Mit dem Neustarten der Programme teste ich noch.
Eine solche falsche Farbdarstellung wie bei Dir ohne palette in fvdi.sys, gab es bei mir noch nie. Es beweist auch nicht, dass xaaes bei mir auch funktioniert. Immerhin bin ich nicht auf dem TT. >:D
In der Tat! Kannst Du das irgendwie in cicons.rsc von teradesk reinfummeln?
Ist doch schon drin, das letzte Icon mit der höchsten Nummer, sonst wäre es ja nicht auf dem Dektop. ;)
In fvdi lade ich nvdi5.pal (angehängt, ebenso cicons.rsc für teradesk).
Ja, genau das mache ich normalerweise auch.
@rastr, wenn Du defeault fvdi.pal nimmst, dann fürchte ich wird es mit vielen Programmen kein schönes Bild geben. Weil doch viele Programme für NVDI entwickelt, bzw. optimiert wurden. Aber vielleicht ist ja xaaes inzwischen so mächtig, dass es bei all diesen Programmen korrigiert. Danke jedenfalls für die fvdi.pal für fvdi.sys.
Achso, das bunte netsurf hatte ich schon mal gezeigt. Es ist die 256-Farbdarstellung unter kommentierter Palette in fvdi.sys. Das Icon selbst kommt aus der globalen netsurf.rsc des Programmes. Es ist im zweiten Tree. Ich hatte es extrahiert und später in die CICON.RSC kopiert. Erst danach war das hellblau richtig. Aber die bunte Version in 256 Farben entsteht immer, wenn die fvdi-palette auskommtiert ist.
-
Mit dem Neustarten der Programme teste ich noch.
Du kannst mir schon glauben, was ich sage. Das nachstarten der Palette mit ctrl-alt-shift-p bewirkt nichts. Auch nicht bei jeweiligem Neustart des cxsu_pcn. Es erscheint immer die gleiche Palettendarstellung, die nach meinen Tests nur von der in fvdi eingestellten Palette abhängig ist. Ob dafür nun xaaes verantwortlich ist, dass es bei jeder Palette immer zum gleichen Ergebnis mapped, kann ich mir nicht vorstellen. Es würde dann ja immer zur Systempalette mappen, obwohl in palette und remap und app_options was ganz anderes eingestellt ist.
Ich bin jetzt mal gespannt, was rastrs fvdii.sys bringt.
-
Kommando zurück. Du brauchst mir natürlich nicht zu glauben, was ich sage. ;D
Es funktioniert doch, man sieht es bei mir erst, wenn man das Desktop.prg neustartet. Und nun habe ich mal Deine völlig kranke fvdi.sys in xaaes nachgeladen (short-cut) und mein Desktop sieht so aus. Das entspricht etwa Deinem letzten Bild meines Testicon. Diese Palette wird bei mir normalerweise nicht geladen oder erzeugt, auch nicht, wenn in in fvdi.sys auskommentiere
nosyspal_xfvdi.png bedeutet
in fvdi.sys keine Palette, in xaaes palette=fvdi.sys fvdi.pal
wobei ich Deine angehängte fvdi.sys fvdi.pal von vorgestern genommen habe.
(http://forum.atari-home.de/index.php?action=dlattach;topic=10117.0;attach=4120)
-
Das gleiche Szenario, aber mit System-Palette = nvdi5 und Deine fvdi.pal nachgeladen
(http://forum.atari-home.de/index.php?action=dlattach;topic=10117.0;attach=4122)
-
Ebenso mit system-palette =nvdi5 und palette=nvdi nachgeladen
(http://forum.atari-home.de/index.php?action=dlattach;topic=10117.0;attach=4124)
-
Und jetzt mit nachgeladener gem.pal.
Das remapping ist immer auf nvdi gestellt.
Man sieht die schwärzeren Konturen und in der Palette sind die beiden unteren Zeilen ein perfekter Graukeil. Nicht alle Icons werden richtig gemapped.
(http://forum.atari-home.de/index.php?action=dlattach;topic=10117.0;attach=4126)
-
Warum schickst Du mir deine CICONS.RSC. Mir würde Deinee Testicon.rsc mehr bringen mit Deinen Testicons. Die CICONS enthält nicht ein Icon, das ich nicht auch habe. Oder wolltest Du, dass ich DIr da mein Test-icon einbaue?
-
Kommando zurück. Du brauchst mir natürlich nicht zu glauben, was ich sage. ;D
Es funktioniert doch, man sieht es bei mir erst, wenn man das Desktop.prg neustartet. Und nun habe ich mal Deine völlig kranke fvdi.sys in xaaes nachgeladen (short-cut) und mein Desktop sieht so aus. Das entspricht etwa Deinem letzten Bild meines Testicon. Diese Palette wird bei mir normalerweise nicht geladen oder erzeugt, auch nicht, wenn in in fvdi.sys auskommentiere
nosyspal_xfvdi.png bedeutet
in fvdi.sys keine Palette, in xaaes palette=fvdi.sys
Was soll denn palette=fvdi.sys? Dann lädt XaAES wahrscheinlich gar keine Palette, und dass das dann so aussieht, ist kein Wunder.
fvdi.sys ist doch keine Palette!
-
Warum schickst Du mir deine CICONS.RSC. Mir würde Deinee Testicon.rsc mehr bringen mit Deinen Testicons. Die CICONS enthält nicht ein Icon, das ich nicht auch habe. Oder wolltest Du, dass ich DIr da mein Test-icon einbaue?
Da sind die Test-Icons drin, die ich zum debuggen verwendet hab, und die auch in meinen screenshots gezeigt werden. Hab ich gerade extra nochmal überprüft!
Wenn ich CICONS.RSC von Dir nehme, kommt von teradesk icon(s) not found in the resource-file. Klappt aber trotzdem.
Kannst Du jetzt noch das bunte Icon in meine Test-cicons.rsc integrieren?
Wieso das clipbrd-Icon mit gem-Palette bei Dir so dunkel ist, ist mit schleierhaft - ich benutzte auch palette=gem in xaaes.cnf, und palette nvdi5.pal in fvdi.sys, und das clipbrd-Icon ist korrekt.
Mit palette=fvdi in xaaes.cnf bekomme ich:
(http://forum.atari-home.de/index.php?action=dlattach;topic=10117.0;attach=4130)
Mit palette=gem bekomme ich:
(http://forum.atari-home.de/index.php?action=dlattach;topic=10117.0;attach=4131)
Scheint da stimmt was nicht ...
-
Habe ich mich wohl vertippt, muss fvdi.pal heißen. Es handelt sich dabei um Deine fvdi.pal, die Du ein paar Tage weiter oben angehangen hattest.
Die ganze Serie sieht genauso aus, wenn ich in fvdi.sys palette=fvdii.pal von rastr einstelle.
Das Umschatlten von xaaes der Palette mit shortcut sieht man sehr gut auch auf dem Xaaes-Desktop mit dem Logo. Wobei zwischen fvdi.pal und gem.pal man dort keinen Unterschied bemerkt (sind aber auch nur zwei Farben sichtbar).
-
In der anhängenden CICONS.ZIP bei Dir sind sie nicht drin, hab sie nicht gefunden.
Sieh selbst
(http://forum.atari-home.de/index.php?action=dlattach;topic=10117.0;attach=4128)
-
In der anhängenden CICONS.ZIP bei Dir sind sie nicht drin, hab sie nicht gefunden.
Sieh selbst
(http://forum.atari-home.de/index.php?action=dlattach;topic=10117.0;attach=4128)
Ich hab den link
http://forum.atari-home.de/index.php?action=dlattach;topic=10117.0;attach=4116
Gerade extra nochmal runtergeladen und in rsm geladen: Sie sind drin! Die Farben sind auch alle anders in Deinem Bild.
-
Ich muss sicher in die 256-Farbdarstellung schauen. Sehr mühselig. Ich versuche es anhand der icon-namen.
-
Kannst Du jetzt noch das bunte Icon in meine Test-cicons.rsc integrieren?
Hab das jetzt erst gesehen, muss erst Deine Testicons identifizieren, dann baue ich Dir das Icon ein, das kannst Du aber doch mit rsm ganz einfach selber machen.
Warum schickst Du mir deine CICONS.RSC. Mir würde Deinee Testicon.rsc mehr bringen mit Deinen Testicons. Die CICONS enthält nicht ein Icon, das ich nicht auch habe. Oder wolltest Du, dass ich DIr da mein Test-icon einbaue?
Da sind die Test-Icons drin, die ich zum debuggen verwendet hab, und die auch in meinen screenshots gezeigt werden. Hab ich gerade extra nochmal überprüft!
Wenn ich CICONS.RSC von Dir nehme, kommt von teradesk icon(s) not found in the resource-file. Klappt aber trotzdem.
Das dürfte an Deiner TERADESK.INF liegen. Man kann die CICONS.RSC nicht so einfach komplett austauschen. Wenn ich neue Icons in meine CICONS.RSC einbaue, gibt es keine Probleme. also schön eins nach dem anderen. Wenn man ein Icon aus der CICONS.RSC löscht geht die Nummer verloren. Das nächste Icon das man hineinkopiert bekommt die höchste Nummer, es wird einfach weiter nummeriert. Und TERADESK zeigt die Icons in seinem Dialog "Deskicon anlegen" in der Reihenfolge der Objektnummern. Also jedes neue Icon rutscht ans Ende.
Wenn man die CICONS.RSC extern verändert hat, muss man TERADESK.INF zuerst neu laden, dann werden auch die Icons neu geladen in den Auswahl-Dialog. Reicht nicht, man muss Teradek neu starten, evtl. vorher Teradesk.inf speichern
Wieso das clipbrd-Icon mit gem-Palette bei Dir so dunkel ist, ist mit schleierhaft - ich benutzte auch palette=gem in xaaes.cnf, und palette nvdi5.pal in fvdi.sys, und das clipbrd-Icon ist korrekt.]
Hängt vielleicht mit dem remapping zusammen, da ist some random drin?
Die Tafelfläche ist in nvdi hellgrau und in gem dunkel-olive-grau.
Mit palette=fvdi in xaaes.cnf bekomme ich:
(http://forum.atari-home.de/index.php?action=dlattach;topic=10117.0;attach=4130)
Mit palette=gem bekomme ich:
(http://forum.atari-home.de/index.php?action=dlattach;topic=10117.0;attach=4131)
Scheint da stimmt was nicht ...
Leg mal das Testicon nicht auf ein LW, sondern als Datei auf irgendeine Deiner Pal-Dateien, oder sonstwas. Dann hast Du keinen störenden Buchstaben drin. Ich habe dem ICON außerdem den aussagekräftigen Namen gegeben.
Die gem-palette stimmt nicht, zu sehen ist die nvdi-palette, warum fvdi jetzt bei Dir nur so gering abweicht, weiß ich nicht. Es liegt wohl an der nvdi5 in der fvdi.sys.
-
Die Farben sind auch alle anders in Deinem Bild.
Das liegt wohl daran, dass bei mir der rsm in dieser iconvorschau nur 4-bit zeigt. ich sehe die Icons also nicht in ihrer 256-farb-Darstellung. dazu muss ich für jedes Icon den Editor öffnen. das habe ich oben ja schon mal zusammen gefasst unter 1., 2., 3. usw.
-
Das remapping verstehe ich sowieso nicht. Es ist natürlich klar, dass Du hauptsächlich am debugging des remap-Mechanismus interessiert bist. Aber für mich wäre es übersichtlicher und aussagekräftiger, wenn man das remapping erstmal ganz abschaltet und sieht was die Paletten selber machen.
-
Ja, die Icons scheinen drin zu sein. Ich muss jetzt jedes Icon öffnen, da die Namen ja nicht mit den Filenamen auf deinem snap übereinstimmen.
Jetzt kommt wieder das Problem Iconeditor ins Spiel. Das lasse ich zunächst einmal ganz aus dem Spiel. Denn der Editor zeigt natürlich wieder die Palette an, die ich in fvdi.sys eingestellt habe und das ist im Moment die fvdii.pal. Ergo alles viel zu dunkelgrün. Was der Editor nachdem Palette nachgeladen wurde macht, ob er überhaupt was macht, das muss ich erst wieder testen. Soweit bin ich noch nicht. Ich werde die Testicons jetzt in meine CICON.RSC einbauen und mir die Testicons auf den Desktop legen. damit ich sie in der richtigen von xaaes eingestellten Palette sehe. Das wird dauern.
Die fvdii.pal ist nicht ganz identisch mit ohne Palette, aber sehr ähnlich.
Vorher baue ich Dir das icon ein.
-
Anhang testicons.rsc
-
Auf die schnelle hab ich diese 4 Icons eingebaut. Das Hard_Disk in schwarz-rot habe ich wohl übersehen. das floppy erscheint bei mit im Editor kaputt, aber das habe ich ja. So siehts in meinem Desktop aus. Teradesk hat übrigens nach meinem Verfahren nicht gemeckert.
fvdi.sys palette=fvdii
führt zu falschen Darstellungen meiner Meinung nach und ist für den IconEditor nicht zu gebrauchen. Ist aber hier eingestellt, und nvdi von xaaes geladen. Woran erkennt denn xaaes, dass ein Icon in falscher Palette vorliegt und mapped sie um?
Nicht verwirren lassen von den Icon-Titeln. Die Icons sind ein Link auf die genannten pal-Dateien.
rsm zeigt beharrlich die fvdi.sys palette=fvdii
(http://forum.atari-home.de/index.php?action=dlattach;topic=10117.0;attach=4133)
-
ich hatte vorhin mal ein test mit 8bit farbtiefe gemacht und habe dabei fast nur schwarz und dunkle töne gesehen.
bei 16bit ist es ok.
-
In diesem Zustand, letztes Bild starte ich das Matrixtool und es zeigt mir auch die in fvdi.sys eingestellte Systempalette. Genau wie der iconEditor. Wärend der Desktop zweifellos die in xaaes eingestellte nvdi-palette darstellt. Hier teste ich jetzt weiter.
Nächster Schritt: was passiert beim Palette nachladen.
Man sieht es auf dem nächsten Snap. Die beiden Palettenprogramme zeigen die Systempalette, wie sie in fvdi eingestellt ist. Mein TestIcon auf dem Desk zeigt aber die NVDI-Palette. Man beachte den Graukeil, der bei fvdi oben ist, wärend er bei NVDI in den letzten zwei Zeilen steckt, also unten (bei NVDI ist im Gegensatz zu gem blau hinzugefügt).
Zur Erinnerung, in meinem Icon stecken nur die letzten 6 Zeilen der Palette, und oben die 16 Farben.
(http://forum.atari-home.de/index.php?action=dlattach;topic=10117.0;attach=4135)
-
Lade ich nun die Palette fvdi.pal (Deine) nach (shortcut), beende alle Programme, beende den Desktop und start ihn neu, dann erscheinen die Icons auf dem Desktop in neuer Palette (fvdi), in den Palettenprogrammen bleibt aber alles unverändert. Mit anderen Worten, die scheren sich überhaupt nicht um xaaes. Das passiert auch bei allen anderen nachgeladenen Paletten.
(http://forum.atari-home.de/index.php?action=dlattach;topic=10117.0;attach=4137)
-
Anhang testicons.rsc
Damit kann man schon was anfangen, danke! Nachdem ich jetzt in teradesk die Einstellungen gesichert hab, meckert er auch nicht mehr.
So, jetzt werde ich als nächstes mal untersuchen, wieso das Test-Icon bei fvdi-Palette anders aussieht, kann noch dauern ...
-
Lade ich nun die Palette fvdi.pal (Deine) nach (shortcut), beende alle Programme, beende den Desktop und start ihn neu, dann erscheinen die Icons auf dem Desktop in neuer Palette (fvdi), in den Palettenprogrammen bleibt aber alles unverändert. Mit anderen Worten, die scheren sich überhaupt nicht um xaaes. Das passiert auch bei allen anderen nachgeladenen Paletten.
Nach erneutem, intensivem Nachdenken ist mir der Gedanke gekommen, dass die Palettenänderungen pro Applikation (also pro vdi-handle) wirken. Aber nur bei TC, bei 8 bit verändert sich alles sofort.
Das sind ganz neue Erkenntnisse, und ob man da irgendwas machen kann, weiß ich nicht.
-
Das sind aber rein theoretische Überlegungen. Ich habe hingegen empirisch nun auch noch alle anderen Varianten durchprobiert und es gibt keine neuen Erkenntnisse.
Grundsätzlich richten sich die "Palettenprogramme" nur nach der in fvdi eingestellten Palette. Und das ändert sich auch nicht mehr, egal wie oft man eine andere Palette nachlädt, oder was in xaaes eingestellt ist. Das hat überhaupt keinen Einfluß auf die Palettenspektren und Keile. Sie ändern sich aber sofort, wenn man in fvdi.sys eine andere Palette wählt, oder aber keine Palette wählt. (über welche Schnittstelle das funktioniert, scheint unbekannt).
Der Desktop richtet sich nach dem xaaes und folgt auch jedesmal, wenn man eine andere Palette nachlädt. Wirkt sich aber erst nach jeweiligem Neustart des Desktop-Programmes aus.
Was nun das remapping da noch zwischen funkt, das kann ich nicht kontrollieren. Wichtiges Fazit für mich, will ich mit einem der Palettenprogramme arbeiten, z.B. Icons bearbeiten oder erzeugen, muss ich zwingend nvdi5.pal laden. Da die meisten Icons auf diese Palette aufsetzen und ich auch sonst die Palette auf NVDI stellen will.
-
Ganz genau!
Die Desktop-Icons und alle widgets, und überhaupt alles was aus einem rsc-file kommt, wird vom AES gezeichnet, und dementsprechend umgemappt.
Wenn die Programme wie rsm direkt über das VDI zeichnen, wird nicht die von XaAES installierte Palette verwendet, sondern, die für dieses Programm (bzw. VDI-handle) gültige. Passt doch alles zusammen!
-
In netsurf wird das favicon als iconify bild angezeigt, es sei denn es gibt gerade kein favicon ;)
Naja, auf jeden fall... ich glaube dafür muss die NVDI Palette verwendet werden, also bei dem Standard bild....
ich habe das icon uebrigens nicht erstellt,.... von daher kann ich dazu auch nicht so genau infos geben ;)
-
Passt ;D
Theorie und Praxis stimmen mal wieder überein. 8)
Aber ehrlich, der User sollte nie in so eine Situation kommen, dass Widgets eine andere Palette verwenden als die Tools. Klar nun könnte man verlangen, dass die Tools selber in der Lage sind eine Palette aus zu wählen. :-\ Das MAtrix-tool kann doch eigentlich Paletten nachladen, habs nur noch nicht hinbekommen, aber es ist ja sonst zu nix nutze ohne GraKa.
Mmmh AES-Palette und VDI-Palette, wer hätte das gedacht. ;D Das einfachste, was Du machen kannst: Kleiner Hinweis in die cnf.
-
Ich könnte in XaAES als Systempalette immer die beim Start vorhandene nehmen, also nichts mit palette=, aber nur bei TC.
Hatte ich ja sowieso noch vor, dass man palette weglassen kann, und das dann so gemacht wird. Wäre in dem Fall glaub ich eine ganz gute Lösung. solange die vorhandene Palette was taugt und nicht sowas ist wie in meinem screenshot mit ohne palette in fvdi.sys.
-
AES-Palette, VDI-Palette?
Bitte. Eigentlich ist es doch die Palette des VDI.
Das AES ist nur das Visuelle Instrument was du siehst.
Darunter hantiert das VDI, und die anderen dinge
-
Kann sein, das war jetzt mehr aus Anwendersicht gesprochen, als aus Theorie-Sicht.
Helmut, muss ich noch länger drüber nachdenken, aber es könnte ein Ansatz sein.
Inzwischen kann ich im Matrix-Tool auch Paletten nachladen. Einfach das Diskicon auf das Palette-icon schieben (da hat es einer mit wisiwig GUI D&D zu gut gemeint). dabei ist mir aufgefallen, dass deine fvdi.pal, die wir jetzt immer verwendet haben, irgendwie corrumpt ist, sie besteht im Spektrum zur oberen Hälfte aus gem und zur unteren Hälfte aus fvdi, so weit ich sehe. Sie hat kein kontinuierlich durchgehendes Spektrum, wie die echte fvdi-Palette. Muss ich mir direkt mal mit dem fvdii ansehen.
Das Tool kann die um 4 Byte verkürzten Paletten nicht laden, also keine für das fvdi passenden Paletten. Da muss ich mir wohl doch einen hexeditor besorgen. :)
-
Was Ihr hier eigentlich macht ist:
Ihr guckt ein Aquarium an. Die Scheibe ist etwas schmutzig. Eure Aussage: Die Fische sind dreckig. Eure Gegenmaßnahme: Ihr legt verschiedene Folien auf die Scheibe und schaut wie die Fische damit aussehen.
Ihr müßt aber die Scheibe putzen!!
-
Also:
Putzt die Scheibe und legt eine XaAES Palette fest!
Das mag die Nvdi-palette sein. Aber dieses remapping ist mmn absoluter Irrsinn!!
-
Wenn die Icons dann nicht richtig dargestellt werden, müssen die mit er richtigen palette eben neu gezeichnet werden. ende.
-
Der Knackpunkt ist aber, dass fvdi und XAaes die gleich Palette haben müssen, denn sonst funktioniert der Icon-Editor nicht. Und genau das haben wir herausgefunden. Über den langen Weg, na gut... ::)
Ich denke auch, dass die meisten Icons die NVDI-Pallette wollen, aber einige eben nicht und dafür wurde wohl das remapping erfunden. Man kann natürlich auch die Icons entweder nicht verwenden oder einfach neu zeichnen. ;)
-
das AES hat mit der Palette eigentlich NULL zu tun
-
Das remapping ist von mir gewünscht, weil ich in XaAES die gem-Palette bevorzuge, die meisten icons aber für nvdi-Palette gemacht sind. Manche können auch auf irgendeiner beliebigen Palette basieren. Außerdem verlangt das die AES-Spezifikation, wo eine Palette im rsc-file enthalten sein kann, so dass der der die Icons gemacht hat, bestimmen kann, mit welcher Palette sie dargestellt werden. Ich glaub es ist sogar möglich, für jedes Icon eine separate Paltte zu definieren, das wird von XaAES allerdings nicht unterstützt.
Ich will in jedem Fall davon weg, dass man immer nur die eine Palette benutzen kann, das ist Schrott!
Man kann die fvdi-Palette ganz einfach in eine XaAES-Palette umwandelen, indem man
cat pa01 <fvdi-Palette> >XaAES-Palette
in einer shell eingibt
Die Datei pa01 enthält dann PA01 ohne newline..
-
ich als enduser mag mit dieser ummapperei nichts zu tun haben, eigentlch. denn mit der jetztigen methode wird man quasi dazu gezwungen sich damit zu beschäftigen. und das finde ich persönlich scheisse!
vorher ging es doch auch. wieso jetzt nicht mehr? wo ist das prob?
wenn es mehrere anwendungen gibt in einer palettenauflösung und jede anwendung einer eigene palette durchsetzt (auch nur beim fokus auf sie selbst) gibt es eine bunte hin und her blinkerei. ein kunterbunterhaufen an farben die der user dann sehen darf. und das empfinde ich als störend, schrottig und blöde.
in einer mehr als 8bittigen also 16 bittigen umgebung ist ein umappen eigentlich nicht mehr sinnvoll, da es kein palette im eigentlchen sinn mehr gibt. sie ist eher störend. warum also dort dem vdi in die methoden einmischen? wenn ds aes dann schon so weit geht, warum dann nicht gleich das gesamte vdi entfernen und ersetzen? das würde doch viel einfacher sein, oder?
aber sorry, seit einigen jahren empfinde ich die entwicklung hier eher als persönliche belange noch als allgemeinen fortschritt. aber das mag auch nur mich betreffen, denn sonst hat ja niemand den mum die schnauze aufzumachen.
sorry, hab schlechte laune!!
-
Du hast das ganze Konzept nicht verstanden. Lass einfach in xaaes.cnf alles mit pal* weg und Du bist glücklich.
-
das konzept ist scheisse, das ist ds prob. aber ich lass euch jetzt in ruhe weiter fummeln
-
Für jeden Besitzer einer Grafikkarte ist das wohl ein interessantes Thema und es wäre schön wenn die Farben auch in höheren Farbtiefen nicht falsch rüber kommen.
-
das konzept ist scheisse, das ist ds prob. aber ich lass euch jetzt in ruhe weiter fummeln
Denkst Du - Du hast es ja auch nicht verstanden.
-
versteht doch bitte das vdi ist für die palette zuständig, nicht das aes
mit dem remapping wird alles verkompliziert.
-
erklärt mir das konzept hinter dem remapping. aus sicht des endanwenders. danke.
bitte ohne aes und vdi zu vermischen, danke
-
Lies alles nochmal von vorne, vielleicht wird's dann klar, keinen Bock alles nochmal zu wiederholen.
-
das sind die antworten, weshalb atari.anwender heute noch so zahlreich sind.
ich hatte 2005 oder so aufgegeben. anfang des jahres hatte ich mal wieder was versucht. ich hätte es nicht tun sollen. sorry.
sorry das ich fragen stelle die vielleicht nicht so genehm sind . sorry, ganz grosses
wird nicht wieder vorkommen.
-
So geht es mir auch oft. Ich möchte immer alles hinschmeissen und frage mich welcher Affe mich gebissen hat. Aber ernsthaft löse ich meine Probleme schon lange nicht mehr mit dem Atari. Für Entwickler ist das jedoch ein reizvolles System nach wie vor und es macht mir dann halt wieder Spaß damit zu experimentieren. Gerade das Aranym-System auf meinem kleinen Notebook ausschließlich unter Host-Medien ist jetzt, nachdem ich es erstmal eingerichtet habe, dermaßen flexibel, für Experimente und Tests ideal. Da ich jede Operation auch im Host machen kann und ständig hin und her springen kann. Es macht jetzt keinen Unterschied mehr, ob ich tar oder gzip auf der Hostconsole oder in toswin2 benutze. Wäre das nicht so, hätte die ganze Arie hier doppelt so lange gedauert. Natürlich habe ich vor Augen, dass die Entwicklungen letztlich für den Firebee- oder Atari-user gedacht sind. Nur mit einem Rechner unterhalb der Firebee, würde ich heute nicht mehr ernsthaft arbeiten. Andere wollen spielen. Das ist mein Spiel.
Ich finde das auch etwas kompliziert mit dem remapping, aber den Ansatz verstehe ich jetzt und ich denke man kann es so weiterentwickeln, dass jeder damit klar kommt und man davon profitiert.
Einstweilen habe ich mal eine saubere fvdi.pal erzeugt (für XAaes). Das Format mit den 4 zusätzlichen Bytes gibts doch eigentlich schon lange. Und man fragt sich, warum fvdi damit nicht zurecht kommt. Das Testicon mit der CD ist das mit der falschen Palette. Ich habe für meinen Desktop das mal gegen das richtige CD-Icon ausgetauscht, dass auch bei mir gut aussieht. Also nicht wundern, wenn die falsch aussehende Scheibe bei mir plötzlich richtig aussieht. Dieses auswählen der richtigen Icons, insbesondere gerade das CD-Rom-Icon habe ich auch früher so gemacht, daran erinnere ich mich noch sehr genau. Ich bin sogar der Meinung, dass ich damals mit ähnlichen Problemen kämpfte und schon das Matrix-Tool benutzt hatte, um mit der Palette zu spielen. Wenn ich dereinst wieder an meine Atari-festplatten rankomme, werde ich all die Software wiederfinden. ;)
-
Das Format mit den 4 zusätzlichen Bytes gibts doch eigentlich schon lange. Und man fragt sich, warum fvdi damit nicht zurecht kommt
.
Ich weiß ja nicht, was das TOS-VDI und das NVDI machen, aber das fvdi-Format wird vom Matrix-Tool nicht geladen. Das deutet doch daraufhin, dass fvdi was falsch macht und das ist zumindest unbefriedigend.
-
Hast Du das probiert:
Man kann die fvdi-Palette ganz einfach in eine XaAES-Palette umwandelen, indem man
cat pa01 <fvdi-Palette> >XaAES-Palette
in einer shell eingibt
Die Datei pa01 enthält dann PA01 ohne newline..
-
Aber gebraucht wird gerade das umgedrehte. Denn die nvdi.pal und die gem.pal sind ja Referenz. Die würde ich nicht anzweifeln.
Im Falle des fvdi.pal, habe ich einfach fvdi die fvdii.pal laden lassen beim booten. Jetzt hat das Matrix genau diese Palette, wie wir ja längst wissen und dann habe ich aus Matrix die Palette exportiert. Das ergibt eine xaaes-fähige fvdi.pal. Welche oben anhängt. Ein direktes Laden über das file-system der fvdii.pal in Matrix funktioniert nicht. Was wiederum ein Beweis ist, dass die Palette über das VDI geladen wird und nicht irgendwie über das Filesystem innerhalb von Matrix und gewiss auch vom IconEditor. Über das Filesystem lassen sich offenbar nur die langen PALs laden, was wiederum der IconEditor garnicht beherrscht.
Ich erwähne das nicht, weil ich damit nicht klar komme, sondern weil ich der Meinung bin, da sollte was geändert werden = Einheitliches Palettenformat
-
Sicher sollte da was geändert werden: Alle sollte nur das Matrix-Format verwenden (mit PA01 am Anfang). Aber das kann man wohl vergessen.
Etwas dumm ist zugegebenermaßen, dass XaAES .pal als Endung verwendet, so wie fvdi, und MyAES, die alle das einfache 1536-byte lange Format verstehen.
Deine Erklärung ist mir leider nicht so ganz klar geworden.
Also:
fvdi->XaAES: PA01 am Anfang einfügen
XaAES->fvdi: PA01 entfernen.
Wenn das nicht geht, stimmt noch was anderes nicht.
Das Matrix-tool streikt gelegentlich mit fvdi, da muss man schonmal Komplett-redraw machen, manchmal geht's garnicht., hab ich ja schon gesagt.
Man kann die Palette ja über XaAES laden (Ctrl-Alt-Shift-P), dann wirkt es nur auf die AES-Palette, oder in dem Programm selbst mit dem Disk-Icon, dann wirkt es auf die Palette in CXX-Setup. Die ist ja nicht dieselbe bei TC. Sollte zumindest so sein ..
-
Also:
fvdi->XaAES: PA01 am Anfang einfügen
XaAES->fvdi: PA01 entfernen.
Genau, das meinte ich. Ich habs nicht ausprobiert und weiß auch nicht, wie man die zweite Zeile durchführt (außer natürlich im Hexedit)
Ich habe es gemacht, wie oben beschrieben und wie wir empirisch herausfanden. Nämlich beim booten lädt das cx-Programm eine der beiden Paletten nvdi5.pal oder fvdii.pal. Durch speichern erzeuge ich dann die xaaes-taugliche Palette. Umgekehrt kann man über das Disk-Icon ja nur letztere Formate laden, und da fehlte mir halt das fvdi.pal. Da Deines ja nicht sauber war. Es ging mir eben gerade darum das kurze in das lange zu verwandeln und nicht umgekehrt. XAaes kann ja auch beides, die Palette beim booten laden, oder per shortcut über den FS. Das Matrix-Tool kann das auch, mit der Einschränkung des richtigen Formates, nur der IconEditor kann ausschließlich ersteres.
-
Das kurze in das lange verwandeln ist doch einfach: hab ich doch schon zweimal erklärt: mit cat.
Und außerdem sind meine Paletten immer sauber!
Geht auch mit einem Einzeiler:
echo -n PA01 >neu.pal && cat nvdi5.p >>neu.pal
nvdi5.p ist jetzt die Palette, die bei mir von fvdi geladen wird.
-
Und außerdem sind meine Paletten immer sauber!
Stimmt, sauber und genau die gleiche wie die durch mich erzeugte. Da muss früher was schief gelaufen sein, als ich sie in das Tool geladen hatte, war sie hybrid. Nun ist sie sauber, habe sie extra nochmal downloadet.
http://forum.atari-home.de/index.php?action=dlattach;topic=10117.0;attach=4085 (http://forum.atari-home.de/index.php?action=dlattach;topic=10117.0;attach=4085)
-
Damit's nicht langweilig wird. Gemclip macht komische Redraw Sachen. Schätze aber, ist selbst dran schuld.
(http://forum.atari-home.de/index.php?action=dlattach;topic=10117.0;attach=4086)
Wie hast Du das denn sauber gekriegt? Tritt nicht mehr auf - clean
-
Aber es geht weiter. Noch immer besteht bei mir ein Palettenunterschied zwischen ein Desk-Icons und den favicons in den Iconify-Bildchen.
fvdi.sys palette c:\nvdi5.pal
xaaes remap_cicons = yes, palette = nvdi,
app_options = default, ..., icn_pal_name = nvdi
app_options = xasys,..., icn_pal_name = nvdi
app_options = aessys, ..., icn_pal_name = nvdi
Der Iconify-Reihenfolge bug scheint gefixed.
-
Was steht denn bei palette= in xaaes.cnf?
Wenn da auch nvdi steht, wird nichts umgemappt.
Ansonsten muss man erstmal feststellen, wie die icons eigentlich aussehen müssen, also was falsch und was richtig ist.
Ich meine die Iconify-Icons werden nicht vom AES gemalt, und kommen daher vom Programm mit der fvdi-Palette.
Aber es ist ja auch noch ein Fehler beim remap, hab ich ja schon geschrieben, muss ich sowieso noch verbessern.
Sind denn nvdi5.pal und nvdi.pal gleich (bis auf das PA01)?
-
Was steht denn bei palette= in xaaes.cnf?
schrieb ich oben
xaaes remap_cicons = yes, palette = nvdi,
Im Falle des Netsurf ist es eindeutig das leuchtende Hellblau, wie auch unter Linux. Im Iconify erscheint wieder das graublau, schwarzgrau verpixelt. Bei Highwire sind auch geringe Unterschiede in den Farben zu bemerken, wobei es mir fast im Iconify richtiger aussieht, so wie bei Dir unter Truecolor.
Sind denn nvdi5.pal und nvdi.pal gleich (bis auf das PA01)?
Ich denke ja, aber werde ich nochmal sorgfältig prüfen. Ok, wenn da noch ein Bug bekannt ist, ist ja gut. :)
Weiters, ;) wenn ich folgende Programme laufen habe:
tw2, rsm, netsurf, highwire, div. Desktop-Fenster. Jedes Programm hat mind. ein Fenster offen und iconified. Jetzt beende ich Teradesk. Lande auf der Xaaes-Ebene. Normalerweise bleiben die geöffneten Programme aktiv und sind auch auf dem AES-Desktop weiter als Iconify zu sehen. Nur Highwire verschwindet und taucht auch nicht wieder auf, wenn Teradesk erneut gestartet wird. Liegt das allein an Highwire? ???
-
Sind denn nvdi5.pal und nvdi.pal gleich (bis auf das PA01)?
Etwas sorgfältiger überprüft = Ja!
Bei der Iconify-Würfelei, habe ich jetzt doch nochmal provozieren können, dass zwei Teradesk Iconify-Fenster übereinander zu liegen kamen. Muss ich das genau protokollieren. ??? Das wird schwierig.
Wenn ich den IconEditor offen habe und dann TeraDesk beende, gibts einen BusError. Ob das verifizierbar ist? Gelegentliche BusError kommen schon mal vor und erscheinen mir immer eher zufällig.
1.5.5 Beta
-
Hallo,
nur mal eine allgemeine Anmerkung zu diesem Thread...
Ich findees ist nicht verkehrt sein Wirken auf andere einzuschätzen...
Fragen sind gut und wichtig - aber ich finde hier wird
das Mass überschritten. Wenn ich eine 0900 support
hotline hätte, dann würde ich dich Fragen gerne am Telefon
beantworten - aber in der Freizeit für Lau, und dann in einer art, kaum nach dem man eine Frage beantwortet hat kommt schon die näxte? Und dann
auch noch blöd angemacht werden wenn man zu verstehen
gibt das es reicht?? Hm...
Der letzte Satz geht an rastr- aber der ist ja nicht mehr angemeldet...
-
ich hoffe Du meinst nicht mich. Worauf bezieht sich jetzt Deine Kritik, Mono? Ich sehe das nicht als Support, sondern als Hilfe beim Debuggen. Ich mache das nicht für mich allein. Meinst Du, das sollte man per PM machen? Aber so haben doch hier andere die Möglichkeit ihre Erfahrungen auch einzubringen und zu überprüfen. Darin sehe ich den SInn dieses Forums. Immerhin steht XAaes vor einem neuen Release.
-
Natürlich ist es wertvoll, wenn Anwender ein (vermeindliches) Fehlverhalten melden, anstatt alles zu schlucken. Aber Du hast schon Recht: Man kann alles übertreiben, und bugreports sollten immer eins nach dem anderen und vor allem so geschildert werden, dass sie reproduzierbar sind. Sowas wie "Mir ist hier gerade was abgestüzrt" unter "XaAES bugreport" ist nicht unbedingt hilfreich.
Aber unterm Strich konnte ich dank Goli schon einige Sachen reparieren in XaAES, die ich wohl so schnell nicht gefunden hätte. Es geht eben nicht immer alles von heute auf morgen.
Also: Immer schön mit Thema und nachvollziehbarer Vorgehensweise wäre nicht schlecht.
Das mit dem release würde ich nicht so wahnsinnig eng sehen, das dauert sowieso noch.
-
Ok, ich will versuchen daran zu arbeiten. Aber ein einfaches "hier stürzt was ab", sagt doch auch was aus. Wenn es auch erstmal nicht viel weiterhilft, so weiß man doch, hier muss noch untersucht werden. deshalb finde ich es immer etwas unfreundlich, wenn immer gleich gesagt wird, mach das mal nachvollziehbar. Das ist oft sehr mühevoll und für den Laien gar nicht möglich. Und so erfährt man auch, ob anderen es auch so geht und den Bug vielleicht schon kennen und Hinweise geben können, wie man wo suchen sollte. Das st doch der SInn eines Forums. Wenn man unspezifisch sagt, es crashed, erwartet man doch auch nicht sofort eine Lösung des Problems. Wie ich überhaupt nicht erwarte, dass Fehler sofort oder überhaupt behoben werden. das kann ich doch gar nicht verlangen. Aber immerhin hat der Autor einen Hinweis, dass was klemmt. Was ihm vielleicht noch nicht aufgefallen ist. Mehr nicht. ok, ich rede zu viel...
-
Es tut mir nun mal leid. Jedes neue Programm, dass ich ausprobiere, ergibt mindestens einen neuen Fehler. Ich könnte gleich weiter machen. Soll ich mich jetzt auch hier abmelden? >:(
-
Moinmoin.
Soll ich mich jetzt auch hier abmelden? >:(
Quatsch!
Es ist ja tatsächlich so, daß Du offensichtlich betatestest und auch nach den Problemen suchst und nicht einfach sagst, daß irgendwas hakt.
Ich wundere mich bei der Postingflut nur, daß Du nicht einen Messenger verwendest.
-
Es tut mir nun mal leid. Jedes neue Programm, dass ich ausprobiere, ergibt mindestens einen neuen Fehler. Ich könnte gleich weiter machen. Soll ich mich jetzt auch hier abmelden? >:(
Eigentlich hatte ich ja vor, die remap-Geschichte noch zu vertiefen, später ;)
-
Ja klar, ich hab's doch nicht eilig, das kam vielleicht falsch rüber. Sehr hilfreich ist es auch, wenn Du das alles theoretisch ein wenig verarbeitet hast, Du mir sagst an welcher Ecke ich was testen oder ausprobieren soll. ;)
Bei einem Massanger kann ich ja meine eigenen Fehler nicht so gut korrigieren. Soll doch auch für andere nützlich sein hier. Wer an Xaaes nicht interessiert ist, der muss ja nciht mitlesen, steht doch drüber.
Natürlich weiß ich nicht so genau, was an XAaes liegt und was die Programme falsch machen.
Ich wunder mich über den Zustand des ganzen Systems. Nachdem ich einige Jahre fremd gehe. Habe auch gar nicht vor, das zu bereuen. Aber wenn ich bedenke, dass ich schon neben Ozk gestanden habe und der sich bereits in windiger Geschwindigkeit mühte XAaes auf Vordermann zu bringen, wundere ich mich, dass noch so vieles klemmt. Ich meine jetzt gar nicht XAaes, sondern das ganze System. Es sind oft Klitzekleinigkeiten, die es für den User praktikabel machen würden, aber nichts tut sich. Gerade habe ich mal das 7up Paket testweise installiert. Als erstes haut es einem seinen eigenen völlig überalterten Desktop um die Ohren, was natürlich auch zu zahlreichen Redraw-Fehlern führt in einem Multitasking AES. Dabei ist es so einfach, dem Paket eine default-7up.inf beizufügen, mit vernünftigen Einstellungen für moderne Systeme. Ist aber keine dabei, es sucht sie aber verzweifelt in /home. auch nicht gerade sinnvoll bei reinen Atari-Systemen. Man verbringt ne Menge Hakeleien, bis alles so läuft wie es out of the box laufen sollte. Insbesondere in Hinblick auf die Firebee. ich hab ne PM an Gerhard Stoll geschrieben, und wollte es hier eigentlich gar nicht besprechen.
Bringt man mal ein bisschen Leben in die Bude, ist es auch nicht recht. ::)
Egal, ich wundere mich nur halt, dass es überall klemmt.
-
Ich muß jetzt auch mal OffTopic was dazu sagen. Ich bin nämlich in der Lage beide Seiten nur allzugut zu kennen! ;)
Einerseits denke ich gehe ich mit meinen "Bugreports" dem ganzen ACP-Entwicklerteam manchmal gehörig auf die Senkel. Und besonders mit meiner "Ich-kenne-mich-nicht-aus-und-bin-doch-nur-Anwender-Attitüde". Auch den Helmut habe ich schon mal 3 Wochen so in Beschlag genommen. ;)
Aber; ist es ja auch so! Um dieses Posting zu schreiben, habe ich grade 5 Minuten mit Backspace alle Zeichen einzeln löschen müssen, weil Text markieren geht halt momentan nicht mit Netsurf, ... nur so als Beispiel, warum ich Goli schon nachvollziehen kann. Aber das kann man niemandem "anlasten" und die Leute die sich eh schon in Ihrer Freizeit abstrudeln bis zum Geht nicht mehr, braucht man da auch nicht "in die Pflicht zu nehmen"
Womit wir schon beim "Andererseits" wären, ich kenne das nämlich auch zur Genüge, wenn man von Usern für Dinge verantwortlich gemacht wird, die einen Behandeln, wie wenn man da ein normal marktwirtschaftliches Produkt verkaufen würde, obwohl man einfach nur seine ganze Freizeit opfert - und so kommt mir Helmut auch vor. ;)
Ich denke die "Lösung" ist immer respektvoll zu sein, aufeinander zuzugehen, und den anderen Standpunkt zu sehen. Einerseits die reine Userseite wirklich wahrzunehmen, besonders von Solchen die das System echt nutzen, und andererseits die Entwickler wirklich wertzuschätzen! Dann passt das schon! ;)
Man verbringt ne Menge Hakeleien, bis alles so läuft wie es out of the box laufen sollte. Insbesondere in Hinblick auf die Firebee. (...)
Bringt man mal ein bisschen Leben in die Bude, ist es auch nicht recht. ::)
Insofern ist es glaube ich schon recht, wenn Du hier sagst was Sache ist, solange es nicht darauf hinausläuft, die verbliebenen Entwickler für Alles verantwortlich zu machen. ;)
Und den Teil mit der FireBee verstehe ich nicht. Wie meinst Du das?
-
Ich finds super wie hier debuggt wird. ;D Und es kommt ja auch etwas dabei herum. Und Helmut ist auch immer sofort behilflich genauso wie Goli ein guter Betatester ist. Wegen mir also weiter so.... evtl. mal ne kleine Pause für Helmut. >:D ;D
-
BTW: Goli, wenn Du Lust hast, kannst Du mehr Farb-Icons machen, mit größeren Quadraten, und mehr. am besten allen, Farben.
Das hält dich vielleicht etwas vom Rumspielen ab ;)
-
Aber das kann man niemandem "anlasten" und die Leute die sich eh schon in Ihrer Freizeit abstrudeln bis zum Geht nicht mehr, braucht man da auch nicht "in die Pflicht zu nehmen"
Das wäre fatal, wenn das so rüber käme. ich mache hier natürlich niemanden verantwortlich für irgendwas und schon gar nicht die letzten Entwickler, die sich hier abstrampeln. Ich gehe so an die Sache heran, weil ich davon ausgehe, dass wir alle so ran gehen. Nicht an ein kommerzielles System mit Hotline und Support, sondern alle gemeinsam, um die Platform voran zu bringen. Ich erwarte gar keine Reparatur, Erklärungen, Hilfen dergleichen, aber mehr als sagen, was schief läuft oder dass was klemmt kann ich doch nicht tun. Dadurch soll sich hier auch niemand getrieben fühlen. Besser wäre vielleicht ein Bugtracker, aber bitte nicht auf englisch, denn dann verliere ich nämlich die Lust. Da kann ich dann nur ganz wenig beitragen und die Dinge gewiss nicht richtig erklären. Beziehungsweise, das wäre zusätzliche Mühe, sinnlos.
Mit der firebee meinte ich nur in Hinblick darauf, dass ja hier auch ein Softwarepaket mitgeliefert wird, dass wirklich out of the box funtkionieren soll. Und da sie mit Mint ausgeliefert wird, sollte z.B. ein Programm wie 7up schon mit einer vorkonfigurierten .inf daherkommen (ohne jetzt zu wissen, ob das Bestandteil ist und ist nur ein Beispiel).
Ich bin nicht empfindlich. Gerade Mono sollte still sein, dem ich unter größter Mühe vor einem Jahr eine Cross-Compiler-Umgebung auf meinem Laptop eingerichtet hatte und seine damaligen Netsurf-sourcen erfolgreich kompilierte. Kleiner Beta-Test. Damals lief das aranym noch nicht mal auf dem Rechner, oder nur gerade mal als MiniPack und Afros in rudimentärer Ausstattung. Danach kamen etliche Updates meiner Hostsoftware und erst vor Weihnachten habe ich den Cross-Compiler, diesmal passend zu meiner Distribution, wieder installiert.
Aber warte nur Mono, bis ich erstmal netsurf zu fassen kriege. ;D
Zu seinem Glück, funktioniert das Netzwerk bei mir nämlich noch nicht unter aranym. >:D
Ohjeh, da steht Euch ja noch was bevor. ::)
Wegen der Farb-Icons, schaun wir mal.
-
Ich finds super wie hier debuggt wird. ;D Und es kommt ja auch etwas dabei herum. Und Helmut ist auch immer sofort behilflich genauso wie Goli ein guter Betatester ist. Wegen mir also weiter so.... evtl. mal ne kleine Pause für Helmut. >:D ;D
Dem kann ich nur beistimmen.
Gruß Milan
-
Ich gehe so an die Sache heran, weil ich davon ausgehe, dass wir alle so ran gehen. Nicht an ein kommerzielles System mit Hotline und Support, sondern alle gemeinsam, um die Platform voran zu bringen.
Passt, dann sind wir beide z.B. eh auf der selben Wellenlänge. ;)
Mit der firebee meinte ich nur in Hinblick darauf, dass ja hier auch ein Softwarepaket mitgeliefert wird, dass wirklich out of the box funtkionieren soll. Und da sie mit Mint ausgeliefert wird, sollte z.B. ein Programm wie 7up schon mit einer vorkonfigurierten .inf daherkommen (ohne jetzt zu wissen, ob das Bestandteil ist und ist nur ein Beispiel).
Achso. Ja, das Softwarepaket der FireBee gibts ja genau aus den Gründen, daß man sich das Rumgetue am Anfang erspart. Und deshalb ist auch QED dabei und nicht 7up (freut mich übrigens, daß die 7up-Desktopprobleme nicht FireBee-spezifisch sind *g*)
Aber warte nur Mono, bis ich erstmal netsurf zu fassen kriege. ;D
Zu seinem Glück, funktioniert das Netzwerk bei mir nämlich noch nicht unter aranym. >:D
Ohjeh, da steht Euch ja noch was bevor. ::)
Haha, ...
Zur Entspannung könntest Du ja Deinen Test-Enhusiasmus auf mehrere Entwickler aufteilen, und z.B. mal die Aranymleute "ärgern". ;D Weil daß das mit dem Netzwerk so ein Krampf ist ist ja auch unglaublich. Ich hab vor 2 jahren meinen Rechner nach Tschechien geschleppt und die Jungs dort haben 4 Stunden dran gewerkelt bevor das gelaufen ist. Wohlgemerkt nachdem meine 2 lokalen Linux-Gurus je nach 2 Stunden aufgegeben haben, … ;)
-
Na Du bist näher an Tschechien dran, als ich, aber das Bier ist gut. Da kann ich mich ja auf was gefasst machen. Ja sicher aranym wäre auch noch so ein Kandidat. 7up läuft inzwischen ganz gut hier. Ich verfüge aber nur über das Programm-Paket und den Hypertext, die zahlreichen Zusatzprogramme, die noch zu dem Gesamt-Paket mal gehörten, habe ich noch nicht gefunden.
-
Neues Farbicon:
Auf meinem kleinen LCD-Display ist das natürlich extrem mühsam, da man die Farbnuancen kaum unterscheiden kann. Dazu muss man ständig den Blickwinkel verändern.
Die Farben in der Palette sind nummeriert. Man erhält die Nummer, wenn man im Kalibrierungsfenster des Matrixtools den Zeiger über der jeweiligen Farbe hält.
Ich habe die ersten 16 Farben 0 - 15 bei Seite gelassen und mit der 16. begonnen. Der Filename des Icon enthält den Farbbereich in Nummern.
Anhängendes Icon ist komplett aus der NVDI-Palette.
Mir fehlt sehr, die Möglichkei den Mauscursor mit dem shortcut ALT-Cursor zu bewegen. Da mein Mousepad sehr empfindlich ist in Bezug auf den Cursor. Ich glaube, das funktionierte schon mal bei mir unter Aranym. Nun habe ich aber die aranym-Einstellung scrolling wie Arrow-Keys und nicht die Einstellung Eifel. Die Folge ist wohl, dass die Cursor-Shortcuts auf das Fensterscroling wirken und nicht auf den Cursor. Das muss ich noch ausgiebig untersuchen.
(http://forum.atari-home.de/index.php?action=dlattach;topic=10117.0;attach=4150)
-
Freut mich wenn Ihr alle Positiv gestimmt seit - mir wurde es in diesem Thread irgendwann zu viel, von daher, ich habe dann aufgehört es zu verfolgen 8)
-
Noch ein kleiner Vorschlag. In der Exempel-XAaes.cnf in der Sektion
Clipoard
gibt es kein Beispielhinweis für die Verwendung des HostClipboard unter Aranym, entsprechend der Doku in
http://wiki.aranym.org/gem_clipbrd (http://wiki.aranym.org/gem_clipbrd)
#####################################################################
# clipboard = <path> # path to clipboard
CLIPBOARD = u:\host\clipbrd\
setenv SCRAPDIR u:\host\clipbrd\
setenv CLIPBRD u:\host\clipbrd\
Das hätte mir um Wochen früher den Zugriff auf das Hostclipboard ermöglicht. ;D
-
ist das setenv wichtig? Ich hab sowas nicht drin, allerdings wird das vorher gesetzt., geht aber auch ohne.
Und dass das clipboard auf /host/clipbrd gesetzt werden muss, ist doch wohl eher aranym-Sache. Das geht auch mit jedem anderen AES.
-
das ist wohl eine dreifache sicherheit für Programme, die mit dem AV-Server nicht umgehen. Es steht jedenfalls komplett so im Aranym-Wiki, nur muss man die Seite auch finden. ich habe sie nur über google-Suche gefunden.
Ja, natürlich ist das ein Aranym-Fall. Nur in Aranym steht ja auch keine Beispiel-Konfiguration dafür. Weil es eben in XAaes.cnf gesetzt wird. ;) Daher wäre es nützlich diesen Anwendungsfall als Beispiel mit auf zu nehmen, unterhalb der Beispielzeile
# CLIPBRD = C:\Clipbrd
Apropos: Es funktioniert bei mir, aber nur in eine Richtung. In der anderen Richtung muss ich mit Tricks arbeiten, da u:\clipbrd kein reales Verzeichnis ist, sondern nur ein alias für die PIPE. Also muss ich vorher scrap.txt in einen realen Folder kopieren, den ich dann ja auch vom host aus erreiche. Aber nix mit Copy & Past.
-
Noch ein offensichtlicher Schreibfehler in dem README für das Netzwerk. Es kommt in mehreren Texten vor (Wortlaut ist immer der gleiche):
README, nfeth.txt und README.xif
And before loading this driver please check (and possibly fix) the
read/write permissions of the "/dev/net/tun" device:
linux:~# chmod a+rw /net/dev/tun
Hier ist offenbar der Pfad in der unteren Zeile verdreht. Ich habe es korrigiert und es funktioniert. Ist natürlich auch ne Aranym-Sache.
-
Wie kriege ich es bloß wieder hin, dass Aranym mit den gleichen Fensterparametern aufgerufen wird, ich meine auch das Startfenster. Jedesmal. wenn ich ein neues Mintara.prg installiere, wieder das gleiche Problem. Ich kann nicht sagen, wie ich es das letzte mal hingekriegt habe, dass sich aranym die Koordinaten merkt.
-
Geht nicht und hat offensichtlich keinen Bezug zum Thema.
-
Naja, Bezug ist halt nicht klar. Aber bei mir ging das irgendwie immer, und beim vorletzten Update eine weile lang nicht, bis es dann wieder klappte. Kann es sein, dass das Speichern der Koordinaten vollständig mein LINUX hinkriegt? Ich wüsste nicht wie, aber schließlich sinds ja auch nur Fenster. ich schau mal.
Es ist halt lästig, wenn gleich zu Beginn das Linux-Terminal verdeckt ist und ich so den Log nicht sehen kann. Deshalb liegt das Aranym fenster auf der rechten Seite und das terminal auf der linken, sollte jedenfalls.
edit: Wenn ich nur nicht so vergesslich wäre. :-[ Also es hat tatsächlich nichts mit dem Thema und auch nicht mit Aranym zu tun. Man muss nur einmal die Linux-Session herunterfahren, ohne Aranym zu beenden. Also geöffnetes Fenster und schon startet aranym beim nächsten mal und immer an der gleichen Position. Das ist ein Feature des xfce-Desktop.
Ich werde mal mein Skript auf Helmut stellen. Aber dann nicht wieder nach Fehlern im Trunk fragen. ;D
Wie kriege ich denn das hier weg, geht nur weg, wenn ich aranym als root starte:
ARAnyM RTC Timer: /dev/rtc: Permission denied
ist das nun /dev/rtc in ATARI, oder im Host?
-
Hab mal das Thema geändert :)
Man kann aranym die Position vorgeben
-P <X,Y> or <center> set window position
Scheint aber nicht zu funktionieren. Normal hab ich immer center, aber das Fenster landet immer irgendwo.
Wenn man mit Pause das Menu öffnet, kann man's aber normal verschieben.
/dev/rtc gibt''s m.W. nicht unter MiNT.
-
/dev/rtc
Naja, ist ja auch logisch, dass es sich um den Host handelt, denn mit User.rechten hat aranym keinen Zugriff drauf, mit root Rechten klappt es. Die Fehlermeldung verschwindet und irgendwas mit RTC wird gemeldet.
Wie haben die Konstrukteure sich das gedacht? Aranym als root?
Mit der Ortszeit habe ich aber nie Probleme gehabt, daher verstehe ich die Fehlermeldung auch nicht richtig. Ist hier der Takt gemeint und hat das irgendwas zu sagen?
Danke für den Hinweis auf die Koordinaten. Bei mir funktioniert das sogar und Verschieben kann ich das Fenster immer und zu jeder Zeit. Es funktioniert sogar sehr gut für das Startfenster und dann gibt es noch ein automatisches Clipping auf den Bildschirm. Aber das ist ok.
-
Wegen des Iconifyes arbeite ich an einem genauen Protokoll. Das ist ne langwierige Angelegenheit.
Damit Du aber was zu grübeln hast, hier noch was neues
Neues Feature! ;D
(http://forum.atari-home.de/index.php?action=dlattach;topic=10117.0;attach=4218)
-
Wo hast Du denn da rumgespielt?
Sag schon - zum Grübeln hab ich so schon genug!
Thema ändern geht hier wohl nicht ...
-
Kann ich nicht beantworten. Meine Klicks müssen manchmal dreifach erledigt werden, weil mit dem mousepad ist das so eine Sache. Eigentlich genügt ein ganz leichter Tip auf das Pad, aber eben immer auf die richtige Stelle, das ist die Mitte, ansonsten scroled man schon. Und so passiert es manchmal, das ein Click nicht richtig registriert wird. Möglich, das da irgendwas in eine Zwischenzustand geraten ist. Es ist ja sicher eine vom Host ermöglichte Transparent-Darstellung, die sich hier eingeschlichen hat. Hat vermutlich nichts mit FreeMint oder XAaes zu tun. aber wer weiß? Wollte Dich nur ärgern. :D
Durch dieses unpräzise Klicken, dauert es auch immer, bis ich wieder im ATARI lande. Grapmouse geht nicht besonders gut, dazu ist die Maus zu empfindlich und ich kann dann den Atari-Cursor nur schwer einfangen, daher mache ich immer Hostmouse. das geht besser, aber eben das Klicken ist so eine Sache. Das wäre vermutlich mit einer Maus besser.
-
Ich hab was gefunden. Hyp_view (und es ist ja ein Hyp_view-fenster mit einem Hypertext) kennt folgende Option, die bei mir aber nicht angeschaltet ist und war:
# Draw pictures transparently: 1 = ON (default) / 0 = OFF
#TRANSPARENT_PICS=0
Das passt doch. :) Wenn das default ist, dann wundert mich das ja nicht.
-
Ok, schieben wir's auf highwire :)
-
Das ist Hyp_View gewesen, ich bin schon ganz durcheinander. Sorry.
-
Thema ändern geht hier wohl nicht ...
Muß pro Posting beim Antworten gesetzt werden.
Auch, wenn man einen Thread umbenennt, behalten die Posts ihren alten Betreff.
-
Wie ungünstig ...
-
Laut Anleitung wird mouse_w.adi gegenüber mouse.adi bevorzugt. Das ist leider nicht der Fall. Um Mausradunterstützung zu erhalten, muss ich zZ das mouse.adi umbenennen damit es nicht gefunden wird oder direkt löschen. Dann klappt es auch mit dem Mausrad.
-
Die Anleitung ist falsch, aufgrund des Konzepts geht das garnicht, die Auswahl erfolgt anhand der Reihenfolge im directory, also eher zufällig. Jetzt steht im bootlog immerhin eine Meldung, dass beide vorhanden sind.
Bitte nicht immer alles in ein Thema schreiben!