Page 1 sur 1

Problème avec php-qt

Posté : 01 mars 2008, 00:59
par momox
Hello !
Après réflexion, je me suis décidé a tenter l'aventure Qt en utilisant la librairie php-qt qui fonctionne ma foi fort bien pour le moment.
Mais je suis confronté a un petit problème avec les slots personnalisés...
Hop, voila le code que j'ai fait:
<?php
if(!extension_loaded('php_qt')) {
	dl('php_qt.' . PHP_SHLIB_SUFFIX);
}
class window extends QWidget {
	const Q_OBJECT = null;
	public $slots = array('changerLargeur(int)', 'changerHauteur(int)');
	public $signals = array('valueChanged(int)');
	public function changerLargeur($largeur) {
		$this->setFixedSize($largeur, $this->height());
	}
	public function changerHauteur($hauteur) {
		$this->setFixedSize($this->width(), $hauteur);
	}
	public function __construct() {
		parent::__construct();
		$this->setFixedSize('200', '160');
		
		$hslider = new QSlider(Qt::Horizontal, $this);
		$hslider->setGeometry(10, 60, 150, 20);
		$hslider->setRange($this->height(), 600);
		
		$vslider = new QSlider(Qt::Vertical , $this);
		$vslider->setGeometry(160, 10, 20, 150);
		$vslider->setRange($this->width(), 600);
		
		$hlcd = new QLCDNumber($this);
		$hlcd->setSegmentStyle(QLCDNumber::Flat);
		$hlcd->display($this->height());
		
		$vlcd = new QLCDNumber($this);
		$vlcd->setSegmentStyle(QLCDNumber::Flat);
		$vlcd->move(0, 20);
		$vlcd->display($this->width());
		
		QObject::connect($hslider, SIGNAL('valueChanged(int)'), $hlcd, SLOT('display(int)'));
		QObject::connect($vslider, SIGNAL('valueChanged(int)'), $vlcd, SLOT('display(int)'));
		QObject::connect($hslider, SIGNAL('valueChanged(int)'), $this, SLOT('changerLargeur(int)'));
		QObject::connect($vslider, SIGNAL('valueChanged(int)'), $this, SLOT('changerHauteur(int)'));
	}
}
//building app
$app = new QApplication(&$argc,$argv);
//building widget
$widget = new window();
//showing widget
$widget->show();
//executing application
$app->exec();
?>
En théorie, si executé en ligne de commande, il doit afficher une fenetre affichant deux sliders, et deux afficheur a segments.
Si l'on bouge un de sliders, cela modifie la hauteur ou la largeur, selon le slider déplacé.
Mais le problème est que lorsque je commence a déplacer mon slider, pfuuiiit ! Segmentation fault (Core dumped) dans la console...
Farfouillant sur le web, j'ai vu que en C++ pour utiliser les custom slots, il fallait charger la macro Q_OBJECT, ce qui n'est pas possible en php...
Donc je me demandais si parmi vous quelqu'un aurait deja touché a ce coté sombre et peu exploré de php que sont les interfaces en Qt.
Merci d'avance ;)

Posté : 01 mars 2008, 01:39
par Sékiltoyai
Alors ca ne va peut être pas t'avancer, mais c'est complètement débile de faire du graphique en php. Le php est fait pour du web, il n'est absolument pas adapté à de l'applicatif. Pour cela, on a de très bons langages parmi le C, le C++, ou bien en interprété le Python ou le java, mais absolument pas le PHP.
Et au passage, je me demande ce qui est passé par la tête de ceux qui ont fait les librairies gtk et qt pour php…

Posté : 01 mars 2008, 10:49
par momox
Alors ca ne va peut être pas t'avancer, mais c'est complètement débile de faire du graphique en php. Le php est fait pour du web, il n'est absolument pas adapté à de l'applicatif. Pour cela, on a de très bons langages parmi le C, le C++, ou bien en interprété le Python ou le java, mais absolument pas le PHP.
Et au passage, je me demande ce qui est passé par la tête de ceux qui ont fait les librairies gtk et qt pour php…
Peut être d'apporter la possibilité aux programmeurs web de pouvoir faire facilement des interfaces graphique en qt ou gtk sans avoir a apprendre d'autres langages non ? ;)

Posté : 01 mars 2008, 17:04
par Sékiltoyai
Peut être d'apporter la possibilité aux programmeurs web de pouvoir faire facilement des interfaces graphique en qt ou gtk sans avoir a apprendre d'autres langages non ? ;)
Ce n'est pas les aider que de faire ca. Toute ta vie, tu ne vas connaître que le php et tu vas faire tout et n'importe quoi en php (coder un serveur en php, c'est techniquement possible, mais personnellement je l'utiliserais pas…). Faire du php qui se "compile", autoriser l'utilisation de librairies graphiques, et j'en passe, c'est cantonner ceux qui ne connaissent que le php parce qu'il faut l'avouer, c'est un langage très simple d'utilisation, au php.

Alors qu'une attitude responsable aurait été de ne pas fournir ces librairies pour forcer le développeur à prendre un langage un tant soit peu plus adapté. C'est pour ces raisons qu'il est pour moi abhérent de proposer ces librairies.

heun

Posté : 05 oct. 2008, 08:56
par darkloy
Désolé, je ne veux pas foutre le bordel, mais on est quand même en démocratie, le monsieur ce décarcasse et essaye de trouver une solution pour faire avancer son projet le plus rapidement j'imagine ,vaux mieux pas trop le décourager .Je suis quand même d'accord avec toi Sékiltoyai, je pense que le php-qt justement est une passerelle à la programmation d'applications fenêtrées, après si ce monde lui plaît, il pourras toujours ce tourner vers du C, du Java...Et je suis pas d'accord avec toi sur la "facilitée" du php, j'ai appris plusieurs languages, et si on travaille sur un vrai projet web en php, il est pas "plus facile" (ok, en dehors de la gestion du client, les threads, mémoire....) que d'autre langages...

Posté : 05 oct. 2008, 10:26
par Sékiltoyai
C'est un langage de très haut niveau, assez proche des considérations humaines. Cela veut dire que n'importe qui peut faire quelquechose avec très rapidement, ce qui n'est pas vrai en C ou assembleur. Après, je suis d'accord qu'il faut du temps pour assimiler les subtilités, comme dans tout langage, mais cela reste tout de même un langage très facile puisqu'il oublie une quantité impressionnante de contraintes. Et c'est d'autant plus vrai en CLI, puisqu'il n'y a même plus à s'occuper des problèmes relatifs au net…

Posté : 05 oct. 2008, 15:43
par fab
Et si l'interet était de coupler un applicatif graphique à un applicatif web ?

Le concept de webappli est aujourd'hui encore loin d'être bien intégré dans la tête des gens, et par exemple j'ai vu un projet ( en java ) ou l'on devait concevoir une interface d'administration pour un site mais en graphique.
Imagine le temps que tu peux gagner à utiliser les classes métiers etc... déjà présentes dans l'applicatif web si tu utilises php-qt :)
C'est un des aspect je pense les plus intéressant :)


Mais après faut aussi avouer que plus la puissance des machines évolue plus les devs se font dans des languages de haut niveau, imagine il y a 5-6 ans ce que represénté le java à savoir une belle usine à gaz, aujourd'hui combien de personnes utilisent des logiciels en java tel que Eclipse, Azureus ou autre :)

Posté : 06 oct. 2008, 14:38
par JeanMarc31
Alors ca ne va peut être pas t'avancer, mais c'est complètement débile de faire du graphique en php. Le php est fait pour du web, il n'est absolument pas adapté à de l'applicatif. Pour cela, on a de très bons langages parmi le C, le C++, ou bien en interprété le Python ou le java, mais absolument pas le PHP.
Et au passage, je me demande ce qui est passé par la tête de ceux qui ont fait les librairies gtk et qt pour php…
Sékiltoyai, tu devrais pê passer du PHP 3 au PHP 5. Les choses ont évolué.
Si tu es déjà au PHP 5, ton avis démontre une méconnaissance partielle voire importante de PHP.
D'autre part dans le cas présenté ici on ne "fait" pas de graphique avec PHP puisque c'est la bibliothèque qui s'en charge.
Tu es sans doute un programmeur web, qui a une utilisation "page perso" du PHP. D'où effectivement ta position qui se conçoit, à l'aulne de la manière dont tu t'en sers.

Posté : 06 oct. 2008, 18:17
par Sékiltoyai
Sékiltoyai, tu devrais pê passer du PHP 3 au PHP 5. Les choses ont évolué.
Si tu es déjà au PHP 5, ton avis démontre une méconnaissance partielle voire importante de PHP.
D'autre part dans le cas présenté ici on ne "fait" pas de graphique avec PHP puisque c'est la bibliothèque qui s'en charge.
Tu es sans doute un programmeur web, qui a une utilisation "page perso" du PHP. D'où effectivement ta position qui se conçoit, à l'aulne de la manière dont tu t'en sers.
Ah la sale attaque. :)
Oui je suis au PHP5, depuis longtemps, et très à même de tout ce qui se fait autour de PHP. Mais que l'on soit clair, ce n'est pas parce qu'un langage développe des modules ou extensions qui sortent de son cadre habituel qu'il est adapté.
Question : As-tu déjà vu un serveur en PHP ? Pourtant on peut utiliser des sockets en PHP.
C'est un des nombreux exemples de quelquechose que l'on peut faire en PHP, mais qu'il serait une abbération technique.

Bref, pourquoi dis-je que PHP est spécialisé dans le Web :
- Parce qu'il intègre nativement depuis la nuit des temps des variables spéciales pour capter les données qu'il reçoit du navigateur ou du serveur.
- Parce qu'il possède de très nombreuses extensions orientées Web, comme des extensions spécifiques aux serveurs, de traitement de données XML, de bases de données.
- Parce que la configuration est clairement orientée Web, avec les upload_max_filesize, max_input_time, ou encore html_errors, voire, dans l'optique d'un environnement de production mutualisé et de haute performance, les fameux open_basedir, memory_limit, ou max_execution_time (et j'en oublie pas mal).

Et pourquoi dis-je que PHP n'est pas adapté à du standalone :
- Parce que c'est un langage de script.
- Parce qu'il n'est pas puissant.
- Parce qu'il ne gère à priori pas les thread.
- Parce qu'il a une faible interaction avec le système, notament le matériel ou les bibliothèques.

Bref, PHP est un langage de script optimisé pour le Web, et c'est en cela qu'il est le meilleur. Malgré l'ajout d'une forte composante objet, il reste un langage léger, qui peut supporter l'utilisation concourante de plusieurs centaines d'utilisateurs, mais qui n'a pas la puissance de C++, de java, ni même de Perl si on veut comparer à d'autres langages de script.

Après que l'on puisse faire des applications graphiques avec PHP, c'est un fait, mais pour moi c'est une connerie technique. Dans ma formation, on nous apprend à choisir une technologie adaptée pour lancer un projet sans aller dans le mur…

php serveur, sisi

Posté : 23 déc. 2008, 03:39
par DCmalcom
salut,

je me doit d'intervenir :)

j'ai vue plusieurs fois qu'il n'existe pas de serveur en php, oula, si tu savais !!!

je travail chez un opérateur télécom plutôt réputé dans son domaine qui à misé depuis quelques années de tout developper en php, mais vraiment tout, et je peut te dire que quand tu décroche ton téléphone, et bien ya un packet de php executé, et on arrive très bien à tenir plus de 1000 appels simultané avec très peut de serveurs ( 100% SIP ).

pourquoi ce choix, parce que php, çà va vite, très vite, un bug, réglé instantanément, parfois directement en prod, impossible avec un langage compilé, et tu me dira ya python, perl, ... oui, mais quitte à faire de l'interpréter, autant prendre le plus simple, accessible et souple.

et il ne faut pas négliger php, certe il a bien des défauts, on resent bien les developpeurs différents avec des conceptions différentes pouvant ammener à des comportement pas très logique parfois, on une méthode permettant de faire une chose et une autre ayant un nom indiquant faire le contraire, mais en fait non, ..., bref, le php est bien plus puissant qu'un simple langage web, il permet un programmation objet tout à fait suffisante pour répondre à la très très grande majorité des besoins, et il a des performance parfois non négligeable, n'oublions pas que php tape directement dans des libs en C, et ne servant finalement dans bien des cas, que de sur-couche de ces libs.

en espérant ne pas déclancher une polémique sur le rôle de php dans notre société ;)

ps : et nous on est encore au php4 ... passage au php5 difficile au vue de l'existant, on attent php6, qui ne devrait plus trop tarder.

Re: php serveur, sisi

Posté : 24 déc. 2008, 17:04
par Sékiltoyai
j'ai vue plusieurs fois qu'il n'existe pas de serveur en php, oula, si tu savais !!!
On aura tout vu…

Hé bien cela n'enlève en rien que si avec php on peut "tout" faire, ou peut aussi "tout" faire mal. Pour un serveur par exemple il n'y aura pas toutes les fonctionnalités de socket des librairies C, car en effet, ce n'est qu'une surcouche, qui sera dans tous les cas de piètre qualité par rapport à l'original…
Par ailleurs, ce n'est pas un hasard que les fonctions de socket passent dans les modules PECL depuis PHP 5.3…

Posté : 25 déc. 2008, 00:33
par Hywan
Hey :),

Au passage, PHP 6 n'est pas pour tout de suite …

Je suis aussi assez d'accord avec Sékil'. Déjà, il connaît très bien le PHP, et bien plus que les personnes qui en parlent ici.

Un langage c'est quoi ? C'est juste une syntaxe, une notation, qui permet de répondre à un problème particulier. Si le problème est de faire un solveur (ou prouveur selon les termes), on ne va pas utiliser PHP, mais plutôt OCaml. Si on veut faire de l'intelligence artificielle, bah du Prolog. Si on veut des applications multi plate-formes à forte sécurité, bah du Java. Si on veut faire de l'algorithmie poussée, bah du C. Si on veut faire du Web, bah du PHP (qui a dit ASP ?, que je l'étrangle …) !
Chaque langage répond à une problématique précise, et PHP, malgré tous les efforts pour GTK et Qt, ne répond pas à ce genre de contrainte. Ou alors, on utilise la syntaxe de PHP pour, mais c'est un fake, c'est du vent. PHP n'a pas cet objectif, c'est clair.

Un avantage de PHP que Sékil' a cité, c'est d'être un langage de script (quoi que, un bon langage fonctionnel et objet maintenant) puissant et rapide. Oui, il est interprété, mais il est incroyablement rapide. Et ça, c'est rare. Regardez Scheme, il est loin derrière PHP (désolé Docteur).
Je parle de PHP comme un langage objet car il a une couche objet très intéressante et poussée qui n'a rien à envier à d'autre langage objet. On garde la philosophie de PHP, mais avec de l'objet. Même si j'aimerais voir des fonctionnalités de Java ou C++ dans PHP, sa couche objet est largement suffisante. Sinon, pourquoi tous les frameworks bosseraient en objet ?
Je parle de PHP comme un langage fonctionnel car il l'est, nativement, mais que depuis la version 5.3, on a les lambda calculus et les clôsures, et ça, c'est cool.

Donc si quelqu'un veut se péter la tête avec PHP-Qt, c'est son problème, mais je commencerais d'abord par faire un bon environnement en ligne de commande avec PHP (ce qui fonctionne extrêmement bien, on arrive vite à de bon résultat), et pourquoi pas un peu de Java pour exécuter les lignes de commandes si certains trouvent ça … non ergonomique (même si je ne suis pas d'accord).