[NMZ] Ein neues Gewand für EmuTOS

[Grendell]

Moin!

Die Entwicklung gefällt mir! Den "alten Style" finde ich nicht so gut, aber das ist ja bekanntlich Geschmackssache. Die Möglichkeit der Einbindung von "EMUICON.RSC" benutze ich schon seit der letzten Version und das funktioniert soweit ganz gut. Ich freue mich auf die Möglichkeit, neue Mauszeiger nachzuladen. So kann man schon mal, wenn man will, das Aussehen des Originals nachempfinden.

EmuTOS macht sowieso im Moment mehr Spaß, weil es endlich den Blitter unterstützt.

[1ST1]

Toll, das "neue" Design gefällt mir.

[simonsunnyboy]

Wie ist denn der aktuelle Stand? Ich würde den Look gerne in eigenen EmuTOS Images reincompilieren.

[czietz]

Wie ist denn der aktuelle Stand? Ich würde den Look gerne in eigenen EmuTOS Images reincompilieren.

Aktuelle Snapshots (und damit auch das kommende 0.9.9er-Release) können Mauscursor und Icons aus einer Datei nachladen. Die eincompilierten Standardicons und -cursor zu ändern, ging ja schon immer. Ich weiß aber nicht, ob der neue Look zum Standard wird, z.B. mit dem 1.0er-Release. Wimre gab es auch "Bedenkenträger", die ein möglichst altbackenes Aussehen beibehalten wollten...

[simonsunnyboy]

Mir reichen die RSC Files, die ich in den Sourcetree reinkopieren könnte. Bauen kann man selber. Nachladen kostet unnötig RAM.

[czietz]

Mauscursor z.B. aus diesem Thread: http://forum.atari-home.de/index.php?topic=13761.0. Ziel ist aes/mform.rsc. Desktop-Icons z.B. von hier: https://sourceforge.net/p/emutos/mailman/message/35940345/. Ziel ist desk/icon.rsc.

[simonsunnyboy]

Der PAVEL look gefällt mir gut. Den würde ich sofort als Standard akzeptieren

Ich schau mal, daß ich das icon.rsc ausgetauscht bekomme. Danke!

[ari.tao]

Hallo @czietz , da als PM nicht möglich, hier nun öffentlich:

Hallo Christian,
schön, Dich in H. kennengelernt zu haben. Hier nun die verabredete PM.
Ich bin endlich dazu gekommen, mir die Icon-Behandlung in EmuTOS näher anzuschauen (nachdem ich das G-Problem mit Hatari überwunden hatte). Vergiß, was ich in H. gesagt habe. Es hat sich herausgestellt, daß das Problem beim Nachladen von Icon-Resourcen durch EmuTOS von viel primitiverer Natur ist: Der Emu-Desktop ist in dieser Hinsicht schlicht inkompatibel zum GEM-Desktop. Ich empfehle deshalb, daß Du auf eine Angleichung hinwirkst.
Nähere Einzelheiten siehe #27 in
   http://forum.atari-home.de/index.php?topic=13724.20   hier unten --vv
Herzlich grüßt
   ari.tao

-------

Nachdem ich mir die in #7 angehängte EmuIcon.RSC näher angeschaut habe, ist klar:
Diese enthält zwei Bäume - in deren erstem acht Icons, die die im EmuTOS eingebauten Defaults ersetzen, im zweiten dann alle weiteren, mit fortlaufender Numerierung (dh. der zweite Baum beginnt mit Nr. acht). Wenn man eine .RSC mit nur einem Baum anbietet, so wird diese schlicht nicht angenommen.
   Der Emu-Desktop ist in dieser Hinsicht inkompatibel zum GEM-Desktop.
Eine solche Mimik mit zwei Bäumen bedeutet aber, daß weder DeskIcon.RSC noch (New)Desk(Top).INF vom GEM-Desktop einfach übernommen werden können. Dem armen User/Tester wird also aufgebürdet, alle Icon-Zuweisungen zu erneuern. Da muß sich dann niemand wundern, wenn die Rückmeldungen spärlich ausfallen...
Meine Empfehlung:
1) Zusammenfassen in nur einem Baum, dessen erste (acht?) Icons die Defaults ersetzen.
2) Anzahl, Reihenfolge (!) und Bedeutung (!) der ersten Icons an TOS angleichen.
3) Die Verarbeitung von EmuDesk.INF so angleichen, daß NewDesk.INF verwendet werden kann.
4) Im Idealfall sollten imho sogar die Namen DeskIcon.RSC & NewDesk.INF beibehalten werden.

Anhang: Beschreibung des Formats von NewDesk.INF

[1ST1]

ari.tao, dein Vorschlag ist sehr gut!

Man kann zwar auch den Aufbau in EmuTOS für besser halten, aber er ist halt leider inkompatibel.

[Thorsten Otto]

Man kann zwar auch den Aufbau in EmuTOS für besser halten, aber er ist halt leider inkompatibel.

Ja, sicher ist er inkompatibel. Ihn jetzt aber zu ändern und an newdesk.inf anzugleichen, würde aber bedeuten daß er widerum inkompatibel zu vorherigen Versionen ist, und Benutzer zwingen die icons neu zuzuordnen, ohne daß sie eine eigene Icon-Datei laden. Ich denke mal das würde noch viel grösseres Geschrei geben.

Ganz abgesehen davon ist es ganz normal daß ein anderer desktop andere Konfigurationen hat. Du kannst ja auch nicht erwarten die GEMINI.INF mit Jinnee benutzen zu können oä.

Ausserdem hatte Atari vermutlich einen guten Grund, warum sie den Aufbau der NEWDESK.INF nie selber offiziell dokumentiert haben, ua. nämlich die Möglichkeit ihn bei Gelegenheit ändern zu können.

[czietz]

Ich denke, dass es -- neben den von Thorsten schon angemerkten Punkten -- gute Gründe gibt, dass weder Icon- noch INF-Datei kompatibel sind; Gründe, die ich gerade in der Mailingliste angefragt habe. Ich denke nicht, dass es hier zu einer Angleichung kommen wird.

[czietz]

Was wäre denn mit einem separaten Konverter von Atari-TOS-Format nach EmuTOS-Format? Da Du INF-Dateien und erst recht die Icons nicht täglich änderst, wäre das eine Lösung, mit der EmuTOS abwärtskompatibel zu sich selbst bleiben könnte.
Würdet Ihr EmuTOS nutzen, wenn ein derartiger Konverter verfügbar wäre?

[Arthur]

Die Idee von ari.tao würde mir auch gefallen. Viel wichtiger ist für mich jedoch ein alternatives OS zu haben das möglichst kompatibel zum original TOS von Atari ist (wenn es um Programmausführung geht). Wenn es einmal so weit ist das einem kaum noch ein Programm einfällt das nicht mit EMU-TOS läuft, dann wird das Atari-TOS vielleicht mal eine Seltenheit werden. Freuen würde es mich. Auch das MiNT mit Emu-TOS stabiler läuft könnte es für die Allgemeinheit attraktiver machen. Wobei ich wieder zurück zum eigentlichem Thema komme, optisch fand ich die Standard-Icons teilweise abstoßend... z.B. diese Floppys arrrg schrecklich... oder die Menu-Info im Desktop. Das wirkte wie hingekritzelt. Schön das endlich auch auf solchen Nebensächlichkeiten mehr geachtet wird. Danke für die Mühe.

[1ST1]

Für mich sind die Icons in der originalen deskicon.rsc für TOS 2.06 einfach Kult. Allerdings habe ich noch eine Reihe zusätzliche Icons dazu gemacht, z.B. einen VW-Käfer für den AUTO-Ordner. ein Netzwerksymbol und noch ein paar weitere.

[ari.tao]

Ganz abgesehen davon ist es ganz normal daß ein anderer desktop andere Konfigurationen hat. Du kannst ja auch nicht erwarten die GEMINI.INF mit Jinnee benutzen zu können oä.

Ich kann meine Icon-Resourcen ohne Änderung problemlos zugleich mit GEM-Desktop, MagxDesk, Jinnee, Thing, TeraDesk und Gemini nutzen. Nur die Ease macht da mit ihrem proprietären Format eine unrühmliche Ausnahme (kein Wunder, daß sie es nicht weit gebracht hat). Natürlich sind die Zuordnungs-Dateien da jeweils unterschiedlich - jedoch, das EmuDesk.INF ist derart stark an NewDesk.INF angelehnt, daß man zu Recht fragen muß, warum es dann nicht gleich ganz kompatibel ist. Btw. würde ich sonst aber eine ´modernere´ Behandlung der Zuordnung (ie. Identifizierung über die Icon-Namen anstatt über die Position in der .RSC) bevorzugen.

Was wäre denn mit einem separaten Konverter von Atari-TOS-Format nach EmuTOS-Format?

Wenn Du schon erwägst, einen Konverter zu schreiben, könnte es ja genausogut einer sein, um umgekehrt die bisherigen EmuDesk.INF in NewDesk.INF zu konvertieren (für die bisherigen Emu-Anwender).
Die in #27 skizzierten Angleichungen sind wohl nicht sehr aufwändig.

[czietz]

Ich halte eine Änderung der Formate in EmuTOS weiterhin nicht für wahrscheinlich. Der Konverter war ein Kompromissvorschlag -- ich hatte nicht gesagt, dass ich ihn schreiben würde. Da diese Idee aber offensichtlich nicht auf Zustimmung stößt (oder doch?), bleibt halt alles beim Alten.

Alternative: wenn jemandem im Open-Source-Software etwas nicht passt, kann dieser ja seinen eigenen Patch entwickeln und zur Diskussion stellen. 

[Thorsten Otto]

Ich kann meine Icon-Resourcen ohne Änderung problemlos zugleich mit GEM-Desktop, MagxDesk, Jinnee, Thing, TeraDesk und Gemini nutzen.

Daß die icons anders angeordnet sind, liegt vermutlich daran daß als Basis für EmuTOS die von DRI freigegebenen Sourcen verwendet wurden. Das sind nicht ganz die gleichen die später im TOS verwendet wurden, und insbesondere der Desktop ist natürlich komplett anders.

Btw. würde ich sonst aber eine ´modernere´ Behandlung der Zuordnung (ie. Identifizierung über die Icon-Namen anstatt über die Position in der .RSC) bevorzugen.

Das wäre vlt. sinnvoll, wäre aber dann widerum inkompatibel sowohl zu newdesk.inf als auch zu bisherigen versionen von emudesk.inf.

Wenn Du schon erwägst, einen Konverter zu schreiben, könnte es ja genausogut einer sein, um umgekehrt die bisherigen EmuDesk.INF in NewDesk.INF zu konvertieren (für die bisherigen Emu-Anwender).

Er hat denke ich nicht erwähnt daß er das erwägt, er wollte dir wohl eher vorschlagen sowas zu schreiben Wenn man so einen Konverter schreibt, wäre es vermutlich auch möglich das in beide Richtungen zu machen. Wobei sich mir der Sinn für EmuDesk->Newdesk nicht ganz erschliesst, es sollte ja eine Erleichterung sein auf EmuDesk umzusteigen, nicht umgekehrt.

Die in #27 skizzierten Angleichungen sind wohl nicht sehr aufwändig.

Und das schliesst du woraus? Ohne dir zu nahe treten zu wollen, aber ich denke nicht daß du das beurteilen kannst. Ganz abgesehen davon daß man (zumindest für eine gewisse Zeit) beide Formate unterstützen müsste, sonst würde man Benutzer zwingen bei einem Upgrade die alte emudesk.inf in die Tonne zu treten. In jedem Fall bedeutet das aber zusätzlicher Code, und der Platz in den 192k ROMs ist nunmal arg beschänkt.

[1ST1]

Wie wärs denn, wenn EmuDesk das Format automatisch erkennt und mit beiden Formaten umgehen kann, je nachdem was man ihm vorlegt? Es muss dann nur noch festgelegt werden, was passiert, wenn beide Dateien vorhanden sind, Vorschlag, zuerst die RSC von EmuDesk laden, dann die Newdesk.rsc hinzufügen. Dann hat man Icons satt.

[Thorsten Otto]

Wie wärs denn, wenn EmuDesk das Format automatisch erkennt und mit beiden Formaten umgehen kann, je nachdem was man ihm vorlegt?

Nochmal zur Klarstellung: ganz egal was man sich da überlegt, abgesehen vom Programmieraufwand, bedeutet das alles zusätzlichen Code, der in den 192k ROMs sehr knapp bemessen ist, und IMHO für wichtigere Sachen genutzt werden sollte. Ganz abgesehen davon daß man einer Resource-Datei nicht ansieht in welcher Reihenfolge die Icons da definiert wurden.

[ari.tao]

... Ganz abgesehen davon daß man einer Resource-Datei nicht ansieht in welcher Reihenfolge die Icons da definiert wurden.

Hä? Muß man doch nur mit Hilfe eines RCS´ anschauen. Ich empfehle InterFace.

Ohne dir zu nahe treten zu wollen, aber ich denke nicht daß du das beurteilen kannst.
 ...
und der Platz in den 192k ROMs ist nunmal arg beschänkt.

Glaube mir, ich kann das sehr gut beurteilen - mit 50-jähriger Erfahrung im Programmieren.
Wenn Atari tatsächlich von der DRI-Vorlage abgewichen ist, dann vermutlich, um Platz zu sparen (das wäre nämlich ein Nebeneffekt der og. Vorschläge).

... ich hatte nicht gesagt, dass ich ihn schreiben würde.

Und ich habe nicht gesagt, daß Du erwägst, daß Du selbst ihn schreibst.

Alternative: wenn jemandem im Open-Source-Software etwas nicht passt, kann dieser ja seinen eigenen Patch entwickeln und zur Diskussion stellen. 

Es ist ein Fehler, jedem Beitrag ein egoistisches Eigeninteresse zu unterstellen. Mir passen EmuDesk & seine Icons sehr gut: Ich brauche sie nicht.
Ich habe einen Beitrag zu EmuDesk geleistet, sine ira et studio, indem ich eine Inkompatibilität aufgezeigt habe - und wie man sie beseitigen kann. Macht daraus, was Ihr wollt.
Mein Interesse gilt derzeit Hatari. Dessen Macher haben sich einer größtmöglichen Kompatibilität zum orig. Atari verschrieben. Aus Sicht von Hatari wäre es imho sicher wünschenswert, wenn auch EmuTOS, Emudesk sowie dessen Icons größtmögliche Kompatibilität zum TOS aufwiesen. Aber auch Hatari braucht EmuTOS & Co. nicht, man kann ja ein orig. TOS.IMG benutzen.