Re: Rhaa, KDE 4
Oui, mais le principe du raccourci clavier, c'est qu'il existe un nombre fini d'actions auxquelles on peut associer un raccourci (dans un lecteur média: commencer la lecture, au niveau global: baisser le son, etc ...)
Quand tu parles d'exécuter une application, c'est différent. KDE n'est pas sensé connaître la liste des applis installées chez toi. Il existe donc potentiellement une infinité d'applications. C'est donc bien une action d'entrée.
[ Répondre ]
Re: Rhaa, KDE 4
Dans la terminologie KDE, je penses que tu évoques les "action d'entrée" où tu peux associer un peu n'importe quelle action à un peu n'importe quel événement.
C'est configurable dans systemsettings, avancé, actions d'entrée et (chez moi) ça marche. Est-ce qu'il existe des bugs que tu pourrais rencontrer et auxquels je n'ai pas à faire ... Je n'en sais rien, mais http://bugs.kde.org saura certainement mieux te répondre.
[ Répondre ]
Re: Rhaa, KDE 4
kde4 s'avérait [...] d'un goût très douteux au niveau design.
cela reste désespérément LAID
compiz est fluide et élégant, KDE semble une caricature
Avec la concurrence qu'on connaît entre gnome et KDE, avec la tendance dans le libre à s'approprier un projet et à dénigrer tout le reste, avec le conservatisme qui pousse bien souvent à refuser toute évolution de l'interface, mon avis est que le fait que le principal reproche fait à KDE4 soit son thème par défaut est une très bonne nouvelle pour cet environnement !
Sur ce, et après avoir bien marché dedans, je vais essayer de me retenir de répondre plus à ce genre de commentaires subjectifs et qui donc n'acceptent aucune discussion.
[ Répondre ]
Re: Rhaa, KDE 4
process kioslave qui ne meurent pas quand l'application est quittée (les voir la source d'une page web laisse un kioslave kwrite par exemple)
Oui effectivement ... et c'est normal ! Si tu regardes bien, ça a toujours été comme ça, les process persistent pour être éventuellement réutilisés si un autre accès au même dossier est fait, puis ils disparaissent après une durée déterminée.
Ce comportement n'est pas forcément optimal, mais il n'est pas à classer dans les régressions.
[ Répondre ]
Re: KDE?
Je trouve ça un peu limite du coup ... Voilà mon Linux, mon KDE, mon dolphin ...
Réutiliser les noms, comme ça, sans faire de demande aux auteurs originaux, et sans même préciser clairement qu'il s'agit de logiciels différents, en dehors de toute considération légale, je trouve que c'est quand même un manque de respect certain.
Combien comme l'auteur de la dépêche se sont fait prendre et pensent qu'il s' agit d'un portage ?
Quels résultats pour l'image de Linux, de KDE (les vrais) ? J'entend déjà les "Linux, KDE ? Non merci, ceux de ma PSP me l'ont fait cramer !"
[ Répondre ]
Re: aujourd'hui, c'est vendredi -4
Eh ben, quand je lis tout ça, j'ai une drôle d'impression ...
Je suis assez d'accord avec les arguments avancés. Besoins d'un daemon pour le mixage du son. Permettre un réglage du volume par application, pas par canal de la carte son, etc ...
Il faut cependant replacer la sortie de PulseAudio dans son contexte, c'est un peu la guerre entre les différents systèmes de son depuis longtemps sous linux et tant qu'un standard n'aura pas émergé, aucun ne sera parfait puisqu'il devra émuler tous les autres.
Dans ce cadre, j'imagine que le développeur de PulseAudio doit en prendre plein la gueule et en avoir marre des critiques et reproches sur ce qu'il estime ne pas être un problème de son petit bébé.
Mais quand même, sa manière de communiquer ne grandit pas le logiciel libre. Je le trouve vraiment agressif.
Certes il est passionné, ça se comprend. Mais dans son cas, c'est à un point tel qu'il n'en accepte plus aucune critique et qu'il semble décidé à ce que toutes les fonctionnalités doivent être dans SON bébé ou ne pas être.
Il en vient à critiquer d'autres projets vraiment sans raison phonon, esd, amarok ... et à reproduire ce qu'il reproche à ceux qui critiquent PA.
Je ne suis pas très impliqué dans la communauté LL, je ne la connais que de loin, notamment par la lecture du planet KDE. Je n'y avais pas trop ressenti cette ambiance désagréable jusqu'à maintenant. Mais si c'est ça la communauté, ça ne donne pas envie de s'y aventurer ...
[ Répondre ]
Re: Vite KDE sous license BSD ou MIT!
Petite remarque quand même. La FLA limite les licences sous lesquelles KDE e.V peut relicencier le code qui lui est donné par ce moyen. Pas de risque de voir KDE devenir proprio même si tous les contributeurs signaient cet accord.
[ Répondre ]
Re: Le jamais content...
personnellement il me semble beaucoup moins bien que l'iPhone techniquement (si ce dernier était débloqué d'office et que la suite logicielle proposée était libre, [...])
Il me semble au contraire que l'iPhone est beaucoup moins bien que le Neo FreeRunner techniquement (si ce dernier était plus fin, plus joli et avec plus d'autonomie)
Chacun sa vision ... :)
[ Répondre ]
Re: précisions
C'est comme bash, cette usine à gaz avec laquelle on voudrait nous faire croire qu'il est possible d'éditer un fichier texte ou d'écouter un fichier son ... aberrant !
Sarcasmes mis à part, il faut comprendre que konqueror se voulait être un "shell graphique" et non pas un navigateur de fichier.
L'idée étant que comme dans un shell, on peut naviguer dans les fichiers puis lancer l'action appropriée. Dans un shell on lancera un éditeur de texte qui remplace le shell à l'écran, dans konqueror une kpart qui viendra prendre la place de l'interface de navigation mais la philosophie reste la même.
Il suffit de voir comment dans KDE2, tous les fichiers étaient ouvert dans une kpart dans le konqueror actif pour s'en convaincre.
Le concept a fait long feu, mais konqueror est toujours là. Il reste très puissant et loin d'être une "usine à gaz" à mon avis.
[ Répondre ]
Re: Standard ?
Le standard OMG ... Je ne pense pas que l'OMG soit un organisme de normalisation. Ses standards n'ont donc pas plus de valeur qu'un autre contrairement à ce qu'ils ont l'air de penser.
Sinon, pourquoi a t'on vu la disparition de CORBA des bureaux libres si c'était un standard ?
[ Répondre ]
Re: Ca a l'air vachement bien
L'idée c'est de modéliser les langages de programmation comme tu modélises une application.
J'ai ma méta-classe "classe" qui hérite de la méta-classe "type", qui contient un méta-attribut "nom" et qui est lié à la méta-classe "attribut", elle même ayant un méta-attribut "type" etc ...
Ainsi, un programme écrit en java pourra se représenter comme une instance de ce méta-modèle. La classe "Personne" que j'ai écrit en java sera une instance de la méta-classe "classe", etc, etc ...
Bon, comme tu le dis, si on s'en arète là, ça s'apparente fortement à de l'onanisme cérébral.
Une idée c'est ensuite d'ajouter des méta-méthodes au méta-classes. Par exemple, une méta-méthode "rename" à la méta-classe "classe". Cette méthode renommera la classe mais aussi toutes les références à cette classe. Tu viens de créer un outil de refactoring de manière relativement aisée.
Une autre idée est l'approche MDA (Model Driven Architecture) de l'OMG (Object Management Group).
On commence par décrire l'application dans un modèle générique (disons UML puisqu'il vient aussi de l'OMG), c'est ce qu'on apelle le PIM (Platform Independant Model).
On utilise ensuite une transformation de modèle pour transformer notre application en son équivalent dans un modèle spécifique, par exemple Java, c'est ce qu'on appelle le PSM (Platform Specific Model).
Cette transformation est effectuée par un programme de niveau méta qui remplace chaque instance de "UML::Classe" par une instance de "Java::Classe" et ainsi de suite pour toutes les méta-classes du modèle de départ en s'appuyant sur un PDM (Platform Description Model).
On obtient ainsi un équivalent Java de notre application UML initiale.
Pourquoi s'emmerder à faire ça ? Eh bien, l'idée est de coder de manière indépendante de la plateforme d'exécution, puis, les spécificités de la plateforme sont décrites dans le PDM. Tu as donc une sorte de phase de compilation pour s'adapter à la plateforme et tu obtiens en résultat différent en fonction de tes ressources, de tes contraintes, etc ... Y compris, peut être dans un langage différent.
[ Répondre ]
Re: Wargames
J'avais entendu la même chose à l'époque de DADVSI, moi aussi j'avais voulu y croire ... Je crains que les internautes tant qu'ils ne pourront pas bloquer de ports (autres que TCP) ou bloquer les approvisionnements en carburant ne représenteront pas un pouvoir de nuisance qui nécessite de les écouter.
Je continuerai à me battre, mais je crains vraiment que ce ne soit que peine perdue ...
Comme tu le dis : en «espèr[ant] que j'ai tord»
[ Répondre ]
Re: Nom de Dieu
Eh bien ne le sois pas (pour l'Europe), les députés européens ont voté une motion (ou quel que soit le nom des trucs votés par les députés européens) où la coupure de l'accès internet est considérée contraire aux droits de l'homme.
Je suis de mon côté vraiment heureux qu'il y ait les institutions européennes pour fournir un embryon de contre pouvoir à notre omniprésident et au parlement à ses ordres.
[ Répondre ]
Re: Et les entreprises
Maiiiiiiis non !
Nos députés savent bien que si la vie privé d'un pauvre terroriste en puissancecitoyen ne vaut pas grand chose, les entreprises au contraire doivent être défendues.
Par exemple dans la loi sur la riposte graduée, la coupure de l'accès internet n'est possible que pour les personnes physiques, pas pour les entreprises (et encore moins pour l'état.)
[ Répondre ]
Re: Et si rien ne disparaissait ?
Je ne connais pas du tout le fonctionnement des cartes physiques. En quoi diffèrent-elles d'une carte graphique ?
Il me semblerait logique que les deux se prêtent au parallélisme massif ... J'ai même cru entendre qu'elles arrivaient trop tard (les cartes physiques) et qu'avec les cartes graphiques programmables, leur valeur ajoutée était ridicule.
[ Répondre ]
Re: Le CPU, limité dans son évolution
Je pense de mon côté que la révolution (si révolution il y a) viendra des langages interprétés et JITés. Je ne serais pas étonné qu'on nous refasse le coup du Out-of-order_execution avec le bytecode dans le rôle de l'assembleur et l'assembleur dans le rôle du microcode.
Je m'explique : le OoO revient à transformer l'assembleur du binaire en un code plus finement découpé : le microcode. Ce microcode est stocké dans un "pool" dans le processeur et chaque instruction est exécutée dans le désordre (out of order) dès que ses dépendances sont satisfaites.
Une partie du processeur est donc destinée à la gestion de ce mécanisme : traduction, gestion des dépendances, etc ...
Dans le cas du bytecode, on ajoute une étape de transformation. Le bytecode est soit interprété, soit transformé en code assembleur pendant l'exécution (JIT). Il me semble que cette étape ressemble fortement à ce qui se fait pour le OoO, mais à une échelle plus large.
On pourrait donc imaginer une architecture où un coeur est destiné à la gestion de ce bytecode (exécution de la VM) et où les autres coeurs exécutent le résultat. Cette solution permettrait de tirer partie de coeurs hétérogènes : 1CPU OoO classique pour l'interprétation, un GPU pour ce qui se parallélise facilement, un VLIW pour ce qui a été JITé, un FPGA pour les tâches très répétitives, etc ...
Enfin, je divague ...
[ Répondre ]



Re: KDE?
Désolé si je n'ai pas été clair, je ne parlais pas de la dépèche ici mais bien des différents posts de l'auteur qui comme tu le dis toi même induisent facilement en erreur.
Quant à savoir si c'est une bonne chose pour le libre ... je n'ai même pas l'impression qu'il diffuse son code ...
[ Répondre ]