atari-home.de - Foren
Software => Alternative Betriebssysteme => Thema gestartet von: czietz am Fr 14.07.2017, 18:57:41
-
Ein oft geäußerte Kritikpunkt an EmuTOS ist ja, dass es unansehnlich sei.
Nun hat ein talentierter Nutzer nicht kritisiert sondern stattdessen dazu beigetragen, EmuTOS hübscher zu machen, indem er komplett neue Icons, Cursor usw designt hat. Hier ein erster Blick auf einen Teil der kommenden Icons:
(http://forum.atari-home.de/index.php?action=dlattach;topic=13724.0;attach=14175;image)
Das ist noch "work in progress"; zur Zeit wird an den Mauscursorn gearbeitet, evtl. werden danach auch noch die Fensterelemente (Scrollleisten, Titelzeile, etc.) verändert.
-
Ich verfolge die Diskussionen in der Mailingliste immer und muß sagen im letzten halben Jahr wurde echt viel umgesetzt und EmuTOS wird immer eleganter. In manchen Sachen sogar schneller als Atari Tos aber es gibt auch ecken wo es langsamer ist. Ich möchte daher hier einmal ein Dank für die Tolle Arbeit die Ihr macht aussprechen.... macht bitte weiter so :)
-
Ein oft geäußerte Kritikpunkt an EmuTOS ist ja, dass es unansehnlich sei.
Nun hat ein talentierter Nutzer nicht kritisiert sondern stattdessen dazu beigetragen, EmuTOS hübscher zu machen, indem er komplett neue Icons, Cursor usw designt hat. Hier ein erster Blick auf einen Teil der kommenden Icons:
(http://forum.atari-home.de/index.php?action=dlattach;topic=13724.0;attach=14175;image)
Das sieht schonmal sehr gut aus!
zur Zeit wird an den Mauscursorn gearbeitet, evtl. werden danach auch noch die Fensterelemente (Scrollleisten, Titelzeile, etc.) verändert.
Hm. Ich hoffe nicht - je näher an (Atari-)GEM 1, desto (mir) lieber.
-
Ein oft geäußerte Kritikpunkt an EmuTOS ist ja, dass es unansehnlich sei.
Komisch ... aber ich fürchte, ich bin wohl ziemlich der einzige, der das EmuTOS-Design mochte bzw. mag. Ich hatte nie Probleme mit den Icons. Im Gegenteil, ich fand sie teilweise sogar besser die originalen Atari Icons.
Aber nichts gegen Vielfalt. Solange jeder das so nutzen kann wie sie/er möchte, ist doch alles in Butter.
Ich muss auch sagen, dass sich bei EmuTOS eine ganze Menge tut und das OS auf einem guten Wege ist, denke ich. Herzlichen Dank an alle Beteiligten für die geleisteten Dinge und für das, was noch kommen wird!
-
Es hieß doch, man könne Icons nachladen? Wie geht das?
Ich habe emuicon.rsc nach C:\ kopiert, aber nix rührt sich...
Mit dem üblichen Menue kommen nur die Defaults.
-
Es hieß doch, man könne Icons nachladen? Wie geht das?
Ich habe emuicon.rsc nach C:\ kopiert
Das ist richtig. Welche EmuTOS-Version?
-
EmuTOS 0.9.8
-
EmuTOS 0.9.8
OK, da sind nachladbare Icons verfügbar. Kannst Du es mit der angehängten Datei probieren? Das sind die neuen Icons aus meinem Screenshot. Wenn es damit funktioniert, muss es an Deiner emuicon.rsc liegen.
PS: Ich nehme an, C:\ ist auch tatsächlich Dein Bootlaufwerk.
-
Nein, geht auch nicht.
Jetzt ist aber etwas passiert, was mich noch mehr irritiert, siehe ScreenShot.
Die Partition G: ist eigentlich leer.
-
Upps, da ist ja noch mehr seltsam:
Der ScreenShot zeigt ein EMUICON+.URL anstatt des unter Windows sichtbaren EMUICON.RSC ...
Was ist da los?
-
Noch mal wiederholt, siehe Anhang.
-
Ein oft geäußerte Kritikpunkt an EmuTOS ist ja, dass es unansehnlich sei.
Komisch ... aber ich fürchte, ich bin wohl ziemlich der einzige, der das EmuTOS-Design mochte bzw. mag. Ich hatte nie Probleme mit den Icons. Im Gegenteil, ich fand sie teilweise sogar besser die originalen Atari Icons.
Die EmuTOS-Icons stammen aus dem PC-GEM 1.0*. Mit den neuen Icons bekommt EmuTOS ein Stück weit mehr eine eigene Identität, mir gefällt's.
* Im Premierenbuch von Data Becker kann man sehen, dass Beta-Versionen des Atari-GEM ebenfalls die Icons des PC-GEM nutzten.
-
Jetzt ist aber etwas passiert, was mich noch mehr irritiert, siehe ScreenShot.
Die Partition G: ist eigentlich leer.
Sorry, aber das hat sicherlich nix mit den Icons zu tun -- und passt damit nicht in den Thread. Zumal ich ich nicht mal weiß, wie Deine Platte partitioniert ist...
-
Schön! Dann bin ich mal auf das fertige Set gespannt. Wird das offiziell ins EmuTOS wandern, oder ist das auch nur ein USerpatch wie die "Busy Bee"-Edition?
-
Der neue Look soll Teil des offiziellen EmuTOS werden. Wenn es nach mir geht auch als Standard und nicht als optionales Extra, wobei es auf der Liste Befürchtungen gibt, dass das auch wieder nicht jedem gefällt.
-
[...] wobei es auf der Liste Befürchtungen gibt, dass das auch wieder nicht jedem gefällt.
Stimmt!
-
Bei Windows wurden die USer auch nicht gefragt, aber jeder hat den Defaultlook genommen, etwa bei XP :P
EmuTOS sollte von der Optik Eigenständigkeit und Modernität zeigen. GEM1 oder TOS 1.0 Look bieten beides nicht.
-
EmuTOS sollte von der Optik Eigenständigkeit und Modernität zeigen. GEM1 oder TOS 1.0 Look bieten beides nicht.
Dann sollte man aber diesen Ansatz auch konsequent verfolgen und auch sobald wie möglich ein Farbiconset nachreichen und integrieren.
Ansonsten habe ich auch nichts gegen die Qual der Wahl wie ich schon schrieb. ;)
-
Bei Windows wurden die USer auch nicht gefragt, aber jeder hat den Defaultlook genommen, etwa bei XP :P
EmuTOS sollte von der Optik Eigenständigkeit und Modernität zeigen. GEM1 oder TOS 1.0 Look bieten beides nicht.
Siehste, find ich nicht :-) So unterschiedlich sind die Geschmäcker. Es sollte IMHO so nah an GEM1/Atari sein wie möglich. Der Mauszeiger ist schief und dürr, derzeit, es ist der von PC-GEM …
Ist halt eine Frage der Ausrichtung - will EmuTOS ein moderner Abkömmling sein, der binärkompatibel zu TOS ist, sonst aber eigen? Dann sollte der Look moderat eigen sein (mit moderat meine ich, da jetzt keinen BeOS-Look einzubauen)
Oder soll es „einfach“ ein freies GEM1/TOS 1.x/2.x sein, mit ein paar kleinen Erweiterungen? Dann sollte der Look GEM1/Atari sein.
-
wobei es auf der Liste Befürchtungen gibt, dass das auch wieder nicht jedem gefällt.
Naja icons kann man schon seit der letzten version selber definieren, mit Maus-Cursorn wird das auch bis zur nächsten Version gehen, wem das also nicht gefällt kann jederzeit den bisherigen Look installieren (oder einen ganz anderen).
-
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.
-
Toll, das "neue" Design gefällt mir.
-
Wie ist denn der aktuelle Stand? Ich würde den Look gerne in eigenen EmuTOS Images reincompilieren.
-
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...
-
Mir reichen die RSC Files, die ich in den Sourcetree reinkopieren könnte. Bauen kann man selber. Nachladen kostet unnötig RAM.
-
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.
-
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!
-
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
-
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.
-
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.
-
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.
-
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?
-
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. >:D Schön das endlich auch auf solchen Nebensächlichkeiten mehr geachtet wird. Danke für die Mühe.
-
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.
-
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.
-
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. ;D
-
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.
-
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.
-
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.
-
... 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. ;D
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.
-
...Ich habe einen Beitrag zu EmuDesk geleistet, sine ira et studio, ...
Oder vielleicht eher sine gratia aut ambitione?
OpenSource ist eigentlich so zu verstehen, dass ambitionierte Programmierer ihre Leistung interessierten Anwendern (und nachfolgenden, ambitionierten Programmierern) kostenfrei zur Verfügung stellen.
Aus der Programmierersicht werden Vorschläge von interessierten Nutzern dann üblicherweise als Beitrag von Nicht-Programmierern verstanden.
Vorschläge von uninteressierten Nicht-Anwendern können allerdings auch leicht als Versuch interpretiert werden, lediglich über anderer Leute Freizeitnutzung bestimmen zu wollen...
-
Hä? Muß man doch nur mit Hilfe eines RCS´ anschauen.
Dann erklär mir mal wie man das in einem Programm wie EmuTOS machen soll ;)
Ich empfehle InterFace.
Hust. Hab da glaub ich ne bessere Alternative.
Glaube mir, ich kann das sehr gut beurteilen - mit 50-jähriger Erfahrung im Programmieren.
Damit wollte ich auch nur sagen daß du vermutlich die EmuTOS Sourcen nicht oder nicht besonders gut kennst, und dementsprechend nicht weiss was man da alles ändern müsste.
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).
Warum die dort abgewichen sind kann ich nicht sagen, aber sicher nicht um Platz zu sparen. Die Objekt-Strukturen, in die die Icons eingebettet sind, werden nämlich eigentlich gar nicht gebraucht.
Es ist ein Fehler, jedem Beitrag ein egoistisches Eigeninteresse zu unterstellen.
Wir unterstellen da gar nichts. Die Inkompatibiltät ist auch bekannt. Ist nur leider aus genannten Gründen zu spät/zu aufwendig/zu viel zusätzlicher code um das jetzt noch zu ändern.
Mir passen EmuDesk & seine Icons sehr gut: Ich brauche sie nicht.
Genau das sollte dieser Thread eigentlich herausfinden. Wenn da tatsächlich grosser Bedarf bestehen würde, würde man das vlt. nochmal überlegen. Ansonsten besteht immer noch die Möglichkeit das in einem externen Tool zu erledigen (das dann irgendein Freiwilliger natürlich erstmal schreiben müsste).
-
Für mich ist TOS TOS und EmuTOS EmuTOS ...
... die anderen RSC und INF Dateien empfinde ich als Vorteil wenn mal TOS oder EmuTOS boote.
-
Irgendwie gibt's immer Zoff. ??? Ich konnte sehr gut mit den originalen EmuTOS Icons leben. Ich fande die gut. Wenn's jezt neue gibt, soll mich das auch nicht stören. Was die Handhanbung der Icons in den unterschiedlichen TOS-Versionen und/oder Desktops angeht, davon habe ich eh keinen Schimmer. Das scheint auch nur ein Problem zu sein, wenn man sich selbst eine Icondatei stricken will oder eine verwenden möchte, die nicht für EmuTOS vorgesehen ist? Sicherlich wäre das schon wünschenswert, wenn alles miteinander kompatibel wäre, wenn's jetzt nicht so ist ... manchmal geht eben nicht alles.
Bislang habe ich EmuTOS nicht im regelmäßigen Einsatz. Dazu fehlt mir irgendwie die Hardware, Software bzw. die Notwendigkeit. Aber ich verfolge das Projekt schon sehr lange und finde es echt klasse, was in dieser Hinsicht schon alles geleistet wurde und welche Entwicklung EmuTOS vor allem in letzter Zeit gemacht hat. Das war meiner Meinung nach schon ein echter Sprung nach vorne. Insofern können alle Beteiligten erstmal stolz auf das sein, was geleistet wurde, finde ich.
-
Irgendwie gibt's immer Zoff.
Das ist doch kein Zoff. Zoff geht anders.
Das ist ganz normaler Austausch von Meinungen. Wird auch Diskussion genannt ;)
-
Ich glaube nicht, dass es codemäßig einen großen Aufwand darstellt, zwei Ressourcen-Bäume zu verfolgen, erst liest man den einen aus, bis alle Icons darin gefunden wurden, und dann schaut man, ob es einen zweiten Baum gibt und ließt den dann auch aus.
Aber wenn die ganzen Zusatzfunktionen, ich würde mir z.B. ein EmuTOS mit dem Desktop-Funktionsumfang von TOS 2.0x bis 4.0x wünschen, zu viel Platz in den ROMs beanspruchen, dann hätte ich einen Vorschlag: Im ROM eine Minimalversion, die nichtmal eine Icon-Datei einlesen kann, sondern gerade den Umfang von TOS 1.0x umfasst. Und - ich nehme hier mal NEWDESK.PRG als Vorbild - eine in den Auto-Ordner platzierbare AES/VDI/Desktop-Version mit vollem Funktionsumfang, die man einfach bei Bedarf lädt. So etwa kam meine STacy auch zum Look&Feel von TOS 2.06, braucht halt ein bischen RAM, aber 4 MB sind doch recht üppig, um sowas zu machen.
-
Vorschläge von uninteressierten Nicht-Anwendern können allerdings auch leicht als Versuch interpretiert werden, lediglich über anderer Leute Freizeitnutzung bestimmen zu wollen...
Wenn man einen Thread aufmacht, um Meinungen & Vorschläge einzusammeln, dann doch (hoffentlich!) nicht, um diese dann hinterher als Fremdbestimmung zu schmähen. Und gleich noch eine Bemerkung zur Diskussions-Kultur hinterher: Solch ein Argument (das hier im Forum in Varianten schon des öfteren aufgetaucht ist), nämlich
"Wenn jemandem ... etwas nicht passt, kann dieser ja seinen eigenen Patch entwickeln und zur Diskussion stellen."
ist schlechter Stil, denn es zielt an der Sache vorbei auf den Vortragenden und ist damit Gift für eine jegliche Sach-Diskussion. So argumentiert man, um eine Diskussion abzubrechen!
Aber dieser ganze Absatz ist eine Meta-Diskussion, und damit hier OT...
-------
Dann erklär mir mal wie man das in einem Programm wie EmuTOS machen soll ;)
Du hattest von einer Resource-Datei geschrieben. Aber auch für eine in einem Programm eingebettete Resource kann man durchaus die Reihenfolge ihrer Teile bestimmen - muß man bloß sehr genau die Resource-Strukturen kennen. Aber leichter geht´s so: Zur Einbettung von Resourcen in Prg.-Code gibt es Tools - damit ist das Problem wieder auf das einfachere der Resource-Dateien zurückgespielt. Ich habe mir mal ein eigenes Tool geschrieben, das sogar ´rückwärts´ ebenfalls funktioniert, also auch wieder aus einer im Code eingebetteten Resource eine .RSC-Datei machen kann.
Ich empfehle InterFace.
Hust. Hab da glaub ich ne bessere Alternative.
InterFace besitzt ein Alleinstellungsmerkmal, dh. eines, das afaik von keinem Konkurrenten beherrscht wird: Es kann nämlich auch Icons mit zwei oder drei Bitplanes editieren. Würde mich aber mal interessieren, warum Du Deine alte Native besser findest.
Die Inkompatibiltät ist auch bekannt.
Da ist schlicht unfair, wenn verkündet wird, man könne Icons per Datei nachladen, und dann diese Falle verschwiegen wird.
Genau das sollte dieser Thread eigentlich herausfinden. Wenn da tatsächlich grosser Bedarf bestehen würde, würde man das vlt. nochmal überlegen.
Das war/ist mir völlig klar. Eben deshalb schrieb ich: Macht daraus, was Ihr wollt.
Aber ich halte die Kompatibilität per se für wichtiger (ibs. in Hinblick auf Hatari).
-------
Hallo @Nervengift , was mfro hiermit
Irgendwie gibt's immer Zoff.
Das ist doch kein Zoff. Zoff geht anders.
Das ist ganz normaler Austausch von Meinungen. Wird auch Diskussion genannt ;)
meint, das ist:
Er kommt und gibt seine Meinung in der Garderobe ab. Und anschließend geht er mit meiner Meinung wieder nach Hause - und ich kann dann gucken, wo meine Meinung geblieben ist!
-
Aber auch für eine in einem Programm eingebettete Resource kann man durchaus die Reihenfolge ihrer Teile bestimmen - muß man bloß sehr genau die Resource-Strukturen kennen.
Das ist schon klar. Es geht ja nicht um die Struktur, es ist in jedem Fall eine Resource-Datei, damit ist die Struktur schon vorgegeben. Es geht darum, daß z.b. in TOS 3.06 das erste Icon für Floppy ist, während es in EmuTOS für Harddisk ist. Diese Zuordnung ist hard codiert (in beiden Fällen).
Aber leichter geht´s so: Zur Einbettung von Resourcen in Prg.-Code gibt es Tools
Das wird (im Falle von EmuTOS) bereits so gemacht. TOS arbeitet da anders, und bettet einfach die komplette Resource-Datei als Binär-Datei ins ROM ein.
InterFace besitzt ein Alleinstellungsmerkmal, dh. eines, das afaik von keinem Konkurrenten beherrscht wird: Es kann nämlich auch Icons mit zwei oder drei Bitplanes editieren.
ORCS kann das ebenfalls, und RSM glaube ich auch.
Würde mich aber mal interessieren, warum Du Deine alte Native besser findest.
Könnte daran liegen daß ich diese Alternative selber geschrieben hab... (http://tho-otto.de/download/orcs215.zip)
Da ist schlicht unfair, wenn verkündet wird, man könne Icons per Datei nachladen, und dann diese Falle verschwiegen wird.
Da ist was dran. Sollte wohl irgendwo einen Hinweis geben.
Aber ich halte die Kompatibilität per se für wichtiger (ibs. in Hinblick auf Hatari).
Die Schwierigkeit daran ist halt, daß diese Entscheidung vor langer Zeit getroffen wurde, und man jetzt nur schwerlich mit beidem (bisherigen EmuTOS Versionen und newdesk.inf) kompatibel sein kann.
-
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.
Das "später" ist - glaube ich - "historisch" nicht ganz richtig.
Die AES-Quellen von EmuTOS sind m.E. deutlich neuer als die von Atari verwendeten.
In den von DR/Caldera freigegebenen AES-Quellen (© 1987), die EmuTOS als AES "Ausgangsmaterial" verwendet, war (als Resultat des Apple-Rechtsstreits) der Desktop bereits auf die unbeweglichen zwei Fenster umgestrickt. Im Zuge der EmuTOS-Entwicklung wurde diese Veränderung wieder "rückgebaut".
Die Inkompatibilität hat uns also höchstwahrscheinlich DR eingebrockt, _nachdem_ der Atari-"Fork" abzweigte. Wär' schön, wenn's nicht so wär', aber das lässt sich jetzt nicht mehr ändern, ohne entweder die einen oder die anderen zu ärgern.
-
Das "später" ist - glaube ich - "historisch" nicht ganz richtig.
Da hast du vermutlich recht. Atari hat die Quellen deutlich früher bekommen, danach sind sie auf beiden Seiten in unterschiedliche Richtungen weiter entwickelt worden.
Die Inkompatibilität hat uns also höchstwahrscheinlich DR eingebrockt, _nachdem_ der Atari-"Fork" abzweigte.
Möglich, aber ich denke eher nicht. Atari hat den Aufbau auch in anderer Hinsicht geändert, die #a, #b, #c Zeilen zB sind ausschliesslich für XCONTROL gedacht und werden vom Desktop gar nicht ausgewertet, und sind zudem sehr Atari-spezifisch.
-
Ich habe auf einem meiner PCs eine GEM-Installation, die Kollege @ST-Oldie mal gebastelt hat. Darin kann man beim Start auswählen, welche GEM-Deskop-Version man haben will. Man hat die Wahl zwischen 1.2 und 3.0, dazu werden je nach Auswahl folgende Dateien in den c:\gemapps\gemsys Ordner kopiert:
DESKHI.ICN, DESKLO.ICN, DESKTOP.APP, DESKTOP.RSC, DESKTOP.INF
Alles andere bleibt gleich. Zwischen den beiden Versionen muss es also jenseits von desktop.app/rsc weitere Inkompatiblitäten geben, aber ob das die selben wie zwischen TOS und EMUTOS sind, vermag ich nicht zu sagen.
-
... daß z.b. in TOS 3.06 das erste Icon für Floppy ist, während es in EmuTOS für Harddisk ist ...
Daran ist gleich mehrerlei verkehrt. In allen mir bekannten TOS-Versionen, auch in 3.06 und sogar noch in der MülltiTOS-Icon-Resource, zeigt das erste Icon (also das mit der Nr. null), als Bild die Akten-Schublade, also weder eine Diskette (bei MTOS die Nr.9) oder ein Floppy-LW, noch eine HardDisk (bei MTOS die Nr.11, wie in 3.06 & 4.04 das letzte Icon (ebenfalls Nr.11) mit dem Bild einer MegaFile (leider! ein Fehler! das letzte sollte neutral sein, da TOS es für alle höheren Icon-Nrn. benutzt)). Das erste TOS-Icon steht also für ´Partition´. Die Namen der Icons (ie. die Bild-Unterschriften) spielen für TOS bzw. GemDesk bekannlich keine Rolle (iGgs. zu späteren DeskTöppen, zB. Thing oder Jinnee). Bei den MTOS-Icons wird das auch dadurch deutlich, daß Namen mehrfach vergeben wurden (zB. ´floppy disk´ oder ´folder´). Bei der Benennung hat Atari einfach geschlampt, wohl weil das für die Zuordnung in GemDesk nicht benutzt/gebraucht wurde.
Das Icon mit der Nr. null der neuen Serie für EmuTOS zeigt auch nicht allein eine HardDisk, sondern die Kombination aus MegaFile-HD zusammen mit einem Mega-ST. Auch in EmuTOS wird der Icon-Name offensichtlich nicht weiter verwendet. Nur in der alten, derzeit noch im EmuTOS eingebetteten Icon-Resource soll das Bild des ersten Icons offenbar eine HD darstellen - wird aber ebenfalls in der Bedeutung ´Partition´ vom EmuDesk benutzt. Sowohl was die metaphorische Bedeutung, also die Bild-Symbolik angeht, als auch bzgl. der Benennung haben sich also gleich mehrere Leute etwas vertan. Der EmuDesk macht übrigens bzgl. des letzten eingebetteten Icons (es ist das Prg.-Icon, also auch nicht neutral) den gleichen Fehler wie der GemDesk und verwendet es für alle fehlenden höheren Icon-Nrn.
ORCS kann das ebenfalls, und RSM glaube ich auch.
RSM_3.65d kann definitiv keine drei Bitplanes, und von ORCS hatte ich bisher nur die Version 1.0 von 1991. Herzlichen Dank für die neue Version 2.15 ! Allerdings, an InterFace bin ich gewöhnt... Was hast Du besser gemacht als InterFace?
Auch ich habe mal so etwas ähnliches wie ein RCS geschrieben, allerdings ein sehr exotisches Teil (auf Text-Basis!). Mein Motiv dazu war, alles das editieren zu können, was die Resource-Strukturen erlauben, aber die damals gängigen RCSs nicht berücksichtigten. Davon blieb dann das og. Einbettungs-Tool übrig.
Die Schwierigkeit daran ist halt, daß diese Entscheidung vor langer Zeit getroffen wurde, und man jetzt nur schwerlich mit beidem (bisherigen EmuTOS Versionen und newdesk.inf) kompatibel sein kann.
Daran ist wohl nix schwieríg oder schwerlich - sondern bloß eine gewisse Menge Arbeit. Wenn die aber niemand tun will, dann bleibt halt alles beim alten.
-
Daran ist gleich mehrerlei verkehrt. In allen mir bekannten TOS-Versionen, auch in 3.06 und sogar noch in der MülltiTOS-Icon-Resource, zeigt das erste Icon (also das mit der Nr. null), als Bild die Akten-Schublade
Äh, ja gut. da hab ich wohl nicht richtig geguckt, und mich vom icon text ins Boxhorn jagen lassen. Ist aber auch egal, was bleibt ist die Tatsache daß die Reihenfolge dort anders als in EmuTOS ist.
Die Namen der Icons (ie. die Bild-Unterschriften) spielen für TOS bzw. GemDesk bekannlich keine Rolle (iGgs. zu späteren DeskTöppen, zB. Thing oder Jinnee).
Das ist richtig, das gilt auch für EmuTOS. Ob eine Zuordnung über Namen sinnvoller ist, bleibt dahin gestellt, dazu müsste man erstmal festlegen welche Namen dort erwartet werden. Was dann widerum Schwierigkeiten gibt bei nicht-englischen Resourcen.
RSM_3.65d kann definitiv keine drei Bitplanes,
Meinst du wirklich 3 Bitplanes (also 8 Farben)? Was soll das für ein Format sein? Nein, das kann weder ORCS noch RSM. Interface allerdings auch nicht. Aber Farbicons mit 4, 16 oder 256 Farben können sie alle.
Allerdings, an InterFace bin ich gewöhnt...
Kann ich verstehen. Höre ich nur leider öfter, was nicht gerade motiviert. Soviel anders ist ORCS in der Bedienung nun auch nicht. Wenn sich die Leute das nicht mal anschauen, und man nur hört "danke für dein Programm, ich werde es aber nicht benutzen", muss man sich nicht wundern wenn die Entwicklung eingestellt wird.
Was hast Du besser gemacht als InterFace?
Das würde den Rahmen hier glaube ich sprengen ;)
Auch ich habe mal so etwas ähnliches wie ein RCS geschrieben, allerdings ein sehr exotisches Teil (auf Text-Basis!).
Ein wichtiges Kriterium für mich war ein WYSIWYG Feeling. Das gilt auch für die meisten gängigen Erweiterungen über Extended Objekt-Typen, wie zb. Radio- und Checkboxen. Und das ganze nicht nur beim Testen, sondern schon bei der normalen Darstellung.
Daran ist wohl nix schwieríg oder schwerlich - sondern bloß eine gewisse Menge Arbeit. Wenn die aber niemand tun will, dann bleibt halt alles beim alten.
Naja es gibt mehrere Gründe dafür. Die Entwickler-Resourcen sind halt beschränkt. Ausserdem funktioniert es so wie es jetzt ist, das im nachhinein zu ändern birgt immer die Gefahr daß man was übersieht, und dann plötzlich neue Fehler einbaut. Ganz abgesehen davon, daß man (zumindest für eine gewisse Zeit) am besten sowohl altes als auch neues Format unterstützen müsste, was für die 192k ROMs aufgrund des fehlenden Platzes so gut wie unmöglich ist.
-
... was bleibt ist die Tatsache daß die Reihenfolge dort anders als in EmuTOS ist.
Ja, ab dem zweiten Icon (= das mit der Nr. 01H).
Ob eine Zuordnung über Namen sinnvoller ist ... müßte man erstmal festlegen welche Namen dort erwartet werden.
Ja, ganz bestimmt! Das haben die Autoren von MagxDesk, Thing & Jinnee richtig erkannt! Und haben da eine Festlegung vorentschieden... (manchmal ebbes Denglisch). Die Zuordnung über Hexa-Nrn. a la GemDesk oder EmuDesk ist leider mit 256 Icons am Ende - was für 2-Farben-Resourcen von 64k auch reicht, aber für ColorIcons sind beide Grenzen störend. Ich habe bereits mehr als 500 Icons (das ist die Grenze für Thing_2.27 MagxDesk, leider) mit igs. fast 800k Platzbedarf.
Meinst du wirklich 3 Bitplanes (also 8 Farben)? Was soll das für ein Format sein?
Ja! Die Ease kann solche Icons erzeugen. Interface kann sie ´nur´ bearbeiten. Verwendet werden können sie afaik überall. Interessant sind sie, wenn man Platz sparen muß. Wahrscheinlich gehen auch fünf Bitplanes &c. - habe ich aber nicht mehr so genau in Erinnerung.
... was nicht gerade motiviert.
Wenn ich das richtig beobachtet habe, war InterFace für OM auch kein so gutes Geschäft. Und dann hat auch noch ein Holländer eine der letzten Versionen in´s Netz gestellt. Würde mich mal interessieren, wie es dazu kam... Mein Eindruck ist, daß InterFace oder auch Geneva tragische Beispiele dafür sind, wie sehr viel Fleiß durch falsches/fehlendes Management keinen Lohn einfuhr. Einzelkämpfer oder Kleingruppen, die alles selber machen wollen/müssen, haben da schlechte Karten, ibs. wenn die Konkurrenz eine Industrie ist.
Du mußt Dein ORCS als Dein ureigenstes (Kunst-) Werk ansehen, getreu dem Motto "Was niemand verlacht, ist nicht wert, daß man zum Weg es macht!" (LaoTse, TaoTeKing). Die Motivation darf nicht aus dem Beifall des Publikums kommen (außer für Popper)! Eine Rose ist eine Rose ist eine Rose... Sie blüht und schert sich nicht darum, ob einer sie schön findet oder gar nützlich.
PS: In einer arbeitsteiligen Welt muß es Leute geben, die genau hingucken - und andere, die daraus Konsequenzen ziehen. Ich selber habe leider die Gabe der Kassandra. Deren Ansichten waren bekanntlich nicht sehr beliebt...
Erratum: Nicht Thing, sondern MagxDesk hat eine Grenze bei 500 Icons (und weitere Grenzen bei 3x200 Zuordnungen). Thing_2.27 hat eine Grenze bei 1000 Zuweisungen. Mit Jinnee bin ich bisher noch nicht an eine Grenze gestoßen.
-
Höre ich nur leider öfter, was nicht gerade motiviert. Soviel anders ist ORCS in der Bedienung nun auch nicht. Wenn sich die Leute das nicht mal anschauen, und man nur hört "danke für dein Programm, ich werde es aber nicht benutzen", muss man sich nicht wundern wenn die Entwicklung eingestellt wird.
Ich finde aus rein ästhetischen Gründen, die schriftlich schwierig schnell zusammenzufassen sind, Interface zwar „schöner“, aber in der Praxis nutze ich es kaum (noch) in den letzten vielen Jahren. Ich wechsle zwischen RSM und ORCS, einfach weil sie moderner und in vielem heute „geschmeidiger“ sind, man also nicht sich den OBTYPE-Index oder wasweißich merken muss, sondern klicken kann. Und eine nette Vorschau hat. Das alleine ist Gold^WZeit wert.
-
Die Zuordnung über Hexa-Nrn. a la GemDesk oder EmuDesk ist leider mit 256 Icons am Ende
Die icons sind 32x32, für Daten&Maske alleine also schon 256b pro Icon. Dazu kommen noch mindestens die ICONBLK Strukturen. Da ist das Limit bei 64k Resourcen also wesentlich kleiner als 256.
was für 2-Farben-Resourcen von 64k auch reicht, aber für ColorIcons sind beide Grenzen störend.
Solange EmuTOS keine Farb-Icons kann, ist das aber relativ egal. Und auch für Farb-Icon-Resourcen gilt, daß der Standard-Teil 64k nicht überschreiten darf, es sei denn man nimmt das Interface Format mit entsprechend anderem Header. Das kann aber so gut wie kein AES direkt lesen, wenn überhaupt XaAES, aber auch da funktioniert das nicht so wie es soll. Und der Aufwand das zu unterstützen ist nicht unerheblich. Externe Desktops haben es da wesentlich einfacher, die können die Resource-Dateien zur Not selber laden (macht ORCS ja auch zb), aber EmuTOS nimmt logischerweise dazu die rsrc_load() Routine vom AES.
Ja! Die Ease kann solche Icons erzeugen. Interface kann sie ´nur´ bearbeiten. Verwendet werden können sie afaik überall.
Hm, macht für mich wenig Sinn. Die entsprechen ja keinem Bildschirm-Format, und müssten zur Darstellung erstmal konvertiert werden. Bleibt auch die Frage welche Palette dann genommen werden soll. Wenn du da Beispiele hast, kannst du mir die trotzdem mal zuschicken, vlt. schaue ich es mir mal an. Ich hab zwar Magic hier auch am laufen, aber keine EASE (wieso kann EASE die eigentlich erzeugen, ist doch nur der desktop??)
Und dann hat auch noch ein Holländer eine der letzten Versionen in´s Netz gestellt. Würde mich mal interessieren, wie es dazu kam...
Weiss zwar nicht ob das rechtlich so astrein ist, aber vermutlich hat er es als Abandonware betrachtet, ist ja seit 25 Jahren nix dran gemacht worden.
-
Die icons sind 32x32 ...
Icons müssen nicht 32x32 sein, das hat schon Gemini gezeigt, und sogar GemDesk kann damit grundsätzlich umgehen (wenn auch mit kleinen Problemen).
Solange EmuTOS keine Farb-Icons kann ...
Das wäre sicherlich dringend Abhilfe wünschenswert.
... 64k nicht überschreiten darf, es sei denn man nimmt das Interface Format mit entsprechend anderem Header. Das kann aber so gut wie kein AES direkt lesen ...
Doch doch, nicht nur die og. Desktöppe können das, sondern auch MTOS, NAES ...
Meine Icon-Resource für den GemDesk des MTOS ist ~270k groß (da waren die 256 200* Icons erreicht). Für 8p-Icons wird noch mehr Platz gebraucht (-> neue Icons 48x48 für die FireBee - wieviele davon passen in 64k? Und wieviel Platz braucht man für 1000 solche Icons? Wenn die auch ein ´sel.´-Bild haben und gleichzeitig auch noch solche für 1p und 4p? Und wenn sie gar noch animiert würden?). Allerdings, der Aufwand ist nicht unerheblich. Bis wir Filmchen im Icon abspielen könnten, ähnlich wie Windoof das jetzt macht, wäre es noch ein weiter Weg.
Die entsprechen ja keinem Bildschirm-Format, und müssten zur Darstellung erstmal konvertiert werden. Bleibt auch die Frage welche Palette dann genommen werden soll.
Geht mit den CopyRaster-Funktionen des VDI. Kein sehr großer Aufwand also. Palette einfach gekürzt durch 1p weniger. Beispiele im Anhang.
wieso kann EASE die eigentlich erzeugen, ist doch nur der desktop?
Die Ease besitzt einen (sehr rudimentären) eigenen Icon-Editor.
Weiss zwar nicht ob das rechtlich so astrein ist, aber vermutlich hat er es als Abandonware betrachtet, ist ja seit 25 Jahren nix dran gemacht worden.
Nein, das geschah schon, während OM noch daran gearbeitet hat. Ich weiß nicht so recht, ob das gegen oder mit seinem Willen geschah (wie von dem Holländer behauptet). Sehr seltsam das, damals!
Erratum:
* Die 270k ColorIcon-Resource hat nicht 256 Icons, sondern nur 200 - gerade genau so viele, wie die entsprechende 64k große für 1p-Icons.
-
Icons müssen nicht 32x32 sein, das hat schon Gemini gezeigt
Grundsätzlich natürlich nicht, allerdings erwartet EmuTOS der Einfachheit halber zZ. daß sie alle gleich groß sind. Würde im Fenster auch seltsam aussehen wenn das nicht der Fall ist.
Doch doch, nicht nur die og. Desktöppe können das, sondern auch MTOS, NAES ...
NAES habe ich nicht deswegen kann ich dazu nichts sagen. Aber MTOS kann das definitiv nicht. Nochmal zur Klarstellung: natürlich können Resource-Dateien mit Color-Icons > 64K sein. Aber solche Dateien bestehen aus einer Standard-Resource Datei, mit angehängten Color-Icon Daten. Der Standard-Teil kann *nicht* grösser als 64k sein, weil der Header nur 16-bit Offsets hat.
Meine Icon-Resource für den GemDesk des MTOS ist ~270k groß (da waren die 256 Icons erreicht).
s.o. Die Dateigröße ist ziemlich unerheblich.
Bis wir Filmchen im Icon abspielen könnten, ähnlich wie Windoof das jetzt macht, wäre es noch ein weiter Weg.
Abgesehen davon daß ich solche icons nie benutzen würde (mich nervt so ein ständiges geflicker), würde den meisten Rechnern auch die nötige Power dafür fehlen.
Geht mit den CopyRaster-Funktionen des VDI. Kein sehr großer Aufwand also. Palette einfach gekürzt durch 1p weniger.
Ganz so einfach kann es eigentlich nicht sein. Pixel-Werte und VDI Farben sind zwei paar Schuhe. Solch ein Icon hat nur Pixelwerte von 0-7. Welcher davon soll zb. schwarz sein, wenn man es in 16 Farben darstellt, wo schwarz normalerweise einen Wert von 15 hat?
Beispiele im Anhang.
Danke, Schaue ich mir mal an.
-
... erwartet EmuTOS ... daß sie alle gleich groß sind ...
GemDesk (und auch MagxDesk?) erwartet iirc nur, daß sie alle gleich hoch sind, sonst ´tanzen´ sie.
Aber MTOS kann das definitiv nicht.
Ich hatte Dir doch gerade geschildert, daß bei mir MTOS mit einer 270k großen Color-Icon-Resource läuft, die mit InterFace erstellt wurde. Nicht mehr (aber auch nicht weniger) habe ich berichtet. Einen ScreenShot davon findest Du in der Gallery.
... daß ich solche icons nie benutzen würde (mich nervt so ein ständiges geflicker) ...
Da bin ich völlig dacour mit Dir, deshalb benutze ich auch die ´Kachel´-Oberfläche von Windoof_8 nicht.
PS: Erratum in #56 korrigiert.
-
Schaue ich mir mal an.
Ist jetzt auch in ORCS eingebaut. Darstellung funktionierte sogar schon, aber solche Icons können jetzt auch bearbeitet und erzeugt werden. War doch einfacher als ich dachte, eigentlich fehlten da hauptsächlich die entsprechenden Buttons in den Dialogen.
Neue Version (http://tho-otto.de/download/orcs216.zip) ist auch bereits verfügbar.
-
Freut mich, daß das so einfach war! 8)
Damit hat ja wohl InterFace sein Alleinstellungsmerkmal verloren... ;D
Tipp: Du solltest für ORCS mal ´nen eigenen Thread aufmachen...
Sicherlich könnte Dir auch @gh-baden noch so manche Verbesserung vorschlagen.
-
Zurück zum Thema:
Der neue Icon-Satz kann durchaus noch verbessert werden, zB. eingefärbt.
Vorschlag -> Anhang.
-
^^-- Sorry, wenn die Anhänge mißverständlich waren:
Das Bild wurde mit einer anderen, größeren .RSC gemacht, nicht mit ownicon.rsc. Letztere enthält nur genauso viele Icons (und in der gleichen Reihenfolge!) wie die .RSC aus #7 !
Die größere .RSC kann/darf ich hier nicht anhängen, sonst staucht (http://forum.atari-home.de/index.php?topic=13238.msg212450#msg212450) mich J. wieder zusammen... ownicon.rsc enthält nur Icons, die imho unzweifelhaft sind (aber das waren alle anderen _imho_ auch...).
Ich hatte bereits in #51 darauf hingewiesen, daß das letzte der in EmuTOS eingebetteten Icons, also Nr. 07H, das Prg.-Symbol zeigt; lt. Doku emudesk.txt sollte Nr. 7 aber für ´generic document´ stehen und nicht für ´generic application´. Da hat offensichtlich jmd. vergessen, die in der .RSC sichtbare Reihenfolge der logischen Reihenfolge anzupassen (oder umgekehrt). Dieser kleine Bug ist nun auch noch im neuen EmuTOS 0.9.9 vorhanden.
Ich plädiere noch einmal dafür, Reihenfolge & Bedeutung der ersten acht Icons an TOS anzupassen. Allerdings, das letzte eingebettete Icon sollte auch nicht für ´Dokument´ stehen, sondern für noch was allgemeineres, denn es könnte auch für einen Folder oder sonstwas eingesetzt werden, wenn diesem im .INF ein Icon mit einer höheren Nr. zugeordnet wurde.
-
Ich hatte bereits in #51 darauf hingewiesen, daß das letzte der in EmuTOS eingebetteten Icons, also Nr. 07H, das Prg.-Symbol zeigt; lt. Doku emudesk.txt sollte Nr. 7 aber für ´generic document´ stehen und nicht für ´generic application´.
Ich denke da verwechselst du was. in Emudesk.txt ist die Nummerierung 0-7 (weil diese Nummern auch in die emudesk.inf geschrieben werden). In der Resource sind die entsprechenden Objekt-Nummern aber 1-8. Die Reihenfolge ist aber soweit ich sehen kann richtig beschrieben.
Ich plädiere noch einmal dafür, Reihenfolge & Bedeutung der ersten acht Icons an TOS anzupassen.
Im original TOS (zumindest in 2.x und 3.x) sind allerdings 12 Icons definiert. Eins davon für Cartridge (für das Pseudo-Drive "c" wenn ein Filesystem im Cartridge ist, was von EmuDesk nicht unterstützt wird), eins für Laserprinter, eins für "New Program" (was immer das sein soll), und ein alternatives Icon für Hardisk.
-
^^-- Am besten schaust Du mal bzgl. der ersten 12 Icons die Icon-Resource von MTOS an (& siehst dann auch, was von zB. TOS_2.06 abweicht) und vergleichst mit den Icon-Sätzen, die bei MagxDesk, Thing & Jinnee mitgeliefert wurden.
Bzgl. der Namenswahl hatten wir ja schon festgestellt, daß sie in EmuDesk ebenso wie in GemDesk irrelevant ist, man da also frei walten kann - und sich dann vielleicht besser an die modernen D-Töppe anpaßt, wo das nicht mehr so ist.
(NB: Der Laser-Prn. ist vielleicht entbehrlich, aber ein Device-Icon sollte sein).
Ich selber habe für die ersten Icons folgende Namenswahl getroffen:
FILESYS, FOLDER, TRASH, APPL, FILE, PRINTER, DEVICE, CD-ROM,
RAM/ROM, FLOPPY, DATA, DRIVE, NET, FONTS, DRAFTS, ICONS,
EVIL, EDITOR, ACC, RSC, INFO, INX, TEXT, BATCH, ...
Unverzichtbar sind imho auch PARENT (für ´..´) & ALIAS (für verwaisten Link).
An letzter Stelle sollte in der eingebetteten RSC aber LAST stehen (und in einer nachgeladenen .RSC auch an letzter Stelle!).
Ich hatte bereits in #51 darauf hingewiesen, daß das letzte der in EmuTOS eingebetteten Icons, also Nr. 07H, das Prg.-Symbol zeigt; lt. Doku emudesk.txt sollte Nr. 7 aber für ´generic document´ stehen und nicht für ´generic application´.
Ich denke da verwechselst du was. in Emudesk.txt ist die Nummerierung 0-7 (weil diese Nummern auch in die emudesk.inf geschrieben werden). In der Resource sind die entsprechenden Objekt-Nummern aber 1-8. Die Reihenfolge ist aber soweit ich sehen kann richtig beschrieben.
Seufz. In Emutos.INF wird von 00H bis 07H gezählt! Vielleicht verwendet ja EmuTOS das vorletzte Icon für die höheren Nummern? >:D
Du kannst sehr einfach nachprüfen, welches Icon zB. für Nr. 13H verwendet wird, wenn keine externe EmuIcon.RSC vorhanden ist.
PS: Es muß mal eine Version von EmuTOS gegeben haben, deren Icon-Resource zu TOS besser kompatibel war, ie. mit nur einem Baum, -> #40 in
http://forum.atari-home.de/index.php?topic=13238.40
Edit.:
PS2: Elegant hat MagxDesk das Problem mit der Default-Icon-Auswahl gelöst. Man schaue sich das in dessen APPLICAT.APP an! Die Namen der dort eingebetteten ersten acht Icons:
DISK, ORDNER, PROGRAMM, DATEI, STAPEL, TONNE, GERAET, ALIAS
Dahinter folgen dann die externen, also zB. wie oben FILESYS, FOLDER, ...
Edit.: Oh pardon, das war ja meine gepätschte applicat.rsc da in PS2. Im Original:
DISK, ORDNER, PROGRAMM, DATEI, BATCHDATEI, PAPIERKORB,
DRUCKER, ELTER
Narürlich hatte ich meine guten Gründe für die Änderung...