Please note, this is a STATIC archive of website developer.mozilla.org from 03 Nov 2016, cach3.com does not collect or store any user information, there is no "phishing" involved.

 

Czym jest chrome?

Chrome to zestaw elementów interfejsu użytkownika, które znajdują się poza obszarem treści okna. Paski narzędzi, paski menu, paski postępu i pola tytułu okna to przykłady elementów, które są zazwyczaj elementami chrome.

Dostawcy chrome

Jednostka dostarczająca chrome dla danego okna (np. dla okna przeglądarki) nazywana jest dostawcą chrome (ang. chrome provider). Dostawcy pracują wspólnie, aby dostarczyć pełny zestaw chrome dla danego typu okna, od obrazków na paskach narzędziowych po pliki zawierające ciągi znakowe, treść oraz opis prezentacji samego okna.

Są trzy podstawowe typy dostawców chrome:

Zawartość (ang. Content)

Główne źródła plików do opisu okna pochodzą z dostawcy zawartości i może to być dowolny plik, który może zostać wyświetlony w Mozilli. Będzie to zazwyczaj plik XUL, ponieważ język XUL jest stworzony do opisywania zawartości okien i okienek dialogowych. Pliki JavaScript opisujące interfejs użytkownika oraz pliki wiążące XBL również są trzymane w pakietach zawartości.

Pliki lokalizacyjne (ang. Locale)

Aplikacje, które można zlokalizować trzymają wszystkie lokalizowane informacje w dostawcy tekstów. To pozwala tłumaczom dołączać zewnętrzną paczkę chrome z tłumaczeniem aplikacji, bez potrzeby dotykania reszty kodu. Dwoma podstawowymi rodzajami plików tłumaczeń są pliki DTD oraz pliki własności znane z Javy.

Skórki (ang. Skin)

Dostawca skórek jest odpowiedzialny za dostarczanie pełnego zestawu plików opisujących wygląd chrome. Zazwyczaj dostawca skórek dostarcza pliki CSS i obrazki.

Rejestr chrome

Środowisko Gecko zarządza serwisem znanym jako rejestr chrome, który dostarcza mapowanie nazw z przestrzeni chrome na fizyczne lokalizacje pakietów chrome na dysku.

Rejestr chrome jest konfigurowalny i trwały, dzięki czemu użytkownik może instalować różnych dostawców chrome i używać preferowanej skórki lub języka. Ten proces jest dokonywany poprzez XPInstall oraz menedżer rozszerzeń.

W celu informowania rejestru chrome o dostępności chrome używany jest tekst manifestu (ang. text manifest): ten plik nosi nazwę "chrome.manifest" i jest trzymany w korzeniu rozszerzenia lub motywu, oraz chrome/*.manifest w aplikacji XULRunnera.

Manifest chrome w postaci czystego tekstu ma prostą postać liniową. Każda linia jest przetwarzana niezależnie; jeżeli linia nadaje się do przetworzenia, rejestry chrome wykonują akcję określoną przez tę linię; w przeciwnym wypadku, rejestry chrome ignorują ją (oraz wypisują ostrzeżenie w konsoli błędów).

locale nazwapakietu nazwajezyka sciezka/do/pliku
skin nazwapakietu nazwaskorki sciezka/do/pliku

Instrukcje manifestu

Komentarze

Możemy wprowadzić linię komentarza zaczynając komentarz znakiem '#'. Jakiekolwiek inne znaki w tej linii zostaną zignorowane.

# to jest linia komentarza - możemy ją umieścić w każdym miejscu

zawartość (content)

Zawartość pakietu jest rejestrowana poprzez linię

contentnazwapakietuuri/do/plików/[flagi]

Taka linia zarejestruje położenie podczas odtwarzania ścieżki chrome:// nazwapakietu /content/... . URI może być względną lub bezwzględną ścieżką do pliku manifestu.

pliki językowe (locale)

Pakiet językowy jest rejestrowany poprzez linię

localenazwapakietunazwajęzykauri/do/plików/[flagi]

Taka linia zarejestruje pakiet językowy przy odtwarzaniu ścieżki chrome:// nazwapakietu /locale/... . nazwajęzyka jest zazwyczaj identyfikatorem języka jak "pl" lub identyfikatorem typu język-kraj jak "pt-BR". Jeżeli dla danego pakietu zarejestrowany jest więcej niż jeden pakiet językowy, rejestr chrome wybierze najbardziej pasujący do preferencji użytkownika.

skórki (skin)

Pakiet skórek jest rejestrowany poprzez linię

skinnazwapakietunazwaskorkiuri/do/plików/[flagi]

Taka linia zarejestruje pakiet skórek przy odtwarzaniu ścieżki chrome:// nazwapakietu /skin/... . nazwaskorki jest zazwyczaj identyfikatorem określającym instalowaną skórkę. Jeżeli dla danego pakietu zarejestrowany jest więcej niż jeden pakiet skórek, rejestr chrome wybierze najbardziej pasujący do preferencji użytkownika.

Nakładki (overlays)

Nakładki XUL są rejestrowane przy użyciu poniższej składni:

overlay chrome://URI-do-pliku-nakładki chrome://URI-nakładki[flagi]

style

Nakładki stylów (własne pliki CSS, które będą nakładane na strony chrome) są rejestrowane przy użyciu poniższej składni:

style chrome://URI-do-pliku chrome://URI-arkusza-stylów

nadpisywanie (override)

W pewnych przypadkach rozszerzenia mogą chcieć nadpisać pliki chrome dołączone do aplikacji lub XulRunnera. Aby to zrobić, należy skorzystać z instrukcji "override" w pliku manifestu:

override chrome://pakiet/typ/original-uri.whatevernew-resolved-URI

Flagi manifestu

Linie manifestu mogą mieć flagi dodane na końcu linii rejestracji. Te flagi oznaczają specjalne atrybuty, lub ograniczają warunki w których dana linia zostanie użyta.

aplikacja (application)

Rozszerzenia mogą być instalowane jako wiele aplikacji. Mogą istnieć linie rejestracyjne chrome, które dotyczą tylko wybranych aplikacji. Flaga

application=app-ID

określa, że ta instrukcja ma dotyczyć wyłącznie rozszerzeń instalowanych w aplikacji określonej przez app-ID . Można określić wiele flag aplikacji w jednej linii, i w tym wypadku linia zostanie wykonana, jeśli którakolwiek z nich będzie pasować.

appversion

Rozszerzenia mogą być instalowane w wielu wersjach aplikacji. Można stworzyć linie rejestracji chrome, które będą dotyczyły tylko wybranych wersji aplikacji. Flaga

appversion=version
appversion<version
appversion<=version
appversion>version
appversion>=version

określa, że instrukcja ma dotyczyć wyłącznie, jeżeli rozszerzenie jest instalowane w aplikacji o pasującej wersji. Można określić wiele flag appversion w jednej linii, i w tym wypadku linia zostanie wykonana, jeśli którakolwiek z nich będzie pasować.

platform (Pakiety dotyczące platformy)

Niektóre pakiety posiadają specjalną flagę oznaczającą, że dany pakiet jest dla konkretnej platformy. Niektóre elementy zawartości, skórki, tekstów mogą być różne zależnie od platformy, na której aplikacja została uruchomiona. Te pakiety posiadają trzy różne zestawy plików, dla windows/os2, macintosha oraz platform uniksowych. Na przykład kolejność przycisków "OK" i "anuluj" w okienkach dialogowych jest różna, tak samo jak nazwy niektórych elementów. Modyfikator "platformy" jest przetwarzany tylko dla rejestracji zawartości, nie jest używany przy rejestracji pakietów językowych lub skórek.

Aby oznaczyć, że dany pakiet zawartości jest przeznaczony dla konkretnej platformy, należy dodać flagę "platform" za ścieżką; np.

content global-platform jar:toolkit.jar!/toolkit/content/global-platform/ platform

Mając to zdefiniowane w pliku manifestu, należy się upewnić, że w w katalogu global-platform znajdują się podkatalogi win (Windows/OS2), mac (OS9/OSX), lub unix (Wszystko inne). Wszystko, co znajduje się poza tymi podkatalogami, zostanie zignorowane.

xpcnativewrappers

Pakiety chrome mogą decydować, czy chcą użyć mechanizmu bezpieczeństwa xpcnativewrappers, aby chronić swój kod przed nieuprawnionym dostępem do treści. Zajrzyj do Bezpieczny dostęp do zawartości DOM z chrome po więcej szczegółów.

W wydaniu Firefox 1.5 alpha (Deer Park alpha), ta flaga jest *wyłączona* domyślnie i musi zostać ręcznie włączona poprzez ustawienie xpcnativewrappers=yes.

Od pierwszego wydania Firefox 1.5 beta, ta flaga będzie domyślnie włączona i rozszerzenia potrzebujące niebezpiecznego dostępu do zawartości obiektów będą musiały ustawić xpcnativewrappers=no.

Flaga xpcnativewrappers dotyczy tylko pakietu content: nie jest rozpoznawana w rejestrach locali ani skórek.

Przykładowy Manifest Chrome

content       necko                   jar:comm.jar!/content/necko/ xpcnativewrappers=yes
locale	       necko       en-US       jar:en-US.jar!/locale/en-US/necko/
content       xbl-marquee             jar:comm.jar!/content/xbl-marquee/
content       pipnss                  jar:pipnss.jar!/content/pipnss/
locale        pipnss      en-US       jar:en-US.jar!/locale/en-US/pipnss/
# Firefox-only
overlay chrome://browser/content/pageInfo.xul           chrome://pippki/content/PageInfoOverlay.xul application={ec8030f7-c20a-464f-9b0e-13a3a9e97384}
overlay chrome://communicator/content/pref/preftree.xul chrome://pippki/content/PrefOverlay.xul
overlay chrome://navigator/content/pageInfo.xul         chrome://pippki/content/PageInfoOverlay.xul [email protected]
content       pippki                  jar:pippki.jar!/content/pippki/ xpcnativewrappers=yes
locale        pippki      en-US       jar:en-US.jar!/locale/en-US/pippki/
content       global-platform         jar:toolkit.jar!/content/global-platform/ platform
skin          global      classic/1.0 jar:classic.jar!/skin/classic/global/
override chrome://global/content/netError.xhtml jar:embedder.jar!/global/content/netError.xhtml
content       inspector               jar:inspector.jar!/content/inspector/ xpcnativewrappers=no

Manifesty starego typu contents.rdf

Zanim manifesty czysto tekstowe zostały wprowadzone (nastąpiło to w Firefoksie 1.5, Toolkit 1.8), używane były manifesty RDF nazywane "contents.rdf". Ten format jest teraz wycofywany; jednakże, Mozilla suite (Seamonkey) nie obsługuje jeszcze manifestów czysto tekstowych, więc manifesty contents.rdf są wymagane dla rozszerzeń, które chcą zachować wsteczną zgodność z Firefoksem 1.0 oraz suite.

Oficjalne dokumentacje dla Toolkit API

Official References. Do not add to this list without contacting Benjamin Smedberg. Note that this page is included from the pages listed below. So: Don't Add Breadcrumbs!

 

 

Autorzy i etykiety dokumentu

Etykiety: 
 Autorzy tej strony: teoli, Zwierz, Mgjbot, Verruckt, Ptak82, Takenbot, gandalf, Witia, Dria, Anonymous
 Ostatnia aktualizacja: teoli,