Hey; On Fri, 2006-09-15 at 17:33 +0100, Bastien Nocera wrote: > > Will test. Little patch attached for me to be able to compile it, but I > don't know how to make use of the library. >
Its a pretty nasty little pocketpc based lib, I just hacked it to build and run with X. The clutter backend branch should pull it in with --enable-egl . > > > It would certainly cut down the number of things to port, and > > > probably fix bugs like: > > > http://bugzilla.openedhand.com/show_bug.cgi?id=100 > > > > > > Is there any reasons why pure-X is preferred to using GDK/GTK+? > > > > > > > Historical raisins and probably that I know xlib better than I do > > GDK/GTK+. The reason for still avoiding currently is for what clutter > > needs to actually do currently windowing system wise ( think clutter on > > raw fb ) Im not sure if this justifies the extra dep of GTK at least. I > > am working towards getting clutter on embedded type h/w so GTK as a dep > > could be quite a big deal. > > Yeah, I can imagine that adding GTK+ wouldn't be the smallest of deps. > But I'm wondering what kind of embedded device would have OpenGL, and > not be able to handle GDK (I don't see GTK+ as needed actually). > Also we're already pulling in gdk-pixbuf so its kind of a misnomer. *but* I wonder if it really buys us that much and could actually become potentially limiting if we want to use on a backend GDK does not support - like EGL. > > We're going to end up using at least a fair amount of xlib-ish calls > > anyway for GLX use of which GDK/GTK does not abstract. > > > > Also if you really do want to do more advanced windowing system type > > stuff with the stage you can always use the GTK clutter widget. > > Which craps out for me, on one older machine. I think it's actually DRI > brokenness on my system. But it *should* work. I know it is a bit rough around the edges but no reason why it cant be made to work well. I have seen it working. We need to hassle mr Holmes :) > > Re #100, Im not totally convinced use of GTK would solve this and if it > > indeed does surely it wouldn't be that much extra xlib code to fix with > > just xlib. > > I'll look into it, should be small enough. > That would rock. The way fullscreening is done currently is very simple. I have no dual screen set up to test with, especially not with GL on both heads. > > For now at least Id like to stick with just xlib, see how the backend > > branch pans out and if we hit a more issues like #100 then by all means > > reconsider. > > Well, you're reimplementing keyboard and mouse events as well. > ClutterColor is just convenience functions that could sit on top of > GdkColor, and a large portion of the exported X11 specific commands > could use Gdk and be portable for free. > > Removing code is something I quite like :) > Yes, I understand the attraction but I think because of windowing system specific GL implementations ( GLX, Apple GL, WGL etc) and these not being abstracted by GDK it may become alot less fruitful than one would expect. We would still need to translate things like GDK Input events into clutter specific ones to avoid it becoming a major pita to port clutter to some backend not supported by GDK and also to avoid a strong dep on GDK in case a future version throws a curve ball which severely limits it on embedded platforms. Does GDK pull in Cairo already ? Note, Im not totally anti this idea I would just like to put off a more serious consideration/investigation of doing it a release ( or two ). > > btw, are you hacking something exciting with clutter :) ? > > Hehe, is there anything but one application to do with clutter? :) > Pong game ? Many thanks; -- Matthew -- To unsubscribe send a mail to [EMAIL PROTECTED]
