Mokona a écrit 223 commentaires

Tu grattes la touche et tu mets une gommette à la place :)

Ceci dit... mmmh... il me semble avoir vu ça un jour sur une photo.

Et ce genre d'écrans se rayent (voir les tablettes graphiques/écrans). Ca a ses inconvénients aussi, en plus du problème du toucher.

Ceci dit avec un peu d'habitude... je connais des télécommandes universelles tactiles à cristaux liquide qui font un peu ça.

L'idée est plaisante... je n'imagine pas trop le prix par contre...

Euh... petit ajout en fait. Xterm depuis quelques version comprend l'utf8.

Sous X, l'edition de script Perl exotique ne pose théoriquement pas de problème (il y a aussi Yudit pour faire ce genre de choses, mais l'éditeur n'est pas très pratique pour des textes longs).

Reste donc comme je le disais ci-dessus le problème du chargement des fontes.

Et le problème d'éditer par un terminal texte :)

Ca va un cran plus loin : yaka reprogrammer le système de fontes de X. Et là, on entre dans la partie "énorme" du problème :)

La gestion des fontes dans X n'est pas du tout adaptée à la gestion de l'unicode. Le principal problème étant qu'il tient à charger une fonte dans son intégralité dès qu'on fait appel à un des caractères de la fonte.

Sur ma petite Sparcstation 10, il suffit que j'entre un caractère japonais pour que X me bloque la machine pendant deux bonnes minutes, le temps de tout charger.

Et il n'y a qu'un peu plus de 2000 caractères dans cette fonte.

Il y a quelques solutions, le projet Pango est très intéressant à ce sujet, et devrait permettre à terme une utilisation correcte multilingue (et multisymbole, pour le sujet qui nous intéresse ici).

Personnellement sur les claviers PC, je map la touche Windows sur Compose et la touche Menu sur Kanji. Ca me permet déjà d'entrer les caractères accentués et le japonais.

À la place de Kanji, on peut mettre autre chose qui soit compris par la méthode d'entrée de caractères pour switcher en mode math, arabe, cyrillique,...

Mon problème principal quand je parle de ça dans la plupart des projets, on me regarde (par mail) avec des yeux ronds en me demandant à quoi ça peut bien servire d'entrée autre chose que ce qu'il y a sur le clavier de base.

Mais je ne désespère pas :) Cette idée dans Perl me donne un argument de plus.

Oui c'est bien ce que je disais dans mon premier commentaire : si l'entrée de "sygma majuscule" est plus long que "sum", l'intérêt n'est qu'esthétique.

Mais ce système n'est pas obligatoire, il s'agit juste, si j'ai bien compris, d'associer un signe à une fonction (voire peut être d'appeler cette fonction par ce signe).

Mon bémol au dessus était que l'édition d'un script perl en mode console n'allait pas être évident. (pour test : essayer de lire un fichier unicode dans n'importe lequel de ces codages en mode console sous Linux).

<< Ca permettra par exemple de définir une fonction sigma, en écrivant le symbole. Enfin, ça c'est grace à l'unicode, pas au futur parser en perl. Si j'ai bien compris ;-) >>

Un peu grace aux deux. Unicode défini un codage pour sigma majuscule en tant que symbole mathématique. Perl considère(ra) que c'est un symbole valide, c'est tout (et c'est plutot bien).

On se limite généralement dans les languages à des noms de symboles disponibles partout, donc lettres maj/min, chiffres et éventuellement quelques symboles ascii.

Ca permettra de mettre des symboles japonais... C'est un beau jouet. Par contre, bonjour l'édition en mode console des scripts Perl.

On va dire que "c'est dans l'esprit" :)

<< Sinon, le fait de rajouter des "mini-langages" semble au premier abord une bonne idee, mais à la réflexion, je me demande si ça vas pas plutot augmenter le bordélisme... enfin, ça fera comme de grosses macros... >>

Un jouet intéressant aussi. Ce qui me fait peur a priori (mis à part la lisibilité :) ) c'est que si tout est fait par extentions de la base, comme pour les modules actuels, on va encore se retrouver avec des centaines de petits modules à maintenir, avec des versions pas forcément toujours compatibles entres elles.

(mon expérience personnelle a longtemps été de trouver des modules incompatibles entre eux... ça va, ça m'a passé... ouf).

Ah c'est bon, j'ai compris ce que ça voulait dire en allant voir le compte-rendu.

C'est bien joli ça, mais il faudrait pouvoir pour cela avoir des méthodes d'entrée de caractères potables pour en profiter.

Parceque je veux bien mapper un Sigma majuscule sur un sum() mais encore faut il avoir accès à l'entrée du caractère Sigma majuscule en moins de trois frappes clavier, sinon l'intérêt est plutôt faible.

D'un point de vu "beauté", rien à dire, écrire avec les symboles mathématiques, ça serait "beau".

<< On pourrait arriver à des choses très surprenantes, comme des équations mathématiques tapées en caractère Unicode interprétées ensuite avec les bons appels de fonction. >>

Hello,

je lis et relis cette phrase et soit je ne vois pas ce qu'il y a de nouveau, soit je ne comprends pas la phrase.

Ceci dit, elle m'a l'air intéressante. Des précisions ou développements ?

Avec une voix d'une fille qui n'a visiblement jamaieuh apeuhpris à parlereuh.

C'était intenable comme émission ! Irritiant au possible, inutile. Une sorte de clip de séquences sans relations mises bout à bout.

Le summum de l'art de la télé dans sa capacité à créer du vide.

Une horreur

T'inquiète t'inquiète, je pense que la proportion de gens qui n'ont pas compris ton second degré est assez faible.

Tout au moins je l'espère, car il était du genre voyant (et amusant).

Dans tout language de programmation (même orienté objets) on peut apprendre à optimiser.

Et en assembleur, on peut écrire des trucs lourds.

Je n'ai jamais ouvert de source concernant le projet KDE donc je ne me prononcerais pas sur l'optimisation de la chose. De toute façon, c'est hautement graphique, et X est facilement engorgé dès qu'il y a beaucoup d'appels graphiques.

Pas sous la main là tout de suite non.

En C effectivement, je vois ça en simulant les objets. C'est bof, et c'est pas fait pour. Mais c'est faisable.

En C++, il suffit de créer une classe Objet qui décrit ce qu'est un objet. Après tout, un Objet en mémoire est un... objet. C'est bête à dire mais bon :)

(au cas où, explication : on peut imaginer un ensemble de classes (là je ne parle plus C++) qui héritent toutes d'une classe "Objet". Puis on peut tenter de définir cette classe "Objet" en termes de classe, nommée "Méta-Objet". On va vite s'appercevoir qu'il y a un bouclage : une méta-classe est une classe).

C++ n'a pas ce mécanisme intrinsèquement (void *, le père de tout le monde, ne fait pas grand chose), mais on peut créer une classe "Objet" facilement, avec ces "addMethod()", "addMember()".

Au niveau implémentation simple, on peut imaginer un vecteur d'associations entre des "string" et des "void *".

Maintenant, si on veut faire ça dans le cadre d'un petit script rapidement, c'est n'est pas le langage à choisir, je disais ça juste pour montrer que c'est faisable (et utile, et utilisé).

Oui oui, on peut faire ça en... C++ par exemple. (ou même en C si on y tient).

Puis ensuite de manière générale dans tous les langages qui définissent les objets comme étant des objets (meta-objet) (ce qui n'est pas le cas du C++, mais cela peut se simuler).

Plus précisemment, j'avais mal lu son message et je pensais qu'il parlait de téléphone par le cable.

Priority Telecom a un license téléphonique qui lui permet de faire de la téléphonie au même niveau que France Telecom... ils doivent se débrouiller pour avoir leurs lignes. Et donc ils s'arrangent avec les cable opérateurs pour avoir des lignes.

(C'est ce que j'ai chez moi, je n'ai pas de ligne France Telecom).

C'est loin (très loin) d'être disponible partout. Déjà parceque le cable n'est pas disponible partout, mais en plus car tous les opérateurs cables ne proposent pas le téléphone.

En France, il y a Priority Telecom (avec UPC) il me semble qui fait ça, mais je crois bien que c'est tout.

Yep, moins cher ou pas moins cher, à moins qu'ils ne proposent un jour 90% moins cher que leurs concurrents, je ne veux plus rien avoir à faire avec eux.

Quelques centimes moins cher que les autres, ça n'est pas un argument assez fort pour retourner chez un opérateur sans aucun suivi client et ayant un tel mépris pour ces mêmes clients.

C'est un peu ça qui m'épate, je n'ai vu aucun jeu sous X qui arrive à aller aussi vite qu'un jeu sous... disont PC-Engine.

Bon certes, il y a un gros handicap : X.

Mais faire des jeux en OpenGL juste pour pouvoir profiter des accelérations, c'est assez démesuré je trouve :) C'est pourtant la seule méthode que je vois actuellement pour des jeux qui ne sont pas tour par tour.

Ben justement, quand j'ai vu Raptor j'ai foncé dessus. Moi grand fan de shooters depuis le début des années 80. Je m'attendais à trouver si ce n'est quelque chose du niveau d'un Thunderforce ou d'un Aleste au moins d'un niveau Tyrian...

Quelle deception, chez moi, c'est à peine jouable en 320x200 (K7-600) :-/ (c'est sans compter que les niveaux sont sans intérêt, mais ça, c'est du domaine design, pas technique).

Je ne sais pas si Raptor était rapide sous DOS, mais sous X, c'est vraiment pas terrible, et un shoot pas rapide, bof bof :)

Hum. Gtk, oui donc je me réponds, ton truc tourne sous X :)

Quelle version de X ? Pour l'instant, je n'ai rien vu qui puisse tenir du 60fps en 640x480 avec un dizaine de sprites et du son. Je cherche je cherche...

Ah tiens, voilà qui m'interesse. En effet, j'ai a un moment tenté une review des possibilités d'avoir un jeu 2D rapide sous Linux sans passer par les accelérations OpenGL (parceque bon...).

Il tourne sous X ton jeu ? J'ai testé tout un tas de librairies, de jeux, et je n'ai jamais vu de choses très probantes.

Je suis donc intéressé par quelque chose qui tournerait bien.

Ah ben tiens, je me sens moins seul :)

Aux vues des différents et nombreux articles sur imlib, je me demandais si je n'étais pas seul à me demander à quoi pouvait bien servir cette librairie à part à amuser son créateur (après tout, coder, c'est aussi un passe temps).

Je me sens moins seul, merci :)

Quel est l'intérêt de la "news" si c'est faux ? Je sais qu'il n'y a pas eu beaucoup de news hier mais tout de même.