diff options
Diffstat (limited to 'files/pt-pt/mozilla/add-ons')
13 files changed, 0 insertions, 1431 deletions
diff --git a/files/pt-pt/mozilla/add-ons/amo/index.html b/files/pt-pt/mozilla/add-ons/amo/index.html deleted file mode 100644 index 3857ed65ca..0000000000 --- a/files/pt-pt/mozilla/add-ons/amo/index.html +++ /dev/null @@ -1,9 +0,0 @@ ---- -title: AMO -slug: Mozilla/Add-ons/AMO -tags: - - NeedsTranslation - - TopicStub -translation_of: Mozilla/Add-ons/AMO ---- -<p>Content to be added.</p> diff --git a/files/pt-pt/mozilla/add-ons/amo/policy/em_destaque/index.html b/files/pt-pt/mozilla/add-ons/amo/policy/em_destaque/index.html deleted file mode 100644 index 71eafffe67..0000000000 --- a/files/pt-pt/mozilla/add-ons/amo/policy/em_destaque/index.html +++ /dev/null @@ -1,85 +0,0 @@ ---- -title: AMO - Políticas de Extensões em Destaque -slug: Mozilla/Add-ons/AMO/Policy/Em_destaque -translation_of: Mozilla/Add-ons/AMO/Policy/Featured ---- -<p>{{AddonSidebar}}</p> - -<p>Featured add-ons are top-quality extensions and themes highlighted on <a href="https://addons.mozilla.org/en-US/firefox/extensions/?sort=featured">AMO</a>, Firefox's Add-ons Manager, and across other Mozilla websites. These add-ons showcase the power of Firefox customization and are useful to a wide audience.</p> - -<p>Featured extensions are chosen by the Featured Extensions Advisory Board, a small group of extension developers and fans from the Mozilla community who have volunteered to review and vote on nominations.</p> - -<p>Todos os meses, são escolhidas novas <a href="https://addons.mozilla.org/pt-PT/firefox/search/?featured=true&type=extension">extensões em destaque</a>.</p> - -<h3 id="Critérios_para_Extensões_em_Destaque">Critérios para Extensões em Destaque</h3> - -<p>Before nominating an extension to be featured, please ensure it meets the following criteria:</p> - -<ol> - <li>The extension must have a complete and informative listing on AMO. This means: - <ul> - <li>a 64-pixel custom icon</li> - <li>a clear and concise name (no lengthy keywords)</li> - <li>a clear and concise summary of the extension's functionality</li> - <li>detailed description and privacy policy, if applicable</li> - <li>updated screenshots of the extension's functionality</li> - </ul> - </li> - <li>The extension must have excellent user reviews and any problems or support requests must be promptly addressed by the developer.</li> - <li>The extension must have a minimum of 500 users.</li> - <li>The extension must be built with <a href="https://developer.mozilla.org/Add-ons/WebExtensions">WebExtensions</a> API.</li> - <li>The extension must be compatible with the latest release of Firefox.</li> - <li><strong>Most importantly</strong>, the extension must have wide consumer appeal to Firefox's users and be outstanding in nearly every way: user experience, performance, security, and usefulness or entertainment value.</li> -</ol> - -<h3 id="Painel_de_Descoberta">Painel de Descoberta</h3> - -<p>The Get Add-ons section (also referred to as the Discovery Pane) in about:addons serves a distinct editorial function: it is a tightly curated list of extensions and themes selected by Mozilla staff to address an array of the most common user needs (e.g. ad blockers, screenshot tools, etc.). The Discovery Pane is primarily intended to introduce extensions to Firefox users who have limited experience with browser customization. As such, we only select extensions that meet the highest standards of functionality, user experience, and Firefox compatibility.</p> - -<p>Only content that is part of AMO’s <a class="external text" href="https://addons.mozilla.org/en-US/firefox/search/?featured=true&type=extension" rel="nofollow">Featured Extensions collection</a> will be considered for the Discovery Pane; please note that featured content must meet certain <a href="https://wiki.mozilla.org/AMO/Featured_Board_Process#Add-on_Requirements" title="AMO/Featured Board Process">criteria</a>.</p> - -<p>Discovery Pane content is updated monthly, though some highly popular extensions may remain on the page for an indefinite period of time.</p> - -<p>If you’d like to nominate a great extensions for consideration in the Discovery Pane, please send us a link to the add-on on AMO to <strong>amo-featured@mozilla.org</strong> and we’ll add your nomination to the editorial review queue. There’s no need to mention you’re nominating add-ons specifically for the Discovery Pane, but feel free to note that if you like.</p> - -<h3 id="Nomear_um_Extra">Nomear um Extra</h3> - -<p>If you wish to nominate an extension to be featured and it meets the criteria above, send an email to <a href="mailto:amo-featured@mozilla.org">amo-featured@mozilla.org</a> with:</p> - -<ul> - <li>the extension name, URL, and whether you are its developer</li> - <li>a short explanation of why the extension has wide appeal and should be featured</li> - <li>optionally, links to any external reviews or articles mentioning the extension</li> -</ul> - -<p>Extension nominations are reviewed by the Advisory Board once a month. Common reasons for rejection include lacking wide appeal to consumers, a suboptimal user experience, quality or security issues, incompatibility, and similarity to another featured extension. Rejected extension cannot be re-nominated within 3 months.</p> - -<h3 id="Rodar_Extensões_em_Destaque">Rodar Extensões em Destaque</h3> - -<p>Mozilla and the Featured Extensions Advisory Board regularly evaluate and rotate out featured extensions. Some of the most common reasons for extensions being removed from the featured list are:</p> - -<ul> - <li>Lack of growth — Extensions that are featured typically experience a substantial gain in both downloads and active users. If an extension is not demonstrating growth in any substantial way, that's a good indicator the extension may not be very useful to our users.</li> - <li>Negative reviews — Featured extensions should have a great experience and very few bugs, so extensions with many negative reviews may be reconsidered.</li> - <li>Incompatibility with upcoming Firefox versions — Featured extensions are expected to be compatible with stable and beta versions of Firefox. Extensions not yet compatible with a Beta version of Firefox four weeks before its expected release will lose their featured status.</li> -</ul> - -<h3 id="Aderir_ao_Conselho_Consultivo_de_Extensões_em_Destaque">Aderir ao Conselho Consultivo de Extensões em Destaque</h3> - -<p>Every six months a new Advisory Board is chosen based on applications from the add-ons community. Members must:</p> - -<ul> - <li>be active members of the add-ons community, whether as a developer, evangelist, or fan</li> - <li>commit to trying all the nominations submitted, giving their feedback, and casting their votes every month</li> - <li>abstain from voting on extensions that they have any business or personal affiliations with, as well as direct competitors of any such extensions</li> -</ul> - -<p>Members of the Mozilla Add-ons team may veto any extension's selection because of security, privacy, compatibility, or any other reason, but in general it is up to the Board to select extensions to feature.</p> - -<p>This featured policy only applies to the addons.mozilla.org global list of featured extensions. Extensions featured in other locations are often pulled from this list, but Mozilla may feature any extension in other locations without the Board's consent. Additionally, locale-specific features override the global defaults, so if a locale has opted to select its own features, some or all of the global features may not appear in that locale.</p> - -<p>Follow the <a href="http://blog.mozilla.com/addons">Add-ons Blog</a> or <a href="http://www.twitter.com/mozamo">@mozamo</a> on Twitter to learn when the next application period opens.</p> - -<p><em>Última atualização: 12 de abril de 2018</em></p> - -<p><span class="comment seoSummary">How up-and-coming add-ons become featured and what's involved in the process. </span></p> diff --git a/files/pt-pt/mozilla/add-ons/amo/policy/index.html b/files/pt-pt/mozilla/add-ons/amo/policy/index.html deleted file mode 100644 index 2dd894f5bd..0000000000 --- a/files/pt-pt/mozilla/add-ons/amo/policy/index.html +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: Políticas AMO -slug: Mozilla/Add-ons/AMO/Policy -tags: - - NeedsTranslation - - TopicStub -translation_of: Mozilla/Add-ons/AMO/Policy ---- -<p>Mozilla está empenhada em garantir uma grande experiência com os extras para os nossos utilizadores e desenvolvedores. Por favor, reveja as políticas abaixo antes de submeter o seu extra.</p> - -<dl> - <dd></dd><dt><a href="/Mozilla/Add-ons/AMO/Policy/Agreement">Developer Agreement</a></dt> -<dd>Effective January 5, 2016</dd> <dt><a href="/Mozilla/Add-ons/AMO/Policy/Reviews">Review Process</a></dt> -<dd>Add-ons extend the core capabilities of Firefox, allowing users to modify and personalize their Web experience. A healthy add-on ecosystem, built on trust, is vital for developers to be successful and users to feel safe making Firefox their own. For these reasons, Mozilla requires all add-ons to comply with the following set of policies on acceptable practices. The below is not intended to serve as legal advice, nor is it intended to serve as a comprehensive list of terms to include in your add-on’s privacy policy.</dd> <dt><a href="/Mozilla/Add-ons/AMO/Policy/Featured">Featured Add-ons</a></dt> -<dd>How up-and-coming add-ons become featured and what's involved in the process. </dd> <strong><a href="/en-US/Add-ons#Contact_us">Contacting us</a></strong> - - <p> How to get in touch with us regarding these policies or your add-on.</p> - -</dl> diff --git a/files/pt-pt/mozilla/add-ons/amo/policy/revisões/index.html b/files/pt-pt/mozilla/add-ons/amo/policy/revisões/index.html deleted file mode 100644 index 96e6d880f5..0000000000 --- a/files/pt-pt/mozilla/add-ons/amo/policy/revisões/index.html +++ /dev/null @@ -1,160 +0,0 @@ ---- -title: Políticas de Extras -slug: Mozilla/Add-ons/AMO/Policy/Revisões -tags: - - Extras - - Política de Revisão -translation_of: Mozilla/Add-ons/AMO/Policy/Reviews ---- -<p>{{AddonSidebar}}</p> - -<p>Os extras estendem os recursos principais do Firefox, permitindo que os utilizadores modifiquem e personalizem a sua experiência na Web. Um ecossistema de extras saudável, baseado na confiança, é vital para que os programadores sejam bem-sucedidos e os utilizadores se sintam seguros, tornando o Firefox deles próprio. Por estes motivos, a Mozilla requer que todos os extras estejam em conformidade com o seguinte conjunto de políticas sobre as práticas aceitáveis. O abaixo, não se destina para servir como aconselhamento jurídico, nem pretende servir como uma lista abrangente de termos para incluir na política de privacidade do seu extra.</p> - -<p>Todos os extras estão sujeitos a estas políticas, independentemente de como eles são distribuídos. Os extras que não estejam em conformidade com estas políticas podem estar sujeitos à rejeição ou desativação pela Mozilla.</p> - -<h2 id="Sem_Surpresas">Sem Surpresas</h2> - -<p>As surpresas podem ser apropriadas em muitas situações, mas não são bem-vindas quando a segurança, a privacidade e o controlo do utilizador estão em jogo. É extremamente importante ser o mais transparente possível quando submeter um extra. Os utilizadores deverão ser capazes de discernir facilmente qual é a funcionalidade do seu extra e não receber experiências inesperadas do utilizador depois de o instalal.</p> - -<h3 id="Funcionalidades_Inesperadas">Funcionalidades Inesperadas</h3> - -<p>“Funcionalidades" inesperadas são aquelas que não estão relacionadas com a função principal do extra e provavelmente não são do nome do extra ou da descrição esperada por um utilizador que está a instalar esse extra.</p> - -<p>Um extra deveria incluir qualquer funcionalidade inesperada que se enquadre numa das seguintes categorias:</p> - -<ul> - <li>Potencialmente compromete a privacidade ou a segurança do utilizador (tal como enviar dados para terceiros)</li> - <li>Altera as definições predefinidas, tal como o novo separador, a página inicial ou o motor de pesquisa</li> - <li>Faz alterações inesperadas no navegador ou no conteúdo da Web</li> - <li>Inclui recursos ou funcionalidades não relacionadas com as funções principais do extra</li> -</ul> - -<p>Então, a(s) funcionalidade(s) "inesperada(s)" devem seguir todos os seguintes requisitos:</p> - -<ul> - <li>A descrição do extra deve indicar claramente quais as alterações que o extra efetua.</li> - <li>Todas as alterações devem ser "opcionais", o que significa que o utilziador deve executar uma ação não predefinida para aprovar a alteração. As alterações que solicitam aos utilizadores por meio do sistema de permissões não requerem uma opção adicional.</li> - <li>A interface de opções deve declarar claramente o nome do extra que está a solicitar a alteração.</li> -</ul> - -<h2 id="Conteúdo">Conteúdo</h2> - -<p>Os extras que utilizarem as marcas registadas da Mozilla devem obedecer à <a href="https://www.mozilla.org/en-US/foundation/trademarks/policy/">Política de Marcas Registadas da Mozilla</a>. Se o extra utiliza “Firefox” no seu nome, o padrão de nomeação que o extra deve seguir é “<nome do Extra> por Firefox”.</p> - -<p>Além disso, os extras listados em <a href="https://addons.mozilla.org/pt-PT/firefox/">Extras para o Firefox</a> (AMO) devem seguir as seguintes políticas:</p> - -<ul> - <li>All add-ons submitted for listing on AMO are subject to Mozilla’s <a href="https://www.mozilla.org/en-US/about/legal/acceptable-use/">Conditions of Use</a>.</li> - <li>Add-ons must disclose when payment is required to enable any functionality.</li> - <li>Any add-ons, or add-on content, hosted on Mozilla site(s) must conform to the laws of the United States.</li> - <li>The add-on listing should have an easy-to-read description about everything it does, and any information it collects. Please consult our best practices guide for <a href="https://developer.mozilla.org/en-US/Add-ons/Listing">creating an appealing listing</a>.</li> - <li>Add-ons that are intended for internal or private use, or for distribution testing may not be listed on AMO. Such add-ons may be <a href="https://developer.mozilla.org/en-US/Add-ons/Distribution#Self-distributed_(unlisted)_versions">uploaded for self-distribution</a> instead.</li> - <li>If the add-on is a fork of another add-on, the name must clearly distinguish it from the original and provide a significant difference in functionality and/or code.</li> -</ul> - -<h2 id="Linhas_Diretrizes_de_Submissão">Linhas Diretrizes de Submissão</h2> - -<p>Os extras devem funcionar apenas conforme o descrito e devem fornecer uma experiência de utilizador atraente. Com base na descrição do extra, um utilizador deve ser capaz de entender e utilizar os recursos do extra sem exigir conhecimento especializado. Dicas sobre como criar uma boa experiência do utilziador para o seu extra podem ser encontradas <a href="/pt-PT/Add-ons/WebExtensions/As_melhores_praticas_de_experiencia_do_utilizador">aqui</a>.</p> - -<p>During review, the add-on undergoes basic testing in addition to code review. To facilitate the functional testing, the add-on author must provide testing information and, if applicable, testing credentials required to use the add-on if an account is needed for any part of the add-on’s functionality.</p> - -<p>Issues brought up during review must be addressed using best efforts. If corrections have been requested, the new version should not contain unrelated changes, as this complicates the review process and can lead to further rejections.</p> - -<h3 id="Submissão_de_Código_Fonte">Submissão de Código Fonte</h3> - -<p>Add-ons may contain transpiled, obfuscated, minified or otherwise machine-generated code, but Mozilla needs to review a copy of the human-readable source code. The author must provide this information to Mozilla during submission as well as instructions on how to reproduce the build.</p> - -<p>The provided source code will be reviewed by an administrator and will not be redistributed in any way. The code will only be used for the purpose of reviewing the add-on. Failure to provide this information will result in rejection.</p> - -<p>Please read our <a href="https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Source_Code_Submission">Source Code Submission guidelines</a> to avoid unexpected rejections.</p> - -<h2 id="Práticas_de_Desenvolvimento">Práticas de Desenvolvimento</h2> - -<p>In general, developers are free to maintain their add-ons in the manner they choose. However, in order to maintain appropriate data security and effectively review code, we do have certain technical requirements that all add-ons must meet. In particular, potentially dangerous APIs may only be used in ways that are demonstrably safe, and code within add-ons that cannot be verified as behaving safely and correctly may need to be refactored.</p> - -<p>While any code, method or practice in a submitted add-on is subject to review and rejection, the following requirements are of particular importance:</p> - -<ul> - <li>Add-ons must only request those permissions that are necessary for function</li> - <li>Add-ons must be self-contained and not load remote code for execution</li> - <li>Add-ons must use encrypted channels for sending sensitive user data</li> - <li>Add-ons should avoid including duplicate or unnecessary files</li> - <li>Add-on code must be written in a way that is reviewable and understandable. Reviewers may ask you to refactor parts of the code if it is not reviewable.</li> - <li>Add-ons must not negatively impact the performance or stability of Firefox.</li> - <li>Only release versions of third-party libraries and/or frameworks may be included with an add-on. Modifications to these libraries/frameworks are not permitted.</li> -</ul> - -<h2 id="Gestão_Recolha_e_Divulgação_de_Dados">Gestão, Recolha e Divulgação de Dados</h2> - -<p>You must disclose how the add-on collects, uses, stores and shares user data in the privacy policy field on AMO. Mozilla expects that the add-on limits data collection whenever possible, in keeping with Mozilla’s <a href="https://www.mozilla.org/en-US/about/policy/lean-data/">Lean Data Practices</a> and Mozilla’s <a href="https://www.mozilla.org/en-US/privacy/principles/">Data Privacy Principles</a>, and uses the data only for the purpose for which it was originally collected.</p> - -<p>User data includes all information the add-on collects, regardless of the manner. It can be personal data actively provided by the user (such as a name or email address), technical data (such as operating system, build ID, version numbers, crash reports, activation, updates), and interaction or activity data (add-on activity data, visited URLs, console logs), including interactions with Firefox.</p> - -<p>The add-on’s privacy policy must be the full policy text; it cannot be a link to an externally hosted privacy policy. In addition, the privacy policy must:</p> - -<ul> - <li>be specific and exclusive to the add-on,</li> - <li>clearly describe the purpose of the data collection,</li> - <li>set forth the exact data to be collected,</li> - <li>address the add-on’s particular privacy properties.</li> -</ul> - -<p>A summary of this information must be included in the add-on’s listing description. Finally, you and your add-on must also comply with all applicable data privacy laws as well as any other laws that may apply to your specific add-on.</p> - -<h3 id="Interações_do_Utilizador_e_Dados_Técnicos">Interações do Utilizador e Dados Técnicos</h3> - -<ul> - <li>Users must be provided a clear way to control this data collection. The control mechanism must be shown during the installation process of the add-on.</li> - <li>Add-ons must only collect information about add-on performance and/or use.</li> - <li>Collecting ancillary information (e.g. any data not explicitly required for the add-on’s basic functionality) is prohibited.</li> -</ul> - -<h3 id="Cookies">Cookies</h3> - -<ul> - <li>If your add-on installs cookies, this must also be disclosed in the add-on’s privacy policy.</li> - <li>The add-on privacy policy must clearly express the placing and purposes of the cookie(s). It is highly recommended that you disclose the types of cookies being used.</li> - <li>Users must be provided an opportunity to refuse the storage of or access to cookies, and must be informed of the consequences of doing so (e.g., without a functional cookie, the add-on may not work).</li> - <li>Installing cookies that are not explicitly required for the add-on’s functionality is prohibited.</li> -</ul> - -<h3 id="Dados_Pessoais">Dados Pessoais</h3> - -<ul> - <li>If you are collecting any personal information, the users must provide affirmative consent (i.e., explicit opt-in from the user). It must be clear to the user that they give consent to the collection of personal data.</li> - <li>Collecting ancillary personal information (e.g., any data not explicitly required for the add-on’s basic functionality) is prohibited.</li> - <li>Any transmission of this type of data must use secure, encrypted connections.</li> -</ul> - -<h3 id="Protocolos_de_Privacidade_Adicionais">Protocolos de Privacidade Adicionais</h3> - -<ul> - <li>Leaking local or user-sensitive information to websites or other processes (e.g., using native messaging) is prohibited.</li> - <li>If the add-on uses native messaging, the privacy policy must clearly disclose which information is being exchanged with the native application. Data exchanged with the native application must be in accordance with our No Surprises policy.</li> - <li>HTTPS must be used for security and privacy-sensitive operations such as transmitting passwords or tokens.</li> - <li>Browsing data from private browsing sessions must not be stored.</li> - <li>Identity information must not be leaked to web content in private browsing sessions.</li> -</ul> - -<h2 id="Vulnerabilidades_de_Segurança">Vulnerabilidades de Segurança</h2> - -<p>Because add-ons run in an environment with elevated privileges relative to ordinary web pages, they present a very serious set of security considerations. They have the potential to open security holes not only in the add-ons themselves, but also in the browser, in web pages, and, in particularly distressing cases, the entire system the browser is running on.</p> - -<p>As a result, we take our security policies very seriously and apply them to all add-ons, whether hosted on AMO or not. We expect all add-ons to be secure and well-maintained in handling both their own data and their user’s data. They must also securely manage all of their interactions with the web, the browser and the operating system.</p> - -<h2 id="Monetização">Monetização</h2> - -<ul> - <li>Os mecanismos de monetização devem cumprir com as políticas na secção <em>Divulgação, Recolha e Gestão de Dados</em>. Em particular, um extra deve ser acompanhado de um mecanismo de controle de utilizador claro (e opção para dados pessoais) apresentado durante o processo de instalação ou atualização do extra. A recolha de informação auxiliar para monetização é proibida.</li> - <li>Um extra que injetar publicidade no conteúdo da página da Web deve identificar claramente o conteúdo injetado como originário do extra.</li> - <li>A inclusão de mineiros de criptomoedas ou funcionalidades similares num extra é proibida.</li> - <li>A modificação do conteúdo da Web ou a facilitação de redirecionamentos para incluir etiquetas de promoção de afiliados não é permitida. Por outro lado, a utilização da promoção de afiliação nos elementos da interface do utilizador claramente identificada como pertencentes ao extra é aceitável.</li> -</ul> - -<h2 id="Conformidade_e_Lista_de_Bloqueio">Conformidade e Lista de Bloqueio</h2> - -<p>Para os extras que não correspondem com estas políticas, a Mozilla pode rejeitar ou bloquear as versões afetadas ou extras completos, dependendo da extensão da sua não conformidade.</p> - -<p>Geralmente, a Mozilla tentará entrar em contacto com o(s) programador(es) do extra e fornecer um prazo razoável para que os problemas sejam corrigidos antes que um bloqueio seja implementado. Se um extra for considerado malicioso ou se os seus programadores tiverem se mostrado inalcançáveis ou não responderem, ou no caso de violações recorrentes, a inclusão na listagem de bloqueio ser imediata.</p> - -<p>A Mozilla reserva o direito de bloquear ou eliminar a conta do programador em addons.mozilla.org, evitando assim a utilização adicional do serviço.</p> diff --git a/files/pt-pt/mozilla/add-ons/crição_de_extensões_firefox_com_sistema_mozilla/index.html b/files/pt-pt/mozilla/add-ons/crição_de_extensões_firefox_com_sistema_mozilla/index.html deleted file mode 100644 index 35a9c7fbe1..0000000000 --- a/files/pt-pt/mozilla/add-ons/crição_de_extensões_firefox_com_sistema_mozilla/index.html +++ /dev/null @@ -1,518 +0,0 @@ ---- -title: >- - Criação de extensões personalizadas do Firefox com o sistema de criação da - Mozilla -slug: Mozilla/Add-ons/Crição_de_extensões_Firefox_com_Sistema_Mozilla -translation_of: >- - Archive/Add-ons/Creating_Custom_Firefox_Extensions_with_the_Mozilla_Build_System ---- -<p>{{AddonSidebar}}</p> - -<p>Existe uma <a href="/pt-PT/Add-ons" title="en/Extensions">abundância de material</a> na criação de extensões para Firefox. Todos estes documentos atualmente assumem, contudo, que está a desenvolver a sua extensão utilizando apena <a href="/en/JavaScript" title="en/JavaScript">JavaScript </a>e <a href="/en/XUL" title="en/XUL">XUL</a>. Para extenões complexas, poderá ser necessário criar componentes em C++ que proporcionam uma funcionalidade adicional. Os motivos pelos quais poderá querer incluir componentes C++ na sua extensão incluem:</p> - -<div class="m2"> -<div class="mrg"> -<div class="client" id="baseBody" style=""> -<div id="textContainer" style="DISPLAY: block;"> -<div id="FtxtWnd" style=""> -<div class="targetTxt"> </div> -</div> -</div> -</div> -</div> -</div> - -<ul> - <li>Need for high-performance beyond what can be delivered by JavaScript code.</li> - <li>Use of third-party libraries written in C or C++.</li> - <li>Use of Mozilla interfaces that are not exposed via <a href="/en/XPCOM" title="en/XPCOM">XPCOM</a> (e.g. <a href="/en/NSPR" title="en/NSPR">NSPR</a>).</li> -</ul> - -<div class="note"><strong>Note:</strong> With the modern JIT Javascript Engine in Gecko and <a href="/en/js-ctypes/js-ctypes_reference" title="js-ctypes reference">js-ctypes</a> more extension code can be written only in JavaScript than ever before. Please consider all of your options carefully before deciding to use native code (C++) in your extension. In addition, binary components need to be recompiled for every major Firefox release, which can be frustrating.</div> - -<p>This article describes how to set up the development environment for a large, complex Firefox extension with any or all of the above-mentioned requirements. I should also stress that you do <em>not</em> have to build Mozilla or use the Mozilla build system if you want to create C++ components for Mozilla. If you are just looking to create an <a href="/en/XPCOM" title="en/XPCOM">XPCOM</a> component or two, this is probably overkill, and you might want to take a look at <a class="external" href="http://www.iosart.com/firefox/xpcom/">this guide</a> instead. On the other hand, if you are an experienced developer or team, and you know that you are going to build a large, complex extension, you would do well to consider the approach described in this article.</p> - -<p>One final note: I’ve only tried these techniques inside Firefox, but they’ll probably work more or less unchanged on other Gecko-based platforms like Thunderbird or Seamonkey. If someone can confirm this and/or provide guidelines for what’s different, I’ll update the article to incorporate this information.</p> - -<h3 id="Bambi_Cruza-se_com_Mozilla">Bambi Cruza-se com Mozilla</h3> - -<p>None of this is for the faint of heart. In particular, the initial step involves building Mozilla, which is a huge - nay, gargantuan! - project. Many intelligent developers have been driven to the brink of insanity trying to build it for the first time. If you're not an experienced C++ developer, I wouldn’t even bother. Stick to JavaScript.</p> - -<h4 id="Nas_Plataformas_do_Windows">Nas Plataformas do Windows</h4> - -<p>The first time I built Mozilla I used <a href="/En/Developer_Guide/Build_Instructions/Windows_Prerequisites" title="En/Developer_Guide/Build_Instructions/Windows_Prerequisites">this guide</a>. I can’t even remember why anymore, but I got stuck in a number of places, and the whole affair ended up taking far longer than I originally expected. Much furniture was smashed, much hair torn out by the roots. Here’s a <a class="external" href="http://whereswalden.com/mozilla/msvcfree/">comprehensive looking guide</a> that’s gotten good reviews. Follow every step methodically and you’ll probably be alright. Focus on the fact that once you get the build working, it’ll probably work effortlessly from then on. Maybe.</p> - -<h4 id="Em_Outras_Plataformas">Em Outras Plataformas</h4> - -<p>On other platforms, namely Linux and MacOS, the process is much easier. All the tools for building are available built-in, and therefore all you have to do is run some commands in the terminal. You can find full instructions for almost any OS <a href="/En/Developer_Guide/Build_Instructions" title="En/Developer_Guide/Build_Instructions">here</a>.</p> - -<h3 id="Estruturar_o_Seu_Projeto">Estruturar o Seu Projeto</h3> - -<p>Mozilla includes a number of complex extensions that are integrated into its build process. It has thus been necessary to solve all of the issues involved in creating and registering XPCOM components, building JAR files and manifests, installing the lot into the Firefox <code>extensions/</code> directory and so forth. So it behooves us to piggyback on this infrastructure to build our extension.</p> - -<p>First of all, think of a catchy name for your extension and create a directory with that name under the <code>/mozilla/extensions/</code> directory. Use only lowercase letters. You should see a bunch of other directories (<code>inspector/</code>, <code>reporter/</code> and so forth) at the same level in the build tree.</p> - -<p>Note that before actually building anything, the Mozilla build system invokes a configuration process that generates the actual makefiles used for the build from makefile templates called <code>Makefile.in</code>. The actual makefiles tend to be very similar or identical to the templates, but the extra flexibility gained from having the makefiles generated dynamically is one of the things that makes the build system so powerful.</p> - -<h4 id="Anatomia_de_uma_Extensão_C_Simples">Anatomia de uma Extensão C++ Simples</h4> - -<p>We assume that you are using C++ to write XPCOM components that can be used either from other C++ components or from JavaScript. The process of creating a component is actually relatively straightforward when the Mozilla build system is used.</p> - -<p>In the simplest case, a component will consist of a single main directory with two subdirectories, <code>public/</code> and <code>src/</code>. The main directory and each subdirectory must contain a <code>Makefile.in</code> (from now on I’ll just refer to this file as a makefile although we know that it is actually used to generate the real makefile). This makefile says two things. First of all, it lists the subdirectories that make up the extension, so the build system knows where to look for additional makefiles. Secondly, it instructs the build system to create a new extension, rather than copying the components directly into Firefox’s binary directory. The main advantage of using an extension is that it is easy to package everything up and install it on another machine.</p> - -<p>So here’s your basic, plain-vanilla top-level makefile (<code>Makefile.in</code> in the main extension directory):</p> - -<pre>DEPTH = ../.. -topsrcdir = @top_srcdir@ -srcdir = @srcdir@ -VPATH = @srcdir@ - -include $(DEPTH)/config/autoconf.mk - -MODULE = myextension - -DIRS = public src - -XPI_NAME = myextension -INSTALL_EXTENSION_ID = myextension@mycompany.com -XPI_PKGNAME = myextension - -DIST_FILES = install.rdf - -include $(topsrcdir)/config/rules.mk -</pre> - -<p>A detailed description of the make process, describing the key features of this makefile, can be found <a href="/en/How_Mozilla's_build_system_works" title="en/How_Mozilla's_build_system_works">here</a>. <strong>MODULE</strong> and <strong>XPI_NAME</strong> are both set to the name of your extension; they should be repeated in all project makefiles so that all of the files land in the same place in the XPI staging area (see below). <strong>INSTALL_EXTENSION_ID</strong> is the unique ID of your extension. This can be a GUID, but the format shown above is prettier and, let’s face it, a lot easier to remember. You don’t have to provide an <strong>XPI_PKGNAME</strong>, but if you do an XPI file, suitable for distribution, is automatically created in the root of the XPI staging area (<code>/mozilla/$(MOZ_OBJDIR)/dist/xpi-stage/</code>).</p> - -<p>Every extension must include an <code>install.rdf</code> file that tells Firefox how to install it. This file should be located in the main extension directory and look something like this:</p> - -<pre class="brush: xml"><?xml version="1.0"?> - -<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#" - xmlns:em="http://www.mozilla.org/2004/em-rdf#"> - <Description about="urn:mozilla:install-manifest"> - <em:id>myextension@mycompany.com</em:id> - <em:version>0.1</em:version> - - <em:targetApplication> - <!-- Firefox --> - <Description> - <em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id> - <em:minVersion>1.0+</em:minVersion> - <em:maxVersion>1.0+</em:maxVersion> - </Description> - </em:targetApplication> - - <!-- front-end metadata --> - <em:name>My First Extension</em:name> - <em:description>Just an example.</em:description> - <em:creator>allpeers.com</em:creator> - <em:homepageURL>http://www.allpeers.com/blog/</em:homepageURL> - </Description> -</RDF> -</pre> - -<p>There's a <a href="/en/Install_Manifests" title="en/Install_Manifests">detailed description</a> of the format of the <code>install.rdf</code> file. Use the <strong>DIST_FILES</strong> variable in the makefile to tell <code>make</code> to copy the file into the extension directory and (optional) XPI file.</p> - -<h4 id="Interfaces_Públicas">Interfaces Públicas</h4> - -<p>The <code>public/</code> directory contains any interfaces that need to be accessed by other modules. These can be <a class="external" href="http://www.mozilla.org/scriptable/xpidl/idl-authors-guide/index.html">IDL</a> files describing <a href="/en/XPCOM" title="en/XPCOM">XPCOM</a> interfaces, which are used to generate normal C++ header files for inclusion in your source files. They can also be normal C++ header files that are to be used directly by other modules. The easiest way to accomplish the latter is to use inline implementations for all methods so you don’t have any additional linking dependencies. Otherwise you will have to link statically to your module if you use these public headers in other modules. Personally I would discourage this practice (among other things, static linking means the same code gets loaded more than once into memory, and the code won’t be available from JavaScript or other non-C++ languages) and encourage the use of XPCOM wherever possible.</p> - -<p>The makefile in the <code>public/</code> directory should follow this model:</p> - -<pre>DEPTH = ../../.. -topsrcdir = @top_srcdir@ -srcdir = @srcdir@ -VPATH = @srcdir@ - -include $(DEPTH)/config/autoconf.mk - -MODULE = myextension -XPIDL_MODULE = myextension - -XPI_NAME = myextension - -EXPORTS = \ - myHeader.h \ - $(NULL) - -XPIDLSRCS = \ - myIFirstComponent.idl \ - myISecondComponent.idl \ - $(NULL) - -include $(topsrcdir)/config/rules.mk -</pre> - -<p><strong>XPIDL_MODULE</strong> is the name of the generated XPT file that contains type information about your <a class="external" href="http://www.mozilla.org/scriptable/xpidl/idl-authors-guide/index.html">IDL</a> interfaces. If you have multiple modules, make absolutely sure that you use a different value for <strong>XPIDL_MODULE</strong> for each one. Otherwise the first module’s XPT file will be overwritten by the second and you’ll get <strong>NS_ERROR_XPC_BAD_IID</strong> errors when you try to access its IDL interfaces from your code. The files under <strong>EXPORTS</strong> are copied directly to the <code>/mozilla/$(MOZ_OBJDIR)/dist/include/</code> directory and are thus accessible from other modules (the value of <strong>MOZ_OBJDIR</strong> is defined in <code>/mozilla/.mozconfig</code>). XPIDLSRCS are run through the IDL processor, and the generated C++ headers are copied into the same include directory. In addition, an XPT (type library) file is generated and placed in the <code>components/</code> subdirectory of your extension.</p> - -<h4 id="Ficheiros_Fonte">Ficheiros Fonte</h4> - -<p>Now it’s time to create the makefile and source files in the <code>src/</code> subdirectory. If you're implementing interfaces that you've described using IDL, the easiest way to do this is to leave the <code>src/</code> directory empty and run <code>make</code> on the <code>public/</code> directory only; this will be explained shortly.</p> - -<p>Then open the generated header file for your interface from <code>/mozilla/$(MOZ_OBJDIR)/dist/include/</code>. It contains stubs for the component .H and .CPP files that you can copy and paste into your implementation files. All you have to do is fill in the implementation stubs in the C++ file and you’re good to go.</p> - -<p>Here’s an example of the makefile you need to place into your <code>src</code> directory:</p> - -<pre class="eval">DEPTH = ../../.. -topsrcdir = @top_srcdir@ -srcdir = @srcdir@ -VPATH = @srcdir@ - -include $(DEPTH)/config/autoconf.mk - -IS_COMPONENT = 1 -<a href="/en/MODULE" title="en/MODULE">MODULE</a> = myextension -<a href="/en/LIBRARY_NAME" title="en/LIBRARY_NAME">LIBRARY_NAME</a> = myExtension -<a href="/en/USE_STATIC_LIBS" title="en/USE_STATIC_LIBS">USE_STATIC_LIBS</a> = 1 - -XPI_NAME = myextension - -<a href="/en/CPPSRCS" title="en/CPPSRCS">CPPSRCS</a> = \ - myFirstComponent.cpp \ - mySecondComponent.cpp \ - myExtension.cpp \ - $(NULL) - -include $(topsrcdir)/config/rules.mk - -<a href="/en/EXTRA_DSO_LDOPTS" title="en/EXTRA_DSO_LDOPTS">EXTRA_DSO_LDOPTS</a> += \ - $(MOZ_COMPONENT_LIBS) \ - $(NSPR_LIBS) \ - $(NULL) -</pre> - -<p>In this example, the first two files contain the implementation of the extension’s two components. The final file, <code>myExtension.cpp</code>, contains the code necessary to register these components, as described in the next section.</p> - -<h4 id="Registar_os_Seus_Componentes">Registar os Seus Componentes</h4> - -<p><a href="/pt-PT/docs/Mozilla/Tech/XPCOM/Guide/Alterações_XPCOM_Gecko_2.0" title="XPCOM changes in Gecko 2.0">Este artigo </a>explica como registar os componentes XPCOM no Gecko 2.0 e superior.</p> - -<h4 id="Criação_de_Extensão">Criação de Extensão</h4> - -<p>As mentioned above, you’ll probably want to build your extension immediately after creating your IDL files in order to generate the C++ stubs for your component implementations. I’m assuming that you’ve already built Firefox successfully. If not, return immediately to the beginning of this article and don’t come back til you have a functioning <code>firefox.exe</code>. Do not pass go. Do not collect $200.</p> - -<p>Still here? Okay, now we have to modify your <code>.mozconfig</code> (in the <code>/mozilla/</code> root directory) so that your extension is built along with Mozilla. Add the following line at the end of the file:</p> - -<pre class="brush: shell">ac_add_options --enable-extensions=default,myextension -</pre> - -<p>Now launch <code>make</code> from the Mozilla root:</p> - -<pre class="brush: shell">make -f client.mk build -</pre> - -<p>Even if you have an up-to-date Firefox build, you’ll have to wait a while for <code>make</code> to recurse over the entire Mozilla source tree looking for new stuff (on my machine, which is pretty fast, this takes a good 10-15 minutes). Eventually it will reach your extension and generate a bunch of stuff under <code>/mozilla/$(MOZ_OBJDIR)/</code>:</p> - -<ul> - <li>Exported header files and generated header files (from IDL) in <code>dist/include/</code></li> - <li>Static libraries for your modules in <code>dist/lib/</code> (in case other modules want to link statically to your stuff instead of using XPCOM).</li> - <li>XPI file in <code>dist/xpi-stage/myextension.xpi</code>.</li> - <li>Generated makefiles for your projects in <code>extensions/myextension/</code> (remember, we’re under <code>/mozilla/$(MOZ_OBJDIR)/</code>.</li> - <li>Everything else in <code><a class="link-mailto" href="mailto:dist/bin/extensions/myextension@mycompany.com" rel="freelink">dist/bin/extensions/myextension@mycompany.com</a>/</code>.</li> -</ul> - -<p>A lot of this stuff won’t get created on this first pass since <code>make</code> will gag when it doesn’t find the source files for your components. Don’t worry about this; all you need are the generated header files that contain the C++ implementation stubs. Go back and flesh out the C++ implementation of your components so that the build can complete next time. Remember that you should never, ever modify any of these generated files. Always modify the files used to generate them and rerun <code>make</code>. If you’re changing the generated files directly, you’re probably doing something wrong.</p> - -<p>The process of walking the entire Mozilla tree takes a long time. If you already have a Mozilla build, you can avoid this by creating a makefile for your extension directly. Go to the root of your $(MOZ_OBJDIR) and (from a bash-compatible shell) enter:</p> - -<pre class="eval">../build/autoconf/make-makefile extensions/myextension -</pre> - -<p>If your $(MOZ_OBJDIR) is located outside your $(TOPSRCDIR), you'll need to do:</p> - -<pre class="eval">$(TOPSRCDIR)/build/autoconf/make-makefile -t $(TOPSRCDIR) extensions/myextension -</pre> - -<p>in order for the script to know where your source is (it'll use the extension path you gave it relative to the current dir to figure out where you want your makefiles to go).</p> - -<p>This will generate the proper makefile for your extension. Whether you build the whole Mozilla tree or take this shortcut, you can build from now on by going to <code>/mozilla/$(MOZ_OBJDIR)/extensions/myextension/</code> and typing "make" on the command line. It should build your component without bothering with the rest of Mozilla. If everything works out, you’ll see your XPI file in the XPI staging area. You’ll also see the "exploded" version of the XPI (i.e. the unzipped directory structure) underneath <code>/mozilla/$(MOZ_OBJDIR)/dist/bin/extensions</code>. (If something goes wrong, figure out what, fix it and then come back here and add it to this article.)</p> - -<p>To make sure that the build really finished, launch Firefox and check that your extension is listed when you select Tools/Extensions. If you are using Firefox as your regular browser (and if you’re not, why not!?), you might be annoyed by the fact that you have to close regular Firefox before running your custom-built version. If so, try setting the <strong>MOZ_NO_REMOTE</strong> environment variable to "1" before running the development version of Firefox. You’ll also need to use a different profile for your development version:</p> - -<pre class="brush: shell">firefox -P <em>development</em> -</pre> - -<p>Where <em>development</em> is replaced with the name of the extra profile you’ve created. This will let you run both versions of Firefox simultaneously, saving you oodles of time over the course of the build/test cycle.</p> - -<h4 id="Nenhum_Local_Como_o_Chrome">Nenhum Local Como o Chrome</h4> - -<p>Yippee-ki-yay! Now you have an extension that does, well, absolutely nothing. It’s time to do something with those groovy components that you’ve implemented and registered. The simplest way to do this is to write some <a href="/en/JavaScript" title="en/JavaScript">JavaScript</a> and <a href="/en/XUL" title="en/XUL">XUL</a> code. At this point, it would be very helpful to have a bit of experience <a href="/en/Extensions" title="en/Extensions">writing "regular" extensions</a> (i.e. without using custom C++ components). If you’ve never done this, I strongly recommend that you think of a cool idea for something simple that you’ve always wanted to tweak in Firefox and write it. Just displaying a new menu item that opens a "Hello, World!" dialog box would be already be a great exercise to get warmed up with.</p> - -<p>Assuming you know how to write XUL/JavaScript extensions, you’re aware that the most important stuff goes in the <code>chrome/</code> directory of your extension. Well, the fact that you’re also using C++ components doesn’t change that one whit. So now you need to create the normal <code>content/</code>, <code>locale/</code> and <code>skin/</code> directories in which to place your chrome files. Personally I like placing these directly under the root directory of my module, but I don’t suppose it makes any difference if you prefer putting them under a <code>chrome/</code> subdirectory or whatever. Let freedom reign!</p> - -<p>Once you’ve written the necessary chrome files (for instance, an overlay that adds a menu item to instantiate and use one of your components), you need to package them up as part of your extension. This is accomplished through the use of a <a href="/en/JAR_Manifests" title="en/JAR_Manifests">JAR Manifest</a>. For our simple extension example, this file might look something like this:</p> - -<pre>myextension.jar: -% content myextension %content/ -% locale myextension en-US %locale/en-US/ -% skin myextension classic/1.0 %skin/classic/ -% overlay chrome://browser/content/browser.xul chrome://myextension/content/MyExtensionOverlay.xul - content/MyExtensionOverlay.js (content/MyExtensionOverlay.js) - content/MyExtensionOverlay.xul (content/MyExtensionOverlay.xul) - locale/en-US/MyExtension.dtd (locale/en-US/MyExtension.dtd) - locale/en-US/MyExtension.properties (locale/en-US/MyExtension.properties) - skin/classic/MyExtension.css (skin/classic/MyExtension.css) -</pre> - -<p>Place this code in a file called <code>jar.mn</code> in the root directory of your extension, making sure that the paths in parentheses point to actual files (when interpreted relative to the root directory). You also have to make one small change to the makefile in the same directory, adding the following line:</p> - -<pre class="eval">USE_EXTENSION_MANIFEST = 1 -</pre> - -<p>This tells <code>make</code> to create a single manifest file called <code>chrome.manifest</code> instead of creating separate manifests with goofy names for each package.</p> - -<p>Now launch <code>make</code> again, and you should see a <code>chrome</code> subdirectory appear in your extension (<code>/mozilla/$(MOZ_OBJDIR)<a class="link-mailto" href="mailto:/dist/bin/extensions/myextension@mycompany.com" rel="freelink">/dist/bin/extensions/myextension@mycompany.com</a>/</code>). Note that the <code>chrome</code> directory contains a JAR (i.e. ZIP) file with all the chrome files listed in <code>jar.mn</code> as well as a complete directory structure mirroring that of the JAR file. The directory structure, however, is empty. Why? I don’t know. Don’t worry about this, the files in the JAR are the ones that are actually used.</p> - -<h4 id="Mantedo-a_Complexa">Mantedo-a Complexa</h4> - -<p>If you’re developing a really complex extension with lots of <a href="/en/XPCOM" title="en/XPCOM">XPCOM</a> components, you’ll probably want to divide your code up into smaller modules.</p> - -<h5 id="Kinda_Sorta_Complex_Extensions">Kinda, Sorta Complex Extensions</h5> - -<p>For a moderately complex extension, it’s probably enough just to subdivide the code into a single level of modules. Let’s assume that you have a <code>base/</code> module that defines a bunch of basic XPCOM components and an <code>advanced/</code> module that defines some chrome as well as other components that use the basic components. Your complete directory structure will look something like this:</p> - -<ul> - <li>myextension - <ul> - <li>base - <ul> - <li>public</li> - <li>src</li> - </ul> - </li> - <li>advanced - <ul> - <li>content</li> - <li>locale - <ul> - <li>en-US</li> - <li>...other locales...</li> - </ul> - </li> - <li>public</li> - <li>skin - <ul> - <li>classic</li> - <li>...other skins...</li> - </ul> - </li> - <li>src</li> - </ul> - </li> - </ul> - </li> -</ul> - -<p>Other than that, nothing really changes. The makefiles in the <code>base/</code> and <code>advanced/</code> directories should look more or less like your original root makefile, remembering to change the <strong>DEPTH</strong> variable to account for the fact that they’ve moved a level further away from the Mozilla root. You also need to remove the <strong>DIST_FILES</strong> variable since that’s going to be in the top-level makefile. Every makefile that generates anything should define the <strong>XPI_NAME</strong> variable to make sure generated files go into your extension and not into the global <code>components/</code> directory. In fact, just define this in every makefile to be safe. You can use the same <strong>MODULE</strong> in both <code>base/</code> and <code>advanced/</code> so that all the generated include files go into the same directory, but make sure that you don’t use the same <strong>XPIDL_MODULE</strong> in the two <code>public/</code> directories or one of the component type libraries (i.e. XPT files) will overwrite the other one and all hell will break loose.</p> - -<p>Each module must also have a different value for the <strong>LIBRARY_NAME</strong> variable. This is the name of the generated dynamic library, so if we call the libraries "myBase" and "myAdvanced", we’ll end up with <code>myBase.dll</code> and <code>myAdvanced.dll</code> (on Windows, at least). And each of these modules is going to have a separate C++ file for registering components. So there will be two files that look like <code>myExtension.cpp</code> in the original example, say <code>Base.cpp</code> and <code>Advanced.cpp</code>. Finally, each module will obviously have its own <code>jar.mn</code>, though they can reference the same JAR filename and package name if you want all the chrome files to be organized in a single JAR file and package. The only file that really stays put is <code>install.rdf</code>, which still exists once and only once in the extension root directory.</p> - -<p>As for the top-level makefile, it will now look like this:</p> - -<pre>DEPTH = ../.. -topsrcdir = @top_srcdir@ -srcdir = @srcdir@ -VPATH = @srcdir@ - -include $(DEPTH)/config/autoconf.mk - -MODULE = myextension - -DIRS = base advanced - -XPI_NAME = myextension -INSTALL_EXTENSION_ID = myextension@mycompany.com -XPI_PKGNAME = myextension - -DIST_FILES = install.rdf - -include $(topsrcdir)/config/rules.mk -</pre> - -<h5 id="Extensões_Complexas_Sérias">Extensões Complexas Sérias</h5> - -<p>At some point, even a single module may grow to the point where you want to divide it further into submodules. The difference between having separate modules and having a single module with separate submodules is that the submodules all share the same file for registering components (the famous <code>myExtension.cpp</code> file), and when compiled they create a single dynamic library. The decision to split a module into submodules is all about code organization; it doesn’t really affect the final product at all.</p> - -<p>To split a module into submodules, first create a subdirectory for each submodule. Then create an additional directory called <code>build/</code>. Each submodule will be configured to create a static library, and the <code>build/</code> directory will pull these libraries together to create a single dynamic component library. Confused? Here’s an example, showing just the <code>advanced/</code> subbranch of the <code>myextension/</code> directory:</p> - -<ul> - <li>advanced - <ul> - <li>build</li> - <li>intricate - <ul> - <li>public</li> - <li>src</li> - </ul> - </li> - <li>multifarious - <ul> - <li>public</li> - <li>src</li> - </ul> - </li> - <li>content</li> - <li>locale - <ul> - <li>en-US</li> - <li>...other locales...</li> - </ul> - </li> - <li>skin - <ul> - <li>classic</li> - <li>...other skins...</li> - </ul> - </li> - </ul> - </li> -</ul> - -<p>As you can see, we’ve split <code>advanced/</code> into two submodules: <code>intricate/</code> and <code>multifarious/</code>, and we’ve added an additional <code>build/</code> subdirectory. We’ve left the chrome directories directly under <code>advanced/</code>, since they aren’t tied to any specific submodule. This means that <code>jar.mn</code> will stay in the same place.</p> - -<p>The <code>intricate/</code> and <code>multifarious/</code> makefiles will look a lot like the original <code>advanced/</code> makefile, but we’ll need to tweak them a bit. As always, we have to adjust the <strong>DEPTH</strong> variable since the makefiles are deeper in the directory structure. And we should change the <strong>LIBRARY_NAME</strong> to indicate that we’re generating a static library for each submodule. By convention the "_s" suffix is used for this purpose. So let’s call them "myIntricate_s" and "myMultifarious_s". Finally, we define the variable <strong>FORCE_STATIC_LIB</strong>, resulting in a makefile that starts something like this:</p> - -<pre>DEPTH = ../../../../.. -topsrcdir = @top_srcdir@ -srcdir = @srcdir@ -VPATH = @srcdir@ - -include $(DEPTH)/config/autoconf.mk - -MODULE = myextension -LIBRARY_NAME = myIntricate_s -FORCE_STATIC_LIB = 1 -USE_STATIC_LIBS = 1 - -XPI_NAME = myextension - -...more stuff here... -</pre> - -<p>The <code>build</code> makefile pulls together the static libraries generated by the submodules and creates a single (dynamic) component library:</p> - -<pre>DEPTH = ../../../.. -topsrcdir = @top_srcdir@ -srcdir = @srcdir@ -VPATH = @srcdir@ - -include $(DEPTH)/config/autoconf.mk - -IS_COMPONENT = 1 -MODULE = myextension -LIBRARY_NAME = myAdvanced -USE_STATIC_LIBS = 1 - -XPI_NAME = myextension - -DEFINES += XPCOM_GLUE - -SHARED_LIBRARY_LIBS = \ - $(DIST)/lib/$(LIB_PREFIX)myIntricate_s.$(LIB_SUFFIX) \ - $(DIST)/lib/$(LIB_PREFIX)myMultifarious_s.$(LIB_SUFFIX) \ - $(DIST)/lib/$(LIB_PREFIX)xpcomglue_s.$(LIB_SUFFIX) \ - $(DIST)/lib/$(LIB_PREFIX)xul.$(LIB_SUFFIX) \ - $(DIST)/lib/$(LIB_PREFIX)nss3.$(LIB_SUFFIX) \ - $(NULL) - -CPPSRCS = \ - Advanced.cpp \ - $(NULL) - -include $(topsrcdir)/config/rules.mk - -LOCAL_INCLUDES += \ - -I$(srcdir)/../intricate/src \ - -I$(srcdir)/../multifarious/src \ - $(NULL) -</pre> - -<p>The makefile in the <code>advanced/</code> directory should list the <code>intricate/</code>, <code>multifarious/</code> and <code>build/</code> directories in its <strong>DIRS</strong> variable. Make sure that <code>build/</code> comes last since it can’t create the component library until the other makefiles have completed.</p> - -<h3 id="Outros_Tópicos">Outros Tópicos</h3> - -<h4 id="Adicionar_Ficheiros_de_Dados_às_Suas_Extensões">Adicionar Ficheiros de Dados às Suas Extensões</h4> - -<p>In some cases, you may wish to include additional files in your extension that don’t belong in the <code>chrome/</code> subdirectory. Examples might be database files or XML schemas. This can be achieved by adding a custom step to your makefile that copies the files from the source tree into the extension’s target directory.</p> - -<h5 id="Copiar_Ficheiros_de_Dados_para_a_Diretoria_de_Destino">Copiar Ficheiros de Dados para a Diretoria de Destino</h5> - -<p>Let’s say that you have some data files containing statistical information that you want to include in your extension and make available to your components. You’ve placed these files, which have the extension .TXT, into a <code>stats/</code> subdirectory under your extension directory in the source tree. The following makefile rule can be used to copy these files into the final target directory of the extension:</p> - -<pre>export:: - if test ! -d $(FINAL_TARGET)/stats; then \ - $(NSINSTALL) -D $(FINAL_TARGET)/stats; \ - fi - $(INSTALL) $(srcdir)/*.txt $(FINAL_TARGET)/stats -</pre> - -<h5 id="Aceder_aos_Ficheiros_de_Dados_a_partir_dos_Componentes">Aceder aos Ficheiros de Dados a partir dos Componentes</h5> - -<p>The trick to accessing your data files is to figure out where the home directory of your extension is. Rumor has it that at some future date, this will possible through the <code><a href="/en/XPCOM_Interface_Reference/nsIExtensionManager" title="en/XPCOM_Interface_Reference/nsIExtensionManager">nsIExtensionManager</a></code> interface or something similar. In the meantime, there is a simple and reliable hack that can be used to achieve this. In the implementation of any JavaScript XPCOM component, there is a special <strong>__LOCATION__</strong> (two leading and two trailing underscores) symbol that points to the component’s implementation file. So you can write a simple component which deduces the root directory of your extensions by extrapolating from its location.</p> - -<p><a class="external" href="http://www.builderau.com.au/program/soa/Creating_XPCOM_components_with_JavaScript/0,39024614,39206503,00.htm">This article</a> explains how to create an XPCOM component in JavaScript. You’ll need an IDL file for an interface that looks something like this:</p> - -<pre>interface myILocation : nsISupports -{ - readonly attribute nsIFile locationFile; -}; -</pre> - -<p>Place the IDL file in the <code>public/</code> directory of your project or subproject. In the <code>src/</code> directory, place the JavaScript file that implements the component. The component implementation will include the methods for retrieving the path or file for the extension’s home directory:</p> - -<pre class="brush: js">myLocation.prototype = -{ - QueryInterface: function(iid) - { - if (iid.equals(nsISupports)) - return this; - if (iid.equals(myILocation)) - return this; - - Components.returnCode = Components.results.NS_ERROR_NO_INTERFACE; - return null; - }, - - get locationFile() - { - return __LOCATION__.parent.parent; - } -} -</pre> - -<p>This assumes that the component resides in a subdirectory of the extension directory (by convention, this directory is called <code>components/</code>). The <code>parent</code> property of <strong>__LOCATION__</strong> returns the <code>components/</code>, and the <code>parent</code> of this is the extension directory.</p> - -<p>The last step is to modify the makefile of the source directory where you placed your JavaScript file so that it is copied into the appropriate location in the extension:</p> - -<pre>export:: - $(INSTALL) $(srcdir)/*.js $(FINAL_TARGET)/components -</pre> - -<p>Now you can instantiate an instance of this component and use the <code>locationFile</code> property to get an <code><a href="/en/XPCOM_Interface_Reference/nsIFile" title="en/XPCOM_Interface_Reference/nsIFile">nsIFile</a></code> interface that points to your extension’s home directory.</p> - -<h4 id="Using_Third-Party_Libraries">Using Third-Party Libraries</h4> - -<p>For more sophisticated extensions, you may want to integrate third-party libraries that provide specialized functionality for database connectivity, image processing, networking and the like. If you want your extension to run on all Firefox platforms, you will need to have the source code for the library in question, so I assume that this is available.</p> - -<p>The most convenient approach from the perspective of the development cycle is to create a Mozilla-style makefile for the library. This works well for libraries that have a straightforward make process without extensive configuration. A good example of this is the SQLite library included in the Mozilla build tree at <code>db/sqlite</code>. By adapting the makefile in this way, the library is created as part of the standard Mozilla build process, which eliminates additional build steps. The downside is that you will need to update the modified makefile any time a new version of the library is released.</p> - -<p>For libraries that have complex configuration processes, use a non-standard compiler or have other special characteristics, it may be unfeasible to create a Mozilla-compliant makefile. In this case, I would recommend placing the entire library distribution inside the project or subproject that uses it. So if library <code>acmelib</code> is used inside the <code>multifarious/</code> subproject in the above example, it would be placed as a subdirectory underneath that subproject (at the same level as <code>public/</code> and <code>src/</code>).</p> - -<p>Of course, this means that you will have to build <code>acmelib</code> manually on all platforms before launching the Mozilla build. But at least you can then refer to include files and import libraries from your component using relative paths.</p> - -<h4 id="Building_for_Multiple_Platforms">Building for Multiple Platforms</h4> - -<p>TODO</p> - -<div class="originaldocinfo"> -<h2 id="Original_Document_Information">Original Document Information</h2> - -<ul> - <li>Author: Matthew Gertner - July 26, 2005.</li> - <li>Permission granted to migrate in Jan 2006, including permission to relicense under the CC:By-SA.</li> - <li>Original Source: <a class="external" href="http://www.allpeers.com/blog/creating-complex-firefox-extensions/" rel="freelink">http://www.allpeers.com/blog/creatin...ox-extensions/</a></li> -</ul> -</div> - -<p> </p> diff --git a/files/pt-pt/mozilla/add-ons/distribuicao/index.html b/files/pt-pt/mozilla/add-ons/distribuicao/index.html deleted file mode 100644 index eede6b7581..0000000000 --- a/files/pt-pt/mozilla/add-ons/distribuicao/index.html +++ /dev/null @@ -1,78 +0,0 @@ ---- -title: Assinar e distribuir os seus extras -slug: Mozilla/Add-ons/Distribuicao -tags: - - Extensões - - Extensões da Web - - Extras - - assinatura - - distribuição - - publicação - - revisões -translation_of: Mozilla/Add-ons/Distribution ---- -<div>{{AddonSidebar}}</div> - -<p>Os extras precisam de ser assinados antes de serem instalados nas versões beta e de lançamento do Firefox. Este processo de assinatura ocorre via addons.mozilla.org (AMO), independentemente de optar por distribuir o seu extra via AMO ou por si mesmo.</p> - -<p>Nós aqui analisamos os requisitos de assinatura e as revisões relacionadas, antes de discutir como escolher entre o distribuir no AMO ou distribuir um extra por si mesmo. Nós também analisamos os canais disponíveis no AMO e respondemos a questões sobre propriedade e disputas de código.</p> - -<h2 class="brush: js" id="Assinar_os_seus_extras">Assinar os seus extras</h2> - -<p>Starting with Firefox 43, add-on extensions and multi-item add-ons that include extensions need to be signed by Mozilla before they can install in release and beta versions of Firefox. Themes, and other types of add-ons such as spelling dictionaries, don't need to be signed.</p> - -<p>Unsigned extensions can be installed in <a href="/en-US/Firefox/Developer_Edition">Developer Edition</a>, Nightly, and <a href="/en-US/Firefox/Enterprise_deployment">ESR</a> versions of Firefox, after toggling the <em>xpinstall.signatures.required</em> preference in <code>about:config</code>.</p> - -<p>Mozilla signs add-ons through the <a href="https://addons.mozilla.org/developers/addon/submit">AMO</a> website and provides three methods for submitting your add-on for signing:</p> - -<ul> - <li>upload your add-on through the <a href="/en-US/Add-ons/Distribution/Submitting_an_add-on">Developer Hub on AMO</a>.</li> - <li>use the <a href="http://addons-server.readthedocs.io/en/latest/topics/api/signing.html">addons.mozilla.org signing API</a>.</li> - <li>use <a href="https://developer.mozilla.org/en-US/Add-ons/WebExtensions/web-ext_command_reference#web-ext_sign">web-ext sign.</a></li> -</ul> - -<p>All the signing options are subject to the <a href="/en-US/Add-ons/AMO/Policy/Agreement">Firefox Add-on Distribution Agreement</a>.</p> - -<p>Using the signing API or web-ext returns you signed add-ons, with no distribution listing created on AMO. If you take the option to upload your add-on through the AMO Developer Hub, you're given a choice between listing on AMO or self-distribution. If you choose self-distribution, at the end of the process you download signed copies of your add-on.</p> - -<p>Regardless of the method used all add-ons must pass an automated validation before they are signed. They may also be subject to a manual code review. The review criteria applied to add-ons are found in the <a href="/en-US/docs/Mozilla/Add-ons/AMO/Policy/Reviews">Add-on Policies</a>.</p> - -<h2 id="Distributir_o_seu_extra">Distributir o seu extra</h2> - -<p>You aren't required to list or distribute your add-on through AMO. You'll, therefore, need to decide if you want to distribute and list your add-on through AMO or distribute it yourself. Here are some things you should consider:</p> - -<ul> - <li>AMO is a very popular distribution platform, with millions of monthly visitors and installations. It's integrated into the Firefox Add-ons Manager, allowing for easy installation of add-ons published on AMO.</li> - <li>When an add-on is listed on AMO, updates to installed copies are handled automatically by Firefox each time a new version is listed on AMO.<br> - To enable Firefox to automatically update self-distributed add-ons, the URL where Firefox can find updates needs to be included in the add-on manifest's <a href="/en-US/Add-ons/Updates">update_link</a> key. Self-distributed add-ons that don't have an update URL check AMO for updates and are updated to a listed version, if one is available.</li> -</ul> - -<p>For more information on how to submit an add-on for distribution on AMO or self-distribution, see <a href="/en-US/docs/Mozilla/Add-ons/Distribution/Submitting_an_add-on">Submitting an add-on.</a></p> - -<h2 id="Mais_informação_sobre_AMO">Mais informação sobre AMO</h2> - -<h3 id="Propriedade">Propriedade</h3> - -<p>Os extras no AMO podem ter vários utilizadores com permissão para atualizar e gerir a listagem. Os autores de um extra podem transferir a propriedade e adicionar programadores à listagem de um extra por meio do <em>Hub </em>do Programdor. Não é necessária nenhuma interação com os representantes da Mozilla para uma transferência de propriedade.</p> - -<p> </p> - -<h4 id="Para_transferir_propriedade">Para transferir propriedade</h4> - -<ul> - <li>Make sure the new owner has an account on <a href="https://addons.mozilla.org/">addons.mozilla.org</a>. New accounts can be created using the "Register or Log in" button, after which the owner must confirm their email address.</li> - <li>Sign into your account on the <a href="https://addons.mozilla.org/developers/">Add-on Developer Hub</a>, and click "Edit Listing" for the extension you want to transfer.</li> - <li>On the left-hand side of the screen, you will see a blue box labeled "Edit Information". Click "Manage Authors & License" — from the resulting page you can add and remove authors.</li> - <li>One you have added the new author's email address, set that person as the extension owner and make sure the "Listed" box has a checkmark. Now you can remove yourself by clicking the "x" next to your email address.</li> - <li>When you're done, click "Save Changes". The new owner will be able to manage updates, listing information, etc., when logged in.</li> -</ul> - -<p> </p> - -<h3 id="Disputas_de_códogo">Disputas de códogo</h3> - -<p>Many add-ons allow their source code to be viewed. This does not mean that the source code is open source or available for use in another add-on. The original author of an add-on retains copyright of their work unless otherwise noted in the add-on's license.</p> - -<p>If we're notified of a copyright or license infringement, we will take steps to address the situation per the DMCA, which may include taking down the add-on listing. Details about this process and how to report trademark or licensing issues can be <a href="https://www.mozilla.org/en-US/about/legal/report-abuse/">found here</a>.</p> - -<p>If you are unsure of the current copyright status of an add-on's source code, you must contact the author and get explicit permission before using the source code.</p> diff --git a/files/pt-pt/mozilla/add-ons/linhas_diretrizes_para_extras/index.html b/files/pt-pt/mozilla/add-ons/linhas_diretrizes_para_extras/index.html deleted file mode 100644 index 4293fe9c74..0000000000 --- a/files/pt-pt/mozilla/add-ons/linhas_diretrizes_para_extras/index.html +++ /dev/null @@ -1,8 +0,0 @@ ---- -title: Linhas Diretrizes para Extras -slug: Mozilla/Add-ons/Linhas_diretrizes_para_extras -translation_of: 'https://extensionworkshop.com/documentation/publish/add-on-policies/' ---- -<div class="warning"> -<p>Este documento já não é válido. Por favor, consulte o documento de <a href="/pt-PT/docs/Mozilla/Add-ons/AMO/Policy/Revisões">Políticas de Revisão</a> para o conjunto atual das políticas de extras.</p> -</div> diff --git a/files/pt-pt/mozilla/add-ons/sdk/index.html b/files/pt-pt/mozilla/add-ons/sdk/index.html deleted file mode 100644 index 1c160220ae..0000000000 --- a/files/pt-pt/mozilla/add-ons/sdk/index.html +++ /dev/null @@ -1,97 +0,0 @@ ---- -title: Add-on SDK -slug: Mozilla/Add-ons/SDK -tags: - - Add-on SDK - - Jetpack -translation_of: Archive/Add-ons/Add-on_SDK ---- -<div class="warning"> -<p>Support for extensions using XUL/XPCOM or the Add-on SDK was removed in Firefox 57, released November 2017. As there is no supported version of Firefox enabling these technologies, this page will be removed by December 2020.</p> - -<p>Add-ons using the techniques described in this document are considered a legacy technology in Firefox. Don't use these techniques to develop new add-ons. Use <a href="/en-US/Add-ons/WebExtensions">WebExtensions</a> instead. If you maintain an add-on which uses the techniques described here, consider migrating it to use WebExtensions.</p> - -<p><strong>Starting from <a href="https://wiki.mozilla.org/RapidRelease/Calendar">Firefox 53</a>, no new legacy add-ons will be accepted on addons.mozilla.org (AMO) for desktop Firefox and Firefox for Android.</strong></p> - -<p><strong>Starting from <a href="https://wiki.mozilla.org/RapidRelease/Calendar">Firefox 57</a>, only extensions developed using WebExtensions APIs will be supported on Desktop Firefox and Firefox for Android. </strong></p> - -<p>Even before Firefox 57, changes coming up in the Firefox platform will break many legacy extensions. These changes include multiprocess Firefox (e10s), sandboxing, and multiple content processes. Legacy extensions that are affected by these changes should migrate to use WebExtensions APIs if they can. See the <a href="https://blog.mozilla.org/addons/2017/02/16/the-road-to-firefox-57-compatibility-milestones/">"Compatibility Milestones" document</a> for more information.</p> - -<p>A wiki page containing <a href="https://wiki.mozilla.org/Add-ons/developer/communication">resources, migration paths, office hours, and more</a>, is available to help developers transition to the new technologies.</p> -</div> -<p>Pode criar extras do Firefox utilizando <strong><u>Add-on SDK</u></strong>. Pode utilizar várias tecnologias da Web padrão: CSS, HTML e JavaScript, para criar os extras. O SDK inclui as APIs de JavaScript APIs, que pode utilziar para criar extras e ferramentas para a criação, execução, testes, e empacotamento dos extras.</p> - -<hr> -<h3 id="Tutoriais"><a href="/en-US/Add-ons/SDK/Tutorials">Tutoriais</a></h3> - -<div class="column-container"> -<div class="column-half"> -<dl> - <dt><a href="/en-US/Add-ons/SDK/Tutorials#getting-started">Getting started</a></dt> - <dd>How to <a href="/en-US/Add-ons/SDK/Tutorials/Installation">install the SDK</a> and <a href="/en-US/Add-ons/SDK/Tutorials/Getting_Started_(jpm)">use the jpm tool</a> to develop, test, and package add-ons.</dd> - <dt><a href="/en-US/Add-ons/SDK/Tutorials#interact-with-the-browser">Interact with the browser</a></dt> - <dd><a href="/en-US/Add-ons/SDK/Tutorials/Open_a_Web_Page">Open web pages</a>, <a href="/en-US/Add-ons/SDK/Tutorials/Listen_For_Page_Load">listen for pages loading</a> and <a href="/en-US/Add-ons/SDK/Tutorials/List_Open_Tabs">list open pages</a>.</dd> - <dt><a href="/en-US/Add-ons/SDK/Tutorials#development-techniques">Development techniques</a></dt> - <dd>Learn about common development techniques, such as <a href="/en-US/Add-ons/SDK/Tutorials/Unit_testing">unit testing</a>, <a href="/en-US/Add-ons/SDK/Tutorials/Logging">logging</a>, <a href="/en-US/Add-ons/SDK/Tutorials/Creating_Reusable_Modules">creating reusable modules</a>, <a href="/en-US/Add-ons/SDK/Tutorials/l10n">localization</a>, and <a href="/en-US/Add-ons/SDK/Tutorials/Mobile_development">mobile development</a>.</dd> -</dl> -</div> - -<div class="column-half"> -<dl> - <dt><a href="/en-US/Add-ons/SDK/Tutorials#create-user-interfaces">Create user interface components</a></dt> - <dd>Create user interface components such as <a href="/en-US/Add-ons/SDK/Tutorials/Adding_a_Button_to_the_Toolbar">toolbar buttons</a>, <a href="/en-US/Add-ons/SDK/Tutorials/Add_a_Context_Menu_Item">context menus</a>, <a href="/en-US/Add-ons/SDK/Tutorials/Add_a_Menu_Item_to_Firefox">menu items</a>, and <a href="/en-US/Add-ons/SDK/Tutorials/Display_a_Popup">dialogs</a>.</dd> - <dt><a href="/en-US/Add-ons/SDK/Tutorials#modify-web-pages">Modify web pages</a></dt> - <dd>Modify pages <a href="/en-US/Add-ons/SDK/Tutorials/Modifying_Web_Pages_Based_on_URL">matching a URL pattern</a> or dynamically <a href="/en-US/Add-ons/SDK/Tutorials/Modifying_the_Page_Hosted_by_a_Tab">modify a particular tab</a>.</dd> - <dt><a href="/en-US/Add-ons/SDK/Tutorials/Annotator">Putting it together</a></dt> - <dd>Walkthrough of the Annotator example add-on.</dd> -</dl> -</div> -</div> - -<hr> -<h3 id="Guias">Guias</h3> - -<div class="column-container"> -<div class="column-half"> -<dl> - <dt><a href="/en-US/Add-ons/SDK/Guides#contributors-guide">Contributor's guide</a></dt> - <dd>Learn <a href="/en-US/Add-ons/SDK/Guides/Getting_Started">how to start contributing</a> to the SDK and about the most important idioms used in the SDK code such as <a href="/en-US/Add-ons/SDK/Guides/Modules">modules</a>, <a href="/en-US/Add-ons/SDK/Guides/Classes_and_Inheritance">classes and inheritance</a>, <a href="/en-US/Add-ons/SDK/Guides/Private_Properties">private properties</a>, and <a href="/en-US/Add-ons/SDK/Guides/Content_Processes">content processes</a>.</dd> - <dt><a href="/en-US/Add-ons/SDK/Guides#sdk-infrastructure">SDK infrastructure</a></dt> - <dd>Aspects of the SDK's underlying technology: <a href="/en-US/Add-ons/SDK/Guides/Module_structure_of_the_SDK">modules</a>, the <a href="/en-US/Add-ons/SDK/Guides/Program_ID">Program ID</a> and the rules defining <a href="/en-US/Add-ons/SDK/Guides/Firefox_Compatibility">Firefox compatibility</a>.</dd> - <dt><a href="/en-US/Add-ons/SDK/Guides/Content_Scripts">Content scripts</a></dt> - <dd>A detailed guide to working with content scripts.</dd> -</dl> -</div> - -<div class="column-half"> -<dl> - <dt><a href="/en-US/Add-ons/SDK/Guides#sdk-idioms">SDK idioms</a></dt> - <dd>The SDK's <a href="/en-US/Add-ons/SDK/Guides/Working_with_Events">event framework</a> and the <a href="/en-US/Add-ons/SDK/Guides/Two_Types_of_Scripts">distinction between add-on scripts and content scripts</a>.</dd> - <dt><a href="/en-US/Add-ons/SDK/Guides/XUL_Migration_Guide">XUL migration</a></dt> - <dd>A guide to <a href="/en-US/Add-ons/SDK/Guides/XUL_Migration_Guide">porting XUL add-ons to the SDK</a>. This guide includes a <a href="/en-US/Add-ons/SDK/Guides/XUL_vs_SDK">comparison of the two toolsets</a> and a <a href="/en-US/Add-ons/SDK/Guides/Porting_the_Library_Detector">working example</a> of porting a XUL add-on.</dd> - <dt><a href="/en-US/Add-ons/SDK/Guides/Multiprocess_Firefox_and_the_SDK">Multiprocess Firefox and the SDK</a></dt> - <dd>How to check whether your add-on is compatible with multiprocess Firefox or not and fix it accordingly.</dd> -</dl> -</div> -</div> - -<hr> -<h3 id="Referência">Referência</h3> - -<div class="column-container"> -<div class="column-half"> -<dl> - <dt><a href="/en-US/Add-ons/SDK/High-Level_APIs">High-Level APIs</a></dt> - <dd>Reference documentation for the high-level SDK APIs.</dd> - <dt><a href="/en-US/Add-ons/SDK/Tools">Tools reference</a></dt> - <dd>Reference documentation for the <a href="/en-US/Add-ons/SDK/Tools/jpm">jpm tool</a> used to develop, test and package add-ons, the <a href="/en-US/Add-ons/SDK/Tools/console">console</a> global used for logging, and the <a href="/en-US/Add-ons/SDK/Tools/package_json">package.json</a> file.</dd> -</dl> -</div> - -<div class="column-half"> -<dl> - <dt><a href="/en-US/Add-ons/SDK/Low-Level_APIs">Low-Level APIs</a></dt> - <dd>Reference documentation for the low-level SDK APIs.</dd> -</dl> -</div> -</div> diff --git a/files/pt-pt/mozilla/add-ons/themes/conceitos_tema/index.html b/files/pt-pt/mozilla/add-ons/themes/conceitos_tema/index.html deleted file mode 100644 index bb59c4386f..0000000000 --- a/files/pt-pt/mozilla/add-ons/themes/conceitos_tema/index.html +++ /dev/null @@ -1,230 +0,0 @@ ---- -title: Conceitos de Tema -slug: Mozilla/Add-ons/Themes/Conceitos_tema -tags: - - Tema - - extra -translation_of: Mozilla/Add-ons/Themes/Theme_concepts ---- -<div>{{AddonSidebar()}}</div> - -<p>Os temas desenvolvidos utilizando a <a href="/pt-PT/docs/Mozilla/Add-ons/WebExtensions">WebExtensions API</a> no Firefox permitem-lhe alterar a aparência do navegador ao adicionar imagens na área do cabeçalho do navegador Firefox; esta é a área por trás da barra de menus, barras de ferramentas, barra de endereço, barra de pesquisa e seuparador de faixa.</p> - -<p>Estas opções de temas podem ser implementadas como temas estáticos (embora as próprias imagens do tema possam ser animadas) ou como temas dinâmicos criados numa extensão do navegador.</p> - -<div class="note"> -<p>If you have a <a href="/en-US/docs/Mozilla/Add-ons/Themes/Lightweight_themes">lightweight theme</a> it will be converted to this new theme format automatically before lightweight themes are deprecated. You do not need to port your theme. However, please feel free to update your themes to use any of the new features described here.</p> -</div> - -<h2 id="Temas_estásticos">Temas estásticos</h2> - -<p>Static themes are specified using the same resources as a browser extension: a <a href="/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json">manifest.json</a> file to define the theme components with those components stored in the same folder as the manifest.json file or a sub folder. These resources are then packed in a zip for publication on <a href="https://addons.mozilla.org">addons.mozilla.org</a> (AMO).</p> - -<div class="note"> -<p>A theme and browser extension functionality cannot be defined in one package, such as including a theme to complement an extension. You can, however, programmatically include a theme in an extension using the Theme API. See <a href="#Dynamic_themes">Dynamic themes</a>.</p> -</div> - -<h3 id="Definir_um_tema">Definir um tema</h3> - -<p>To create a theme (in this example a simple, single image theme):</p> - -<ul> - <li>Create a folder in a suitable location on your computer.</li> - <li>Add the theme image file to the folder: - <pre><mytheme> - <your_header_image>.<type></pre> - </li> - <li>Create a file called manifest.json in the folder and edit its content as follows: - <pre class="brush: json">{ - "manifest_version": 2, - "version": "1.0", - "name": "<your_theme_name>", - "theme": { - "images": { - "headerURL": "<your_header_image>.<type>" - }, - "colors": { - "accentcolor": "#FFFFFF", - "textcolor": "#000" - } - } -} -</pre> - Where: - - <ul> - <li><code>"accentcolor":</code> is the heading area background color for your theme.</li> - <li><code>"</code><code>textcolor</code><code>":</code> the color of the text in the heading area.</li> - </ul> - </li> - <li>Package your theme and submit it to AMO, <a href="/en-US/Add-ons/WebExtensions/Publishing_your_WebExtension">following these instructions</a>.</li> -</ul> - -<h3 id="Static_theme_approaches">Static theme approaches</h3> - -<p>There are two approaches you can take to theming the header area of Firefox: using a single image or using multiple images. You could combine the two, but it’s easier to treat them separately.</p> - -<h4 id="Single_image_themes">Single image themes</h4> - -<p>This is the basic or minimal theming option, where you define:</p> - -<ul> - <li>a single image, which is anchored to the top right of the header area.</li> - <li>A color for the text in the header.</li> -</ul> - -<p>The area your header image needs to fill is a maximum of 200 pixels high. The maximum image width is determined by the resolution of the monitor Firefox is displaying on and how much of the monitor Firefox is using. Practically, this means you would need to allow for a width of up to 5120 pixels wide (for the next generation of 5k monitors). However, rather than creating a very wide image, a better approach is to use a narrower image with a transparent left edge so that it fades to the background color. For example, we could use this image<br> - <img alt="An image of a weta (the common name for a group of about 70 insect species in the families Anostostomatidae and Rhaphidophoridae, endemic to New Zealand) with the left edge fading to total transparency." src="https://mdn.mozillademos.org/files/15215/weta.png" style="height: 200px; width: 406px;"><br> - combined with a complementary background color, to create this effect in the header<br> - <img alt="A single image theme using the weta.png image" src="https://mdn.mozillademos.org/files/15217/basic_theme.png" style="height: 113px; width: 679px;"></p> - -<p>See details about this theme in the <a href="https://github.com/mdn/webextensions-examples/tree/master/themes">themes</a> example <a href="https://github.com/mdn/webextensions-examples/tree/master/themes/weta_fade">weta_fade</a>.</p> - -<p>Obviously, you can still provide a single wide image if you prefer.</p> - -<h4 id="Multiple_image_themes">Multiple image themes</h4> - -<p>As an alternative to creating a single image theme, you have the option to use multiple images. These images can be individually anchored to locations within the header, with the option to apply tiling to each image.</p> - -<p>Depending on the effect you want to create you may need to suppress the mandatory <code>"</code><code>headerURL</code><code>":</code> image with an empty or transparent image. You would use an empty or transparent image if, for example, you wanted to tile a centrally justified image, such as<br> - <img alt="An image of a weta (the common name for a group of about 70 insect species in the families Anostostomatidae and Rhaphidophoridae, endemic to New Zealand) with the left and right edges fading to total transparency." src="https://mdn.mozillademos.org/files/15219/weta_for_tiling.png" style="height: 200px; width: 270px;"><br> - to create this effect<br> - <img alt="A single image theme using the additional images option to align an image to the center of the heading and tile it. " src="https://mdn.mozillademos.org/files/15221/tiled_theme.png" style="height: 113px; width: 679px;"><br> - Here you specify the weta image like this:</p> - -<pre class="brush: json" dir="ltr">"images": { - "headerURL": "empty.png", - "additional_backgrounds": [ "weta_for_tiling.png"] -},</pre> - -<p dir="ltr">and the images tiling with:</p> - -<pre class="brush: json" dir="ltr">"properties": { - "additional_backgrounds_alignment": [ "top" ], - "additional_backgrounds_tiling": [ "repeat" ] -},</pre> - -<p>Full details of how to setup this theme can be found in the <a href="https://github.com/mdn/webextensions-examples/tree/master/themes">themes</a> example <a href="https://github.com/mdn/webextensions-examples/tree/master/themes/weta_tiled">weta_tiled</a>. Full detais of the alignment and tiling options can be found in the <a href="/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/theme">"theme" key description</a>.</p> - -<p>Alternatively, you can use multiple images, say combining the original weta image with this one anchored to the left of the header<br> - <img alt="An image of a weta (the common name for a group of about 70 insect species in the families Anostostomatidae and Rhaphidophoridae, endemic to New Zealand) with the right edge fading to total transparency." src="https://mdn.mozillademos.org/files/15223/weta-left.png" style="height: 200px; width: 406px;"><br> - to create this effect<br> - <img alt="A theme using the additional images option to place two mirrored image to the left and right of the browser header." src="https://mdn.mozillademos.org/files/15225/multi_image_theme.png" style="height: 113px; width: 679px;"></p> - -<p>Where the images are specified with:</p> - -<pre class="brush: json" dir="ltr">"images": { - "headerURL": "empty.png", - "additional_backgrounds": [ "weta.png", "weta-left.png"] -},</pre> - -<p dir="ltr">and their alignment by:</p> - -<pre class="brush: json" dir="ltr">"properties": { - "additional_backgrounds_alignment": [ "right top" , "left top" ] -},</pre> - -<p>Full details of how to setup this theme can be found in the <a href="https://github.com/mdn/webextensions-examples/tree/master/themes">themes</a> example <a href="https://github.com/mdn/webextensions-examples/tree/master/themes/weta_mirror">weta_mirror</a>. Full detais of the alignment options can be found in the <a href="/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/theme">"theme" key description</a>.</p> - -<h3 id="Static_animated_themes">Static animated themes</h3> - -<p>It is possible to create an animated theme using an APNG format image, as in the <a href="https://github.com/mdn/webextensions-examples/tree/master/themes">themes</a> example <a href="https://github.com/mdn/webextensions-examples/tree/master/themes/animated">animated</a>. However, remember that rapid animations, such as the one in the example might be too distracting for a practical theme.</p> - -<p dir="ltr">You can also animate themes programmatically, which we discuss in <a href="#Dynamic_themes">Dynamic themes</a>.</p> - -<h2 id="Temas_dinâmicos">Temas dinâmicos</h2> - -<p>As an alternative to defining a static theme, you can use the {{WebExtAPIRef("theme")}} API to control the theme used in Firefox from within a browser extension. There are a couple of use cases for this option:</p> - -<ul> - <li>To bundle a theme with a browser extension, as an added extra.</li> - <li>Create a dynamic theme that changes under programmatic control.</li> -</ul> - -<p>And, obviously, you can combine the two and bundle a programmatically controlled theme with your extension.</p> - -<p>Using the {{WebExtAPIRef("theme")}} API is straightforward. First, request "theme"<a href="/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions"> permission</a> in the extension's<a href="/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json"> manifest.json</a> file. Next, you build a JSON object containing the same information you would use in a static theme’s manifest.json, Finally, pass the JSON object in a {{WebExtAPIRef("theme.update()")}} call.</p> - -<p>For example, the following code, from the <a href="https://github.com/mdn/webextensions-examples/tree/master/dynamic-theme">dynamic theme example</a> defines the content for the day and night elements of the dynamic theme:</p> - -<pre class="brush: js" dir="ltr">const themes = { - 'day': { - images: { - headerURL: 'sun.jpg', - }, - colors: { - accentcolor: '#CF723F', - textcolor: '#111', - } - }, - 'night': { - images: { - headerURL: 'moon.jpg', - }, - colors: { - accentcolor: '#000', - textcolor: '#fff', - } - } -};</pre> - -<p>The theme.Theme object is then passed to {{WebExtAPIRef("theme.update()")}} to change the header theme, as in this code snippet from the same example:</p> - -<pre class="brush: js" dir="ltr">function setTheme(theme) { - if (currentTheme === theme) { - // No point in changing the theme if it has already been set. - return; - } - currentTheme = theme; - browser.theme.update(themes[theme]); -}</pre> - -<p dir="ltr">Learn more about dynamic themes and see an additional example in the following video:</p> - -<p dir="ltr">{{EmbedYouTube("ycckyrUN0AY")}}</p> - -<p dir="ltr"> </p> - -<p dir="ltr">If you have not built a browser extension before, check out <a href="/en-US/docs/Mozilla/Add-ons/WebExtensions/Your_first_WebExtension">Your first extension</a> for a step-by-step guide.</p> - -<h2 id="Compatibilidade_entre_navegadores">Compatibilidade entre navegadores</h2> - -<p>There is currently limited compatibility between themes in the major browsers. Opera takes an entirely different approach, and Microsoft Edge themes are not yet open to developers.</p> - -<p>There is some compatibility between Firefox static themes and Chrome themes, providing the ability to port a single header image theme from Firefox to Chrome. This would be done by amending the manifest.json keys as follows:</p> - -<ul> - <li><code>"headerURL":</code> to <code>"theme_frame":</code></li> - <li><code>"accentcolor":</code> to <code>"frame":</code></li> - <li><code>"textcolor":</code> to <code>"tab_text":</code></li> -</ul> - -<p>Noting that "frame": and "tab_text": support RGB color definition only.</p> - -<p>So, in the single image theme example (weta_fade) could be supported in Chrome using the following manifest.json file:</p> - -<pre class="brush: json" dir="ltr">{ - "manifest_version": 2, - "version": "1.0", - "name": "<your_theme_name>", - "theme": { - "images": { - "theme_frame": "weta.png" - }, - "colors": { - "frame": [ 173 , 176 , 159 ], - "tab_text": [ 0 , 0 , 0 ] - } - } -}</pre> - -<p>However, there will be a couple of differences:</p> - -<ul> - <li>Chrome tiles the <code>“theme_frame”:</code> image from the left of the header area.</li> - <li><code>"tab_text":</code> only affects the text on the highlighted/active tab.</li> -</ul> - -<p dir="ltr"><img alt="The basic theme example using the Chrome compatible manifest.json keys, showing the differences in how those keys are implemented." src="https://mdn.mozillademos.org/files/15227/basic_in_chrome.png" style="height: 113px; width: 679px;"></p> - -<p>For more information, see the notes on <a href="/en-US/Add-ons/WebExtensions/manifest.json/theme#Chrome_compatibility">Chrome compatibility</a>.</p> diff --git a/files/pt-pt/mozilla/add-ons/themes/index.html b/files/pt-pt/mozilla/add-ons/themes/index.html deleted file mode 100644 index 26dfb24673..0000000000 --- a/files/pt-pt/mozilla/add-ons/themes/index.html +++ /dev/null @@ -1,49 +0,0 @@ ---- -title: Temas -slug: Mozilla/Add-ons/Themes -tags: - - Apresentação e Disposição - - Extras - - Temas -translation_of: Mozilla/Add-ons/Themes ---- -<p>{{AddonSidebar}}</p> - -<p>Temas permite-lhe alterar a apresentação e disposição da interface do utilizador e personalizar a seu gosto. Saiba como criar e partilhar os temas!</p> - -<div class="column-container"> -<div class="column-half"> -<h2 class="Documentation" id="Documentation" name="Documentation">Temas de Navegador</h2> - -<dl> - <dt><a href="/en-US/docs/Mozilla/Add-ons/Themes/Theme_concepts">Browser theme concepts</a></dt> - <dd>Get an introduction to creating themes for the latest versions of Firefox</dd> -</dl> - -<h2 class="Documentation" id="Documentation" name="Documentation">Temas Simples</h2> - -<dl> - <dt><a href="/en-US/docs/Themes/Lightweight_themes" title="Themes/Lightweight themes">Lightweight themes</a></dt> - <dd>Building lightweight themes for Firefox</dd> - <dt><a href="/en-US/Add-ons/Themes/Lightweight_Themes/FAQ">Lightweight themes FAQ</a></dt> - <dd>Get answers to commonly asked questions</dd> -</dl> -</div> - -<div class="column-half"> -<h2 id="Ferramentas_e_Recursos">Ferramentas e Recursos</h2> - -<ul> - <li><a href="/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/theme">Browser theme manifest.json keys</a></li> - <li><a href="/en-US/docs/Mozilla/Add-ons/WebExtensions/API/theme">Browser extensions theme API</a></li> - <li><a href="http://vanillaorchidstutorials.blogspot.com/2015/11/mozilla-themes-focal-point-sizing.html">Lightweight themes tutorial</a></li> - <li><a href="https://discourse.mozilla.org/c/add-ons/themes">Discourse forum</a></li> - <li><a href="https://blog.mozilla.org/addons/category/personas/">Theme related blog posts</a></li> - <li><a href="/en-US/Mozilla/Add-ons/Themes/Obsolete">Archived resources</a></li> -</ul> -</div> -</div> - -<p> </p> - -<p> </p> diff --git a/files/pt-pt/mozilla/add-ons/themes/obsolete/creating_a_skin_for_firefox/index.html b/files/pt-pt/mozilla/add-ons/themes/obsolete/creating_a_skin_for_firefox/index.html deleted file mode 100644 index 9d187b7315..0000000000 --- a/files/pt-pt/mozilla/add-ons/themes/obsolete/creating_a_skin_for_firefox/index.html +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: Creating a Skin for Firefox -slug: Mozilla/Add-ons/Themes/Obsolete/Creating_a_Skin_for_Firefox -tags: - - Add-ons - - NeedsTranslation - - Themes - - TopicStub -translation_of: Archive/Themes/Creating_a_Skin_for_Firefox ---- -<h2 id="Introduction" name="Introduction">Introduction</h2> - -<p>In order to create a skin for Firefox, there are three things you need to know: how to edit images, how to extract zip files, and how to modify CSS. Firefox uses standard GIF, PNG, and JPEG images for the buttons and CSS to style everything else in the interface.</p> - -<h3 id="What_is_a_skin" name="What_is_a_skin">What is a skin?</h3> - -<p>A skin does not totally change the interface; instead, it just defines how the interface looks. You can't change what happens when the user right clicks on an image, but you can change the look of the right click menu (Make it blue with pink polka dots, for example). If you want to change the functionality of Firefox, you'll have to look into modifying the chrome, which is beyond the scope of this document.</p> - -<h2 id="Contents" name="Contents">Contents</h2> - -<ul> - <li><a href="/en-US/docs/Creating_a_Skin_for_Firefox_Getting_Started">Getting Started</a></li> -</ul> - -<div class="originaldocinfo"> -<h2 id="Original_Document_Information" name="Original_Document_Information">Informações Sobre o Documento Original</h2> -<ul> -<li>Autor(es): Neil Marshall and Tucker Lee</li> -<li>Outros Contribuidores: Brent Marshall, CDN (http://themes.mozdev.org), JP Martin, Boris Zbarsky, Asa Dotzler, WeSaySo, David James, Dan Mauch, Anders Conbere, Tim Regula (http://www.igraphics.nn.cx)</li> -<li>Informações sobre Copyright: Copyright 2002-2003 Neil Marshall, permission given to MDC to migrate into the wiki April 2005 via email.</li> -<li>Original Location: <a class="external" href="http://www.eightlines.com/neil/mozskin" rel="noopener">http://www.eightlines.com/neil/mozskin</a></li> -</ul> -</div> diff --git a/files/pt-pt/mozilla/add-ons/themes/obsolete/index.html b/files/pt-pt/mozilla/add-ons/themes/obsolete/index.html deleted file mode 100644 index d420b6ebf0..0000000000 --- a/files/pt-pt/mozilla/add-ons/themes/obsolete/index.html +++ /dev/null @@ -1,10 +0,0 @@ ---- -title: Obsolete -slug: Mozilla/Add-ons/Themes/Obsolete -tags: - - NeedsTranslation - - TopicStub -translation_of: Mozilla/Add-ons/Themes/Obsolete ---- -<p>This page collects theme docs that we don't expect will ever be updated, but which we're keeping for the time being as potential source material for updated docs.</p> -<p>{{ ListSubPages ("/en-US/Add-ons/Themes/Obsolete", 5) }}</p> diff --git a/files/pt-pt/mozilla/add-ons/thunderbird/index.html b/files/pt-pt/mozilla/add-ons/thunderbird/index.html deleted file mode 100644 index b15b535a59..0000000000 --- a/files/pt-pt/mozilla/add-ons/thunderbird/index.html +++ /dev/null @@ -1,135 +0,0 @@ ---- -title: Thunderbird extensions -slug: Mozilla/Add-ons/Thunderbird -tags: - - Add-ons - - Extensions - - NeedsTranslation - - TopicStub - - thunderbird -translation_of: Mozilla/Thunderbird/Thunderbird_extensions ---- -<div class="callout-box"><strong><a href="/en/Extensions/Thunderbird/Building_a_Thunderbird_extension" title="en/Building_a_Thunderbird_extension">Building a Thunderbird extension</a></strong><br> -Step-by-step explanation on how to build an extension for Thunderbird.</div> - -<div> -<p>{{AddonSidebar}}</p> -The following documentation provides help for creating extensions for Mozilla's <a class="internal" href="/en/Thunderbird" title="En/Thunderbird">Thunderbird</a> email client. Although there are many similarities with <a href="/en/Extensions" title="en/Extensions">Firefox extensions</a> there are also some differences that may confound the starting developer.</div> - -<div><br> -<strong>Please help!</strong> You can <a class="internal" href="/en/Extensions/Thunderbird/HowTos" title="en/Extensions/Thunderbird/HowTos">add a how-to</a> (a question or an answer or a code snippet), <a class="internal" href="/en/Extensions/Thunderbird/Useful_newsgroups_discussions" title="En/Extensions/Thunderbird/Useful newsgroups discussions">summarize and link to a relevant newsgroup discussion</a>, or create a tutorial. Need help? Contact <a class="internal" href="/User:jenzed" title="User:jenzed">jenzed</a>.</div> - -<table class="topicpage-table"> - <tbody> - <tr> - <td> - <h2 id="Documentation" name="Documentation"><a href="/Special:Tags?tag=Extensions&language=en" title="Special:Tags?tag=Extensions&language=en">Documentation</a></h2> - - <h3 id="Getting_started_with_Thunderbird">Getting started with Thunderbird</h3> - - <p>A brave, young developer wants to develop an add-on for Thunderbird. Here's a few links to help them through this journey.</p> - - <ul> - <li>Start by reading the tutorial and learn how to<a class="internal" href="/en/Extensions/Thunderbird/Building_a_Thunderbird_extension" title="En/Building a Thunderbird extension"> build a Thunderbird extension</a> (Outdated, still talks about overlays and the add-on builder is no longer available but the tutorial has not been updated.)</li> - <li>Read about the <a href="/en/Thunderbird/Main_Windows" title="Main Windows">main windows</a> so that you know what one means when they say « thread pane », « preview pane », and « folder pane ».</li> - - <li>Want to do some real stuff? See <a class="external" href="http://blog.xulforum.org/index.php?post/2011/03/14/Basic-MimeMessage-demo" title="http://blog.xulforum.org/index.php?post/2011/03/14/Basic-MimeMessage-demo">how to inspect a message</a> (demo add-on included!)</li> - <li>Play with our other <a href="/en/Extensions/Thunderbird/Demo_Addon" title="Demo Addon">demo add-on</a> that exercises some more advanced Thunderbird-specific features</li> - <li>Want to do even more stuff? Don't reinvent the wheel: steal functions from the <a class="link-https" href="https://github.com/protz/thunderbird-stdlib" title="https://github.com/protz/thunderbird-stdlib">thunderbird-stdlib</a> project (doc <a class="external" href="http://protz.github.com/thunderbird-stdlib/doc/symbols/_global_.html" title="http://protz.github.com/thunderbird-stdlib/doc/symbols/_global_.html">here</a>). Functions for dealing with messages (delete them, archive them, change their tags, etc.) are included.</li> - <li>Haven't found what you're looking for? Read the <a class="internal" href="/en/Extensions/Thunderbird/HowTos" rel="internal" title="en/Extensions/Thunderbird/HowTos">Thunderbird how-tos</a>; they contain a lot of recipes for things extensions want to do.</li> - <li>Still haven't managed to do what you wanted? See the list of all <a class="external" href="http://wiki.mozilla.org/Thunderbird/CommunicationChannels" title="http://wiki.mozilla.org/Thunderbird/CommunicationChannels">Thunderbird communication channels </a>so that you know where to ask when you get stuck :-).</li> - <li>Feeling really brave? Read the source using a <a class="external" href="http://doxygen.db48x.net/comm-central/html/" title="http://doxygen.db48x.net/comm-central/html/">fancy interface</a>; you can often find tests that demonstrate how to do what you're trying to achieve.</li> - </ul> - - <h3 id="The_Gloda_database">The Gloda database</h3> - - <p>Thunderbird has a subsystem called Gloda. Gloda stands for « Global Database », and creates Thunderbird-wide relations between objects. Gloda provides concepts such as Conversations, Messages, Identities, Contacts. All these concepts are related together: a Conversation contains Messages which are linked to Identities (<strong>from</strong> field, <strong>to</strong> field) which are themselves part of a Contact: indeed, a contact has multiple identities.</p> - - <p>Typical use cases for Gloda: find all messages whose subject matches [search term], find all messages from [person], find all messages in the same thread as [a given message], find all messages involving [person], etc. etc.</p> - - <p>Gloda is extremely powerful and is used heavily by add-ons such as <a class="link-https" href="https://addons.mozilla.org/en-US/thunderbird/addon/gmail-conversation-view/" title="https://addons.mozilla.org/en-US/thunderbird/addon/gmail-conversation-view/">Thunderbird Conversations</a>. Learn more about Gloda:</p> - - <ul> - <li>an overview of <a href="/en/Thunderbird/gloda" title="Gloda">Gloda</a></li> - <li>learn how to create <a href="/en/Thunderbird/Creating_a_Gloda_message_query" title="Creating a gloda message query">your first message query</a> and read the <a href="/en/Thunderbird/Gloda_examples" title="Gloda examples">gloda examples</a></li> - <li>learn about the Gloda internals: <a href="/en/Thunderbird/Gloda_debugging" title="Gloda debugging">Gloda debugging</a>, <a href="/en/Thunderbird/Gloda_indexing" title="Gloda indexing">Gloda indexing</a></li> - </ul> - - <h3 id="More_Thunderbird-specific_links">More Thunderbird-specific links</h3> - - <p>Some of these links may be wildly out of date, but they still provide valuable information on the codebase.</p> - - <ul> - <li><a class="internal" href="/en/Extensions/Thunderbird/An_overview_of_the_Thunderbird_interface" title="En/Extensions/Thunderbird/An overview of the Thunderbird interface">An overview of Thunderbird components</a></li> - <li><a class="internal" href="/en/Extensions/Thunderbird/Thunderbird_developer_reference_docs" title="en/Extensions/Thunderbird/Thunderbird developer reference docs">Developer reference docs</a>: - <ul> - <li><a class="internal" href="/en/Folders" title="En/Folders">Folder classes</a></li> - <li><a class="internal" href="/en/DB_Views_(message_lists)" title="En/DB Views (message lists)">DB views (message list)</a></li> - <li><a class="internal" href="/en/Message_Summary_Database" title="En/Message Summary Database">Message summary database</a></li> - <li><a class="internal" href="/en/MailNews_Protocols" title="En/MailNews Protocols">MailNews protocols</a></li> - <li><a class="internal" href="/En/MailNews_Filters" rel="internal" title="En/MailNews Filters">MailNews filters</a></li> - <li><a class="internal" href="/en/Extensions/Thunderbird/Error_reporting_tools" title="en/Extension Library/Extensions/Thunderbird/Error reporting tools">Error reporting tools</a></li> - <li><a href="/en/Toolkit_API/STEEL" title="en/Toolkit API/STEEL">STEEL library</a> (obsolete as of Thunderbird 52, use <a class="link-https" href="https://github.com/protz/thunderbird-stdlib" title="https://github.com/protz/thunderbird-stdlib">https://github.com/protz/thunderbird-stdlib</a>)</li> - <li><a class="external" href="http://quetzalcoatal.blogspot.com/2010/01/developing-new-account-types-part-0.html" title="http://quetzalcoatal.blogspot.com/2010/01/developing-new-account-types-part-0.html">Developing new account types</a> <strong>NEW!</strong></li> - </ul> - </li> - <li><a class="internal" href="/en/Extensions/Thunderbird/Useful_newsgroups_discussions" title="En/Extensions/Thunderbird/Useful newsgroups discussions">Useful newsgroup discussions</a> (watch out, anything that's too old should be regarded suspiciously; there's been significant API rewrite over the past years, and most of these techniques are considerably easier now) </li> - <li><a href="/en/Thunderbird/Thunderbird_API_documentation" title="en/Thunderbird/Thunderbird API documentation">Thunderbird API docs</a> (mostly a collection of out-of-date pages, relevance is rather dubious) </li> - <li><a href="/en/Mozilla/Thunderbird/Releases" title="Thunderbird developer release notes">Thunderbird developer release notes</a> - changes in the recent Thunderbird updates affecting add-on developers. <a href="/Thunderbird_5_for_developers" title="Thunderbird 5 for developers">Thunderbird 5 for developers</a> has important information on MsgHdrToMimeMessage which is a central piece of code.</li> - </ul> - - <h3 id="General_links">General links</h3> - - <ul> - <li><a href="/en/Extensions/Thunderbird/Finding_the_code_for_a_feature" title="en/Extensions/Thunderbird/Finding the code for a feature">Finding the code for a feature</a></li> - <li><a class="external" href="http://kb.mozillazine.org/Category:Thunderbird" title="http://kb.mozillazine.org/Category:Thunderbird">Mozillazine articles on Thunderbird</a></li> - <li><a href="/Special:Tags?tag=Thunderbird" title="https://developer.mozilla.org/Special:Tags?tag=Thunderbird">All pages tagged with Thunderbird</a></li> - <li><a href="/Special:Tags?tag=MailNews" title="https://developer.mozilla.org/Special:Tags?tag=MailNews">All pages tagged with MailNews</a></li> - </ul> - </td> - <td> - <h2 id="Community" name="Community">Community</h2> - - <ul> - <li>See the list of all <a class="external" href="http://wiki.mozilla.org/Thunderbird/CommunicationChannels" title="http://wiki.mozilla.org/Thunderbird/CommunicationChannels">Thunderbird communication channels </a>first</li> - <li>Among these are:</li> - </ul> - - <p>{{ DiscussionList("dev-extensions", "mozilla.dev.extensions") }}</p> - - <ul> - <li><a class="link-irc" href="irc://moznet/#extdev">#extdev IRC channel</a> / <a class="link-irc" href="irc://moznet/#maildev">#maildev IRC channel</a></li> - <li><a class="external" href="http://forums.mozillazine.org/viewforum.php?f=19">MozillaZine forum</a></li> - <li><a class="external" href="http://mozdev.org/mailman/listinfo/project_owners">mozdev project owners</a></li> - <li><a href="/en/Extensions/Community" title="en/Extensions/Community">Other community links...</a></li> - </ul> - - <h2 id="Tools" name="Tools">Tools</h2> - - <ul> - <li><a class="link-https" href="https://addons.mozilla.org/en-US/firefox/addon/6622" rel="external nofollow" title="https://addons.mozilla.org/en-US/firefox/addon/6622">DOM Inspector</a> edit the live DOM (Firefox and Thunderbird)</li> - <li><a class="link-https" href="https://addons.mozilla.org/thunderbird/addon/workspace-for-thunderbird/" title="https://addons.mozilla.org/thunderbird/addon/workspace-for-thunderbird/">Workspace for Thunderbird</a>, allows running code snippets in Thunderbird and inspecting variable structure and content</li> - <li><a class="external" href="http://www.hacksrus.com/~ginda/venkman/" rel="external nofollow" title="http://www.hacksrus.com/~ginda/venkman/">Venkman</a>, a JavaScript debugger (<a class="external" href="http://addons.mozilla.org/en-US/firefox/addon/216" rel="external nofollow" title="http://addons.mozilla.org/en-US/firefox/addon/216">Firefox</a>, <a class="external" href="http://addons.mozilla.org/en-US/thunderbird/addon/216" rel="external nofollow" title="http://addons.mozilla.org/en-US/thunderbird/addon/216">Thunderbird</a>)</li> - <li><a class="link-https" href="https://addons.mozilla.org/en-US/firefox/addon/7434/" rel="external nofollow" title="https://addons.mozilla.org/en-US/firefox/addon/7434/">Extension Developer's Extension</a> a suite of development tools</li> - <li><a class="external" href="http://www.gijsk.com/" rel="external nofollow" title="http://www.gijsk.com/">Chrome List</a> view files in chrome:// (<a class="external" href="http://addons.mozilla.org/en-US/firefox/addon/4453" rel="external nofollow" title="http://addons.mozilla.org/en-US/firefox/addon/4453">Firefox</a>, <a class="external" href="http://addons.mozilla.org/en-US/thunderbird/addon/4453" rel="external nofollow" title="http://addons.mozilla.org/en-US/thunderbird/addon/4453">Thunderbird</a>)</li> - <li><a href="/en/Mozmill" title="en/Mozmill">Mozmill</a> test tool and framework</li> - <li><a class="external" href="http://xpcomviewer.mozdev.org/" rel="external nofollow" title="http://xpcomviewer.mozdev.org">XPCOMViewer</a> an XPCOM inspector (Firefox and Thunderbird)</li> - </ul> - - <p>... <a class="internal" href="/en/Setting_up_extension_development_environment#Development_extensions" title="en/Setting up extension development environment#Development extensions">more tools</a> ...</p> - - <p><span class="alllinks"><a href="/Special:Tags?tag=Extensions:Tools&language=en" title="Special:Tags?tag=Extensions:Tools&language=en">View All...</a></span></p> - - <h2 id="Related_Topics" name="Related_Topics">Related Topics</h2> - - <dl> - <dd><a href="/en/XUL" title="en/XUL">XUL</a>, <a href="/en/JavaScript" title="en/JavaScript">JavaScript</a>, <a href="/en/XPCOM" title="en/XPCOM">XPCOM</a>, <a href="/en/Themes" title="en/Themes">Themes</a>, <a href="/En/Developer_Guide" title="en/Developing_Mozilla">Developing Mozilla</a></dd> - </dl> - </td> - </tr> - </tbody> -</table> - -<p><span class="comment">Categories</span></p> - -<p>{{ languages( { "ja": "ja/Extensions/Thunderbird" } ) }}</p> |