pshunter a écrit 132 commentaires

gdk_window_input_shape_combine_mask ()

void gdk_window_input_shape_combine_mask (GdkWindow *window,
GdkBitmap *mask,
gint x,
gint y);

Like gdk_window_shape_combine_mask(), but the shape applies only to event handling. Mouse events which happen while the pointer position corresponds to an unset bit in the mask will be passed on the window below window.

An input shape is typically used with RGBA windows. The alpha channel of the window defines which pixels are invisible and allows for nicely antialiased borders, and the input shape controls where the window is "clickable".

On the X11 platform, this requires version 1.1 of the shape extension.

On the Win32 platform, this functionality is not present and the function does nothing.

window :
a GdkWindow

mask :
shape mask, or NULL

x :
X position of shape mask with respect to window

y :
Y position of shape mask with respect to window

Since 2.10

Ah, bien vu mais c’est récent, j’ai dû mettre à jour ma machine avant de voir la transparence à la souris.

Je vais voir comment c’est fait et ce que je peux récupérer.

Merci

C’est opaque aussi.

Je me demandais dans quelle mesure il était possible de récupérer un de ces programmes, comme par exemple osd-monitors (un seul fichier c), de détecter la position de la souris quand elle passe dessus et de créer un trou de 1 pixel carré sous le pointeur…

Je confirme, j’ai testé et c’est opaque.

Effectivement c’est très pratique pour les notifications ponctuelles lorsque «quelque chose se passe», mais si je veux garder un œil en permanence sur, par exemple, la date, l’heure ou la météo, ça n’est pas vraiment adapté.

Qui a parlé d'A4 ? Qui a dit qu'on avait pas la topographie ? Qui a dit qu'on avait pas d'ombrage pour mieux voir le relief ?

Personnellement, je ne trouve pas qu'une carte d'un mètre de côté soit pratique. C'est bien pour l'afficher en poster mais quand je pars en randonnée elle est toujours bien pliée pour ne voir qu'un petit bout. Et à force de devoir la plier et la replier ça fait des trous.

Il y a déjà un bon début pour les courbes de niveau :
http://openstreetmap.org/?lat=48.2849&lon=6.9717&zoo(...)

Quant à l'ombrage, ça existe mais les serveurs ne sont pas dimensionnés pour une linuxfrisation, donc je ne colle pas de lien ici.

Qu'est-ce qui empêche les gens d'imprimer des cartes OSM ? OSM n'est pas exclusivement une carte routière et il existe un groupe d'intérêt pour la randonnée qui répertorie les sentiers.

OSM permet un nombre inimaginable d'emplois créatifs des données géographiques. Je ne serais pas surpris qu'un jour soient proposées des cartes orientées impression au moins aussi utiles et pratiques que celles de l'IGN.

Évidemment que nous ne sommes pas des ingrats… Les remerciements étaient encore dans les tuyaux lorsque j’ai posté la dépêche mais il a été question de la rédaction d’un message de remerciement dès la réception de la bonne nouvelle.

C’est désormais chose faite :
http://wiki.openstreetmap.org/wiki/Cadastre_Français/Legal#Les_remerciements

La précision du cadastre est variable, autant dans les villes elle est excellente, en montagne ou dans certaines campagnes la qualité est un peu moindre… Normal vu que moins de mesures sont faites par des géomètres experts.

Même si les traces GPS sont assez précises, le cadastre est souvent supérieur (heureusement vu qu’il s’agit de répertorier officiellement la taille du terrain qui vous appartient !)

Je confirme, jai posé la question il y a deux ans à la présentation de l'OLPC au FOSDEM. Par contre je ne connais pas les algorithmes qui sont utilisés. Etant donné que la plupart des protocoles pour réseaux ad-hoc fonctionnent au niveau 3, je suspecte une forme de flooding au niveau 2, ce qui limite l'application à de petits groupes d'OLPC reliés par un backbone classique.

Le contexte d'une traduction peut être particulièrement complexe. Je tiens à partager ici une perle, trouvée dans un antique logiciel de gravure de CD-ROM.

Le logiciel indiquait :

« Écrire l'état du tampon »

Qui était une traduction correcte, dans l'absolu, de :

« Write buffer status »

Mais la bonne traduction était :

« État du tampon d'écriture »

Est-ce qu'un système tel qu'il est proposé ici pourrait corriger ce genre d'erreurs ? Sans voir le contexte (boîte de dialogue de gravure) dans lequel le texte est présenté à l'utilisateur, comment le traducteur peut-il trouver la bonne traduction ?

Si la vache n'avait pas levé la queue, elle n'aurait pas bousé.

Ah, j'oubliais aussi le format mammoth : 150Go/bande mais un peu tombé en désuétude il me semble...

Les bandes DDS sont compatibles avec les lecteurs plus récents, c'est-à-dire un lecteur DDS4 pourra lire les DDS1,2,3 et4, par contre impossible de faire manger une bande DDS3 à un lecteur DDS2.

En ce qui concerne le LTO, je pense que c'est la même chose, mais ce n'est pas le genre de matériel que je peux me payer.

Pour les geeks on trouve également des tours robotisées à 5 cartouches d'occasion ce qui permet de laisser de grosses sauvegardes (>12Go) tourner la nuit sans avoir à changer les cartouches.

La vitesse d'écriture des cartouches DDS n'est pas très élevée, mais c'est un système qui est prévu pour fonctionner qu'avec des interventions occasionnelles de l'opérateur donc ce n'est pas grave.

En lecture/récupération, c'est pas la joie non plus mais si on travaille avec un soft intelligent, il pourra bobiner la bande très rapidement jusqu'au fichier voulu sans tout lire, puis extraire le fichier qu'on veut récupérer.

Pour la fiabilité, les bandes DAT c'est le pied. Après, bien sûr, il ne faut pas les stocker à côté des enceintes de votre chaîne hi-fi.
J'utilise bacula comme logiciel de sauvegardes, c'est pratique y'a juste à changer les cartouches et mettre celles qu'il demande.
Pour acquérir le matériel, on peut trouver de bonnes affaires sur des sites de vente aux enchères à partir de 50¤ environ.
Les lecteurs SCSI sont assez courants donc si vous avez déjà une carte contrôleur (par exemple, un vieux scanner scsi) c'est le pied. Sinon il existe des modèles IDE il me semble.
Pour les modèles plus récents (DDS-4, LTO2) les prix sont largement trop chers (y compris pour les bandes) car encore à la mode dans les entreprises (compter plusieurs centaines d'euros pour un lecteur LTO2 par exemple).

Comme toi, j'aimerais bien ne plus avoir à mettre d'extensions dans les noms de mes fichiers. Cependant je ne pense pas que ta proposition soit applicable à la grande majorité des fichiers possédés par les gens en général. Si déjà ton idée a du mal à prendre chez les libristes, je doute qu'elle puisse être reprise dans des systèmes propriétaires et on aurait de plus en plus de mal à étendre des fichiers.

Par contre, comme les indexeurs sont à la mode, je pense qu'on pourrait les utiliser pour analyser de façon paresseuse et de manière approfondie les différents fichiers dont dispose une personne. Par exemple, lors de l'apparition d'un fichier openoffice, le système voit que c'est une archive zip, puis essaie de l'ouvrir, et finit par voir que c'est un document de type tableur ods. Quand cette info est obtenue, on l'inscrit dans les métadonnées du fichier gérées par l'indexeur (ou les attibuts étendus) pour ne pas avoir à ré-analyser plusieurs fois.

Sur les systèmes lents, on pourrait commencer par afficher une icône représentant un type de fichier inconnu, et par-dessus un symbole qui indique que l'analyse est en cours. Au fur et à mesure que l'info sur le fichier s'affine, l'icône change et une fois que l'analyse est terminée l'indicateur d'attente disparaît. Si la personne est pressée et qu'elle veut ouvrir le fichier, mais que l'analyse n'est pas terminée, on peut présenter un boîte qui indique où on en est de l'analyse (par exemple, jusqu'à présent c'est une archive zip et vous pouvez l'ouvrir, mais si ça se trouve c'est autre chose, si vous n'êtes pas sûr veuillez patienter)

Et s'il était possible d'avoir à la fois les avantages d'une interface graphique et de la ligne de commande, qu'en dirais-tu ?

Oui, mais bon, d'après le titre on parlait de l'usage de l'informatique dans les éléctions. Donc ce n'est pas une personne qui doit contacter le bureau de rattachement, mais le système, ce qui est beaucoup plus faisable. Et si on doit conserver le bulletin papier (ce qui semble indispensable pour la transparence) le bureau de rattachement n'enregistre que l'information "a voté" et le bureau local enregistre le vote.

Faut arrêter de se faire des noeuds au cerveau... Il suffit que le citoyen indique son bureau de rattachement (précisé sur la carte d'électeur) et le bureau où le citoyen vote contacte son bureau de rattachement. Si on donne un faux bureau de rattachement, on est tout simplement pas sur la liste des votants.

...petit et qui ne consomme pas grand chose, il y a aussi le microclient :

http://www.norhtec.com/products/mcr/index.html

que l'on a pu voir au FOSDEM sur le stand Debian. On peut y mettre un DD 2.5 pouces.

Je crois qu'on oublie quelque chose. C'est France 2 qui souhaite diffuser des vidéos, et dans France 2, il y a France. Or chez nous, aux dernières nouvelles, il n'y a pas de brevets logiciels, donc pas de droits à acquitter.

Pour une trouvaille... Signalons qu'elle avait déjà été faite par François Pérusse il y a bien longtemps...

Manifestement, tu sais écrire "requête" à peu près correctement :

jouer directement avec les requètes.

Mais alors pourquoi, pourquoi tu écris huit fois "requette" ??

De plus, impossible de signer électroniquement un document de manière sûre. Forcément, si les clés ne sont pas dans une mémoire locale et les calculs ne sont pas faits dans une machine sous le contrôle exclusif de l'utilisateur, ça ne marche pas...

Saint-Chinian.