[NMZ] Ein neues Gewand für EmuTOS

[mfro]

...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...

[Thorsten Otto]

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).

[Lukas Frank]

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.

[Nervengift]

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.

[mfro]

Irgendwie gibt's immer Zoff.

Das ist doch kein Zoff. Zoff geht anders.

Das ist ganz normaler Austausch von Meinungen. Wird auch Diskussion genannt

[1ST1]

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.

[ari.tao]

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!

[Thorsten Otto]

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...

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.

[mfro]

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.

[Thorsten Otto]

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.

[1ST1]

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.

[ari.tao]

... 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.

[Thorsten Otto]

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.

[ari.tao]

... 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.

[goetz @ 3rz]

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.

[Thorsten Otto]

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.

[ari.tao]

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.

[Thorsten Otto]

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.

[ari.tao]

... 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.

[Thorsten Otto]

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 ist auch bereits verfügbar.