Ir para o conteúdo principal

September 2016: New Apps

· Leitura de 3 minutos

Here are the new Electron apps and talks that were added to the site in September.


This site is updated with new apps and meetups through pull requests from the community. You can watch the repository to get notifications of new additions or if you're not interested in all of the site's changes, subscribe to the blog RSS feed.

If you've made an Electron app or host a meetup, make a pull request to add it to the site and it will make the next roundup.

New Talks

In September, GitHub held its GitHub Universe conference billed as the event for people building the future of software. There were a couple of interesting Electron talks at the event.

Also, if you happen to be in Paris on December 5, Zeke will be giving an Electron talk at dotJS 2016.

New Apps

PexelsSearch for completely free photos and copy them into your clipboard
TimestampA better macOS menu bar clock with a customizable date/time display and a calendar
HarmonyMusic player compatible with Spotify, Soundcloud, Play Music and your local files
uPhoneWebRTC Desktop Phone
SealTalkInstant-messaging App powered by RongCloud IM Cloud Service and IM SDK
InfinityAn easy way to make presentation
Cycligent Git ToolStraightforward, graphic GUI for your Git projects
FocoStay focused and boost productivity with Foco
StrawberryWin Diners for Life Know and serve them better with the all-in-one restaurant software suite.
MixmaxSee every action on your emails in real-time Compose anywhere.
Firebase AdminA Firebase data management tool
ANoteA Simple Friendly Markdown Note
TempsA simple but smart menubar weather app
AmiumA work collaboration product that brings conversation to your files
SoubeSimple music player
(Un)coloredNext generation desktop rich content editor that saves documents with themes HTML & Markdown compatible. For Windows, OS X & Linux.
quickcalcMenubar Calculator
Forestpin AnalyticsFinancial data analytics tool for businesses
LingREST Client
ShortextsShortcuts for texts you copy frequently, folders and emojis
Front-End BoxSet of front-end-code generators

Electron's API Docs as Structured Data

· Leitura de 3 minutos

Today we're announcing some improvements to Electron's documentation. Every new release now includes a JSON file that describes all of Electron's public APIs in detail. We created this file to enable developers to use Electron's API documentation in interesting new ways.


Schema overview

Each API is an object with properties like name, description, type, etc. Classes such as BrowserWindow and Menu have additional properties describing their instance methods, instance properties, instance events, etc.

Here's an excerpt from the schema that describes the BrowserWindow class:

{
nome: 'BrowserWindow',
descrição: 'Criar e controlar janelas de navegador. ,
processo: {
main: true,
renderer: false
},
tipo: 'Class',
instância: 'win',
slug: 'browser-window',
websiteUrl: 'https://electronjs. rg/docs/api/browser-window',
repoUrl: 'https://github.com/electron/electron/blob/v1.4.0/docs/api/browser-window. d',
Métodos estáticos: [...],
exemploMédios: [...],
instâncias: [...],
eventos: [...]
}
}

And here's an example of a method description, in this case the apis.BrowserWindow.instanceMethods.setMaximumSize instance method:

{
name: 'setMaximumSize',
signature: '(width, height)',
description: 'Sets the maximum size of window to width and height.',
parameters: [{
name: 'width',
type: 'Integer'
}, {
name: 'height',
type: 'Integer'
}]
}

Using the new data

To make it easy for developers to use this structured data in their projects, we've created electron-docs-api, a small npm package that is published automatically whenever there's a new Electron release.

npm install electron-api-docs --save

For instant gratification, try out the module in your Node.js REPL:

npm i -g trymodule && trymodule electron-api-docs=apis

How the data is collected

Electron's API documentation adheres to Electron Coding Style and the Electron Styleguide, so its content can be programmatically parsed.

The electron-docs-linter is a new development dependency of the electron/electron repository. It is a command-line tool that lints all the markdown files and enforces the rules of the styleguide. If errors are found, they are listed and the release process is halted. If the API docs are valid, the electron-json.api file is created and uploaded to GitHub as part of the Electron release.

Standard Javascript and Standard Markdown

Earlier this year, Electron's codebase was updated to use the standard linter for all JavaScript. Standard's README sums up the reasoning behind this choice:

Adopting standard style means ranking the importance of code clarity and community conventions higher than personal style. This might not make sense for 100% of projects and development cultures, however open source can be a hostile place for newbies. Setting up clear, automated contributor expectations makes a project healthier.

We also recently created standard-markdown to verify that all the JavaScript code snippets in our documentation are valid and consistent with the style in the codebase itself.

Together these tools help us use continuous integration (CI) to automatically find errors in pull requests. This reduces the burden placed on humans doing code review, and gives us more confidence about the accuracy of our documentation.

A community effort

Electron's documentation is constantly improving, and we have our awesome open-source community to thank for it. As of this writing, nearly 300 people have contributed to the docs.

We're excited to see what people do with this new structured data. Possible uses include:

Electron Internals: Weak References

· Leitura de 6 minutos

As a language with garbage collection, JavaScript frees users from managing resources manually. But because Electron hosts this environment, it has to be very careful avoiding both memory and resources leaks.

This post introduces the concept of weak references and how they are used to manage resources in Electron.


Weak references

In JavaScript, whenever you assign an object to a variable, you are adding a reference to the object. As long as there is a reference to the object, it will always be kept in memory. Once all references to the object are gone, i.e. there are no longer variables storing the object, the JavaScript engine will recoup the memory on next garbage collection.

A weak reference is a reference to an object that allows you to get the object without effecting whether it will be garbage collected or not. You will also get notified when the object is garbage collected. It then becomes possible to manage resources with JavaScript.

Using the NativeImage class in Electron as an example, every time you call the nativeImage.create() API, a NativeImage instance is returned and it is storing the image data in C++. Once you are done with the instance and the JavaScript engine (V8) has garbage collected the object, code in C++ will be called to free the image data in memory, so there is no need for users manage this manually.

Outro exemplo é a janela desaparecendo do problema, que visualmente mostra como a janela é armazenada quando todas as referências a ela se foram.

Testing weak references in Electron

There is no way to directly test weak references in raw JavaScript since the language doesn't have a way to assign weak references. The only API in JavaScript related to weak references is WeakMap, but since it only creates weak-reference keys, it is impossible to know when an object has been garbage collected.

In versions of Electron prior to v0.37.8, you can use the internal v8Util.setDestructor API to test weak references, which adds a weak reference to the passed object and calls the callback when the object is garbage collected:

// O código abaixo só pode ser executado no Electron < v0.37.8.
var v8Util = process.atomBinding('v8_util');

var object = {};
v8Util.setDestructor(object, function () {
console.log('The object is garbage collected');
});

// Remove all references to the object.
object = undefined;
// Manually starts a GC.
gc();
// Console prints "The object is garbage collected".

Note that you have to start Electron with the --js-flags="--expose_gc" command switch to expose the internal gc function.

The API was removed in later versions because V8 actually does not allow running JavaScript code in the destructor and in later versions doing so would cause random crashes.

Weak references in the remote module

Apart from managing native resources with C++, Electron also needs weak references to manage JavaScript resources. Um exemplo é o módulo remotodo Electron, , que é um módulo de Procedimento Remoto (RPC) que permite o uso de objetos no processo principal a partir de processos de renderização.

One key challenge with the remote module is to avoid memory leaks. When users acquire a remote object in the renderer process, the remote module must guarantee the object continues to live in the main process until the references in the renderer process are gone. Additionally, it also has to make sure the object can be garbage collected when there are no longer any reference to it in renderer processes.

For example, without proper implementation, following code would cause memory leaks quickly:

const { remote } = require('electron');

for (let i = 0; i < 10000; ++i) {
remote.nativeImage.createEmpty();
}

The resource management in the remote module is simple. Whenever an object is requested, a message is sent to the main process and Electron will store the object in a map and assign an ID for it, then send the ID back to the renderer process. In the renderer process, the remote module will receive the ID and wrap it with a proxy object and when the proxy object is garbage collected, a message will be sent to the main process to free the object.

Using remote.require API as an example, a simplified implementation looks like this:

remote.require = function (name) {
// Tell the main process to return the metadata of the module.
const meta = ipcRenderer.sendSync('REQUIRE', name);
// Create a proxy object.
const object = metaToValue(meta);
// Tell the main process to free the object when the proxy object is garbage
// collected.
v8Util.setDestructor(object, function () {
ipcRenderer.send('FREE', meta.id);
});
return object;
};

No processo main:

const map = {};
const id = 0;

ipcMain.on('REQUIRE', function (event, name) {
const object = require(name);
// Add a reference to the object.
map[++id] = object;
// Convert the object to metadata.
event.returnValue = valueToMeta(id, object);
});

ipcMain.on('FREE', function (event, id) {
delete map[id];
});

Maps with weak values

With the previous simple implementation, every call in the remote module will return a new remote object from the main process, and each remote object represents a reference to the object in the main process.

The design itself is fine, but the problem is when there are multiple calls to receive the same object, multiple proxy objects will be created and for complicated objects this can add huge pressure on memory usage and garbage collection.

For example, the following code:

const { remote } = require('electron');

for (let i = 0; i < 10000; ++i) {
remote.getCurrentWindow();
}

It first uses a lot of memory creating proxy objects and then occupies the CPU (Central Processing Unit) for garbage collecting them and sending IPC messages.

An obvious optimization is to cache the remote objects: when there is already a remote object with the same ID, the previous remote object will be returned instead of creating a new one.

This is not possible with the API in JavaScript core. Using the normal map to cache objects will prevent V8 from garbage collecting the objects, while the WeakMap class can only use objects as weak keys.

To solve this, a map type with values as weak references is added, which is perfect for caching objects with IDs. Now the remote.require looks like this:

const remoteObjectCache = v8Util.createIDWeakMap()

remote.require = function (name) {
// Tell the main process to return the meta data of the module.
...
if (remoteObjectCache.has(meta.id))
return remoteObjectCache.get(meta.id)
// Create a proxy object.
...
remoteObjectCache.set(meta.id, object)
return object
}

Note that the remoteObjectCache stores objects as weak references, so there is no need to delete the key when the object is garbage collected.

Native code

For people interested in the C++ code of weak references in Electron, it can be found in following files:

The setDestructor API:

The createIDWeakMap API:

August 2016: New Apps

· Leitura de 3 minutos

Here are the new Electron apps that were added to the site in August.


The site is updated with new apps and meetups through pull requests from the community. You can watch the repository to get notifications of new additions or if you're not interested in all of the site's changes, subscribe to the blog RSS feed.

If you've made an Electron app or host a meetup, make a pull request to add it to the site and it will make the next roundup.

New Apps

Code RPGifyRPG style coding application
PamFaxA cross-platform app for sending and receiving faxes
BlankUpMarkdown editor witch clarity +1
RamboxFree and Open Source messaging and emailing app that combines common web applications into one
GordieThe best app for your card collections
Ionic CreatorBuild amazing mobile apps, faster
TwitchAlertsKeep your viewers happy with beautiful alerts and notifications
MuseeksA simple, clean and cross-platform music player
SeaPigA converter from markdown to html
GroupMeUnofficial GroupMe App
MoeditorYour all-purpose markdown editor
SoundnodeSoundnode App is the Soundcloud for desktop
QMUI WebQMUI Web Desktop is an application for managing projects based on QMUI Web Framework
SvgsusOrganize, clean and transform your SVGs
RammeUnofficial Instagram Desktop App
InsomniaREST API Client
CorreoA menubar/taskbar Gmail App for Windows, macOS and Linux
KongDashDesktop client for Kong Admin API
Translation EditorTranslation files editor for INTL ICU messages (see formatjsio)
5EClient5EPlay CSGO Client
Theme JuiceLocal WordPress development made easy

Ferramentas de acessibilidade

· Leitura de 2 minutos

Desenvolver aplicativos acessíveis é importante, e ficamos contentes em introduzir novas funcionalidades ao Devtron e ao Spectron, que oferecem aos desenvolvedores a oportunidade de fazerem seus apps melhores para todos.


As questões de acessibilidade em aplicativos Electron são semelhantes às de sites na Web, já que ambos usam HTML. No entanto, com apps Electron, você não pode usar recursos online para auditorias de acessibilidade, já que seu app não tem um URL para o auditor poder acessá-lo.

Esses novos recursos trazem essas ferramentas de auditoria para seu app Electron. Esses novos recursos trazem essas ferramentas de auditoria para seu app Electron. Leia para ver um resumo das ferramentas ou verifique nossa documentação de acessibilidade para mais informações.

Spectron

No framework de testes Spectron, agora você pode auditar cada janela e <webview> tag em seu aplicativo. Como por exemplo:

app.client.auditAccessibility().then(function (audit) {
if (audit.failed) {
console.error(audit.message);
}
});

Você pode ler mais sobre esse recurso na documentação do Spectron.

Devtron

No Devtron, há uma nova aba de acessibilidade que te permite auditar uma página em seu app, classificar e filtrar resultados.

captura de tela do devtron

Ambas essas ferramentas usam a biblioteca Ferramentas de acessibilidade para desenvolvedores, feita para o Google Chrome. Você pode aprender mais sobre as regras de auditoria de acessibilidade que essa biblioteca usa na wiki do repositório.

Se você conhece outras ótimas ferramentas de acessibilidade para Electron, adicione-as à documentação de acessibilidade com um pull request.

npm install electron

· Leitura de 3 minutos

As of Electron version 1.3.1, you can npm install electron --save-dev to install the latest precompiled version of Electron in your app.


npm install electron

The prebuilt Electron binary

If you've ever worked on an Electron app before, you've likely come across the electron-prebuilt npm package. This package is an indispensable part of nearly every Electron project. When installed, it detects your operating system and downloads a prebuilt binary that is compiled to work on your system's architecture.

The new name

The Electron installation process was often a stumbling block for new developers. Many brave people tried to get started developing an Electron by app by running npm install electron instead of npm install electron-prebuilt, only to discover (often after much confusion) that it was not the electron they were looking for.

This was because there was an existing electron project on npm, created before GitHub's Electron project existed. To help make Electron development easier and more intuitive for new developers, we reached out to the owner of the existing electron npm package to ask if he'd be willing to let us use the name. Luckily he was a fan of our project, and agreed to help us repurpose the name.

Prebuilt lives on

As of version 1.3.1, we have begun publishing electron and electron-prebuilt packages to npm in tandem. The two packages are identical. We chose to continue publishing the package under both names for a while so as not to inconvenience the thousands of developers who are currently using electron-prebuilt in their projects. We recommend updating your package.json files to use the new electron dependency, but we will continue releasing new versions of electron-prebuilt until the end of 2016.

The electron-userland/electron-prebuilt repository will remain the canonical home of the electron npm package.

Many thanks

We owe a special thanks to @mafintosh, @maxogden, and many other contributors for creating and maintaining electron-prebuilt, and for their tireless service to the JavaScript, Node.js, and Electron communities.

And thanks to @logicalparadox for allowing us to take over the electron package on npm.

Updating your projects

We've worked with the community to update popular packages that are affected by this change. Packages like electron-packager, electron-rebuild, and electron-builder have already been updated to work with the new name while continuing to support the old name.

If you encounter any problems installing this new package, please let us know by opening an issue on the electron-userland/electron-prebuilt repository.

For any other issues with Electron, please use the electron/electron repository.

Electron Internals: Using Node as a Library

· Leitura de 4 minutos

This is the second post in an ongoing series explaining the internals of Electron. Check out the first post about event loop integration if you haven't already.

Most people use Node for server-side applications, but because of Node's rich API set and thriving community, it is also a great fit for an embedded library. This post explains how Node is used as a library in Electron.


Sistema de criação

Tanto o Node quanto o Electron usam GYP como sistemas de compilação. If you want to embed Node inside your app, you have to use it as your build system too.

New to GYP? Leia este guia antes de continuar mais nesta publicação.

Node's flags

O nó . o arquivo yp no diretório de código fonte do Node descreve como o Node é criado, junto com várias variáveis do GYP controlando quais partes do nó estão habilitadas e se devem abrir certas configurações.

To change the build flags, you need to set the variables in the .gypi file of your project. The configure script in Node can generate some common configurations for you, for example running ./configure --shared will generate a config.gypi with variables instructing Node to be built as a shared library.

Electron does not use the configure script since it has its own build scripts. As configurações para o Node são definidas no arquivo common.gypi no diretório do código fonte raiz do Electron.

In Electron, Node is being linked as a shared library by setting the GYP variable node_shared to true, so Node's build type will be changed from executable to shared_library, and the source code containing the Node's main entry point will not be compiled.

Since Electron uses the V8 library shipped with Chromium, the V8 library included in Node's source code is not used. This is done by setting both node_use_v8_platform and node_use_bundled_v8 to false.

Shared library or static library

When linking with Node, there are two options: you can either build Node as a static library and include it in the final executable, or you can build it as a shared library and ship it alongside the final executable.

In Electron, Node was built as a static library for a long time. This made the build simple, enabled the best compiler optimizations, and allowed Electron to be distributed without an extra node.dll file.

No entanto, isto mudou depois que o Chrome mudou para usar o BoringSSL. BoringSSL é um fork do OpenSSL que remove várias APIs não utilizadas e altera muitas interfaces existentes. Because Node still uses OpenSSL, the compiler would generate numerous linking errors due to conflicting symbols if they were linked together.

O Electron não pôde usar BoringSSL no Node, ou usar o OpenSSL no Chromium, então a única opção era mudar para construir o Node como uma biblioteca compartilhada, e esconde os símbolos BoringSSL e OpenSSL nos componentes de cada um.

This change brought Electron some positive side effects. Before this change, you could not rename the executable file of Electron on Windows if you used native modules because the name of the executable was hard coded in the import library. After Node was built as a shared library, this limitation was gone because all native modules were linked to node.dll, whose name didn't need to be changed.

Supporting native modules

Módulos nativos no Node funcionam definindo uma função de entrada para carregar o Node e, em seguida, pesquisando os símbolos da V8 e da libuv do Node. This is a bit troublesome for embedders because by default the symbols of V8 and libuv are hidden when building Node as a library and native modules will fail to load because they cannot find the symbols.

So in order to make native modules work, the V8 and libuv symbols were exposed in Electron. For V8 this is done by forcing all symbols in Chromium's configuration file to be exposed. Para libuv, é alcançado definindo a definição BUILDING_UV_SHARED=1.

Starting Node in your app

After all the work of building and linking with Node, the final step is to run Node in your app.

Node doesn't provide many public APIs for embedding itself into other apps. Geralmente, você pode apenas chamar node::Start e node::Init para iniciar uma nova instância do Node. However, if you are building a complex app based on Node, you have to use APIs like node::CreateEnvironment to precisely control every step.

In Electron, Node is started in two modes: the standalone mode that runs in the main process, which is similar to official Node binaries, and the embedded mode which inserts Node APIs into web pages. The details of this will be explained in a future post.

July 2016: New Apps and Meetups

· Leitura de 2 minutos

We're starting a monthly roundup to highlight activity in the Electron community. Each roundup will feature things like new apps, upcoming meetups, tools, videos, etc.


This site is updated with new apps and meetups through pull requests from the community. You can watch the repository to get notifications of new additions or if you're not interested in all of the site's changes, subscribe to the blog RSS feed.

If you've made an Electron app or host a meetup, make a pull request to add it to the site and it will make the next roundup.

New Apps

DemioA Webinar platform built for inbound sales and marketing
ElectorrentA remote client app for uTorrent server
PhoneGapThe open source framework that gets you building amazing mobile apps using web technology
WordMarkA lightweight blog publishing editor for Markdown writers
UbAuthApp to help developers create access tokens for Uber applications with OAuth 2.0
HyperTermHTML/JS/CSS terminal
MarpMarkdown presentation writer
Glyphr StudioA free, web based font designer, focusing on font design for hobbyists
BitCryptA simple file encryption application for Windows Encrypt your bits
TrymBeautiful small app for macOS to help you view, optimize and convert SVG icons
BookerText editor with the power of Markdown
PhonePresenterThe smartest presentation clicker
YoutThe new way to watch your playlists from YouTube on desktop

New Meetups

Electron Open Source Desktop FrameworkLondon, UK

Electron Internals: Message Loop Integration

· Leitura de 3 minutos

This is the first post of a series that explains the internals of Electron. This post introduces how Node's event loop is integrated with Chromium in Electron.


Houve muitas tentativas de usar o Node para a programação da GUI, como node-gui para ligações GTK+, e node-qt para ligações de TQ. But none of them work in production because GUI toolkits have their own message loops while Node uses libuv for its own event loop, and the main thread can only run one loop at the same time. So the common trick to run GUI message loop in Node is to pump the message loop in a timer with very small interval, which makes GUI interface response slow and occupies lots of CPU resources.

During the development of Electron we met the same problem, though in a reversed way: we had to integrate Node's event loop into Chromium's message loop.

The main process and renderer process

Before we dive into the details of message loop integration, I'll first explain the multi-process architecture of Chromium.

No Electron existem dois tipos de processos: o processo principal e o processo de renderização (isso é realmente extremamente simplificado, para uma visualização completa, por favor veja Arquitetura Multiprocesso). The main process is responsible for GUI work like creating windows, while the renderer process only deals with running and rendering web pages.

Electron allows using JavaScript to control both the main process and renderer process, which means we have to integrate Node into both processes.

Replacing Chromium's message loop with libuv

My first try was reimplementing Chromium's message loop with libuv.

It was easy for the renderer process, since its message loop only listened to file descriptors and timers, and I only needed to implement the interface with libuv.

However it was significantly more difficult for the main process. Each platform has its own kind of GUI message loops. macOS Chromium uses NSRunLoop, whereas Linux uses glib. I tried lots of hacks to extract the underlying file descriptors out of the native GUI message loops, and then fed them to libuv for iteration, but I still met edge cases that did not work.

So finally I added a timer to poll the GUI message loop in a small interval. As a result the process took a constant CPU usage, and certain operations had long delays.

Polling Node's event loop in a separate thread

As libuv matured, it was then possible to take another approach.

The concept of backend fd was introduced into libuv, which is a file descriptor (or handle) that libuv polls for its event loop. So by polling the backend fd it is possible to get notified when there is a new event in libuv.

So in Electron I created a separate thread to poll the backend fd, and since I was using the system calls for polling instead of libuv APIs, it was thread safe. And whenever there was a new event in libuv's event loop, a message would be posted to Chromium's message loop, and the events of libuv would then be processed in the main thread.

In this way I avoided patching Chromium and Node, and the same code was used in both the main and renderer processes.

The code

You can find the implemention of the message loop integration in the node_bindings files under electron/atom/common/. It can be easily reused for projects that want to integrate Node.

Update: Implementation moved to electron/shell/common/node_bindings.cc.

Podcasts do Electron

· Leitura de um minuto

Procurando por uma introdução ao Electron? Dois podcasts que explicam o que é, porque foi construído e como está sendo usado acabaram de ser lançados.


Disponíveis agora:

Hanselminutes: Criando apps multiplataforma com Electron

O Electron é "apenas o Chrome em um frame" ou é muito mais? Jessica coloca Scott no caminho certo e explica exatamente onde a plataforma Electron se encaixa no seu mundo de desenvolvimento.


JavaScript Air: Aplicativos Electron

O Electron está se tornando cada vez mais um modo relevante e popular de construir aplicativos multiplataformas para desktop com tecnologias da web. Vamos mergulhar nessa tecnologia incrível e ver como podemos usá-la para melhorar a nossa própria experiência e a experiência do nosso usuário no computador.


Se você está procurando uma introdução ao Electron, escute o primeiro. Já o segundo vai a mais detalhes sobre construir aplicativos, com ótimas dicas do Evan Morikawa, de Nylas.

We are currently working on two more podcasts that should come out next month, keep an eye on the @ElectronJS Twitter account for updates.