 |
| R3-hostkit installation et configuration sous windows | |
| shadwolf | 5-Jan-2011/12:50:44+1:00 |
| Je viens detester l'installation de R3-hostkit 110 avec code::blocks sous MS Windows (windows 7) Voici la marche a suivre: 1) Télécharger et installer Code::Blocks MinGW setup. http://download2.berlios.de/codeblocks/codeblocks-10.05mingw-setup.exe 2) Télécharger et décompresser l'archive R3hostkit https://download.github.com/carls-R3A110-a660e4a.zip 3) se rendre dans dossier_contenant_r3-hostkit\make-cbp\ et double cliquez sur le fichier r3.cpb. Code:blocks s'ouvre alors et vous montre le projet R3-host-kit. Dans Code:blocks : 1) dans le panneau de gauche présentant l'arboressance du projet cliquez sur le noeud "R3-host-kit" avec le bouton droit de la sourie et dans le menu qui apparait choisissez "Poperties". 2) Dans la fenetre "Project/terget properties" qui souvre alors, cliquez sur le bouton en bas a droite de cette fenêtre qui s'appel "Project's build options..." 3) dans cette nouvelle fenêtre "Build project options", Vérifiez que sur le paneau d'arboressence r3-host-kit soit sélectionné. Dans l'onglet "Compiler flag" au centre de cette fenêtre cliquer sur le sous onglet "#define" et après UNICODE ajouter " TO_WIN32". Valider/fermer les 2 fenêtres modales en cliquant sur les boutons "OK" de chacunes de ses fenêtres 4) lancer la compilation de teste: avec l'icone en forme de fleche verte dans la toolbar ou en appuyant sumiltanément les touches CTRL et F10. La compilation s'effectuera sans erreures et r3.exe sera lancé a la fin de son processus d'assemblage. | |
| shadwolf | 5-Jan-2011/12:58:11+1:00 |
| Pou linux / macosx ca devrait etre la meme procédure sauf qu'il vous faudra cahnger le TO_WIN32 de ce tutoriel par TO_LINUX et TO_MACOSX ... je n'ai pas testé donc à voir. A Faire: tester ce tutoriel pour linux et macosx et le propager sur le wiki rebolfrance, une fois complémenté des retours d'expérience sur linux et macosX. En suite pour développer notre propre R3-GUI il nous suffirait de crée un dossier wxw,gtk, qt, oGL, dans le projet r3-host-kit au meme niveau que source/win32 et a déposer dedans nos codes sources dedans. | |
| shadwolf | 5-Jan-2011/12:59:44+1:00 |
| Petite note quand même a l'heure ou j'ecris ses ligne pour linux et macOSX il n'y a que la partie r3 hostkit qui existe ne chercher donc pas a tester r3/GUI sur ces OS il n'y en a pas. | |
| shadwolf | 5-Jan-2011/13:39:19+1:00 |
| Pour simplifier les choses le R3-host-kit officiel est en retard par rapport au rma-host-kit. Pour obtenir le host-kit RMA (Rober Münch Asset? contenant donc R3/GUI en version de développement) allez ici: http://www.rm-asset.com/code/downloads/files/rma-host-kit.zip | |
| shadwolf | 5-Jan-2011/13:41:09+1:00 |
| Pour simplifier les choses le R3-host-kit officiel est en retard par rapport au rma-host-kit. Pour obtenir le host-kit RMA (Rober Münch Asset? contenant donc R3/GUI en version de développement) allez ici: http://www.rm-asset.com/code/downloads/files/rma-host-kit.zip | |
| shadwolf | 5-Jan-2011/13:42:09+1:00 |
| Si on se réfère a cette page on voit que c'est un beau boxon leur projet: http://www.rm-asset.com/code/downloads/ | |
| shadwolf | 5-Jan-2011/17:56:07+1:00 |
| pour les librairies graphiques possibles je propose : 1) GTK+ 2) GLUT/OPENGL 3) WxWindows 4) QT Il n'y pas là d'ordre de préférence toute ces librairies pour moi se valent... Si vous avec d'autre proposition de librairies graphiques portables (tcl/tk ? ce serait drole tiens ...) merci de les faire connaitres  .Le point important étant que ces librairies soient portable sur windows, linux et macOSX. | |
| shadwolf | 5-Jan-2011/18:04:18+1:00 |
| en regardant le code source je trouve scandaleux de casher les partie d'interface en rebol les fameux dialecte. Apparement voila comment marche rebol-host-kit. Pour ce que j'en ai compris. Il y a un dialect en rebol (caché) dans les fichiers header et il y a des enum qui ont pour but d'envoyer des signaux depuis le dialect rebol vers la librairie graphique C / CPP. Cette interface n'est absoluement pas documentée et le code rebol est caché j'ai pas encore découvert comment. Headers/src/include/host-ext*.h. Le code rebol étant mis dans une tableau de type const unsigned char RX_* Pour notre R3/GUI on aurait plusieur maniere de procedé la plus rapide probablement serait de modifier le contenu des fonction C qui sont appellées par le case switch et les divers signaux. En remplacent le code WinAPI32 par le code de la librairie de notre choix. | |
| nve | 5-Jan-2011/18:15:35+1:00 |
| Trop compliqué pour moi tout cela. Sinon, pour les librairies, je ne les connais pas trop. Je sais juste que QT a repris du poil de la bête par le biais de Nokia. Et même si Nokia n'est plus number 1 de la mobilité, leur projet de QT avec Maemo et retrocompatibilité sur Symbian me parait plutôt pas mal (ils ont pensé aux développeur en leur indiquant que leur projet fonctionneront sous QT tant sur Maemo que sur Symbian). En sachant qu'un groupement de constructeurs automobile a choisi la solution Maemo pour les systèmes embarqués, que l'europe a remis quelques millions d'euros dans Symbian... Je trouve que cela pourrait être un bon choix. My vote is for QT. -Nicolas | |
| shadwolf | 5-Jan-2011/18:21:36+1:00 |
| Maemo est devenu Meego !! et c'est soutenu par intel, nokia, amd. QT est pas mal parcontre sa licence est plutot chiante sachant que carl va probablement vendre une version R3 host-kit. En suite c'est une librairie C++ donc ca nous force a utiliser des interfaces pour l'intégrée au reste du code C (comme ca été fait pour AGG avec les appels sur extern C etc...). Je connais assez bien QT pour m'en être longtemps servie. | |
| nve | 5-Jan-2011/18:30:51+1:00 |
| Donc, il faut peut-être une librairie full C alors ? Mais je ne connais pas trop ce monde là en fait. | |
| shadwolf | 5-Jan-2011/18:33:08+1:00 |
| en fait c++ c'est du c mais plus plus ... quelques changement mineurs mais les 2 restent largement compatibles d'ailleurs AGG ecrit en C++ a été intégrée dans rebol. Un point en faveur de wxwindows c'est quelle ne dispose pas du support avancer de dessins résultat on pourrait garder AGG telquels. | |
| shadwolf | 5-Jan-2011/18:49:48+1:00 |
| Bon en fouillant encore dans le code source j'ai découvert ou ce cachait le vrai #define TO_osutilisé. 1) retire le TO_WIN32 des build options du projet 2) aller dans le fichier Headers/src/include/reb-to.h Mettez en commentaire le #define TO_LINUX et ajoutez à la suite: #define TO_WIN32 sauvegarder et recompiler le r3-host-kit | |
| deglingo | 5-Jan-2011/22:04:33+1:00 |
| Je ne connais pas du tout le monde des librairies graphiques, juste leur nom. En faisant une recherche sur Qt, je suis tombé sur ce super tutoriel en français pour ceux que ça intéresse : http://www.siteduzero.com/tutoriel-3-11240-introduction-a-qt.html | |
| none | 5-Jan-2011/23:05:41+1:00 |
| Bonjour je suis nouveau sur le forum, mais connais rebol depuis plusieurs annees. je vote pour glut/opengl pour licence,taille possibilités 3D. En plus niclassen a fait un truc interessant client/serveur (à la x-window) que l'on pourrait reprendre en simplifiant la partie cliente. L'inconvénient est que niclasssen veut pas partager le code du serveur... Sinon pour prolonger l'idée de fun, le meme principe client/serveur avec horde3D serait un bon délire, car ouvrirait les portes de la 3D à rebol... | |
| shadwolf | 6-Jan-2011/10:09:09+1:00 |
| none en effet opengl/glut me semble une bonne pioche... Voici les avantages: 1) c'est du C 2) très petite taille 3) Partabilité windows, linux, macosx 4) Glut ne fait que ce que win32API dans le code de rebol host kit fait. C'est a dire géré l'affichage offrir une boucle de gestion des évènements, et capter les entrée clavier / sourie. ah et offrir aussi un canevas de dessin permettant a opengl de dessiner sur sa surface. La question que je me pose c'est est ce que ce canvas permettrai aussi d'afficher les rendus AGG ? Gros avantage de basé R3/GUI sur cette librairie c'est de récuperer opengl... Evidement cela implique d'inventer un dialect dans l'esprit rebolien permetant d'utiliser les fonction opengl. | |
| deglingo | 6-Jan-2011/12:37:05+1:00 |
| Développer un dialect Rebol permettant d'utiliser les fonction OpenGL...ce n'est pas ce que RM-Asset est entrain de faire en ce moment, même si l'on a très peu d'infos ? (les "software wizards, highly talented people" comme ils se présentent sur la page principale de leur site : http://www.rm-asset.com/ - ça rigole pas ! ) | |
| shadwolf | 6-Jan-2011/15:38:50+1:00 |
| Deglingo en fait on peut voir le projet de librairies graphique pour rebol sous 2 angles distincts. Soit remplacer les appel vers la win32 api par des appels vers une autre librairie portable et qui supporte opengl - ce qui est le cas de GLUT, wxwindows, GTK+ et QT, toutes ses librairie dispose de canevas spécifiques permettant l'affichage de rendu opengl... Evidement Glut est surtout faite pour ca en fait-. Le dialect GUI alors reste inchangé ce qui tombe bien car j'ai pas trouvé comment y avoir accès. Je sais que les nouveaux systeme d'extension suposent que le dialect rebol soit externalisé et intégré au niveau des fichiers C/H. Enfin tout ca c'est super mal expliqué ils voudraient faire de la rétention d'information il ne s'y prendrait pas mieux... Faut faire l'analys du contenu de chaque fichier pour avoir un plan complet du contenu de l'extension. Je vois pas example que la librairie réseau a aussi été externalisée... Pourquoi ? mystère. Soit enrichir le dialect GUI en rajoutant au face un champ effect/opengl comme le effect/draw mais pour encapsuler du dialect rebol-opengl (ce qui serait le top intégrale) | |
| nve | 7-Jan-2011/22:05:59+1:00 |
| D'après ton post sur le topic de Rebol3, il faudrait prendre OpenTK. Car pour le projet MonoDroid, ils ont utilisé OpenTK. Ce qui permet d'avoir du Droid, iOS, Windows... | |
| nve | 8-Jan-2011/0:23:09+1:00 |
| Bouuuuu..... ca troll grave.... AltME, Kaj : "But I think the problem is that you want "the community" to do that work for you and profit from their work without doing anything yourself..." en s'adressant à qui vous savez...  | |
| paullys | 8-Jan-2011/9:49:46+1:00 |
| none devenu paullys: Inconvenients glut/openGL: sauf erreur la 2D, fonts.. demandent pas mal de travail. Je propose le dev d'un serveur et d'un client d'affichage, a base de glut/opengl avec un dialecte d'accés a ce serveur et un dialect de dev de ce serveur. Cela permettra de rester indépendant des lubbies de Sassenrath et nous évitera la honte de passer plus de temps a dev en C qu'en rebol. | |
| shadwolf | 8-Jan-2011/12:17:08+1:00 |
| c'est pour ca que dans cette optique garder AGG pour le rendu 2D sur la suface de la fenêtre me semble bien si on considère employez GLUT. De quoi a besoin opengl pour déssiner dans une fenetre GLUT ? d'un pixel buffer. Quoi a besoin AGG pour dessiner dans uns fenetre ? D'un Pixel buffer. Précisement je ne sais pas si on peut interfacer glut et agg quel en serait les performances, personne ne c'est jamais posé la question. Tout ce qu'on souhaite faire c'est du bricolage sur windows qui ne soit pas portable. Si Glut pose trop de problème on peut en revenir à GTK+ ou QT ou autre... Mais au moins faire l'effort de se poser des question d'avoir un débat constructif sur le sujet me semble un minimum. | |
| shadwolf | 8-Jan-2011/12:20:46+1:00 |
| paullys, j'aime bien l'idée d'une client rebol / serveur C pour traiter les données d'affichage. ca permettrait d'être complètement indépendant quand au choix de notre librairie on pourrait meme envisager serieusement un serveur fait en mono ou en java. ce qui nous eviterait meme d'avoir a recompiler notre serveur d'affichage d'une plateforme à l'autre. | |
| shadwolf | 8-Jan-2011/12:22:47+1:00 |
| on pourrait aussi introduire des processus threadé coté serveur. Rebol/core serait suffisant pour faire fonctionner ce système. Il faut donc decider d'un dialect, et voir quel librairie nous convient le mieux. | |
| shadwolf | 8-Jan-2011/12:28:10+1:00 |
| Il me semble que la librairie graphique de Mono soit GTK+. Donc faire notre serveur en Mono reviendrait à faire notre serveur pour GTK+. nve en meme temps quand je fais les choses je me fait snober. OpenTK moi j'aime déjà leur phrase d'introduction: The Open Toolkit is an advanced, low-level C# library that wraps OpenGL, OpenCL and OpenAL. | |
| shadwolf | 8-Jan-2011/12:30:46+1:00 |
| Environnement de programmation conseillé: SharpDevelop (windows) MonoDevelop (all os) visual studio .NET 2008(windows). | |
| shadwolf | 8-Jan-2011/12:30:47+1:00 |
| Environnement de programmation conseillé: SharpDevelop (windows) MonoDevelop (all os) visual studio .NET 2008(windows). | |
| shadwolf | 8-Jan-2011/12:33:10+1:00 |
| nve ce que kaj dit la ca vient après que je lui ai demander de m'indiquer la marche a suivre pour faire mon propre projet R3/GUI. | |
| shadwolf | 8-Jan-2011/12:35:15+1:00 |
| de toutes façon Kaj ne participe déjà a rien tout comme Oldes et les autres ... Il n'ont qu'un role de commentateur externe. Je le sais pertinament que si je lance un projet R3/GUI alternatif quelqu'en soit la forme je vais être seul à le faire... Et apres j'aurai ses charmantes personnes qui viendront encore me dire que je perd mon temps que ce que je fais est nul... | |
| paullys | 8-Jan-2011/13:53:35+1:00 |
| Oui mais en conservant AGG , on retombe sur tes remarques sur le manque de support de la library... Quand a GTK, mono, java trop lourd, trop lent...non? mieux vaut utiliser un subrebol, dll avec dialect côté serveur (case compilation minimale des que dialect au point) et dialect côté client. | |
| shadwolf | 8-Jan-2011/14:23:54+1:00 |
| trop lent faut pas exagérer non plus ... Mono et java sont installer par defaut sur unix. De très groooooos projets sont basés sur ces librairies. aller juste pour le fun voici un petit eventaille de TRès gros projets: MonoDevelop, Pirate Galaxy (mmorpg 3D en ligne sans installation qui fonctionne en java pure qui est donc portable et avec un niveau de graphisme et une fluidité ennorme), Jokosher (logiciel de traitement de son fait en python GTK+ par des non développeurs professionels... Voila quand les gens ne savent pas programmé et qu'ils veulent faire un gros projet ils prennent python et GTK+ et pas rebol ca c'est la vraie vie), Tux Guitare (logiciel portable fait en java qui permet d'afficher des partition et de les entendre via un synthétiseur intégré. Logiciel libre clonnant Guitare Pro et compatible avec ce logiciel)... lent lent ... booof... java mono et GTK+ ont des mise à jours bien plus souvent que rebol ca c'est aussi un fait indéniable. Ils sont donc de plus en plus rapide et simple d'emploi. On a pas non plus les pc merdique de la fin des années 90 ... en 98 mon pc perso etait un AMD K6 400Mhz avec de la sdram 100mhz. 12 ans plustard j'ai un Core i5 760 4 coueurs et 4 go de sdram DDR3 a 1.33 Ghz. Quand on voit le discours de promotion de rebol on a l'impression qu'il sont rester bloqué a l'epoque de la disquette 1,44 Mo, du processeur 80 486 DX @ 33 Mhz 64 mo de Ram ( 4 barette de 12 Mo) et windows 3.11 pour l'interface graphique et l'interface réseau... | |
| paullys | 8-Jan-2011/15:54:35+1:00 |
| Ce que je trouve intéressant dans la vision des dinosaures, c'est qui peut le moins peut le plus, donc si cela fonctionne sur une vieille machine, cela peut fonctionner sur une config musclée. En plus en dev sur les java, mono.. c'est que l'on prend de mauvaises habitudes: style intégrer toute une lib juste pour 2 fonctions. Et Enfin même si cela demande du travail pour GLUT/openGL en 2D, l'avantage c'est qu'ensuite pour passer en 3D on rajoute la dimension Z!!! J'ai dans le petit coin de la mémoire openCOBALT. Enfin je pense que REBOL il y a dix était en avance, et que cette avance a fondue. Il faut reprendre cet esprit avant-garde en ce projetant sur ce que sera une IHM dans dix pour faire les bons choix. Donc un opencoblat light and magic il me semble que le futur des IHM ressemble à cela. Donc si on troue de quoi faire comme je l'indiquais dans le fil sur rebolfrance on peut se lancer dans l'aventure. S'en suivrai un fork de rebol, dès que ce serveur serait opérant. Avec une vrai communauté, avec une gestion démocratique. | |
|
Login required to Post. | |