Aplicativos em segundo plano do GNOME estão fazendo sucesso!

Desculpa mas acho q vc misturou bastante mobile com desktop. Essa característica de notificação em cima do ícone do app é mais presente em sistemas mobile e n em sistemas de desktop. Ex: Windows (só o sistema de desktop mais usado no planeta) não usa isso já q ainda a maioria dos apps dele não vem proveniente da sua loja e sim de instaladores de terceiros o que altera drasticamente o controle sobre notificações.

Não é bem por aí, isso é um uso errado do recurso, minimizar pela bandeja e minimizar são conceitualmente diferentes, minimizar significa “ocultar” esse nome vem da forma como o Windows 3.x fazia

Não, o espaço no desktop é limitado além disso, nem toda aplicação faz sentido ter uma janela, exemplos disso são applets, olhe essa imagem:

image

Cada um desses itens com uma seta para a direita, são applets (o GNOME, o KDE, o MATE… podem chamar de outra forma, mas o conceito é o mesmo) ou seja, subaplicativos que estendem o funcionamento do aplicativo principal (Shell), em um mundo ideal, o DE fornece uma API (tipo uma cola) que permite fazer esses aplicativos, isso iria permitir que o desenvolvimento do applet de bateria do GNOME não só pudesse ser executado no KDE por exemplo, como ele se integraria perfeitamente, o tray é o que chegou mais perto disso

O problema é que notificações são distrativas e difícil (se não impossível) implementar elas de forma realmente eficiente, quando o app altera o estado raramente elas “funcionam” porém nem sempre é o caso, uma sincronização não linear de arquivos, como funcionaria? Você não pode por uma barra porque não é linear, duas barras podem confundir o usuário, notificação? Imagina centenas de arquivos, quantas seriam as notificações, seriam persistentes, seriam a parte? Se é pra implementar a systray usando barras de notificação, porque não fazer uma tray suspensa logo? Poupa tempo e saúde mental tanto dos devs quanto dos usuários

Quais apps?

o que seria uma informação útil que justifique tirar o usuário de seu foco?

Pessoal,

Concordo que o tray pode tirar o usuário de seu foco.
Mas no Gnome 45, como então o usuário faz para entrar em contato com os apps que estão em segundo plano?

No meu Void LXQt, bastava eu clicar em um deles diretamente no tray que eu deixava no canto do painel, junto ao relógio.

Eu acesso o Joplin (tipo Evernote) inúmeras vezes durante meu trabalho. Mas no Gnome, quando clico em fechar (X), ele simplesmente desaparece, aí o que faço é carregá-lo novamente. Então penso que cada caso é um caso, e no meu caso torna-se improdutiva a ausência do tray.

Vai dizer que o Joplin não tem um ícone que é exibido no dock/painel? Tem sim! Então você não precisa de mais um ícone pra fazer a mesma coisa!

Mas tudo bem, eu entendo que vocês não estão abertos a discutirem se um conceito arcaico deveria ser revisto. A equipe do Gnome felizmente já discute isso a muito tempo, e eles chegaram a conclusão de que system tray é desnecessária graças a grande quantidade de recursos que já existem.

Somente desenvolvedores que não se atualizaram usam system tray, até mesmo no Windows poucos são as aplicações que usam essa funcionalidade.

O tray é útil para esse tipo de coisa:


Para coisas assim, ter uma janela da coisa seria só mais foco indo pelo ralo gerenciando + uma janela.

Eu vivo sem o tray porque atalhos de teclado são naturais para mim, estes aplicativos colocam atalhos de teclado no sistema, mas atalhos são meio que o nêmesis de várias pessoas que conheço. Por esse motivo eu acho que o tray agrega.

1 curtida

Definitivamente não é isso, estar aberto a discussão sobre um guia de interface humana e aceitar um guia quebrado por design são duas coisas completamente diferentes

A discussão sobre a tray remota o System 7 da Apple e nunca parou, inúmeras soluções foram propostas a do GNOME não é a primeira, nem a mais eficiente quem chegou mais perto de realmente substituir a tray é KStatusNotifier do KDE, como exemplificado acima a implementação do GNOME além de ser incompleta, está quebrada

1 curtida

Na verdade não é que o Gnome apresenta uma implementação incompleta, é que as pessoas resistem a mudanças. E eu estou falando aqui é de desenvolvedores mesmo.
Particularmente eu não entendo essa tara por colocar ícones ao lado do relógio, cada um criar seu próprio sistema de notificações ignorando as preferências globais do usuário, e até mesmo em alguns casos os aplicativos tendo o próprio tema (sim, existem aplicativos que insistem em terem um tema próprio, principalmente quando é software proprietário).

Acho que agora eu entendi o ponto, você tem uma ideia errada do que é uma tray, então pra entender porque a solução do GNOME é incompleta, você precisa entender que , uma tray não é:

  • Ícones ao lado do relógio, isso é uma decisão da Apple que foi seguida ao longo dos anos sem questionar, mas realmente não é preciso nem ser apenas ícones, nem muito menos estar ao lado do relógio

  • Não são sistemas de notificação, a ideia do tray não é ser um sistema de notificação embora possa ser usado não é esse o objetivo

Uma tray é uma região do sistema operacional que permite que desenvolvedores alheios ao shell do sistema possa estender ele, se ficou grego, veja essa extensão isso é um exemplo de tray (pode não parecer, mas é):

  • Indica estado
  • Executa uma ação quando é clicada

Outro excelente exemplo é essa extensão:

  • Indica um estado (ou nesse caso poderia, se suportasse sincronização por exemplo)
  • Executa uma ação quando é clicada
  • Mostra um pop up com opções

Perceba que essas e dezenas de extensões no GNOME Shell não tem qualquer motivo para existir como algo suscetível a mudança de API e mais importante, elas não tem nada demais para estarem presas ao GNOME Shell, elas poderiam ser serviços rodando em background que expõe um ícone, se existir uma API universal você poderia usar a Plasces Status indicator no XFCE ou mesmo no KDE, isso seria basicamente uma tray, basicamente uma implementação de tray:

  1. Deve suportar listar ícones e texto controlado pelo software que criou o ícone
  2. Deve suportar callbacks (basicamente um recurso que avisa pro programa que criou o ícone que uma ação foi feita pelo usuário) ao clicar no ícone
  3. Deve permitir ao desenvolvedor desenhar uma interface ainda que básica com suporte a callbacks

E é isso, não se trata de notificações, temas ou contrariar o usuário, se trata de ser um mini aplicativo universal cross-desktop, o “Aplicativos em segundo plano” atende apenas 1 dos 3 pontos então está incompleta e a forma como funciona é quebrada por definição (já que não permite iteração), essa “resistência a mudança” é por dois motivos: o primeiro e mais óbvio que é “Meus software já funciona” e segundo é nítido, se tem pelo menos:

  • KDE Plasma
  • GNOME Shell
  • MATE
  • XFCE
  • Pantheon
  • LXQT
  • Cinnamon
  • DDE
  • Budgie

Só pra citar os mais populares, as APIs D-BUS padronizadas que “substituem” o tray são incompletas, imagina o desenvolvedor que precisa de um widget (porque fora da tray essa é a única alternativa) mais rebuscado (exibir e controlar o estado de um serviço por exemplo) pra cada ambiente só nessa brincadeira são 9 ambientes, desses só KDE e XFCE tem APIs estáveis (isto é, não obrigam o desenvolvedor a reescrever código) de longa duração, percebe que é um problema enorme? Muitos desenvolvedores ou usam tray ou simplesmente nem fazem uma interface pra Linux por isso, se a primeira é ruim e a segunda faz o software deixar de existir pro usuário e não tem alternativa, pra que fazer software pra Linux? Se faz é xingado, se não faz é ignorado por isso devs de fora fazem coisas assim:

Uma interface só pra tudo que é sistema suportado e ignora o que a comunidade fala, talvez e só talvez, acabar com a mentalidade que todo software se resume a player de música e chat e começar a se discutir soluções realmente completas sem querer enquadrar o software, essa resistência fosse neutralizada

Olá Rodrigo.
Não sei como vc intepretou minha mensagem. Não vim aqui defender o tray, mas sim partilhar minha experiência que, após anos usando MATE, KDE e LXQt, estou agora gostando cada vez mais do Gnome, e por isso mesmo estou tentando encontrar outro meio de interagir com as coisas, que apareciam no tray desses outros DE’s.

Meu Joplin.appimage desaparece ao fechar, e onde vc me indicou, ele não tá não… (seguem os prints)

O Xtreme Donwload Manager é outro que só aparece quando uso a extensão “Tray Icons: Reloaded”.

Por outro lado, observando o que foi comentado por @eddiecsilva e @henriquead7, decidi instalar o Dropbox (flatpak) que também uso e… ok, o Dropbox apareceu no Menu de status - “aplicativos em segundo plano.”

Porém não me deu acesso ao menu de contexto para poder, por ex., interromper ou retomar uma sincronização.

O Joplin em appimage não apareceu nem mesmo nesse tray que instalei, e o que acabei de instalar em flatpak (print abaixo), também não tá aparecendo em lugar nenhum… lembrando que meu Gnome foi atualizado pro 45 (no openSUSE Tumbleweed). Talvez o desenvolvedor do Joplin terá que adaptá-lo ao novo modus operandi do Gnome 45, que mudou de tal forma, que até as extensões que funcionavam na v.44 terão também que ser compatibilizadas.

01 XDM 20023-10-07 16h06'

O gnome preza pelo minimalismo, então aplicativos em segundo plano não faz muito sentido pra filosofia dessa ambiente gráfico. O KDE Plasma também está caminhando pra essa filosofia ao longo dos anos, logo logo vão implementar algo parecido, com certeza vão adotar alguma forma de usar app em segundo plano sem bandeja.

A questão é que cada vez mais desktop e o mobile vão ficar mais semelhantes e única diferença vai ser o tamanho da tela. Mobile está ficando cada vez mais com processadores tão bons quanto desktops. Ainda prefiro Desktop para estudar, ouvir música e assistir vídeos, pois com a tela maior e um teclado físico disponível é mais confortável para estas atividades.

Então faz sentido sim aplicativos em segundo plano funcionar sem o tray icons, mas de alguma forma o usuário deve ter um atalho para voltar a usar o aplicativo que estava em segundo plano, deixando apenas minimizado como é no android quando muda de atividade para outro aplicativo.

Quê? O Plasma está caminhando para o minimalismo? Nunca. O GNOME e o Plasma são e provavelmente sempre serão completamente opostos em filosofia. O Plasma implementar uma forma de usar apps em segundo plano sem a bandeja do sistema também é uma coisa que provavelmente nunca acontecerá. O GNOME e o Pantheon são os únicos que apoiam a ideia de acabar com a bandeja do sistema, ninguém mais apoia.

Não que seja proposital a diferença de filosofias e escolhas, mas tem acontecido de trilharem caminhos diferentes. Por mais que o KDE não tenha problema algum em dá o braço a torcer e implementar coisas boas do ambiente Gnome, coisa que o pessoal do Gnome é teimoso em querer dá o braço a torcer e trazer algo que outro já tenha implementado.

Talvez por padrão isso nunca aconteça, mas conhecendo a versatilidade do ambiente Plasma, talvez tenhamos a opção “pra quem quiser, e não imposta” da opção de segundo plano similar ao Gnome.

Sei não, o Gnome consegue impor as coisas e torná-las um padrão ou aceito pela comunidade, claro após muita discussão e críticas kk.

1 curtida

O KDE implementa qualquer coisa boa que faça sentido no desktop, enquanto que o GNOME primeiramente verifica se uma coisa faz sentido no mobile para depois verificar se essa coisa faz sentido no desktop. O GNOME faz isso porque o GNOME Shell Mobile e o GNOME Shell desktop são um só, não existe uma separação entre eles. Depois de ver este vídeo eu entendi por que o GNOME perdeu diversas funcionalidades.

Eu usei o GNOME por quase todo o tempo em que eu uso Linux, mas nos últimos meses eu abracei o Plasma após eu perceber que muitas funcionalidades não retornarão ao GNOME, além de que o GNOME botou tudo em tamanho extra GG, e com o libadwaita nem dá para usar um tema compacto mais.

A falta de ícones na bandeja é muito impopular, muito mesmo. São raros os usuários que não instalam uma extensão para ter os ícones na bandeja de volta.

1 curtida

Poderia citar algumas?

Os ícones na bandeja do sistema, a ferramenta de print que não me pergunta mais se eu quero apenas copiar a imagem capturada para a área de transferência, os atalhos na área de trabalho, o indicador do menu de aplicativo (não ter mais como saber o título da janela que está ativa é um problema de acessibilidade, não?) etc.

Quase todos os apps GNOME perderam funcionalidades, sendo o Nautilus o mais emblemático dos casos. O Nautilus é o único gerenciador de arquivos que eu conheço que não é capaz de ter a exibição divida. Os apps mais capazes perdem funcionalidades ou são trocados por apps mais simplistas.

2 curtidas

Desculpa, mas esse comentário está equivocado em vários níveis. E muito usuários do Diolinux Plus poderiam levar isso como uma verdade, o que de fato não se caracteriza.

Converse com um desenvolvedor GNOME e verá que o GNOME Shell mobile não é o foco, é um projeto que está começando a ganhar atenção só agora, o desktop não leva ele em consideração - como foco - para implementar ou remover recursos no shell desktop como diz seu comentário. Isso é apenas baseado em sua percepção, uma opinião apenas e não a realidade.

Recomendo acompanhar os blogs dos devs GNOME, como também as lives do Georges (feaneron) - quase toda sexta ele tira várias dúvidas sobre o projeto GNOME, até mesmo sobre o tema ela já comentou brevemente - é uma forma mais direta e simplificada da coisa. Muita percepção que temos não se traduz na realidade, tem outros motivos e causas, esse contato mais direto é muito bom para saber realmente como as coisas são.

(Obs.: ao capturar a tela com a ferramenta que foi incorporada ao GNOME Shell, e deixou de ser um app, a imagem tanto vai para o diretório de captura, como para área de transferência. Faz mais sentido esse comportamento do que apenas ir para área de transferência e “nada acontecer” para o usuário. Você pode tanto colar diretamente em outro app, como deixar salvo a imagem).

2 curtidas

Acho que ele tá falando sobre a janela no GNOME 2.x que perguntava se o usuário quer salvar como arquivo ou copiar para a área de transferência, nem toda screenshot tem a premissa de ser salva como arquivo ou ser copiada os dois geram duplicidade

2 curtidas

Obrigado pela resposta.
Sabia dessas perdas mas, como uso o Zorin, muitas delas não são sentidas.

Gosto do Gnome, mas certos aspectos incomodam:

  • não dar a opção de escolha em coisas bem óbvias e “ridículas” como, por exemplo, atalhos de Desktop e bandeja de sistema. O ambiente padrão pode seguir a ideia do projeto, mas, ter a opção de escolha (prezo muito por isso) para coisas tão usadas é, no mínimo, muito razoável.

  • programas com nenhuma ou pouquíssima configuração disponível. É ridículo isso. Você abre o programa e aquela configuração super “necessária” salta aos olhos, mas não está disponível. Muitas das vezes, quando encontro um programa assim, já desinstalo em seguida.

Minimalismo tem limite, principalmente em pontos muito úteis.

2 curtidas

Ah! Então é apenas uma coincidência tudo que não funciona no mobile acabar virando uma extensão no GNOME. Eu lhe digo que se um dia derem um fim às extensões, também será o fim do GNOME.

Se você mantém o GNOME Shell Mobile e o GNOME Shell Desktop como um só, você INEVITAVELMENTE terá de remover coisas que não funcionam no mobile. Por exemplo, ícones na bandeja do sistema ficariam horríveis em um smartphone. A atual ferramenta de print do GNOME não apenas se parece visualmente como também funciona como uma ferramenta de print mobile. Como podemos pensar em devolver a opção de exibição dividida ao Nautilus se telas de smartphone são muito pequenas para isso? O Dolphin, o Nemo, o Caja, o Thunar e o Pcmanfm-Qt têm a opção de exibição dividida, e o Nautilus é o diferentão que não tem.

O GNOME Shell Mobile tem importância para o GNOME. A Purism, que vende smartphones e tablets, é uma das empresas que mais investem no GNOME.

Pois é! Aprendi que ter opções de mais é melhor do que ter opções de menos.