Pinaraf a écrit 3682 commentaires

J'ai aussi un E71 pour le boulot.

Voici mon avis :
- puce GPS très très peu précise (ie ne faîtes pas d'OSM avec)
- le symbian libre, tu rêves, tu l'auras jamais sur ton E71 (déjà que tu peux pas avoir une version récente du symbian proprio)
- coder sous linux pour cet E71 relève du miracle... ou de la folie. Et même avec Qt et Qt Mobility. J'vais essayer de faire un journal sur ça le jour où ça marchera...

il est probable que Linux - avec l'aide des applications qui seront portées - pourrait profiter pour progresser sur le segment des Netbooks et des Laptops
Fail.
Android n'a rien à voir, en espace utilisateur, avec un système Linux classique. Il n'est pas possible d'utiliser une application android sous un Linux "normal". De même, une application classique (qu'elle soit KDE, Gnome, X11 directement...) ne marchera pas sous android.

Le soucis c'est la taille du journal je pense... Ça fait limite journal-marquepage...

Ce phénomène est plus vieux que cela, on le trouvait déjà à l'époque de leur appareil sans réception téléphonique, l'aphone...

Envoyé depuis mon Intel/nVidia/BIOS/Grub/Linux/X11/Qt/KDE/KHTML/Konqueror avec mon Input/Keyboard/Logitech

Yep, dommage pour ton commentaire...
Au passage, petite note pour ceux qui veulent essayer pareil : tentez aussi un coup avec la version shareware d'IDA 5.7, elle est bien plus performante et plus pratique à utiliser... (dommage que ce logiciel coûte si cher)

Il y a quelques années, le projet boomerang était intéressant : http://boomerang.sourceforge.net/ (mort lui aussi)

Sinon dans mon cas l'inclusion au noyau devrait être assez simple puisqu'il s'agit d'une "extension" d'un pilote existant... Après s'il faut séparer le pilote dans un nouveau pilote ou un truc comme ça, ça ne devrait pas poser de problèmes non plus...

J'avais également lu ton article, mais Toshiba n'utilise pas du tout WMI apparemment (en tout cas je n'ai pas trouvé de WMI dans la DSDT).
À la limite j'aurais préféré du WM, ça aurait pu être plus simple je pense...
Dans le cas de Toshiba, vu l'horreur qu'est la fonction GHCI, la DSDT ne sert pas à grand chose je pense. Ou alors c'est dans une partie vraiment compliquée à comprendre, mais je doute que l'on puisse trouver les valeurs magiques sans le pilote windows.

Sinon j'ai envoyé un mail à un type contribuant au noyau chez toshiba, merci pour l'idée de vérifier le git log (j'ai fait qu'un grep sur le code du noyau...)
On verra le résultat.

Sic, je ne me suis basé que sur la date des différents documents.

À titre d'information, quand j'ai écrit le code dans le noyau, je me suis inspiré des autres pilotes de diodes... Et j'ai vu que le pilote dell_led est écrit par des employés de Dell directement...

J'étais tombé sur ce lien.
Ce site est vieux, et ils ne donnent même pas directement les documents.

Pour info, l'interface HCI est différente de la SCI.
La SCI permet de consulter/configurer le BIOS (ie. des changements permanents, comme par exemple l'ordre de boot de la machine), la HCI étant là pour manipuler dynamiquement le matériel.

J'ai oublié d'indiquer un lien, que j'ai trouvé hélas après avoir deviné le rôle du HCI...
http://www.buzzard.me.uk/toshiba/downloads/hci.pdf
C'est le document le plus complet à ce sujet à ma connaissance...

La version dans la norme est Differentiated System Description Table.

Raison de plus pour les plaindre

À ma connaissance, Qt est l'une des bibliothèques avec la meilleure documentation qu'il soit... Et vu les domaines couverts par les classes de Qt, c'est nickel quoi (Gtk ne couvre finalement qu'une partie de QtGui, il faut y ajouter la stl pour QtCore, libxml pour QtXml, libwebkit-gtk pour QtWebkit ... et la documentation sur tout ça n'est centralisée nulle part)

Quant à Solaris, ça vivote toujours autour des évolutions d'opensolaris, non ?
L'annonce n'est pas passée sur Linuxfr, mais depuis l'acquisition par Oracle, ça pue vraiment pour Solaris et OpenSolaris.
Notamment le groupe de direction d'OpenSolaris (? Opensolaris Governing Board), chargé de gérer les interactions avec la communauté, a menacé de se faire hara kiri si Oracle ne se bouge pas le cul pour au moins dire ce qu'il advient de solaris/opensolaris. La version 2010.1H, prévue comme son nom l'indique pour la première moitié de l'année 2010 (et encore, initialement c'était février, puis mars), n'est pas encore sortie... Aucune nouvelle version depuis 13 mois quand même...

Certes, mais ton application C n'est pas toute seule dans son coin.
Elle va par exemple lire l'adresse IP depuis la ligne de commande, ou dans une interface graphique, ou depuis un fichier de configuration.
Toutes les expressions régulières, tous les validateurs des champs... sont-ils corrects ?
Sinon Java a, depuis au moins Java 1.4.2 (flemme de remonter plus avant dans le temps), une classe InetAddress gérant l'IPv4 et l'IPv6...

Même maintenant, pour être portable proprement avec certains compilateurs tordus, pour avoir une gestion propre de l'unicode partout, une API "claire" et lisible... il vaut mieux faire des doublons de la STL.
Également, pour réaliser de l'introspection sans passer par le RTTI, le choix de moc me semble raisonnable.
Quand tu dis "gros morceaux de pré-processeur partout", je pense d'ailleurs que tu n'as pas vu de code en Qt depuis très longtemps...

Faut que je trouve comment se debarasser de cet héritage que je n'apprécie pas trop
Lequel ?
Tu peux n'hériter que de QWidget par exemple et faire ceci :

#!/usr/bin/env python
# -*- coding: utf-8 -*-

from PyQt4 import uic, QtCore, QtGui
import sys

class myForm(QtGui.QWidget):
def machin(self):
print "test !"

app = QtGui.QApplication(sys.argv)
(uiForm, container) = uic.loadUiType("test.ui")
chose = myForm()
uiGenerator = uiForm()
uiGenerator.setupUi(chose)
chose.show()
app.exec_()


Je vois pas pourquoi l'héritage de QWidget serait un problème…

Clic droit sur ta fenêtre, Change Signals/slots.
T'as alors une liste de slots avec un bouton + en dessous de la liste…

Tu dois me confondre avec quelqu'un d'autre. Moi j'ai juste dis que le binding était pourris.
Effectivement, mea culpa…

Sinon pour le chose.setupUi(chose), c'est un choix dans mon implémentation…
J'aurais pu/du créer un QWidget à part et faire chose.setupUi(mon_beau_widget)

Non... Je parle de PyQT depuis le départ.
Alors n'affirme pas que Qt n'a pas d'équivalent à GTKBuilder, affirme que PyQt ne fait pas bien son boulot en choisissant de ne pas implémenter de bindings pour QUITools…

Avec pygtk je n'ai JAMAIS utilisé directement la glib. Je n'ai jamais utilisé la variante de string de la GLib, ni les structures de données de la Glib. A l'époque ou j'avais fais un peu de PyQT, je devais instancier des QString pour faire correctement fonctionner l'unicode et il m'arrivait de devoir charger des QList ou autre.
Ce n'est plus le cas sur les dernières versions de PyQt, même en Python 2…

Sinon pour ton histoire de signaux et slots je vois pas non plus le problème…

Voici un exemple de code :

#!/usr/bin/env python
# -*- coding: utf-8 -*-

from PyQt4 import uic, QtCore, QtGui
import sys


app = QtGui.QApplication(sys.argv)
(f, c) = uic.loadUiType("test.ui")
class m(f, c):
def machin(self):
print "test !"

chose = m()
chose.setupUi(chose)
chose.show()
app.exec_()


Dans le fichier test.ui j'ai une fenêtre avec un slot machin() défini et connecté au clic sur un bouton… Et ça marche…

Ha en fait tu confonds Qt et les bindings Qt pour Python, c'est ça ?

Je vois pas le problème dont tu parles avec les évènements pour le déplacement de la souris. Moi je parle de la sélection de texte et de ses intéractions foireuses avec le buffer souris sur Gtk : https://linuxfr.org//~mildred/29854.html

- Le fait que Qt impose (c'est pas forcement vrai, mais c'est difficile de sortir du moule) vraiment la façon de penser Qt, l'utilisation de la lib Qt.
Tout comme Gtk impose l'utilisation de la glib. Je vois pas le problème.

Je n'aime pas non plus la présence de /media, /cdrom ou /selinux par exemple hein.
Mais /sys me semble logique et légitime, c'est tout…

De plus, il y a dedans des choses très utiles comme GTKBuilder, que Qt n'as pas.
Hoo fud.
Qt a Qt Designer pour dessiner les fenêtres, et QUILoader pour charger les .ui dynamiquement.

http://doc.trolltech.com/4.6/quiloader.html

Au moins Qt a un bon support du buffer souris.

La décision de normaliser et simplifier l'accès à la configuration des pilotes et du noyau te paraît stupide ? Fichtre !
Après, libre à toi de monter le sysfs où tu veux, même dans un /etc/sys si ça te plaît…

Il suffit d'utiliser le backend Qt pour OOo directement, non ?

Au passage, c'est mignon de taper sur /sys, mais ça date déjà de plus de 5 ans...
Gros coup de vieux, ça fait 7 ans…