Saltar al contenido principal

Mes tranquilo de diciembre (Dic'24)

· 2 lectura mínima

El proyecto de Electron realizará una pausa para el mes de diciembre de 2024, para después regresar a toda velocidad en enero de 2025.

vía GIPHY


Lo que será igual en diciembre

  1. Los lanzamientos de día cero y los lanzamientos principales relacionados con la seguridad se publicarán según sea necesario. Los incidentes de seguridad se deben reporar a través de SECURITY.md.
  2. Los reportes relacionados con el Código de conducta continuarán.

Lo que será diferente en diciembre

  1. Las últimas versiones estables de las ramas de 2024, que incluyen Electron 31, 32 y 33, se lanzarán la semana del 1 de diciembre. No habrá lanzamientos adicionales planificados en diciembre.
  2. No habrá versiones preliminares ni de prueba durante las últimas dos semanas de diciembre.
  3. Con algunas excepciones, no se realizará la revisión o fusión de pull requests.
  4. No se actualizará el rastreador de incidencias en ningún repositorio.
  5. No se ayudará con la depuración en Discord por parte de los encargados.
  6. No se publicarán actualizaciones de contenido en las redes sociales.

¡Nos vemos en el 2025!

Migrating from BrowserView to WebContentsView

· 4 lectura mínima

BrowserView has been deprecated since Electron 30 and is replaced by WebContentView. Thankfully, migrating is fairly painless.


Electron is moving from BrowserView to WebContentsView to align with Chromium’s UI framework, the Views API. WebContentsView offers a reusable view directly tied to Chromium’s rendering pipeline, simplifying future upgrades and opening up the possibility for developers to integrate non-web UI elements to their Electron apps. By adopting WebContentsView, applications are not only prepared for upcoming updates but also benefit from reduced code complexity and fewer potential bugs in the long run.

Developers familiar with BrowserWindows and BrowserViews should note that BrowserWindow and WebContentsView are subclasses inheriting from the BaseWindow and View base classes, respectively. To fully understand the available instance variables and methods, be sure to consult the documentation for these base classes.

Migration steps

1. Upgrade Electron to 30.0.0 or higher

advertencia

Electron releases may contain breaking changes that affect your application. It’s a good idea to test and land the Electron upgrade on your app first before proceeding with the rest of this migration. A list of breaking changes for each Electron major version can be found here as well as in the release notes for each major version on the Electron Blog.

2. Familiarize yourself with where your application uses BrowserViews

One way to do this is to search your codebase for new BrowserView(. This should give you a sense for how your application is using BrowserViews and how many call sites need to be migrated.

tip

For the most part, each instance where your app instantiates new BrowserViews can be migrated in isolation from the others.

3. Migrate each usage of BrowserView

  1. Migrate the instantiation. This should be fairly straightforward because WebContentsView and BrowserView’s constructors have essentially the same shape. Both accept WebPreferences via the webPreferences param.

    - this.tabBar = new BrowserView({
    + this.tabBar = new WebContentsView({
    info

    By default, WebContentsView instantiates with a white background, while BrowserView instantiates with a transparent background. To get a transparent background in WebContentsView, set its background color to an RGBA hex value with an alpha (opaqueness) channel set to 00:

    + this.webContentsView.setBackgroundColor("#00000000");
  2. Migrate where the BrowserView gets added to its parent window.

    - this.browserWindow.addBrowserView(this.tabBar)
    + this.browserWindow.contentView.addChildView(this.tabBar);
  3. Migrate BrowserView instance method calls on the parent window.

    Old MethodNew MethodNotas
    win.setBrowserViewwin.contentView.removeChildView + win.contentView.addChildView
    win.getBrowserViewwin.contentView.children
    win.removeBrowserViewwin.contentView.removeChildView
    win.setTopBrowserViewwin.contentView.addChildViewCalling addChildView on an existing view reorders it to the top.
    win.getBrowserViewswin.contentView.children
  4. Migrate the setAutoResize instance method to a resize listener.

    - this.browserView.setAutoResize({
    - vertical: true,
    - })

    + this.browserWindow.on('resize', () => {
    + if (!this.browserWindow || !this.webContentsView) {
    + return;
    + }
    + const bounds = this.browserWindow.getBounds();
    + this.webContentsView.setBounds({
    + x: 0,
    + y: 0,
    + width: bounds.width,
    + height: bounds.height,
    + });
    + });
    tip

    All existing usage of browserView.webContents and instance methods browserView.setBounds, browserView.getBounds , and browserView.setBackgroundColor do not need to be migrated and should work with a WebContentsView instance out of the box!

4) Test and commit your changes

Running into issues? Check the WebContentsView tag on Electron's issue tracker to see if the issue you're encountering has been reported. If you don't see your issue there, feel free to add a new bug report. Including testcase gists will help us better triage your issue!

Congrats, you’ve migrated onto WebContentsViews! 🎉

Electron 33.0.0

· 5 lectura mínima

¡Electron 33.0.0 ha sido liberado! It includes upgrades to Chromium 130.0.6723.44, V8 13.0, and Node 20.18.0.


El equipo de Electron esta emocionado de anunciar el lanzamiento de Electron 33.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. Continue reading for details about this release.

If you have any feedback, please share it with us on Twitter or Mastodon, or join our community Discord! Bugs and feature requests can be reported in Electron's issue tracker.

Notable Changes

  • Added a handler, app.setClientCertRequestPasswordHandler(handler), to help unlock cryptographic devices when a PIN is needed. #41205
  • Extended navigationHistory API with 2 new functions for better history management. #42014
  • Improved native theme transparency checking. #42862

Introducción al Historial de API (GSoC 2024)

· 8 lectura mínima

Los cambios históricos en las API de Electron ahora serán detallados en los documentos.


Hola 👋, soy Peter, el 2024 Google Summer of Code (GSoC) colaborador de Electron.

Durante el curso del programa GSoC, implementé una función de historial de API para la documentación de Electron y sus funciones, clases, etc. de forma similar a la Nodo. s documentación: permitiendo el uso de un esquema YAML simple pero potente en los archivos Markdown de documentación de la API y mostrándolo bien en el sitio web de documentación de Electron.

Electron 32.0.0

· 5 lectura mínima

¡Electron 32.0.0 ha sido liberado! It includes upgrades to Chromium 128.0.6613.36, V8 12.8, and Node 20.16.0.


El equipo de Electron esta emocionado de anunciar el lanzamiento de Electron 32.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. Continue reading for details about this release.

If you have any feedback, please share it with us on Twitter or Mastodon, or join our community Discord! Bugs and feature requests can be reported in Electron's issue tracker.

Notable Changes

  • Added new API version history in our documentation, a feature created by @piotrpdev as part of Google Summer of Code. You can learn more about it in this blog post. #42982
  • Removed nonstandard File.path extension from the Web File API. #42053
  • Aligned failure pathway in Web File System API with upstream when attempting to open a file or directory in a blocked path. #42993
  • Added the following existing navigation-related APIs to webcontents.navigationHistory: canGoBack, goBack, canGoForward, goForward, canGoToOffset, goToOffset, clear. The previous navigation APIs are now deprecated. #41752

Electron 31.0.0

· 4 lectura mínima

¡Electron 31.0.0 ha sido liberado! It includes upgrades to Chromium 126.0.6478.36, V8 12.6, and Node 20.14.0.


El equipo de Electron esta emocionado de anunciar el lanzamiento de Electron 31.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. Continue reading for details about this release.

If you have any feedback, please share it with us on Twitter or Mastodon, or join our community Discord! Bugs and feature requests can be reported in Electron's issue tracker.

Notable Changes

  • Extended WebContentsView to accept pre-existing webContents object. #42319
  • Added support for NODE_EXTRA_CA_CERTS. #41689
  • Updated window.flashFrame(bool) to flash continuously on macOS. #41391
  • Removed WebSQL support #41868
  • nativeImage.toDataURL will preserve PNG colorspace #41610
  • Extended webContents.setWindowOpenHandler to support manual creation of BrowserWindow. #41432

Electron 30.0.0

· 5 lectura mínima

¡Electron 30.0.0 ha sido liberado! Incluye actualizaciones a Chromium 124.0.6367.49, V8 12.4 y Node.js 20.11.1.


El equipo de Electron esta emocionado de anunciar el lanzamiento de Electron 30.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. Continue reading for details about this release.

If you have any feedback, please share it with us on Twitter or Mastodon, or join our community Discord! Bugs and feature requests can be reported in Electron's issue tracker.

Notable Changes

  • Fusible de integridad ASAR ahora soportado en Windows (#40504)
    • Las aplicaciones existentes con la integración ASAR habilitada pueden no funcionar en Windows si no están configuradas correctamente. Las aplicaciones que usan herramientas de empaquetado Electron deben actualizar a @electron/packager@18.3.1 o @electron/forge@7.4.0.
    • Eche un vistazo a nuestro tutorial de integración ASAR para más información.
  • Añadido WebContentsView y BaseWindow módulos de proceso principales, haciendo obsoleto y reemplazando BrowserView (#35658). Learn more about how to migrate from BrowserView to WebContentsView in this blog post.
    • BrowserView es ahora una corrección sobre WebContentsView y la implementación antigua ha sido eliminada.
    • Consulte nuestra documentación de Incrustaciones Web para una comparación de la nueva API WebContentsView a otras API similares.
  • Soporte implementado para File System API (#41827)

Verano del Código de Google 2024

· 4 lectura mínima

¡Estamos encantados de anunciar que Electron ha sido aceptado como una organización mentora para la vigésima edición de Google Summer of Code (GSoC) 2024! Google Summer of Code es un programa global centrado en traer nuevos colaboradores al desarrollo de software de código abierto.

Para obtener más detalles del programa, consulta la página de inicio de Summer of Code.

Sobre nosotros

Electron es un framework JavaScript para construir aplicaciones multiplataforma de escritorio usando tecnologías web. El framework central de Electron es un ejecutable binario compilado construido con Chromium y Node.js, y está escrito principalmente en C++.

Fuera del núcleo de Electron, también trabajamos en una variedad de proyectos para ayudar a sostener la organización de Electron como:

Como colaborador de Summer of Code, estarías colaborando con algunos de los principales colaboradores de Electron en uno de los muchos proyectos bajo el paraguas github.com/electron.

Antes de aplicar

Si no estás muy familiarizado con Electron, te recomendamos que comiences leyendo la documentación y probando ejemplos en Electron Fiddle.

Para obtener más información sobre la distribución de aplicaciones Electron también puede jugar con Electron Forge creando una aplicación de muestra:

npm init electron-app@latest my-app

Después de familiarizarte un poco con el código, ven a unirte a la conversación en el Servidor de Discord de Electron.

info

Si esta es tu primera participación en Google Summer of Code o si eres nuevo en código abierto en general recomendamos leer la [Guía de colaboradores](https://google. ithub.io/gsocguides/student/) como un primer paso antes de comprometerse con la comunidad.

Elaborando su propuesta

¿Estás interesado en colaborar con Electron? Primero, revisa los siete borradores de ideas del proyecto que hemos preparado. Todas las ideas de la lista están actualmente abiertas a propuestas.

¿Tienes una idea diferente que te gustaría tener en cuenta? También estamos abiertos a aceptar nuevas ideas que no están en la lista de proyectos propuestos. pero asegúrese de que su enfoque está completamente esbozado y detallado. En caso de duda, le recomendamos que se aferre a nuestras ideas listadas.

Su solicitud debe incluir:

  • Tu propuesta: un documento escrito que describe en detalle lo que planeas lograr durante el curso del verano.
  • Su experiencia como desarrollador. Si tiene un currículum, por favor incluya una copia. De lo contrario, cuéntanos tu experiencia técnica pasada.
    • La falta de experiencia en ciertas áreas no te descalificará, pero ayudará a nuestros mentores a elaborar un plan para ayudarte mejor y asegurarte de que tu proyecto de verano sea un éxito.

[Aquí está una guía detallada de qué enviar como parte de tu aplicación Electron.](https://electronhq.notion. ite/Electron-GSoC-2024-Contributor-Guidance-f1f4de7a0d9a4664a96c8d4dd70cb208?pvs=4) Enviar propuestas directamente al portal de Google Summer of Code. Tenga en cuenta que las propuestas enviadas por correo electrónico al equipo Electron en lugar de enviarlas a través del portal de la aplicación no serán consideradas como un envío final.

Si desea más orientación sobre su propuesta o no está seguro de qué incluir, también recomendamos que sigas [la propuesta oficial de Google Summer of Code escribiendo consejos aquí](https://google. ithub.io/gsocguides/student/writing-a-proposal).

Aplicaciones abiertas el 18 de marzo de 2024 y cierran el 2 de abril de 2024.

info

Nuestro interlocutor de Google Summer of Code 2022, @aryanshridhar, hizo un trabajo increíble! Si quieres ver en qué trabajó Aryan durante su verano con Electron, puedes leer su informe en [2022 GSoC program archives](https://summerofcode. ithgoogle.com/archive/2022/organizations/electron).

¿Preguntas?

Si tienes preguntas que no enviamos en las publicaciones del blog o consultas para tu borrador de propuestas, por favor envíanos un correo electrónico a Summer-of-code@electronjs. rg o revisa GSoC FAQ!

Recursos

Electron 29.0.0

· 5 lectura mínima

¡Electron 29.0.0 ha sido liberado! It includes upgrades to Chromium 122.0.6261.39, V8 12.2, and Node.js 20.9.0.


El equipo de Electron esta emocionado de anunciar el lanzamiento de Electron 29.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. Continue reading for details about this release.

If you have any feedback, please share it with us on Twitter or Mastodon, or join our community Discord! Bugs and feature requests can be reported in Electron's issue tracker.

Notable Changes

  • Added a new top-level webUtils module, a renderer process module that provides a utility layer to interact with Web API objects. The first available API in the module is webUtils.getPathForFile. Electron's previous File.path augmentation was a deviation from web standards; this new API is more in line with current web standards behavior.

Stack Changes

Electron 29 upgrades Chromium from 120.0.6099.56 to 122.0.6261.39, Node from 18.18.2 to 20.9.0, and V8 from 12.0 to 12.2.

Nuevas características

  • Added new webUtils module, a utility layer to interact with Web API objects, to replace File.path augmentation. #38776
  • Added net module to utility process. #40890
  • Added a new Electron Fuse, grantFileProtocolExtraPrivileges, that opts the file:// protocol into more secure and restrictive behaviour that matches Chromium. #40372
  • Added an option in protocol.registerSchemesAsPrivileged to allow V8 code cache in custom schemes. #40544
  • Migrated app.{set|get}LoginItemSettings(settings) to use Apple's new recommended underlying framework on macOS 13.0+. #37244

Restaurar archivos borrados

Behavior Changed: ipcRenderer can no longer be sent over the contextBridge

Attempting to send the entire ipcRenderer module as an object over the contextBridge will now result in an empty object on the receiving side of the bridge. This change was made to remove / mitigate a security footgun. You should not directly expose ipcRenderer or its methods over the bridge. Instead, provide a safe wrapper like below:

contextBridge.exposeInMainWorld('app', {
onEvent: (cb) => ipcRenderer.on('foo', (e, ...args) => cb(args)),
});

Removed: renderer-process-crashed event on app

The renderer-process-crashed event on app has been removed. Use the new render-process-gone event instead.

// Removed
app.on('renderer-process-crashed', (event, webContents, killed) => {
/* ... */
});

// Replace with
app.on('render-process-gone', (event, webContents, details) => {
/* ... */
});

Removed: crashed event on WebContents and <webview>

The crashed events on WebContents and <webview> have been removed. Use the new render-process-gone event instead.

// Removed
win.webContents.on('crashed', (event, killed) => {
/* ... */
});
webview.addEventListener('crashed', (event) => {
/* ... */
});

// Replace with
win.webContents.on('render-process-gone', (event, details) => {
/* ... */
});
webview.addEventListener('render-process-gone', (event) => {
/* ... */
});

Removed: gpu-process-crashed event on app

The gpu-process-crashed event on app has been removed. Use the new child-process-gone event instead.

// Removed
app.on('gpu-process-crashed', (event, killed) => {
/* ... */
});

// Replace with
app.on('child-process-gone', (event, details) => {
/* ... */
});

Fin de soporte para 26.x.y

Electron 26.x.y has reached end-of-support as per the project's support policy. Se anima a los desarrolladores y aplicaciones a actualizar a una versión de Electron nueva.

E29 (Feb'24)E30 (Apr'24)E31 (Jun'24)
29.x.y30.x.y31.x.y
28.x.y29.x.y30.x.y
27.x.y28.x.y29.x.y

¿Y ahora, qué?

Did you know that Electron recently added a community Request for Comments (RFC) process? If you want to add a feature to the framework, RFCs can be a useful tool to start a dialogue with maintainers on its design. You can also see upcoming changes being discussed in the Pull Requests. To learn more, check out our Introducing electron/rfcs blog post, or check out the README of the electron/rfcs repository directly.

A corto plazo puedes esperar que el equipo continúe enfocándose en mantener al día con el desarrollo de los principales componentes que componen Electron, incluyendo Chromium, Node, y V8.

You can find Electron's public timeline here.

More information about future changes can be found on the Planned Breaking Changes page.

Introducing electron/rfcs

· 4 lectura mínima

Electron’s API Working Group is adopting an open Requests for Comments (RFC) process to help shepherd larger changes to Electron core.

Why RFCs?

In short, we want to smooth out the process of landing significant changes to Electron core.

Currently, new code changes are mostly discussed through issues and pull requests on GitHub. For most changes to Electron, this is a good system. Many bug fixes, documentation changes, and even new features are straightforward enough to review and merge asynchronously through standard GitHub flows.

For changes that are more significant—for instance, large API surfaces or breaking changes that would affect the majority of Electron apps—it makes sense for review to happen at the ideation stage before most of the code is written.

This process is designed to be open to the public, which will also make it easier for the open source community at large to give feedback on potential changes before they land in Electron.

¿Cómo funciona?

The entire RFC process lives in the electron/rfcs repository on GitHub. The steps are described in detail in the repository README.

In brief, an RFC is Proposed once a PR is made to the electron/rfcs repository. A Proposed RFC becomes:

  • Active when the PR is merged into the main branch of the repository, which means that Electron maintainers are amenable to an implementation in electron/electron, or
  • Declined if the PR is ultimately rejected.
info

For the RFC to become Active, the PR must be approved by at least 2 API Working Group members. Before merging, the RFC should be presented synchronously and accepted unanimously by a quorum of at least two-thirds of the WG members. If consensus is reached, a one-month final comment period will be triggered, after which the PR will be merged.

An Active RFC is Completed if the implementation has been merged into electron/electron.

Who can participate?

Anyone in the Electron community can submit RFCs or leave feedback on the electron/rfcs repository!

We wanted to make this process a two-way dialogue and encourage community participation to get a diverse set of opinions from Electron apps that might consume these APIs in the future. If you’re interested in leaving feedback on currently proposed RFCs, the Electron maintainers have already created a few:

Credits

Electron's RFC process was modeled on many established open source RFC processes. Inspiration for many ideas and major portions of copywriting go to: