 |
| agar-gui | |
| shadwolf | 4-Jan-2013/21:28:11+1:00 |
| bon c est pas parce qu on est de retour qu on va commencer a mettre les pieds sur la table et a parler de tout dans un seul topic. ldci propose de baser un gui multi plateform sur agar. le jeu consite donc a essayer d adapter rebol a agar. c est a dire remplacer le fond de panier de r3gui qui contient des appels win32 par des appels de bas niveau d agar ce qui permettrai de simplement recompiler en liant la libagar sur les differents os pour avoir r3gui fonctionnant a l identique. ldci 4-Jan-2013/18:34:11+1:00 Une librairie en c qui pourrait grandement �tre intéressante pour rebol R3 ainsi que pour red Aller voir http://libagar.org/ shadwolf 4-Jan-2013/19:01:41+1:00 The AG_Driver interface makes Agar applications portable to a wide variety of platforms, APIs and graphics systems (in either vector or raster mode). Agar applications can work under window-based platforms (such as Xlib, Windows API and MacOS X Quartz/Cocoa), and non-window-based environments (such as an SDL context). Unlike most GUI toolkits, Agar takes maximum advantage of modern graphics hardware where it is available, minimizing movement of data between CPU and GPU. voila tout es dit on s y met quand ? ldci 4-Jan-2013/19:54:50+1:00 @shad. Allez on s'y colle.je regarde pour Mac OS à plus shadwolf 4-Jan-2013/20:29:06+1:00 bien a premiere vue au pif je dirait le plus gros truc a faire va etre de remplacer dans rebhost les appels a la w32api par des appels equivalent vers agar recompilation et hop la ... shadwolf 4-Jan-2013/20:51:42+1:00 les fichiers a regarder ldci sont dans r3/src/os/win32/ Commençons par faire une liste fichier / fonctions C est a dire, https://github.com/rebol/r3/tree/master/src/os/win32 host-event.c host-text.c host-window.c host-effect.c et host-window.c on va se concentrer sur ces fichier lister les fonctionnalités surtout win32 api et voir les equivalent dans agar. host-window.c pour commencer contient les appels vers la win32 api donc agar ca va etre pareil sauf que tu remplace win32 api et les focntions qui luis sont propre par agar. | |
| shadwolf | 4-Jan-2013/21:43:43+1:00 |
| hum en regardant le download du site je m appercoit que les distros de cete lib sont surtout pour windows. | |
| PierreCh | 4-Jan-2013/22:50:24+1:00 |
| hm, décevant. Quid d'une bibliothèque qui soit un peu plus connue, et qui soit réellement multi-plateforme? Je pense à Qt, par exemple. | |
| shadwolf | 4-Jan-2013/23:19:58+1:00 |
| Qt c est du C++ il faudrait un wrapper je pense ceci dit pkoir pas ... | |
| shadwolf | 4-Jan-2013/23:34:19+1:00 |
| parcontre on peut s inspirer de comment ils ont fait l interface avec les 3 main os et faire notre propre adaptation on a pas besoin d ennormement de chose juste avoir un contexte un bord de fenetre le reste c est agg qui s en charge | |
| ldci | 5-Jan-2013/0:50:39+1:00 |
| @Tous Peut être peut on simplement compiler la lib sous les différents os et importer les fonctions par un load/library ? | |
| sameeg | 5-Jan-2013/3:15:16+1:00 |
| En tant que rebol user de base et ayant conscience des défauts de r2View, sa compacité pour ouvrir une GUi et déléguer la gestion d'events est un bonheur total. Mettez un fond noir avec un léger dégradé et tout le monde est scotché par le design. (http://www.tmplab.org/wiki/index.php//tmp/bci/jackson#Screenshots) Partant pour beta tester sous OS x et Linux | |
| jocko | 5-Jan-2013/7:52:25+1:00 |
| dans ce style, il y avait le travail remarquable de Maxim avec Glass et Glayout. Remarquable par l'esthétique, et aussi par l'originalité technique. Quelqu'un sait-il s'il a le projet de le porter sur R3 ? | |
| ldci | 5-Jan-2013/15:31:06+1:00 |
| @sameeg Tirs dans le BCI? J'aimerais qu'on discute. J.ai compilé agar sous osx sans pbs. Restent quelques problèmes de lien pour les librairies à plus | |
| ldci | 6-Jan-2013/3:14:05+1:00 |
| Bien Quelques résultats de tests avec agar sous Mac OSX 10.8.2: Tout est compilé sans problème, mais attention: certaines libs comme SDL sont requises par défaut ./configure --enable-debug # Produce a debug build make depend all # dependance des libs sudo make install # l'usage du sudo est obligé sur mac OSX pour copier dans /usr/local les libs et les includes En suite j'ai compilé les démos dont certaines ne fonctionnent pas et induisent in segmentation fault: 11, c'est-à-dire un pointeur qui se perd dans les limbes. J'ai trouvé l'origine de cette erreur de ségmentation: la fonction AG_InitCore (const char *progname, Uint flags) The AG_InitCore() function initializes the AG_Core library. The optional progname argument sets an application name (this name may be used by ag_gui and AG_Core to set various platform-dependent defaults). progname may be set to NULL. Il ne faut utiliser de pointer NULL pour progrname, mais bien une chaine de caractères comme dans l'exemple suivant
#include <agar/core.h>
#include <agar/gui.h>
int main(int argc, char *argv[])
{
AG_Window *win;
if (AG_InitCore("Hello", 0) == -1 || AG_InitGraphics(0) == -1) {
fprintf(stderr, "%s\n", AG_GetError());
return (1);
}
win = AG_WindowNew(0);
AG_LabelNew(win, 0, "Hello, world!");
AG_WindowSetCaptionS (win, "Hello");
AG_WindowSetGeometryAligned(win, AG_WINDOW_MC, 800, 600);
AG_WindowShow(win);
AG_EventLoop();
return (0);
}
Ceci étant dit ce n'est pas auusi élégant que le VID de rebol ! Mais ça marche A plus | |
| sameeg | 6-Jan-2013/15:48:33+1:00 |
| @ldci : tmpbci sur gmail. | |
| ldci | 7-Jan-2013/13:43:24+1:00 |
| Suite des tests, Première bonne nouvelle, agar peut se compiler sur mac ppc et intel ainsi que sur linux et windows et n'est pas limitée à windows comme le pensait Shadwolf. Quelques libs sont requises: SDL, FreeType et OpenGL Dans l'état actuel des choses (R3 en 32 bits), ces libs sont à compiler avec un flag -m32. Néanmoins, R3 commence à être compilé en 64 bits également ce qui va permettre d'avoir différentes versions. Deuxième bonne nouvelles: agar dispose d'une gestion des threads (sous posix) plus que satisfaisante et en tout cas bien plus intéressante que l'asynchrone de Rebol 2. Ceci étant, je me lance pas tout seul dans ce chantier : help is needed !!! Qui pourrait tester agar 1.4.1 pour Linux et qui pour windows XP, Seven et 8 ? Allez à vos lignes de code  | |
| PierreCh | 7-Jan-2013/15:47:46+1:00 |
| Pour linux, je peux tester, oui, au besoin, et quand j'arrive à me dégager du temps. | |
| shadwolf | 7-Jan-2013/17:42:57+1:00 |
| ravi de savoir qu agar marche aussi pour macOSX. J avais rapidement survolé les sources et la page de download et n avait vu de mension que de win32 ou windows. bon niveau news: 01/07/2013 The 1.5.0 release is imminent (two years in the making, 1.8M lines of diff). Stay tuned! si on arrive a exploiter leur lib vu que c est un projet encore actif on pourra leur indiquer que leur lib nous sert de support pour r3-gui. Du coup il pourront alleger leur librairie en virant les widgets et se concentrer sur le portage des fonctions basiques. pendant que nous on refait les widgets avec rebol. | |
| shadwolf | 7-Jan-2013/17:46:29+1:00 |
| j ai linux donc je vasi tester la lib de ce pas. En suite comme je disait, je vois pas l interret d. avoir une lib avec pleins de chose qu on utilise pas (90% de la lib...) Donc une version LITE, c est a dire ne contenant que les parties dont on a besoin dans notre r3-gui serrait bien. Il y a un support opengl et sdl natif et ca aussi ca pourrait etre une grande avancee pour rebol/view. J aimerai que Maxime nous aide ou qu il nous dise ce qu il pense d agar. | |
| ldci | 7-Jan-2013/17:57:04+1:00 |
| Merci à ts les volontaires pour les tests Ceci étant je suis d'accord avec Shadwolf: pas besoin de toute la lib et personnellement je préférerais un bon VID maison A + | |
| shadwolf | 7-Jan-2013/18:25:01+1:00 |
| alors sur mon linux le ./configure passe plutot bien il y a un probleme de ^M dans le fichier script sh libpng-configure mais une fois edité avec vi ca passe. En suite le make me sort une tonne d erreure (en fait c eest tout le temps la meme la redef d'une structure...) /home/reboldev/agar/agar-1.4.1/include/agar/core/types.h:103:16: error: redefinition of 'struct ag_fake_int64' In file included from /home/reboldev/agar/agar-1.4.1/include/agar/core/begin.h:8:0, from /home/reboldev/agar/agar-1.4.1/include/agar/core/dbobject.h:5, from core.h:95, from variable.c:26: /home/reboldev/agar/agar-1.4.1/include/agar/core/types.h:103:16: note: originally defined here In file included from /home/reboldev/agar/agar-1.4.1/include/agar/core/begin.h:8:0, from /home/reboldev/agar/agar-1.4.1/include/agar/core/exec.h:5, from core.h:96, from variable.c:26: /home/reboldev/agar/agar-1.4.1/include/agar/core/types.h:103:16: warning: useless storage class specifier in empty declaration [enabled by default] | |
| shadwolf | 7-Jan-2013/18:54:03+1:00 |
| Pour corriger l erreur de compilation en haut mettre dans le ./configure d'agar la libre suivante. export CFLAGS="$CFLAGS -Wno-unused-but-set-variable" | |
| shadwolf | 7-Jan-2013/18:56:47+1:00 |
| la ligne doit ete mise apres l entete puis evidement ./configure doit etre relancer suivi de make all. | |
| shadwolf | 7-Jan-2013/18:57:06+1:00 |
| la ligne doit ete mise apres l entete puis evidement ./configure doit etre relancer suivi de make all. | |
| shadwolf | 7-Jan-2013/22:59:14+1:00 |
| bon cqa compile sous linux je vais voir ce que ca donne apres avec les scriptes de demos. | |
| shadwolf | 7-Jan-2013/23:50:30+1:00 |
| ca compile et ca plante agar-1.4.1/demos/customwidget/customwidget Allocated 189x34 pixels Caught X error: BadAlloc (insufficient resources for operation) Aborted (core dumped) | |
| none | 8-Jan-2013/10:38:01+1:00 |
| Permettez moi juste une remarque : Ne confondons pas "View" et "VID". Ce dernier n'a rien à voir avec AGAR ou autre chose, c'est juste un dialecte qui lors de son interprétation génère les objets graphiques ('face en r2) et le code pour les gérer. Donc "View" c'est le moteur bas niveau, qui gère l'affichage et à qui l'OS envoi les événements. View peut donc utiliser les appels natifs à l'OS ou passer par une couche intermédiaire comme AGAR. VID pourrait générer du code HTML si on le voulait : c'est un dialecte interprété par la fonction 'layout de R2, un point c'est tout. Sous R2, on a pas réellement accès à l'interface avec l'affichage proprement dit, hors mi via les dialectes 'effect et 'draw, mais ça ne va que dans un sens. Sous R3 cette interface est plus palpable : c'est le gob! (Graphic OBject). AGG est un peu à part aussi, car cette librairie permet de dessiner des primitives sur un objet graphique. Cette "image" sera de toute façon rendue par l'OS, donc AGG est d'une certaine façon à coté de View. Donc, sans vouloir jouer les rabats joie, je me pose simplement la question : "Si Rebol ne fait que quelques appels de base à l'OS, y-a-t-il un intérêt à utiliser une lib dont on ne va utiliser que quelques appels de base ? | |
| DideC | 8-Jan-2013/10:40:11+1:00 |
| Si on regarde les sources, on trouve les appels à l'OS qui sont regroupés dans "host-window.c". Celui dans "src/os/win32/" est bien plein, celui dans "src/os/posix/" est bien vide ! Mais on voit bien que les appels natifs sont très peu nombreux ! Donc pour faire avancer le schmilblick, ce qui serait intéressant c'est de voir comment ces appels sont codés dans AGAR sous MacOS ou linux pour compléter le code de R3 dans ces environnements. | |
| ldci | 8-Jan-2013/11:32:31+1:00 |
| @Didec Oui c'est bien tout le problème du portage de l'environnement graphique sous différents OS. En fait 2 solutions: soit on récupère le maximum de fonctions de l'OS comme avec wxWigets par exemple, mais on est obligé de décliner des versions spécifiques pour Mac, Linux, Win... et l'interface est conforme à l'OS. L'autre possibilité est de coder moins d'appels possibles à la gestion graphique de l'OS. Dans ce cas, le VID doit faire tout le travail, mais comme avec Rebol 2 on obtient des interfaces similaires sous tous les OS. Je vais regarder dès que possible les appels posix A + | |
| shadwolf | 8-Jan-2013/14:04:15+1:00 |
| none et DideC: Je me posais exactement la meme question. Mais bon le truc c'est que j ai pas envi de maintennir la couche du bas... J ai pas envi d etre un specialiste de COCOA / QUARTZ machin et de win32. C est exactement le meme probleme avec opengl. En gros celui qui utilise la lib opengl ce qu il veut c'est 1 ce concentrer sur l ecriture de code opengl, 2 que son code soit portable sans avoir a l adapter et a foutre des #ifdef partout dans son code parce que les appels preprocesseurs ca te gache la vie... Et en plus ca provoque des merdes a la compilation comme agar qui voit la meme structure definie dans 20 fichiers ce qui fait raller le compilateur C qui refuse d aller plus loin tellement c est foutoir. Tu es obliger de dire au compilateur d arreter faire chier avec les redefinitions de variables / structures pour que la compilation passe. ( c est le sens de l option -Wno-unused-but-set-variable du compilateur gcc). Du coup opengl par example dans sa jeunesse (il ya 15 ans environ) s amusait a avoir une librairie par system de fenetrage suporté on avait xGL sous linux on avait winGL pour windows etc... tout ca etait lourd car ca forceait a passer son temps a adapter son code dans les fonctions ininterressantes du programme. opengl a rassemblé ces appels dans une seul extension GLUT (GL UTils) et la tu utilises une fois pour toutes les meme appels vers l extension glut qui se charge de savoir si tu compile pour win32 pour macosx pour linux etc... | |
| DideC | 8-Jan-2013/16:34:05+1:00 |
| Merci de te sentir responsable de cette maintenance, mais pourquoi ? Le fichier win32 d'interface avec l'OS "host-window.c" fait 839 lignes de code C, commentaires compris. C'est pas beaucoup. Si le but est d'avoir le même système sur tous les OS, alors restons KISS et utilisons un VID/r3gui en Rebol + quelques appels natifs par système. Si le but est d'avoir des widgets natifs, alors utiliser une bibliothèque pour ça peut être une bonne idée. Mais croire que ça va être simple pour celui qui se tape la compil, c'est ignorer ce qu'est la programmation multi plateforme. | |
| ldci | 8-Jan-2013/16:51:21+1:00 |
| Oui tout à fait d'accord Restons KISS et vive le VID/r3gui qui sera implémenté Personnellement je suis toujours avec R2 et grâce a stylize, on peut faire de jolies choses. Par ailleurs, je développe sur Mac et les programmes sont utilisés par des étudiants sous Win ou Linux: je n'ai pas envie de me prendre la tête d'un OS à l'autre. Dernier point, pour les widgets natifs, le mieux c'est wxWidgets qui dispose d'un portage en Lua, Python et Perl entre autres langages de scripts... A + | |
| PierreCh | 8-Jan-2013/18:24:57+1:00 |
| Je rebondis sur le coup du VID qui pourrait générer du GUI ou du html. Ça m'a fait réfléchir, cette nuit. Ça m'a rappellé un vieux fantasme qui consisterait à programmer une interface, graphique ou texte, de manière la plus "universelle" possible. C'est un peu ce que faisait Visual Basic (oui, je sais, arrêtez de me jeter des tomates...) pour DOS et Win, mais qui n'a guère eu d'avenir dans le passé. De mémoire, un seul et même code (en payant deux licences...) générait un exécutable soit pour windows soit pour DOS. Le même genre d'idée serait assez géant: avoir un seul (méta)langage de programmation (VID ou équivalent), qui "sorte", selon le contexte, soit une interface GUI, soit une interface du genre ncurses, soit une interface html (html5, soyons fous). Voilà, c'était juste une idée à la noix. | |
| shadwolf | 9-Jan-2013/17:01:33+1:00 |
| DideC -> Merci de te sentir responsable de cette maintenance, mais pourquoi ? DideC parce qu il est clair que tu ne le fera pas 1) Parce qu apparement des qu on parle de quelque chose ici c'est surtout mon probleme. | |
| shadwolf | 9-Jan-2013/17:09:02+1:00 |
| DideC, ldci, pierreCh, et les autres, je pensais que le but de cette discussione etait de trouver un moyen nous permettant de ne pas avoir a ecrire et maintennir le code de fond de panier vers Il n est pas si simple de faire l adaptation du code actuel vers x11 et macosX la preuve cette partie est disponnible sous forme de host-kit depuis 2 ans presques 3 et personne n a fait d adaptation pourtant, normalement, d apres DideC il n y a qu'a reprendre la structure des noms de fonctions du fichier r3/src/os/win32/host-window.c et de les remplir avec des appels vers les libs correspondantes. Mais bon le vrai probleme est un problem de context tu dois aussi dire a AGG qu'il doit dessiner dans le context qui convient hors un HWND n'est pas identique a un context sous macos ou sous x11. | |
| shadwolf | 9-Jan-2013/17:13:29+1:00 |
| ceci dit MAxime a reussi dans r3 a faire dessine agg dans un context opengl ou integré un context opengl dans r3/gui je ne me souvient plus trop. C'est pour ca que j'aurai aime avoir son avis. et oui la librairie qui marche sur les 3 plateformes et qui est la plus legere c est de loin opengl. S il sagit de gerer des event clavier/sourie et de d'afficher le contenu d un bloc de memoire graphique opengl est tout a fait designé. | |
| PierreCh | 9-Jan-2013/17:16:14+1:00 |
| Off-topic: ça tchatche sur r3-gui en ce moment, sur altme. Je vais dans un fil de discussion plus adéquat. | |
| shadwolf | 13-Jan-2013/20:41:38+1:00 |
| bon agar j arrive a le compiler mais apres les exzecutables plantent. Je pense que SDL serait plus interressant. | |
| shadwolf | 13-Jan-2013/20:50:13+1:00 |
| interfacer SDL et agg me semble possible. | |
| shadwolf | 13-Jan-2013/21:10:27+1:00 |
| le genre de chose qui me fait de la peine. http://en.wikipedia.org/wiki/Anti-Grain_Geometry Quand tu lis ca tu ne vous aucune mention a rebol. Pourtant pour nous le monde rebol l integration d AGG dans rebol/view fut un accomplissement incroyable. Pourtant dans le monde AGG rebol n existe pas... | |
| shadwolf | 13-Jan-2013/21:11:38+1:00 |
| Graphical version of Rebol language interpreter is using AGG for scalable vector graphics DRAW dialect. et puis rien de plus. | |
| PierreCh | 13-Jan-2013/23:05:57+1:00 |
| Ah, c'était donc AGG qui motorisait rebol/view? Purée, j'avais pas du tout pigé... | |
| gerardcote | 13-Jan-2013/23:17:01+1:00 |
| Shadwolf, voici ce que j'ai trouvé en regardant du côté de AGG. Je reproduis ici les questions que j'ai posées sur AltMe mais personne ne semvlait intéressé à donner son opinion non plus sur le sujet - désolé j'ai laissé en Anglais... Peut-être y aurait-il quelques pistes à suivre mais je ne connais vraiment rien de ce côté alors peut-être que cela ne donnera rien non plus! C'est juste au cas. Did someone looked in the past at what other ppl using AGG did in the way of GUIs, as compared with the VID possibilities ? I'm just discovering this tool (the development of the original class library has been stopped and replaced by some similar lib under .NET but may be the original ideas and soft could be reused in part) and so I'm curious if it could be of some value or not for a new Red GUI basis - in the eventuality that the R3-GUI could not be reused or seems appropriate in some way ? Personnaly I found the author's principles of front-end / back-end splitting very interesting - http://www.opac.ch/virtualpen/internals/guisyn.html The authors are the same ppl who realized this free (but closed source) software http://www.creativedocs.net/ which now runs only under Windows but nevertheless they are complete, usable and done for profit under a new name (a French deritative) under http://www.matisseo.com/ which uses the product to let the user create an online photo book creation tool - which permits anybody to get access to some high quality printing and hard covers as well - for a very affordable price... No I'm not associate in any way with any of those companies and/or ppl but as I'm working in this domain, I'm able to share my professional opinion here. Regards Everything is rendered under AGG (see http://www.creativedocs.net/devs/agg for the C# binding and the source code of the higher-level wrapper classes used by Creative Docs .NET) so the rendering engine is currently used in real products and thai confirms that it runs well. To summarize the evolution of the product done by the original opac.ch company, the author Pierre Arnaud has developed the VirtualPen SVG editor for http://www.epsitec.ch/ which also sells some similar product called the Crésus Documents (http://www.epsitec.ch/products/doc/). Finally their product got another commercial derivative in the form of the software found here : http://www.matisseo.com/support/software . this is probably the same one that drives their online photo book creation offer. This software can also be freely downloaded to create local photo books but then you'll have to get some professional firm to get the high quality printing and hard covers if desired. If never you find some similar product for calendar creation, please tell me as I'm interested into this kind of product for producing some stuff for my family and some friends. | |
| shadwolf | 13-Jan-2013/23:31:47+1:00 |
| PierreCh oui a l ete 2005 draw ecrit par carl a ete remplasser par AGG merci gerardcote. J ai eu ce genre d interogations il y a quoi ... attends on est en 2013 l integration den AGG dans r2/view a ete fait ete 2005... donc 8 ans ... Je me suis toujours demander si AGG allait continuer a progresser et s il etait intelligent de maintenir trois codes source differents pour la gestion des events et des fenetres. En 8 ans rien n a ete fait... Disons que la communaute rebol a toujours attendu que Carl fasse les choses. | |
| shadwolf | 14-Jan-2013/0:33:31+1:00 |
| agg a ete adapté a sdl ... cette nouvelle rend les choix de carl encore plus incomprehensif au lieu de passer les 8 dernieres annees a travailler sur une optimisation agg/ sdl on a été maintenu dans une impasse. http://permalink.gmane.org/gmane.comp.graphics.agg/183 cet article dit qu il y a un probleme de pref dans sdl/agg mais en 8 ans on aurai pu optimiser la chose c est plus que certain ! | |
| shadwolf | 14-Jan-2013/0:35:05+1:00 |
| cet article est de 2004... | |
| shadwolf | 14-Jan-2013/0:46:22+1:00 |
| agg vient par default avec un support de sdl... libaggplatformsdl.so contains the AGG SDL API functions that | |
| shadwolf | 14-Jan-2013/0:49+1:00 |
| agg vient par default avec un support de sdl... libaggplatformsdl.so contains the AGG SDL API functions that | |
| gerardcote | 14-Jan-2013/4:55:02+1:00 |
| En effet Shadwolf, je ne connaissais pas cette lib mais elle semble très intéressante. Pour ceux qui comme moi en savent peu sur la SDL, voici un lien pour débuter vos recherches : http://en.wikipedia.org/wiki/Simple_DirectMedia_Layer. De là, suivre les liens pour en apprendre plus ... dont le lien officiel : http://www.libsdl.org/ | |
| gerardcote | 14-Jan-2013/5:09:54+1:00 |
| DideC : La lib de wxWidgets aussi semble intéressante, surtout depuis le port wxUniversal de 2000 a libéré les développeuts sous X11 de la dépendance envers GTK+ et Motif. Voir http://fr.wikipedia.org/wiki/WxWidgets pour débuter ou le site officiel http://wiki.wxwidgets.org/Main_Page. J'ai bien hâte de voir comment les deux se comparent en pratique! Quelqu'un a-t-il déjà utilisé l'un et / ou l'autre pour montrer/tester les possibilités réelles ou les limites de chacune de ces libs ? En attendant je vais au moins tenter de lire et étudier un peu les guides et exemples fournis. avec chacune. | |
| gerardcote | 14-Jan-2013/5:39:59+1:00 |
| Un lien trouvé traitant de la lib 2D Graphin et de sa relation avec AGG et SDL lorsque utilisée sous plusieurs OSes : http://code.google.com/p/graphin/source/browse/trunk/src/agg/src/platform/sdl/agg_platform_support.cpp?r=28 http://code.google.com/p/graphin/source/browse/trunk/src/agg/?r=28 Concernant les Widgets sous SDL, j'ai rapidement visité le site officiel pour tenter de repérer rapidement ce qui se faisait de ce côté. (http://www.libsdl.org/libraries.php?category=19&os=1) Voici aussi une lib développée au-dessus de SDL qui pourrait aider à un démarrage possible d'implantation de widgets. http://members.chello.nl/w.boeke/SDL-widgets/index.html D'après les anciens ayant utilisé View/VID, manque-t-il de Widgets ou d'autres fonctionnalités (threads, events I/O, ...) pour débuter à partir de la liste mentionnée dans ce lien et que je reproduis rapidement ici - contenant ceux déjà disponibles avec cet SDL-Widgets ? subwindows alert window push buttons radio buttons in 1 column radio buttons at arbitrary locations horizontal, vertical and 2-dimensional sliders dial widgets check boxes horizontal and vertical scrollbars indicator lamp non-editable text windows editable text windows dialog widgets menus file chooser temporary, movable windows Plus tard pour la suite, si cela peut être utile... Que j'ai donc hâte de pouvoir programmer avec ces engins en C et de pouvoir en faire des bindings en Red/System pour Red aussi! Probablement encore quelques semaines ou mois de patience seront de mise dans mon cas. J'espère toutefois pouvoir suivre (et modifier) les démos de mes cousins en attendant ... faut bien que je commence quelque part ! | |
| gerardcote | 14-Jan-2013/6:20:01+1:00 |
| Encore un petit pas de fait. Je viens de regarder wxWidgets et sa comparaison avec d'autres libs. Je suis alors tombé sur ceci : http://wiki.gnashdev.org/Glossary et de là, plusieurs termes qui m'étaient inconnus jusqu'alors sont devenus de possibles pistes alternatives. Pour ceux qui ne le savent pas GNASH est le FLASH movie player sous GNU. Les libs pour le GUI que GNASH peut utiliser sont au choix : Qt, FLTK, GTK, SDL, RiscOS, et FrameBuffer. Au moment de l'écrit voici ce que les ocntributeurs disaient : Simple DirectMedia Layer is a cross-platform multimedia free software library that creates an abstraction over various platforms' graphics, sound, and input APIs. At time or writing (2007-01-11) the SDL GUI lacks menus and a performant input event architecture; the SDL sound handler is the most feature rich, supporting Video through ffmpeg. Cela a-t-il changé depuis ? à vérifier. Du site de FLTK, voici comment en 2009 ils utilisaient AGG comme engin de rendu au lieu de OpenGL et GLUT : http://www.fltk.org/applications/articles.php?L898 | |
| gerardcote | 14-Jan-2013/6:48:12+1:00 |
| le dev de FLTK semble au ralenti mais voici des exemples de code l'utilisant : http://seriss.com/people/erco/fltk/ Liste des fonctionnalités (en faveur) de wxWidgets : http://www.wxwidgets.org/about/feature2.htm Liste de IDEs fonctionnant avec wxWidgets : http://wiki.wxwidgets.org/List_of_Integrated_Development_Environments Liste de la hiérarchie des éléments de wxWidgets : http://www.wxwidgets.org/docs/hierarchy_stable_image.htm Un tutoriel pour wsWidgets : http://www.wxwidgets.org/docs/tutorials.htm Un livre pour les développeurs utilisant wsWidgets avec des exemples : http://www.wxwidgets.org/docs/book/index.htm#examples | |
| ldci | 14-Jan-2013/13:49:21+1:00 |
| Salut à tous Toutes ces libs sont intéressantes, mais elles sont écrites en C++ pour la plupart, ce qui ne simplifie pas la vie avec Rebol ou Red qui sont écrits en C. | |
| gerardcote | 14-Jan-2013/15:28:57+1:00 |
| Parfois certaine bindings existent pour d'autres langages. Si Kaj a réussi à lier Red/Systeme t maintenant Red avec plusieurs autres outils, n'est-il pas possible de se regrouper à plusieurs et de faire ensemble une adaptation ou un binding d'une de ces plate-formes, en espérant que plusieurs soient d'accord pour y travailler de cette manière. Il faut d'abord jeter les bases PRéCISES de tout ce que l'on désire avoir (en priorisant la progression) puis de voir qui peut prendre quoi, non ? Je peux offrir de mon temps libre à réaliser des tests manuels (ou en préparer pour une exécution automatique si on dispose des outils pour ce faire) , si on me montre comment les faire de manière satisfaisante et utile pour le groupe. Malheureusement je ne peux pas faire davantage, compte tenu de mes connaissances limitées en ce domaine. En tant que user, je peux dire ce que je voudrais voir mais ce ne sera pas nécessairement en contradiction avec ce que les autres ont déjà émis auparavant (eg. options pour redimensionnement dynamique optionnel des widgets et calcul automatisé des coordonnées) | |
| gerardcote | 14-Jan-2013/15:34:06+1:00 |
| Peut-être qu'à étudier comment Kaj fait ses bindings, je pourrais me tenter à en écrire une partie, mais cela devra être validé ensuite par les autres - ou les tests prévus... Mais si je connais un peu de C, en revanche je ne connais rien de C++ ou de Java. donc je dois me calmer un peu et ne pas offrir ce que je ne serai pas capable, à court terme d'offrir pour ne pas décevoir personne. Rien de plus frustrant je trouve que ceux qui parlent mais ne font jamais rien de très utile, autrement que de proposer des choses sans jamais s'impliquer vraiment pour les réalisations ... même si pour moi, c'est un peu justifié par manque de connaissances et je ne suis pas certain que j'arrive à tout comprendre à ce niveau - malgré mes bonnes intentions! | |
| ldci | 14-Jan-2013/17:04:27+1:00 |
| Proposition intéressante de gerardcote, mais cela demande de l'organisation sinon on se décourage vite. Le binding nécessite une étude approfondie des fichiers d'entête des libs et ensuite une transcription dans un format rebol ou red compatible. Pour avoir porté sous rebol les librairies de National Instruments (labview) et commencé pour rebol et red le portage d'opencv, le plus gros problème avec rebol concerne les pointers et les structures dynamiques. Red est mieux conçu pour ça car le red/système est un c-like. Mais sincèrement constituer une série de bindings pour red/rebol serait génial et permettrait de fédérer nos forces dans un projet utile pour un type de langage qui reste un bijou. | |
| pepemont | 14-Jan-2013/17:20:08+1:00 |
| Si l'on cherche à faire des bindings avec une lib en C, pourquoi ne pas se tourner vers IUP ? http://www.tecgraf.puc-rio.br/iup/ ("IUP is a low level API, but at the same time a very simple and intuitive API. That's why it is implemented in C, to keep the API simple") Voir des exemples de ce toolkit ici : http://www.tecgraf.puc-rio.br/iup/en/basic/index.html | |
| ldci | 14-Jan-2013/21:39:52+1:00 |
| Oui, c.est un lib très intéressante, notamment pour red | |
| shadwolf | 14-Jan-2013/21:53:53+1:00 |
| SDL est ecrite en C. et c est de loin la plus légere si comme dideC le recommande nous devons nous servir d une librairie comme exemple pour ecrire notre propre librairie. Je recommande d utiliser SDL. 1) SDL est ecris en C natif 2) SDL a deja regler le probleme de librairie graphique sous jacentes dans les monde linux (qt? gtk+2? gtk+3? x11? xMotif? peut import sdl universe marche de toute façon...) 3) SDL est compacte. Et sans fioriture superflue ce qui plaira beaucoup a Carl je pense. Bien qu il prefererai je pense extraire les codes utiles sans garder la librairie SDL. Une des exigences de Carl est de garder le code simple lisible et util. | |
| pepemont | 15-Jan-2013/0:39:33+1:00 |
| On est bien d'accord, SDL ne permettra pas des widgets natif ? Parmi différents toolkits confrontés en http://www.tecgraf.puc-rio.br/iup/en/toolkits.html, IUP est le seul en C (et non C++) avec des contrôles natifs... Si l'on veut des contrôles natifs pour rebol, cela pourrait donc être intéressant. En outre, je m'aperçois (cf. http://www.tecgraf.puc-rio.br/iup/en/guide.html#contrib) que IUP connaît déjà des bindings vers : Ruby, Euphoria, FreeBasic, Perl, Go, Lua et ScriptBasic J'en conclus que les bindings IUP ne devraient pas être trop difficiles à écrire et pourraient attirer vers rebol des usagers d'autres langages. Une fois les bindings écrits, ils resteraient complémentaires de SDL en ce qu'ils proposeraient des widgets natifs. Rien n'empêcherait ensuite d'imaginer un dialecte rebol permettant d'appeler ces bindings de manière plus élégante... | |
| gerardcote | 15-Jan-2013/1:56:51+1:00 |
| Moi j'aimerais savoir si on peut repartir de la base (produire un équivalent de View, non bogué et peut-être même étendu pour en combler les limitations actuelles sous R2, que ce soit sous AGG ou pas - c'est déjà intégré à SDL, semble-t-il mais quand même) et ajouter les specs pour ce quel'on désire avoir au final - qui permette ensuite de lui couher par-dessus un équivalent de VID (quitte à l'enrichir ou à en modifier certains comportements si l'ancien de R2 ne convenait pas non plus - peut-être plus proche de Reb-Gui ou d'un autre GUI - à condition qu'il puisse être programmable. i.e. créer par programmation des interfaces avec la possibilité d'y intégrer facilement des éléments utiles pour la validation et/ou des tests automatisés de GUI par la suite. Suis-je assez clair ? Il me semble qu'en prenant n'importe quel autre GUI existant, sans avori au préalable écrit précisément ce qu'on veut pouvoir en faire et la façon d'y arriver, on risque de s'éloigner de ces specs de départ (View et VID) qui me semblaient à priori à conserver ou sinon qu'on visait à garder la possibilité de s'en rapprocher. Est-ce toujours le cas ou doit-on plutôt s'aligner vers de nouveaux outils qui n'auront plus rien en commun avec l'existant de R2 ? Ne pourrait-on pas viser une réécriture déboguée et étendue (si besoin est) de View et VID avec ces nouveaux outils en couche de fond ? L'existant sous R2 (VID ou Reb-GUI ou GLASS) suffiraient-ils toujours ;a combler les besoins d'une majorité ou doit-on plutôt maintenant coller vers une façon de fonctionner qui soit totalement différente avec ce que l'on a connu en R2 ? | |
| pepemont | 15-Jan-2013/9:58:13+1:00 |
| L'existant sous R2 ne supporte pas l'unicode et menace de bugguer à chaque nouvelle release vu qu'on n'a pas le code source... Personnellement j'ai besoin rapidement d'un langage libre, simple et multiplateforme qui produise des exécutables compacts et, après avoir eu à déplorer les bugs de Shoes sous Ruby, j'envisage actuellement de me mettre à wxLua ou EuIUP... L'existant sous R3 n'est pas du tout multiplateforme. On attend depuis très longtemps l'accès graphique à Linux ou Max OX... Et on rêverait aussi de GUIs sous Android, IOS, Windows 8, voire HTML5/JS comme interface via un mini serveur web... Si je ne me trompe pas, VID/layout, Reb-GUI et GLASS ont tous été écrits en rebol. Donc, je conclus que ce dont on a besoin très vite, c'est un ou des liens - peut importe lesquels - vers des systèmes graphiques, quels qu'ils soient. Que seules les personnes versées dans la compilation multiplateforme peuvent fournir. Après, les dialectes en rebol adéquats, dans le style du magnifique créateur du fichiers flash, vont fleurir facilement, vu la puissance du langage et la compétence moins pointue requise. D'ailleurs, la difficulté de porter le R3gui sous Linux et Mac OS X ne vient-elle pas précisément du fait que la partie rebol a été écrite trop tôt, sans tenir compte d'une interface graphique suffisamment portable ? Ce n'est que mon opinion. | |
| AdrianS | 15-Jan-2013/10:24:40+1:00 |
| Why is there an assumption that R3-GUI would be difficult to port by someone skilled in either OS X or Linux dev? I believe the reason it currently exists only for Windows is only because this was the most familiar thing for Carl to do on his own. Has anyone in this community (who has the required skills) looked at what it would take to do a port or are you guys just assuming it would be difficult and so not considering that? | |
| shadwolf | 15-Jan-2013/19:31:17+1:00 |
| hum pourquoi utiliser des widgets natifs d une lib de 200Mo genre GTK+ ou QT quand on a a disposition le dialect VID ou son decendant lesquels s'appuient sur agg Le plus gros probleme pour manipuler des widget natives c'est que ta widget native tu dois lui attribuer un contexte ou elle sera dessinee par le moteur ce contexte est une structure en C ou en C++ et rebol s interface super mal avec ca... | |
| shadwolf | 15-Jan-2013/19:35:26+1:00 |
| si ton but c est d'utiliser toute une librairie de haut niveau je te conseil l'aproche client rebol / server C ou c++ avec la lib de ton choix.... C'etait une approche a la mode il y a une disaine d'années et c'etait pas si mal. Le seul truc que tu dois bossé finalement c'est le passement des instructions a ta librairie... MAis la aussi y a deja beaucoup de fait dans le domaine comme les feuille de style XML pour decrire le contenu de ta fenetre. tu peux parfaitement faire un parser qui va lire le contenu d'un code GOB ou VID et le transformer en code XML qui va bien pour etre transmis et charger par ton application server. Evidement dans cette optique tu pourra pas te servir de code action en rebol ... et l interface entre rebol et ton server sera que dans un sens. | |
| jocko | 16-Jan-2013/7:57:34+1:00 |
| Sur la question du gui, je crois qu'on oublie trop souvent ce qui fait la richesse et l'originalité de rebol: - simplicité - compacité - polyvalence - productivité Le prix à payer, c'est qu'on ne peut pas tout faire de manière optimale. Il faut accepter, entre autres, que le gui ne soit pas programmable dans tous les coins. Si on veut faire des gui sophistiqués, il faut utiliser des langages et des environnements faits pour çà (Cpp Builder, Ms Studio ...) Je suis convaincu qu'il faut garder le gui simple et solide(comme celui de R2, mais relooké), et pour des applications exigentes, utiliser les capacités de communication de rebol, comme ce que suggère Shadwolf. Pour ma part, je commence à utiliser zmq, qui permet des passerelles très faciles entre rebol et la plupart des autres langages, sous windows comme sous linux, et même entre machines. Ceci permet d'utiliser le bon langage pour la bonne application. | |
| shadwolf | 16-Jan-2013/17:12:28+1:00 |
| - polyvalence - productivité pas d'accord ... si ton but c'est d avoir une fenetre avec un text un champs de saisie et un bouton a la con qui fait pas grand chose oui r2-view etait polyvalent et productif. des que tu voulais sortir des sentiers battus c'etait la mega prise de tete... rebgui a ete reecrit 3 fois completement avant qu ashley jette l eponge. et si on compte la version de henrik on peut meme dire 4 fois. Mais ca tenais plus au fait qu'il y avait de gros bug dans VID qu au fait que VID soit une mauvaise aproche. de fait en vid un bouton tu le fais comme ca button "titre" 100x20 [action a faire] en GTK+ un buton c'est un bonne disaine de ligne... a on interret a reprendre GTK+ telquel? Moi je dit que non. Et je me base sur le fait qu ecrire en rebol du code avec une syntaxe speudo C et des structure! instables n a aucun interret.... Nombreux sont ceux qui ont essayer d'adapter des librairie C a rebol 2 ou 3 et ils ont tous en commun d avoir decouvert que les variable sans type et sans taille ca collait pas bien avec la maniere de faire du C et que les debordement de memoire et les crash qui s en suivent etaient frequents. | |
| pepemont | 17-Jan-2013/11:50:08+1:00 |
| L'idée de shadwolf d'utiliser client rebol -> server C + kit graphique m'intéresse, mais j'ai pas envie d'avoir à créer et compiler moi-même un server à la fois sous win, linux et mac os x... ni de devoir m'agacer avec un firewall qui signale mon application comme potentiellement dangereuse... J'ai donc imaginé le dispositif suivant : - écrire un dialecte rebol qui transforme une interface VID en code wxlua (http://wxlua.sourceforge.net/) ; - passer ce code wxlua à wxluafreeze via un shell pour afficher l'interface avec les wxWidgets (wxlafreeze est un interpréteur multiplateforme, qui pèse moins de 6 Mo sous Windows et existe aussi sous forme de librairie C++) ; - récupérer le résultat via un fichier, le presse-papier (ou une valeur de retour de shell si ça existe) Si ça marche bien, peut-être que j'arriverai à convaincre quelqu'un de créer avec la version lib de wxlua un module rebol qui pourrait interagir encore mieux (avec une commande rebol 'ExecuteWxLuaCode' et une commande wxlua 'ExecuteRebolCode', par exemple)... Ce genre de méthode combinant plusieurs interpréteurs qui interagissent a été utilisée avec succès par MoSync : ils donnent des exemples d'applications fonctionnelles hybrides avec une partie du code en C, une autre en lua, une autre en Javascript... (http://www.mosync.com/content/mixing-javascript-and-lua-dynamic-language-interplay) Chaque langage est alors utilisé pour ce qu'il sait le mieux faire... En fait, ici, grâce au dialecte rebol, il n'y aurait même pas à écrire autre chose que du rebol... | |
| ldci | 17-Jan-2013/16:35:21+1:00 |
| Je ne suis pas d'accord avec Shadwolf et j'ai toujours apprécié la simplicité du VID pour créer rapidement et sans peine des interfaces fonctionnelles Juste un exemple  | |
| shadwolf | 17-Jan-2013/16:48:06+1:00 |
| pepemont hum interessant mais tu te complique la vie je pense. Si tu veux pas ecrire du code C /c++ pour la definition de tes fenetre de leur contenu utilise les chargeurs XML de gtk+ ou de QT ton code rebol crache du code XML que tu envois via connection reseau a un mini serveur qui a 5 lignes de codes a peine dont une consiste a appeller la chargeur XML avec le code qu il vient de recevoir soit stoquer sous forme de fichier sois directement depuis le buffer memoire. comme gtk+ et QT existent deja sur les 3 os tu t evite la charge d avoir a adapter ton code le seul truc que tu aura a faire c'est indiquer a librairie linker quell librairie utilisee et quels fichiers inclus integre et c'est tout. | |
| shadwolf | 17-Jan-2013/16:50:50+1:00 |
| puisque wxwidget est ce que tu aimes voici un peu de lecture sur le sujet des fenetres crees par XML http://docs.wxwidgets.org/trunk/overview_xrc.html | |
| shadwolf | 17-Jan-2013/16:50:53+1:00 |
| puisque wxwidget est ce que tu aimes voici un peu de lecture sur le sujet des fenetres crees par XML http://docs.wxwidgets.org/trunk/overview_xrc.html | |
| shadwolf | 17-Jan-2013/16:50:56+1:00 |
| puisque wxwidget est ce que tu aimes voici un peu de lecture sur le sujet des fenetres crees par XML http://docs.wxwidgets.org/trunk/overview_xrc.html | |
| shadwolf | 17-Jan-2013/16:51:49+1:00 |
| puisque wxwidget est ce que tu aimes voici un peu de lecture sur le sujet des fenetres crees par XML http://docs.wxwidgets.org/trunk/overview_xrc.html | |
| shadwolf | 17-Jan-2013/16:51:57+1:00 |
| puisque wxwidget est ce que tu aimes voici un peu de lecture sur le sujet des fenetres crees par XML http://docs.wxwidgets.org/trunk/overview_xrc.html | |
| shadwolf | 17-Jan-2013/17:00:49+1:00 |
| Evidement apres le probleme c'est comment tu interface les boutton de ta fenetre wxwidget avec des fonctions rebol? tu as ton script tu as integre dedans un loader vid / XRC ca donne ca: load %vid2xrc.r ;l action du button close-action: func [][ alert "On ferme!!" wait 3 quit ] ; fenetre simpe en vid view layout [ below text "ma fenetre" button "close" red 10x100 [close-action] ] comment tu vas faire pour que le button XRC integre ton code rebol ? une traduction plus profonde ... Passer par lua ou python serait une alternative. OLdes dans son code reb2flash.r le fait (je suis pas certain du nom mais l idee c est exactement celle la ... prendre un dialect rebol et le traduir en instruction adobe flash que tu peux compiler et deployer sur ton site comme si ca venait du flash natif. L interret etant que le dialect rebol t offre un code plus facile a lire et a maintenir que le code natif flash...) | |
| pepemont | 17-Jan-2013/18:47+1:00 |
merci, shadwolf, pour l'idée d'utiliser XRC, ça va me simplifier la vie... et wxluafreeze permet tout à fait d'utiliser des ressources xrc, ce qui va me permettre de ne pas devoir me mettre au C++  je préfère wxWidgets parce que, tant qu'à me casser la tête, autant que ça serve à long terme, pour permettre des widgets natifs, ce que r3-gui ne fera jamais... pour activer les boutons, traduire le rebol en lua serait une solution... il me semblerait plus complet de faire communiquer le code rebol et le code lua : on crée en lua une ligne de code liée au bouton qui appelle p. ex, ExecuteRebol("do [close-action])" ; ensuite le code rebol pourrait exécuter les actions nécessaires directement en rebol (ouvrir un fichier, déplacer un pointeur dans un bloc...), sauf pour les actions d'interface qui devraient appeler (de façon rendue invisible par un dialecte, s'entend) un code lua, par exemple , executeLua("wx.wxMessageBox("on ferme...")")... enfin, d'ici que j'y arrive, r3-gui débuggué sous Linux et Mac OS X sera déjà sorti ? lol | |
| shadwolf | 17-Jan-2013/23:27:33+1:00 |
| ravi d avoir put t aider et surtout si tu arrives a quelque chose de rigolo n hesite pas a nous en faire profiter. En suite le gros avantage de VID c'est surtout draw AGG... Comme toute les widgets heritent du style face et que face peut etre le support d'un dessin AGG et que cette face est capable de capter des evenement clavier et sourie alors tu peux transformer une widgete fille de face en n importe quoi qui te passe par la tete. Et ca c'etait ultra bien ! | |
|
Login required to Post. | |