TechEvangelism

I have tested only on Ubuntu, but this might apply to some other distros.

Some people follow this: https://help.ubuntu.com/community/DefaultFileManager

but it makes nautilus useless. That's bad!

Instead of changing the way nautilus works, you just want to get rid of it - and let other people use it if they want.

As sudo:
1 - Open the files:

/usr/share/applications/nautilus-folder-handler.desktop

and

/usr/share/applications/kde4/dolphin.desktop

2 - Replace the contents of the MimeType of the dolphin.desktop with the one from nautilus-folder-handler.desktop (replace the entire line).

3 - Run

update-desktop-database -v

Here it worked out of the box... if it doesn't work for you, don't worry.

1 - Open

/usr/share/applications/mimeinfo.cache

2 - Locate each occurrence of kd4-dolphin.desktop and place it before any other option.
For instance:

x-directory/gnome-default-handler=nautilus-folder-handler.desktop;kde4-dolphin.desktop;

should be:

x-directory/gnome-default-handler=kde4-dolphin.desktop;nautilus-folder-handler.desktop;

As a bonus, each user can have a mimeinfo.cache on

$HOME/local/share/applications

and specify it's own order. No logout required.



It's on a per user basis, it won't be smart enough to detect if you're running KDE or not. But you are .
For instance, you can make a script to make copies of the mimeinfo.cache file locally and execute scripts when starting your desktop environment to make a symbolic link to the right mimeinfo.cache.

At least for a per user basis, you can leave one safe system default (GNOME) and one for you.


Note: Firefox uses x-directoroy/gnome-default-handler instead of x-directory/normal, as one would expect.
Note 2: The MimeType change is required.

A comunidade do SeaMonkey deu seu primeiro grande passo em direção a rodar no XULRunner.
Após o nascimento do Firefox, parte do código foi reescrita e parte foi recriada, e o conteúdo que não era exclusivo de um navegador foi migrado para toolkits (nem todo, mas isso daí já é problema deles).

A Suíte estava usando seu código antigo, mantido pela comunidade, até anteontem.
O projeto criado para conduzir a transição do SeaMonkey para toolkits foi nomeado Suiterunner, devido à meta a longo prazo de rodar no XULRunner. Como primeiro grande passo desse projeto, que foi iniciado há três anos e quatro meses atrás, agora as builds do trunk do SeaMonkey são feitas com base nos toolkits, por padrão.

Muitíssimo trabalho foi feito e muita coisa ainda está por vir. Mas o efeito mais importante desta mudança é compartilhar muito mais código com o Firefox, assim ambos irão se beneficiar. O time do SeaMonkey poderá investir bem mais em melhorias, por exemplo.

Aproveitando a deixa...
agora sou o mantenedor do site:
http://seamonkey.ilias.ca/

Há duas opções:

1 - se quiser evitar que o usuário altere as configurações inadvertidamente, coloque um arquivo "user.js" na pasta "[pasta do SM]/defaults/profile" com as alterações
2 - caso essas configurações possam ser modificadas pelo administrador, coloque um arquivo "all.js" na
pasta "[pasta do SM]/defaults/prefs", com elas

Essas duas técnicas podem coexistir.


As alterações da configuração que você faz num perfil ficam armazenadas
no "prefs.js" dele. Você pode criar um perfil, fazer apenas as
alterações necessárias, depois salvar o arquivo "prefs.js", que fica na
pasta do perfil, como "all.js", apagar todos os "user_" e colocar na pasta mencionada no item 2, acima.
O passo de apagar todos os "user_" pode ser feito através de um editor de texto que possua facilidade de substituição de texto.

Assim todos os usuários terão essas configurações carregadas ao iniciar
o programa, mesmo os que já tenham o perfil criado.



Qualquer coisa que mude posteriormente, é só alterar o "all.js".



Com o "user.js" na pasta mencionada no item 1, os arquivos seriam
copiados para o perfil do usuário, o que dispenderia uma alteração
manual posterior em caso de mudanças.


A prioridade das configurações é a seguinte:
primeiro busca-se no "user.js", depois no "prefs.js" e por último no
"all.js" e as configurações não são sobrescritas, isto é, as que já foram
carregadas têm seu valor alterado posteriormente.

Isto significa que as configurações comuns a todos ("all.js") possuem
uma prioridade menor que as configurações que o usuário faça através do
próprio programa ("prefs.js"), e estas possuem uma prioridade menor que
as definidas no arquivo de configuração pessoal ("user.js").
Mas "all.js" tem prioridade maior que os outros arquivos de configuração padrão.


Utilize o diretório "[pasta do TB]/defaults/profile" para colocar
arquivos que precisem ser copiados (o "user.js" é um exemplo desses
arquivos).
Um caso é o catálogo de endereços ("abook.mab").
Adicione os endereços, depois copie o "abook.mab" para a pasta
mencionada acima. Os perfis criados após isso terão esse arquivo copiado
para lá.

O texto abaixo é de um email enviado para uma lista de discussão...

Robert R. Roman:
> Rene de Paula Jr:
>> eu vou repetir uma colocacao que ja fiz em outras ocasioes. surge
>> um browser novo, ou uma versao nova. la' fora, bilhoes de paginas
>> com aderencia limitada aos padroes.
>>
>> duas estrategias:
>> - o browser ser "limpinho" mas tambem acomodar o que nao e' padrao
>> - o browser so' aceitar o padrao e comprar a briga com bilhoes
>> de paginas existentes
>>
>> eu juro que nao consigo entender quem segue a segunda linha
>
> Nas primeiras versões dos nossos sites tentávamos agradar a todos,
> gregos e "baianos", com o passar do tempo e o predomínio total do IE,
> passamos a nos preocupar somente com esse. Agora, com o crescimento
> do Firefox, passamos a nos preocupar com ele também.
>
> A comunidade do software livre ainda não percebeu que a melhor forma
> de combater a MS é sendo o mais parecido possível com ela.
>


Sorry, embrace and extend?
Quer fazer coisas fora do padrão, como a Netscape fez (sim, foi ela quem
começou (brincadeira de criança))?
Software livre = liberdade de escolha.
Eu não tenho dor de cabeça se alguém usar IE ou Windows, desde que não
me peça para tirar uma dúvida ou resolver um problema. Cada um escolhe o
que achar melhor. Devemos nos esforçar para aumentar esta escolha.
Monopólios sempre são ruins, mesmo que o produto seja considerado
realmente bom pela maioria.

A questão não é de um navegador ter usuários e a partir daí fazer coisas
que funcionem somente nele, não se preocupando com os outros.


Esperando responder a pergunta de René objetivamente:
Seguir padrões é bom, esse é o objetivo em qualquer área.
Justamente para não termos que nos preocupar em adaptar as páginas a
cada navegador que faça sucesso, o ideal é todos seguirmos um padrão.
Se alguém coibiu seu uso e, por ser dominante, induziu pessoas a sairem
do padrão, a melhor maneira não é imitar o uso geral.
O que deve ser incentivado é que *todos* migrem para os padrões, dessa
forma a tua questão nem existiria, já que qualquer navegador (seguinte
dos padrões) que a pessoas usasse não teria diferença para a
funcionalidade básica da página.

Os novos que surjam e não se adaptem aos padrões estariam contribuindo
para uma desordem. Se todos quisessem aumentar o domínio fazendo um
navegador personalizado e ferramentas personalizadas para fazer páginas
para ele, a internet viraria uma torre de babel, na qual as pessoas
teriam que usar vários navegadores para poder visualizar todas as páginas.

(Qualquer página mediana no FrontPage é incompatível com qualquer
navegador não IE, por menor que seja a incompatibilidade. Se o Firefox
seguisse isso...)
O IE7 fixa alguns bugs do IE6, portanto a própria Microsoft está
descontinuando a personalização dela para as funcionalidades básicas (as
páginas com hacks toscos para IE6 e que desconsiderem os outros
navegadores não funcionam corretamente nem no IE7).



Apêndice A: Javascript foi algo inventado pela Netscape (majoritariamente Brendan Eich)
para aumentar a funcionalidade das páginas. A implementação da Microsoft
chama-se JScript. Essas foram coisas adicionadas aos navegadores antes
de se pensar em ter um padrão. Atuelmente ambos navegadores implementam
um núcleo comum, mas não há obrigatoriedade de serem completamente iguais.
Portanto javascript não é algo que vá se tornar 100% compatível dentre
os diversos navegadores atualmente e algumas coisas dentro do núcleo em
comum que ambos (Firefox/Gecko e IE/Trident) implementam depende de
características globais da linguagem que sao diferentes, portanto
existem ainda pequenas coisas a se fazer para que páginas com javascript
complexo funcionem em ambos (mesmo que seja só adaptação, restrição de
código, pequenos "jeitinhos").

Apêndice B:
A máquina de renderização do navegador é o que importa:
Gecko - Firefox, Camino, Seamonkey
Trindent - IE para Windows, Windows Explorer, Ajuda do Win
Tasman - IE para Mac
KHTML - KDE(incluindo Konqueror), (base para a WebCore)
WebCore - Safari, MacOS Help Viewer, Mail, iWeb, Nokia Web Browser,
RealPlayer e Dreamweaver (no Mac OS X)
Presto - Opera

Apêndice C:
Especificação da base em comum do javascript, que pode ser extendida,
chamada ECMAScript:
http://www.ecma-international.org/publications/standards/Ecma-262.htm
Tanto extensões oficiais quanto extensões pessoais de cada rendering
engine podem ser feitas.

Apêndice D:
Ninguém lê emails grandes até o fim .

A versão 2.0 do BrOffice.org acabou saindo sem dois links simbólicos. Isso será corrigido nas próximas versões, mas atualmente pode resolver teu problema criando os links manualmente. Para fazer isso execute, como root:

cd /usr/bin
ln -s broffice.org-2.0 broffice
ln -s broffice.org-2.0-printeradmin broffice-printeradmin