Ola pessoal tenho o Pop!-Os 20.10 no virtialbox mas logo vou instala-lo no pc em fim, instalei o NATIVIFIER para transformar sites em aplicativos do linux, fiz o Facebook, Telegram, Messenger e também o Whatsapp, que quando ho criei funcionou de primeira, mas agora esta pedindo para atualizar para o chrome 60 sendo que minha verção e Versão 86.0.4240.198 (Versão oficial) 64 bits…
Logo depois fui pesquisei no Diolinux e tinha uma forma que poderia ajudar nesse link, Como utilizar o WhatsApp através do Nativefier - Diolinux , mas tamben nao deu muito certo, quando abri a tela fica toda em branco, se alguem puder me ajudar com isso fico grato, muito obrigado… 
Vc usa o Chrome ou Chromium, não? Por eles tem como criar webapps facilmente, e eles se mantém atualizados da mesma forma que o navegador. Tenta assim, eu uso o Twitter e o Outlook dessa forma sem problemas
2 curtidas
Rodrigo_chile
Eu uso o Chrome, fiz o seginte, agora a pouco exclui a pasta que o nativifier criou na minha home, e rodei o comando de criar app novamente, criando outra pasta na minha home com o mesmo nome da anterior, e por em quanto voutol a funcionar…
1 curtida
Esse tipo de situação expõe a delicadeza de soluções baseadas em Electron e no encapsulamento de navegadores que são tão complexos e vulneráveis, que poderiam ser comparados a sistemas operacionais inteiros. Os desenvolvedores não sabem ainda como avisar os usuários sobre versões antigas e admitem que, mesmo existindo o pressuposto de que o site acessado é confiado pelo usuário, ainda assim é ruim. O problema segue aberto desde março de 2018. Minha recomendação: use diretamente no navegador Chrome ou Chromium ou crie perfis separados para os sites e rode com a opção --app=URL (é possível criar um .desktop para cada site, eu faço isso para Netflix e Crunchyroll).
2 curtidas
Não sei por quê, mas o WhatsApp e outros aplicativos web tem birra com serem rodados em Electron/Nativefier, mesmo que o Electron corresponda a um Chrome atualizado.
Pra usar um WhatsApp com nativefier tive que “embutir” um JS feito pelo pessoal lá do AUR que basicamente fecha essa tela. Desde então tenho rodado o WhatsApp com Nativefier aqui sem qualquer problema:
Jogue em `resources/app/inject/inject.js` na pasta do WhatsApp Web nativefier
// ==UserScript==
// @include https://web.whatsapp.com/
// ==/UserScript==
// Quirk for WhatsApp Web, based on:
// https://github.com/jiahaog/nativefier/issues/719
"use strict";
var id = setInterval(bypass, 50);
function bypass() {
console.log("Checking for 'Update browser' message...");
if (document.querySelector("a[href='https://support.google.com/chrome/answer/95414']")) {
console.log("Bypassing 'Update browser' message...");
navigator.serviceWorker.getRegistration().then((registration) => {
registration.unregister();
document.location.reload();
console.log("'Update browser' message bypassed.");
clearInterval(id);
});
}
}
window.setTimeout(
function() {
console.log("No 'Update browser' message found after 5 seconds.");
clearInterval(id);
}, 5000
);
Bom, outra solução talvez melhor seja usar a função webapp nativa dos browsers, ou usar clients dedicados que já embutem essa gambiarra (WALC, WhatsAppQt, etc.).
2 curtidas
Então, acontece que o Electron foi projetado pra se desenvolver aplicativos desktop first class, e pra maioria dos casos a versão do Chromium é irrelevante, a menos que se faça um browser com ele…
É um vetor de ataque no mínimo problemático, além disso, para programas de primeira classe, já existem soluções historicamente melhores, com toolkits nativos, de alta performance, alta disponibilidade e que apresentam metáforas mais adequadas nos widgets (controles que permitem a construção das interfaces).
Estamos vendo a disseminação de uma montanha de aplicativos que, além de pesados e com redundância de componentes sem governança (como é o caso do motor Chromium ou múltiplas bibliotecas JavaScript, em diferentes versões), não interoperam adequadamente e não respeitam padrões. Eu me sinto de volta aos tempos do MS-DOS, pois cada desenvolvedor projeta a interface como bem entende, sem padronização, sem preocupação com a consistência e com a redução da curva de aprendizagem por parte do usuário (ou seja, negligenciando conjuntos sólidos de Human Interface Guidelines - HIG).
Mais informações sobre HIGs:
1 curtida
Entendo, mas as soluções existentes são problemáticas, (se não fossem não usariam electron),
Pra um desenvolvedor, isso é o paraíso na Terra, você tem Linux, Mac OS e Windows, graças a isso você não precisa modificar o código pra cada plataforma, com um comando, sem dual boot, você pode gerar um AppImage, um . AppX e um .DMG… sim vc faz um app pra Mac sem um Mac… o código não precisa de manutenção constantes e isso é lindo
Sim isso é um problema sério, mas não é necessariamente culpa do electron, isso ocorre em qualquer forma de se desenvolver, mas sinceramente o que mais gera isso é a ineficiência, das HIGs, e a absurda quantidade de HIGs, como vc mesmo citou temos:
E várias outras como a do elementaryOS, um programa feito só pra Linux, teria que agradar 3 (KDE, GNOME e Elementary), um app, pra Linux e Windows, 5… deu pra notar o problema? O modelo de SO orientado a apps tem esse problema, não permite padronizar a interface do app em várias plataformas sem um árduo trabalho adicional, nesse ponto, nenhum toolkit realmente faz a diferença, e talvez uma padronização do electron com o Materialize e o HIG usada pelo Google seja mais eficiente que usar
Pior que essa impressão pode estar justamente em certas HIGs, algumas são retrocessos de pelo menos 26 anos
Na informática, tudo tem prós e contras. Nenhuma solução bem estabelecida em sistemas Unix-like provoca um anarquia de bibliotecas e motores de JS e HTML.
Já existiam soluções que não exigiam modificações extensivas (ou qualquer tipo de modificação) antes. E elas não desenham interfaces complexas como páginas de hipertexto com folhas de estilo com scripts aqui e acolá.
Lamento, mas isso que você está falando não é nenhuma novidade. Parece até que as linguagens C e C++ não existem, ou que não existem toolkits como o Qt, que tem bindings para linguagens ainda mais acessíveis, como Python.
É só aderir a uma delas, isso para não falar que diversas convenções são comuns.
Nenhuma delas produz uma anarquia de imprevisibilidade e redundância. Se você listar os retrocessos, ajudaria. Do jeito que você fala, ambientes formidáveis como o Plasma ou o próprio macOS seriam o retrocesso, enquanto browsers encapsulados seriam o futuro.
Na verdade, praticamente todos os Toolkits, fazem isso, a menos se o dev não quiser escrever 100 linhas de código pra fazer algo simples, Qt faz isso tendo até uma linguagem própria pra isso, GTK faz isso, Lazarus faz isso (mas não achei a doc)…
Tem 2 problemas, C e C++ são cross compiling de fato (um código feito em um sistema operacional pode ser compilado em outro) mas não é nem de longe automatizado, com o WSL até dá pra fazer isso mas ainda sim é preciso outro sistema operacional e Python, é basicamente a mesma coisa que o electron, só que com mais libs:
electron = player :> index.js :> libs js e arquivos HTML/CSS
python = interpretador :> main.py :> libs .py e arquivos .ui :> libs dinâmicas
E embora seja possível criar um bundle de forma fácil, isso só empacota libs python, vc não vai ter arquivos .so e .dll (que não são necessários no Electron)
Na verdade, só parecem comuns, acho que a mais variações com pontos em comum são as com CSD, então, veja:
- Apple
- Elementary
- Gnome
As HIGs são da mesma classe, os apps são da mesma classe e ainda sim mesmo com o mesmo tema, os apps ficariam aliens fora de seu HIG, um usuário que se desenvolve bem no GNOME vai ter muita dificuldade no Finder (ou qualquer combinação entre os 3), além de serem ineficientes (mas isso é outra história)
Certo, nenhuma delas individualmente faz isso, individualmente, o problema é existirem tantas, assim, integrar 100% com qualquer uma (que já é complicado por natureza independente de toolkit) faz a aplicação se tornar um alien nos outros ambientes, os apps em electron geralmente, seguem UXs alternativas que geralmente usam a metodologia KISS/Do the task que vai contra praticamente todas as HIGs, exemplo
A última tentativa de inovação em uma HIG aconteceu em 1996 (CSD) e era menos Human-friendly que a layout tradicional, e foi deixada de lado justamente por isso, qual o sentido de querer isso de volta ou mesmo tentar empurrar que é de fato uma coisa boa (Apple HIG)?
Nem de longe é isso que eu quis se dizer, se passei essa impressão, desculpa, vou resumir em 3 pontos:
-
As tecnologias atuais não permitem um deploy cross platform facilitado, logo um modelo tipo player acaba sendo mais vantajoso
-
Existem muitas HIGs no mercado, seguir uma delas significa deixar o app “alien” nos outros, sendo assim é preferível deixar todas de lado, minimiza a quantidade de haters
-
Todas as HIGs não são human-friendly, logo, faz ainda menos sentido aplicar alguma delas
Acho que talvez eu não tenha me expressado bem, mas entendo que você confirmou o que eu disse, então, sim, exatamente, as principais soluções tradicionais, orientadas para desktop, permitem o desenho de interfaces que aderem a paradigmas e/ou metáforas de interação homem-máquina bastante sólidos. O Qt é, provavelmente, o mais convergente e versátil dos citados, apesar das polêmicas e/ou limitações de licenciamento.
O Lazarus, aliás, tem aquela proposta de tentar ser um ambiente RAD análogo ao Delphi. Outros exemplos de propostas parecidas são o Gambas (análogo ao Visual Basic), Visual Tcl e VisualWorks (análogo ao VisualAge Smalltalk).
É, não é tão automatizado, o programador precisa saber o que está fazendo (o que é bastante típico de C e C++, que não são as coisas mais fáceis do mundo), mas é possível. Temos muitos exemplos de programas Qt que são consistentes nas três principais plataformas e ainda podem rodar em mais uma variedade de sistemas Unix e Unix-like. O Qt tem sido bem recebido na comunidade Haiku, por exemplo e os programas se mesclam de forma extremamente elegante aos nativos não-Qt.
Já no caso do Python, no caso do ecossistema Linux (e, de certa forma, do que usa gerenciamento de pacotes), a questão das bibliotecas nunca foi um problema.
O problema é o CSD, que eu considero um retrocesso, mas o projeto KDE tem feito esforços para mitigar o gap provocado pelo (que eu considero um equívoco) do projeto GNOME. No caso do macOS, a plataforma está passando por um choque de inconsistência que a comunidade ainda não digeriu. Teremos de esperar os próximos hardwares e desdobramentos.
Fora o CSD, um deslize recente (e em mitigação no Plasma, como falei), nunca mais tivemos nenhum problema sério com integração. Os últimos problemas foram superados há muito tempo, desde, sei lá, o projeto Bluecurve da Red Hat. E, mesmo no caso de toolkits que pararam no tempo, como Motif, o paradigma-guia é basicamente IBM Common User Access, que está presente em vários lugares, inclusive em boa parte do Windows, GTK 2 e Qt (qualquer versão). Aliás, mesmo no Vivaldi, se eu pressionar Shift + F10, o menu de contexto aparece, em complementaridade ao F10, que destaca a barra de menu. Isso tudo é CUA. As teclas clássicas de copiar/colar/recortar seguem funcionando também.
Os apps em Electron não se integram. Não é KISS, eles é que são os aliens, haha. KISS é quando usamos, digamos, OpenBSD e configuramos o virtualizador editando um arquivo de texto simples extremamente direto e com documentação também objetiva, em oposição, digamos, a um arquivo XML.
Essa solução da Xerox era de um ambiente ainda mais antigo, que rodava via emulação ou usando um hardware (basicamente um computador espetado dentro de outro) e que, apesar de possuir controles na barra de título, era extremamente dependente do teclado e pré-data todos os esforços de P&D que vieram nas décadas de 1980 e 1990 por outras empresas. Vale lembrar que a versão para Solaris, muito superior, não violava o OpenLook tentando implementar CSD (aliás, o termo nem cabe, no caso do GlobalView) ou coisas do tipo.
O fato é que o conjunto tradicional titlebar + menubar + toolbar + statusbar continua sendo imbatível. E todos os widgets já existem. Já tem tudo: toolkits, linguagens e sistemas de empacotamento.
Acho que é mais ou menos, porque correr por fora e produzir várias externalidades não torna a vida do administrador de sistemas uma panaceia também.
O programador escolhe uma.
São previsíveis, amigáveis e com mais tempo de pesquisa e implementação do que qualquer invenção JavaScript de programas que não se integram com nada.
Sim, o que eu quis dizer é que elas usam dos mesmos artifícios que o Electron
Flatpak e Snaps…
Vale lembrar que vários apps em diversos toolkits quebram isso, essa questão to F10/Shift F10 (e vários outros) pelo menos quando compilados para Windows requer trabalho extra pra ser implementado usando GTK+ e GDI+ (que aliás é da própria MS), então esse tipo de integração não é tão seamlessy não
Vai por mim, depois que comecei a desenvolver projeto em python eu percebi que carregar coisas do sitema não é uma coisa boa, seja Windows ou Linux
è um bom exemplo de KISS, mas não é só isso, a ideia do KISS é tipo “faz só uma coisa, mas faz bem feito e sem complicação”
Não entendo o motivo, CSD é o cliente (ou aplicação) decorando sua própria janela, pelo menos quando eu testei em VM parrecia ser isso que acontecia, me corrija se eu estiver errando o tecniques
Concordo… o certo seria um meio termo
Assim, eu usei apps do elementary em outras distros e sinceramente, tirando o Fondo, eu desinstalei 2h depois, é muito desconfortável, em compensação no elementaryOS dá gosto usar eles… acho que não tomar partido é melhor
Previsíveis sim, amigáveis definitivamente não, e essas implementações não são ligadas a javascript/html/css porque qualquer toolkit permite isso, mas por serem linguagens Web tem muito mais material aos moldes “como fazer”