Translate

Mostrando postagens com marcador Spectacle. Mostrar todas as postagens
Mostrando postagens com marcador Spectacle. Mostrar todas as postagens

quinta-feira, 13 de outubro de 2016

De volta ao Gnome-screenshot

Um “simples” comando diz ao gnome-screenshot em qual pasta e com qual nome salvar a Captura de tela.

A necessidade de substituir o antiquado KSnapshot no Debian 8.6 KDE foi o que trouxe de volta o “gnome-screenshot”, — mas os resultados foram tão satisfatórios, que ele acabou substituindo também o sofisticado KDE Spectacle no Kubuntu 16.04 LTS, no Linux Mint 18 KDE, no KDE Neon User Edition, — e agora, no teste Live USB do Kubuntu 16.10 Yakkety Yak.

Copiando o comando do Debian para adaptar ao Live Kubuntu 16.10 Yakkety Yak

Leve, ágil e discreto, o “gnome-screenshot” mostrou uma série de vantagens, mesmo em relação ao KDE Spectacle:

  • Basta inserir a extensão “.JPG” para que as Capturas de tela sejam salvas nesse formato, — com economia de 50% (ou mais) no espaço ocupado em disco, sem perda de qualidade;

  • Não polui a tela com “notificações”, — que no caso do Spectacle, às vezes demoram a desaparecer, exigindo intervenção do mouse para fechá-las, ou continuar esperando, para fazer o próximo PrintScreen;

  • A Captura de tela com retardo (delay) pode ser feita sem interação ou uso do mouse, — ao contrário do Spectacle, que abre um diálogo e fica aguardando instruções.

Claro que tudo isso é muito relativo, — depende do uso e dos hábitos de trabalho de cada um.

O KDE Spectacle oferece vários recursos, — importantes para muitos usuários. — Além disso, é possível que permita soluções até melhores, nesses tópicos, e apenas falte neurônio por aqui, para descobrir como.

Os antigos atalhos do KDE Spectacle foram apenas desativados, — e podem ser restabelecidos no futuro

Alterar a duração das “notificações” do KDE Spectacle, por exemplo, não é difícil. — Mais complicado, talvez seja descobrir por que motivo, às vezes, elas acabam deixando de fechar sozinhas.

Kubuntu 16.10 Yakkety Yak


Último Print no Live Kubuntu 16.10, — de volta, após colapso temporário, — e Spectacle sem ser chamado

Não que o “gnome-screenshot” seja imune a falhas.

Ao encerrar a terceira sessão de teste do Kubuntu 16.10 Yakkety Yak, a tecla PrintScreen tinha estado inoperante desde 1 hora antes, — e o Spectacle aparecia na tabela de processos do Monitor do sistema (KSysguard), embora não tenha sido usado em momento algum. — Horas antes, tinha sido verificado no KSysguard que o Spectacle não estava carregado na Memória.

Terceira ou quarta tentativa de finalizar o “processo” Spectacle pelo KSysguard

  • Foram feitos 163 Prints entre 8:14 e 15:06. Às 16:11 ficou evidente que os Prints não estavam mais acontecendo. — Existe, porém, um último Print às 18:06, durante a tentativa de documentar a situação. Mas, passou desapercebido que tivesse voltado a funcionar, e há fotos de celular dessa mesma tela, às 18:11, ainda tentando “finalizar” o processo Spectacle. (Foram feitas 3 ou 4 tentativas, sem êxito). A sessão Live foi encerrada às 18:14. — Obs.: Todos os Prints têm nomes correspondentes à hora exibida na tela (confirmada pelas anotações no caderno), porém no Kubuntu consta que os arquivos foram gravados sempre 3 horas antes (5:14 às 12:06, e o último às 15:06).

Faltam conhecimentos (e tempo) para investigar se cada ocorrência desse tipo de problemas se deve aos aplicativos de Captura de tela, ou a qualquer outro componente dos “sistemas” Linux.

Quando o KSnapshot era mais usado (KDE 4), as observações eram irregulares, anotadas de passagem, e não deixaram registro de falhas. O Shutter começou a ser mais utilizado nos últimos 12 meses, mas só em tempos recentes as falhas foram minuciosamente registradas (Cinnamon e Plasma KDE 5). O uso do Spectacle começou nos primeiros testes Live USB do Kubuntu 16.04 Alpha e Beta (Plasma KDE 5), há cerca de uns 6 meses, mas só recentemente as observações produziram registros mais minuciosos.

Portanto, foram mudando os aplicativos de Captura de tela, mas também foram mudando os “sistemas” Linux onde são usados, — assim como vieram mudando o “observador” e, principalmente, a minúcia dos registros.


Debian 8.6 KDE


Captura de tela com o KSnapshot: — acerte com o Mouse em “Salvar como”.

Depois de 326 Capturas de tela com o KSnapshot, obter uma alternativa simples e prática foi a melhor notícia, desde a instalação do Debian 8.6 KDE, há 2 semanas.

Talvez ainda seja cedo para comemorar, — lembro meu antigo entusiasmo com o KSnapshot, e depois com o Shutter, dos quais agora quero distância. — Afinal, a nova “maravilha” é o Gnome-screenshot, que tanto já xinguei no passado.

Ainda não saber tudo é muito chato.

Captura de tela com o KSnapshot: — “Salvar como”, e confirmar para “Salvar”

Fato é que cada um desses 326 prints do KSnapshot exigiu nada menos que 4 ações, entre Mouse e Teclado:

(1) Teclar “Print”;

(2) Clicar em “Salvar como”, — é preciso ir lá, com o Mouse, pois o foco do “Enter” está em “Fazer nova captura”, — ou teclar “Tab” sucessivas vezes, até passar o foco do “Enter” para o “Salvar como”;

(3) Teclar “Enter” na segunda janela de diálogo, para confirmar e “Salvar”, — ou confirmar com o Mouse;

(4) Teclar “Esc” para fechar o Diálogo do KSnapshot, — ou fechá-la com o Mouse.

E o resultado são 326 arquivos numerados, — pense em centenas de “Snapshot-001”, “Snapshot-002”… até “Snapshot-326”.

Qualquer descuido, — backup, converter, copiar, mover, — pode alterar as datas, deixando tudo com o mesmo dia, hora e minuto. Aí, só abrindo cada um, para ver a hora (caso apareça na imagem).

Então, por que tantos elogios ao KSnapshot, no passado?

A verdade é que isso já foi um tremendo avanço. No antigo Windows XP, por exemplo, a tecla Print apenas copiava a imagem da tela para a memória, — sem direito a Klipper, para guardar várias “memórias”, — e era preciso correr para o Photoshop, criar novo arquivo de imagem, “colar” o ”print”. — Em seguida, “achatar” as camadas, ou não poderia salvar como JPEG (não havia visualizador rápido para arquivos “.PSD”). — Depois, digitar um nome-de-arquivo. — Por fim, “aceitar” salvar JPEG com Qualidade 80%, ou coisa parecida. Uma burocracia sem fim.

Encontrar um Ksnapshot, — que “resolvia tudo” em 3 passos, — parecia o paraíso.

Só mais tarde, — ao pesquisar e explorar o Shutter, — isso também se tornou coisa do passado.

Quando o KDE / Kubuntu substituiu o Shutter pelo Spectacle, logo ficou claro que as coisas podiam ser ainda melhores, — e até ontem, pareceria absurda, a simples ideia de trocar o Spectacle pelo Gnome-screenshot, caso alguém sugerisse.

Linux Mint 17.3 Cinnamon


Tomei conhecimento do Gnome-screenshot, — ou seria melhor dizer, “nem percebi”, — em alguma versão anterior do Linux Mint Cinnamon.

Existem no caderno duas ou três antigas anotações, tipo, — “a tecla Print não funciona. Não abre diálogo para salvar, e não há nada na memória para colar no Gimp”, — até que um dia descobri um punhado de arquivos salvados (silenciosamente) na pasta “/home/Pictures”, que não costumava olhar.

Porém, os arquivos de trabalho ficam na partição “F:\” (Fat32), do antigo Windows XP, que não aceita nomes com “:”. Enquanto foi usado o Nemo para fazer a transferência dos arquivos, tudo bem, — ele automaticamente substitui “:” por “_”, — o que não facilita a leitura (onde começa a hora?), mas ocultava o problema operacional.

A coisa se complicou ao fazer backup (aliás, sincronização), com arquivos duplicados numa direção, e uma mensagem de erro na outra.

E ficou mais evidente quando tentei “centralizar” as Capturas de tela em uma única pasta, — tipo, “F:\000_print-screen”, — para facilitar a sequência cronológica de vários sistemas Linux + Windows.

À primeira vista, a pesquisa na web só apresentava “impossibilidade” de configurar o Gnome-screenshot, — nome que o Linux Mint esconde, como o de muitos aplicativos, depois de lhes dar uma “personalização”. — As afirmações, nos Fóruns, eram de que não havia como “mudar” o padrão de nome-de-arquivo do Gnome-screenshot, e que essa demanda (ou “bug”) estava registrada havia anos, sem solução etc.

Shutter


Surto do Shutter no Linux Mint 17.3 Cinnamon

Como a vida não pode parar, — e o Dolphin foi adotado em diferentes sistemas Linux instalados em paralelo, — a solução imediata foi instalar o Shutter no Linux Mint 17.3 Cinnamon, já que o Spectacle não estava disponível em seus repositórios.

Saraivada de mensagens de erro do Shutter, ao ver seus arquivos renomeados fora dele

A partir daí, começaram a ser percebidos vários problemas relacionados ao Shutter:

  • Alto consumo de Memória RAM, à medida em que a “sessão” do Shutter acumula centenas de arquivos;

  • Reclamações mal-explicadas, a cada vez que um de seus preciosos arquivos é renomeado fora dele;

  • Acessos de atividade desvairada, “consumindo” CPU — e muitas vezes, parando de responder, até reiniciar o Linux Mint;

Montagem da solução


Primeiro “Print” do Gnome-screenshot no Debian, só com parâmetro “-p”, — incluir ponteiro do Mouse

Foi nesse quadro que o Debian 8.6 KDE instalado há 2 semanas veio apenas com o KSnapshot, — e sem Spectacle nos repositórios.

Para quem já se acostumou com “prints” de vários sistemas, salvos automaticamente, numa única pasta, — todos com nomes padronizados “YYYY-mm-DD_HH-MM-SS”, — voltar ao KSnapshot é como voltar à Idade da Pedra Lascada.

Entre as alternativas encontradas pelo Synaptic do Debian 8.6 KDE, havia pouco motivo para entusiasmo:

  • Shutter → 49 pacotes
  • Xfce4-screenshooter → 18 pacotes
  • Kazam → 18 pacotes
  • Mate-utils → 5 pacotes
  • X11-apps → Já instalado. — Mas, cadê? Como se usa isso?
  • Gnome-screenshot → 1 pacote.

Os “capturadores” do Xfce e do MATE foram usados recentemente, — na primeira instalação do Debian testing “Stretch”, com todos os ambientes gráficos, — e não agradaram muito, em um exame superficial (embora não duvide que possam ser fantásticos).

Mas, para pesquisar e aprender, por que não começar pelo Gnome-screenshot, do qual já sabia alguma coisa?

Gnome-screenshot com “-f” → nome-de-arquivo passou a gravar na pasta “/home

Um velho bookmark do AskUbuntu, — intitulado “How can i change the default name for the screenshots made by gnome-screenshot?”, — tinha algumas dicas ainda não exploradas, tipo editar arquivos de configuração, criar um arquivo executável com “chmod a+x” e outras fórmulas cabalísticas de arrepiar os cabelos. Mas, no desespero, até injeção na testa é uma possibilidade a considerar.

Um exame mais atento mostrou que algumas partes daquela fórmula:

gnome-screenshot.real -f "$HOME/Pictures/Screenshots/$(date +%F_%H-%M-%S).png" $@

talvez pudessem ser utilizadas, — não como “arquivo executável”, mas — como parâmetros para o “comando” a ser disparado pela tecla “Print”.

Bastou mudar a extensão para o gnome-screenshot gravar em formato JPEG, — com economia de espaço

Depois de várias experiências, o “comando” acabou transformado nisso, — que funcionou com perfeição, para Captura “imediata” de tela:

gnome-screenshot -p -f "/media/$USER/F/000_print-screen/$(date +%F_%H-%M-%S)_D.jpg"

onde “-p” é o parâmetro para incluir o ponteiro do Mouse; e “-f” é o parâmetro para indicar o nome do arquivo, a ser salvo sem mais delongas.

Incluindo apenas o nome-de-arquivo, o Gnome-screenshot já começou a funcionar na mesma hora, — porém, não havia jeito dele aceitar o caminho “/media/flavio/F/000_print-screen/”, — copiado do Dolphin por CTRL-L / CTRL-C.

Testando parâmetros do gnome-screenshot para a pasta onde os arquivos devem ser salvos

A variável “$USER” foi inspirada em outro tópico do AskUbuntu, — intitulado “Default save directory for gnome-screenshot?”, — onde se encontra outra fórmula cabalística de dar nó em pingo d’água:

gsettings set "org.gnome.gnome-screenshot" "auto-save-directory" "file:///home/$USER/screenshot"

Fez-se, então, a luz. — Aquele cifrão “$” da primeira fórmula não é para “estar no começo” do nome, — nem a “HOME” estava em maiúsculas por mania de grandeza. — O nome desse negócio é “variável”, ou algo assim, e o cifrão “$” está ali para indicar isso.

Na primeira fórmula, não é citado o usuário ($USER), talvez porque a variável “$HOME” já cuida disso, — imagino eu (que não entendo lhufas dessa algaravia).

Para capturar Menus, — também em tela inteira, — pelo “Shift-Print”, foi usado o mesmo comando, com uma pequena variação:

gnome-screenshot -p -d 7 -f "/media/$USER/F/000_print-screen/$(date +%F_%H-%M-%S)_D.jpg"

onde o parâmetro “-d” indica o retardo (delay) em segundos, para dar tempo de abrir os Menus etc.

Na prática, foi constatado que muitas “camadas” e “menus” são flagrados em tempo real, — não impedem o “Print” de chamar, — nem impedem o “gnome-screenshot” de agir.

Apenas em alguns casos isso não funciona, — e o “Shift-Print” fica para essas ocasiões.

Os parâmetros utilizados foram obtidos pelo comando “gnome-screenshot --help” no Terminal:

flavio@Linux3:~$ gnome-screenshot --help
Uso:
  gnome-screenshot [OPÇÃO...]

Opções de ajuda:

  -h, --help                       Exibe opções de ajuda
  --help-all                       Exibe todas as opções de ajuda
  --help-gtk                       Mostra as opções do GTK+
  --help-gapplication              Mostrar opções do aplicativo-G

Opções de aplicativo:

  -c, --clipboard                  Send the grab directly to the clipboard
  -w, --window                     Grab a window instead of the entire screen
  -a, --area                       Grab an area of the screen instead of the entire screen
  -b, --include-border             Include the window border with the screenshot
  -B, --remove-border              Remove the window border from the screenshot
  -p, --include-pointer            Include the pointer with the screenshot
  -d, --delay=seconds              Take screenshot after specified delay [in seconds]
  -e, --border-effect=effect       Effect to add to the border (shadow, border, vintage or none)
  -i, --interactive                Interactively set options
  -f, --file=filename              Save screenshot directly to this file
  --version                        Print version information and exit
  --display=MONITOR                Monitor do X a ser utilizado

Parece pouco, — mas é mais do que se encontra em algumas páginas “oficiais” ou “oficiosas”, — e já permite mais algumas operações básicas, como captura de janela, de área, efeitos etc.

Uso mínimo de Memória RAM pelo gnome-screenshot

Talvez fiquem faltando plumas e paetês, — coisas como setas coloridas, legendas, upload etc., que não uso.

Em compensação, bastou instalar 1 único pacote (733 kB), que ocupa um mínimo de Memória RAM, por poucos segundos, — e torna a desaparecer da “Tabela de processos” do Monitor do sistema (KSysguard).

O KDE Spectacle costuma permanecer na Memória, — e quando resolve usar CPU em excesso, é preciso descobrir alguma solução para o mistério.

Notificações do Spectacle acumulando-se na tela, sem desaparecer

O “gnome-screenshot” ambém consegue ser mais discreto do que o Spectacle, — que coloca na tela um baita retângulo de “notificação”, durante intermináveis segundos, — e às vezes se “esquece” de fechar, obrigando a esperar, ou acertar no “x”.

••• Mensagens ocultas


Mensagens de erro do comando “gnome-screenshot” no Terminal do Debian testing KDE

Ao transformar o Debian 8.6 “Jessie” KDE em Debian “testing” KDE, os scripts de instalação tornaram a configurar as teclas de atalho “PrintScreen” para chamar o Spectacle, — e ao tentar reconfigurá-las para chamar o Gnome-screenshot, ficou a impressão de que ele não funcionava, ou talvez o comando não estivesse 100% católico.

Para tirar a dúvida, o comando foi colado no Terminal (Konsole), — e revelou-se a ocorrência de mensagens de erro:

flavio@Linux3:~$ gnome-screenshot -p -f "/media/$USER/F/000_print-screen/$(date +%F_%H-%M-%S)_Dgshot.jpg"

(gnome-screenshot:10400): Gtk-WARNING **: Failed to get the GNOME session proxy: The name org.gnome.SessionManager is not owned

(gnome-screenshot:10400): Gtk-WARNING **: Failed to get the Xfce session proxy: The name org.xfce.SessionManager is not owned

(gnome-screenshot:10400): Gtk-WARNING **: Failed to get an inhibit portal proxy: The name org.freedesktop.portal.Desktop is not owned
** Message: Unable to use GNOME Shell's builtin screenshot interface, resorting to fallback X11.

Mensagens de erro do comando “gnome-screenshot” no Terminal do Kubuntu

O teste foi repetido depois no Kubuntu 16.04, no KDE Neon User Edition e no Linux Mint 18 KDE, — onde nada jamais fez suspeitar de qualquer “erro”.

No Kubuntu:

flavio@linux1:~$ gnome-screenshot -p -f "/media/$USER/F/000_print-screen/$(date +%F_%H-%M-%S)_Kgshot.jpg"
** Message: Unable to use GNOME Shell's builtin screenshot interface, resorting to fallback X11.

Mensagens de erro do comando “gnome-screenshot” no Terminal do KDE Neon

Verifica-se que no Kubuntu e no KDE Neon o comando retorna apenas uma mensagem de erro.

No KDE Neon:

flavio@linux4:~$ gnome-screenshot -p -f "/media/$USER/F/000_print-screen/$(date +%F_%H-%M-%S)_Ngshot.jpg"
** Message: Unable to use GNOME Shell's builtin screenshot interface, resorting to fallback X11.

Comando “gnome-screenshot” no Terminal do Linux Mint KDE, único que não retorna mensagem de erro

O Linux Mint 18, — embora também com ambiente KDE, — foi o único onde o comando não retornou qualquer mensagem de erro.

É uma questão a investigar, — mas, enquanto isso, o gnome-screenshot continua em uso normal no Kubuntu, no KDE Neon e no Linux Mint KDE, pela tecla de atalho “PrintScreen”.

No caso do Debian 8.6 KDE transformado em “testing” KDE, a tecla de atalho “PrintScreen” permanece configurada para chamar o Spectacle, até pesquisar mais sobre o assunto.

___________
Publicado inicialmente em 13 Out. 2016.
••• “Mensagens ocultas” → Adicionado em 21 Out. 2016.

— … ≠ • ≠ … —

Ferramentas &tc.


sábado, 9 de abril de 2016

Kubuntu Xenial beta2: Discover e Spectacle

Uso da CPU pela animação inicial do Discover (“Muon”), com pequenos pulsos de uso da rede

O objetivo principal deste terceiro “teste de trabalho em Live USB” com o Kubuntu 16.04 Xenial beta2 LTS era investigar o funcionamento do Discover, — além de continuar explorando e aprendendo sobre o Xenial Xerus, que cedo ou tarde substituirá o sistema “principal” do computador (ainda Kubuntu 14.04 LTS). — Tudo isso, sem prejudicar as atividades cotidianas, pessoais e de trabalho.

A sessão Live USB foi iniciada às 13:09 de 9 Abr. 2016, — usando a daily build xenial-desktop-amd64.iso de 08-Apr-2016 05:38, baixada e gravada na véspera em Pendrive, por comando “dd”, — e prosseguiu até 2:30 de 12 Abr. 2016, totalizando 61h20min.

Gráfico da instalação do Synaptic pelo Discover

Descobrir o Discover


O Discover foi aberto às 13:34, — logo após as configurações mínimas de Fuso horário, Relógio, Spectacle (PrtScn), Teclado, Dolphin, Wallpaper, — e já com o Monitor do sistema (KSysguard) pronto para registrar o uso da CPU e da conexão (Network history).

Gráfico da instalação do Shutter pelo Discover

Apesar do Synaptic ficar disponível desde esse momento, vários softwares foram instalados pelo Discover, — sempre com esse monitoramento do uso da CPU e da Rede, — tanto nesse momento inicial, como depois, ao longo da sessão.

Gráfico da instalação do Gimp pelo Discover

Entre 13:34 ~ 13:46, foram instalados pelo DiscoverSynaptic, Shutter, Gimp, KRuler, Psensor, Chromium (Relógio ainda marcando horário de Loncres). — No dia 9, às 22:39: Xsane. — E no dia 11, às 14:38: Qlix.

Gráfico (1) da instalação do Chromium pelo Discover

Gráfico (2) da instalação do Chromium pelo Discover

Afora isso, o Discover foi aberto várias outras vezes, — inclusive após ser removido e reinstalado, — sem nenhuma falha até o final da sessão.

Discover → Advanced → Configure software sources → Software restricted

Também foi o Discover que possibilitou marcar os repositórios “restricted” (“non-free”), — opção não encontrada no Synaptic, — para instalar ttf-mscorefonts.

Esse foco sobre o Discover foi motivado pelos problemas, — e dúvidas sem resposta, — na “Falha prévia” do segundo teste de trabalho em Live Kubuntu 16.04 Xenial beta LTS.

Outras épocas


Já faz alguns anos que procuro escapar do “Descobridor do Muon”, — tão logo ele apareça pela frente, — pelos motivos explicados ao escrever sobre o Synaptic.

Em resumo, o “Descobridor do Muon” não conseguia “descobrir” o Synaptic (por exemplo), e o jeito era instalar o “Gerenciador de pacotes do Muon” para, — só então, — conseguir instalar o Synaptic, e escapar de ambos.

Uso de CPU pela animação inicial do Discover, — leva até 1 minuto para conseguir digitar na busca, e parar

Acontece que isso foi em outra época, — o “Descobridor” era simples, leve, — e não causava nenhum mal.

Porém, nos últimos meses, 2 coisas, — pelo menos, — mudaram esse quadro:

1) Agora, o Discover encontra o Synaptic
2) Agora, o Discover exibe uma “animação” digna dos piores momentos da “febre dos sites em Flash”, — ocupa 50% da CPU, retardando em 1 minuto (ou mais), a resposta a qualquer clique, — e essa triste “animação” recomeça a todo momento, pois voltar ao início é quase a opção-padrão, dentro dele.

Muon ou Plasma


Em busca de mais informações, — para entender melhor, quem sabe, — desenhou-se o seguinte panorama:

O “Discover” do KDE Plasma não é mais “Muon”, — sem mantenedor há algum tempo, ou sem mantenedor com disponibilidade para acompanhar a evolução do KDE Plasma (ao que se diz aqui e ali), — obrigando a equipe do KDE a desenvolver uma alternativa.

Discover atende por “Muon”, no Menu, mas é o “plasma-discover”, — e não o “muon-discover”

Você abre o Menu, digita “Muon”, aparece o “Discover”, — mas não é o “muon-discover” que está instalado, — o que existe no Kubuntu 16.04 Xenial é o “plasma-discover”.

Ao procurar pela série Muon, no Synaptic, encontram-se pacotes transicionais para os equivalentes Plasma

E se você quiser voltar ao antigo “muon-discover”, não adianta procurar nos repositórios, — pois o que se encontra lá, com este nome, é um pacote de transição (“transitional package”), que leva… ao “plasma-discover”.

Instalar “muon” + “libmuon” permite voltar ao Muon Package Manager, eliminando os substitutos “plasma”

No entanto, pode-se voltar ao Muon Package Manager, — basta instalar simultaneamente “muon” + “libmuon”, — evidentemente usando outra ferramenta, pois o “plasma-discover” será necessariamente removido no processo.

Muon Package Manager instalado em Live USB Kubuntu 16.04 Xenial (não foi testado)

O Muon Package Manager foi instalado, mas não chegou a ser testado. Ao tentar fechá-lo (para fazer outras coisas), não houve jeito, nem mesmo pela Tabela de processos do Monitor do sistema (KSysguard). No entanto, o restante do sistema e demais aplicativos continuaram normais.

Para evitar um longo aprendizado fora dos objetivos imediatos, foi feito Log out / Log in, após fechar tudo mais, e em seguida desinstalado o Muon Package Manager, pela reinstalação do “plasma-discover” e “plasma-discover-updater”, — que automaticamente incluem os pacotes transicionais “muon-discover”, “muon-notifier” e “muon-updater”.

Qlix, instalado pelo Discover no dia 11: única solução encontrada para acessar o Nokia Lumia por cabo USB

No dia seguinte (11), o Discover (plasma-discover), reinstalado desse modo, foi utilizado para instalar o Qlix, com sucesso.

WindowsPhone, Digital Sony e Scanner via cabo USB


Qlix foi a única solução encontrada para acessar fotos (e demais arquivos) do WindowsPhone Nokia Lumia durante a sessão Live USB do Kubuntu 16.04 Xenial beta2.

No Kubuntu 14.04 LTS (HD), a conexão USB com o Nokia Lumia tem funcionado há bastante tempo, mas não há registro de “dificuldades” (nem de uma eventual “solução”).

Os registros encontrados são bem mais recentes, — datam da instalação do Linux Mint 17.3 Cinnamon, em Jan. 2016, — porém todas as soluções tentadas no Linux Mint, também não resultaram agora, no Kubuntu 16.04 Xenial em Live USB.

Essas tentativas incluíram: — mtp-tools, obexfs, obextool, gphoto2, gphotofs, gmtp, jmtpfs, mtpfs, gthumb, gnokii, — instalados (e ao final desinstalados) pelo Synaptic, uma vez que o Discover só encontrou obextool, gmtp, gthumb. É possível que tenha faltado alguma ferramenta, instalada para complementar outros programas (Dolphin, Konqueror, Krusader, Gwenview…) no Kubuntu 14.04, talvez até antes de ter Nokia Lumia.

Reconhecimento imediato da câmera digital Sony DSC-H2 conectada por cabo USB

Já a conexão com a câmera digital Sony DSC-H2 por cabo USB não apresentou dificuldade alguma, — bastou plugar e ligar, para ser reconhecida e exibida nos “locais” e nas “pastas” do Dolphin.

Teste do scanner com Xsane instalado pelo Discover desde o início da sessão Live USB Kubuntu 16.04 Xenia beta2

Foi feito também o teste do scanner USB, — com o Xsane instalado pelo Discover.

De quebra


Foi constatado que lm-sensors, hddtemp e fancontrol não são indispensáveis para o Psensor, — que trabalhou perfeitamente, desde a instalação pelo Discover, sem nenhum crash.

Aliás, não houve crash neste terceiro teste de trabalho em Live USB Kubuntu 16.04 Xenial beta2, — exceto um fechamento súbito do Dolphin (às 13:19 do dia 10), ao clicar com o botão direito do mouse em uma imagem TIFF, — sem perda de configuração, ao reabrir em seguida.

Isso, apesar de inúmeras mensagens de “Low disk space”, ao longo de todo o terceiro dia (11), a partir das 13:17. — Ou, melhor, uma notificação permanente no Painel, com alertas frequentes na área de trabalho.

Avisos de pouco espaço em “disco” (/home) ao longo do terceiro dia da sessão Live USB Kubuntu Xenial beta2

Esse aviso não se refere à “Memória”, em si, — houve só um momento em que chegou a ser usado 1,6 GiB dos 8,3 GiB Swap, caindo depois para 1,1 GiB, — mas ao “espaço” atribuído à “/home”. A certa altura, restavam menos de 160 MiB de “espaço” na “/home”. Esvaziar a Lixeira elevou o “espaço” restante para 190 MiB, o que ainda foi considerado muito pouco: — apenas 9% do “espaço” total atribuído a essa partição virtual.

Salvo melhor hipótese, isso talvez possa ser atribuído ao grande número de pacotes instalados ao longo da sessão Live USB Kubuntu Xenial beta2, — Gimp, Synaptic, Shutter, Kruler, Psensor, Chromium, fonts-arkpandora, ttf-mscorefonts-installer, muon + libmuon, pyRenamer, Xsane, mtp-tools, obexfs, obextool, gphoto2, gphotofs, gmtp, jmtpfs, mtpfs, gthumb, gnokii, Qlix, — mas a simples desinstalação de muitos desses pacotes (no dia 11) não voltou a aliviar a “/home”.

Apesar da notificação permanente e dos avisos frequentes, nenhum programa foi fechado ou poupado, para aliviar, — foram mantidos abertos (e usados o tempo todo): Chromium, Dolphin, Gimp, LibreOffice, System Monitor (KSysguard), Psensor, Gwenview, — e o trabalho prosseguiu sem nenhuma lentidão ou falha, por mais 15 horas.

Configuração de Pasta e Nome automático para salvar capturas de tela do Spectacle

Spectacle


A intenção inicial era utilizar o Shutter, — instalado logo no começo da sessão Live USB, — para a Captura de tela pela tecla PrtScn, salvando as imagens numa pasta específica, com nome automático no padrão YYYY-MM-DD_HH-MM-SS_Kxb2.png.

Porém, logo ficou claro que, no Kubuntu 16.04 Xenial Xerus, a atribuição da tecla PrtScn exige mais do que um simples “shutter -f”, — como acontece no Kubuntu 14.04 e no Linux Mint 17.3 Cinnamon.

Entre fazer um curso de KDE 5, — ou procurar outra solução mais imediata, — foi mais prático examinar melhor o Spectacle, e observar bem os atalhos existentes.

O Spectacle tem, sim, o recurso de salvar as imagens automaticamente, — apenas, fica escondida no atalho “Shift-Print”.

Bastou trocar esse atalho com o “Print”, — que, por padrão, apenas “chama” o Spectacle, exigindo uma opção e um “Salvar & sair”, — o que se torna muito chato, bem antes de chegar à 285ª captura de tela.

E o “Shift-Print” ficou para “apenas chamar” o Spectacle, — opção interessante para capturar Menus, por exemplo: — Você estabelece um “Delay” de 5 ou 15 segundos, clica em “Take new screenshot”, e tem tempo de sobra para abrir o menu e chegar ao sub-sub-menu que deseja documentar.

Meta-Print” permaneceu atribuído a capturar e salvar automaticamente a janela ativa, — coisa pouco habitual, até o momento.


pyRenamer


Mais uma vez, pyRenamer foi fundamental para enfileirar, — na ordem correta, — as primeiras capturas de tela, feitas até o momento em que o Fuso horário “pegou”.

Corrigindo os nomes dos primeiros screenshots pelo pyRenamer

Pelo formato de nome automático, bastou substituir o horário de Londres, — “_16-” pelo horário oficial do Brasil, — “_13-” nos primeiros screenshots.

O pyRenamer foi instalado através do Synaptic (embora encontrado também pelo Discover), assim como ttf-mscorefonts-installer, e também a substituição do “plasma-discover” pelo Muon Package Manager, e posterior des-substituição.

•• Falha prévia (II)


Também desta vez houve uma sessão prévia, — iniciada às 18:57 do dia 8 Abr. 2016, e abortada às 12:54 do dia 9, — falhada por 2 erros claramente humanos:

  • Tentativa de atribuir a tecla PrtScn ao Shutter. — Não funcionou, e não foi possível restabelecer a atribuição da tecla ao Spectacle, por não haver documentado a configuração original.

  • Erro na escolha do layout de Teclado (PT-PT!). — A causa do problema só foi “descoberta” depois de encerrada a sessão, examinando retroativamente as Capturas de tela.

•• Falha intermediária


Talvez fosse correto numerar esta “Falha prévia” como (III), uma vez que no primeiro teste de trabalho em Live Kubuntu Xenial (beta), também houve uma “sessão falhada”.

Porém, aquele primeiro teste de trabalho em Live Kubuntu Xenial (beta), não foi feito em sessão única, — mas, sim, em 3 sessões Live USB (3 dias consecutivos), — e a “falha” ocorreu na sessão intermediária.

Foi um primeiro “bate-cabeça” com o “Discover” (plasma), — e com o Ubuntu Software Center, — possivelmente também causado por falha humana.

Ponto provável de falha: — Talvez tenha clicado em algo que não o (esperado) “atualizar informações dos repositórios”? Em vez disso, teria clicado numa “atualização geral”? Vai saber! Não ficaram registros tão detalhados, que permitam certeza imediata, nem compensa obcecar-se numa investigação detalhista, e talvez inconclusiva.

As primeiras hipóteses eram muito vagas, em campos demasiadamente amplos, — inclusive “memória”, — e a providência imediata foi aprender mais sobre isso.

Só então (e por esse motivo), começou a boa prática de monitorar a “memória” (e o resto), —inicialmente pelo KInfocenter, pelo KSysguard, — depois também pelo Psensor.

Aliás, sem o Psensor, não arriscaria sessões de 30 ou 60 horas, sem primeiro substituir o cooler original pelo adquirido em Nov. 2015. E, mesmo assim, ainda teria dúvida em arriscar, “no escuro”. — “Ver” a real situação é o que transmite segurança.

No segundo teste de trabalho Live Kubuntu Xenial (beta2), voltou a ocorrer “bate-cabeça” com o “Discover” (plasma), mas, — sem documentar as Capturas de tela com o monitoramento pelo KSysguard, — persistiram dúvidas sobre o processo e o momento exato da instalação dos pacotes.

Fato é que o “plasma-discover” nãocomplica” a vida do “usuário comum” com indicações claras de que a instalação de pacotes tenha, de fato, terminado. Durante algum tempo, há indicações mais ou menos visíveis do andamento do processo. Depois, cessam, — é preciso passar o “mouse over” para ter alguma noção das fases de “download”, em seguida “instalando”, e por fim “Remover” (suposta indicação de “instalação concluída”). — E para casa uma dessas fases, é necessário retirar o “mouse over” e voltar, várias vezes, para ver se a situação já mudou.

Só neste terceiro teste de trabalho Live Kubuntu Xenial (beta2), finalmente, foi feito um acompanhamento mais exato, — pelo KSysguard, — dos processos de download e instalação de cada pacote.

Nada 100% “conclusivo”, — ao ponto de compreender a causa exata de cada falha anterior, — mas apenas o suficiente para afastar a maioria das dúvidas mais paranóicas, e para concluir que o “plasma-discover” pode ser usado. — Embora sem a menor intenção de usá-lo, exceto como ferramenta para instalar o Synaptic, o quanto antes, e nunca mais.

•• Conclusões


As únicas “falhas” realmente relevantes, nesses 3 testes de trabalho em Live USB Kubuntu Xenial (beta, beta2), foram, — ou podem ter sido, — de origem humana.

No entanto, — do ponto de vista de “segurança (para um leigo) em dispor de um sistema produtivo”, — a experiência desperta cautela quanto a outros aspectos, escaldados em sucessivas “migrações”, nos últimos 30 anos: — Apple OS → CP/M → MS-DOS → DR-DOS/Windows → Kurumin → Kubuntu, — passando pelo desaparecimento / perda de rumo de alguns softwares (Xerox Ventura Publisher, dBase), que em alguns casos ocasionaram perda total de trabalho acumulado (acervo digital), em outros casos exigiram horas excessivas para migração / conversão de arquivos, busca de alternativas (nem sempre satisfatórias), novo aprendizado (perda de produtividade) etc.

O “sistema principal”, — Kubuntu 14.04 LTS, — está operacional, satisfatório, plenamente produtivo, com um conjunto de aplicativos suportados em seus repositórios, e com as configurações acumuladas na “/home” ao longo de 4 anos. É o que comanda o backup diário, baixa as fotos do celular etc., — entre outras coisas, ainda não obtidas no “sistema alternativo” (Linux Mint 17.3 Cinnamon).

Isto sugere:

a) Instalar o novo Kubuntu 16.04 LTS Xenial Xerux, — sem urgência desatada, — inicialmente como “sistema alternativo”, até instalar e configurar todos os aplicativos necessários ao trabalho regular, conferir que ainda sejam os mesmos, ou, — se forem “substitutos”, — certificar que atendam às necessidades, aprender a usá-los etc.

b) Após Kubuntu 16.04 LTS Xenial Xerus tornar-se o “sistema principal”, rever o uso do “sistema alternativo”, — não mais como “teste” de outras distros (Debian, Linux Mint), — mas para acompanhamento ativo  de novas versões intermediárias do próprio Kubuntu (16.10, 17.04, 17.10), pois fica evidente a inconveniência da longa acomodação a um LTS, seguida de súbita migração para outro LTS muito diferente.

Várias das “dificuldades” e estranhamentos experimentados agora, — num salto súbito do KDE 4.13.2 para 5.5.4, — já se teriam dissipado numa vivência sequencial do Kubuntu 14.10, 15.04, 15.10.

_______
Esta postagem foi inicialmente publicada às 23:58 de 9 Abr. 2016, com 1 imagem e alguns parágrafos, e desenvolvida até 1:15 de 12 Abr. 2016, com 17 imagens.
A sessão Live USB Kubuntu 16.04 Xenial beta2 (Daily Build 08-Apr-2016 05:38) foi carregada em 9 Abr. 2016, às 13:09, e prosseguiu até 2:30 de 12 Abr. 2016, totalizando 61h20min.
•• Reaberto em 16 Abr. 2016 para acréscimo dos tópicos “Falha prévia (II)” + “Falha intermediária” + “Conclusões”.

— … • … —

Kubuntu



Testes de trabalho em “Live USB”


quinta-feira, 31 de março de 2016

Fedora 24 alpha KDE em sessão Live USB

Tela inicial do Fedora 24 alpha KDE, às 14:47

Esta foi minha primeira experiência, na vida, com um Linux alheio à “família” Debian, — onde mal me viro com meia-dúzia de comandos básicos, — por isso, feitas as contas, o que parece um retumbante fracasso foi, na verdade, um aprendizado valioso. E nem um pouco desagradável. Gostei tanto, que entrei pela madrugada. Apenas, não consegui produzir nada, além de screenshots.

E que safra de screenshots!, — nada menos que 77, das 14:52 às 17:19, — quase todos com mensagem semi-transparente de erro.

Verdade, consegui fazer boa parte das configurações habituais, para trabalhar com mais agilidade, — mas o trabalho, mesmo, não andou, por falta de LibreOffice e de Gimp, e por impossibilidade de obtê-los. Boa parte dessas 2h30 minutos se gastou em luta com o Calligra (nunca usado antes) e com o instalador de programas.

Mas, foi instrutivo. O que sabia sobre o Fedora, era praticamente zero. — Ao passo que, agora, tenho meia dúzia de tópicos para pesquisar, caso queira dar mais um passo.

Fedora, download, Live USB


Fedora está em 5º lugar no ranking de “acessos por dia” do Distrowatch nos últimos 12 meses, logo abaixo do Linux Mint, Debian, Ubuntu e openSUSE. Trata-se de um ranking apenas de “interesse” (busca de informações). Nas últimas 4 semanas, havia caído para a 6ª posição, mas na última semana já recuperou e apresenta algum crescimento.

O Fedora 23 foi lançado em 3 Nov. 2015, — há 5 meses, portanto, — e no último dia 29 Mar. (anteontem), já foi liberada a primeira versão “alpha” do próximo Fedora 24 (Distrowatch), previsto para lançamento em Jun. 2016 (Wikipedia EN). O ambiente desktop padrão é o Gnome, mas oferece várias alternativas (Distrowatch). No site oficial, você se depara logo com 3 “Baixar agora”: — “Workstation” (desktop), “Server” e “Cloud”, — cujos links levam às versões Fedora 23, de 64bit (“x86_64_23-10”), pelo menos no meu caso.

Em vez disso, — se você procura um Fedora 23 “não-Gnome”, — veja no rodapé da página, embaixo do título “Download”, a opção (em letras miúdas) “Fedora spins”, que leva a uma página com as versões KDE, Xfce, Mate-Compiz, Cinnamon, Soas; ou a opção “Fedora Labs”, para versões especializadas “Design suite”, “Games”, “Robotics suite”, “Scientific”, “Security Lab”.

Pouco antes do rodapé, você passou pelo destaque “Fedora 24 Alpha released”, — que leva só às opções especializadas “Astronomy”, “Jam”, “Robotics suite” e “Scientific”.

Ou, escolha a última opção do rodapé, — “Torrent Downloads”, — que apresenta todas essas opções numa tabela simples (mas sem esclarecimentos).

Gerando a midia USB (Pendrive) do Fedora 24 alpha KDE por comando “dd

Esqueça o “USB Creator”, que ignora solenemente as ISOs do Fedora. Em geral basta triscar em qualquer outra ISO, para preencher com ela o campo respectivo. Mão há jeito dele aceitar uma ISO do Fedora. É o mesmo que você não clicar em em nada, — o campo permanece em branco.

Links sobre “como gerar a mídia”, no Guia oficial de instalação, te levam a uma enciclopédia, que dá a volta ao quarteirão. Boa parte das alternativas recomendadas dependem de você já ter um Fedora instalado, ou um Windows moderno, e/ou softwares de que nunca tinha ouvido falar, até ontem.

De todas as alternativas, a única ao meu alcance imediato era mesmo o comando “dd”:

dd if=/path/Fedora-XYZ.iso of=/dev/sdc

Depois de várias cabeçadas, — com o Fedora 24 alpha KDE, com o Fedora 23 KDE e com o Fedora 24 alpha Workstation (padrão: Gnome), — nova pesquisa sobre a geração da mídia apontou variações dentro do próprio site oficial:

bs=8M
bs=1M
bs=1M count=100
bs=8M && sync

Trata-se de diferentes versões do Guia, desde o Fedora 17 até o Fedora 23. É tentador deixar-se hipnotizar por miuçalhas como essa. Pesquisa adicional sobre o comando “dd” não sugere grandes probabilidades de resultado prático, caso faça mil testes em torno dessa hipótese. Fica o registro.

Num dos outros testes, mais tarde, utilizei “bs=1M”, mas não ouvi soarem trombetas.

Tela de opções para o carregamento do Fedora 24 alpha KDE em Live USB

Boot


Ao inicializar o computador a partir do Pendrive, são oferecidas 2 opções principais, e 2 alternativas:

  1. Iniciar
  2. Testar midia e iniciar
  • Solução de problemas
  • TAB para configuração das opções

Escolhido “Testar a midia e inciar”, surgiu uma mensagem de “Supported ISO: no”, porém passou desapercebido, uma vez que o processo transcorreu rapidamente, e com toda aparência de sucesso.

Teste da midia USB (Pendrive) antes de carregar o Fedora 24 alpha KDE

Pesquisando mais tarde, na web, foram encontrados alguns registros de bug com essa frase, aqui e ali, porém nenhuma com prosseguimento aparentemente exitoso. São casos em que o bicho empacou.

Para um absoluto ignorante em Fedora, a tentação de se hipnotizar por essa frase também é grande. Fica o registro.

1ª sessão Live USB


A tecla PrtScn aciona o Spectacle, — com suas boas opções de “Salvar e sair”, e de Configurar o nome (automático) e a pasta onde os prints serão salvos, — mas a brincadeira foi muito mais divertida.

Relatório do crash do Spectacle, printado por ele mesmo, no Fedora 24 alpha KDE em Live USB

Feita a configuração do nome automático (data_hora) e da pasta (F:\…\Fedora…etc), — imediatamente deu crash no Spectacle. — Mas, um crash curioso, pois ele continuou funcionando, e salvando com os nomes corretos, na pasta correta, por mais 2h30m.

Só de brincadeira, aproveitei para fazer um print do crash dele próprio.

Dolphin ajustado para agilizar o trabalho no Fedora 24 alpha KDE em Live USB

Das 14:56 às 15:35 foram configurados o Fuso horário, o Dolphin, e o Gwenview, sem incidentes.

Depois das 15:37, a brincadeira começou a perder um pouco da graça.

Primeiro, porque a midia não inclui LibreOffice, — lidar com o Calligra, de improviso, pela primeira vez na vida, não foi muito produtivo, — e tampouco inclui o Gimp.

Algum tempo perdido no Apper, sem nenhum sucesso em instalar Gimp ou LibreOffice.

Forte sensação de que isso talvez não seja possível no Fedora em sessão Live USB, — mas nenhuma confirmação explícita encontrada, até agora, no site oficial ou na web.

às 16:26, Firefox sincronizado (Complementos e Favoritos), — System Monitor (KSystemguard) indica uso de 1,2 de 3,9 GiB da memória (e zero de 8,3 GiB swap).

“Erros inesperados” no Apper e no Spectacle, em sessão Live USB Fedora 24 alpha KDE

Às 16:42, — após sucessivas tentativas falhadas de instalação de software, — crash do Apper (“Out of memory”), e novo crash do Spectacle (///config/spectacler “not writable”). Mas, o Spectacle continua printando. Apenas, incluindo suas próprias mensagens de erro. — Uso de memória: 1,3 de 3,9 GiB.

Às 16:44, “erro inesperado” no Dolphin (continua funcionando) e no Spectacle (segue printando). — Daqui por diante, todos os prints de “erro” incluem também “erro” do Spectacle (às vezes superpostos).

Às 16:50, “erro” ao tentar fazer anotações no Calligra. Erro ao verificar o layout Teclado. Erro ao tentar uma visualização no Gwenview (///config/gwenviewrc “not writable”).

Às 17:16, Firefox desaparecido. Não pode ser aberto, porque já está aberto. Três tentativas de “encerrar” o Firefox pelo System Monitor (KSysguard), até 17:19.

Hora de encerrar a experiência, — já que não é possível receber as fotos enviadas do celular por email, nem editar imagens, nem vale a pena tentar trabalhar com um editor de textos (Calligra) nunca utilizado antes, sem Teclado PT-BR e sem acesso ao 3º nível.

2ª sessão Live USB


Confiado em experiências recentes, — com pausa, aviso para remover o Pendrive e clicar Enter, — acabei voltando ao Fedora 24 alpha KDE.

17:24 – Tela inicial do Fedora

17:26 – Dolphin aberto para buscar o primeiro PrtScn, gravado (por padrão) na pasta /home/Pictures

17:27 – Dolphin → partição F:\ — para montar, antes de configurar o Spectacle para gravar nela os prints… Epa. Mensagem de erro.

17:43 – System monitor, com Dolphin, Firefox, Gwenview e Calligra abertos

17:44 – System monitor, após novo crash do Firefox… com mensagem de erro também do Spectacle.

Tira-teima


Não fiquei nem um pouco satisfeito com esse desfecho. Mas, tampouco via motivo para prosseguir. Por todos os lados que considerasse a experiência, não era possível ver utilidade em tentar “trabalhar em sessão Live USB” com uma ISO sem Gimp, sem LibreOffice, e aparentemente sem possibilidade de instalar, sequer, uma fonte de letra.

Para tirar uma prova, baixei e rodei mais 2 ISO Fedora:

  • 31 Mar., 0:06 → Fedora 23 KDE
  • 31 Mar., 18:00 → Fedora 24 alpha Workstation (Gnome)

No primeiro caso, para ver o KDE em um Fedora já lançado. — No segundo, para ver o Fedora 24 alpha sem o KDE.

Live USB Fedora 23-10 KDE


Por quase 3 horas, de 0:06 às 2:58, foi possível trabalhar razoavelmente, — em especial, colocar em dia a comunicação (Firefox com complementos), por quase uma hora, sem problema, — e depois, levantar o relato cronológico da experiência, a partir dos prints, usando Gwenview e Dolphin. Dessa vez, o Teclado ABNT2 funcionou sem problemas no Calligra.

Feito tudo que havia para ser feito, era hora de cutucar a onça.

“Read-only file system” no Apper em Live USB Fedora 23 KDE

Às 3:06, aberto o Apper. Dá impressão de que precisa de um longo tempo, antes de começar a funcionar. No começo, não encontra nada, embora pareça normal. Às 3:13 → “Aconteceu algum errro que não era esperado”. Às 3:19, finalmente começa a encontrar as coisas digitadas no campo de busca. Às 3:26, instalar Gimp e Vermana2000. Às 3:27, “problema” no Apper.

  • Às 3:32, Firefox avisa: “Sync encountered an error while syncing: Unknown error”.
  • PrtScn não funciona mais.
  • Apper fecha inesperadamente, ao dar Esc para fechar uma subjanela.
  • Terminal não abre.
  • Firefox, fechado há pouco, também não abre mais.
  • Menu → Shutdown → Não acontece nada.

Sessão encerrada pelo botão de energia.

Fedora 24 alpha Workstation (Gnome)


17:53 – Concluída gravação da ISO no Pendrive.

18h00 – Acumulado ateh aqui: (1) Crash logo na tela de pre-entrada, ~Try or install~, mandei Reload (ver foto NL), e apagou o aviso. (2) PrtScn nao reage, e nao ha nada em /home/Pictures, (3) Gerenciador de arquivos muito simples, sem nome, sem ~About~, a muito custo descobri o caminho para umas pobres configuracoes, no entanto bastou ajustar as propriedades de visualizacao de 1 pasta, e fez efeito geral, (4) Tem LibreOffice, (5) Tem um Screenshot, que oferece nomeacao automatica de arquivos no formato ~Screenshot from 2016-03-31 17-20-19~ e daih por diante lembra a pasta escolhida antes. Mas nao responde ao PrtScn, eh preciso procurar no menuzao.

18h27 – Keyboard. Clicado em Add para adicionar PrtScn, e a janelica de configuracao desapareceu. Alt-Tab nao acusa sua existencia, soh LibreOffice e Gerenciador de arquivos. Reaberto pelo caminho burocratico (Atividades, Quadro de bolotas, exibir um punhado de icones enormes ocupando toda a tela). Parece configurada PrtScn, sim, soh que nao funciona.

Layout de Teclado aparece em Region & language, Input sources. “+” para adicionar, Portugues (Brasil), ok, e já começou a valer no LibreOffice, sem nem precisar fechar e abrir de novo.

18:37 – Firefox conectado, já fez Sign in e já está sincronizando. Navegação normal, até parece mais ágil do que no Kubuntu instalado. Mais leve no FB. – Flash unavailable.

19:18 – Nada mais a fazer por aqui. Pouquíssimos softwares (cabem quase todos numa tela, mesmo abusando da enormidade dos ícones), e a maioria não interessa neste momento (som, fotos, vídeo, Evolution para emails).

19:28 – Restaurado o Gerenciador de arquivos, e apareceu tudo no formato de ícones enormes, inclusive a pasta que estava aberta com exibição em lista. Tudo bem, bastou ajustar numa aba, e voltou a valer para as outras abas.

20:10 – Disparado o comando:

  • su
  • dnf install gimp

A princípio, pareceu funcionar, depois começaram a surgir erros, — deixo de transcrever as 395 linhas do Terminal, — mas, pelo menos, não deteriorou o sistema inteiro.

A penúltima das 395 linhas diz o seguinte:

Message: "[Errno 30] Read-only file system: '/var/cache/dnf/expired_repos.json'"

21:50 – Nada mais a fazer, sem Gimp, sem PrtScn ágil, sem quase nada configurável.

Aprendizado


Por incrível que pareça, foi muito instrutivo esse contato inicial com o Fedora, — aprender não é só obter domínio imediato, mas também identificar dúvidas e pontos a pesquisar.

A aparente impossibilidade de instalar, sequer, uma fonte de letra em sessão Live USB, — embora não encontre afirmação explícita neste sentido, — sugere que a resposta não seja tão simples.

Também ficou evidente, — ainda que de modo indireto e meio distante, — que a “zona de conforto” do Kubuntu 14.04 LTS (com KDE 4) pode ter levado a descuidar do que se passa no KDE 5.0 (Jul. 2014!), … 5.5, 5.6.

Régua de tela (Kruler) descoberta no Fedora 23 KDE

Este relato foi publicado inicialmente às 9:59 de 31 Mar. 2016, com 1 imagem, e as informações de download e gravação da midia. — Tudo mais foi acrescentado das 17:40 de 2 Abr. às 2:30 de 3 Abr., — sempre em Kubuntu 14.04 (HD).

Também em Kubuntu 14.04 (HD) foram renomeadas em massa as fotos de celular, com pyRenamer, para se enfileirarem cronologicamente com os prints do Spectacle feitos no Fedora 24 alpha KDE.

Apenas o levantamento cronológico, com base nos prints e fotos assim alinhados, foi feito em sessão Live USB Fedora 23-10 KDE, usando Calligra, Dolphin e Gwenview.

— … ≠ • ≠ … —

Não-debians



Testes de trabalho em “Live USB”