Forum Linux.gui accélérer le lancement de Kwrite

Posté par  (site web personnel) .
Étiquettes : aucune
0
19
nov.
2006
Bonjour,

J'utilise l'environnement de bureau GNOME car je le trouve très convivial et que je n'ai que du 1024x768 sur mon écran (écran plat 15" limitant, et je ne veux pas revenir à un CRT). Pourtant j'utilise Kwrite pour éditer mes fichiers, programmer. Notament grâce à ses grandes possibilités concernant la coloration syntaxique que je personnalise à outrance.

J'utilise Kwrite au lieu de Kate car j'aime bien avoir une fenêtre = un document, et aussi car je ne maximise pas mes fenêtres. Je préfère clisuer sur une autre fenêtre plutôt que clisuer sur une barre des tâches ou sur un panel à gauche listant les documents ouverts (comme kate).

Maintenant, mon problème, c'est que lorsque je lance une nouvelle instance de Kwrite, cela me prend plusieurs secondes. En testant, cela varie de 5 à 10 secondes. Et c'est beaucoup trop long pour moi.
ma solution, drag&drop du fichier depuis nautilus sur un Kwrite déjà ouvert car cela n'ouvre pas une nouvelle instance de Kwrite, donc c'est presque instantanné.

problème, c'est très contraignant. En regardant sur Internet, j'ai vu qu'avec DCOP on pouvait demander à une instance de kwrite déjà lancée d'ouvrir un autre document, seulement, la fonction n'est dispossible qu'avec kate et n'est plus présente dans kwrite.

Cela fait des moins (je n'ose parler d'années) que je me traine avec ce problème, et j'aimerais bien si possible finir par le résoudre. Avez vous des idées, comment précharger Kwrite ? Demander que le lancement de Kwrite utilise une instance déjà existante ?
Et sans me dire d'utiliser KDE ou Kate, je préfèrerais.

PS: j'utilise kwrite 4.5.5 (KDE 3.5.5)

Merci
  • # désolé ...

    Posté par  (site web personnel) . Évalué à -1.

    Je ne connais pas du tout kwrite, mais gedit (l'éditeur de gnome) à fait d'énorme progrès ces derniers temps, grâce à l'intégration de plugins pas mal du tout.

    Regarde tout de même du coté de prelink, ...

    Adhérer à l'April, ça vous tente ?

    • [^] # Re: désolé ...

      Posté par  (site web personnel) . Évalué à 3.

      enfin, gedit, niveau coloration syntaxique, c'est plutôt inexistant.
      gedit dans sa forme actuelle, par exemple, ne permettra jamais de colorer le script shell suivant correctement :
      abc="texte`cat "fichier"`"
      cat "monfichier2"

      Les deux commandes cat ne sont pas colorisées de la mêmee manière. la première est colorisée exactement comme du texte (gedit ne détecte pas et ne peux pas détecter les backquotes `). De plus "fichier" n'est pas reconnu comme une chaîne.
      Je ne te parle pas du Here Document que kwrite colorise parfaitement :
      cat > fichier <<EOF
      contenu avec une $variable ...
      EOF


      Avec kwrite, aucun problème :)

      Enfin, merci pour prelink, je vais chercher là dessus.
      • [^] # Re: désolé ...

        Posté par  (site web personnel) . Évalué à 0.

        Mouais j'avoue ... en réalité, je n'édite jamais de code avec gedit, je suis un vim-iste.

        Je pense que prelink pourra te servir, car en fait, si tu as un système basé gnome, le temps de lancement doit être principalement dû au démarrage de la machinerie k* ...
        Je serai intéressé de voir ce que ça donne.

        Adhérer à l'April, ça vous tente ?

  • # Tps de lancement

    Posté par  (site web personnel) . Évalué à 4.

    1°) lance un kwrite que tu minimise (au besoin au chargement de ton desktop)... les libs seront déjà chargées, ça devrait être presque instantané.
    2°) vérifie que ton cache de polices est à jour (sudo fc-cache)... ça accélère considérablement le démarrage de la machine
    3°) utilise prelink (sudo prelink -av) afin d'accélérer le chargement des applications C++
    4°) Si 1 ne te vas pas et que 2 & 3 ne suffisent pas:
    * au démarrage de ton desktop, lance kdeinit
    * créé en raccourcis et lance "kdeinit_wrapper kwrite" au lieu de kwrite

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.