EmuTOS 1.1 erschienen

[MJaap]

Das Entwicklerteam scheint ja eher klein gewesen zu sein:
https://dadhacker-125488.ingress-alpha.easywp.com/the-atari-st-part-2/

Halte ich für nicht stichhaltig. Thomas hat Texel 1.0 in … 18? Monaten geschrieben. Alleine. Und vor allem: nebenher. Selbst wenn das TOS-Team nur aus 1 Vollzeit-Person bestand, dann sind in 4 Jahren nur Blitter, ein paar Fixes, und fsel_exinput weiter ziemlich mager.

...und größere Änderungen hätten TOS mit Sicherheit wieder über die 192KB Grenze geschoben, die mit ROM-TOS unterschritten wurde. Mich würde interessieren, was Atari zum Umdenken verleitete.

Naja, 1987++ waren 64 KB mehr EPROM nicht mehr wirklich teuer. Sieht man ja auch am 1040STE von 1989, wo dann 256 KB drin waren.

Ja, aber Thomas hat das auf eigene Rechnung geschrieben und nicht für einen Arbeitgeber, der vielleicht ganz andere Vorstellungen hat, wo die Entwicklerressourcen besser aufgehoben sind. Ein reines "TOS-Team" hat es so wohl nie gegeben.

64KB mehr ROM waren vielleicht ab 1987 nicht mehr viel teurer, aber vielleicht zu teuer für die Geschäftsleitung. Vorher hätte auch entschieden werden müssen, den Desktop zu verbessern, oder ein paar Funktionen beim Mac abzukupfern. Offenbar keine Priorität.

Übrigens haben die letzten Snapshots von EmuTOS nun auch 3D-Look

[goetz @ 3rz]

Übrigens haben die letzten Snapshots von EmuTOS nun auch 3D-Look

… hoffentlich optional. Ich mag den original Atari-GEM-2D-Look, und verwende EmuTOS außer zum testen erst, seitdem dort Atari-GEM-gleichende Mauszeiger und Icons Einzug gehalten haben. Der Atari TOS4-3D-Look war mir eigentlich immer zu klobig. MagiC machte es später etwas „feiner“, das ging dann einigermaßen.

[czietz]

Übrigens haben die letzten Snapshots von EmuTOS nun auch 3D-Look

… hoffentlich optional. Ich mag den original Atari-GEM-2D-Look

Probiere es aus. In allen aktuellen Snapshots außer den 192k ROMs ist 3D aktiv: https://sourceforge.net/projects/emutos/files/snapshots/. Jetzt ist der richtige Moment (auch als User) Feedback zu geben, gerne auch direkt auf der Mailingliste: https://sourceforge.net/p/emutos/mailman/emutos-devel/

Blöd finde ich hingegen, wenn in einem erst im Release-Thread (wie zuletzt zu Version 1.1) alles "um die Ohren gehauen" wird, was persönlich an EmuTOS nicht gefällt.

[Thorsten Otto]

… hoffentlich optional.

Bin mir jetzt nicht sicher ob es ein CPX dafür gibt, aber man kann es über objc_sysvar() einstellen (und dementsprechend auch weitgehend abstellen). Was allerdings bleibt ist daß dann Buttons etwas grösser als sonst dargestellt werden.

PS.: eine Vorschau gibt es auf http://tho-otto.de/rscview/de/index.php?aes3d=1

[MJaap]

MagiC machte es später etwas „feiner“, das ging dann einigermaßen.

Den von MagiC mochte ich gerne. Ganz schlimm ist der von Geneva, der zum Teil sehr protzig aussieht.

Vielleicht kann man ja den 3D-Support zum Online-Build-Tool hinzufügen.

Ich hatte gestern in "meinem" Build die unterstrichenen Dialogtitel von MagiC hinzugefügt. Die finde ich optisch ansprechender als zentrierte Titel in Großbuchstaben.

[Thorsten Otto]

Vielleicht kann man ja den 3D-Support zum Online-Build-Tool hinzufügen.

Ja, kann man

BTW, die  scripts die dafür zuständig sind, sind natürlich auch verfügbar: https://github.com/th-otto/rscview/tree/master/emutos

Wenn sich jemand daran versuchen will: ist im wesentlichen Fleiss-Arbeit, die restlichen config-Optionen dort hinzuzufügen, und dürfte mit copy/paste auch ohne grosse PHP-Kenntnisse machbar sein.


PS.: das script macht keinerlei Überprüfung ob die ausgewählten Optionen zusammen passen. Nicht alle Kombinationen sind möglich, manche Einstellungen setzen andere voraus etc. Das kann dann auch dazu führen daß sich EmuTOS gar nicht übersetzen lässt. Im Zweifelsfall sollte man solche Einstellungen erstmal mit einer Release-Version überprüfen, das geht wesentlich schneller (für eine snapshot-Version muss immer erstmal das EmuTOS-Repository geclont werden).

[MJaap]

Mit vier Zeilen Code zu Nicelines in Menüs. Vorher/Nachher-Vergleich.

Inspiriert von diesem Artikel:
https://stcarchiv.de/stc1992/03/menutune

Aber eben direkt im Betriebssystem

[goetz @ 3rz]

Mit vier Zeilen Code zu Nicelines in Menüs. Vorher/Nachher-Vergleich.

Inspiriert von diesem Artikel:
https://stcarchiv.de/stc1992/03/menutune

Aber eben direkt im Betriebssystem

Mui bien! Sehr gut. Viel besser als "Pseudo-Grafik" mit Minuszeichen.

[MJaap]

Mui bien! Sehr gut. Viel besser als "Pseudo-Grafik" mit Minuszeichen.

Ich hab's mal vorgeschlagen, vielleicht schaffen es die Nicelines in EmuTOS 1.2. Verglichen mit den Verrenkungen für so einen 3D-Dialog/Button-Look super-simpel 

[tuxie]

Wie würde das ganze den aussehen wenn man Unterlinien  nimmt ? die sollten so Breit sein das sie durchgängig sind.   _______________________ wie das.

Die frage ist natürlich ob das geht!

[MJaap]

Wie würde das ganze den aussehen wenn man Unterlinien  nimmt ? die sollten so Breit sein das sie durchgängig sind.   _______________________ wie das.

Die frage ist natürlich ob das geht!

Naja, im Prinzip sind die Menüeinträge ganz normale String-Objekte, die nur eben disabled sind. Du könntest da auch andere Zeichen verwenden (manche Anwendungen tun das auch  ) Das Problem beim Unterstrich ist eben, dass du nach oben dann so einen Riesenabstand hast. Eventuell ist der Unterstrich noch nicht mal durchgängig, je nach Font.

Ich hatte am Anfang meine Niceline falsch platziert, also quasi einen Unterstrich erzeugt. Die Menüs sahen durchlöchert und chaotisch aus.

[Thorsten Otto]

Die frage ist natürlich ob das geht!

Natürlich geht das, dazu musst du nur mal im RSC-Editor die "-" durch "_" ersetzen. Aber das ganze sieht ziemlich besch* aus, siehe unten. Erstens sind die nicht durchgängig, und zweitens ist der Strich dann halt auch nicht mehr in der Mitte.

BTW: die meisten Libraries benutzen keine gepunktete Linie, sonder eine durchgehende graue, wenn 16 Farben oder mehr verfügbar sind. Sieht auch meiner Meinung nach besser aus.

[MJaap]

BTW: die meisten Libraries benutzen keine gepunktete Linie, sonder eine durchgehende graue, wenn 16 Farben oder mehr verfügbar sind. Sieht auch meiner Meinung nach besser aus.

Das ist tatsächlich keine Absicht - hatte übersehen, dass EmuTOS später nochmal mit einem Muster über den Bereich zeichnet, da der State Disabled bleibt.

[Nervengift]

Bin ich der einzige, dem der 3D Look des Falcon TOS oder des Milan TOS gefällt? War 3D in TOS 4.x nicht auch abschaltbar?

[MJaap]

Bin ich der einzige, dem der 3D Look des Falcon TOS oder des Milan TOS gefällt? War 3D in TOS 4.x nicht auch abschaltbar?

Ich mochte den 3D-Look erst, aber wenn viele 3D-Buttons in einem Dialog sind und der auch noch in der niedrigen Auflösung auf den Bildschirm passen soll, wirkt er sehr wuchtig - gerade im Vergleich zu MagiC. Zumindest in MagiC ist der 3D-Look leicht abschaltbar.

Nach der Enttäuschung mit dem STE und dessen TOS 1.06 fand ich den Falcon mit TOS 4.0 aber super.

BTW: die meisten Libraries benutzen keine gepunktete Linie, sonder eine durchgehende graue, wenn 16 Farben oder mehr verfügbar sind. Sieht auch meiner Meinung nach besser aus.

Ist jetzt durchgezogen - für den Preis einer weiteren IF-Abfrage. Der Code würde momentan aber aus jedem disabled String der mit "-" anfängt eine Linie machen.

[Thorsten Otto]

Der Code würde momentan aber aus jedem disabled String der mit "-" anfängt eine Linie machen.

Müsste man sich nochmal anschauen. MIMRE, gab es durchaus Programme, die zwar einen "-" am Anfang, dann aber weiteren Text in den Strings hatten. In ORCS hatte ich jedenfalls extra mal 'ne Abfrage eingebaut daß wirklich der komplette String aus "-" besteht.

[goetz @ 3rz]

Bin ich der einzige, dem der 3D Look des Falcon TOS oder des Milan TOS gefällt?

Das wird sicher spätestens mit der zweiten Person, die sich meldet, zu widerlegen sein. :-)

Aber ich mag den Look nicht. Er ist von Atari inkonsistent designed worden an verschiedenen Ecken (nicht alle Elemente sind gleich „erhaben“ bspw.), sehr klobig/dick, und v.a. mit dem üblichen Zeichenraster, das GEM bei aller Grafikaffinität in der Praxis beim Gestalten von AES-Dialogen immer noch hat, schwierig umzusetzen, weil dann Abstände zwischen UI-Elementen nicht mehr passen, da die Elemente zu dick ausfallen.

Ist ähnlich der Farb-Icons die mit dem Falcon kamen. Juhu! Farbe! Booh, ein Farbeimer ausgeschüttet … hauptsache alles wurde bunt, aber ein Konzept war da nicht erkennbar.

Wenn man sich dagegen mal die Icons des frühen BeOS anschaut als Gegenbeispiel: so bekommt man eine Linie rein.

[goetz @ 3rz]

Müsste man sich nochmal anschauen. MIMRE, gab es durchaus Programme, die zwar einen "-" am Anfang, dann aber weiteren Text in den Strings hatten. In ORCS hatte ich jedenfalls extra mal 'ne Abfrage eingebaut daß wirklich der komplette String aus "-" besteht.

Ich muss aus der Erinnerung sagen, dass ich meine, damals RSC-Files in der Hand gehabt zu haben, wo der Menütrenner aus nur drei "-" bestand und dann expandiert wurde. Aber welches Programm das war, da muss ich passen.

[MJaap]

Hier die überarbeiteten Nicelines und die Groupboxes (MagiC kompatibel). Ich habe keine Ahnung, wie "schwer" die einzelnen Ergänzungen sind, also wie viel Bytes sie im ROM beanspruchen würden. Derzeit kompiliere ich immer die 512KB-Version, da gibt es noch für ganz andere Sachen Platz :-D

Die Groupboxes mochte ich vom Aussehen, allerdings gehörten die zu den MagiC-Ergänzungen, die nur dann gut aussehen, wenn das OS dieses Feature kennt.

[Thorsten Otto]

wo der Menütrenner aus nur drei "-" bestand und dann expandiert wurde. Aber welches Programm das war, da muss ich passen.

Das wäre nicht so sehr das Problem. Die drei "-" sind wahrscheinlich nur dafür gedacht um ein paar bytes zu sparen.

Was ich meine sind Einträge wie "--- hier abschneiden ---" (wobei ich jetzt auch nicht mehr weiss  welches Programm das war). Wenn man die durch Nicelines ersetzt, ist der Text futsch.