L. Cornelius Dol's questions

Preciso que todas as combinações de teclas de função ALT/CTL/SHF sejam enviadas para um aplicativo (um emulador IBM 5250). Como desvinculo os mapeamentos de sistema para eles? Não consigo encontrá-los nas configurações de teclado para atalhos. (As primeiras vezes que pressionei ALT+CTL+F10, pensei que meu sistema tinha travado e o Fedora estava instável.)

Não importa se elas não estão mapeadas ou estão mapeadas para alguma combinação SUPER, mas elas devem ser desvinculadas para teclas shift normais.

Sou um novo convertido ao Fedora Linux, Gnome desktop, e uma coisa que continua me atrapalhando é que os títulos das janelas ativas parecem praticamente idênticos aos inativos. Isso geralmente me faz fechar a janela errada, pois tenho um monitor grande com 6 ou 7 janelas lado a lado a qualquer momento.

O que eu quero fazer é personalizar o título da janela ativa para que eu tenha uma forte indicação visual de qual janela está ativa em um dado momento. Eu criei um ~/.config/gtk-4.0/gtk.cssarquivo, com o seguinte:

headerbar,
.titlebar {
    background                          : #9D4904 linear-gradient(to bottom, shade(#9D4904,1.2), shade(#9D4904, 0.8));
    border                              : none;
    border-radius                       : 0;
    padding                             : 2px;
    transition                          : 200ms ease-out;
    }

que funciona para quase tudo (uma exceção notável são as janelas do navegador).

Entretanto, em algumas janelas há uma lacuna inexplicável na parte superior:

E em algumas outras partes da barra de título há uma lacuna na parte inferior e superior:

Qualquer ajuda para eliminar isso (e para janelas do navegador também!) seria muito apreciada. Eu tentei todo tipo de adivinhação sobre qual seria a tag/classe CSS para o contêiner, e todo tipo de configuração de preenchimento, mas não tive nenhum efeito.

Sou novo usuário de Linux aqui, recém-transferido do Windows 10 para o Fedora 41. Tenho muita experiência com muitos sistemas operacionais, incluindo vários sistemas de arquivos *nix e semelhantes ao Unix.

Tenho uma prática padrão de usar links simbólicos de pastas de teste para repositórios de código para recriar a estrutura de pasta de produção implantada localmente para teste, mantendo o teste e o repositório de código claramente separados. Tenho muitos projetos configurados assim para teste local.

Isto se parece com o seguinte, por exemplo:

~/dev
  test
    a-project
      app => ../../code/a-project/src
        (cfg)
        (web)
      dta
        cfg
  code
    a-project
      src
        cfg
        web

A chave para esse problema é que a src/cfgpasta (que na produção é a app/cfgpasta) contém arquivos que têm referências relativas a arquivos opcionais nos dta/cfgquais são carregados se eles existirem na produção, esperados para serem relativos à app/cfgpasta. Assim, ../../dta/cfg/Optional.jsonquando implantado, faz referência à dtapasta. O PWD é a raiz do aplicativo (em testes, isso é ~/dev/test/a-projecte todos os caminhos no software são especificados em relação ao PWD. Esses caminhos são manipulados em código Java, usando Filea classe Java, então este não é um problema de comportamento do shell.

Isso funciona perfeitamente no Windows, já que o sistema de arquivos considera o caminho app/cfg/../../dta/cfg/Optional.jsonexatamente como ele parece e resolve as referências relativas primeiro, resultando em dta/cfg/Optional.json(o inicial app/cfgsendo eliminado pelo seguinte ../...

Mas o Linux aparentemente resolve o link simbólico primeiro ( app/cfg/=> dev/code/project/src/)e só então aplica os segmentos de caminho relativos ../../dta/cfg/Optional.json, resultando em um arquivo não encontrado porque, é claro, o arquivo não está localizado em ~/dev/code/project/dta/cfg.

Independentemente de argumentos sobre se isso é tecnicamente correto ou não, há alguma maneira de eu dizer ao Linux em qualquer nível para resolver segmentos de caminho relativos antes de resolver links simbólicos para que esse comportamento inesperado e imprevisível não ocorra? Além de ser confuso e contraintuitivo para mim, tenho muito código existente que espera que os caminhos resolvam referências relativas primeiro, ou seja, usando o caminho aparente, não o caminho subjacente.

O sistema de arquivos para meu trabalho de desenvolvimento é ext4 com case folding habilitado (vindo do Windows e precisando permanecer compatível com outros desenvolvedores usando Mac e Windows), e eu realmente, realmente gostaria de evitar fazer uma mudança desestabilizadora e invasiva em várias classes Java para implementar a resolução de caminho relativo antes de passar o caminho para o sistema operacional; tanto porque é potencialmente frágil, levando a falhas de segurança, quanto porque é necessário apenas para meus testes, já que sistemas de produção (servidores Ubuntu Linux) não precisam desses links simbólicos.