Je me répond à moi-même, après essai, les possibilité de l'assistant d'impression de digikam ne répondent pas à mon besoin, tel que je l'envisage, ou alors je n'ai pas trouvé.
C'est même pire que ce que je pensais : l'assistant ne respecte pas la rotation spécifiée par l'image.
Pour info, mon programme arrange les photos de la façon suivante (pour le mode portrait seulement, actuellement) :
* on accumule au plus deux images (si on en trouve une deuxième) orientées paysage.
* on imprime en pleine page les images orientées portrait.
(ce week-end, pas chez moi, donc pas en mesure d'éventuellement tester)
Ce que j'en vois, c'est que le layout serait identique pour toutes les pages, qui ne s'adapterait donc pas à l'orientation des photos ==> je vais devoir vérifier ce point, mais si ça ce confirme, ce n'est pas ce que je veux obtenir.
Tu as raté la capture d'écran, je l'ai faite ce matin, et elle devrait être visible sur la page du projet maintenant.
Concernant l'existant, je n'ai testé que Shotwell qui est installé de base sur Ubuntu, et côté web les gestionnaires de Facebook et Google.
Mon test de Shotwell, bien qu'agréable, a été de courte durée, car je pense que ça ne va pas convenir avec le fait que j'ai 2/3 backup de mes archives photos, et aussi en prévision d'un changement de machine. Bref, pour l'essentiel, c'est la portabilité des données.
J'aurais bien aimé stocker mes annotations dans les méta-data de la photo (je vois que digikam le fait), mais j'ai découvert le bordel que c'est (EXIF, XMP, méta-data proprio) et j'ai pas envie de flinguer le fichier d'origine.
J'ai donc récemment conçu un format de fichier qui servirait à stocker ces annotations (cf le wiki)
Et puis dernièrement, ce que je veux obtenir, c'est un document imprimé contenant une sélection de photos, bien arrangées, avec les éventuels commentaires.
Enfin, c'est le prétexte de faire les choses à mon idée, car il y a un peu de ça quand même.
xorg utilise la convention suivante : la 'casse de chameau' (CamelCase) et la restriction à 78 caractères par ligne.
J'utilise un mélange de 'casse de chameau' et des '__' (double souligné). J'utilise les doubles soulignés pour simuler les espaces de nom et les classes (on est en C).
Cette écriture rend les identifiants des fonctions et des symboles très longs, verbeux même, de sorte que la limitation à 78 caractères pourrait se révéler inapplicable de temps à autres.
Le pilote a été testé sur une coque Clévo TN120R équipé d'un touch-screen UT4M de ET&T (et pour cause, c'est pour ça que j'ai du l'écrire...)
À priori, ça fonctionne si les conditions suivantes sont remplies :
- un node 'hiddevX' (X étant un nombre) est créé pour le périphérique
- les coordonnées X, Y et la pression sont envoyés dans des rapports hid de code différent (utiliser l'utiliter 'hidDeviceDump', à télécharger)
0n ne gère pas de niveau de pression, on ne s'intéresse qu'au fait que la valeur soit nulle ou pas.
Cette fois, on a quelque chose de beaucoup plus utilisable : toutes les pièces jointes sont sauvées dans un dossier temporaire à définir, puis réintégrées dans le mail.
Le message texte brut et html sont supportés.
Le problème est que les images inclus dans le message HTML (disposant d'un Content-ID et sans nom de fichier) ne peuvent pas être embarquée de la même façon, et sont donc jointe comme des fichiers normaux.
(J'ai trouvé des exemples de code sur le net, mais les versions récentes des objets COM d'outlook ont l'air d'exposer moins de propriétés, en particulier l'attribut Fields de la classe Attachment, donc ça m'a l'air mort...
Un autre code passe par l'objet COM "MAPI.Session" mais comme Thunderbird est mon client mail par défaut, forcément ça ne marche pas.)
Deuxième problème, le titre du message n'est pas décodé, et je n'ai pas trouvé encore de solution. Ce n'est pas grave si le message doit aller à l'extérieur, car les destinataire verront le titre correcte, mais c'est gênant lorsque le mail restera sur la messagerie interne.
# (c)2009 David SPORN
#
# A brain-dead Python SMTP to MAPI relay server based on the smtps, smtplib and mapi
# packages.
#
# DISCLAIMER
# You are free to use this code in any way you like, subject to the
# Python disclaimers & copyrights. I make no representations about the
# suitability of this software for any purpose. It is provided "AS-IS"
# without warranty of any kind, either express or implied. So there.
#
# Sources
# http://code.activestate.com/recipes/149461/
# http://www.outlookcode.com/d/code/htmlimg.htm
# smtps.py
"""
smtp2mapi.py -- A very simple & dumb Python SMTP to MAPI relay server. It uses
smtps for the server side and MAPI for the client side. This is
intended for use as a proxy to an Exchange server that is restricted to MAPI
(e.g. for 'security purpose').
This blocks, waiting for RFC821 messages from clients on the given
port. When a complete SMTP message is received, it connect to the
Exchange server using the Outlook OLE component, convert the
message and send it. Obviously, Outlook must be present.
All processing is single threaded. It generally handles errors
badly. It fails especially badly if DNS or the resolved mail host
hangs. DNS or mailhost failures are not propagated back to the client,
which is bad news.
The mail address 'shutdown@shutdown.now' is interpreted
specially. This gets around a Python 1.5/Windows/WINSOCK bug that
prevents this script from being interrupted.
"""
import os
import sys
import errno
import mimetypes
import smtps
import string
import smtplib
import email
import StringIO
#http://www.developpez.net/forums/d676074/autres-langages/pyt(...)
import win32com.client.dynamic
import win32com.client
from win32com.gen_py import *
import win32com.gen_py
import re
import marshal
import pickle
from email.feedparser import FeedParser
#Default Mapi profile
DEFAULT_MAPI_PROFILE = "Outlook"
TEMPORARY_FULL_PATH = 'C:\\dsporn\\software\\smtp\\tmp\\'
#
#
# This extends the smtps.SMTPServerInterface and specializes it to
# proxy requests onwards. It uses DNS to resolve each RCPT TO:
# address, then uses smtplib to forward the client mail on the
# resolved mailhost.
#
class SMTPService(smtps.SMTPServerInterface):
def initMapi(self):
self.outlook = win32com.client.dynamic.Dispatch("Outlook.Application")
self.mapi = self.outlook.GetNamespace("MAPI")
self.mapi_session = self.mapi.Logon(DEFAULT_MAPI_PROFILE)
def quitMapi(self):
self.mapi.Logoff()
self.mapi = None
def __init__(self):
self.savedTo = []
self.savedMailFrom = ''
self.shutdown = 0
self.initMapi()
def mailFrom(self, args):
# Stash who its from for later
self.savedMailFrom = smtps.stripAddress(args)
def rcptTo(self, args):
# Stashes multiple RCPT TO: addresses
self.savedTo.append(args)
def data(self, args):
data = args
#check for shutdown command
for addressee in self.savedTo:
toHost, toFull = smtps.splitTo(addressee)
# Treat this TO address speciallt. All because of a
# WINSOCK bug!
if toFull == 'shutdown@shutdown.now':
self.shutdown = 1
return
#sys.stdout.write('Adding recipient ' + toFull + '...\n\r')
#recipients.Add(toFull)
#
#
message = self.outlook.CreateItem(0)
#
#data parsing...
e_mail = self.getEmailMessage(data)
#header = self.getMessageRawHeader(args)
subject=e_mail['Subject']
dest_to = e_mail['To']
dest_cc = e_mail['Cc']
dest_bcc = e_mail['Bcc']
#
#recipientprocessing
recipients = message.Recipients
if (None != dest_to):
#print "To :\n\r"+dest_to
self.appendRecipient(recipients, dest_to, 1)
if (None != dest_cc):
#print "CC :\n\r"+dest_cc
self.appendRecipient(recipients, dest_cc, 2)
if (None != dest_bcc):
#print "BCC :\n\r"+dest_bcc
self.appendRecipient(recipients, dest_bcc, 3)
#
#subject processing
if (None != subject):
message.Subject = subject
else:
message.Subject = ""
#
#message processing
if (e_mail.is_multipart()):
#attachements = message.Attachements
#attache each textual parts to the messsage
the_body = ""
counter = 1
has_body = False
has_html_body = False
the_html_body = ""
for part in e_mail.walk():
if part.get_content_maintype() == 'multipart':
continue
filename = part.get_filename()
save_part = True
has_content_id = False
the_content_id = ""
#
# handle part that have no filename : it might
# be the content of the message body and inlined pictures...
if not filename:
#
# is it the plain text message body ?
if (False == has_body) and (part.get_content_type() == 'text/plain'):
the_body = part.get_payload(decode=True)
has_body = True
save_part = False
#
# is it the html text message body ?
elif (False == has_html_body) and (part.get_content_type() == 'text/html'):
the_html_body = part.get_payload(decode=True)
has_html_body = True
save_part = False
#
# maybe some media files (or something else)
else:
#
# Retrieve the content id if any
#
# Seems to be useless, as the com object seems to not
# expose the Fields attribute of the Attachment class...
if (None != part.has_key('Content-ID')):
has_content_id = True
the_content_id = self.getStripedContentId(part['Content-ID'])
#
# Guess extension
ext = mimetypes.guess_extension(part.get_content_type())
if not ext:
# Use a generic bag-of-bits extension
ext = '.bin'
filename = 'part-%03d%s' % (counter, ext)
if (save_part):
sys.stdout.write('Save part ['+filename+']...\n\r')
fp = open(os.path.join('.\\tmp', filename), 'wb')
fp.write(part.get_payload(decode=True))
fp.close()
attached_file = message.Attachments.Add(TEMPORARY_FULL_PATH+filename)
counter += 1
message.Body = the_body
if (has_html_body):
message.HTMLBody = the_html_body
else:
message.Body = e_mail.get_payload(decode=True)
sys.stdout.write('Sending message...\n\r')
message.Send()
self.savedTo = []
def quit(self, args):
if self.shutdown:
print 'Shutdown at user request\n\r'
sys.exit(0)
def getEmailMessage(self, data):
"""
instanciate a email.Message from the source data
"""
parser = FeedParser()
parser.feed(data)
return parser.close()
def appendRecipient(self, recipientObject, dataList, recipientType):
"""
split dataList and add items to recipientObject
"""
for dest in dataList.split(','):
dest = dest.strip()
recipient = recipientObject.Add(dest.strip())
recipient.Type = recipientType
def getStripedContentId(self, data):
hstart = string.find(data, '<')
if hstart != -1:
rv = data[hstart+1:]
else:
rv = data[:]
hend = string.find(rv, '>')
if hend != -1:
rv = rv[:hend]
else:
rv = rv[:]
return rv
def Usage():
print """Usage pyspy.py port
Where:
port = Client SMTP Port number (ie 25)"""
sys.exit(1)
if __name__ == '__main__':
if len(sys.argv) != 2:
Usage()
port = int(sys.argv[1])
service = SMTPService()
server = smtps.SMTPServer(port)
print 'Python SMTP to MAPI Relay Ready. (c)2009 David SPORN\n\r'
server.serve(service)
J'ai eu le temps d'améliorer un peu le prototype, en utilisant le package email notamment pour convertir les données brutes du mail en objet facilement manipulable.
Concernant la classe de base, j'ai rajouté le comportement correct pour la commande smtp "EHLO" : on renvoie la réponse 502, ce qui indique à Thunderbird que mon serveur est un serveur smtp et non esmtp (Google a été mon ami sur ce coup là, mais j'ai oublié de noter l'url)
L'extrait de code, à rajouter après la section traitant la commande "HELO" :
elif cmd == "EHLO":
return("502 Command not implemented", keep)
Et voici le code de mon serveur. Celui-ci gère maintenant les destinataire (to, cc, bcc), par contre, pour les mails en multiple partie (pièces jointes, texte html etc) je ne fais que concaténer les partie dont le type de contenu contient "text/". Quoiqu'il en soit, c'est maintenant utilisable pour le besoin de base, l'envoi d'un message ou d'une réponse à plusieurs.
# (c)2009 David SPORN
#
# A brain-dead Python SMTP to MAPI relay server based on the smtps, smtplib and mapi
# packages.
#
# DISCLAIMER
# You are free to use this code in any way you like, subject to the
# Python disclaimers & copyrights. I make no representations about the
# suitability of this software for any purpose. It is provided "AS-IS"
# without warranty of any kind, either express or implied. So there.
#
# Sources
# http://code.activestate.com/recipes/149461/
# smtps.py
"""
smtp2mapi.py -- A very simple & dumb Python SMTP to MAPI relay server. It uses
smtps for the server side and MAPI for the client side. This is
intended for use as a proxy to an Exchange server that is restricted to MAPI
(e.g. for 'security purpose').
This blocks, waiting for RFC821 messages from clients on the given
port. When a complete SMTP message is received, it connect to the
Exchange server using the Outlook OLE component, convert the
message and send it. Obviously, Outlook must be present.
All processing is single threaded. It generally handles errors
badly. It fails especially badly if DNS or the resolved mail host
hangs. DNS or mailhost failures are not propagated back to the client,
which is bad news.
The mail address 'shutdown@shutdown.now' is interpreted
specially. This gets around a Python 1.5/Windows/WINSOCK bug that
prevents this script from being interrupted.
"""
import sys
import smtps
import string
import smtplib
import email
import StringIO
import win32com.client.dynamic
import re
from email.feedparser import FeedParser
#Default Mapi profile
DEFAULT_MAPI_PROFILE = "Outlook"
#
#
# This extends the smtps.SMTPServerInterface and specializes it to
# proxy requests onwards. It uses DNS to resolve each RCPT TO:
# address, then uses smtplib to forward the client mail on the
# resolved mailhost.
#
class SMTPService(smtps.SMTPServerInterface):
def initMapi(self):
self.outlook = win32com.client.dynamic.Dispatch("Outlook.Application")
self.mapi = self.outlook.GetNamespace("MAPI")
self.mapi.Logon(DEFAULT_MAPI_PROFILE)
def quitMapi(self):
self.mapi.Logoff()
self.mapi = None
def __init__(self):
self.savedTo = []
self.savedMailFrom = ''
self.shutdown = 0
self.initMapi()
def mailFrom(self, args):
# Stash who its from for later
self.savedMailFrom = smtps.stripAddress(args)
def rcptTo(self, args):
# Stashes multiple RCPT TO: addresses
self.savedTo.append(args)
def data(self, args):
data = args
#check for shutdown command
for addressee in self.savedTo:
toHost, toFull = smtps.splitTo(addressee)
# Treat this TO address speciallt. All because of a
# WINSOCK bug!
if toFull == 'shutdown@shutdown.now':
self.shutdown = 1
return
#sys.stdout.write('Adding recipient ' + toFull + '...\n\r')
#recipients.Add(toFull)
#
#
message = self.outlook.CreateItem(0)
#
#data parsing...
e_mail = self.getEmailMessage(data)
header = self.getMessageRawHeader(args)
subject=e_mail['Subject']
dest_to = e_mail['To']
dest_cc = e_mail['Cc']
dest_bcc = e_mail['Bcc']
#
#recipientprocessing
recipients = message.Recipients
if (None != dest_to):
#print "To :\n\r"+dest_to
self.appendRecipient(recipients, dest_to, 1)
if (None != dest_cc):
#print "CC :\n\r"+dest_cc
self.appendRecipient(recipients, dest_cc, 2)
if (None != dest_bcc):
#print "BCC :\n\r"+dest_bcc
self.appendRecipient(recipients, dest_bcc, 3)
#
#subject processing
if (None != subject):
message.Subject = subject
else:
message.Subject = ""
#
#message processing
if (e_mail.is_multipart()):
#attachements = message.Attachements
#attache each textual parts to the messsage
the_body = ""
for part in e_mail.walk():
if (-1 != string.find(part.get_content_type(), 'text/')):
the_body = the_body + part.get_payload()
message.Body = the_body
else:
message.Body = e_mail.get_payload()
sys.stdout.write('Sending message...\n\r')
message.Send()
self.savedTo = []
def quit(self, args):
if self.shutdown:
print 'Shutdown at user request\n\r'
sys.exit(0)
def frobData(self, data):
hend = string.find(data, '\n\r')
if hend != -1:
rv = data[:hend]
else:
rv = data[:]
rv = rv + 'X-Sporniket: Python SMTP to MAPI Relay'
rv = rv + data[hend:]
return rv
def getSubject(self, data):
hstart = string.find(data, 'Subject: ')
if hstart != -1:
rv = data[hstart+9:]
else:
return ''
hend = string.find(rv, '\n')
if hend != -1:
rv = rv[:hend]
else:
rv = rv[:]
return rv
def getMessageRawHeader(self, data):
hend = string.find(data, '\n\r')
if hend != -1:
return data[:hend]
else:
return ''
def getMessageRawBody(self, data):
hstart = string.find(data, '\n\r')
if hstart != -1:
return data[hstart+2:]
else:
return ''
def getEmailMessage(self, data):
"""
instanciate a email.Message from the source data
"""
parser = FeedParser()
parser.feed(data)
return parser.close()
def appendRecipient(self, recipientObject, dataList, recipientType):
"""
split dataList and add items to recipientObject
"""
for dest in dataList.split(','):
dest = dest.strip()
recipient = recipientObject.Add(dest.strip())
recipient.Type = recipientType
def Usage():
print """Usage pyspy.py port
Where:
port = Client SMTP Port number (ie 25)"""
sys.exit(1)
if __name__ == '__main__':
if len(sys.argv) != 2:
Usage()
port = int(sys.argv[1])
service = SMTPService()
server = smtps.SMTPServer(port)
print 'Python SMTP to MAPI Relay Ready. (c)2009 David SPORN\n\r'
server.serve(service)
J'ai eu peur en lisant la dépêche, mais en lisant le lien "version de Microsoft", il me semble qu'au contraire ils ont l'air de faire les choses comme il faut, pour une fois.
Je reste méfiant -et anti microsoft primaire-, après tout microsoft a mis en œuvre des moyens pour le moins pas joli joli pour imposer la validation de son format OOXML par l'ISO, et est un adepte renommé du "embrace, extend, extinguish".
Pour être plus explicite, j'ai installé une version sortie depuis plus de 6 mois, au lieu de la dernière mouture qui venait juste de sortir quelques jour auparavant.
De plus c'est une version LTS que j'ai choisi.
Maintenant, au vu de l'affairisme exarcerbé de certaine firmes (Apple et Microsoft en particulier), j'ai décidé de pencher, pour mes projets perso, pour l'idéalisme.
Par ailleurs, je ne connais pas assez la licence de X.org, je ne sais pas si elle a passé le test des tribunaux, contrairement à la GPL.
Pour l'absence du texte GPL, c'est le manque de temps. En plus, comme les fichiers de configuration pour les autotools sont des modifs de l'exemple de pilote du site xorg, ces fichiers là sont soumis à une autre licence.
Ca me demande donc un petit travail, que je ferais prochainement.
Pour le choix de la licence, oui, j'ai bien réfléchi, et bien que l'idée d'avoir mon pilote éventuellement intégré à xorg soit trés séduisante, j'ai décidé de rester fidèle à ma licence de prédilection pour mes projets personnels, à savoir la GPL.
C'est un choix totalement idéologique, guidée par mon désir de protéger les utilisateurs contre la fermeture du code, et la GPL est une référence en la matière. Plus précisément, il se peut qu'un jour je sois moins généreux et veuille fermer le code. Le choix de la GPL est donc une assurrance-vie contre cet éventuel futur moi.
Je ne sais pas, mais étant donné que je pouvais m'en sortir avec un petit pilote de périphérique pour xorg, j'ai préféré utiliser ce moyen, plutot que de toucher à un fichier source du noyau.
Hé ben pas la mienne, ma dalle tactile est une TC4UM de chez ET&T. C'est un périphérique USB de classe HID, d'usage "Digitizer".
Mon installation ne créé pas de périphérique input ou event, mais un banal hiddev, et evtouch ne peut rien en faire... ("cannot grab device: bad ioctl machin chose")
Pour info, ci dessous quelques logs pour montrer ce que j'avais
M'enfin, maintenant, j'ai un pilote qui forctionne ^_______^
=== infos dmesg ===
[ 31.423618] usbcore: registered new interface driver hiddev
[ 31.428088] hiddev96hidraw0: USB HID v1.00 Device [ET&T Technology TC4UM] on usb-0000:00:1d.2-1
[ 31.428101] usbcore: registered new interface driver usbhid
[ 31.428104] /build/buildd/linux-2.6.24/drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
=== ma règle udev ===
ATTR{idVendor}=="0664", ATTR{idProduct}=="0306", SYMLINK+="input/touchscreen"
=== contenu de /var/log/Xorg.0.log ===
...
(**) EVTouch TouchScreen: always reports core events
...
(II) evaluating device (EVTouch TouchScreen)
(II) XINPUT: Adding extended input device "EVTouch TouchScreen" (type: TOUCHSCREEN)
...
(**) Option "Device" "/dev/input/touchscreen"
(EE) EVTouch TouchScreen: Unable to grab device (Inappropriate ioctl for device).
j'ai l'impression que l'ecran accroche moins le gras des doigts que la coque du portable, mais il faut prevoir les petites lingettes ou le spray de produit qui va bien.
"Non la java trap c'était que la communauté du logiciel libre n'a jamais été foutue de se sortir les doigts du cul pour faire une implémentation qui passe le TCK."
Pas forcément une histoire de flemme : pour s'assurer de développer sans problème de propriété intellectuelle, il fallait ne pas avoir regardé les sources de chez Sun. Or, le jdk embarquait le code source de Swing. A partir du moment ou on avait regardé ce source, "pour voir comment ça marche", on ne pouvait plus participer au développement des réimplémentation libre de ses classes. Et donc, moi je n'ai pas pu participer...
[^] # Re: Quoi de mieux que Digikam?
Posté par David Sporn (site web personnel) . En réponse au journal Mémoire Persistante, mon gestionnaire d'impression de photos. Évalué à 1.
Je me répond à moi-même, après essai, les possibilité de l'assistant d'impression de digikam ne répondent pas à mon besoin, tel que je l'envisage, ou alors je n'ai pas trouvé.
C'est même pire que ce que je pensais : l'assistant ne respecte pas la rotation spécifiée par l'image.
Pour info, mon programme arrange les photos de la façon suivante (pour le mode portrait seulement, actuellement) :
* on accumule au plus deux images (si on en trouve une deuxième) orientées paysage.
* on imprime en pleine page les images orientées portrait.
[^] # Re: Quoi de mieux que Digikam?
Posté par David Sporn (site web personnel) . En réponse au journal Mémoire Persistante, mon gestionnaire d'impression de photos. Évalué à 1.
J'ai cherché à voir cet assistant, j'ai trouvé un article qui le décrit là :
http://www.techrepublic.com/blog/opensource/a-little-known-digikam-tool-print-assistant/3795
(ce week-end, pas chez moi, donc pas en mesure d'éventuellement tester)
Ce que j'en vois, c'est que le layout serait identique pour toutes les pages, qui ne s'adapterait donc pas à l'orientation des photos ==> je vais devoir vérifier ce point, mais si ça ce confirme, ce n'est pas ce que je veux obtenir.
Plus l'absence d'entêtes/pieds de page.
[^] # Re: Quoi de mieux que Digikam?
Posté par David Sporn (site web personnel) . En réponse au journal Mémoire Persistante, mon gestionnaire d'impression de photos. Évalué à 1.
Tu as raté la capture d'écran, je l'ai faite ce matin, et elle devrait être visible sur la page du projet maintenant.
Concernant l'existant, je n'ai testé que Shotwell qui est installé de base sur Ubuntu, et côté web les gestionnaires de Facebook et Google.
Mon test de Shotwell, bien qu'agréable, a été de courte durée, car je pense que ça ne va pas convenir avec le fait que j'ai 2/3 backup de mes archives photos, et aussi en prévision d'un changement de machine. Bref, pour l'essentiel, c'est la portabilité des données.
J'aurais bien aimé stocker mes annotations dans les méta-data de la photo (je vois que digikam le fait), mais j'ai découvert le bordel que c'est (EXIF, XMP, méta-data proprio) et j'ai pas envie de flinguer le fichier d'origine.
J'ai donc récemment conçu un format de fichier qui servirait à stocker ces annotations (cf le wiki)
Et puis dernièrement, ce que je veux obtenir, c'est un document imprimé contenant une sélection de photos, bien arrangées, avec les éventuels commentaires.
Enfin, c'est le prétexte de faire les choses à mon idée, car il y a un peu de ça quand même.
[^] # Re: Dommage ...
Posté par David Sporn (site web personnel) . En réponse au journal Nouvelle version de hidtouch, pilote xorg pour les écrans tactiles USB/HID. Évalué à 1.
Ce node et les données dépendent du noyau, pas de xorg.
Quant aux librairies xorg et autres, ils s'agit de librairies ''systèmes'' et donc n'ont pas besoin d'être incluses dans mon package.
[^] # Re: juste une question..
Posté par David Sporn (site web personnel) . En réponse au journal Nouvelle version de hidtouch, pilote xorg pour les écrans tactiles USB/HID. Évalué à 1.
J'utilise un mélange de 'casse de chameau' et des '__' (double souligné). J'utilise les doubles soulignés pour simuler les espaces de nom et les classes (on est en C).
Cette écriture rend les identifiants des fonctions et des symboles très longs, verbeux même, de sorte que la limitation à 78 caractères pourrait se révéler inapplicable de temps à autres.
[^] # Re: Dommage ...
Posté par David Sporn (site web personnel) . En réponse au journal Nouvelle version de hidtouch, pilote xorg pour les écrans tactiles USB/HID. Évalué à 5.
Dans des cas moins bon, il peut adapter le code à son système (ou engager quelqu'un pour le faire).
Ce n'est pas comme si je diffusais un blob binaire.
[^] # Re: quel hardware ?
Posté par David Sporn (site web personnel) . En réponse au journal Nouvelle version de hidtouch, pilote xorg pour les écrans tactiles USB/HID. Évalué à 2.
À priori, ça fonctionne si les conditions suivantes sont remplies :
- un node 'hiddevX' (X étant un nombre) est créé pour le périphérique
- les coordonnées X, Y et la pression sont envoyés dans des rapports hid de code différent (utiliser l'utiliter 'hidDeviceDump', à télécharger)
0n ne gère pas de niveau de pression, on ne s'intéresse qu'au fait que la valeur soit nulle ou pas.
# 3eme version
Posté par David Sporn (site web personnel) . En réponse au message Un prototype de relais SMTP vers MAPI en python. Évalué à 1.
# explication de maitre eolas...
Posté par David Sporn (site web personnel) . En réponse au journal présence des députés. Évalué à 1.
cf la deuxième question de la faq de l'article.
# 2eme essais
Posté par David Sporn (site web personnel) . En réponse au message Un prototype de relais SMTP vers MAPI en python. Évalué à 1.
# layout bépo...
Posté par David Sporn (site web personnel) . En réponse au journal La touche ctrl de droite. Évalué à 3.
# Et un choix "autre smartphone" ?
Posté par David Sporn (site web personnel) . En réponse au sondage Mon téléphone mobile. Évalué à 1.
[^] # Re: Toujours pas...
Posté par David Sporn (site web personnel) . En réponse à la dépêche En vrac : ODF by MS, Torcs, FireUnit, Facebook et le libre, Project:Possibility. Évalué à 3.
Je reste méfiant -et anti microsoft primaire-, après tout microsoft a mis en œuvre des moyens pour le moins pas joli joli pour imposer la validation de son format OOXML par l'ISO, et est un adepte renommé du "embrace, extend, extinguish".
[^] # Re: La qualité d'abord
Posté par David Sporn (site web personnel) . En réponse au journal Vitesse vs. Qualite, vous choisissez quoi ?. Évalué à 1.
Pour être plus explicite, j'ai installé une version sortie depuis plus de 6 mois, au lieu de la dernière mouture qui venait juste de sortir quelques jour auparavant.
De plus c'est une version LTS que j'ai choisi.
# La qualité d'abord
Posté par David Sporn (site web personnel) . En réponse au journal Vitesse vs. Qualite, vous choisissez quoi ?. Évalué à 2.
Par exemple, je suis passé à Ubuntu 8.04 en octobre.
[^] # Re: License
Posté par David Sporn (site web personnel) . En réponse au journal Nouvelle version de hidtouch, pilote xorg pour les écrans tactiles USB/HID. Évalué à 1.
Maintenant, au vu de l'affairisme exarcerbé de certaine firmes (Apple et Microsoft en particulier), j'ai décidé de pencher, pour mes projets perso, pour l'idéalisme.
Par ailleurs, je ne connais pas assez la licence de X.org, je ne sais pas si elle a passé le test des tribunaux, contrairement à la GPL.
[^] # Re: License
Posté par David Sporn (site web personnel) . En réponse au journal Nouvelle version de hidtouch, pilote xorg pour les écrans tactiles USB/HID. Évalué à 2.
Ca me demande donc un petit travail, que je ferais prochainement.
Pour le choix de la licence, oui, j'ai bien réfléchi, et bien que l'idée d'avoir mon pilote éventuellement intégré à xorg soit trés séduisante, j'ai décidé de rester fidèle à ma licence de prédilection pour mes projets personnels, à savoir la GPL.
C'est un choix totalement idéologique, guidée par mon désir de protéger les utilisateurs contre la fermeture du code, et la GPL est une référence en la matière. Plus précisément, il se peut qu'un jour je sois moins généreux et veuille fermer le code. Le choix de la GPL est donc une assurrance-vie contre cet éventuel futur moi.
[^] # Re: Triste
Posté par David Sporn (site web personnel) . En réponse au journal Test du MSI Wind 90 X Novell Suse Linux.. Évalué à 3.
[^] # Re: Selon mes infos
Posté par David Sporn (site web personnel) . En réponse au journal Nouveau pilote xorg pour les écrans tactiles USB/HID. Évalué à 1.
[^] # Re: Selon mes infos
Posté par David Sporn (site web personnel) . En réponse au journal Nouveau pilote xorg pour les écrans tactiles USB/HID. Évalué à 1.
Mon installation ne créé pas de périphérique input ou event, mais un banal hiddev, et evtouch ne peut rien en faire... ("cannot grab device: bad ioctl machin chose")
Pour info, ci dessous quelques logs pour montrer ce que j'avais
M'enfin, maintenant, j'ai un pilote qui forctionne ^_______^
=== infos dmesg ===
[ 31.423618] usbcore: registered new interface driver hiddev
[ 31.428088] hiddev96hidraw0: USB HID v1.00 Device [ET&T Technology TC4UM] on usb-0000:00:1d.2-1
[ 31.428101] usbcore: registered new interface driver usbhid
[ 31.428104] /build/buildd/linux-2.6.24/drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
=== ma règle udev ===
ATTR{idVendor}=="0664", ATTR{idProduct}=="0306", SYMLINK+="input/touchscreen"
=== contenu de /var/log/Xorg.0.log ===
...
(**) EVTouch TouchScreen: always reports core events
...
(II) evaluating device (EVTouch TouchScreen)
(II) XINPUT: Adding extended input device "EVTouch TouchScreen" (type: TOUCHSCREEN)
...
(**) Option "Device" "/dev/input/touchscreen"
(EE) EVTouch TouchScreen: Unable to grab device (Inappropriate ioctl for device).
[^] # Re: evtouch
Posté par David Sporn (site web personnel) . En réponse au journal Nouveau pilote xorg pour les écrans tactiles USB/HID. Évalué à 1.
# pour info
Posté par David Sporn (site web personnel) . En réponse au journal Nouveau pilote xorg pour les écrans tactiles USB/HID. Évalué à 2.
c'est le numero de bouton qui était erroné dans l'appel a xf86PostButtonEvent (3e param, de mémoire): le bouton gauche a pour code 1 et non 0.
[^] # Re: L'écran ne se salit pas trop ?
Posté par David Sporn (site web personnel) . En réponse au journal Nouveau pilote xorg pour les écrans tactiles USB/HID. Évalué à 1.
# Ce que j'en pense...
Posté par David Sporn (site web personnel) . En réponse au journal Dredi : Ubuntu, AMD/ATI et drivers propriétaires. Évalué à 3.
[^] # Re: Pas de Mono pour moi...
Posté par David Sporn (site web personnel) . En réponse à la dépêche Mono 2.0 : le singe continue ses grimaces. Évalué à 4.
Pas forcément une histoire de flemme : pour s'assurer de développer sans problème de propriété intellectuelle, il fallait ne pas avoir regardé les sources de chez Sun. Or, le jdk embarquait le code source de Swing. A partir du moment ou on avait regardé ce source, "pour voir comment ça marche", on ne pouvait plus participer au développement des réimplémentation libre de ses classes. Et donc, moi je n'ai pas pu participer...