Xamanian

Juan, este branding é para Primo e Nextgen. Para usá-lo no iGO 8 ou no Amigo você terá refazer o arquivo de branding, mas é possível aproveitar os arquivos de imagem (bmp) que estão neste branding. Já o problema que você falou sobre o erro apontando o poi_brand.spr não é bem de resolução, mas sim de arquivo bmp configurado no spr e que não está sendo encontrado em seu navegador. Mas também pode ser a ausência deste arquivo spr, que tipicamente fica no data.zip. A maneira de resolver é abrir o data.zip e tentar localizá-lo, se não for localizado, então é necessário pegar de outro pacote e inserir no seu. .XA.

Amigo d780, o alerta de voz que anuncia "semáforo" a partir do global_cfg é dado pelo arquivo config_database.lua que fica no arquivo de voz na pasta config. Ele é responsável pelas informações de manobras (vire à esquerda, em x metros, no próximo semáforo, etc.). E você tem razão, as informações sobre pistas e manobras são os ditos Alertas de Condução (drive alerts) que usam os ícones do global_cfg para alertas visuais e o arquivo de voz para os alertas sonoros. Não são pontos de alerta. Abraços, .XA.

Amigos Jorge e Cláudio, a placa de "pista irregular" (Adverte ao condutor do veículo da existência, adiante, de um trecho de pista com superfície irregular) realmente existe: Por outro lado, teremos mais um ponto de alerta. Até hoje, aqui no nosso país, apenas o MapaRadar e o Fidelis se encarregam de cadastrar os pontos de alerta e a placa "pista irregular" não faz parte do banco de pontos de alerta de ambos. Ou seja, na prática ficaria se cadastro. Entendo que o caso "buracos na pista" é diferente, pois a minha intenção, ao fazer essa modificação em skin diMka para Primo, era que o próprio usuário pudesse inserir e remover estes pontos de alerta manualmente, independentemente do MapaRadar ou do Fidelis, uma vez que buracos surgem e são tampados com o tempo. Serve como alerta para não "cair" sobre os buracos; só isso. Já o "pista irregular", não, porém não sou contrário ao seu uso como ponto de alerta no Nextgen. Abraços, .XA.

Jorge, Cláudio e demais colegas, o uso do ícone do cone foi introduzido por mim em skin diMka para Primo que modifiquei. Para isso usei o Type 24, que estava vazio até então e usei as seguintes linhas no lang e no voice: Hole in the ground="Buracos na pista" Hole in the ground,="Buracos na pista" Hole_in_the_ground="Buracos na pista" A minha ideia era usar este ponto de alerta (buracos na pista) para cadastrar eventuais buracos, mas de forma manual, inserindo este ponto de alerta pelo próprio Primo e excluindo quando tampados. Não pensei em criar um novo ponto de alerta para ser adotado pelo MapaRadar ou pelo Fidelis, já que buracos surgem e somem com o tempo, de modo que defendo que deve ser um alerta para o usuário administrar, pois entendo que isso é regional, ou seja, algo na região que a pessoa mais transita. Não tive motivo técnico para escolher o type 24, pode ser qualquer um, mas o uso do recurso e do ícone do cone me parece bem interessante e deveria ser mantido (não importando o type escolhido). Abraços aos amigo, .XA. EDIT: é preciso modificar o módulo ux para que o recurso seja habilitado (ou seja, tem que inserir as frases acima no módulo ux no lugar correto, além de modificar lang e voice).

Amigo Jorge e demais colegas, concordo com as sugestões apresentadas pelo Jorge para modelos de ícones no padrão BR. Acho que estamos no caminho certo para deixar o Nextgen com um visual mais natural, exibindo placas e indicadores que encontramos diariamente nas ruas e rodovias. Vai ficar muito bom! Abraços a todos, .XA.

Amigo Jorge, vamos lá! 1. Câmera no semáforo: a ordem dos primeiros ícones (Primo) é a seguinte: Type 1: Speed Camera (Radar fixo) Type 2: Built-in Speed Camera (Radar no semáforo) Type 4: Red light camera (Câmera no semáforo) Type 3: Average speed camera (Câmera de velocidade média) Type 1: Mobile speed camera (Radar móvel) (...) Type 11: Red light and speed camera (Semáforo com radar) Note que os ícones para o Type 2 e 11 são iguais. Motivo: o Type 2 não é usado aqui no Brasil, mas deveria. Por algum tipo de erro no passado, optou-se por usar o Type 11 para descrever "semáforo com radar". No lang eu mantive esta tradução, mas observe que ela está errada! O correto seria, em termos modernos, escrever "radar inteligente" no Type 11, uma vez que a tradução literal seria "semáforo com câmera e radar". Semáforos que detectam excesso de velocidade, cruzamento de veículos após fechamento (vermelho) ou parada do mesmo sobre faixa de pedestres são atualmente ditos radares inteligentes (por detectarem várias infrações). Note também que os ícones dos Types 2 e 11 têm uma câmera ao lado do símbolo do semáforo (deveria ter um radar e uma câmera no Type 11). O Type 4 (também usado no Brasil, corretamente, pelo MapaRadar) só tem um semáforo (terceiro ícones no print que postei antes), mas deveria ter uma câmera ao lado do mesmo. Pensei em mudar isso anos atrás, estes ícones "confusos", mas optei por deixar assim, pois já havia um entendimento do significado de cada um. Mas gosto da ideia de inserir uma câmera no ícone do Type 4 (que pode ser o mesmo para o Type 2 ou 11) e usar um ícone de radar sobre a figura do semáforo (tipo o ícone do Type 1, reduzindo o tamanho e colando o mesmo no ícone). Já o Type 11 (que usamos no país) deveria ter a figura do semáforo (gosto deste que uso) com uma câmera e um radar (ambos do mesmo lado, um acima e outro abaixo), pois daria real significado (radar inteligente). 2. Radar móvel: usei uma figura já consagrada no país, mas não é um padrão BR. Apenas inseri um pequeno radar na viatura. Mas gosto do ícone que citou, o tripé é mais real. 3. Pedágio e Polícia rodoviária: você tem total razão, os ícones estão fora do padrão, pois não existe placa padrão para estas duas categorias. No caso da placa para pedágio, peguei um ícone retratando uma cabine de cobrança de pedágio e inseri sobre um fundo que simula uma placa sinalização de indicação (placa azul e branco). Já para o ícone de polícia rodoviária, preferi usar um ícone consagrado no país desde o iGO8, que é o logotipo oficial da polícia rodoviária federal. Por outro lado, aqui no Brasil nós tratamos os pontos de alerta ditos "polícia rodoviária" os postos de policiamento federal e estadual. Mas não modifiquei algo que já estava consagrado e bem entendido pelos usuários de navegadores GPS. Baixei os ícones do nosso amigo Alain, vou ver depois; obrigado aos dois amigos. 😉 Abraços grandes, .XA.

Amigo Jorge, a imagem abaixo contém os ícones que eu e o Adinis fizemos para o Primo e que uso até hoje. Essa é a minha sugestão de ícones para o Nextgen. Os arquivos de imagem (png) do tipo camerakSMSS_XX enviados anteriormente contêm todos estes ícones e podem ser usados caso haja concordância dos membros deste fórum interessados nos ícones no padrão BR. No caso do Primo, os arquivos camerak são usados nos menus e no blink (alerta visual na tela de navegação). Já os ícones das placas que aparecem na tela de navegação são aqueles que ficam no arquivo speedwarnXX.bmp (na skin ou no data). No caso do Nextgen, os ícones dos menus ficam na subpasta \res\nodpi (e são vetoriais, svg). Caso as demais subpastas da pasta \res não contenham ícones, então os arquivos da subpasta nodpi também serão usados na tela de navegação. Fiz testes no passado usando arquivos speedwarnX.bmp (X = 0, 1) nas demais subpastas da pasta \res e funcionou muito bem, mas eles só aparecem na tela de navegação (claro, não precisa ser bmp, o formato svg também funciona nestas subpastas). O problema está com os ícones da subpasta nodpi (só aceita svg mesmo). Estes ícones são usados na tela capturada que você postou acima, dois prints. Como defendo ícones diferentes para menus e tela de navegação, sugiro que se use ícones planos (como na figura acima) na pasta nodpi e ícones contendo as placas sobre "pezinhos" (simulando um pequeno poste) nas demais subpastas da pasta \res. Visualmente fica muito melhor. Abraços, .XA.

Jorge, sim, o "cruzamento de linha férrea" era a expressão usada antigamente no lang; eu fui a pessoa que o usou a expressão "passagem de nível" pela primeira vez, que é a forma correta. Quando resolvi modificar o lang existente até então, modifiquei todas as expressões traduzidas literalmente por expressões oficiais no Código Brasileiro de Trânsito. Escrevi de modo "antigo" para me fazer entender. hehehe Não estava conseguindo postar o meu texto original, parece que deu algum problema no fórum nos últimos dias. Mas o link do arquivo que postei acima você poderá encontrar os ícones do Primo em 800x480, sendo os ícones do tipo camerakSMSS_XX em resolução bem adequada (acima de 220 px), que entendo adequados para uma base para compor os ícones do módulo ux que estamos tratando aqui no tópico. Aliás, acho que os ícones do tipo radar (os 5 primeiros) melhores e que contemplam os comentários do Cláudio mais acima. Abraços

Deixo aqui o link para modelos (sugestão) de ícones: https://www59.zippyshare.com/v/qvQXG6qg/file.html .XA. Edit: só consegui postar isso. O site aimore.net contém todas as placas de trânsito do país, onde é possível baixar as figuras em ótima resolução.

Pessoal, não consigo postar nada. O que está acontecendo? Nos últimos dois dias não conseguia nem entrar no fórum.

Caro amigo Jorge, agradeço muito pelo empenho em oferecer os ícones dos pontos de alerta no padrão BR. Realmente não existe regulamentação para muitas placas. Quando fiz os ícones para o Primo procurei fazer uma adaptação dentro do possível, usando o fundo de placas regulamentares e inserindo ícones específicos, simulando o visual. Como exemplo, cito a placa de corpo de bombeiros que aparece no modelo 1 acima. Aquela ambulância na placa não existe, foi uma criação minha na época. Em relação aos ícones, entendo que as placas com "pezinhos" (como um poste onde estão presas) não são adequadas para uso nos menus de configurações, apenas na tela de navegação. Os menus devem conter apenas ícones planos, pois visam a identificação dos pontos de alertas. O efeito 3D também fica estranho em ícones de menus; devem ser o mais simples possível. Além disso, observo que o ícone para "cruzamento de linha férrea" está errado no modelo 2, o símbolo é na cor preta e não vermelha (e é uma placa regulamentada). Daqui há pouco voltarei neste post, o editarei e irei inserir alguns arquivos do Primo que podem servir de modelo para os nossos amigos Cam1981 e Alain57 analisarem. Grande abraço, .XA.

pyoneiro, não tenho essa skin, mas vou tentar ajudá-lo. Abra o data.zip e localize a subpasta \common\ui e localize o arquivo general.ui. Faça uma cópia do mesmo para o seu computador, abrindo-o em seguida com um editor de texto (Bloco de Notas, NotePad++, etc.). Localize o parágrafo abaixo: <element_template et_UiStatus> Verifique se as linhas a seguir aparecem abaixo do parágrafo indicado acima: <layer ui_Status z=151 visible=(%lua.showstatusbar)> <implementation> <property statusListWidthPercent value=((min(5, %ui.statusHeader.size + %ui.statusPlugins.size)) * 5)> <property pos value=(lua.uiResW * (89 - statusListWidthPercent) / 100)> </implementation> <DIV class="header title"> <SPRITE x=1% y=25% z=20 bmp="batterylevel_ico.bmp#10" phase=%power.battery_phase visible=(%power.battery_phase != 10 && !%power.is_charging && !%lua.automotive)> <SPRITE x=1% y=8% z=25 bmp="batterychargeing_ico.bmp" visible=(%power.battery_phase == 10 && (%power.real_battery_percent < 99 || !%power.real_battery_percent.valid ) && !%lua.automotive)> <SPRITE x=1% y=25% z=20 bmp="batteryfulllevel_ico.bmp" visible=(%power.real_battery_percent > 98 && %power.real_battery_percent.valid && %power.on_acline && !%lua.automotive)> Estas linhas são as responsáveis para a exibição dos ícones de carga da bateria. Além das linhas será preciso ter os arquivos bmp indicados acima (batterylevel_ico.bmp, batterychargeing_ico.bmp e batteryfulllevel_ico.bmp) que deverão ficar na pasta de resolução da skin (por exemplo, 800_480). Não sei dizer se a skin Evo é uma modificação dentro do data.zip ou se é uma skin que fica na pasta \content\skin. Se for do segundo caso, então procure pelo arquivo general.ui na correspondente pasta \common\ui dentro da skin e siga os procedimentos apontados, fazendo as modificações, salvando o arquivo e retornando com ele para dentro da skin (faça backup da skin antes de modificá-la). Não se esqueça de verificar se a skin possui o bmp indicado, caso contrário o sistema irá abortar o carregamento e apontará falta de arquivo. Talvez seja necessário modificar mais um ou outro arquivo da pasta \common\ui (talvez o template e mais alguma coisa). Não tive tempo para avaliar todas as modificações necessárias, mas a indicada é essencial. .XA.

Pessoal, vou dar uma dica para quem está tendo problemas com a sincronização de satélites. Entre na subpasta iGO_ISRAEL => save => profiles => 01, localize o arquivo system.ini e o abra. Apague todas as linhas sob as seções [adaptive_routing_statistics], [config] e [gps]. Na seção [interface] apague toda alinha que se inicia por last_sys_time=... Observação: não é indicado editar este arquivo diretamente dentro de um sistema Android. Ao tentar salvar ele vai pedir para salvar em outro lugar e com outro nome de arquivo. A sugestão é copiar o arquivo para o computador, editar, salvar e copiá-lo para a correspondente pasta no dispositivo Android. Os parâmetros acima guardam informações sobre o local, data e hora da última sincronização de satélites. Como todas as pessoas (exceto a que gerou os dados no system.ini que está no pacote) se localizam em lugares diferentes, o navegador GPS tenta sincronizar os dados de satélites a partir daquilo que está no system.ini do pacote. Como não será possível, por estar a pessoa em outro lugar, o tempo de sincronização aumenta enormemente. Ao apagar os dados, o navegador GPS é forçado a baixar novas informações e não em atualizá-las, demandando menor tempo. E se houver demora mesmo assim, de duas, uma: ou o dispositivo está fora de alcance de localização de satélites; ou o número de satélites localizados é baixo. Nesse caso, é só ir para uma área aberta e aguardar um pouco mais. A dica acima vale para qualquer navegador GPS, principalmente aqueles da família iGO. Não é preciso e nem recomendado apagar toda a pasta Save. Ela contém muitas configurações importantes do navegador, de modo que ao deletá-la todas as configurações serão as de fábrica, forçando o usuário a ter que configurar tudo do zero. Abraços, .XA.

Amigo Max, obrigado por fazer testes e reportar a sua experiência. 😉 Diferença entre as duas versões que disponibilizei: na pasta xhdpi da versão 1 os ícones têm tamanho 75 px e 80 px na versão 2. E na pasta xxhdpi a versão 1 tem tamanho 120 px e a 2 tem tamanho 130 px. Como você está usando a resolução HD, ela usa (ou deveria usar) os ícones da pasta xhdpi, onde 75 ou 80 px não faz muita diferença. Por outro lado, como você deve ter acompanhado o debate, aqui comigo a resolução HD usa a pasta hdpi, onde os ícones das duas versões têm tamanho padrão de 60 px. Este é o tamanho de ícone usado em Primo na resolução 800x480, que deveria ficar muito pequeno em 720 (resolução HD). Se o seu pacote é este aqui deste tópico, então você está com ícones em tamanho 60 px, que creio ficar pequenos. Mas se gosta, tranquilo. E sim, versão final pode usar. Neste final de semana vou postar todos os branding lá naquela seção do Primo, em tópico que criei anos trás; os dois branding para Nextgen estarão lá também, mas são estes dois que te passei (estes são de versão final). Abraços, .XA.

Boa tarde, amigo Jorge. Sim, já conhecia estes dois projetos. A questão do branding lá no GPS Power começou logo após a novidade Nextgen e acompanhei tudo de perto. Os membros mais atuantes disseram que o formato para o branding no Nextgen era o mesmo do Primo. E insistiram nesta tese por vários anos inclusive. O trabalho do Seria (um amigo português) seguiu esta lógica, por isso ele fez o branding com bmp (recomendação, digamos). E eu tentava me adaptar ao Nextgen e simplesmente comecei a fazer o branding seguindo esta lógica, mas o tempo me mostrou que o branding não foi pensado, para o Nextgen, para usar os bmp, mas os vetoriais svg. Daí com o tempo branding do tipo criado pelo Stefando e outro. E como saber que o branding só usa arquivos svg? É fácil, basta abrir o data.zip e na subpasta uI-nextgen\res\common\nodpi. Todos os arquivos para POI estão nesta subpasta indicada. E não tem nada relacionada a POI nas demais subpastas da \common. Por outro lado, ouvindo/lendo os caras mais experientes do fórum citado, a conclusão é que era para dar certo com arquivos bmp também. E claro que dá, exceto pelo fato que parece não haver uma regra para uma dada resolução acessar a pasta esperada. Mas como raramente alguém usa um pacote Nextgen sem a skin Pongo/Arimi, então imaginei que tais afirmações poderiam ser balizadas em algo preparado para funcionar corretamente. Ou seja, a mesma coisa que a gente fazia tempos atrás nas skins diMka para Primo; fazíamos com ela o que queríamos. E aí, por ter ficado longe do Nextgen por muito tempo, fiquei sem saber o que estava acontecendo em relação ao branding. Então passei os últimos dias dando uma estudada (mas rapidamente) nos arquivos da skin Pongo. Ele manteve a mesma lógica da skin padrão, usar arquivos svg vetoriais que ficam na basta nodpi. Uma pena. E se ele quiser, ele pode mudar isso. Não faço isso porque ele vive modificando a skin, mas pasta setar as pastas de resoluções várias ao invés de setar apenas a pasta nodpi. Ah, mas tem como passar os bmp para svg? Já tentei e não gostei dos resultados. O que me pareceu mais prático foi usando o Corel, mas o arquivo aparece transparente no Nextgen. Já o o Illustrator não me deu bons resultados visuais. E qual o problema maior na conversão? Ter que converter cerca de 3200 ícones. Daí a insistência (minha) em manter os bmp, pois refazer do zero 3200 ícones em formato vetorial svg seria uma loucura. É isso, amigo. 😉 Abraços, .XA.

Caro amigo Max81, seguem dois branding com os ícones tendo os tamanhos que eu usava antes. Tem duas versões: em cada uma das subpastas presentes no arquivo do link (sem senha) criei um arquivo Tamanho.txt que indica em dpi o tamanho dos ícones em cada pasta. Na versão que postei anteriormente neste tópico, a pasta xxxhdpi contém ícones na dimensão 174 px; já nas duas que seguem no link estão no tamanho 148 px. Veja o que é melhor para o seu uso. Observo que a resolução 720 usa a pasta ldpi (ao menos no que diz respeito ao pacote deste tópico). Tente usar os bmp's nesta pasta de acordo com os tamanho que informo no txt do arquivo do link. Claro, faça backup antes de modificar os ícones. E se usar o bom e velho Winrar, basta selecionar a pasta correta, selecionar todos os ícones (descompactados antes) e arrastar para dentro do Winrar para fazer uma rápida substituição dos arquivos. Eis o link com duas versões (tamanhos diferentes de ícones): https://www103.zippyshare.com/v/kTNajzbg/file.html Observo que na versão original (ou seja, a minha proposta original de branding) a pasta xhdpi era para ser usada pela resolução 720 (HD), mas ela está usando a pasta hpdi (que seria de ícones com tamanho 60 px). Uma versão do link tem ícones de 75 px na pasta xhdpi e a outra tem ícones de tamanho 80 px. Basta copiar os bmp's do tamanho indicado em uma dessas pastas para a que está sendo usada, ou seja, a pasta hdpi. Abraços, caro amigo, .XA.

Pessoal, deixo aqui uma sugestão para ajustes de zoom: basta inserir as linhas abaixo na seção [map] no sys.txt: [map] 3d_max_tiltlevel=8500 3d_max_zoomlevel=14000 3d_min_zoomlevel=10 3d_scale_carmodel=1 building_render_distance_far_front=6.0 building_render_distance_far_back=3.0 building_render_distance_medium_front=3.0 building_render_distance_medium_back=2.0 building_render_distance_near_front=2.0 building_render_distance_near_back=2.0 minimum_rotate_amount=15 minimum_tilt_amount=70 minimum_zoom_amount=70 speedcam_visibility=2500 tiltfactor=30 Agora vou experimentar ajustar as larguras das vias através de comandos no sys. Assim que encontrá-los vou iniciar os testes, funcionando, posto as dicas aqui. Abraços, .XA.

Arbex, este é o inconveniente de setar dpi="auto" no sys. Isto implica em ajustar tudo em função da resolução da tela. A saída é fazer o que o Nelson indicou acima, tentar setar o dpi para valores mais elevados, pois isto equivale a dar maior zoom, deixando o visual do mapa mais próximo. Também é possível ajustar o zoom manualmente, mas ainda não fiz testes com o Nextgen. Farei testes neste sentido e caso obtenha algum resultado positivo, então posto aqui em momento oportuno. Por ora, tente dpi=480 ou dpi=640 e veja o que fica melhor para você. Abraços, .XA.

Como assim passar do ponto, amigo Jorge? Você sempre acerta o ponto! Não sei dizer ao certo, mas tempos atrás existia um problema de compatibilidade de pacotes com a skin do Arimi e a do Pongo, ou seja, exigiam ajustes específicos para funcionarem corretamente. Este problema acabou? Não lembro o problema, mas acho que até data.zip tinha que ser trocado. Aliás, nunca gostei dessa skin (feia de doer. hehehe). Ainda acho que o problema é módulo ux. Muitos foram feitos migrando-se programações do que existia para Primo para o Nextgen e isto dá problema mesmo. A programação LUA do Nextgen é diferente da LUA usada no Primo. A questão é que, no Nextgen, o número de módulos ux aumentou muito, pois não é possível ter uma skin específica como era antes. Assim as skins para o Nextgen são adaptações da skin Padrão, como eram as antigas Gurjon, etc. E aí é módulo ux em cima de módulo ux. É difícil saber o que está gerando o problema, mas ele existe e não acredito que esteja na skin do Pongo (insisto, até pode ser problema nesta skin, mas por ora descarto). O que posso afirmar é que em teste com um Nextgen original (aquele app vendido na Play Store) este problema não existe, ou seja, que as pastas são usadas corretamente. Mas para quem não se incomoda, vale o macete para o branding: qualquer resolução abaixo de Full HD usa a pasta LPDI e de Full HD para acima a pasta usada é a XXHDPI. Basta colocar os ícones com os tamanhos adequados, os que mais agradam, em uma dessas duas pastas. É paliativo? Sim, claro, mas funciona. Só que não era para ser assim. hehehe Abraços, amigo Jorge! .XA.

Pessoal, tem problema? Tem sim, mas vamos resolver. Se tem uma coisa que gosto é de desafios, mas não de disputas. E se temos um desafio, então vamos buscar soluções. E contem comigo para ajudar a comunidade que adotou o Nextgen. Mas gostaria de propor algo: que alguém sugerisse um tópico específico para este tipo de discussão. Assim a gente não polui o (ótimo) tópico criado pelo Jorge com assuntos correlatos, mas não específicos para este tópico aqui. Outra coisa: Moderação e Administração, não dá para manter as seções sobre navegadores Android lá no "fim da fila" na página inicial do fórum. Isso já deu e faz tempo. Sugestão: usar ordem cronológica nas seções. Ou seja, o que é mais novo e atual no início e depois os seguintes. Exemplo: (Garmin pode começar ou não, deixo por conta), mas vejo assim as seções: Android GPS (que deveria receber o nome de iGO Android) => iGO Primo => iGO Amigo => iGO 8 => etc. Faz um bom tempo que navegador GPS é baseado principalmente no S.O. Android, deveria ser a primeira seção na página inicial. O restante deveria aparecer depois, não por demérito, mas por obedecer uma ordem cronológica dos navegadores. Assim penso e acredito. 😉 [ ]'s .XA.

Cláudio, pois é, algo inesperado está acontecendo e não sei dizer se é na skin ou em algum módulo ux. A Full HD foi feita para usar os arquivos da pasta xxhdpi e isso está correto. Mas a resolução Quad HD (1444 px) usar a mesma pasta é uma excrescência sem igual. Como comentei, o que importa é o número de pixels das linhas e não as das colunas, pois os fabricantes de smartphones, tablets, etc. não se prendem mais à proporção 16:9. Para você tomar como exemplo: a Samsung anos atrás saiu da proporção 16:9 (a dita padrão cinema) e foi para 18:9, depois para 19:9 e chegou a proporção 20:9 nas linhas Galaxy S20 e Note 20 (pelo que li, esta última proporção de tela será mantida na nova linha Galaxy S21). Ou seja, aumenta-se o número de linhas, mas o número de colunas é aumentado. Daí a terminologia HD+, FHD+ (Full HD extended), etc. Para ficar claro o que chamo de linhas e colunas, pense em um smartphone em modo paisagem, onde a parte menos estreita é o número de linhas e o mais expandido é as colunas (no modo retrato a coisa se inverte). D780, não é assim como você pensou. A regra é a seguinte: DPI = sigla em inglês que significa "Dots Per Inch" (pontos por polegada quadrada). Assim, tem-se: LDPI = DPI baixa (onde o L significa low, baixo) MDPI = DPI média (M = Middle) HDPI = DPI alta (H = High) XHDPI = DPI extra alta XXHDPI = DPI super alta XXXHDPI= DPI hiper altra Este super significa "extra extra" e o hiper significa "extra extra extra". Em inglês é assim, repete-se a mesma palavra para significar os superlativos. E claro, o que escrevi acima é uma adaptação e não uma tradução literal, pois fica mais fácil de ser entendido. O problema não está no significado nos nomes das pastas, mas sim no uso indevido de pastas para as resoluções esperadas. Até hoje, até onde eu sei, não existe smartphone com tela em 4K, o máximo que conheço é a Quad HD (1440 linhas, não importando o número de colunas, ou seja, se 2560 px ou mais). Na verdade este Quad HD tem o dobro de linhas e o dobro de colunas da resolução HD (720 linhas por 1280 colunas), o que resulta em ter quatro vezes mais pixels por polegada quadrada (DPI) do que a resolução HD. O 4K é a mesma coisa, dobra-se o número de linha e dobra-se o número de colunas da resolução Full HD e obtém-se quatro vezes mais pixels por polegada quadrada do que a FHD. Mas por que no Nextgen esta lógica não está funcionando? Não é o Nextgen e nem o pacote, acho que é módulo ux mal feito ou que está introduzindo erro crônico. O Pongo pode ter errado alguma coisa em sua skin, mas pelo que fiz, hoje e apenas hoje, afirmo: duvido! Abraços, nobilíssimos amigos. 😉 .XA.

Pessoal, não estou entendo bem a lógica dessa versão do Nextgen, está diferente do que eu conhecia, talvez o Pongo tenha mudado certas coisas. Mas antes de continuar deixo um link para o branding (apenas para testes iniciais; e sem senha): https://www3.zippyshare.com/v/QLkg17Xp/file.html A questão é a seguinte: em linhas gerais, a resolução HD (720 linhas) deveria usar os arquivos da pasta xhdpi; a resolução Full HD (1080 linhas) deveria usar a pasta xxhdpi e a resolução Quad HD (1440 linhas) deveria usar a pasta xxxhdpi. A pasta ldpi deveria ser a correspondente da antiga resolução 320x240, a mdpi corresponderia a 480x272 e a pasta hdpi corresponderia a 800x480; isto para manter a retrocompatibilidade. As duas resoluções pouco usuais, 1024x600 e 1024x768 (usadas em certas CMs) usariam, em tese, a mesma pasta xhdpi. Na verdade, o que importar é o número de linhas da tela, o número de colunas não importa, uma vez que cada fabricante de dispositivo usa resoluções e proporções várias. Ou seja, é o número de linhas que determina qual é o melhor tamanho para os ícones. No fundo é isso. Mas nesse pacote a resolução HD está usado os arquivos da pasta hdpi e as resoluções Full HD e Quad HD estão usando, ambas, a pasta xxhdpi. Isto não está correto, tem uma falha gritante aí. As informações que mencionei acima sobre tamanhos de ícones e localização foram baseadas no data.zip de um Nextgen original, onde os arquivos originais da NNG para os POI estão no tamanho que usei para elaborar os meus, mas com uma diferença: uso tamanho ligeiramente maiores. Exemplo: o tamanho para ícones da pasta hdpi é 52 px, eu uso 60 px. Então, na prática, para usar um branding com este pacote é preciso reestruturar tudo. Colocar ícones maiores (90 px) na pasta hdpi para a resolução HD, sem problemas. A questão que não se resolve é com as duas resoluções superiores, a Full HD e a Quad HD, simplesmente porque elas usam a mesma pasta (a xxhdpi). Então, se um ícone fica com tamanho bom para a Full HD (130 px), ele fica pequeno para a Quad HD (174 px); se os tamanhos forem invertidos, fica ok para a Quad HD, mas ficam gigantes para a Full HD. Tentei verificar a skin do Pongo, mas não encontrei nada apontando problema. Até pode ser a responsável, mas o que digo é que não encontrei. Em virtude disso, passo a desconfiar de algum ux como o causador do problema. Mas qual? Não sei. De qualquer forma, quem quiser testar o branding do link acima e dar um retorno será muito útil. Peço que a Moderação entenda que trato do assunto branding em um tópico sobre um pacote baseado no Nextgen, me perdoando pelo lugar errado. Mas justifico: o problema que encontrei foi aqui, em virtude de algo que tem no pacote. Aliás, não culpo o pacote e muito menos o amigo Jorge, é algo que está no pacote e que pode até mesmo ser coisa antiga e não notada por ninguém, até mesmo pelo Pongo. Os branding para Primo WinCE e Android já estão prontos e será postado em momento oportuno naquele tópico que criei anos atrás, onde escreverei um post informando que os links foram atualizados. 😉 .XA.

Salve amigo Montagner! O idiota aqui baixou a versão do primeiro post e só agora, após seu post, notei que instalei uma versão antiga (170120210603, do Jorge). Ô idade!... 😂 Vou instalar a nova (que realmente tem o apk), obrigado. E aproveito para adiantar que uma nova versão do branding está quase pronta. Todos os ícones estão prontos, agora estou fazendo testes. 😉 Abraços, .XA.

Jorge, baixei o seu pacote, mas não tem o apk. No post inicial você fala que ele está na pasta raiz, mas não tem nada de apk em todas as pastas. Você poderia upar o apk? Ah, estou usando Android 11; espero que o apk funcione. Abraços, .XA. EDIT: encontrei o apk na versão indicada no primeiro post. E ele funciona corretamente com Android 11. Porém reafirmo que o apk não está presente no pack do primeiro post.

Fernando, tempos atrás testei as minhas schemes em uma versão mais antiga do Nextgen e funcionou, mas não testei tais schemes neste pacote do Jorge. No smartphone eu tenho uma versão paga do Nextgen e que é chatinha para fazer testes. Vou desinstalar e tentar instalar a versão do Jorge e fazer testes. Reporto depois aqui. Abraços, .XA.