Open phedroreis opened 3 years ago
Opa, simbora! Já clonei!
Claro que está tudo no papel ainda. Não vi a pasta "src". Vou ficar acompanhando com o "git pull".
Você clonou mas não criou um fork.
O mais comum é a pessoa criar o fork e depois clonar seu próprio fork.
Não faz tanta diferença, mas esse modo é padrão e simplifica um pouco. Pouca coisa.
Clonando seu próprio fork seu repositório local fica configurado para rastrea-lo automaticamente. Ou seja, git pull vai puxar do branch master do seu fork para o branch master local.
Já o git push irá automaticamente empurrar do branch master local para o branch master do seu fork .
E lembre-se: quando você clona um remoto, este remoto recebe o apelido de origin
Isso significa que o comando git remote add origin [url do seu fork] foi executado implicitamente pelo comando git clone [url do seu fork]
Então é assim que o seu repo local chama seu fork: 'origin'
Assim você pode fazer suas alterações no repositório local e depois empurra-las para o fork com o simples comando git push (no caso de alterações feitas no branch master, porque clone fez master local 'rastrear' master remoto)
Se você criar algum outro branch e quiser empurrar para o fork, aí tem que especificar o branch git push origin novo-branch. (Empurre novo-branch para origin)
Mas para não embolar o meio de campo, inicialmente não precisa criar novos branches. Então para atualizar o fork usaria apenas git push
Uma vez empurrada a alteração, você pode acessar sua conta no GitHub e criar um Pull Request para esta contribuição.
Bem, nesse caso git pull não serve porque este comando está puxando do seu próprio fork. Então como?
Você tem que associar seu local com o meu repositório. O comando é:
git remote add upstream https://github.com/phedroreis/whatsappweb-fix.git
Este comando está dando ao meu repositório o apelido de upstream e só precisa ser dado uma vez. Poderia ser qualquer outro nome, mas 'upstream' é tradicional para estas situações.
De agora em diante você pode sempre atualizar repo local com o seguinte comando:
git pull upstream master
Isso está puxando o meu branch master (que está no repo 'upstream') para o seu branch master.
Percebeu? Você está informando ao comando pull qual branch (master) puxar e em qual remoto ele se encontra (upstream).
Se fosse para puxar do repo do qual o seu foi clonado (nesse caso, seu próprio fork) não seria necessário informar repo nem branch porque o comando git clone já os configurou por default. Bastaria git pull
De qualquer forma git pull origin master daria o mesmo resultado de puxar o branch master do seu fork para seu repo local.
Mas após atualizar seu repo local com as alterações que eu fiz no meu próprio repositório, você poderia atualizar o fork lá no GitHub.
git push (ou git push origin master, que teria o mesmo efeito)
Em suma: dá para gerenciar tudo da sua própria máquina apenas abrindo o Git Bash no seu repo local. Sem precisar acessar seu fork no GitHub. Desde que você associe este repo local aos dois remotos.
Ao seu fork foi associado automaticamente quando você clonou. E para associar ao meu o comando foi:
git remote add upstream [url do meu repositorio]
Não é para decorar. Tem que entender.
Ou seja, seria melhor deletar este clone. Criar um fork e depois sim, clonar este fork.
Em seguida você associa este repo local clonado do seu fork também ao meu repositório:
git remote add upstream https://github.com/phedroreis/whatsappweb-fix.git
Agora você pode puxar e empurrar para os dois. (sendo que para seu fork basta git pull e git push)
Então você pode PUXAR as atualizações do meu repo e depois EMPURRA-LAS para o seu fork no GitHub.
Sincronizando os 3.
Acabei de programar a primeira classe do projeto e atualizar o site com a documentação.
É só uma classe com dois métodos, mas é 90% do projeto.
O primeiro método converte emoji utf8 para codepoint. O segundo converte o nome de um arquivo baixado da Emojipedia em respectivo codepoint também.
Essa era a parte que tinha que parar pra pensar. O resto não tem mistério.
Meu objetivo particular com esse projeto é utiliza-lo para começar a desenvolver um modelo mais aprimorado de documentação baseada em HTML.
Pra mim é a parte mais difícil de programar: documentar as ideias.
Porque embora existam as ferramentas de UML para documentação de projetos de software, a UML não se presta bem para capturar as ideias por trás do código. Esse é um grande problema porque quando se trata de desenvolver algo mais complexo como foi aquele motor de busca do Huugle, 2 dias depois eu mesmo não lembro mais da ideia subjacente e não consigo entender mais meu próprio código.
O que é uma dor de cabeça quando é preciso encontrar bugs mas também dificulta para que aquela ideia possa ser reaproveitada de outras formas. Em outros problemas.
Nesse ponto, este projeto não tem nem 20 linhas de código. Mas estas poucas linhas concentram quase toda a ideia da coisa. O resto é programação simples e direta.
Na seção Especificação do site de documentação se pode ver como às vezes poucas linhas de código dependem de muitas particularidades sutis ou de algum raciocínio sofisticado subjacente, que precisam ser conhecidos e compreendidos para que o próprio código fonte seja também entendido com segurança. Até mesmo por quem escreveu o código!
No momento estou empenhado nisso e gostaria do seu feedback, se possível. Que você, quando puder, dê uma lida nesta seção Especificação e me diga de 0 a 10 como você avalia o grau de clareza na explicação daqueles códigos.
De resto acho que muito breve vai haver uma solução razoável para o enigma do desaparecimento dos emojis...
O arquivo no anexo dessa msg lista 3171 nomes de arquivos com diferentes figuras de emojis. Estes nomes de arquivo estão listados em atributos data-src das tags e estão no formato correto.
Agora é só baixar cada um deles, normalizar os nomes e escrever um programa que localize as tags que inserem emojis e troque por tags que inserem as figuras destes arquivos. whatsapp-emojis.zip
Vai ficar legalzim...
Oi, Pedro.
Desculpe a minha ausência por esses dias, mas estou plenamente empenhado em dar minha participação de alguma forma.
Sobre o fork, é isso mesmo que você explicou: vou apagar o clone, criar o fork e cloná-lo. É o caminho certo e natural.
Sobre a documentação, pode deixar. Vou ler e dizer depois o grau de entendimento para quem está chegando de fora. Mas eu acho que já posso adiantar alguma coisa, mesmo sem ter lido uma linha do que tem lá: Pelos seus trabalhos anteriores, eu já vi que você é muito detalhista e rigoroso com essa parte do código. Todo ele que sai de sua criação é sempre ricamente documentado e exaustivamente explicado.
Eu entendi o ponto onde você quer chegar: de conseguir isolar e expor o cerne da ideia, o miolo da engrenagem que leva àquele código escrito. Mesmo assim, se você já está preocupado com isso e quer cumprir o objetivo, é quase certo de que conseguirá.
Estarei ocupadasso por esses dias, mas tenho esse projeto atravessado no meio do meu caminho. Darei retorno depois.
Ok. Valeu Gabarito.
Já baixei os 3171 arquivinhos com figuras dos emojis e parece que está tudo ok. Nesse lote o Normalize.jar conseguiu converter todos e parece que os codepoints correspondem às figuras dos arquivos.
Então, até aqui, tudo suave na nave.
O arquivo no anexo dessa msg lista 3171 nomes de arquivos com diferentes figuras de emojis. Estes nomes de arquivo estão listados em atributos data-src das tags e estão no formato correto.
Agora é só baixar cada um deles, normalizar os nomes e escrever um programa que localize as tags que inserem emojis e troque por tags que inserem as figuras destes arquivos. whatsapp-emojis.zip
Eu estava indo ler a documentação, mas reli sua mensagem acima e fui dar uma olhada no anexo. E fiquei encucado.
No código dele, de fato, tem as chamadas a cada um dos emojis. Mas ao carregá-lo com o navegador, só aparecem os 11 primeiros. Que bruxaria é essa?
Removi os scripts da página e mesmo assim não consegui exibir toda a turma. Você sabe por quê?
Procurei a página de origem e vi que toda a família do WhatsApp estava lá na Emojipedia. Fazia tempo que eu procurava por isso e nem me apercebi que estava tão perto.
Baixei com o Firefox e obtive realmente as 3.171 imagens PNGs. Baixei com o Webscrapbook e o bicho entrou em parafuso.
Você deve ter melhores ferramentas para baixar. E, como já falou, suave na nave.
Vou ver se ainda dá pra ver a documentação ainda hoje.
Criei o fork e clonei-o na máquina. Abri o Especificação e estou lendo.
Não ficou clara a definição de LOW SURROGATE BYTES, mesmo que ele não interfira no projeto. Mas o leitor fica perdido. A não ser que vá buscar lá fora a definição do termo. Claro que foge do escopo do projeto explicar algo que não pertence a ele, mas alguma coisa mais poderia ser dito sumariamente.
Na frase: "...o caractere U+FE0F pode estar presente na string UTF-8 mas não nome do arquivo" ficou faltando o "no": "o caractere U+FE0F pode estar presente na string UTF-8 mas não no nome do arquivo"
Ao baixar a página, notei que a bandeira do Brasil está representada em dois arquivos: flag-brazil_1f1e7-1f1f7.png e flag-brazil_1f1e7-1f1f7-1.png Essa segunda imagem é de resolução maior, 144x144, enquanto que o padrão parece ser de 72x72, o da primeira.
O Webscripbook finalmente baixou tudo. E veio mais do que o esperado, 6.352. Serão arquivos duplicados. O valor é quase o exato dobro de 1.371.
Você fala da dificuldade numa RegExp para deletar tudo que não for code point do nome do arquivo. Concordo que poderia acontecer de apagar mais do que devia. Mas, mesmo assim, eu dou uma sugestão.
Existe uma comunidade sensacional para resolução de RegExps. Parece que existe um plantão permanente e tem sempre algum fera a postos para resolver os nossos maiores desafios que se apresentem. Quando eu engasgo com alguma questão que exija uma RegExp de especialistas, eu vou lá e tenho tido a sorte de sair com a solução no mesmo dia, às vezes em questão de minutos. E costumam ser expressões cabeludas que eu NUNCA conseguiria chegar sozinho.
Se você não conhece, devia. Nem precisa criar conta; faça login com o Google. Uma vez lá dentro, você cria suas RegExps e o próprio ambiente da página vai analisá-las e detalhar cada comando dado. Coloque também a massa de testes para ver a avaliação. A url de cada expressão que você cria pode ser salva na sua biblioteca e também servirá de referência quando você pedir ajuda aos universitários. Você os encontra no último ícone do painel da esquerda em forma de bolha de conversa e com o texto alternativo de "Live help". Coloque o Apelido que quiser e se conecte. Será direcionado a um chat no estilo do velho IRC, com a rapaziada toda lá, esperando por perguntas. Lembre-se de colocar a dúvida informando a url da RegExp que você está tentando criar. O propósito e a pergunta propriamente dita, você explica no chat.
Talvez eles tenham uma sugestão para essa RegExp difícil. Eu mesmo não vou lá porque você está mais por dentro desses code points e pode haver algum detalhe que eu não considerei.
Onde é mesmo esse Céu das RegExps? https://regex101.com/
Como dizem nesses mundos de redes sociais, "espero ter ajudado".
Ah, e parabéns pela explicação lá no Especificação. Como eu já sabia, fez o bê-a-bá para quem possa interessar. Não se preocupe com a documentação. O seu default, eu já vi, é documentar e isso ocorrerá naturalmente.
Eu estava indo ler a documentação, mas reli sua mensagem acima e fui dar uma olhada no anexo. E fiquei encucado.
No código dele, de fato, tem as chamadas a cada um dos emojis. Mas ao carregá-lo com o navegador, só aparecem os 11 primeiros. Que bruxaria é essa?
Removi os scripts da página e mesmo assim não consegui exibir toda a turma. Você sabe por quê?
Procurei a página de origem e vi que toda a família do WhatsApp estava lá na Emojipedia. Fazia tempo que eu procurava por isso e nem me apercebi que estava tão perto.
Baixei com o Firefox e obtive realmente as 3.171 imagens PNGs. Baixei com o Webscrapbook e o bicho entrou em parafuso.
Você deve ter melhores ferramentas para baixar. E, como já falou, suave na nave.
Vou ver se ainda dá pra ver a documentação ainda hoje.
Tô fazendo isso agora, mas como a maior parte é só copy e paste do projeto antigo acho que não demora terminar.
Se você abriu na sua máquina então ele não carregou os css e nem os scripts. Essa deve ser a explicação.
Eu baixei com um código que eu mesmo fiz e já deve estar no repositório, não sei... É a classe GetPngs.java, mas não tem uma interface pra ela. Vou ver se faço uma agora.
Esta classe usa o método downloadUrl(), que está na classe FileTools.java dentro pacote util. Não sei se já está no repositório mas funciona para baixar qualquer tipo de arquivo desde que você tenha a URL do arquivo.
Mas acho que eles devem ter alterado essa página desde que você me enviou aquele lote de PNGs. Porque os arquivos estão com outros nomes.
Criei o fork e clonei-o na máquina. Abri o Especificação e estou lendo.
Não ficou clara a definição de LOW SURROGATE BYTES, mesmo que ele não interfira no projeto.
É meio complicado explicar isso e foge do escopo. Os caracteres em UTF-8 têm tamanho variável. Podendo estar codificados em 8, 16 ou 32 bits. O decoder precisa saber se deve ou não continuar codificando o caractere pelo próximo byte. Ele precisa de informações extras além do próprio código do caractere.
Mas para este programa só o que interessa é o próprio UNICODE do emoji.
Mas o leitor fica perdido. A não ser que vá buscar lá fora a definição do termo. Claro que foge do escopo do projeto explicar algo que não pertence a ele, mas alguma coisa mais poderia ser dito sumariamente.
Posso botar um link pra isso.
Na frase: "...o caractere U+FE0F pode estar presente na string UTF-8 mas não nome do arquivo" ficou faltando o "no": "o caractere U+FE0F pode estar presente na string UTF-8 mas não no nome do arquivo"
Ok.
Ao baixar a página, notei que a bandeira do Brasil está representada em dois arquivos: flag-brazil_1f1e7-1f1f7.png e flag-brazil_1f1e7-1f1f7-1.png Essa segunda imagem é de resolução maior, 144x144, enquanto que o padrão parece ser de 72x72, o da primeira.
Ah, essa pode ser a explicação para os arquivos duplicados e com nomes fora do padrão.
Mas como agora estou baixando com meu próprio código, o problema não deve mais ocorrer.
O Webscripbook finalmente baixou tudo. E veio mais do que o esperado, 6.352. Serão arquivos duplicados. O valor é quase o exato dobro de 1.371.
Não sei como funciona este programa.
Você fala da dificuldade numa RegExp para deletar tudo que não for code point do nome do arquivo. Concordo que poderia acontecer de apagar mais do que devia. Mas, mesmo assim, eu dou uma sugestão.
Existe uma comunidade sensacional para resolução de RegExps. Parece que existe um plantão permanente e tem sempre algum fera a postos para resolver os nossos maiores desafios que se apresentem. Quando eu engasgo com alguma questão que exija uma RegExp de especialistas, eu vou lá e tenho tido a sorte de sair com a solução no mesmo dia, às vezes em questão de minutos. E costumam ser expressões cabeludas que eu NUNCA conseguiria chegar sozinho.
Se você não conhece, devia. Nem precisa criar conta; faça login com o Google. Uma vez lá dentro, você cria suas RegExps e o próprio ambiente da página vai analisá-las e detalhar cada comando dado.
Coloque também a massa de testes para ver a avaliação. A url de cada expressão que você cria pode ser salva na sua biblioteca e também servirá de referência quando você pedir ajuda aos universitários. Você os encontra no último ícone do painel da esquerda em forma de bolha de conversa e com o texto alternativo de "Live help". Coloque o Apelido que quiser e se conecte. Será direcionado a um chat no estilo do velho IRC, com a rapaziada toda lá, esperando por perguntas. Lembre-se de colocar a dúvida informando a url da RegExp que você está tentando criar. O propósito e a pergunta propriamente dita, você explica no chat.
Talvez eles tenham uma sugestão para essa RegExp difícil. Eu mesmo não vou lá porque você está mais por dentro desses code points e pode haver algum detalhe que eu não considerei.
Onde é mesmo esse Céu das RegExps? https://regex101.com/
Haha!!! Eu uso direto este site! Mas não sabia que tinha essa comunidade... Pensei que EU que tivesse indicado este site a você.
Como dizem nesses mundos de redes sociais, "espero ter ajudado".
Claro, e eu sei que dá trabalho fazer isso. Então valeu.
Ah, e parabéns pela explicação lá no Especificação. Como eu já sabia, fez o bê-a-bá para quem possa interessar. Não se preocupe com a documentação. O seu default, eu já vi, é documentar e isso ocorrerá naturalmente.
O primeiro interessado sou eu mesmo.
Porque quando documento um código estou com ele na cabeça, os detalhes, e então os comentários me parecem claros.
Só que depois de um tempo, quando eu preciso entender aquilo e já não estou mais com os detalhes na cabeça, minha própria explicação me parece confusa.
Antes usava LateX pra isso, mas agora estou tentando bolar uma forma mais aprimorada de documentar com HTML, que tem muitos mais recursos.
Quase pronto.
No repositório já tem os executáveis GetPngs.jar e Normalize.jar que podem ser compilados com compile.bat na pasta src.
O 1o é para baixar os PNGs. Só precisa indicar na interface onde está o arquivo whatsapp-emojis.html. Porque o programa vai coletar as URLs nesse arquivo. Estes serão baixados para uma pasta png.
Normalize.jar cria a pasta emoji-images dentro de png e move os arquivos normalizados para essa pasta.
Para dar pull:
O git vai puxar para o branch master local porque master é o branch corrente. Sempre há um branch corrente, se você não mudou de branch ele ainda está no master. Então qualquer push empurra o master. Qualquer pull puxa para o master. ( Ou seja, por default push empurra o branch corrente para o destino especificado. Pull puxa da origem especificada para o branch corrente. A menos que vc especifique o contrário)
Depois disso você pode atualizar seu próprio fork com git push (Empurra seu master atualizado para o master do fork)
Esse vai funcionar. O arquivo de log agora é um HTML criado pelo Normalize.jar na pasta emoji-images. Dá para abrir no navegador e ver que não há PNGs repetidos nem com nomes incorretos.
Ah, qual o nome da pasta base?
Pra botar na regex e copiar a pasta emoji-images para dentro da pasta base.
Bom, a pasta base tá com nome de PastaBase. Assim mesmo.
Se não for esse você pode mudar em src/br/com/hkp/whatsappwebfix/glogal/Global.java
Vou atualizar o repositório agora.
Ou seja, seria melhor deletar este clone. Criar um fork e depois sim, clonar este fork.
Em seguida você associa este repo local clonado do seu fork também ao meu repositório:
git remote add upstream https://github.com/phedroreis/whatsappweb-fix.git
Apanhando e aprendendo. Criei o fork e depois o clone. Para isso, eu devo estar na pasta raiz. A que eu uso localmente é "/Meus documentos/Github". Maaaas... para associar meu repo local clonado do meu fork ao seu, eu não posso estar na pasta raiz. Devo me mudar para a pasta do clone: cd whatsappweb-fix-fork
Descobri depois que deu erro quando executei no raiz.
fatal: not a git repository (or any of the parent directories): .git
Esqueci...
Se vc for testtar, a pasta emoji-images nessa versão tem que ser copiada pra dentro da PastaBase. Eu usei o nome que vc mencionou em um email, mas não sei se é PastaBase literalmente ou se aquilo era uma referência a uma pasta base.
Se não for esse o nome tem que trocar no fonte.
Corrigindo isso deve funcionar.
É bem simples: antes de montar a tag, o programa verifica se o arquivo PNG existe. Se não existir, ele vai tentar renderizar com o emoji raiz e uma moldura vermelha. Mas se nem o PNG do raiz existir, então o programa usa uma tag span para mostrar o UNICODE mesmo.
Isso do Git é simples. Vc não está em um repositório. Pra dar comandos tem que estar no repositório.
O Git Bash tem que ser sempre executado dentro da pasta do repositório. Não pode ser um pasta filha e nem pasta mãe. Tem que ser a pasta do repositório.
Claro, antes de criar o repo não havia pasta do repo. Então o clone é feito na pasta que virá a ser a mãe do repo.
Compilei e fui logo executar o GetPngs. Ele pede o arquivo whatsapp-emojis.html, mas a janela que se abre espera por uma pasta. Acho que tem um erro aí. Ele não devia especificar exatamente um nome, mas deixar escolher um arquivo qualquer.
Vi depois de renomear o arquivo que ele aceita arquivo mesmo, e não apenas pastas. Mas o nome podia ser de qualquer HTML.
Outra coisa: descobri por que eu não estava conseguindo exibir todos os emojis quando abria o HTML. Era porque eu estava offline. Estando online, tudo aparece como deve ser. Eu abri offline porque a pasta com todos os PNGs já estava baixada e eu não queria que fosse buscado nada online. Mas precisava do estilo ou de outra coisa aí.
Meu amigo vou ter que sair agora mas felizmente não é pra votar porque o cara aqui levou no 1 turno.
Vou almoçar na rua porque o almôço aqui tá caidasso.
Bon appetit
Ele deixa escolher qualquer arquivo HTML
Tem razão. Mas não vê os que são só HTM.
HTM não. Precisa? Isso é fácil de corrigir, você mesmo pode fazer aí.
O nome é mesmo PastaBase sim.
HTM não. Precisa? Isso é fácil de corrigir, você mesmo pode fazer aí.
Vou fazer depois.
É na linha 45 do fonte DownloadsPngs.java
Tem que acrescentar mais um parâmetro na chamada do método. Acrescentar (depois uma vírgula) "htm".
Bom, vou nessa. Acho que vai tudo funcionar aí.
Linha 46 na verdade...
Valeu! Bom apetite.
@Gabarito007
Então vamos começar um novo projeto em substituição ao show-emojis.
A documentação poderá ser consultada no link abaixo:
https://phedroreis.github.io/whatsappweb-fix/
No momento, nesta página, vc verá apenas a cópia da introdução da documentação do projeto show-emojis. Na próxima atualização esta página já vai mostrar as especificações do projeto.
Minha intenção é que dê para seguir o desenvolvimento desde o iniciozinho. E sugestões podem ser feitas à medida em que as classes são desenvolvidas.
Por exemplo: os arquivos HTML devem referenciar uma Pasta Base? Qual o nome dessa pasta?
Este projeto não deve ter muito código. Serão classes pequenas e a lógica de programação deve ser razoavelmente simples. Seguindo desde o início acredito que seja possível compreender todo o código.