Le grand absent de cette version est Kontact 4.5 qui devait arriver avec le portage de Akonadi, les développeurs ont préféré retarder la sortie afin d'éviter la perte de courriels importants. Il y a quand même quelques nouveautés comme l'intégration de Webkit, l'amélioration de la zone de notification ou, encore, la détermination d'itinéraire avec Marble. Nouveautés dans KDE Development Platform
- WebKit peut désormais être utilisé à la place de KHTML par les applications KDE tout en offrant autant d'intégration que KHTML.
- KHTML supporte les requêtes XPath.
- Un nouvel ordonnanceur HTTP (via le KIO HTTP) permet d'accélérer les requêtes concurrentes afin d'accélérer le temps de téléchargement total. Ceci permet à KHTML et WebKit de finir le rendu de la page plus vite.
- Les espaces de travail de Plasma peuvent être configurés par JavaScript, ceci permet aux administrateurs réseau de gérer plus facilement la configuration des postes de travail des utilisateurs.
- Un système de cache pour les applications, KSharedDataCache, a été introduit, il est dès à présent utilisé pour les icônes et montre un gain de temps sensible.
- Phonon, la bibliothèque multimedia, utilise optionnellement PulseAudio.
- Un binding pour Perl a été ajouté et la gestion de Ruby s'est nettement améliorée.
- Les API pour les applications utilisant KatePart ont été étendues pour offrir plus de fonctionnalités.
Nouveautés dans Plasma
- La zone de notification a été visuellement retravaillée, des icônes monochromes permettent plus de clarté et de consistance. Les indicateurs pour les opérations de longue durée sont maintenant directement intégrés au widget et l'affichage des notifications par catégorie et la mise en file ont été retravaillés. Les notifications des widget Plasma partagés sur le réseau peuvent être affichées comme les notification locales.
- KWin, le gestionnaire de fenêtre, peut désormais placer les fenêtre sur le bureau sans qu'elles se recouvrent en utilisant les algorithmes de tiling. Il est aussi possible de déplacer des fenêtre (écrites en Qt) en sélectionnant une zone vide de la fenêtre. Les performances des effets des fenêtres ont aussi été améliorées.
- Un gestionnaire d'activité a été introduit pour gérer les activités de Plasma. Les activités sont plus faciles à gérer et la séparation des activité en tâches différentes est plus évidente.
- Plasma Netbook la version de Plasma pour les petits écran continue de s'améliorer.
- Les calendriers japonnais, thaï et taiwanais sont désormais supportés.
- Les applications Plasma peuvent être utilisées comme applications à part entière via plasma-windowed.
- Les distributeurs et les administrateurs peuvent définir une blacklist d'effets visuels afin d'éviter ceux qui posent problème avec une configuration donnée.
Nouveautés dans KDE Applications
- Marble peut déterminer un itinéraire hors ligne en utilisant les données de OpenStreetMap et OpenRouteService.
- Parley a une nouvelle interface d'exercices et gère la conjugaison.
- La liste d'Adblock dans Konqueror peut être automatiquement mise à jour afin d'améliorer son efficacité.
- Gwenview garde désormais toutes les informations EXIF en cas de manipulation d'image.
Aller plus loin
- KDE (6 clics)
- L'annonce de la version 4.5 (7 clics)
- Les nouveautés de la plateforme KDE (4 clics)
- Les nouveautés du bureau Plasma (9 clics)
- Les nouveautés des applications (3 clics)
# Tant qu'on est dans KDE
Posté par Goffi (site web personnel, Mastodon) . Évalué à 10.
- Quanta Plus est sorti de sa léthargie et annonce son grand retour (pour 2011 ?): http://milianw.de/blog/quanta-gsoc-midterm-evaluation et http://milianw.de/blog/final-days-of-quanta-gsoc-2010
- La détection de visage arrive dans Digikam, et via une bibliothèque afin d'être utilisée dans d'autre projets: http://adityabhatt.wordpress.com/2010/08/10/digikam-gsoc-fac(...)
2 projets du GSoC
Dans les fonctionnalités annoncées depuis longtemps, j'aimerais beaucoup voir apparaître la détection de langage: https://bugs.kde.org/show_bug.cgi?id=66516
# Mise à jour sur Mandriva
Posté par gerard delafond . Évalué à -7.
J'ai fait pointer les dépôts pour mise à jour sur les rpm Mandriva.
Ça a mis à jour quelques centaines de paquets sans message d'erreur.
Depuis, le mode graphique ne démarre plus.
C'est normal, chef ? (c'est peut-être le nouveau KDE qui est en mode texte pur ?)
[^] # Re: Mise à jour sur Mandriva
Posté par phoenix (site web personnel) . Évalué à 3.
[^] # Re: Mise à jour sur Mandriva
Posté par Beurt . Évalué à 3.
http://forum.mandriva.com/viewtopic.php?t=130555
[^] # Re: Mise à jour sur Mandriva
Posté par alpha_one_x86 (site web personnel) . Évalué à 1.
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
[^] # Re: Mise à jour sur Mandriva
Posté par Grunt . Évalué à 10.
Surtout dans certains cas bien précis, non?
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Mise à jour sur Mandriva
Posté par Alexandre COLLIGNON (site web personnel) . Évalué à 1.
notamment sur certaine configuration.
Surtout dans certains cas bien précis, non?
A une certaine heure je crois
Alexandre COLLIGNON
[^] # Re: Mise à jour sur Mandriva
Posté par Neije . Évalué à 4.
Ce n'est pas parce que les choses sont difficiles que nous n'osons pas. C'est parce que nous n'osons pas qu'elles sont difficiles. - Sénéque
# Activités
Posté par mickabouille . Évalué à 2.
Maintenant, j'ai essayé (honnêtement) d'utiliser ça il y a quelque temps. La doc était plus que disparate, et les quelques manipulations que j'ai pu effectuer ne m'ont pas permis de déterminer ce qu'on peut en faire, comment le faire ni pourquoi.
Après, j'ai eu l'impression qu'il y avait un mélange dans ma tête entre ces activités, le bureau et l'écran. Comment je mélange tout ça ? Je suis en permanence en double écran avec 6 bureau, et j'ai l'impression que ça rajoute juste une couche virtuelle au dessus de tout ça.
Cela dit, ces essais sont assez anciens. Ca se trouve c'était le tout début et les choses n'étaient pas finies et la doc n'existait pas. Il y a des explications plus claires maintenant ?
[^] # Re: Activités
Posté par Albert_ . Évalué à 1.
[^] # Re: Activités
Posté par Gniarf . Évalué à 7.
ce qu'il y a de mignon avec KDE 4, c'est qu'on nous fait le coup à chaque sortie de KDE 4.n+1
[^] # Re: Activités
Posté par Albert_ . Évalué à 3.
[^] # Re: Activités
Posté par Gniarf . Évalué à 9.
[^] # Re: Activités
Posté par imr . Évalué à 4.
Quand tu ne sens plus la douleur, tu as l'impression que c'est enfin plaisant et tu cours l'écrire sur linuxfr.
Et là tu te prends un coup de Gniarf. A chaque sortie de KDE 4.n+1.
KDE Sado Cacahouette 4
Vous en redemanderez!
[^] # Re: Activités
Posté par Aurélien Bompard (site web personnel) . Évalué à 5.
C'est aussi la philosophie open-source "publier vite, publier souvent".
Pas choquant, quoi.
[^] # Re: Activités
Posté par cosmocat . Évalué à 3.
Je voyais plutôt l'utilisation des activités lorsqu'on n'a qu'un seul écran et qu'on fait plusieurs utilisations différentes de sa machine avec des besoins assez différents.
[^] # Re: Activités
Posté par cosmocat . Évalué à 7.
JDE, c'est l'implémentation en java de KDE?
[^] # Re: Activités
Posté par zebra3 . Évalué à 10.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Activités
Posté par mekare . Évalué à 2.
[^] # Re: Activités
Posté par Maclag . Évalué à 4.
Mais rassurez-vous, tout va bientôt s'arranger:
La prochaine version de KDE par Mandriva sera plutôt écrite en Lisp.
Donc, bientôt, une Mandriva Emacs adaptée aux débutants grâce à son plugin KDE! \o/
[^] # Re: Activités
Posté par Gniarf . Évalué à 2.
hop merci de rien \o/
[^] # Re: Activités
Posté par mickabouille . Évalué à 1.
Quand je parle des écrans, c'est parce que la seule chose que je sois arrivé à faire avec les activités, c'est mettre un fond d'écran différent sur les bureaux :)
Pour JDE4 : hé oh, ça va hein !
[^] # Re: Activités
Posté par Albert_ . Évalué à 2.
# rekonq vs Konqueror-Webkit ?
Posté par reno . Évalué à 3.
Y a t'il une association 'flexible' entre les onglets et les processus comme Chrome le permet (plusieurs possibilités: un processus par onglet, par site web, pour tous les sites, etc.)?
[^] # Re: rekonq vs Konqueror-Webkit ?
Posté par Adrien BUSTANY (site web personnel) . Évalué à 2.
[^] # Re: rekonq vs Konqueror-Webkit ?
Posté par Yakulu . Évalué à 2.
[^] # Re: rekonq vs Konqueror-Webkit ?
Posté par zebra3 . Évalué à 3.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: rekonq vs Konqueror-Webkit ?
Posté par ZeroHeure . Évalué à 4.
partager les librairies KDE permet d'avoir les même signets, le même historique, le même portefeuille de mots de passe, etc.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
# kdepim non inclu
Posté par moi1392 . Évalué à 2.
La raison principale est le portage de kmail vers akonadi, qui est à l'heure actuelle encore assez expérimental (j'en ai une version compilée depuis les sources, et même pour juste rapporter des bugs, c'est très limite)
D'après l'avis personnel que je me fait de cette version, je serais assez surpris si une version stable de kmail 2 sortait avant kde 4.6
Mais en tout cas pour l'instant, la suite kdepim de kde 4.4 est parfaitement utilisable, et elle a même reçu quelques corrections de bogues.
[^] # Re: kdepim non inclu
Posté par zebra3 . Évalué à 1.
C'est dommage, Akonadi devait être un des piliers de KDE en tant que bureau sémantique.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: kdepim non inclu
Posté par Pinaraf . Évalué à 2.
[^] # Re: kdepim non inclu
Posté par moi1392 . Évalué à 4.
Le portage en lui même à finalement commencé un peu avant la sortie de kde 4.4 mais n'est pas complet/fonctionnel/utilisable à ce jour. Donc l'équipe kdepim à décidé de ne pas inclure kdepim 4.5 avec kde sc 4.5
C'est vrai que c'est dommage que ce soit si long, surtout que pour la première version, à mon avis, on se rendra surtout compte des régressions en terme de fonctionnalité, d'ergonomie et de performances par rapport à la version sans akonadi, et ça va râler.
Mais je pense que l'architecture globale de akonadi est un pas dans la bonne direction et qu'une fois bien stabilisé, le développement pourra reprendre de plus belle pour corriger les lacunes et améliorer des tas de choses qu'il était très difficile de faire avant :)
[^] # Re: kdepim non inclu
Posté par wismerhill . Évalué à 2.
[^] # Re: kdepim non inclu
Posté par zebra3 . Évalué à 2.
Néanmoins, la PIM fait partie du bureau sémantique, et Nepomuk aura besoin de piocher dans les informations d'Akonadi pour faire une partie de son boulot. Donc ça reste un pan encore manquant.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: kdepim non inclu
Posté par mickabouille . Évalué à 5.
Quand j'ai vu qu'il fallait un mysql installé (et e exécution) pour lire ses mails, hop poubelle.
Y a pas besoin d'un SGBD pour stocker des mails, enfin !
C'est dommage, j'aimais bien kmail...
[^] # Re: kdepim non inclu
Posté par moi1392 . Évalué à 10.
Les développeurs de kmail (ou plutôt d'akonadi) ont décidé (à tord ou à raison, ça peut se discuter) que les concepteurs et développeurs d'un SGBD sont mieux placés pour fournir une solution plus efficace pour stocker et gérer les mails et informations associés sur disque que des développeurs de logiciels quelconques.
Maintenant je ne vois pas en quoi le fait que kmail ait besoin de mysql le rende moins bien, tu ne sais absolument pas ce que mysql rempli comme besoins dans kmail, il pourrait très bien remplacer du code qui était plus volumineux, moins performant et plus bogué mais directement inclus dans kmail, et du coup tu ne t'en rendais pas compte.
Teste le toi même et vois la différence, et après tu pourras venir te plaindre chiffres et expérience personnelle à l'appuis de ce qui ne te conviens pas.
PS: actuellement, au niveau des performances c'est effectivement moins bon qu'en 4.4, mais mysql ne semble pas être le fautif, et j'ai vu plusieurs mail des développeurs qui en parlaient et qui annoncent qu'ils vont bosser pour améliorer ça.
[^] # Re: kdepim non inclu
Posté par Gniarf . Évalué à 3.
tout dépend de ta volumétrie de mails donc de tes usages, je suppose.
[^] # Re: kdepim non inclu
Posté par phoenix (site web personnel) . Évalué à 7.
[^] # Re: kdepim non inclu
Posté par ZeroHeure . Évalué à 5.
Il y a une grande confusion dans les commentaires là. Voilà une explication pour tout le monde:
Akonadi n'est pas un agent de stockage pour vos courriels, vos carnets d'adresse, vos agendas, etc. C'est un cache. Ils s'occupe de récupérer (ou d'envoyer) les informations et méta-informations, que ce soit sur le grand Ternet ou dans votre disque dur, ensuite il les met en cache dans sa base de données (mySQL ou postgreSQL actuellement) pour en faciliter l'accès aux applications.
Cette structure permet des accès concurrents (plusieurs application sur les mêmes données). Elle permet aussi à l'application de s'affranchir de la gestion des données, c'est ainsi que la première version fonctionnelle de Mailody a été écrite en 10 minutes.
Enfin le couplet sur la base de données me fait un peu rigoler: on s'énerve tous dès qu'une appli a besoin d'une ressource supplémentaire, mais dites... il y a écrit quoi sur nos babasses? GHz ou MHz? Ram en Mo ou en Go? RPM HD ca commence par 1xxx, 4xxx ou 7xxx (ou plus)? En plus Akonadi utilise un mySQL minimal (ou pas si on veut). Et puis il faut bien que les développeurs s'amusent.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: kdepim non inclu
Posté par ZeroHeure . Évalué à 3.
vous pouvez donc toujours stocker vos données en mbox, maildir, ldap, vcard, etc.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: kdepim non inclu
Posté par Bastien Mourgues . Évalué à 7.
Un SGBD nécessite une part d'administration qu'un utilisateur de base ne saura jamais faire (pour rester constant et optimal en terme de perf) ; mais vu la quantité de données à manipuler (relativement nulle vu les capacités du programme), on peut aussi se poser la question de la pertinence de son utilisation.
Pour enchaîner sur le chapitre des ressources, quitte à faire mon dinosaure, mon pc fixe à la maison est un pentium II 266MHz, avec 600 Mo de RAM. Le disque dur est un vieil IDE , je n'ai pas les RPM en tête, mais ce n'est pas un foudre de guerre.
Linux tourne dessus depuis plus de 10 ans. Le passage à KDE 3.5 n'a pas été un problème. J'ai même été surpris de voir que ça ne tournait pas trop mal.
Je serais peut être surpris, lors du passage à KDE 4.x, de voir que tout reste réactif, mais je me pose des questions. C'est bien que les développeurs "s'amusent" comme tu dis, espérons que cela ne se fasse pas au détriment de leur produit ....
Bon, comme on est vendredi, pour finir, je me contenterai d'un : c'était mieux avant ! :)
[^] # Re: kdepim non inclu
Posté par ZeroHeure . Évalué à 6.
Sur ta bécane, qui a 12 ou 13 ans, oui c'est assez puissant pour kde3 (j'en ai une avec 128 Mo de Ram, avec un noyau linux 2.4 c'est très rapide), mais pour le reste? les vidéos, flash, les sons, les jeux récents, les pages web (et dieu sait si ça bouffe de plus en plus!), la reconnaissance faciale, la virtualisation, ... enfin tous ces trucs hype qui nous empêchent de bosser mais qui plaisent à nos femmes. Et même dans les trucs pour bosser: OpenOffice.org 3, SugarCRM, etc. je ne pense pas que ça tourne bien dessus.
Et puis rappelle-toi la sortie de Win95, on trouvait normal que ça ne tourne pas sur des XT, ni des 286 (et même les 386 il fallait de la patience).
Et enfin, c'est vrai c'est un peu ridicule cette course à l'échalotte, mais d'un autre côté on ne peut pas se plaindre de l'omniprésence de Windows et MacOSX sans proposer d'équivalent, et ça ça bouffe de la puissance.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: kdepim non inclu
Posté par lolop (site web personnel) . Évalué à 8.
Même les machines légères de maintenant sont plus puissantes, même les téléphones portables ont plus de mémoire.
Pour le dinosaure, il ferait un bon terminal X.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: kdepim non inclu
Posté par Psychofox (Mastodon) . Évalué à 3.
KDE 4 rame, même sur une machine légère de maintenant. C'est ça le problème.
J'ai un ion 330 (processeur atom, 2GB de ram, carte graphique nvidia) et kde4 est franchement inutilisable : très lent et peu réactif (même en activant le preset "machine peu puissante, grand écran", avec pleins de petits bugs d'affichage (j'utilise le driver "nouveau"). A côté gnome est une fusée.
[^] # Re: kdepim non inclu
Posté par wismerhill . Évalué à 2.
Sur une carte nvidia, si tu n'utilise pas le driver propriétaire il vaut mieux configurer son bureau "à l'ancienne" avec des fenêtres qui se redessinnent à l'écran sans passer par des buffer opengl.
[^] # Re: kdepim non inclu
Posté par whity . Évalué à 1.
C'est un peu le même ressenti que Vista : tout est lent, tout lagge. Ca ne ramait pas vraiment, mais c'était juste un peu trop lent pour être confortable. En revanche, sur mon pc de salon (pentium dual core 2.4Ghz etcarte graphique intel), c'est suffisamment confortable.
Je confirme que gnome est une fusée comparativement, sur les deux machines où j'ai fait le test.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: kdepim non inclu
Posté par moi1392 . Évalué à 4.
l'objectif de KDE est, entre autre, de proposer un environnement de bureau avec une suite logicielle cohérente, aux fonctionnalités avancées et fonctionnant sur du matériel résonnablement moderne.
L'objectif était le même avec kde3, sauf qu'à l'époque, ton matos était raisonnablement moderne, ce n'est plus le cas aujourd'hui.
Je pense que demander comme matériel raisonnablement moderne une machine de moins de 6 ans n'est pas abusif, surtout que ce n'est pas le seul environnement de bureau libre et qu'ils n'ont pas sur les épaule le fardeau d'avoir à combler les besoins et envies en terme d'environnement de travail de tous les utilisateurs de logiciels libres.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: kdepim non inclu
Posté par Larry Cow . Évalué à 4.
Oui, enfin ça impose un peu d'avoir un daemon qui tourne juste pour gérer tes mails. Même pas, d'ailleurs, juste pour gérer le _stockage_ de tes mails (sinon y'avait déjà le MailDaemon[Replacement] de BeOS/Haiku qui faisait la même). Ce n'est pas exactement anodin, si?
Ca peut être une bonne idée, mais ça devrait être débrayable : le mec qui lit une pauvre boîte IMAP de 10Mo, on ne devrait pas lui imposer une telle usine à gaz.
[^] # Re: kdepim non inclu
Posté par Albert_ . Évalué à -1.
[^] # Re: kdepim non inclu
Posté par Pinaraf . Évalué à 1.
Il faudrait que des efforts soient faits pour pouvoir rebasculer sur SQLite au lieu de MySQL, mais les performances de SQLite pour Akonadi sont... pas terribles on va dire... Une autre solution serait d'utiliser mysql embedded peut être ?
Mais il vaut mieux reprendre un serveur existant plutôt que de recoder soi-même tout le système d'indexation notamment, non ?
[^] # Re: kdepim non inclu
Posté par Larry Cow . Évalué à 3.
Je crois que ça avait été tenté et abandonné, le MySQLe. Enfin de toutes manières, avec les doutes qui planent actuellement sur l'avenir de MySQL, ça serait probablement une bonne idée d'avoir un plan B.
Mais il vaut mieux reprendre un serveur existant plutôt que de recoder soi-même tout le système d'indexation notamment, non ?
Ne pas réinventer la roue, c'est bien. C'est très bien, même. Mais réutiliser un parpaing comme roue pour éviter de la réinventer, c'est stupide. Même si c'est un très très bon parpaing. Même si on l'a rogné pour le rendre "presque rond".
[^] # Re: kdepim non inclu
Posté par whity . Évalué à 3.
akonadi est peut-être très bien pour stocker son carnet d'adresse, mais pour les mails, ça me semble hautement inadapté à mon cas d'utilisation (que je n'estime pas spécialement exotique).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: kdepim non inclu
Posté par moi1392 . Évalué à 4.
Et ensuite, il ne sert pas qu'à les fournir à kmail, mais ou tout autre client pim à qui tu en autorise l'accès.
Ça permet d'avoir une base de données centralisée (et non redondante entre applis) de tes infos personnelles avec une interface d'accès uniforme et concurrente (ça se dit ça ?)
[^] # Re: kdepim non inclu
Posté par whity . Évalué à 3.
Pour résumer, j'attendais beaucoup d'akonadi : j'ai testé et tout ce que j'ai constaté, c'est qu'il n'y a AUCUN bénéfice utilisateur à l'utilisation d'akonadi, que ça ne me permettait toujours pas d'avoir un calendrier ou un carnet d'adresses partagé, etc). C'est peut-être lié à l'implémentation foireuse plus qu'au modèle lui-même, mais en l'état ça ne me satisfait pas (surtout sur mon eeepc où je ne souhaite pas de cache local).
Pour résumer, en tant qu'utilisateur, je ne vois aucun bénéfice à akonadi. En tant que développeur, je ne vois pas le bénéfice d'avoir un *serveur* akonadi par rapport à une API d'accès aux données. J'ai l'impression que les dev kde se sont bien plantés sur ce coup là.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: kdepim non inclu
Posté par moi1392 . Évalué à 2.
Ensuite les requêtes vers akonadi sont faites via DBus et seulement lui il me semble, or DBus peut fonctionner sur un réseau, donc il n'y a pas de limitation technique qui empecherait akonadi de tourner sur une machine et des clients de 4 machines différentes d'y accéder. (il faut bien sur que les clients puissent faire une connexion DBus réseau et que akonadi écoute le réseau pour des requêtes DBus, ce qui n'est pas le cas actuellement)
En tant qu'utilisateur, un des intérêts est d'avoir tes infos centralisées quel que soit le logiciel que tu utilises, tu n'as toujours qu'un seul endroit à changer, à configurer, à mettre à jour pour que tous les logiciels qui ont besoin de cette info l'aient à disposition.
En tant que développeur, tu n'as pas à coder la partie base de données et requêtes sur les informations, en plus tu n'as aucun problème d'accès concurrent aux fichiers de ressources qu'il est très difficile de résoudre en bossant appli par appli. Tu peux écrire une appli qui vérifie si tu as de nouveau mails et t'affiche le sujet, un lien vers d'éventuelles pièces jointes et un lien vers le contact de messagerie instantané correspondant à l'envoyeur s'il est connecté; le tout très rapidement et avec très peu de code.
[^] # Re: kdepim non inclu
Posté par moi1392 . Évalué à 1.
"je ne vois pas le bénéfice d'avoir un *serveur* akonadi par rapport à une API d'accès aux données."
Le fait que ce soit un serveur n'empêche en aucun cas d'avoir une API "à la KDE" pour y accéder. Tu ne fais pas des requêtes toi même sur le réseau via DBus (ou sans...) mais tu utilises libakonadi qui est une abstraction de haut niveau au protocole de communication.
[^] # Re: kdepim non inclu
Posté par whity . Évalué à 1.
Pour le stockage centralisé des contacts, j'ai l'impression qu'il faut plus une norme et une lib qu'un serveur.
En soi, je n'ai toujours pas compris ce que fait akonadi (en tant que serveur) qui ne saurait être fait par une lib et une api correspondante. Je suis peut-être passé à côté de quelque chose, mais je sèche pour trouver des arguments (et je pense vraiment que le temps investi l'aurait été beaucoup mieux pour une gestion correcte de l'imap).
Sinon, il y a une norme maintenant pour dbus sur le réseau ? Les dernières fois que j'avais regardé, c'était toujours "oui oui, c'est possible, mais personne n'a encore fait le boulot".
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: kdepim non inclu
Posté par moi1392 . Évalué à 1.
Pour DBus sur le réseau, il me semble que ça a toujours fonctionné, il y a de sévères limitations (entre autre l'impossibilité d'identifier avec certitude l'id de l'utilisateur faisant la requête, ce qui parait normal, et aussi des problèmes de performance) mais DBus en lui même dialogue par dessus une socket de type unix, qui a strictement (à part pour l'id utilisateur donc) la même api et le même fonctionnement qu'une socket tcp. Et il me semble que le code qui ouvre la socket en TCP au lieu d'UNIX est déjà dans DBus depuis la 1.0
[^] # Re: kdepim non inclu
Posté par whity . Évalué à 1.
On pourrait effectivement parler de performances, de cache, mais pour ça, il faudrait que kde4 soit performant. Là, c'est une catastrophe, il ne tourne pas correctement sur mon eeepc701 (pas la faute d'akonadi, mais là aussi les ressources seraient sûrement mieux exploitées ailleurs). Et puis, monter une usine à gaz pour charger 300 contacts, je suis pas convaincu. Par contre, sotcker chaque mail que je consulte via imap dans une base de données, je suis sûr que ça plombe les perfs.
Non, je crois vraiment qu'aknoadi est l'un des pires choix qu'ait fait kde4. Sur le papier, ça avait l'air joli, dans les faits, ça ne marche pas. C'est dommage, parce qu'il y a eu beaucoup d'investissement dessus et que ça me laisse vraiment l'impression d'un beau gâchis.
Sinon, dbus sur le réseau, le gros facteur limitant est l'absence d'authentification.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: kdepim non inclu
Posté par moi1392 . Évalué à 3.
"On pourrait effectivement parler de performances, de cache, mais pour ça, il faudrait que kde4 soit performant."
tu disais te poser cette question "très sérieusement" Que viens faire cette insulte gratuite qui n'apporte rien là dedans ?
1) les performances de kde sont moins bonnes que celles de kde3, mais elles ne sont pas "catastrophiques"
2) les problèmes de performances sur certains problèmes n'empêchent en rien le fait de vouloir les régler sur d'autres.
3) les optimisations de code et d'algo ne suffisent pas toujours à améliorer les performances, on fini par atteindre les limites de ce qui peut être fait à un moment, et si on veut faire mieux, la seule façon est d'essayer une autre voie.
"Et puis, monter une usine à gaz pour charger 300 contacts, je suis pas convaincu. Par contre, stocker chaque mail que je consulte via imap dans une base de données, je suis sûr que ça plombe les perfs."
akonadi, c'est pas pour stocker 300 contacts, je pense que même les développeurs KDE savent que pour ça, on a pas besoin d'un système de gestion des données personnelles centralisées qui utilise un SGBD.
Ensuite, tu as beau être "sûr que ça plombe les perfs" ça reste de la théorie de comptoire, et en matière d'optimisation, il n'y a qu'une seule règle absolue, tester !
Tu vas toujours trouver que dans ton super cas à toi avec 3 mail et 1 date dans ton calendrier, les perfs sont plombées, mais si ça prends 0.003 secondes au lieu de 0.000001 secondes, c'est pas la mort. Par contre, le type qui a vraiment une grosse base de mails, de contacts, de calendriers et tout, il sera content d'avoir un truc plus réactif.
De ton coté, si tu ne peux pas patienter ces 0.002999 secondes supplémentaires, tu peux toujours utilser mutt, il lira et fera des recherches dans tes 1 mail super rapidement et sans plomber aucune perf !
"Non, je crois vraiment qu'aknoadi est l'un des pires choix qu'ait fait kde4. Sur le papier, ça avait l'air joli, dans les faits, ça ne marche pas."
Moi j'appelle ça un bon choix, plombé par des problèmes techniques et des retards d'implémentation.
Je suis le premier frustré de l'avancement d'akonadi, j'aurai aimé (et je pensais, à la sortie de kde 4.0) en être au point actuel dans la version 4.2 de KDE, finalement, c'est beaucoup plus long que prévu, mais les choses avancent, et je ne doute toujours pas des avantages technologique de ce choix par rapport aux autres, comme je ne doutais pas du potentiel de kde 4 avant la sortie de la 4.0, et il n'y a qu'a voir la vitesse à laquelle les développeurs arrivent à faire avancer les choses à chaque version pour s'en convaincre. ça a été long, mais maintenant, chaque version, en plus d'ajouter son lot de régressions, viens avec ses améliorations en terme de performance et consomation, d'ergonomie, de fonctionnalités et de nouveau outils et logiciels.
[^] # Re: kdepim non inclu
Posté par wismerhill . Évalué à 2.
Hou, le vilain lapsus ;-)
[^] # Re: kdepim non inclu
Posté par whity . Évalué à 3.
Ca tombe bien, j'ai testé, c'est juste super lent akonadi pour les mails.
[cite>Tu vas toujours trouver que dans ton super cas à toi avec 3 mail et 1 date dans ton calendrier, les perfs sont plombées, mais si ça prends 0.003 secondes au lieu de 0.000001 secondes, c'est pas la mort. Par contre, le type qui a vraiment une grosse base de mails, de contacts, de calendriers et tout, il sera content d'avoir un truc plus réactif.
Ca tombe bien aussi, j'ai 2.8Go de mails, en 115.000 messages environ (stats faites à la vavite au du et find sur le répertoire Maildir). Peut-être qu'akonadi marche pour tes 200 messages reçus via pop, mais pour moi, ça ne marche pas.
Moi j'appelle ça un bon choix, plombé par des problèmes techniques et des retards d'implémentation.
C'est peut-être simplement l'implémentation qui fait qu'en l'état, ça ne marche pas. Mais j'ai quand même de gros doutes sur la validité du modèle dans l'ensemble.
Sinon, pour les perfs de kde4, elles sont juste insuffisantes pour qu'il soit utilisable sur un eeepc701 (malgré 2Go de ram, c'est donc bien un problème de cpu). Pas grave que ça soit pas la cible, mais pour moi, ça signifie que si on se préoccuppe des perfs, il y a sûrement plus urgent à faire que d'optimiser l'accès aux 200 contacts personnels stockés dans un fichier/dossier (les carnets d'adresse d'entreprise, ils sont déjà dans du ldap ou une bdd).
3) les optimisations de code et d'algo ne suffisent pas toujours à améliorer les performances, on fini par atteindre les limites de ce qui peut être fait à un moment, et si on veut faire mieux, la seule façon est d'essayer une autre voie.
Comme virer akonadi ;). Non, plus sérieusement, tant mieux si les dev réussissent à faire marcher akonadi correctement, kde a besoin d'un pim qui marche. Mais juste "avoir un truc qui marche" ne suffira pas à me convaincre que les ressources mises sur akonadi ne l'auraient pas été mieux ailleurs.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: kdepim non inclu
Posté par gnumdk (site web personnel) . Évalué à 4.
Avec un proc de merde (P3) et un bon disque, kde4 tourne correctement
[^] # Re: kdepim non inclu
Posté par whity . Évalué à 1.
Intéressant. Tu as des sources là dessus ? (notamment, sur pourquoi kde solliciterait autant le disque dur et les remèdes à y apporter). Je précise que j'avais désactivé l'indexation et nepomuk, qui sont donc hors de cause.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: kdepim non inclu
Posté par gnumdk (site web personnel) . Évalué à 4.
Sinon, pour la partie processeur, désactiver oxygen et ses gradients est une bonne idée aussi...
[^] # Re: kdepim non inclu
Posté par bubar🦥 (Mastodon) . Évalué à 2.
Ha bon ?
>(les carnets d'adresse d'entreprise, ils sont déjà dans du ldap ou une bdd
Et pour les particuliers, ils sont certainement nombreux a avoir déjà leur carnet d'adresse soit chez leur F.A.I. soit chez MSn ou encore Gmail... voir Facebook... Donc, bon, comment dire... une suite "pim" lourde locale... est ce encore bien utile ? Dans quel cas ? Pas la majorité des entreprises semble t il, ni la majorité des utilisateurs.
Dans synchronisation il y a accès.
Puisqu'accès est nécessaire, celui ci est plus important.
Pourquoi alors synchroniser puisqu'on peux accéder ? Pourquoi faire de tels échanges de données lorsque l'accès seul rend lui même le même service ?
Bref la "synchronisation" c'était l'ancien temps... Les accès se sont tellement diversifiés et multipliés (qu'un simple 'google gears like' suffit)
[^] # Re: kdepim non inclu
Posté par Larry Cow . Évalué à 2.
Il peut, mais pas dans Akonadi, apparemment (alors que ça aurait été un bon compromis) :
Why not use MySQL/Embedded?
We tried that as well, there are two reasons for not using it: No support for the InnoDB engine (which we need for transaction support) and poor availability (only OpenSUSE provided usable packages, needed a patched QSQL driver).
http://techbase.kde.org/Projects/PIM/Akonadi#Why_not_use_MyS(...)
[^] # Re: kdepim non inclu
Posté par gnumdk (site web personnel) . Évalué à 2.
>kde4.
C'est vrai que avoir un kmail vraiment stable en IMAP, c'est un très mauvais choix...
Puis, pour ton histoire de serveur, y'a la même chose sous Gnome (en peut etre plus limité) avec evolution-data-server ...
Donc bon, j'ai plus confiance en les devs de gnome et kde qu'en toi ;)
Et de ce que j'ai testé de kmail/akonadi, c'était instable mais largement plus rapide que le kmail monolithique actuel.
[^] # Re: kdepim non inclu
Posté par Albert_ . Évalué à 1.
De ce que j'ai teste c'est l'inverse, il fallait bien 5 minutes pour qu'il affiche le moindre email (imap avec copie local) et la verification des nouveaux emails ne fonctionnait pas mais bon lorsque cela sera un peu plus stabilise je retesterai. Par contre j'espere vraiment qu'il y aura la possibilite d'avoir les deux versions en parallel...
[^] # Re: kdepim non inclu
Posté par whity . Évalué à 1.
C'est clair qu'il fallait monter akonadi pour refaire l'imap de kmail (qui n'est toujours pas un bon client imap, si tu veux une idée de ce qu'est une bonne architecture pour un client imap, regarde du côté de trojita, malheureusement pas encore assez avancé pour être utilisable).
[quote]Puis, pour ton histoire de serveur, y'a la même chose sous Gnome (en peut etre plus limité) avec evolution-data-server ...[/quote]
evolution-data-server est une couche d'abstraction sur divers backend, un composant corba à utiliser par les applications. Du coup je vois pas trop la différence avec ce que j'ai décrit.
[quote]Et de ce que j'ai testé de kmail/akonadi, c'était instable mais largement plus rapide que le kmail monolithique actuel.[/quote]
Il fallait refaire kmail, ça c'est une évidence. Mais le choix d'akonadi, vraiment, sur le papier ça avait l'air joli, dans les faits, ça ne marche toujours pas correctement.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: kdepim non inclu
Posté par Albert_ . Évalué à 2.
[^] # Re: kdepim non inclu
Posté par Ph Husson (site web personnel) . Évalué à 4.
Je me demande bien pourquoi il ne l'ont toujours pas sorti dit donc !
# Vers où va KDE ?
Posté par zebra3 . Évalué à 6.
L'équipe de KDE continue de travailler sur plein de sujets excitants, mais pour les problèmes de base ou les attentes des utilisateurs, rien n'est encore fait.
Par exemple, KDE ne dispose pas d'un lecteur vidéo digne de ce nom. Je trouve que Dragon Player, pourtant lecteur officiel, jure au milieu des autres applications KDE qui regorgent de fonctions en tout genre. Son support des sous-titres est minimal, il n'est pas capable de me donner des infos sur ce qu'il lit, ne sait pas se mettre à la taille d'une vidéo, ne supporte pas UPNP et, bien plus gênant, n'est pas du tout utilisable en réseau.
Par exemple, quand je veux regarder sur mon netbook mes vidéos hébergée sur mon serveur en passant par SFTP, ce boulet veut d'abord me les copier dans /tmp. C'est très pénalisant vu que les vidéos pèsent 300 Mo et que je le fais via le WiFi... Alors qu'avec Totem et Nautilus, aucun problème pour lancer la lecture et me balader dedans !
Et Kaffeine n'est pas beaucoup mieux. À l'origine, il devait être basé sur Phonon mais reste finalement sur Xine et doit donc rester sur ses limitations. Sur Debian avec la dernière version de Xine, toujours pas de VP8... Quand à l'interface qui demande au minimum une fenêtre de 1000×500, c'est pas terrible sur un netbook... La faute à des boutons mal conçus alignés en largeur. Et en plus, je n'arrive même pas à le faire lire des fichiers par SFTP...
Quand aux autres applis, j'ai l'impression que Konqueror, pourtant l'appli phare de la 3.x, est complètement laissé à l'abandon, remplacé par Dolphin et reKonq qui en font moins.
L'équipe semble tiraillée entre le besoin de faire des trucs simples et ergonomiques, et celui de faire des trucs très puissants. Le problème, c'est que le mélange ne donne pas quelque chose de cohérent, et comme il n'y a pas assez de dev, elle ne peut pas tout faire.
C'est dommage, j'aimais bien la 3.5 qui avait une large avance sur tout ce qui se faisait (y compris propriétaire), mais j'ai maintenant l'impression qu'avec la 4, le bureau ne sait plus trop vers où se diriger. Du coup, il s'est fait doublé par GNOME, qui avec Dbus, Gstreamer, Telepathy ou GVFS a réussi à se mettre à niveau. Il n'y a plus qu'Evolution qui aurait besoin d'un travail de fond. J'ai du mal à voir en KDE une vitrine technologique comme avant...
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Vers où va KDE ?
Posté par Craftyman . Évalué à 3.
[^] # Re: Vers où va KDE ?
Posté par zebra3 . Évalué à 2.
D'ailleurs, KDE 4 devait apporter Decibel, un nouveau framework pour ce qui tourne autour de la messagerie instantanée et Kopete devait se baser dessus.
Pour finir, on n'a plus de nouvelles.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Vers où va KDE ?
Posté par moi1392 . Évalué à 2.
les dev de kopete souhaitent migrer vers télépathy, mais manque de dev, de temps, toussa...
[^] # Re: Vers où va KDE ?
Posté par ftp . Évalué à -6.
Et, plus sérieusement, quand on en est à corriger 16.000 bugs dans une release mineure, on est en droit de se poser des questions. Il y avait un bug toutes les 40 lignes ou bien ?
Toutes vérifications faites, je suis définitivement une mauvaise langue, ce dont je tiens à m'excuser ici publiquement. Les 16.000 bugs corrigés sont vraiment bien corrigés:
- 15.999 applications buggées en mousse (style Kaffeine, K-machin qui gère mal le wifi, K-s'tête chinois...) virées
- le 16.000ème: remplacement de kdm par gdm dans le startup.sh
Oui, encore une fois, modestement, et comme disait l'amie Ségolène: pardon !
[^] # Re: Vers où va KDE ?
Posté par patrick_g (site web personnel) . Évalué à 4.
Cf cette discussion: http://lwn.net/Articles/399523/
En gros il regardent juste le nombre de bugs fermés entre deux dates (la release 4.4 et la release 4.5 par exemple).
Si un même bug est ouvert 250 fois en doublon car il impacte beaucoup de monde et bien une seule correction du code permettra d'annoncer fièrement qu'on a corrigé 250 bugs !
[^] # Re: Vers où va KDE ?
Posté par reno . Évalué à 8.
Uniquement dans *ton* interprétation!
Le bug dupliqué quelqu'un a bien dut bosser pour vérifier qu'il était un dupliqué et le fermer, non?
C'est aussi du travail donc je trouve normal de le compter parmi le boulot fournit par les contributeurs a KDE, tout comme les traductions, la documentation, etc.
Après il serait bien d'avoir aussi le nombre de bug corrigé par une modification de code, c'est une autre mesure du travail accompli, mais l'un ne remplace pas l'autre!
[^] # Re: Vers où va KDE ?
Posté par patrick_g (site web personnel) . Évalué à 6.
Quand on annonce que 16 000 bugs ont été corrigés cela devrait vouloir dire que 16 000 dysfonctionnements ont réellement été corrigées dans KDE. Sinon cela perd tout son sens.
Bien entendu que vérifier les doublons c'est du boulot, mais cela ne corrige pas un dysfonctionnement dans KDE !
Sinon ils peuvent aussi dire que 16 000 trous ont été creusés puis rebouchés. C'est assurément un sacré travail que de creuser et de reboucher autant de trous mais je en vois pas en quoi cela améliore directement KDE.
Je ne dénigre pas du tout le boulot des devs de KDE. Je dis juste qu'ils feraient mieux de laisser tomber cette mesure des bugs fermés car elle est absurde.
[^] # Re: Vers où va KDE ?
Posté par claudex . Évalué à 2.
C'est une mesure qui a le mérite d'être très simple et de ne pas demander de travail supplémentaire, il suffit juste de faire une soustraction.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Vers où va KDE ?
Posté par reno . Évalué à 3.
C'est un raccourci plutôt malheureux, oui.
Après rapporter ce chiffre ne me choque pas, il est une mesure (parmi d'autre) de l'effort fourni.
[^] # Re: Vers où va KDE ?
Posté par patrick_g (site web personnel) . Évalué à 6.
Y'a SMPlayer qui est bourré de fonctions et qui est écrit avec Qt: http://smplayer.sourceforge.net/
Certes Qt ce n'est pas KDE mais bon...au moins l'intégration est meilleure qu'avec un soft GTK.
[^] # Re: Vers où va KDE ?
Posté par vincent_k (site web personnel) . Évalué à -1.
[^] # Re: Vers où va KDE ?
Posté par mickabouille . Évalué à 2.
(Non, j'ai rien trouvé de pertinent sur un moteur de recherche)
[^] # Re: Vers où va KDE ?
Posté par Florian.J . Évalué à 4.
Pour Dolphin, je le trouve à l'usage bien plus agréable à utiliser que konqueror (y compris dans la branche 3.x), c'est vrai que lors de la sortie de KDE 4.0 il était largement en retard, mais personnellement je peux plus m'en passer, je ne me sers plus de konqueror, y compris pour la navigation web (firefox).
Personnellement je trouve que KDE est actuellement l'environnement graphique le plus avancé, bien que je ne l'utilise pas (mais je me sers de la plupart de leurs applications).
Si un logiciel n'est pas directement fournit par KDE rien n'empêche d'aller le chercher ailleurs, avec un peu de chance ça sera basé sur Qt.
Tu vois une différence entre une applications KDE et une application Qt toi ? Moi pas ?
Et puis avec le thème Qt4 de Gtk, même les applications Gtk sont visuellement proches de Qt, donc même si une application KDE est manquante je vois vraiment pas le problème tant que ça tourne sous Linux...
[^] # Re: Vers où va KDE ?
Posté par zebra3 . Évalué à 3.
...
Si un logiciel n'est pas directement fournit par KDE rien n'empêche d'aller le chercher ailleurs, avec un peu de chance ça sera basé sur Qt.
Tu vois une différence entre une applications KDE et une application Qt toi ? Moi pas ?
Qu'un logiciel soit développé en Qt ne suffit pas pour qu'il soit pleinement intégré à KDE. C'est comme dire qu'un logiciel en GTK est explicité fait pour GNOME, c'est faux.
Des environnements de bureau fournissent de nombreuses fonctions plus haut niveau que le toolkit sur lesquels ils se basent, comme l'accès aux fichiers à distance avec Kio, Phonon qui permet d'avoir des paramètres multimedia communs à toutes tes applis, ou Kwallet qui garde précieusement tous les mots de passe.
C'est également important pour l'interface : boîtes de dialogues, cohérence de l'ergonomie et des icônes, etc.
VLC peut lire des fichiers par SFTP ?
Pour Dolphin, je le trouve à l'usage bien plus agréable à utiliser que konqueror (y compris dans la branche 3.x), c'est vrai que lors de la sortie de KDE 4.0 il était largement en retard, mais personnellement je peux plus m'en passer,
D'un point de vue fonctionnalités pures, il reste largement en deça de Konqueror. De nombreuses fonctions ont sauté, comme la sélection par motif, l'affichage visuel des dossiers par tailles, le découpage des fenêtres, etc.
Quand on est habitué à une certaine puissance, il est difficile de s'accommoder de tels choix, on a l'impression de revenir en arrière.
je ne me sers plus de konqueror, y compris pour la navigation web (firefox)
Toujours pareil, Firefox ne s'intègre pas correctement à KDE, ne serait-ce que que parce qu'il est plus conçu pour GTK, mais pas seulement : il n'utilise pas kwallet, ni kio, ni Phonon, etc.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Vers où va KDE ?
Posté par windu.2b . Évalué à 2.
Il existe le paquet firefox-kde-opensuse (mais que l'on peut trouver dans d'autres distrib comme ArchLinux), qui permet de mieux intégrer Firefox à KDE, en s'appuyant justement sur kwallet, l'sexplorateur de fichiers de KDE, ...
[^] # Re: Vers où va KDE ?
Posté par zebra3 . Évalué à 2.
Par contre, ça n'a pas l'air d'être dispo sous Debian, dommage.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Vers où va KDE ?
Posté par imr . Évalué à 2.
J'ai aussi laissé tomber konqueror parce que firefox fait mieux le boulot même si je suis d'accord avec toi sur les usages incroyables et l'intégration magnifique que permettait konqueror. J'avais trop de sites qui ne rendaient pas bien dans konqui, et surtout les extensions firefox sont géniales.
Quand j'ai commencé à utiliser konqui, j'espérais beaucoup des kio slaves et des kparts, d'autres idées du genre "l'extension" qui permettait de ripper des CDs facilement depuis konqui, et j'espérais en voir arriver plus. Ca n'a jamais eu lieu faute de développements.
Pendant ce temps, j'ai trouvé cette richesse et cette facilité d'extension et de modification de l'appli pour l'adapter à mes usages chez firefox et ses extensions. J'utilise KDE pour cette possibilité d'adaptation, et firefox aussi, malgré les lacunes de GTK.
Donc je n'ai plus besoin que d'un file manager qui me procure les possibilité des kio, dolphin fait le boulot, tant pis pour les kparts et l'intégration géniale de konqui. C'était une bonne idée, mais s'il n'y a pas les ressources en dévs derrière pour les mener à bout, ça ne sert à rien de pisser contre le vent.
[^] # Re: Vers où va KDE ?
Posté par Goffi (site web personnel, Mastodon) . Évalué à 2.
T'as essayé avec webkit ? Même si ce n'est dispo "officiellement" que depuis cette version, ça fait un moment qu'on peut l'utiliser avec konqui.
Pour les extensions, autant que je m'en souvienne il y a eu (il y a fort longtemps) une démo technique qui permettait d'utiliser les extension firefox avec konqui (un KPart XUL), mais qui n'a pas été continué (probablement trop de boulot à maintenir). Dommage, parce konqui + extensions firefox, quand bien même ça serait un peu plus lent, ça laisserait tout le monde loin, très loin derrière.
[^] # Re: Vers où va KDE ?
Posté par imr . Évalué à 2.
J'ai installé la dernière version pour essayer, mais sans mes extensions je doute de m'y faire à nouveau.
wekbit, c'est juste le rendu ou c'est aussi le javascript?
Parce que c'était ça aussi qui posait des problèmes, pas seulement khtml.
[^] # Re: Vers où va KDE ?
Posté par imr . Évalué à 1.
[^] # Re: Vers où va KDE ?
Posté par Florian.J . Évalué à 1.
Après tu me parle de Kwallet, mais ça ne concerne que quelques applications et pour Kio ça ne concerne que le gars qui programme l'application, l'utilisateur final en a un peu rien à faire.
Il y a aussi la cohérence de l'interface mais franchement est ce que c'est vraiment génant de pas avoir exactement la même fenêtre avec Fichier/Ouvrir... entre Kate et QtCreator ?
Moi personnellement je m'en accomode très bien, je m'en aperçois même pas au quotidien.
J'utilise mes applications pour les services qu'elle fournissent et j'attend d'elles qu'elles soient agréables, rien à faire que mon éditeur de texte (Kate/KDE), mon environnement de développement (QtCreator/Qt) et mon navigateur (Firefox/Gtk+) diffèrent à quelques détail près, en choisissant bien ses thèmes ils ont tous la même apparence à moins de chercher dans le détail.
Effectivement, je connais peut être pas assez Konqueror, mais dans ce que tu cite Dolphin permet de diviser la fenêtre, tout comme trier les fichiers par taille.
(Ou alors j'ai mal compris).
[^] # Re: Vers où va KDE ?
Posté par zebra3 . Évalué à 4.
C'est vrai, et c'est même très bien, c'est la preuve que leur boulot est reconnu et en vaut la peine.
Après tu me parle de Kwallet, mais ça ne concerne que quelques applications et pour Kio ça ne concerne que le gars qui programme l'application, l'utilisateur final en a un peu rien à faire.
Kwallet concerne toute application qui a un mot de passe à conserver et les exemples sont légions : Konqueror pour les formulaires, Dolphin pour les partages distants, Krdc pour les accès distants, Amarok pour last.fm, Chocoq pour Twitter, etc.
Quant à Kio, je ne suis pas développeur et pourtant j'en ai besoin chez moi et au bureau. Ben oui, j'ai plusieurs machines, et au boulot je dois accéder à des partages SMB et SFTP. C'est par Kio que je passe, même sans m'en rendre compte.
Il y a aussi la cohérence de l'interface mais franchement est ce que c'est vraiment génant de pas avoir exactement la même fenêtre avec Fichier/Ouvrir... entre Kate et QtCreator ?
Ça dépend des gens, mais c'est le ressenti global qui y perd. Après, ça peut être comme sous Windows où chaque appli a son propre framework, mais je trouve dommage de ne pas le faire sous Linux où l'on a justement de très bons frameworks, unifiés et complets.
Effectivement, je connais peut être pas assez Konqueror, mais dans ce que tu cite Dolphin permet de diviser la fenêtre, tout comme trier les fichiers par taille.
En effet, Dolphin peut diviser sa fenêtre, mais pas en plus de deux parties, quand Konqueror peut la diviser en autant que tu veux. C'est certes overkill, mais qui peut le plus peut le moins.
L'autre fonction, ce n'est pas ça, je vais essayer de la décrire : il s'agit de présenter les répertoires par des rectangles dont la surface est proportionnelle à l'espace occupé (ça a le même rôle que Baobab sous GNOME). Quand on veut faire le ménage, c'est très utile.
Après, chacun fait ce qu'il veut, bien sûr, je ne force personne. Je me contente de souligner ce pourquoi je ne l'utilise pas, malgré avoir tenté d'en saisir l'approche. Et j'imagine ne pas être le seul. Après, tu le dis toi-même, il y a des défauts, tu arrives à passer outre, mais tout le monde ne le peut pas forcément.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Vers où va KDE ?
Posté par Nonor . Évalué à 2.
[^] # Re: Vers où va KDE ?
Posté par wismerhill . Évalué à 1.
Je ne trouve pas ça du tout overkill, il m'est déjà arrivé plusieurs fois de diviser la fenêtre en quatre pour voir quatre dossier différents en simultané.
Aujourd'hui encore, je l'ai coupé en trois pour accéder à des dossiers sur des serveurs distants, et comme l'accès est un peu lent, je naviguait dans les répertoires des différents serveurs en parallèle.
Il m'est aussi arrivé de couper la fenêtre en deux pour mettre des pages HTML en parallèle (un peu comme des frames).
[^] # Re: Vers où va KDE ?
Posté par ZeroHeure . Évalué à 2.
installe Kdirstat
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Vers où va KDE ?
Posté par zebra3 . Évalué à 2.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Vers où va KDE ?
Posté par Beurt . Évalué à 3.
[^] # Re: Vers où va KDE ?
Posté par ZeroHeure . Évalué à 2.
http://packages.debian.org/sid/kdirstat
La version "non-intégrée" est plus puissante et plus efficace pour faire de la place.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Vers où va KDE ?
Posté par Philip Marlowe . Évalué à 2.
[^] # Re: Vers où va KDE ?
Posté par wismerhill . Évalué à 2.
Ç a existe toujours, au moins dans konqueror.
Je suis avec KDE 4.4 (sur une mdv 2010.1), et dans konqueror lorsque j'affiche un dossier, parmis les types d'affichage j'ai un "affichage de la taille des fichiers".
Je crois qu'il s'appelle fsviewpart(.so) et dans mandriva il se trouve dans le paquet konq-plugins (avec plusieurs autres plugins pour konqueror).
Et si on a installé filelight il y a aussi une "vue radialMap" qui est en fait un filelight intégré dans konqueror.
[^] # Re: Vers où va KDE ?
Posté par zebra3 . Évalué à 2.
Malgré tout, c'est bien Dolphin qui est mis en avant pour gérer les fichiers, et c'est ce que je trouve dommage.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Vers où va KDE ?
Posté par ZeroHeure . Évalué à 7.
Je ne comprends pas très bien ces façons de se plaindre sans cesse: on n'a pas 4 mains pour coder, et on n'a qu'un seul cerveau, on ne pense pas forcément à tout. Si personne ne fait l'effort d'un rapport de bug ou d'une demande de fonction, ben faut pas s'attendre à ce que ça apparaisse miraculeusement. Même Saint Ignucius ne fait pas de miracles.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Vers où va KDE ?
Posté par zebra3 . Évalué à 1.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Vers où va KDE ?
Posté par ZeroHeure . Évalué à 7.
Ensuite, Dolphin n'est pas un remplaçant. Le remplaçant c'est Konqueror 4, qui demeure très puissant. Dolphin est un outil qui essaie de rester simple, parce que plein de râleurs n'aimaient pas la politique du couteau suisse avec Konqueror.
Enfin, si ça se trouve ça marche chez le développeur et pas chez toi. Ou alors ça marchote dans le tronc de développement.
Donc fais un rapport de bug.
Je sais de quoi je parle, on a exactement le même problème sur un projet de SGBD: on ne peux pas faire tout ce qu'on a prévu, faute de temps, et il y a des utilisateur qui râlent à chaque nouvelle version parce qu'ils voudraient tel ou tel truc. Mais ils n'ont jamais rien dit avant. Ces tels ou tel truc sont d'ailleurs souvent presque prêts, mais faute de demande, je fais avancer le code lentement.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Vers où va KDE ?
Posté par Gniarf . Évalué à 3.
[^] # Re: Vers où va KDE ?
Posté par windu.2b . Évalué à 3.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.