 |
| [GUI] Quelle librairie graphique minimaliste ? | |
| trigram | 19-Mar-2011/10:48:49+1:00 |
| Existe-t-il une librairie graphique simple dans un seul package (1 seul DLL) ? QT est-elle un ensemble de DLL ? | |
| ldci | 19-Mar-2011/12:30:02+1:00 |
| Simple DirectMedia Layer is a cross-platform multimedia library designed to provide low level access to audio, keyboard, mouse, joystick, 3D hardware via OpenGL, and 2D video framebuffer. It is used by MPEG playback software, emulators, and many popular games, including the award winning Linux port of "Civilization: Call To Power." SDL supports Linux, Windows, Windows CE, BeOS, MacOS, Mac OS X, FreeBSD, NetBSD, OpenBSD, BSD/OS, Solaris, IRIX, and QNX. The code contains support for AmigaOS, Dreamcast, Atari, AIX, OSF/Tru64, RISC OS, SymbianOS, and OS/2, but these are not officially supported. SDL is written in C, but works with C++ natively, and has bindings to several other languages, including Ada, C#, D, Eiffel, Erlang, Euphoria, Go, Guile, Haskell, Java, Lisp, Lua, ML, Objective C, Pascal, Perl, PHP, Pike, Pliant, Python, Ruby, Smalltalk, and Tcl. | |
| shadwolf | 23-Mar-2011/15:36:35+1:00 |
| SDL est très bien ... compact et puissant sans peusé 2 tones ... Surtout que nous ce dont on a besoin en fait c'est une API disposant d'un canevas nous permettant de faire notre moteur de dessin de widgets personnalisées. Si on va vers un clone de VID pour le GUI de red SDL me semble etre le meilleur choix possible. | |
| shadwolf | 23-Mar-2011/15:47:03+1:00 |
| Le point for de rebol c'est de premettre de réaliser à travers le système de dialect des API ultra flexibles. Le point faible de VID ayant été d'avoir été conçu par quelqu'un qui n'a pas la culture du logiciel libre... Du coup VID c'est reposé sur le plus bas niveau de dessin à l'écran GDI pour windows et Xlib pour linux ... Loin d'etre au top et en phase avec le 21 ème siècle ses deux API sont archaique lente démodée et même de moins en moins bien supportée par les cartes graphiques ressentent. On va vers le tout 3D le GPU fusionne avec le CPU pour atteindre des niveau de performance jamais atteind ! Il faut que le software soit capable de s'adapter a ce changement et clairement rebol ne prendra jamais ce chemin compte tenu de son inertie monstrueuse. Red quand à lui aurait tout interet a proposer un VID bati sur SDL (AGG peut toujours etre rajouter si besoin est ou meme remplacé par Cairo... Cairo qui est rappellons le LA librairie 2 qui déssine a l'écran les pages web de nos navigateurs favoris basé sur webkit). | |
| ldci | 23-Mar-2011/17:17:08+1:00 |
| On trouve une ébauche de wrapping sdl par Bouba sur le site Rebol Documentation Project http://pl.legoff.free.fr/dotclear/rdp/index.php/post/2005/07/07/Interfacer-Rebol-et-les-bibliotheques-dynamiques | |
| shadwolf | 30-Mar-2011/15:01:02+2:00 |
| belle présentation de l'interface de SDL et du calvere de l'interface avec R2 documentation du mardi 05 juillet 2005: "J'espère que cette lecture vous aura servi et vous permettra d'enrichir Rebol et d'en faire profiter tous vos amis codeurs de par le monde, en attendant l'interface plugin promise par Carl !" Hum on est en 2011 l'interface plugin est là mais y a plus personne pour s'en servir (courage maxim pour ta lib OpenGL/R3 GUI). | |
| ldci | 26-Aug-2011/13:43:20+2:00 |
| Je viens de trouver cette lib en C++ http://www.fltk.org/index.php Installée et testée sous Mac OSX Lion: marche parfaitement Une voie intéressante pour Red/Rebol? | |
| ldci | 26-Aug-2011/13:47:01+2:00 |
avec un exemple c'est mieux  Le fameux hello word #include <FL/Fl.H> #include <FL/Fl_Window.H> #include <FL/Fl_Box.H> int main(int argc, char **argv) { Fl_Window *window = new Fl_Window(340,180); Fl_Box *box = new Fl_Box(20,40,300,100,"Hello, World!"); box->box(FL_UP_BOX); box->labelfont(FL_BOLD+FL_ITALIC); box->labelsize(36); box->labeltype(FL_SHADOW_LABEL); window->end(); window->show(argc, argv); return Fl::run(); } | |
| ldci | 13-Sep-2011/15:05:10+2:00 |
| bonjour quelques tests avec sdl et red en prenant le code de Kaj de Vos Sous OSX Lion, le code compile mais problèmes à l'exécution $ ./PeterPaint-SDL space.bmp SDL version: 1.2.14 Sep 13 14:59:16 iMac-de-fj.local PeterPaint-SDL[16897] <Error>: kCGErrorInvalidConnection: CGSGetCurrentCursorLocation: Invalid connection Sep 13 14:59:16 iMac-de-fj.local PeterPaint-SDL[16897] <Error>: kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to catch errors as they are logged. Sep 13 14:59:16 iMac-de-fj.local PeterPaint-SDL[16897] <Error>: kCGErrorInvalidConnection: CGSGetCurrentCursorLocation: Invalid connection Sep 13 14:59:16 iMac-de-fj.local PeterPaint-SDL[16897] <Error>: kCGErrorInvalidConnection: CGSNewWindowWithOpaqueShape: Invalid connection 2011-09-13 14:59:16.482 PeterPaint-SDL[16897:60b] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Error (1002) creating CGSWindow on line 262' *** Call stack at first throw: ( 0 CoreFoundation 0x93edce77 __raiseError + 231 1 libobjc.A.dylib 0x9244c149 objc_exception_throw + 155 2 CoreFoundation 0x93e44e89 +[NSException raise:format:arguments:] + 137 3 CoreFoundation 0x93e44df9 +[NSException raise:format:] + 57 4 AppKit 0x913ad5de _NSCreateWindowWithOpaqueShape2 + 335 5 AppKit 0x912f4e35 -[NSWindow _commonAwake] + 2290 6 AppKit 0x912f3854 -[NSWindow _commonInitFrame:styleMask:backing:defer:] + 1772 7 AppKit 0x912f28bc -[NSWindow _initContent:styleMask:backing:defer:contentView:] + 1054 8 AppKit 0x912f2432 -[NSWindow initWithContentRect:styleMask:backing:defer:] + 70 9 SDL 0x0004567f SDL_SoftStretch + 27215 10 SDL 0x000445f8 SDL_SoftStretch + 22984 11 SDL 0x0003814f SDL_SetVideoMode + 623 12 PeterPaint-SDL 0x000014f9 PeterPaint-SDL + 1273 ) Trace/BPT trap: 5 | |
| DocKimbel | 13-Sep-2011/22:49:06+2:00 |
| @ldci FLTK est une lib intéressante, mais c'est visiblement du C++, donc il faut écrire un wrapper en C pour pouvoir y accéder depuis Red. Pour le problème de SDL sur Mac, c'est sans doute dû à un nom (et/ou chemin) de la librairie SDL pour Mac qui est erroné (c'est moi qui l'ai fourni à Kaj, mais je n'ai pas eu le temps de le tester). Si tu peux trouver le bon nom et chemin de la lib SDL et le changer dans le source SDL.reds, ça devrait régler le pb. | |
| shadwolf | 13-Sep-2011/23:25:26+2:00 |
| hum mouai fltk est une lib toute faite avec pliein de widgets existante sa propre phylosophie de gestion de la géometries des widgets mais bon globalement pas différents de gtk+ wxwidget, qt etc .... c'est a mon avis too much pour ce dont a besoin un clone vid ... ce que carl utilisait de gdi32.dll etait tres limité et essentiellement les fonction de bas niveau. donc sdl cardre bien on a un acces au gestionaire de fenetre et des evênements clavier, sourie et on a un canevas sur lequel on peut projeter ce qu'on veux ... pour les dessin des widgets on peut le faire en faisant que agg dessin dans le canevas sdl ou bien carement en faisant que opengl desine dans le canevas sdl (comme c'est le cas pour IO). J'aurais tendence a dire que pour le dessin 2D opengl est pas terrible. après moi je suis pour un vrai travail de font sur le video dialect qui doit permettre de proposer un set de widget classe, une acceleration materielle pour les travaux comme afficher des tableurs ou du texte colorisé ou des editeurs de texte enrichi tout en auyant la simplicité d'architecture de VID... Mais bon a t on vraiment le temps et l'envi de ce genre de chose ? la question est posée. | |
| shadwolf | 13-Sep-2011/23:34:52+2:00 |
| idealement un truc du genre view/ogl layout [ label "hello world" red 100 btn "close" [ quit] ] ou view layout [ label "hello world" red 100 btn "close" [ quit] ] serait l'ideal par defaut rendu des widget en 2D via AGG si on precise OGL alors le moteur de rendu passe par opengl avec accélération matérielles etc ... visuallement le set de widget serait identique ... donc 1 dialect vid like unique et la possibilité des "changer" a la volée le mode de rendu. pour ce qui est des widgets si on peu faire du simple esthétique et animé se serai le pied ...( example la bar de manu qui s'acculte si le pointeur de la sourie n'est pas dans la région haute de la fenetre que ce soit automatique et intégré dans la widget menu des le départ. un reminder serrai afficher en mode plier montrant qu'il y a quelque chose a afficher etc ...) | |
| ldci | 14-Sep-2011/8:46:34+2:00 |
| @dockimbel Ftkl est effectivement une lib en C++ assez sympa car pas très volumineuse. J'ai utilisé avec xcode: parfait. Pour SDL, le code me renvoie le numéro de version (1.2.4) ce qui à première vue signifie que l'import de la lib a bien marché et le chemin correct. Je pense que c'est juste un pb de version 32bits/64bits avec OS X Lion Je vais regarder ASAP | |
| shadwolf | 21-Sep-2011/20:08:16+2:00 |
| Moi j'aime ennormement VID parce qu'a mon avis c'est la plus proche definition possible d'une interface graphique. VID me semble incontournable et absoluement nécessaire. Serrieusement qui a envie de programer en speudo C alors que REBOL et son concepte dialecte sont tellement plus puissant, flexible etc... A ton besoin de baser un VID sur un GTK+ ou sur une autre librairie graphique de haut niveau en C? Hum ... c'est pas une question facil car ce dont a besoin VID reelement correspond au fonctionnalité de plus bas niveau de ces librairies... GTK+ 2.22 runtime environement pour windows c'est un installer de 7.5 MB en compressé. Mais un VID n'a besoin que de 10 pourcent a peine des fonctions qui sont offerte dans the Gimp ... Rien que la couche support de texte de (pango ATK etc..) représente 70% de GTK+. Ceci dit on a les sources et GTK+ est portable et vient de base avec 99% des distros linux ... Donc oui se baser sur une librairie unique disponible partout me semble être la meilleure idée possible cependant.... un VID n'a pas besoin de supporter 100% des fonctionnalités de cette librairie et ca semble etre un gros gachis que de forcer les gens a telecharger un sdk et une runtime pour soit dev ou soit utiliser leur soft... Hors une librairie GUI minimaliste ca n'existe pas ... X11r6 ou Gdi32.dll sont loin d'etre minimalistes ... C'est pas parce que Carl en a exploiter 5% pour VID que ce sont des librairies minimaliste et adapter a ce dont on a besoin pour un VID ... Ceci dit ils viennent de basent avec les OS... Donc pas d'installation supplèmentaires... LA logique voudrait si on voulait vraiment faire les choses convenablement qu'on prennent une librairie comme GTK+ qu'on en conserve que les parties importante pour la rèalisation du VID et qu'on diffuser ca dans le SDK de RED. Probleme ... ennormement de travail est necessaire pour arriver a ce rèsultat. Mais l'avantage pricipal de cette approche c'est que des points très faibles du VID de REBOL comme par example le support des fonts serait contourner car oui GTK+ intègre de loin le meilleur dans ce domaine. J'ai utiliser ennormement QT et GTK+ pour programmer et je n'aime ni l'un ni l'autre.. je deteste devoir donner un parametre par ligne et devoir systematiquement appeller une fonction pour faire en sorte que mon parametre soit affecté a une widget... J'aime l'aproche HTML-like de VID j'aime donne sur une seule et meme ligne tout les parametre de mon widget sans avoir en plus a specifier quelle valeur correspond a quoi (sauf pour le block draw ou pour les prametres avancés de font) pour rappel un GTK+ une fenetre avec un bouton avec marqué dessus Hello World ca se fait comme ca :
include <gtk/gtk.h>
void
hello (void)
{
g_print ("Hello World\n");
}
void
destroy (void)
{
gtk_main_quit ();
}
int
main (int argc, char *argv[])
{
GtkWidget *window;
GtkWidget *button;
gtk_init (&argc, &argv);
window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
gtk_signal_connect (GTK_OBJECT (window), "destroy",
GTK_SIGNAL_FUNC (destroy), NULL);
gtk_container_border_width (GTK_CONTAINER (window), 10);
button = gtk_button_new_with_label ("Hello World");
gtk_signal_connect (GTK_OBJECT (button), "clicked",
GTK_SIGNAL_FUNC (hello), NULL);
gtk_signal_connect_object (GTK_OBJECT (button), "clicked",
GTK_SIGNAL_FUNC (gtk_widget_destroy),
GTK_OBJECT (window));
gtk_container_add (GTK_CONTAINER (window), button);
gtk_widget_show (button);
gtk_widget_show (window);
gtk_main ();
return 0;
}
En vid2 ca se fait avec view layout [btn "Hello World" [quit]] ... Et j'ai meme pas eu besoin de forcer mon talent... | |
| shadwolf | 21-Sep-2011/20:20:05+2:00 |
| A defaut de tailler dans une librairie pas fait pour ca, pour obtenir une version ultra-light pour baser un VID ce qu'on peut faire c'est faire ce que carl n'a pas voulu/put faire, c'est a dire prendre une librairie evoluer qui fait tout ce dont on a besoin pour notre splendide RED/VID (oui je prefère le terme VID Visual Interface Dialect plutot que le terme GUI ... Pourquoi ? C'est simple VID n'existe que pour et dans rebol ,.. GUI trop vaste trop flou pas rebolesque du tout! Tout ce qui s'affiche sur un écran est GUI parcontre VID n'est pas n'importe quoi ...) et s'en inspirer pour écrire notre propre librairie portable et de base élaboré pour etre le socle d'un VID ... Ceci dit l'approche de IO est loin d'etre bête plutot que de se baser sur une librairie 2D avec plein de widgets ils ont choisi d'implementer un moteur de dessin de widget en openGL... C'est minimaliste portable et materiellement acceleré que demande de plus le peuple? | |
| shadwolf | 21-Sep-2011/20:22:38+2:00 |
| parcontre faire du 2d avec une librairie 3d ... c'est mode ... pour example blender ... et encore blender est un must dans le genre ... si si vraiment ... | |
| shadwolf | 21-Sep-2011/20:25:18+2:00 |
| parcontre faire du 2d avec une librairie 3d ... c'est moche ... pour example blender ... et encore blender est un must dans le genre ... si si vraiment .. si vous prennez les très ancienne version de blender vous verez que les menu en opengl c'est vraiment moche... Ceci dit la aussi comme pour IO, GTK+ SDL Etc les sources sont dispos rien ne nous empeche de nous en inspirer pour notre propre emploi du moment qu'on remercie en bon et due forme les auteurs des codes qu'on aura repompé. | |
| ldci | 28-Sep-2011/16:11:19+2:00 |
| The latest version of GTk+, version 3.2, has been released. While this new release contains many smaller, less invasive changes, it also has experimental support for two very important new features. First, the ability to run Gtk+ applications inside a browser using HTML5. Second, initial support for the Wayland display server. Gtk+ 3.2 introduces many smaller features which users will benefit from straight away. CSS themeing support has been improved, GtkFileChooser has been overhauled, the GtkFontSelection has been replaced by a new set of GtkFontChooser widgets, and several new widgets have been introduced as well. The HTML5 support in Gtk+ 3.2 is still experimental. It allows you to run Gtk+ applications inside HTML5-capable browsers - and we're not just talking a calculator or a notepad application, since GIMP runs just fine in Firefox 4.0 as well, as the video below demonstrates. | |
| shadwolf | 4-Oct-2011/4:39:11+2:00 |
| ce qui est bien avec le fait que rebol soit abandonné c'est qu'a moyen terme il marchera plus sur linux... bref on s'en fiche... | |
|
Login required to Post. | |