Reprise du message précédent :
Sachant que quand KDE sera débarrassé de HAL, il y aura forcément un autre soft qui en a besoin qui n'aura pas fini sa migration, je pense qu'on va garder HAL en couche de compatibilité pendant encore un moment.

Que des paquets en dépendent ne m'a pas empêché de le supprimer dès le passage à xorg-server 1.8. Ça fait juste des fonctionnalités en moins.

Il me semblait que VLC était pourtant encore très dépendant de HAL, à moins qu'une mise à jour ait corrigé le problème ?

Ou pas : http://www.archlinux.org/packages/extra/i686/vlc/

EDIT : Enfin suffit de voir la liste des paquets dépendant de HAL : http://www.archlinux.org/packages/extra/x86_64/hal/

Je l'ai compilé moi-même en désactivant HAL pendant quelques temps mais ce n'est plus nécessaire comme l'indique _Oni_.

OK, très bien. C'est plutôt une bonne chose.

 
S'il faut commencer à (dé)monter les clés USB en console ou lancer un script quand je veux mettre mon PC en veille, merci mais non merci. Les applis sont une chose, mais je ne veux pas d'un DE boiteux.

certaines personnes utilisent bien gnome...

Trop gros, passera pas

Pour les quelques secondes de plus que ça prend, ça ne me dérange pas, étant donné que je ne fais ces choses ( démonter et mettre en veille, udev s'occupe du montage automatique ) que rarement.

 
HUM HUM
 

 
Et ça n'est QUE les 2 dernières pages de ce thread...  
 
(désolé d'avoir mordu)

D'un autre côté, avec 50% des fonctionnalités absentes, il est normal qu'il y ait moins de bugs dans ton DE favori...
Et pour 4 des 5x où tu m'as cité, il n'y a aucun rapport avec KDE.

Salut, je viens de remarquer un problème que je n'avais pas il y a quelques jours ... je suis sous kde 4.4.3 (Mandriva 2010 spring).
 
Quand l'affichage composite est activé dans KDE, c'est nickel pour KDE, par contre, aucune autre application opengl ne s'exécute correctement (ex: glxgears). Le symptome, c'est que l'appli en question prend 100% du cpu, reste figée pendant environ 15 secondes, se défige une demi seconde, puis se refige 15 secondes à 100% cpu, et ainsi de suite ...
 
Dès que je désactive les "effets de bureau" de KDE, les autres applications redeviennent parfaitement fluide.
 
(carte nvidia + driver proprio 256.44)
 
Ca vous dit qqchose ce symptome ?
 
Edit:  bon apparemment ça le fait moins avec le 256.35 et le 195.36 .... la joie des drivers nvidia  

J'ai pas les symptômes que tu décris avec les 256.44.
D'un autre côté, il semble y avoir un problème de freeze de xorg avec cette version des drivers nvidia. J'ai personnellement subi 2 plantages suspects (modif hardware et kernel en parallèle donc impossible d'être catégorique) depuis que je les ai installés.

Et voila la 4.5.0 \o/

pas de mise à jour chez moi ... y'a un dépot à rajouter ? je suis toujours en KDE SC 4.5 RC 2

Dispo dans testing sous ArchLinux apparemment, les paquets KDE sont du 10. Je teste peut être ce soir.

dépôts Kubuntu à jour avec KDE 4.5 SC :
 

Supaïr, j'vais pouvoir recompiler la moitié de mon ppa à cause des changements -_-

on fais comment pour choisir webkit pour konqueror par defaut ?
 
rien trouvé :\

A l'époque où je compilais webkit, il fallait l'activer dans le menu "view -> view mode".

j'ai pas "view" ni "vue" dans konqueror  

essaie viou ?

Je viens d'installer KDE 4.5 sur Arch. Pour avoir WebKit dans Konqueror, il a fallu que j'installe également kwebkitpart, puis la sélection se fait dans Affichage -> Type d'affichage -> Webkit.

C'est quand même fou que le WebKit de KDE soit si en retard sur celui de Chromium. Il y a des choses moches ou mal gérées, je ne somprend pas que ça n'ait pas été corrigé. Je pense notamment aux textarea avec le curseur qui se fait la malle en dehors de la zone de saisie ou des trucs comme ça. C'est con, parce que le rendu est vraiment agréable, plus que sous FireFox par exemple, notamment les polices qui sont mieux lissées je trouve.

 
Je vois que ça n'a pas vraiment évolué depuis ~1an. Au point où en est konqueror, ils feraient aussi bien de le virer de kde.

C'est pas trop la faute de Konqueror je pense, plutôt celle de la version de WebKit utilisé dans le rendu de Konqueror. J'ai un peu du mal à comprendre la position de KDE là dessus, quand on sait la place centrale qu'occupe un navigateur dans un desktop aujourd'hui, "vendre" du KDE sans navigateur digne de ce nom, c'est difficilement défendable, surtout quand on voit les dépendances qu'entrainent l'installation de FireFox ou Chromium. Pour quelqu'un qui veut se faire un bureau full Qt, c'est un peu la mort.

Disons qu'il n'y a pas qu'au niveau web que konqueror est le parent pauvre. Même en mode gestion de fichiers, il n'est pas si bien maintenu que dolphin. Ce qui est normal puisque sa base d'utilisateur actuelle est bien moindre.
Mais sinon, je suis 100% d'accord avec toi. Il manque un vrai navigateur à KDE. Malheureusement, tous les grands acteurs du web ont choisi leur camps.

 
Kpart-webkit est bien installé mais toujours rien dans affichage  
 
edit: trouvé la réponse ici ... super simple    
 
http://ail.islibre.fr/2009/05/astu [...] konqueror/

Côté gestion de fichiers, Konqueror n'a plus vraiment à être maintenu, il est remplacé par Dolphin comme tu le dis, ce qui signifie qu'il n'y a plus vraiment d'intérêt à développer ce mode. A la rigueur, je pencherais plus vers un arrêt pur et simple de Konqueror tel qu'on le connais aujourd'hui, la production rapide et efficace d'applications indépendantes pour chaque tâche précise (Dolphin pour la gestion de fichiers, Rekonq ou autre pour la navigation Web, etc) et un Konqueror qui prenne la forme (au moins sur le fond, à voir ce que ça donnerait en pratique) de Kontact qui n'est finalement que l'agrégation (modulaire de surcroit, afin de laisser le plus de possibilité de configuration à l'utilisateur) de KMail, Korganizer, KadressBook, etc. Cela permettrait le développement rapide et simple d'applications légères et dédiées, l'intervention rapide et ciblée lors de la détection d'un bug ou l'ajout d'une fonctionnalité et la possibilité pour ceux qui aiment tout faire avec une seule application de rester dans le conteneur Konqueror quoi qu'ils fassent ou presque.

Peut être une piste de réflexion pour la 4.6 ?

KDE 4.5.0 dispo pour Mandriva 2010 Spring.
 
Mirroir français:
http://kde-mirror.freenux.org/stab [...] va/2010.1/
 
Je viens de faire la mise à jour, la différence visuelle avec le 4.4.3 n'est pas flagrante

Le thème a quand même bien changé, notamment pour les icônes en systray, et le panneau de systemsettings a été profondément remanié également. Les effets de transitions dans les fenêtres ont pris un bon coup de jeune aussi. Bref, sans être une révolution, l'apparence de ce KDE 4.5.0 s'est bien remis au goût du jour je trouve (en tout cas sur la version testing de Arch, je ne sais pas ce qu'à fait Mandriva là dessus).

Sous arch Le passage de kde@testing à kde@extra se fait bien kortex ?
J'ai vraiment pas envie de tout casser pour 2 jours à  attendre

J'en sais rien, ça je verrai dans 2 jours

Ce que je remarque pour le moment :
- pas de paquet kde-l10n-fr pour le moment, donc tout n'est pas tip top côté traduction, mais rien de bien grave.
- pas de composition au boot, je suis obligé de l'activer à chaque ouverture de session (Alt + Maj + F12 par défaut). Pas bien grave, mais un peu relou, à voir dans la version finale.
- avec la version Soprano de testing, je n'ai enfin plus de crash au lancement d'Akonadi, ça c'est cool.

bon je vais patienter alors

C'est-à-dire?
Une fois les paquets validés sur la testing, ils sont déplacés dans extra (ou core c'est selon mais pour KDE c'est extra), tu auras même pas besoin de les réinstaller…

Bon, j'ai franchi le pas en 4.5 (et j'avais dit que je le ferais pas avant 4.5.2 ).
La première réflexion que je me suis faite "tiens, le texte de la taskbar a été viré pour ne laisser que les icones, on se croirait sous win7"...

Et pour rebasculer sur extra j'ai juste à virer le dépot testing ?
Les paquets sont donc indépendant du repo ?

Une fois que tu as installé un paquet, il n'est associé à aucun dépôt en particulier.
La façon dont il sera upgradé dépend uniquement de l'ordre des dépôts dans ton pacman.conf : si tu as mis Testing en tête, il sera upgradé dès qu'une version plus récente est dans Testing, sinon ce sera avec Core/Extra.

Donc une bonne manière de mixer avec des paquets de Testing tout en restant sur une Arch non-Testing, c'est d'ajouter le dépôt Testing dans pacman.conf juste après Core et Extra, comme ça pacman ne te mettra jamais à jour avec des paquets de Testing, mais tu pourras toujours en installer manuellement

ok merci
 
J'aurai du aller voir un peu la doc désolé

Interessant cette méthode Par contre, pour installer spécifiquement un paquet de testing, il suffit de taper son nom et hop, ça le récupère depuis testing ou il y a une option à ajouter pour spécifier qu'on veut récupérer le truc depuis testing ?

Edit : on devrait peut être aborder ça sur le topic Arch non ?