Possible ?

Programmation
#1

Bonjour,
J’ai une idée de faire un logiciel, il devra fonctionner comme un site web sous un navigateur, mais en forme de logiciel.

Il sera/devra être accessible qu’à partir du logiciel.

Pour exemple, imaginer un logiciel, vous l’ouvrez et vous avez exactement ce site debian-fr.org à l’intérieur, fonctionnement pareil et rien d’autre.

Est-ce possible de faire cela ?

Si oui:
J’aimerais le faire fonctionner aussi sous windows en plus de linux (debian).
(95% seront des utilisateurs de windows (malheuresement))

Quel(s) langage(s) utilisé ?

Aurais-je besoin d’autre(s) chose(s) ?
Exemple, pour site web codé en php/mysql, on aura besoin de: apache2, php, mysql.

Pour info, je m’y connais:

  • html, css, php, mysql (pour création site web, plusieurs années d’expérience)
  • visual basic (que j’apprends à l’école cet année (très malheureusement))

Je suis prêt à apprendre depuis 0 le language qu’il me faudra pour ce projet, sa me gène pas du tout, mais pas n’importe lequel.

Merci d’avance.

#2

Qt + Webkit : fonctionnera sur Linux, Windows, Mac.

Langages : C++, HTML / CSS / Javascript (voire PHP si tu as aussi besoin d’un serveur web central, cette partie n’est pas claire dans ta question). Tu peux peut-être remplacer le C++ par un autre langage qui a des bindings Qt (au hasard, Python) mais là je pourrai pas vraiment te conseiller.
Bases de données : à peu près ce que tu veux, mais si c’est pour une utilisation uniquement locale SQLite est assez facile d’utilisation / déploiement (ne nécessite aucune installation/administration d’un serveur, toute la base est contenue dans un seul fichier). Si t’as besoin d’un serveur central tu fais comme tu veux (MySQL, Postgre, …).

Si ton appli n’a pas besoin d’être connectée à internet je crois que tu peux assez facilement intégrer le “serveur web” directement dedans (aucun accès réseau, tu interceptes directement les requêtes HTTP) – à vérifier j’ai jamais fait ça, faudrait probablement dériver QNetworkAccesManager et QNetworkReply. Mais l’avantage d’un produit mixte C++/HTML comme ça c’est plutôt d’avoir une partie performante en C++ et une UI qui se met à jour “dynamiquement” à partir d’un serveur web central. Ou tu dois aussi pouvoir faire un mélange entre le contenu web centralisé, web local et natif local.
Les objets C++ sont utilisables à partir du code Javascript et vice-versa, ce qui présente de gros avantages si tu as un serveur web central pour fournir du contenu (mise à jour transparente du code Javascript). Tu peux aussi intégrer des widgets Qt (éléments d’UI plus ou moins complexes) dans les pages web affichées donc tu as une vraie “interface riche”.

Par contre si tu as un serveur web central pour distribuer du contenu le vrai problème ça va être de restreindre son usage à ta seule application, ça va être assez compliqué vu que ça reste du HTTP qui te produit du HTML (non, les secrets partagés entre ton appli et le serveur ne fonctionnent pas : le réseau ça se sniffe et même si tu passes en SSL pour empêcher ça, il restera toujours le désassemblage du programme lui-même car celui-ci est obligé de connaître le secret, et tout ça dans le “meilleur” des cas pour toi, à savoir si tes sources restent fermées). Ça dépendra aussi :

  • du public visé (B2B ? Grand public ?), car les entreprises ont assez peu de temps à perdre pour essayer de contourner ce genre de protections (faut quand même que ça reste sécurisé mais c’est encore une autre question)
  • du niveau de “protection” que tu veux (mettre des bâtons dans les roues de Mme Michu, ou bien empêcher complètement un bricoleur professionnel pourtant bien décidé à y arriver)
  • est-ce que ça sera Open Source ? (là ça va être encore plus compliqué :smiley:)

Gros inconvénient de cette solution : la courbe d’apprentissage C++ / Qt qui sera très longue étant donné le nombre de technos en jeu… :confused:

#3

Ce que tu cherche c’est prism non ?
prism.mozillalabs.com/

#4

Merci pour vos réponses.

Pour répondre à MisterFreez,
Oui c’est ce que je veux, mais pas d’une manière à avoir accès aux site web globalement dans une application et dépendre d’une application comme firefox ect.

Je veux que l’application englobe que mon projet, qui ne sert à rien d’autre, et bien entendu, je veux qu’il soit le plus personnalisable possible, c’est pour cela que j’aimerais le coder depuis 0, et même jusqu’à apprendre de nouveaux langages.

Pour répondre à syam,
Pour être courtois.
Un site web normal fonctionne comme ceci en résumer:
-Côté serveur, apache2-php-mysql tourne en fonction de la programmation du site, les info venant du client, et envoie les résultats html au client.
-Côté client, sous navigateur, il accède le site, il reçoit les info html et l’affiche.

Donc ce que moi je dois faire:

  • côté serveur, faire une programmation, qui selon les info client, fera son travail, puis envoie les info au client.
  • côté client, affiche les info reçu du serveur et envoie les info du client selon ses actes.

Du côté serveur, si j’ai bien résonner, n’importe quel langage fera l’affaire du moment que les info sont traité et renvoyé au client sous forme d’html.
Exemple: serveur: apache2, mysql et php, l’application client se connectera à apache2 et recevra les données html.

Du côté client je dois programmer une application qui supportera l’html, affichage et exécution.
Affichage: les html reçu par le serveur.
Exécution: exemple, l’envoie d’un commentaire sous “form” devra être envoyer au serveur comme sous un navigateur.

Et donc la j’ai plusieurs question si j’ai juste jusqu’à la:

  • il va falloir trouver un langage qui fonctionnera autant sous debian que sous windows
    (apprendre 1 langage différent pour linux et pour windows me sera dure, donc je veux qu’il y ai un langage commun)
  • il va falloir un support qui me permettra de faire fonctionner le code html sous l’application client, j’y ai penser un truc comme le navigateur Uzbl, un truc léger qui me permettra de faire fonctionner le code html dans l’application (je m’y connais strictement rien) les truc gecko ect donc le plus minimal possible.
#5

Oui merci, je sais comment fonctionne le web. :wink:

Si j’ai autant détaillé c’est que dans ta question d’origine il y avait un point qui n’était pas clair pour moi : est-ce que tu as besoin d’un serveur web central pour distribuer du contenu, ou bien est-ce que tout se passera en local.

[quote=“kripteks”]Du côté client je dois programmer une application qui supportera l’html, affichage et exécution.
[…]
Et donc la j’ai plusieurs question si j’ai juste jusqu’à la:

  • il va falloir trouver un langage qui fonctionnera autant sous debian que sous windows
    (apprendre 1 langage différent pour linux et pour windows me sera dure, donc je veux qu’il y ai un langage commun)
  • il va falloir un support qui me permettra de faire fonctionner le code html sous l’application client, j’y ai penser un truc comme le navigateur Uzbl, un truc léger qui me permettra de faire fonctionner le code html dans l’application (je m’y connais strictement rien) les truc gecko ect donc le plus minimal possible.[/quote]
    C’est exactement ce dont je parlais : une appli cross-platform hybride client lourd / client léger, écrite en C++ et qui repose d’une part sur Qt (un toolkit d’interface utilisateur) et d’autre part sur Webkit (le même moteur qui est utilisé par Chrome et Safari) car les deux sont très bien intégrés ensemble. Pour une utilisation “de base” (la même chose qu’un navigateur, ni plus ni moins) y’a presque rien à coder, mais ça offre en plus des possibilités d’intégration qui peuvent être très intéressantes selon ce que tu veux faire. Les 2 premiers paragraphes de mon message précédent donnent plus de détails à ce sujet.

Malgré tout y’a toujours une chose qui me chiffonne :

[quote=“kripteks”]J’ai une idée de faire un logiciel, il devra fonctionner comme un site web sous un navigateur, mais en forme de logiciel.
Il sera/devra être accessible qu’à partir du logiciel.[/quote]
Comment est-ce que tu comptes empêcher un navigateur classique d’accéder à ton site vu que tu vas utiliser exactement les mêmes protocoles ? Voir le 3ème paragraphe de mon message précédent pour les questions que ça soulève.
Sur ce point je ne pense pas qu’une solution comme Prism réponde à ton besoin car ce n’est pas fait pour.

L’avantage d’une appli hybride natif/web c’est que tu peux coder certaines fonctionnalités directement dans l’appli et faire appel à elles depuis l’environnement web. Conséquences :

  • interface enrichie si tu en as besoin
  • les opérations lourdes côté client pourront être optimisées en C++
  • certaines fonctionnalités indispensables à l’ensemble pourront n’être présentes que dans l’appli (soit codées en C++ soit en Javascript) ce qui fait qu’un navigateur classique qui se connecterait à ton serveur web ne pourra pas en faire grand chose car il lui manquera du code

C’est plus clair maintenant ? :wink:

#6

:slightly_smiling: en fait je voulais décrire mon savoir toute en voulant expliquer la situation, comme sa, si je m’étais tromper sur mon savoir, on aurait pu me contredire, sinon je serais partie sur de mauvaise base.

[quote=“syam”]
Malgré tout y’a toujours une chose qui me chiffonne :

[quote=“kripteks”]J’ai une idée de faire un logiciel, il devra fonctionner comme un site web sous un navigateur, mais en forme de logiciel.
Il sera/devra être accessible qu’à partir du logiciel.[/quote]
Comment est-ce que tu comptes empêcher un navigateur classique d’accéder à ton site vu que tu vas utiliser exactement les mêmes protocoles ? Voir le 3ème paragraphe de mon message précédent pour les questions que ça soulève.
Sur ce point je ne pense pas qu’une solution comme Prism réponde à ton besoin car ce n’est pas fait pour.[/quote]
Tu as raison, j’avais pas trop penser ce côté là, je m’en souciais pas trop au début mais bien que la, je suis certain de ne pas vouloir.

Même si je peux pas empêcher ceci, je pourrais au moins le restreindre:
je pourrais faire un petit code, qui permet de vérifier si l’accès a été fait par navigateur ou par le logiciel, des truc du genre UniqueId, key ect…

Oui la je commences à mieux comprendre, faut que je relise et vois un peu les détails.

Sinon vu les détails du projet:
-serveur: client html --> apache/php/mysql --> client html
-client: serveur html --> application --> lecture,execution html

Est-ce que côté client, mon logiciel a t il vraiment besoin d’être codé en c++, de la je veux dire est-ce que sa vaut vraiment la peine d’apprendre ce langage pour ce logiciel ?

Car s’il y a d’autres alternatif sa pourrait m’intéresser.
J’ai toujours aimer vouloir apprendre perl (car je connais le php et linux le supporte et on sait faire des choses avec).
Ou autre, s’il n’y a rien, pas le choix c++ :smiley:

#7

[quote=“kripteks”]Même si je peux pas empêcher ceci, je pourrais au moins le restreindre:
je pourrais faire un petit code, qui permet de vérifier si l’accès a été fait par navigateur ou par le logiciel, des truc du genre UniqueId, key ect…[/quote]
C’est justement ça que j’appelais un “secret partagé” dans mon premier message, et ça n’offre pas vraiment de protection en réalité.

Moi je te proposais ça parce que c’est un environnement que je connais, et je sais que ça marcherait. Après, Qt et QtWebkit sont disponibles dans d’autres langages (Python entre autres) mais j’ai bien peur que l’intégration natif/web soit moins facile (en français : ton appli Python pourra certainement contrôler un minimum l’environnement Webkit, mais celui-ci ne pourra peut-être pas faire appel à du code Python). Cela dit apparemment tu n’as pas l’air d’avoir besoin d’une intégration aussi poussée donc ça n’est probablement pas gênant.

Et il y a aussi sûrement plein d’autres solutions tout aussi viables que Qt+Webkit. Tu cites par exemple uzbl, je ne le connais pas plus que ça mais leur approche a le mérite d’être très intéressante.

Mais bon ça vaut toujours la peine d’apprendre le C++… (ok, je suis pas forcément objectif :mrgreen:)

#8

En gros ça ressemble fortement a une console de gestion déporté ce que tu décris là !!! et dans ce cas c’est plus une application qui va discuter avec ton serveur via ssh avec des clé :033

#9

[quote=“syam”]
Malgré tout y’a toujours une chose qui me chiffonne :

[quote=“kripteks”]J’ai une idée de faire un logiciel, il devra fonctionner comme un site web sous un navigateur, mais en forme de logiciel.
Il sera/devra être accessible qu’à partir du logiciel.[/quote]
Comment est-ce que tu comptes empêcher un navigateur classique d’accéder à ton site vu que tu vas utiliser exactement les mêmes protocoles ? Voir le 3ème paragraphe de mon message précédent pour les questions que ça soulève.
Sur ce point je ne pense pas qu’une solution comme Prism réponde à ton besoin car ce n’est pas fait pour.[/quote]

En y relisant ce paragraphe plus exactement ci-dessous (et la réponse de Clochette avec ssh):
Comment est-ce que tu comptes empêcher un navigateur classique d’accéder à ton site vu que tu vas utiliser exactement les mêmes protocoles ?

Je me suis demander une chose (qui n’a rien à voir avec le fait d’interdire l’accès via navigateur):
Côté serveur.
Au lieu d’utiliser le protocole web et language web (php).
Je pourrais programmer le script qui effectuera la même tâche avec un langage du système directement intégrer comme le perl (qui est proche de php que je connais) (ou autres, c++).

Cela m’éviterais d’utiliser/installer apache2,php ect. (sauf mysql dont j’aurais toujours besoin (voir un autre alternatif (à voir après))).

Sa complique les choses en terme de mes non-connaissances, je dois faire des recherches voir comment je peux réaliser la communication entre le serveur/client et les dites code html serveur/client ect…

Sans oublier, j’avais oublier de répondre à une de tes questions licence que tu citais.

Je m’y connais pas trop sur les licences.

Je veux qu’il soit juste utiliser à la fonction que je le donne c-à-d, installer et comme dans notre exemple avoir le forum debian-fr.org dans l’application, l’utiliser et rien d’autre.

Et non comme debian/ubuntu copier/coller puis modifier à volonté pour son plaisir.

Peut-être plus tard, je pourrais rendre libre à x personne ou complètement plubique, ou bien qui sait, le vendre (bien que j’ai aucunement cet intention).