Re: [clutter] ideas for a opacity dissolving text
Thanks for the suggestion. Not as fancy of a solution as I might have hoped for:) but I'm sure if works just fine... and quick and easy to implement. - Reid On 27-May-09, at 2:54 PM, Kristjan Vaga wrote: i'd put simply a background colored image with gradual alpha channel over the text box edge. btw. one of the most wanted features by designers in Clutter is probably the technique to produce image-based clipping masks. this feature would fit to your case as well... kris. On Sun, May 24, 2009 at 5:58 PM, Reid van Melle rvanme...@gmail.com wrote: I'm trying to produce a dissolving text effect near a clipping edge, so that the text appears to fade-out as it approaches the edge. Can anybody point me in the right direction for the best way to produce this type of effect in clutter/cogl? It looks like the fog effect in clutter may do something related, but it appears to be purely based on z- index. Is there an easy way for me to shoe-horn this to my purposes. Alternately, I found a openGL example with a linear fog effect on the x-axis... is this a better model? - Reid -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
[clutter] ideas for a opacity dissolving text
I'm trying to produce a dissolving text effect near a clipping edge, so that the text appears to fade-out as it approaches the edge. Can anybody point me in the right direction for the best way to produce this type of effect in clutter/cogl? It looks like the fog effect in clutter may do something related, but it appears to be purely based on z-index. Is there an easy way for me to shoe-horn this to my purposes. Alternately, I found a openGL example with a linear fog effect on the x-axis... is this a better model? - Reid -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
[clutter] clutter 0.9.2 on OSX 10.5
I've finally got around to working with the 0.9.2. release on OSX 10.5 in hopes of using it with a client and eventually updating my OCaml bindings to 1.0. The updated API looks great so I'm excited to be on the new tree! First thing I ran into was a compile problem which I think may have been patched because I found some reference to it... basically needed to manually modify the LDFLAGS to add CLUTTER_LIBS in both Makefiles in tests/interactive and tests/conform. After that, everything compiled and installed great. However :( I cannot seem to run anything successfully in 0.9.2. A window comes up but there must be something wrong with the event loop and/or redraw because the scene only progresses if I manually drag the window edges which seems to trigger a redraw. This seems to be the case with all of the interactive tests. Can I provide more info to help? or is this a known problem? Should I try the git trunk? or just stick with the 0.8 series for now? Hoping somebody has fought this battle already and lived to tell the tale. - Reid -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
[clutter] version advice for a new project
I've been working with a clutter for a while now, but most of my time has been spent around the 0.8 release. I'm just starting a new project with a client, and wondering whether anybody has some friendly advice about whether to use 0.8 vs 0.9 ? I realize that 0.8 is the stable release, but the final delivery for the project is in the fall of 2009. At that point, I'm sure the project would want to be on the most up-to-date 1.0 release of clutter. I guess I'm asking, what is likely going to be the least pain: 1) building on 0.8 now, and then porting to 1.0 2) dealing with minor problems etc. on slushy 0.9, and hopefully having an easier port to 1.0 I realize that this is a difficult question without more specific, but I'm looking for a gut reaction. ** ALSO ** I should mention that I did get the OCaml bindings for Clutter-0.8 to about a 90% state and it is hosted on bitbucket. It is certainly usable but needs a bit more TLC and probably leaks a few bytes. Announcement: http://brierwooddesign.com/2008/11/19/announcing-oclutter OClutter site: http://bitbucket.org/rvanmelle/clutter-ocaml/wiki/Home I'm hoping to invest some more time once the 1.0 release comes out. Also, it is extremely likely that this will get pushed over to github soon, but I'll leave a trail of breadcrumbs regardless. - Reid -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] Easiest way to install 0.8.4 on OSX?
I wasn't sure whether you mean not use Macports to install clutter or not use Macports at all sorry if the rest of this email is useless (I don't have any experience with jhbuild). You can easily compile and install from source, but you can't dodge Macports very easily when it comes to resolving clutter dependencies. You will need to have the Developer Tools installed etc. as you would normally for Macports. Also X11 is required methinks. The deps off the top of my head: % sudo port install glib2 % sudo port install gobject % sudo port install pango % sudo port install cairo This will likely cover most of the dependencies, though there might be a few holes that will become obvious during the configure. Download the tarball, unzip it etc.: $ configure --with-flavour=osx $ make all $ sudo make install Bob's your uncle. Hope this helps. - Reid On 29-Dec-08, at 11:39 PM, Z. S. O. wrote: Hi, I've been trying with no success to install the latest clutter on my Leopard machine. I'd rather not use Macports because it's probably out of date (and in fact isn't working at all for me right now). I read Emmanuel's post from March (http://lists.o-hand.com/clutter/0912.html ) but I'm not familiar with Jhbuild and haven't had any success with it. Anyone come up with a simpler way to get clutter up and running? Thank you.
Re: [clutter] Animations not smooth
WRT creating bindings for self-made actors, that is relatively straightforward. I have done similar things for the OCAML bindings I'm building. Basically, you need to follow the recipe for creating a new Gobject- based actor class as discussed in the Clutter documentation. Even better, you can copy some of the stuff implemented for the coglbox examples which used a private data structure in the object (you will need something like this). In the private data structure, you will need to keep references to all of the python closures/lambdas (whatever you call them:). In the foo_actor_init, you can pass in all of the python closures or Py_NULL or whatever for methods you don't want to implement. Then you write C functions that correspond to all of the routines that you might want to override. The C function will simply check the private structure to see if, for example the pick function has a python closure, and then invoke it with the appropriate arguments. I hope this helps. I can send you an incomplete example if it helps, but it will be for OCAML, so may not be that illuminating. WRT threads and cairo, I think you should be pretty safe as long as you implement it properly. I mean, you really just need to make sure that your thread is operating on its own Cairo context, maybe just to a backing pixmap. The you can blit this in using a Cairo.paint or other mechanism. - Reid -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] Some help with Ruby and Clutter
Well, I haven't run the ruby bindings but I did just take a quick look and the README says they were built for version 0.4 back in 2007 and then updated for 0.5. So... you should check for an older clutter package or just download the appropriate tarball from the clutter web page and install from source. If you want to be a bit more adventuresome, I'm sure you would make many friends by working off the SVN trunk and updating the bindings to work with latest trunk version. It looks like there are also bindings for gstreamer and gtk. If you cannot find a package with the rbclutter bindings (they certainly don't exist for ports on a mac), then it may just be easiest to check out the source from svn. There is an examples directory in the ruby bindings with a few example files. Once you get the hang of it, you should be able to translate a C or python example very mechanically and easily. Hope this helps. - Reid On 4-Jul-08, at 8:54 PM, Fred Warren wrote: Hello- I'd like to try out using clutter in Ruby, testing gstreamer and gtk too. I'm using Ubuntu 8.04. What packages I have to install to get it setup? What documentation is there? What example files are there? Thanks, F. Warren Making the world a better place one message at a time. Check out the i'm Talkathon.
[clutter] several questions
Sorry for this dump of questions... 1. Full Screen Mode I'm just throwing this out before I start digging through code. I translated one of the cairo-actor test programs (flowers.ml) into OCAML for the bindings that I'm working on. Everything works except the full-screen mode setting. I'm 99% confident that I've replicated the exact sequence of C-calls from OCAML, yet the behaviour is slightly different (alla the full-screen mode setting). This suggests that there is some difference related to the way the program is linked and/or executed. Would this make any sense? Does anybody have any clues as to the underlying full-screen mode behaviour/ decision process that might impact this? 2. X11 Backend on Mac I'm very happy to have the native OSX backend and have been using that exclusively. However, this means that I can't embed clutter into the GTK applications that I'm building etc. I think I saw a posting from somebody about disabling a number of the X extensions that are not found in the apple-provided X11 server. Are there other options? Is this an easy process? What is the associated performance impact as an order of magnitude? i.e. is it just slower but still usable? Does anybody happen to know if these extensions are available in 10.5 or have experience with building/using a non- apple X11 server? 3. Clutter Test Programs There are a few test programs (i.e. cluttter/tests/*) that crash and potentially a few others that are not executing properly. Is this expected? Or is every instance of a failing test program a bug that should be investigated and filed? 4. Intent of the COGL API I was confused as-to the usage intent of the COGL API... mostly because of the use of ClutterFixed. I wrapped this as part of the bindings, since it seemed like a very easy-to-use 2D OpenGL abstraction. However, I remembered reading that ClutterFixed was not intended for use in bindings etc which made me think that perhaps this was intended only for embedded environments where FPUs were not available. Is this the case? I realize that ClutterFixed are really ClutterUnits under-the-hood... is this just an oversight in the documentation? As a side note, my intent is to provide equivalent the equivalent OCAML macros for ClutterUnits conversions which should offer approximately the same performance as the C macros without having to cross the C/OCAML barrier. What was the intent with other language bindings? 5. Direct Usage of OpenGL Question #4 led me to try direct use of the OpenGL API within a Coglbox actor paint function. It did not seem to work as I hoped. I was just drawing a simple rectangular polygon via OpenGL... I saw the rectangle appear and then disappear very quickly in subsequent calls to the paint function. Would this be expected behaviour i.e. does this make sense? It is intended to be able to use OpenGL directly within actors? Are there additional instructions and/or examples that I have overlooked? *** - Reid van Melle -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] several questions
I'm running straight out of SVN so have the most recent features and bugs:) This is on a 10.4 Intel box with an ATI Radeon X1600. Everything is compiled and run with --with-flavour OSX (that is my only option at this point). wrt Full Screen Mode: perhaps I didn't explain properly, but the vanilla C version of the program enters full-screen mode just fine. However, the OCAML version (which as I said, I'm 99% sure executes exactly the same sequence of calls into the clutter API) does not enter full-screen mode. i.e. I set the property, check it, and it is still set to false. So, it just seemed very odd that the C version worked and the OCAML one didn't and I didn't have a logical explanation. It made me think that there is some underlying decision making process wrt full-screen mode that is affected by how the program is compiled, executed, started etc. Since I have a working C version and broken OCAML version, I can certainly at some point narrow it down to exactly what the difference is that causes this, however, it may be somewhat painstaking. I was just posting this on the off-chance that somebody had a one line explanation. wrt The Test Program: I will file bugs on ones which aren't working. I feel compelled to perform a minimum amount of debugging on my own before filing bugs on these, but I'll try to get them into the system initially and then hopefully find some time to perform some debugging. There are a couple test programs that I'm not sure what the intended behaviour/success criteria. I very short README file would do wonders (I know, I know, that makes me a volunteer) - Reid On 3-Jul-08, at 10:00 AM, Emmanuele Bassi wrote: On Thu, 2008-07-03 at 14:52 +0100, Matthew Allum wrote: Hi; On Thu, 2008-07-03 at 08:54 -0400, Reid van Melle wrote: Sorry for this dump of questions... 1. Full Screen Mode What version of Clutter are you using here and with what backend ? I think fullscreen on OSX (the one that Reid is using, as far as I understood) is not entirely working: http://bugzilla.openedhand.com/show_bug.cgi?id=545 3. Clutter Test Programs There are a few test programs (i.e. cluttter/tests/*) that crash and potentially a few others that are not executing properly. Is this expected? Or is every instance of a failing test program a bug that should be investigated and filed? Again what version and backend are you using here ? Either way these 'tests' shouldn't crash - if they do please do post a bug on bugzilla. yes, some tests do crash on OSX; I've been going over them on the 10.5 with i965 box we have, but could not figure out why. most of the crashing ones were the COGL tests, as far as I could see. an open bug about them would be great indeed. ciao, Emmanuele. -- Emmanuele Bassi, OpenedHand Ltd. Unit R, Homesdale Business Centre 216-218 Homesdale Rd., Bromley - BR12QZ http://www.o-hand.com -- To unsubscribe send a mail to [EMAIL PROTECTED] -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] crashing on mac os 10.4
I do indeed have the exact same setup as was described by Tommi. I have a workaround plus this patch, so I'm good to go for now. I'm going to comb through the other OSX clutter bugs and see what other treasures I can uncover in advance. Getting into the bugzilla database might have saved the list this email chain... sorry guys. As a matter of etiquette, does this project prefer to receive potential bugs first on the list and then in bugzilla or just directly in bugzilla? I'll graciously await Tommi's patch:) No pressure dude. - Reid On 27-Jun-08, at 6:15 AM, Tommi Komulainen wrote: On Fri, Jun 27, 2008 at 1:23 AM, Reid van Melle [EMAIL PROTECTED] wrote: I've been trying to run the SVN head (3044 as of this email) on my Intel Mac, of course, compiled --with-flavour osx. I kept having bus errors with certain test programs. Happens to me always. Do you also happen to have OS X 10.4 + ATI Radeon X1600? Running CLUTTER_DEBUG=backend ./test-actors will print GL_RENDERER etc. There's a patch in http://bugzilla.openedhand.com/show_bug.cgi?id=929, though Matthew was wanting to restructure code somewhat more that it can be dealt with in the backend. -- Tommi Komulainen [EMAIL PROTECTED] -- To unsubscribe send a mail to [EMAIL PROTECTED]
