Deskicon.rsc gesucht

[Thorsten Otto]

Aha, auch Du hattest also schon die Idee, daß der File länger sein könnte als die Resource

Ja, weil ORCS da sehr viel mehr Prüfungen macht als irgend AES wenn es die Datei läd. Könnte ja sein daß irgendwelche Erweiterungen verwendet wurden die ORCS noch nicht kennt. Ausserdem werden die Daten für die Palette nicht nur einfach an die Datei angehängt, sondern es wird ein neuer Eintrag in das Extension Array gemacht, und auch die Gesamtlänge wird entsprechend angepasst.

Dann nenne doch mal die anderen anstatt FarbIcons und Paletten.

Keine die mir bekannt wären.

[Atariosimus]

Eine Sicherheitskopie habe ich gemacht.

Problem ist halt nur, wenn verschiedene Programme aus dem Bootx direkt angesprungen werden sollen, dann ändert Bootx das jeweils entsprechend nach Sprung in Newdesk.inf ab.

Da steckt der Wurm. Ein Schreibschutz läßt diesen Komfort allerdings nicht mehr zu.

[1ST1]

Mit XBoot macht man das ja auch ganz anders... Man legt sich einen Ordner an, z.b. c:\auto\newdesk (eine andere schöne Variante wäre c:\gemsys\newdesk) und da legt man sich die verschiedenen newdesk.inf Dateien mit sinnvollen Namen (stlow.inf, stmed.inf, sthigh.inf, ttvga.inf, tthigh,inf, scrblstr.inf, network.inf, ...) Die Dateien werden nicht von Xboot bearbeitet, sondern nur kopiert. Man muss sich nur angewöhnen, wenn man tatsächlich mal was an der newdesk.inf was ändert (arbeit sichern), dass man die dann wieder in dem Ordner unter dem Namen kopiert, wie man das in Xboot eingestellt hat. Da,mit hat man dann auch seine Sicherheitskopie.

[Atariosimus]

^^--Wenn Du mit einem Text-Editor die NewDesk.?NF veränderst, dann mußt Du Dich hochnotpeinlich genau an das Format halten, da gibt´s nur wenig Spielraum. Ibs. die Trailing Blanks müssen erhalten bleiben, ganz besonders für #c ! Steht ja alles in meinem Leo. Kann durchaus sein, daß Dein BootSelektor da noch empfindlicher ist als das TOS. Ich bin kein Freund von BootSelektoren, weil sie gleich zu Anfang Schreibzugriffe machen. Das kann mitunter fatal enden!

-------

Interface RCS:
   http://www.atari-home.de/2000/12/interface-23-gfa-interpreter-35-zum-download/
Leider hält GH alias Hadley das Teil inzwischen nicht mehr bereit auf seiner HomePage.
Vielleicht ist es noch in der belgischen

Da ist leider nichts mehr zu holen. Das Programm habe ich allerdings zum Glück damals gekauft.

[ari.tao]

... NEWDESK.INF ... Schreibschutz ...

Schon das Umbenennen ist ein Schreib-Vorgang! Ein Ausweg wären Links auf u: - aber die gibt´s ja erst, wenn das OS Links überhaupt kann, also ia. nicht zu Anfang des Boots, wenn der Selektor werkelt. Man kann vielleicht tricky Links setzen, die zunächst verwaist sind und dann mit einem fähigen OS später doch aktiv (habe ich mal so ähnlich gemacht mit MAGX) - aber das ist sicherlich zu kompliziert für Hansi Normaluser und widerspricht der Intention eines Bootselektors.

-------

... Extension ...

Dann nenne doch mal die anderen anstatt FarbIcons und Paletten.

Keine die mir bekannt wären.

Schade, ich hatte gehofft, ich hätte da bloß ´was verschlafen. 
Unser Problem mit neuen Extension-Slots ist ja wohl, daß man sie nirgends anmelden kann. Schon die Paletten-Extension war doch ein Wildwuchs? Dafür sowie auch für die MonoIcon-Erweiterung >64k fehlt mir jedenfalls offizielle Doku a la FarbIcons.

[1ST1]

Es ist ein Unterschied, ob man den Verzeichniseintrag oder den Inhalt der Datei ändert. Beides ist ein Schreibvorgang, aber auf verschiedene Bereiche des Dateisystems. Eine Namensumbennenung ändert den Inhalt nicht...

[Thorsten Otto]

Es ist ein Unterschied, ob man den Verzeichniseintrag oder den Inhalt der Datei ändert. Beides ist ein Schreibvorgang, aber auf verschiedene Bereiche des Dateisystems.

Theoretisch, ja. Auf unix-Systemen wird das auch so gehandhabt. Bei TOS gibt es allerdings keinen Schreibschutz für Directories. Auch der Schreibschutz für Dateien ist nur halbherzig implementiert. Es wird zwar beim öffnen geprüft, aber du kannst fröhlich eine Datei beschreiben die eigentlich nur zum lesen geöffnet wurde.

[Thorsten Otto]

Unser Problem mit neuen Extension-Slots ist ja wohl, daß man sie nirgends anmelden kann.

Ja, ist halt leider so. Man kann sich nur auf Neuerungen einigen, was aber bei der übriggebliebenen Gemeinde nicht so schwierig sein dürfte. Oder man schafft einfach Tatsachen, wie es MagiC seinerzeit in einigen Bereichen getan hat.

Schon die Paletten-Extension war doch ein Wildwuchs?
Dafür sowie auch für die MonoIcon-Erweiterung >64k fehlt mir jedenfalls offizielle Doku a la FarbIcons.

Irgendwo hatte ich mal was darüber gelesen, weiss aber auch nicht mehr wo. Im Interface-Handbuch ist jedenfalls nichts darüber zu finden.

[ari.tao]

^^-- Hat vielleicht sonst jmd. @alle ebbes dazu?

-------

Wenn man ´von Hand´ einen Directory-Eintrag schreibschützt, dann wird iirc nur der Eintrag geschützt, aber nicht der Inhalt des Dirs.
Einen wirksamen Schreibschutz schafft man, indem eine Datei geöffnet und danach nicht wieder geschlossen wird. Leider gibt es ein paar Kandidaten, die dieses Kunststück im AUTO\ hinkriegen - und dann wundert sich der Benutzer, daß er eine Datei nicht wie üblich vom Desktop aus bearbeiten kann (manchmal hilft Kobold, keine Ahnung, wie er das macht) und daß ihm ein mehr oder weniger großes Stück Speicher fehlt...

[1ST1]

Wenn man ´von Hand´ einen Directory-Eintrag schreibschützt, dann wird iirc nur der Eintrag geschützt, aber nicht der Inhalt des Dirs.

Das ist ja auch Sinn der Sache, es soll nur der Verzeichniseintrag vor Modifikation geschützt werden. Ist unter Windows heutztage übrigens auch machbar, in dem man z.B. die Vererbung nach unten ausschaltet. Und wenn ich mich recht erinnere, ist es in Linux auch so. Wenn du da ein "chmod 111 <ordnername>" machst, bekommen darin die Dateien nichts davon mit. Erst wenn du es rekursiv machst, ändert sich das.



@Thorsten Otto  - Über das Handling des Schreibschutz-Attributes bei Dateien durch den Desktop oder aus Anwendungen heraus gehts hier doch garnicht? Hab ich übrigens unter TOS/MiNT noch nie verwendet, unter DOS/Windows übrigens auch nicht, bei letzterem gehts eh viel effektiver über die Berechtigungen, als über das einfache Schreibschutzhäkchen, das auch jeder, der die Schreib-Berechtigung hat, wieder entfernen kann... Und falls das unter TOS wichtig wäre, sollte man mal BigDOS testen, ob es damit korrekt funktioniert.

[ari.tao]

Neue ExtensionSlots?:

Man kann sich nur auf Neuerungen einigen, was aber bei der übriggebliebenen Gemeinde nicht so schwierig sein dürfte. Oder man schafft einfach Tatsachen, wie es MagiC seinerzeit in einigen Bereichen getan hat.

Wenn Du einen ExtensionSlot für Sounds erfindest und/oder einen für die kleinen AnimationsBildchen, die 1ST1 neuerdings so liebt, dann könnte das den Durchbruch für Dein ORCS bedeuten. Schlecht wäre es allerdings, wenn Dein einziger verbliebener Konkurrent RSM dann etwas anderes inkompatibles macht. Der erste, der eine neue Extension publiziert, der setzt sicherlich den Standard.
                                                                                           

[gh-baden]

Mit XBoot macht man das ja auch ganz anders. […]

Wollt ihr nicht langsam mal den Betreff ändern? Es geht nicht mehr um gesuchte Icons, sondern wie RSC-Dateien auszulegen sind, und wie man mit NEWDESK.INF umgeht …

[ari.tao]

Guter Vorschlag!

[Atariosimus]

In STComputer 10/92 auf Seite 106 steht noch ein interessanter Artikel mit Programm.
Da soll man 255 Icons in 64 KB unterbringen. Ist ein Icon Packer für die Resource Datei.
Das probier ich mal aus wenn ich das Programm zum Download finde. Abtippen ist mir
allerdings zu lang.

Hier das Programm:
http://www.stcarchiv.de/stc1992/10/mehr-icons

[ari.tao]

^^-- Zunächst mal:
Abtippen mußt Du doch gar nix - kann man doch einfach ´rauskopieren:
   http://st-computer.atariuptodate.de/index.php?content=archiv&mag=stc&year=1992
Jedoch bezweifle ich, daß sich die Mühe wirklich lohnt:
Es ist keine gute Idee, daß die Icon-Texte perdü gehen. Der GEM-Desktop benutzt sie zwar nicht - wohl aber moderne Desktöppe wie zB. THING oder JINNEE; die identifizieren nämlich die Icons nicht mehr nach deren fortlaufender Nummer (keine gute Idee, was man merkt, wenn man mal mittendrin Icons löschen oder einfügen will), sondern eben nach deren Namen, ie. dem Icon-Text.
Zum anderen schau Dir einmal im RCS genau die 200 Icons an, die Du von mir hast. Dann wirst Du feststellen, daß nur sehr wenige gleiche Masken haben. Der Grund ist, daß diese Icons nicht bloß zweifarbig sind, sondern gewissermaßen zweiundeinhalb-farbig, denn an einigen Stellen scheint der Untergrund durch, der ebenfalls farbig sein kann (mit einem dazu fähigen Desktop und > 2p). Du wirst dann nur schätzungsweise ein Dutzend zusätzliche Icons einbauen können und alsbald stehst Du wieder vor dem Problem, daß der Platz voll ist.
(Ich habe mehr als 500 Icons. Die mir wichtigsten 200 habe ich nach vorne geholt. Leider weiß ich nicht, welche Desktöppe das .RSX-Format von Interface verarbeiten können...).

PS1: Wenn Du die Vorschau-Funktion benutzt, dann kriegst Du auch das Layout gebacken.
PS2: Warum nicht der Anregung von gh_baden folgen?
PS3: Ah, die von Dir angehängte DeskIcon.RSC scheint wieder verschwunden zu sein. Hatte mich schon gewundert über die neuerdings im Forum herrschende Toleranz...

[Atariosimus]

Danke für die Info. Ich hatte die RCS Datei wieder rausgenommen. Der einfache Grund ist, sie war ja nicht fehlerfrei nur um einigen später den Frust zu ersparen defekte Dateien zu kopieren. Inklusiv mich selbst. 

Danke für den Link. Dann kann ich den Text mit GFA 3.6 umwandeln. 

"...(mit einem dazu fähigen Desktop und > 2p)".  Das versteh ich leider nicht ganz. Was ist 2p?

[mfro]

>2p -> mehr als zwei Planes (vier Farben)

[gh-baden]

Einen wirksamen Schreibschutz schafft man, indem eine Datei geöffnet und danach nicht wieder geschlossen wird. Leider gibt es ein paar Kandidaten, die dieses Kunststück im AUTO\ hinkriegen - und dann wundert sich der Benutzer, daß er eine Datei nicht wie üblich vom Desktop aus bearbeiten kann (manchmal hilft Kobold, keine Ahnung, wie er das macht)

Kobold geht im normalen Modus (also nicht im GEMDOS-Modus) am GEMDOS vorbei und manipuliert Sektoren und FAT von Hand. Quasi ein nachprogrammierter Dateisystemtreiber, aber nur in einem Programm enthalten.

[Atariosimus]

Mit XBoot macht man das ja auch ganz anders... Man legt sich einen Ordner an, z.b. c:\auto\newdesk (eine andere schöne Variante wäre c:\gemsys\newdesk) und da legt man sich die verschiedenen newdesk.inf Dateien mit sinnvollen Namen (stlow.inf, stmed.inf, sthigh.inf, ttvga.inf, tthigh,inf, scrblstr.inf, network.inf, ...) Die Dateien werden nicht von Xboot bearbeitet, sondern nur kopiert. Man muss sich nur angewöhnen, wenn man tatsächlich mal was an der newdesk.inf was ändert (arbeit sichern), dass man die dann wieder in dem Ordner unter dem Namen kopiert, wie man das in Xboot eingestellt hat. Da,mit hat man dann auch seine Sicherheitskopie.

Das ist eine wirklich gute Idee, Danke

Anbei meine Desktop.rsc und Newdesk.inf

[ari.tao]

^^-- @Atariosimus siehe PM.

-------

Kobold geht im normalen Modus (also nicht im GEMDOS-Modus) am GEMDOS vorbei und manipuliert Sektoren und FAT von Hand. Quasi ein nachprogrammierter Dateisystemtreiber, aber nur in einem Programm enthalten.

Das war schon klar - aber mich wundert, daß das GEMDOS hinterher an der Manipulation keinen Anstoß nimmt. Liegt vielleicht einfach daran, daß die geöffneten Dateien bis zum nächsten Reboot gar nicht mehr benutzt werden? Oder, daß der K. die Dateien schließt?