DEV Community: Jefferson Rodrigues

Extensão do gnome para papel de parede de tela de bloqueio

Jefferson Rodrigues — Thu, 05 Nov 2026 22:53:12 +0000

Olá a todos, hoje vou compartilhar com vocês a solução pra um problema que talvez você não tenha. Eu sou um distro hopper, mas recentemente decidi me aquietar e usar um sistema só e ficar nele. Eu usava o Arch por muito tempo, mas desde que corrompi o sistema com uma atualização e perdi coisas do trabalho, mais por falha minha mesmo do que por culpa do Arch, eu passei um bom tempo no Mac por ser dev iOS no meu antigo trabalho. Agora que mudei de área, voltei para o Linux e caí naquele problema de sempre, pular de distro em distro para ir testando coisas novas. Acontece que esse é o pc que uso no trabalho novo então eu não queria ficar brincando.

Distro Hopping

Em pouco mais de um mês eu instalei 3 distros: Linux mint,OpenSuse Tumbleweed e agora o Ubuntu. No mint passei uma ou duas semanas, fui pro suse porque eu queria voltar ao rolling release (gosto de ficar com os pacotes mais atuais) e instalei o Hyprland, mas vendo um vídeo do DioLinux fiquei reflexivo com algo que ele disse: "Porquê eu vou usar uma distro que complique a minha vida?". Isso ficou na minha cabeça, passei uns dois dias pensando nisso e decidi mudar de distro para uma estável e mais "Tranquila".

Entrei num dilema, usar o PopPS! ou Ubuntu, ambos usam apt e são base Debian, e eu gosto disso. Mas eu acho que o Cosmic tem uma pegada muito infantil na interface, talvez por ser toda colorida (Se bem que podemos simplesmente mudar o tema né? rsrs). Não sei se é apenas uma opinião minha. Em contra partida o próprio Cosmic tem o tile nativo que você pode ativar e desativar com muita facilidade, e eu gosto de poder ter essa opção e sinto falta dela no Ubuntu. Não sei se nele temos algo assim configurável por meio de extensão.

Um problema de ninguém

Daí contexto dado, entramos no assunto do post: extensões. O Windows tem algo que eu acho legal que é aquela mudança de papel de parede da tela de bloqueio a cada novo bloqueio de tela. Algo bem simples, é verdade. Mas o Gnome não me permite nem alterar a imagem padrão, quanto mais mudar ela dinamicamente. Iniciei a minha saga em busca de alguma extensão que me permitisse fazer isso, mas não encontrei...

Encontrei então essa extensão que me permite mudar o papel de parede da tela de bloqueio. Boa! Quase lá, mas ainda tem um problema, eu queria que as fotos mudassem dinamicamente sempre que bloqueasse a tela.

Minha solução

Daí resolvi vibe codar a minha própria extensão, abri um fork do repositório desse brother e com o auxílio do Claude, criei a minha própria solução para isso. Ela se chama Gnome Shell Extension Random Lock Screen BG e o diferencial dela está no provider das imagens, você pode configurar ela da seguinte forma:

Você pode selecionar somente uma foto e ela fica fixa;
Você pode selecionar uma pasta com suas fotos que irão ser alteradas de forma aleatória;
Você pode optar por trazer as fotos do Unsplash, se você não quiser criar uma chave de api, pode deixar selecionado sem adicionar chave e ele vai buscar do Lorem Picsum que são fotos grátis e muito boas também;

E como a extensão funciona?

Simples, quando a tela bloqueia, o programa não tem acesso para enviar notificação para o sistema fazer a chamada da foto, então sempre que você desbloqueia, ele chama a API e já deixa selecionada em cache a foto para o próximo bloqueio, você pode limitar a quantidade de fotos salvas em cache.

Tela bloqueada:

Simples assim e o seu Gnome vai ficando mais bonito, como eu disse lá encima, é um problema que ninguém tem, mas me incomodava e eu resolvi resolver. A IA nos permite ter esse tipo de facilidade, e eu estou muito satisfeito com o resultado.

Caso você queia o link para contribuir ou baixar na sua máquia e instalar:
Link da extensão
Link do repositório

Ainda não subi no Gnome Extensions, em breve edito aqui com o link de lá.

Josue Meetings - FOSS aplicativo para transcrever e resumir calls

Jefferson Rodrigues — Thu, 30 Jul 2026 03:05:33 +0000

Josue Meetings é um aplicativo desktop que grava suas reuniões em segundo plano, capturando o áudio do sistema e do microfone. O aplicativo permanece na menu bar e transforma o áudio em texto utilizando o Whisper executado localmente. Depois, se desejar, gera resumos e responde perguntas usando OpenAI ou DeepSeek.

Sem servidor próprio: seus dados permanecem na sua máquina.

O problema

Toda reunião online gera informações importantes, mas quase sempre elas acabam se perdendo. Gravar o áudio, transcrever e resumir normalmente exige várias ferramentas e serviços na nuvem.

O Josue Meetings resolve tudo isso em um único fluxo, executado localmente.

Como funciona

Dê um nome para a reunião (ou utilize o padrão).
Inicie a gravação.
Acompanhe os níveis de áudio do sistema e do microfone.
Pause, retome ou finalize quando desejar.
Continue trabalhando normalmente pela menu bar.
Ao finalizar, a reunião é aberta automaticamente para transcrição.

Transcrição local

Toda a transcrição é realizada utilizando o Whisper executado na própria máquina.

Você pode exportar o resultado em:

Markdown (.md)
Texto (.txt)

Após uma transcrição bem-sucedida, o áudio pode ser removido automaticamente, preservando sua privacidade.

Inteligência Artificial (Opcional)

Com uma chave de API da OpenAI ou DeepSeek, você pode:

Gerar resumos automáticos.
Conversar com um agente sobre uma reunião.
Organizar reuniões em pastas.
Fazer perguntas considerando todas as reuniões de um projeto.

Configuração

O aplicativo possui um assistente de configuração que detecta o sistema operacional e orienta a instalação dos componentes necessários.

Atualmente:

✅ macOS: captura de sistema + microfone utilizando BlackHole e Multi-Output Device.
🚧 Windows: suporte em evolução.
🚧 Linux: suporte em evolução.

Recursos

Aplicativo desktop (Electron)
Gravação do sistema + microfone
Funcionamento na menu bar
Transcrição 100% local (Whisper)
Resumos e chat via OpenAI ou DeepSeek
Organização por projetos
Agente por pasta
Lixeira integrada
Assistente de configuração
Privacidade por padrão

Grave suas reuniões sem interromper seu trabalho, transcreva tudo localmente e utilize IA apenas quando fizer sentido, sempre com a sua própria chave de API.

O software é livre e aceitamos contribuição de pessoas bem intencionadas que queiram ajudar a melhorar cada dia mais!
Repositório do projeto

🚀 Revisando o S.O.L.I.D na Prática com Flutter e Dart

Jefferson Rodrigues — Thu, 26 Feb 2026 03:58:02 +0000

🚀 Revisando o S.O.L.I.D na Prática com Flutter e Dart

🎯 Introdução

Resolvi revisar os meus conhecimentos sobre temas essenciais da programação. Iniciei pelo SOLID porque é algo que deve ser revisitado de vez em quando para garantir que estamos entendendo não só o conceito, mas a prática também.

Com isso, podemos escrever códigos mais limpos, escaláveis e de fácil entendimento.

🛠️ Metodologia

Usei como base dois repositórios meus de quando eu estava estudando Clean Architecture. Um deles trata-se de um app simples: buscar conselhos em uma API e retornar para o usuário.

Neste projeto, aplico cada um dos cinco princípios do SOLID. Abaixo, detalho como cada um deles se comporta no código.

🟢 S — Single Responsibility Principle (SRP)

Princípio da Responsabilidade Única: Uma classe deve ter um, e apenas um, motivo para mudar.

No exemplo abaixo, a classe abstrata para o data source define apenas o contrato de busca remota. Ela não se preocupa com lógica de negócio ou como os dados serão exibidos.

abstract class AdviceRemoteDataSource {
  Future<Advice>? getAdvice();
}

Outro exemplo claro é o tratamento de erros. Criamos uma estrutura base e especializamos as falhas:

abstract class Failure extends Equatable {
  const Failure([List properties = const <dynamic>[]]) : super();
}

// Responsável apenas por erros de servidor
class ServerFailure extends Failure {
  @override
  List<Object?> get props => [];
}

// Responsável apenas por erros de cache local
class CacheFailure extends Failure {
  @override
  List<Object?> get props => [];
}

🔵 O — Open/Closed Principle (OCP)

Aberto para Extensão, Fechado para Modificação: Você deve ser capaz de estender o comportamento de uma classe sem modificar o seu código-fonte original.

A classe AdviceRepository está "fechada" (o contrato está definido). Se precisarmos de uma nova forma de obter dados, apenas implementamos o contrato em uma nova classe, sem tocar na interface original.

abstract class AdviceRepository {
  Future<Either<Failure, Advice?>>? getAdvice();
}

class AdviceRepositoryImpl implements AdviceRepository {
  final AdviceRemoteDataSource remoteDataSource;

  AdviceRepositoryImpl({required this.remoteDataSource});

  @override
  Future<Either<Failure, Advice?>>? getAdvice() async {
    try {
      final remoteAdvice = await remoteDataSource.getAdvice();
      return Right(remoteAdvice);
    } on ServerException {
      return Left(ServerFailure());
    }
  }
}

🟡 L — Liskov Substitution Principle (LSP)

Princípio da Substituição de Liskov: Objetos de uma superclasse devem ser substituíveis por objetos de suas subclasses sem quebrar a aplicação.

No Flutter, isso é muito comum com os DataSources. A implementação AdviceRemoteDataSourceImpl pode substituir perfeitamente a abstração AdviceRemoteDataSource em qualquer lugar que ela seja exigida.

class AdviceRemoteDataSourceImpl implements AdviceRemoteDataSource {
  final http.Client client;
  AdviceRemoteDataSourceImpl({required this.client});

  @override
  Future<Advice>? getAdvice() async {
    // Implementação real da chamada HTTP
    // ...
  }
}

💡 Obs.: Uma melhoria seria criar um AdviceDataSource genérico, permitindo trocar o Remote pelo Local de forma transparente.

🟠 I — Interface Segregation Principle (ISP)

Segregação de Interface: Uma classe não deve ser forçada a implementar interfaces e métodos que não utiliza.

Em vez de criar uma interface gigante "TudoNoApp", dividimos em interfaces específicas. No exemplo, o repositório depende apenas do que é essencial para ele: o DataSource de conselhos.

// Interface específica e focada no domínio de conselhos
abstract class AdviceRemoteDataSource {
  Future<Advice>? getAdvice();
}

🔴 D — Dependency Inversion Principle (DIP)

Inversão de Dependência: Dependa de abstrações, não de implementações concretas.

Aqui é onde o GetIt ou Provider brilham. O AdviceRepositoryImpl não conhece a implementação do DataSource, ele conhece apenas o contrato. A "mágica" acontece no nosso Service Locator:

void setupLocator() {
  // Registramos a abstração apontando para a implementação
  getIt.registerLazySingleton<AdviceRepository>(
    () => AdviceRepositoryImpl(remoteDataSource: getIt()),
  );

  getIt.registerLazySingleton<AdviceRemoteDataSource>(
      () => AdviceRemoteDataSourceImpl(client: getIt()));

  getIt.registerLazySingleton(() => http.Client());
}

📊 Resumo Visual

Sigla	Princípio	Resumo em uma frase
S	Responsabilidade Única	Cada classe faz apenas uma coisa.
O	Aberto/Fechado	Estenda o comportamento sem alterar o original.
L	Subst. de Liskov	Subclasses devem honrar o contrato da base.
I	Segregação de Interface	Crie interfaces pequenas e específicas.
D	Inversão de Dependência	Dependa de contratos, não de classes concretas.

🏁 Conclusão

Utilizar esses conceitos na prática vai além de construir "códigos bonitos". Trata-se de garantir a manutenibilidade. Um código bem estruturado permite que ele viva mais e que as manutenções futuras não sejam um sofrimento.

Lembre-se: o seu código fala muito sobre você! 🚀

Ficou com alguma dúvida sobre como aplicar isso no seu projeto Flutter? Comenta aqui embaixo e vamos trocar uma ideia!