Genbruges

Link: http://gerph.org/riscos/ramble/buildtools.html

Application ikonet for !ResEd
!ResEd

!ResEd værktøj ikke har for meget arbejde på det. Bortset fra at være konverteret til den nye build – system- samt alle dens sub-komponenter – det gjorde ikke rigtig har brug for meget arbejde at gøre. De vigtigste shell ansøgning indeholder alle de ‘filer’, og indlæs og gem, og der er en række sub-komponenter for hver af Værktøjskassen objekt typer. Det er ganske godt tænkt og fungerer godt som et enkelt program (!Konfigurereprogram er ikke helt så godt integreret).

jeg har opdateret den vigtigste shell til at have en lidt mere Ordensmenneske-lignende interface, der giver mulighed for en ‘små ikoner” og “fuld information” tilstand i sin skærm. Mens det var lidt mere standard, det ikke rigtig ser rigtigt, så jeg forlod indstillingen er deaktiveret. Jeg spekulerede på, senere, om vinduet kunne have fået en lille make over som !Maling, med en værktøjslinje, og måske en status bar i bunden. Selv markerer redigeret objekter i hovedvinduet se, og giver en “fortryd” for at ændre et objekt, der kan bidrage til at gøre programmet lidt mere nyttigt.

Hver af de sub-komponenter, der har sin egen rolle at spille, men den eneste virkelige objekt program, som jeg har brugt nogen tid på at arbejde på var vindueseditoren. Jeg havde virkelig en masse sjov med det, <smil>.

problemet med Vinduet editor er, at mens der er programmer, der giver den plug-in interface til forskellige objects, der ikke svarer til den gadgets. Internt, gadgets, alle blev beskrevet i en stor fil, der indeholdt alle de definitioner, der er for alle gadgets. Mens de var beskrevet i et dejligt simpelt sæt af strukturer, og havde adgang til en masse funktioner til at gøre deres arbejde, de var ikke let for andre at opdatere.

Hvis du skrev en ny gadget, du ville have til at tale med den person, der er bygget !Vinduet for at opdatere definitionen til også at indeholde nye definition for den gadget og eventuelle beskeder og skabeloner, det ville have behov for at blive fusioneret ind i den vigtigste anvendelse. Dette syntes urimeligt for mig, og det ville være en grund til, at mennesker ikke er at udvikle en mobiltelefon – hvilket ville være trist, da de er en fantastisk måde at udvide brugerflade. Jeg var fast besluttet på at fjerne årsager til ikke at bruge den Værktøjskasse, hvor jeg kunne, og det var et område, som ikke var for svært.

jeg allerede havde lavet den Opstartsmenu system understøtter dynamisk indlæsning af udvidelser, så Podules kunne give deres egen konfiguration i menuen poster. Jeg brugte hvad jeg havde lært, fra at tilføje dynamiske indlæsning af kode, der er defineret, hvordan de gadgets, der blev redigeret. Fordi vinduet editor ‘ s gadget definitioner, der blev ganske godt struktureret, det var ikke så svært at flytte dem ud til separate filer. Der var nye eksport fra vinduet editor komponent, således at overskrifterne var til rådighed for gadget-redaktør definitioner, når de indlæses.

Hver af de gadgets, som blev skilt ud i komponenter i deres egen ret – de havde deres egen kilde mappe, makefiler og ressourcer. Disse komponenter blev derefter bygget i sub-mapper i vinduet editor-program, og der blev indlæst, når editor er startet op. De skabeloner og beskeder, filer, der blev delt ud, så de kan læses enkeltvis, og ikke behøver at blive fusioneret ind i den vigtigste filer. I det væsentlige, bør du være i stand til at slette den mappe i det vindue, editor-program og gadget støtte ville gå væk – eller kan du bare kopiere over toppen af den gamle for at opgradere.

jeg startede ud med den ‘etiket’ gadget, som var den enkleste, og arbejdet op til de mere komplekse gadgets som skrivbare ikoner. For de fleste af de gadgets, jeg fandt, at jeg havde brug for at eksportere et par flere funktioner, så de kunne gøre deres job. Forhåbentlig, jeg havde formået at indeholde tilstrækkelige eksport som en redaktør, der kunne være skrevet for de fleste fremtidige gadgets (men jeg har helt sikkert glemt nogle ting).

Hver af de gadget definitioner blev også opdateret til at være i stand til at give nærmere oplysninger om de moduler, som de havde brug for. Modulerne blev sikret, og der er lagt, hvis det er nødvendigt, når redaktøren var i gang. Dette betød, at hvis du har det relevante modul på systemet, vil du være i stand til at gøre det, samt redigere det.

ideen var, at som en del af en anden SDK frigivelse, vi vil indeholde de nødvendige oplysninger for at forklare, hvordan man skrev en gadget editoren. ‘App ‘ bemærkninger’, at Acorn havde produceret på at skrive gadgets var faktisk ganske god, men selvfølgelig ville de ikke dække, skriver gadget redaktører, så det ville være nødvendigt at skrive noget, som forklarer, hvordan du opretter sådan en editor bibliotek, sammen med de nødvendige kilde og eksempler.

Det var stadig nødvendigt at opdatere !ResTest ansøgning med oplysninger for hver gadget type, der er frustrerende også. Men det var ikke til at være nogle af de kommende arbejde (som jeg fik aldrig at gøre).

Det betød også, at skrive, redaktør støtte til de nyere gadgets, som AMPlayerGadget var virkelig ganske let. Nogle af de andre gadgets, var blot simple kopier af de grundlæggende gadgets med nogle små opdateringer. Af den simple gadgets, alle de dynamiske bibliotek indeholdt var en struktur, der er beskrevet samspillet mellem ikoner. Jeg har overvejet at skrive et værktøj, der ville gøre strukturen definitioner fra en header-fil, som CMHG er, men besluttede at skrive den definition, som hånd var faktisk mere tilbøjelige til at være nyttigt.

Alle skabelonfiler blev givet behandling af FixUpTemplate for at sikre de var pæn og ensartet.

jeg har tilføjet nogle tentative support for visning af de gadget-nummer sammen med den gadget, i vinduet. Dog, dette er ikke rigtig ser så godt ud og jeg vendte den mulighed fra, før jeg fik en mulighed for at tilføje bruger-interface til at styre det. Jeg havde tænkt mig at vende tilbage til denne mulighed, så ville det være lettere at henvise til gadgets.

genveje fra vinduet er blevet opdateret en smule, så at de genveje, der er gjort lidt bedre, og havde standard navne, der anvendes til dem. Dette forbedret deres udseende lidt, og til at forbedre brugervenligheden, der blev tilføjet for at trække flere genveje mellem windows til at kopiere dem.

En ting jeg ikke komme til at opdatere blev gadget paletten. Du har stadig nødt til at opdatere den palet med en skabelon gadget. Virkelig, paletten bør oprettes dynamisk, men det ville være lidt tricky at gøre lige ud. Det behov en bit mere tanke for at gøre det så fleksibelt, som det kunne være, ikke mindst fordi nogle gadget redaktører måske ønsker at give en gruppe af skabelon gadgets.

ændringer til vinduet editor gjort det langt nemmere at gøre andre gadgets til rådighed. Det var, trods alt, er beregnet til at være et modulopbygget system. Men der var andre områder, der virkelig er behov for adressering. Jeg ønskede at give mere integration til andre applikationer, særligt integrerede værktøjer til udvikling af software, som kan være leveret af tredjepart. Der var et par ting, der kunne gøres der med en tæt integration til Toolbox-beskeder, objekt og gadget-id ‘ er, og de kan lide, men jeg ønskede at forlade dem, indtil senere. Ikke alene var de hårde, men de har også behov for for mig at forstå, hvad den sandsynlige anvendelse tilfælde skulle være, før at designe en protokol til at kommunikere sådanne ting.

På et niveau over den slags tætte integration, var, hvad jeg gjorde – det giver en Ekstern Redigere støtte i !ResEd. Den Eksterne Redigér protokol, der tillader, at en applikation til at anmode om, at en redaktør udføre sit arbejde på en fil, og derefter at vende tilbage filen til det, når du er færdig. Primært redigering er udført af en tekst-editor, og anmoder om programmet er et værktøj, som har behov for nogle større input som en e-mail-klient. Men det behøver ikke at være tekst til alle, og jeg havde allerede tilføjet Eksterne Redigere støtte til !FormEdExt for skabelonen filer.

I dette tilfælde, !ResEd var redaktør. Det accepterer Eksterne Redigere anmodninger om Ressource-filer, og kan vende dem på forlangende, eller opgive rediger. Markøren kontrol ikke fungerer, fordi der ikke er en markør i editoren. Ideelt set bør det være muligt at udløse en redigering af et objekt inden for de Ressource-fil, men der er ikke fastsat (af protokollen eller gennemførelse). Jeg brugte den gamle redigering test, at jeg havde oprindeligt skrevet for at teste den Eksterne Redigere støtte, når jeg har tilføjet det til !FormEdExt.

Det hele virkede ret godt, selv om jeg er temmelig sikker på, at den støtte, der faktisk ikke er nævnt nogen steder, da det stadig var et tidligt træk, og uden nogen programmer til at støtte det, det ikke rigtig gøre så meget.

Brug Eksterne Redigere med ResEd til at redigere en fil
Redigering af en Ressource fil og derefter returnere den redigerede fil var ganske enkel.
(Animeret version (95K))

ResTest

Application ikonet for !ResTest
!ResTest

En ting jeg gjorde tilføj for at lette brugen af !ResEd for at tilføje en ‘Test’ menupunkt nederst i menuen Filer. Dette vil påberåbe sig den !ResTest program, og passerer det en kopi af den aktuelle fil. Der var en simpel protokol, der bruges til at kommunikere med !ResTest men jeg havde ikke følt også komfortable med det at definere det ordentligt. Det gjorde jobbet, og det gjorde redigering og afprøvning Ressource-filer meget nemmere. I sidste ende ville det have været ryddet op og designet og dokumenteret korrekt.

Med alle de andre gadgets, der var blevet tilføjet, og den nye beskeder, der sendes af de objekter, !ResTest er nødvendigt at opdatere til at tilføje i detaljer i sin debug-vinduet. Jeg har tilføjet de fleste af de nye Værktøjskasse beskeder, ligesomWindow_GadgetLostFocus Window_GadgetMouseScroll beskeder, og alle de nye fra OptionsWindow objekt, ScrollList, TextArea, og andre gadgets.

MethodGen

Application ikonet for !MethodGen
!MethodGen

Oprindeligt Værktøjskassen komponenter blev bygget af en gruppe af ad hoc-makefiler, meget som resten af RISC OS-kilden var. Jeg har opdateret disse til at bruge nogle af de “standard” makefile-format, som har reduceret mængden af vedligeholdelse. Når jeg havde gjort det, så jeg lavede alle makefiler mere kompleks ved at tilføje flere muligheder til at bygge! Faktisk var det ikke helt så slemt som denne, der bygger på den Værktøjskasse komponenter var lidt anderledes end mange moduler, som de havde en række ressourcer til eksport og overskrifter.

Derudover vil jeg flytter rundt på den måde, at de definitioner, der blev håndteret. Hvert objekt og gadget har en “Metode definitioner” fil som beskriver den input-og output-parametre. Disse filer bruges til at bygge den metode, grænseflader i kilde-filer, som kan derefter indbygges i objekt filer. Internt disse havde bare været gemt i Værktøjskassen biblioteker komponent, men som ikke giver meget mening.

Den metode, definitioner er generelt ændrede sig, da gennemførelse af ændringer. Generelt er de metoder, der er faktisk ikke ændre (som det ville bryde ABI kompatibilitet), men der er ofte tilsat. Jeg flyttede alle definitioner fra blot at være inkluderet i Værktøjskassen biblioteker til en ‘definitioner’ eksport i hver komponent. !MethodGen værktøj blev opdateret til at være i stand til at generere kilder fra kommandolinjen. Tidligere arbejdsproces ville være at indlæse !MethodGen værktøj, foretage ændringer til metode-filen, gemme det, og tryk derefter på-knappen for at generere kilder fra det. De kilder, der så ville have til at være, der er føjet manuelt til Toolbox library komponent (forudsat, at du har husket at gøre det), og så toolbox library genopbygget.

Den nye metode betød, at mens du stadig behov for at huske at tjekke ind metoden fil med den eller de komponenter, der er temmelig meget en given), den næste ombygning af Værktøjskassen biblioteker vil bruge den nyligt eksporteres metode definition til at bygge de kilder, og konstruere den fulde bibliotek. For at gøre opbygge arbejde, MakeGen værktøj blev der også ryddet op i.

MakeGen værktøj var beregnet til at tage et sæt af mapper, og opbygge den relevante makefiler således, at alle filer i disse mapper, blev bygget med C-compiler, der er knyttet til et mål bibliotek. I modsætning til resten af bygge-systemet, dette værktøj kan ikke bruge standard-bibliotek skelet, fordi det var forventet at blive brugt, uden at resten af makefile-system skal være til stede. I det væsentlige, output fra !MethodGen kan bruges sammen med MakeGen, af enhver, der ikke har den største bygge-systemet.

det faktum, at det skulle kunne bruges uden for den standard build betød, at det ikke får mulighed for at målrette 32bit eller 26bit bygger uafhængigt af hinanden. MakeGen er blevet opdateret, så afhængigt af, hvordan det er gjort gældende, kan det generere makefiler i stand til at bygge bare 32bit, bare 26bit eller begge biblioteker. Det kan synes en smule mærkeligt at bygge moderne komponenter med 26bit varianter, men der var stadig biblioteker, der var 26bit. Plus, af kursus, når ROM blev bygget til en 26bit miljø, det havde at linke mod 26bit biblioteker.

MakeGen værktøj, og !MethodGen, ville være blevet fordelt som led i udviklingen af værktøjer i det næste skal du Vælge udgivelse. Hvis man antager, at er, at der var tid nok til at teste dem og sat sammen på en distribution, der var brugbart for andre mennesker. Jeg er ikke rigtig sikker på, at fordelingen af udviklingsværktøjer var især vigtigt, at folk, men det betød noget for mig, at disse redskaber være til rådighed. Der er ingen mening i at have den udvidede Værktøjskasse, hvis folk er nødt til at kæmpe for at udvide det, og de værktøjer, der gjorde, at kampen betydeligt lettere.

ImageFileGadget metoder
Redigering ImageFileGadget metoder i !MethodGen.

Perl og andre værktøjer

var Der andre værktøjer til støtte, der blev leveret som en del af bygge-systemet, som skal opdateres for at bygge ting. I mange tilfælde, der ikke var alt for mange problemer i genopbygningen af komponenter. Ændringer, for at opbygge systemet i sig selv betød, at skabe en makefile til et nyt værktøj, som kunne bygge i 26bit, 32bit eller anden variant, var meget let.

Perl bruges til en hel del værktøjer, og det øverste niveau opbygge systemet, til at behandle og styre et par ting. Den oprindelige bygge-systemet var blevet forsynet med et par awk scripts, der var… godt jeg kan ikke lide awk med en passion, som er næsten helt kan henføres til dens anvendelse i RISC OS’ build-system. Udskiftning Perl scripts der var langt klarere, selv om jeg havde ikke helt forstået, hvor vigtigt det var at sørge for, at kommentarer er anvendt og relevant.

Perl, at vi, der anvendes inden for bygge-var det den sidste udgave, der ikke brug UnixLib – 5.001. At være en version 5 Perl, det er ret dygtig, men ikke har så mange af de pænere nye funktioner. Stadig, det er en god del bedre end awk på hvilken som helst dag i ugen. Konvertering det over til det nye build system var ligegyldige, og på samme tid, besluttede jeg mig for at undersøge, hvad det var, der fik skiven til at spinde, når tolken var i gang – selv om det var intet at gøre.

Det er slemt. Jeg vidste ikke helt, hvor slemt, men … for at udfylde den første %ENV hash med systemet variabler, ville det problem *Vis, at { > nogle skrot-fil }, kan du læse filen i hukommelsen, og derefter fortolke hver linje til at skabe nøgle-værdi-par. Ikke alene er dette spild ved at skrive til en disk, men introducerer en race condition, og det er påvirket af ethvert værktøj, der ændrer * kommandoen. Jeg havde sådan et værktøj, og heldigvis er det klaret på den måde, at produktionen blev produceret, men det er stadig forkert.

jeg tog tid til at omskrive hash befolkningen, således at det anvendte SWI OS_ReadVarVal opfordrer i stedet. Det er stadig produceret miljø tabellen på samme måde som før – en nøgle-værdi-par – men det ikke længere gik til disken for at gøre det, og så løb en hel del hurtigere.

jeg var interesseret i, på et tidspunkt, med hjælp af enten den ‘mangfoldighed’ byg muligheder for at bygge videre Perl som et modul, eller for at bruge flere instantiering til at give forskellige instanser i en ansøgning. Sådanne ting er kun i begrænset omfang, men der er en Windowsfunktion, som om side med lave start omkostninger, kunne have været meget nyttigt.

var Der en hel flok af andre værktøjer, der er nødvendige for at blive bygget, eller skabt. Build-system havde været forsynet med et værktøj, der hedder Killing – det er en lille ‘kat’ (i Unix forstand, at sammenkæde de filer, der leveres til det). Jeg greb en lille BSD-version og brugte det i stedet. Hele pointen af værktøjet var for at have en konsekvent og kendt adfærd for værktøj.

Andre værktøjer var bare RISC OS-standard-værktøjer, som er nødvendige for at blive gengivet. CDir, IfThere, Kopiér, Ødelægge og SetType kommer til at tænke på. De kommandoer, der alle findes på RISC OS, men når du kører den bygger på Linux eller Windows, er du nødt til at have en ensartet kommandoer, der gør de rigtige ting, uden at skulle bekymre dig om eventuelle særlige tilfælde. Gengivelse af disse værktøjer var faktisk meget simpelt – for eksempel SetType ville bare omdøbe en fil for at få korrekt ,xxx, der sluttede for filetype den blev leveret.

Alle de værktøjer, der anvendes af biblioteker, der forstod at tage RISC OS-som navne og bruge dem i deres oprindelige formater, hvilket betød, at alle makefiler, der var blevet produceret kunne bruges næsten præcis, som de stod. Kun i et par tilfælde var nogen yderligere oversættelser er påkrævet.

Værktøjer som sed var ikke meget brugt, men var behov for nogle specialiserede oversættelser. ‘C i assembler’ komponenter ville samle til assembler-filer, hvilket ville så blive ændret en smule for at fjerne ting som OMRÅDEerklæringer og lignende. bison (parser generator) og flex (leksikalsk analysator) værktøjer blev ligeledes specialiseret – jeg kan ikke huske, hvad de blev brugt til præcis, men jeg har en vag fornemmelse af, at libpcap brugte dem som en del af sin parser.

DefMod værktøj, der blev brugt af OSLib at bygge sine kilder var blevet opdateret til både 26bit og 32bit bygger. Dette betød lidt mere, fordi OSLib blev brugt til at bygge et par komponenter, og vi havde brug for at være i stand til at opbygge biblioteket for enten 26bit eller 32bit mål, på samme måde som alle de andre biblioteker blev.

Have de værktøjer og kontrol for at ændre enhver del af bygge-systemet er altid nyttigt – det er ikke altid nødvendigt, men det er helt sikkert nyttigt. Selv om der i nogle tilfælde betød det, at genskabe værktøjer, der allerede havde været gennemført i RISC OS, det gav en masse mere frihed i at være i stand til at køre bygger på Linux eller Windows.

FixUpTemplate

IconBorders var blevet tilføjet til systemet for at gøre tingene ser pænere og nemmere at style for brugerne. Men en effekt, at de havde, var at gøre den stationære langsommere. I første omgang var dette, fordi hver afrundede hjørne eller blanding på knapperne vil blive plottet direkte på skærmen – og nogle gange pixel for pixel – hvilket var ganske langsomt. For at afhjælpe dette, indholdet af de knapper, der skal præsteres, blev cachet på brug i en sprite område, der kontrolleres afIconBorderRound – modulet. Dette betød, at når den samme stil af knappen blev trukket det ville gøre ved blot at plotte den cachelagrede knappen sprite.

Men denne dukkede op et problem i, at de ikoner, der anvendes i hele systemet – i de programmer, og er bygget i moduler, der blev rigtig strid. Toolbox-baserede applikationer var som regel fint, fordi den standard knapper, som du ikke ville at tage fra paletten var generelt venstre i standard størrelse. Dette betød, at de fleste Værktøjskasse applikationer haft et meget ensartet udseende. Skabelon baserede programmer var mindre konsekvent – og det betød, at de fleste af OS.

I nogle tilfælde, havde jeg allerede begyndt at standardisere den måde, at dialog kasser blev lagt ud, og knappen størrelser, men det var ikke altid en nøjagtig proces. Den stil, som OS, var følgende var ganske konsekvent, og fulgte op på den generelle måde, hvorpå applikationer, der havde været i gang – især !Gennemse og RISC OS-4 konfiguration komponenter.

stil var temmelig enkel (tal og begrænsninger taget fra FixUpTemplate så hvad jeg skulle holde mig til, hvis jeg har læst koden til højre).

  • Knapperne skal være de størrelser, der anvendes af !ResEd palette af standard, medmindre der var særlige grunde til ikke at.
  • Action-knapper, der ville være 52 pixels høj, med en bredde på 188. Hvis de har brug for at blive større, de skal være 12+16*antal tegn.
  • Standard knapper ville være 68 pixels høj, med en bredde på 204. Hvis de havde brug for til at være større, de skal være 12+16+16*antallet af tegn.
  • Ingen-knappen, skal være større end 22 tegn, eller mindre end 6 tegn (generelt) – i nogle sprog, som kan være forskellige, men for engelsk, der var fine.
  • I afviselig dialog bokse, en skillevæg linje skal være placeret i bunden af kassen med handlingsknapperne nedenunder.
  • Dividers bør være baseret på den venstre omfang af vinduet.
  • afskedigelse knapperne nedenfor adskilleren skal være højrejusteret, med knappen længst til højre ved at blive et standard-knappen.
  • Ikoner, der er linet op i en række, der skal være fordelt på 8 enheder fra hinanden.
  • Højder og vertikale positioner af ikonerne skal være linet op på fornuftig vis – basislinjer bør være på det samme punkt.
  • Ikoner foret lodret bør have deres venstre og højre omfang line up fornuftigt – de bør ikke strække sig længere i den ene retning end dem, der ovenfor (i almindelighed, at det hjalp med rækker af radio-ikoner, hvis højre grad en tendens til at være variabel, og ikke var indlysende; at gøre dem ensartede betød, at brugeren ikke behøver at bekymre dig om at klikke på ned i en kolonne af knapperne).
  • Forskellige typer af fælles ikoner skal have sat størrelser:
    • Option/Radio/Tick: 44 x 44
    • Etiketter: (0+tegn * 16) x 40
    • Skærm: (0+tegn * 16) x 52
    • Writables: (8+tegn * 16) x 52
    • Sunkne writables: (16+tegn * 16) x 68
    • Menu-knappen: 44 x 44
    • Skyder pile: 32 x 32
  • Ikoner skal aldrig breder sig over kanten af det synlige arbejdsområde.
  • Ikoner bør ikke være uden for det synlige arbejdsområde (kvoter for windows, at skifte størrelser).
  • Ikoner må ikke placeres uden for omfanget af vinduet.
  • Etiketter ved siden af Display-ikoner skal være højrejusteret.
  • Etiketter følgende ikoner (som regel en separator for en “bredde : højde’ style input) bør være vandret centreret.
  • ikon typer skal have en vis ikon sæt flag:
    • Display felter Skal være udfyldt, vertikalt og horisontalt, centreret.
    • Rejst ikoner: anbefales Ikke.
    • Faste ikoner: anbefales Ikke.
    • Kanal grupper: Må ikke være fyldt, ikke har tekst eller sprite indhold.
    • Action/Standard knapper: Skal udfyldes, horisontalt og vertikalt centreret, ikke lige er berettiget, bruge grey 1 baggrund, sort tekst.
    • Skrivbar ikoner: skal være skrivbar (at sige, hvis de ser som en skrivbar de skal også fungere som om det), skal udfyldes, skal være hvid baggrund og sort forgrund, skal være vertikalt centreret, skal være vandret centreret.
    • Radio/Indstillinger ikoner: Skal have sprites bestilt ‘off,on’, være af typen radio, Radio-ikoner skal være ESG != 0, Option ikoner skal være ESG 0.
    • Dividers: skal ikke udfyldes, skal ikke være vandret, centreret eller højrestillet, skal være vertikalt centreret, ikke må have en grænse.
    • Text+Sprite ikoner (f.eks fil sprites): Skal ikke være både horisontalt og vertikalt centreret (medmindre det er også højrestillet).
  • Dialog bokse, skal kun have en ‘Standard’ – knappen.
  • Dialog bokse er tilladt at have knapper, der er justeret til venstre for ‘under divider” – afsnittet, men kun hvis de konsekvent linje op. (normalt for ‘åbne hjælp”, “avancerede” eller lignende knapper).
  • Afskedigelse knapper til højre for dialogboksen, skal aldrig ende i en ellipse.
  • Label ikoner, aldrig må ende i et kolon, eller en plads, men heller ikke skal have et præfiks med et mellemrum.
  • Knapperne skal i almindelighed være et enkelt ord.
  • Standard knapper skal aldrig ende i en ellipse.
  • Sprite navne må ikke indeholde mellemrum.
  • Kun 2 sprites, der er tilladt i sprite validering.
  • Sprite navne skal være mindre end 12 tegn.
  • Vindue flag skal opfylde visse kriterier:
    • Vinduer skal altid være ” ny ” (RISC OS-2) format.
    • Windows med en Luk-ikonet skal altid have en Back-ikon.
    • Windows med en Titel og en Tilpas størrelse, skal altid have en Toggle-skift ikon.
    • Windows med både vandret og lodret rulle bør have en Tilpas ikon.
    • Resize bør ikke indstilles, når hverken skal du bruge rullepanelet.
    • Windows skal ikke krav på at være både forgrund og baggrund.
    • Vinduer bør ikke have den sande farver flag sat (særlige tilfælde).
  • Vindue titler skal ikke ende i et kolon eller plads, og må ikke begynde med et mellemrum.
  • Windows skal forsøge at tilpasse sig de forhold 1.414:1 (som jeg fejlagtigt skrev som ‘det gyldne snit’, tut tut).

Disse er ikke alle af de regler, der har det – bare dem, at jeg kunne se (og som jeg troede interessant). De nærmere oplysninger om disse (og andre) sammen med en begrundelse blev indsamlet i et tillæg til vejledning. Jeg ved ikke, hvor de gik.

værktøjet ville ind til alle disse ting, og endda løse nogle af dem op, så det var ikke nødvendigt at gøre dette manuelt. De fleste af de ting, som det rapporter er nyttige bulletiner, selvom jeg ikke gøre noget ved dem. Af bidraget til at sørge for, at alle applikationer, der havde et ensartet udseende.

En lille del af produktionen, når behandlingen af skabelon-fil til !Brændenælde, viser bare de ‘åbne’ og ‘resize’ skabeloner.

Skabelon fixer 0.10 (30 Okt 2005). (C) Justin Fletcher
Behandling vinduet 'åbn'
Ikonet 0: type 5 "/'<>'/'Nhost;Pptr_write;Kat;AA-Za-z0-9-. ,:@'
Skrivbar ikonet er ikke H-centreret
Afstand (V) med et ikon, 8 skulle være 8 OS-enheder (i øjeblikket 12)
Afstanden (H) med et ikon, 10 8 OS-enheder (i øjeblikket 4)
Ikonet 1: type 8 'Annuller'/'<>'/'R5,3;Ncancel'
 Handling/Default-knappen er ulige bredde (anbefaler, 156, standard 188, sekundær 140)
Ikonet 2: type 7 'Connect'/'<>'/'R6,3;Nconnect'
Handling/Default-knappen er ulige bredde (anbefaler 172, standard 204 -, sekundær-156)
Ikonet 3: 4 type 'Opgave-vindue'/'<>'/'R2;Ncontype'
Afstanden (H) med et ikon, 5 bør være 8 OS-enheder (i øjeblikket 4)
Ikonet 4: type 12 '<>'/'gright,pgright'/'R5;sgright,pgright;Ncontypebut'
Menu-knap ikke bruge ptr_menu
Menu-knap R-Berettiget
Ikon 5: skriv 0 'Connection'/'<>'/"
 Afstand med vindue kant bør være 12 OS-enheder
Ikon 6: type 5 "/'<>'/'Pptr_write;Kat;Ncommand'
Skrivbar ikonet er ikke H-centreret
Afstanden (H) med ikonet 11 bør være 8 OS-enheder (i øjeblikket 4)
Ikon 7: type 4 'xterm-farve'/'<>'/'R2;Ntermtype'
Afstanden (H) med ikonet 9 bør være 8 OS-enheder (i øjeblikket 0)
Ikon 8: type 12 '<>'/'gright,pgright'/'R5;sgright,pgright;Ntermtypebut'
Menu-knap ikke bruge ptr_menu
Menu-knap R-Berettiget
Ikon 10: type 0 'Host'/'<>'/'Nhostlabel'
 Afstand med vindue kant bør være 12 OS-enheder
Ikonet 11: type 0 'Kommandoen'/'<>'/'Ncommandlabel'
Afstand med vindue kant bør være 12 OS-enheder
Generelt:
Vinduet er ikke formet til det gyldne snit (bredde = 192,384 eller højde = 628,1252)
Vinduet bør ikke være større end 800 x 600 OS-enheder
Vinduet indeholder 1 knappen Handling og 1 Standard-knappen, men ingen skillevæg
Behandling vinduet 'resize'
Ikonet 0: type 5 '80'/'<>'/'Pptr_write;Ktar;A0-9;Nwidth'
Afstanden (H) med et ikon 1 bør være 8 OS-enheder (i øjeblikket 4)
 Afstanden (H) med ikon 8 skulle være 8 OS-enheder (i øjeblikket 4)
Ikonet 1: skriv 0 'Width'/'<>'/'<>'
Afstand med vindue kant bør være 12 OS-enheder
Ikonet 2: skriv 5 '24'/'<>'/'Pptr_write;Ktar;A0-9;Nheight'
Afstanden (H) med et ikon, 3, skal være 8 OS-enheder (i øjeblikket 4)
Afstanden (H) med ikonet 9 bør være 8 OS-enheder (i øjeblikket 4)
Ikonet 3: skriv 0 'Height'/'<>'/'<>'
Afstand med vindue kant bør være 12 OS-enheder
Ikonet 4: type 5 '96'/'<>'/'Pptr_write;Kta;A0-9;Nscroll'
 Afstanden (H) med et ikon, 5 bør være 8 OS-enheder (i øjeblikket 4)
Afstanden (H) med et ikon, 10 8 OS-enheder (i øjeblikket 4)
Ikon 5: skriv 0 'Tilbagerulning'/'<>'/'<>'
Afstand med vindue kant bør være 12 OS-enheder
Ikon 6: type 8 'Annuller'/'<>'/'R5,3;Ncancel'
Handling/Default-knappen er ulige bredde (anbefaler 140, standard 188, sekundær 140)
Ikon 7: type 7 'Set'/'<>'/'R6,3;Nset'
Afstand med vindue kant bør være 12 OS-enheder
Handling/Default-knappen er ulige bredde (anbefaler 140, standard 204 -, sekundær-156)
Generelt:
Vinduet indeholder 1 knappen Handling og 1 Standard-knappen, men ingen skillevæg

Holde en ensartet stil er virkelig vigtigt for et produkt, der ser professionelt ud, og værktøjet hjælper med til at sikre, at dette fortsat er tilfældet.

ModServices

Tilbage, når Acorn udgivet Ursula til udviklere med henblik på test, der var et redskab, der leveres kaldet ursmod, som ville vise detaljer om modul-tjenester og være i stand til at opdatere modulerne fra den gamle stil, service handlere til den nye stil Ursula service borde. Når vi fik koden for OS, at dette værktøj ikke var inkluderet, så vi måtte nøjes med at opdatere ting ved hånden.

for At gøre dette lettere, skrev jeg et lille værktøj der hedder ModServices som gjorde et meget ens job – bortset fra at det ikke ville opdatere modul med den service poster i sig selv. Dets største styrke, selv om, var at finde afkode entry-punkter, og (jeg tror) det gjorde det bedre end Acorn værktøj. Jeg kan ikke være sikker på, fordi jeg ikke har den originale kilde, selvfølgelig <smil>.

under alle omstændigheder, det trådte gennem den vejledning, som tjenesten indlæg vil udføre, for at afgøre, hvilken service numre, det var at forsøge at kontrollere. I almindelighed, de fleste moduler (assembler dem) fulgte et lignende mønster, selv hvis der er skrevet i hånden. De fleste ville gøre en af de få ting:

  • Sammenligne med en umiddelbar konstant. Det er nemmeste.
  • Trække eller tilføje (måske flere gange) i en midlertidig registrere, derefter sammenligne med en umiddelbar konstant.
  • Som ovenstående, men i stedet for at sammenligne med en umiddelbar konstante, sætte flag baseret på den tilstand.
  • Indlæs en konstant i en midlertidig registrere, og derefter trække (eller tilføje).
  • Bygge en konstant ved hjælp af MOV, TILFØJ SUB, og derefter sammenligne den service nummer.
  • Brug EOR for at rydde bits i en midlertidig registrere, og derefter sammenligne med en konstant.

Omkring disse instruktioner, der er af interesse, der kan være stabling instruktioner, processoren tilstand manipulation, operationer på private word, eller et par andre ting, som skulle ignoreres. Når det havde analyseres resultaterne, og der blev indgået en oplagt opsigelse, det ville være glade for, at det havde fået ud af den rigtige service. Hvis det ramte instruktioner, er det i ikke forstår, eller det aritmetiske operationer var lige ulige (fx SUB r14,r1,pc – fratrække det aktuelle program, der tæller fra den service nummer), ville det give op og flag modulet som unparsable.

Typisk output, der kunne se noget i retning af:

UtilityModule: &6F, &81
Podule: &27, &45
UnSqueezeAIF: &B7
AppPatcher: &B7, &B9
DiagnosticDump: &DC
CFrontDemangler: &DC
CLIV: &D8
VideoHWVIDC: &45, &76
VideoHWVF: &45, &46, &B9, &E1, &E2, &400C3, &42680
VideoGuard: &DE, &DF &400C0
BufferManager: &27
Debugger: * &27
DMAManager: &27, &8E, &8F
RTCAdjust: &27
OSPointer: &46, &6F, &DE
Timeglas: &6
FileSwitch: &11, &12, &27, &68, &75, &7D
ResourceFS: &40, &75
ResourceFiler: &27, &4B, &4C, &4F &5E
Beskeder: &60
MessageTrans: &59, &5A, &75
TerritoryManager: &28, &73
UK: &64
Internationale: &43
SerialDeviceDriver: &27, &70, &71, &77, &81, &8A
SerialDeviceSupport: &27, &77
Mus: &27
SerialMouse: &27
PS2Driver: &27, &8A
InternationalKeyboard: &27, &43, &44
FileCore: &C, &11, &27, &40, &69, &6A &6B, &6C &75
ADFS: &27, &8A, &10802
ADFSFiler: &27, &4B, &4C, &4F &5E
RAMFSFiler: &27, &4B, &4C, &4F &5E
CDFS: &40
CDFSFiler: &11, &27, &4B, &4C, &4F &5E &7D
DOSFS: &11, &12, &27, &40, &42, &5C, &68, &69, &6A &6B, &6C
SystemDevices: &40
PipeFS: &40
AIF: &40
TransientUtility: &40
GRUNDLÆGGENDE: &11
BASIC64: &11
Obey: &2A
DDEUtils: &27, &53
SysLog: &7E, &9F, &B0, &D7 &42680, &80C41
ScreenModes: &50, &8D, &DE
ScreenBlanker: &27, &46
ScrSaver: &49, &7B, &80, &A9
SoundDMA: &27, &8A
SoundChannels: &27, &54
WaveSynth: &54, &59
StringLib: &54, &59
Slagtøj: &54, &59
SoundScheduler: &27, &54
SharedSound: &54, &42680, &80481
DeviceFS: &27, &40
ParallelDeviceDriver: &27, &70, &71, &79, &8A
ColourTrans: &27, &46, &59, &5C, &72
Tegn: &27
SpriteExtend: &27, &59, &72, &42680
InverseTable: &27, &46, &59, &5A, &72, &73
DrawFile: &60, &80D60, &80D61, &80D62
FontMap: &60, &6E
ZLib: &53, &42680
PNG: &53, &42680
ROMFonts: &60
FontManager: &27, &41, &46, &57, &64
ImageFileConvert: &80D40, &80D41, &80D42
CompressJPEG: &42680, &80D60, &80D61, &80D62
ConvertPNG: &80D60, &80D61, &80D62
ConvertBMP: &42680, &80D60, &80D61, &80D62
ConvertGIF: &46, &80D60, &80D61, &80D62
ConvertICO: &42680, &80D60, &80D61, &80D62
ConvertPNM: &42680, &80D60, &80D61, &80D62
ConvertSprite: &80D40, &80D41, &80D42, &80D60, &80D61
ConvertSun: &42680, &80D60, &80D61, &80D62
ConvertXBM: &80D60, &80D61, &80D62
ConvertPCX: &42680, &80D60, &80D61, &80D62
ConvertClear: &80D60
ImageFileRender_Artworks: &80D40, &80D41
Lynlås: &53, &42680
PrinterBuffer: &6F
PDriver: &78
PDriverDP: &46, &57, &65, &78
PDumper24: &66
PDumperCX: &66
PDumperDM: &66
PDumperE2: &66
PDumperIW: &66
PDumperLJ: &66
PDriverPS: &46, &57, &65, &78
RemotePrinterSupport: &95, &96
RemotePrinterMessages: &60
WindowManager: &27, &2A, &46, &59, &5A, &60, &6D, &72
FilterManager: &86
RedrawManager: &87, &88
IconBorderPlain: &87
IconBorderRound: &46, &72, &87
TaskManager: &27, &46, &49, &4A &4B, &4E, &4F &5E &90, &91, &92, &42680
ShellCLI: &11, &27, &53
DisplayManager: &27, &46, &49, &4A, &5B; &5D, &94
Filer: &27, &49, &4A, &5E &75, &7D &801C8
FilerSWIs: &53
Filer_Action: &11, &27
Gratis: &27, &49, &4A, &4E
Pinboard: &11, &27, &49, &4A &4B
ClipboardHolder: &49, &4A
WindowScroll: &49, &4A
ColourPicker: &46, &53, &59, &5D, &75, &93
TaskWindow: &11, &27, &53, &57, &72, &CC
NetStatus: &27
MbufManager: &A1; &42680
Internet: &45, &5E &9D &A2, &55640
InetServices: &80C41
Resolver: &9D &9F, &A1; &B0, &80C41
MimeMap: &80C41
InternetTime: &9F, &A1
InetConfigure: &9D &9F
DHCPClient: &9D &9F, &A1; &B0
ZeroConf: &9D &9F, &A1; &B0
RouterDiscovery: &9D &9F, &A1; &B0
Freeway: &9D &9F, &B0
FreewayHosts: &80, &95, &80C41
ShareFS: &40, &4B, &4C, &4F &73, &7D &80, &95, &96, &9F, &B0, &801C1
LanManFS: &40, &60, &9D &9F, &A0, &B0, &80C41
AppleTalk: &40, &9D &A0, &A1; &A2, &42680
Værktøjskassen: &11, &53, &60, &73, &87, &92
Vindue: &46, &49, &60, &80, &A5, &44EC0, &44EC1, &44EC2, &44EC3
Menu: &60, &44EC0, &44EC1, &44EC2, &44EC3
Iconbar: &60, &44EC1, &44EC2, &44EC3
ColourDbox: &60, &44EC0, &44EC1, &44EC2, &44EC3
ColourMenu: &60, &44EC0, &44EC1, &44EC2, &44EC3
DCS: &60, &44EC1, &44EC2, &44EC3
FileInfo: &60, &44EC1, &44EC2, &44EC3
FontDbox: &60, &6E, &44EC1, &44EC2, &44EC3
FontMenu: &60, &44EC0, &44EC1, &44EC2, &44EC3
PrintDbox: &60, &44EC1, &44EC2, &44EC3
ProgInfo: &60, &44EC1, &44EC2, &44EC3
SaveAs: &60, &44EC1, &44EC2, &44EC3
Skala: &60, &44EC1, &44EC2, &44EC3
GDivider: &60, &82881
ToolAction: &46, &60, &82881
TextGadgets: &46, &5D, &44EC6, &82881
ImageFileGadget: &46, &5D, &60, &44EC6, &82881
CDFSResources: &60
CDFSSoftATAPI: &42680
LegacyBBC: &4
LegacyScreen: &46, &DE
BBCEconet: * &27
OwnerBanner: &7C &CF
!Alarm: &60
LibraryHelp: &D6
RPCEmuHostFS: &40
RPCEmuHostFSFiler: &27, &4B, &4C, &4F
VProtect: Dunno? &059f168c på 0225f1cc, offset &00000678
VProtect: ? &49, &7C &4A, &27, &7, &400, &C0FFEE, &DECAFF
BootLog: &49
ErrorLog: &400C0, &400C2, &42680
ROMPatch: &45
AcornURI: &27, &49, &4A, &53
AMPlayer: &54, &80, &92
LineEditor: * &53, &27
WimpSWIVe: * &27
NoCoverIB: - 
Tiler: &7C
StartBanner: &7C
TransTIFF: * &8004C
!StrongHelp: * &40, &11
ZapRedraw: * &46
!Zap: &27, &49, &4A, &53, &7F
ControlAMPlayer: &87, &89, &52E00
AcornSSL: &83E01
MIDI: * &45, &27, &54
MIDISynthesiser: * &58

Hvor:
* angiver en række tjenester, som blev afkodet fra den handling, ikke den Ursula modul bordet.
- indikerer et tomt service handler.
? angiver en unparsable service handler.

Den eneste “unparsable’ modul i ovenstående dump er VProtect, som er en ganske kompliceret service indrejse rækkefølge – og at jeg bevidst forsøger ikke at støtte, fordi det er en af de sværere sager, og alle de andre moduler, som jeg prøvede fungerede fint.

Bare om alle ROM-moduler, og de fleste af støtte moduler, er blevet opdateret til det nye format, ved at kontrollere med værktøjet. En anden lille feature, at værktøjet understøttes var at filtrere efter nummer. Dette betød, at du kan give et nummer til det, og det ville kun rapport hjemmehørende moduler, der håndteres på, at service – nyttige for at indsnævre omfanget af et problem.

ROMEdit

Application ikonet for !ROMEdit
!ROMEdit

Opbygning af en ROM, blot fordi du ønsker at tilføje et par nye moduler til test, eller for at deaktivere noget, der ikke helt fungerer for dig, er ret frustrerende. I løbet af de senere 32bit arbejde der var en hel del gange, når det var virkelig praktisk at have et test-værktøj til rådighed i ROM – især når du ikke har en disk eller netværk med henblik på at få programmet i (jeg brugte serielt input nogle af tid til at få fat i et program, der hurtigt, men at have det i ROM, klar til brug, blev en hel del lettere).

Vælg Omkring 3, mens man arbejder på den BuildROM værktøj, skrev jeg en kammerat værktøj, !ROMEdit. Dette var et skrivebord og kommandolinje-værktøj, der lader dig tage et ROM image, ændre indholdet og gemme det til en ny fil. Moduler, der kan fjernes eller tilføjes, programmer eller bibliotek værktøjer, der kan være tilføjet til ResourceFS, og Kernel kan erstattes – det var før den SystemInit post havde været tilføjet (selv om det ville være rimeligt trivielt at tilføje understøttelse for SystemInit udskiftning).

desktop værktøj lader dig se alle de nyttige indholdet af ROM, og gemme det igen, eller du kan gemme en “Stat” – fil, som beskrevet i den aktuelle konfiguration. Den konfigurationsfil kan derefter indlæses tilbage i at reproducere de samme ændringer, eller redigeres manuelt at foretage små ændringer.

et eksempel på En stat-fil, der blev liggende:

 

# ROMEdit stat-fil
# Syntax:
# ROM <fil>
# - vælg ROM til at arbejde med
# Udelad <modul navn>
# - force et modul til at blive fjernet fra ROM
# AddMod <fil>
# tilføje et modul til ROM
# AddLib <fil>
# - tilføj et bibliotek fil til Bibliotek ressourcer
# AddApp <dir/app>
# tilføje et program eller en mappe til Apps ressourcer
# ReplaceKernel <fil>
# - SReplace kernen i billedet
# Gem <fil>
# - gemme det resulterende billede til en fil
# SaveSquashed <fil>
# - gemme det resulterende billede til en fil i komprimeret form
ROM ADFS::Virginia.$.!Boot.Softload.Adjust1i2
Udelad IconBorderRound
Udelad Network
Udelad LibraryHelp
AddApp Dele::ROMEdit.$.!ROMEdit
AddLib Dele::ROMEdit.$.ROMEdit
AddMod ADFS::Virginia.$.Byg.RISCOS.Kilder.HWSupport.Joysticket.rm.Joystick
Spar ADFS::Virginia.$.!Boot.Softload.ROM

kommandolinje-versionen var nyttigt, fordi det kan bruges til at give hurtige ændringer pålideligt, og det kan bruges under Linux til at ændre ROM-let (omend kompression var ikke anvendes i dette tilfælde). Værktøjet var meget nyttig til hurtig tur rundt, når man arbejder med den 32 bit version i QEmu.

EN ROM indlæst i ROMEdit af
Ændre konfigurationen af en ROM var temmelig simpel, bare kryds i et modul for at deaktivere den.
Update: 2013-07-12Anja Skrba har givet en Serbo-Croation oversættelse på denne side. Det er ganske pænt! Tak!