Software > Alternative Betriebssysteme

[NMZ] Ein neues Gewand für EmuTOS

<< < (10/13) > >>

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:

--- Zitat von: mfro am Fr 08.12.2017, 15:46:46 ---Vorschläge von uninteressierten Nicht-Anwendern können allerdings auch leicht als Versuch interpretiert werden, lediglich über anderer Leute Freizeitnutzung bestimmen zu wollen...
--- Ende Zitat ---
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...

-------


--- Zitat von: Thorsten Otto am Fr 08.12.2017, 15:50:25 ---Dann erklär mir mal wie man das in einem Programm wie EmuTOS machen soll ;)
--- Ende Zitat ---
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.


--- Zitat von: Thorsten Otto am Fr 08.12.2017, 15:50:25 ---
--- Zitat ---Ich empfehle InterFace.
--- Ende Zitat ---
Hust. Hab da glaub ich ne bessere Alternative.
--- Ende Zitat ---
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.


--- Zitat von: Thorsten Otto am Fr 08.12.2017, 15:50:25 ---Die Inkompatibiltät ist auch bekannt.
--- Ende Zitat ---
Da ist schlicht unfair, wenn verkündet wird, man könne Icons per Datei nachladen, und dann diese Falle verschwiegen wird.


--- Zitat von: Thorsten Otto am Fr 08.12.2017, 15:50:25 ---Genau das sollte dieser Thread eigentlich herausfinden. Wenn da tatsächlich grosser Bedarf bestehen würde, würde man das vlt. nochmal überlegen.
--- Ende Zitat ---
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

--- Zitat von: mfro am Fr 08.12.2017, 17:26:56 ---
--- Zitat von: Nervengift am Fr 08.12.2017, 16:50:00 ---Irgendwie gibt's immer Zoff.
--- Ende Zitat ---
Das ist doch kein Zoff. Zoff geht anders.
Das ist ganz normaler Austausch von Meinungen. Wird auch Diskussion genannt ;)
--- Ende Zitat ---
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:

--- Zitat von: ari.tao am Sa 09.12.2017, 03:04:30 ---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.

--- Ende Zitat ---

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


--- Zitat ---Aber leichter geht´s so: Zur Einbettung von Resourcen in Prg.-Code gibt es Tools
--- Ende Zitat ---

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.


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

ORCS kann das ebenfalls, und RSM glaube ich auch.


--- Zitat ---Würde mich aber mal interessieren, warum Du Deine alte Native besser findest.
--- Ende Zitat ---

Könnte daran liegen daß ich diese Alternative selber geschrieben hab...


--- Zitat ---Da ist schlicht unfair, wenn verkündet wird, man könne Icons per Datei nachladen, und dann diese Falle verschwiegen wird.
--- Ende Zitat ---

Da ist was dran. Sollte wohl irgendwo einen Hinweis geben.


--- Zitat ---Aber ich halte die Kompatibilität per se für wichtiger (ibs. in Hinblick auf Hatari).
--- Ende Zitat ---

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:

--- Zitat von: Thorsten Otto am Fr 08.12.2017, 09:05:15 ---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.

--- Ende Zitat ---

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:

--- Zitat von: mfro am Sa 09.12.2017, 15:45:00 ---Das "später" ist - glaube ich - "historisch" nicht ganz richtig.
--- Ende Zitat ---

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.


--- Zitat ---Die Inkompatibilität hat uns also höchstwahrscheinlich DR eingebrockt, _nachdem_ der Atari-"Fork" abzweigte.
--- Ende Zitat ---

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.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete