Re: [clutter] How do i get screen properties with clutter?
On 12/06/10 17:52, Ankur Sinha wrote: On Sat, 2010-06-12 at 17:36 +0100, Emmanuele Bassi wrote: On Sat, 2010-06-12 at 21:58 +0530, Ankur Sinha wrote: hey, I would like my stage to be say, 80% of the screen size. How would I find the size of the screen using pyclutter? I've been through the docs and I don't see any methods that would give me this info. Also, how do I remove window decorations? for eg, I'm making a splash, which doesn't need the title bar etc. Is there a property that I can set? Clutter does not abstract a platform's windowing system - except to the extent that it needs to effectively paint the stage and handle events on it. the rest is left to the platform's own libraries. you can use clutter-gtk (and its python bindings) to get a Stage embedded inside a gtk+ window - and then use gtk+'s API to achieve what you want. I'm trying to *not* use the gtk bindings so the app stays DE independent. As Emmanuele indicated, windowing is not platform-agnostic; you will need to use whatever APIs given platform provides to do this, i.e., on an X-based system, you will need to use xlib and follow the ICCM (http://tronche.com/gui/x/icccm/) and the EWMH (http://standards.freedesktop.org/wm-spec/wm-spec-1.4.html) protocols. Tomas -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] create mutter plugins
Hi, Bastien Bouzerau wrote: Hi everybody.. After some testing on interfaces user like gnome-shell or moblin, I was really interest by windows manager layer. It seems that both of them use mutter(clutter + metacity). In fact gnome-shell and moblin are mutter plugin. So I wonder if there is any tutorial to create a mutter plugin from scratch. Should I get mutter sources and start from here? Or is there another way to create my own mutter plugin? I have already browse mutter-moblin sources but I'm a bit lost. There is no tutorial for this; src/compositor/plugins/default.c is a basic plugin that demonstrates the simple plugin API, and is a good place to start. Both gnome-shell and mutter-moblin go well beyond using the basic plugin interface, and to create a plugin of similar complexity you will need good understanding of window management under X in general and of Mutter, which exposes large number APIs, either directly or through GObject mechanisms, that the plugins can tap into. Tomas -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] problem building MX 0.4 library on Mac OSX
Roland Peffer wrote: On Tue, 2010-01-19 at 08:40 +0100, Roland Peffer wrote: Hello, just tried to compile the moblin MX GUI toolkit on MAC OSX. after using ./configure --prefix=/usr/local I run make ...responding with the following error: make all-recursive Making all in mx GENstamp-mx-enum-types.h /bin/sh: --template: command not found make[2]: *** [stamp-mx-enum-types.h] Error 127 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 anyone have a hint for me? I used to have this problem on and off (on linux) when installing packages into a custom prefix, it's some issue related to the AM_PATH_GLIB_2_0 macro, but I never got to the bottom of what the problem really was. Locally replacing AM_PATH_GLIB_2_0 with AC_PATH_PROG([GLIB_MKENUMS], [glib-mkenums]) AC_PATH_PROG([GLIB_GENMARSHAL], [glib-genmarshal]) Has always worked for me, Tomas -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] blank stage with clutter_x11_handle_event()
Brian J. Tarricone wrote: Small test case exhibiting the problem is attached. Uncommenting the #define near the top doesn't help (or hurt). Any ideas? Without that define it cannot work; you must disable the clutter event retrieval if you plan to retrieve events yourself, but the principal reason it does not work is that your application does not use glib main loop; if you are not calling clutter_main() you need to run some kind of a glib main loop instead of it. Tomas -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] Segment fault on Clutter with SDL flavour
Hieu Le Trung wrote: I'm trying Clutter-1.0 with SDL flavor. When running the test program, it produces segment fault. Any suggestion. gdb ? Tomas -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] Tidy for Clutter-0.9
Kiran Bhide (RBEI/ECG3) wrote: Is there a tidy package build for Clutter-0.9 ? Or when is it expected ? The one in GIT still uses Clutter-0.8 and build with Clutter-0.9 breaks ! Not compalining but just eager to know :) No there isn't one; Tidy is only maintained for each stable release, and will be updated after 1.0 is released. As always, patches to make it work with the 0.9/1.0 API filed in the bugzilla are welcome. Tomas -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] clutter_stage_get_actor_at_pos() when more than one actor
Daniel Alonso wrote: Hi people, clutter_stage_get_actor_at_pos() returns only one reference to an actor., but what's the intended behaviour when more than one actor in the same position, one overlaping the other? Is it possible to retrieve a list of all actors? clutter_stage_get_actor_at_pos() returns the actor that would receive an input event if the users clicked at the given position. Tomas -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] Re: client-side matrix
Havoc Pennington wrote: Another question is how the matrix stack would be done; client-side matrix handling would be an opportunity to remove the limit on stack depth by keeping an infinite (or much larger) stack in cogl. Desirable? The depth of the stack is imposed by your driver; my suspicion would be that if you are finding the stack is not sufficiently deep, you are trying to do something that the driver is actually not up to. Tomas -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] Clipping using cogl_clip_set/cogl_clip_unset
Thomas Steinacher wrote: Hello, The following code displays a blank stage (i.e. the image is not rendered at all). Why is this so? I'd expect a 50x50 rectangle to be visible. import clutter from clutter import cogl class Texture(clutter.Texture): __gtype_name__ = 'Texture' def do_paint(self): cogl.push_matrix() cogl.clip_set(0, 0, 50, 50) If I am not mistaken cogl_clip_set() takes ClutterFixed/ClutterUnit, not int, so you are really setting the clip to 0 x 0. Tomas -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] Metacity-clutter TFP warning
Hi, Bipin George Mathew wrote: I am running the latest version of metacity-clutter on Ubuntu 8.10 and I get the following warning: Not using GLX TFP. I do understand that without GLX TFP, the performance of metacity-clutter will be affected; Few questions: (1) I am trying to understand the cause for this warning: Is it directly related to the my graphics card/driver? Yes. I am on an intergrated Intel 82945G/GZ controller. I read that hardware accl. GLX TFP is supported only on NVidia cards. On Intel HW, you can get turn TFP on by exporting LIBGL_ALWAYS_INDIRECT=1; how well the TFP will work depends on how recent your drivers is; at least in theory it should work OK on a 945 card with the current drivers. (2) If yes for (1), can I get clutter to use GLX TFP by running a software emulation? MESA? IIRC yes, but the last time I tried using Mesa, the OpenGL performance was abysmal. (3) What is the fallback in metacity-clutter if GLX TFP is not available - XShm? If XShm is supported, Clutter uses XShm, it not it falls back further onto XGetImage. Tomas -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] fixed point error?
Andy Tai wrote: Is this a bug? On a x86 PC running Ubnutu, fprintf(stderr, %f\n, CLUTTER_FIXED_TO_FLOAT(CLUTTER_FIXED_DIV(CLUTTER_INT_TO_FIXED(146), CLUTTER_INT_TO_FIXED(182 ; produces -0.601562 CLUTTER_FIXED_DIV() has very limited precision that varies depending on the arguments; it should only be used where this is not an issue. If you need better precision use CLUTTER_FIXED_QDIV() instead. Also, note that it makes no sense to use the DIV macros when the divisor is an int; if you do CLUTTER_INT_TO_FIXED(146) / 182 you will get much better precision. (Same goes for multiplication BTW.) Tomas -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] [patch] Lazily initalize slices on first data store
Hi Owen, Could you please move this into bugzilla ? Thanks, Tomas Owen Taylor wrote: I was doing some profiling on Mutter in one particular case: alt-Tabbing with the classic draw border around window alt-tab indication. This is implemented by creating a big window and shaping it to a narrow rectangle. This a pathological way of doing alt-tab indication in the Clutter universe, but a pretty good test case for the speed of window creation. (Running with indirect GL, as normally is done to get the texture_from_pixmap extension to work via AIGLX.) When I looked at the profile, it was very heavily dominated by glTexImage2D() ... the server was spending 20% of CPU doing that, and the client another 11%. (Plus some undetermined amount of kernel time for wire transport and texture handling.) When I investigated *what* glTexImage2D was taking most of the time, it was a bit funny - the domination was by the calls to glTexImage2D with a NULL pixels parameter that cogl_texture makes when initializing a texture. Turns out that Mesa isn't too smart, and even though the resulting pixmap content is undefined, all the undefined bits get shipped over the wire and then stored in video memory. This is pointless: - If we are immediately going to fill the texture with data - If we were creating the texture to use with texture_from_pixmap So, the patch attached makes the initialization with glTexImage2D lazy so it can either be combined with filling the texture with data or avoided altogether. These changes drop the server time related to glTexImage2D to 7% and the client time to 6% in a similar test. The result feels much snappier as well. Caveats on the patch: - There's a lot of refactoring to consolidate glTexSubImage2D calls so that it feasible to do the actual change which is pretty trivial. - It's not all that well tested - in particular I haven't tested it in situations where I'm sure texture slicing is happening. It's a pretty mechanical refactoring of the current code, but there's obviously potential for introduced error. - If someone is calling glTexSubImage2D on the results of cogl_texture_get_gl_texture() instead of using cogl_texture_set_region() they'll run into problems, because the initialization code path will be bypassed. - You could obviously make the claim that the proper fix lies in Mesa ... the glTexImage2D(..., NULL) should just be made fast. I don't know if that would require GLX wire protocol changes. - Owen -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] clutter-gtk OSX flavour
ere wer wrote: There seams to be a new (native?) port of GTK+ to OSX: http://labs.imendio.com/: From what I understand (have not tested anythig), this version does not require X Im interested if there will be a new flavor to clutter-gtk, currently there are only x11/win32, or the x11 will do? At the moment the Clutter OSX backend does not have the necessary API, for this; I think at least clutter_osx_set_stage_foreign() and clutter_osx_disable_event_retrieval() are necessary to get clutter-gtk to work with the native osx gtk port. Patches, as always, are welcome. Tomas -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] perspective
Hi, Peter Csaszar wrote: Thank you for the answer. I have studied several times the doc for Unfortunately clutter_stage_set_perspective() and cogl_perspective(). May be I wasn't able to understand it or it is just not enough descriptive . But I spent some time with experimenting it. I think these functions are not appropriate for the trick I need. If the perspective API is not enough for you, you will need to use GL directly to set up the perspective matrix; the perspective is setup inside cogl_perspective() and the viewport is setup in cogl_setup_viewport(), so you want to have a look at the code there. Tomas -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] clutter for OSD
Jason Tackaberry wrote: On Sun, 2008-09-07 at 15:18 +0200, Mike Massonnet wrote: I had definitely say no. IMHO, you keep your default stage, and uses something like DBUS so that you can display specific messages onto the default stage. I wonder if it'd be possible to use tfp and redirect the XComposite overlay window. Seems like exactly what the OP asked for (fullscreen transparent stage), assuming it's possible. I am not sure I fully understood, but the overlay window cannot be transparent. You need a compositor to achieve the illusion of transparency, and the overlay window is the target window where the compositor creates that illusion, i.e., the overlay window itself cannot be composited. Your simplest option is not to make the OSD menu fullscreen, and just stack it over the stage. If you want the OSD menu to be translucent, you can either use the RPC approach suggested above to create it by the process that owns the stage, or you need a compositor. Tomas -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] About tearing issues and VSYNC use with video textures
Hi,
Florent wrote:
Another hint: since the small animation seems to freeze on FPS count
print, this may indicate that there's something that's freezing the app
here:
if (g_timer_elapsed (timer, NULL) = 1.0)
{
g_print (*** FPS: %i ***\n, timer_n_frames);
timer_n_frames = 0;
g_timer_start (timer);
}
In short, all of this may indicate that there's a bottleneck somewhere,
and this bottleneck might well be that of the main glib loop. But why
ONLY when using VSYNC ?
When clutter is made to sync to VBLANK and the paint operation does not
naturally hit vblank, the main loop is paused until the vblank takes
place, at which point the paint executes, and the main loop resumes
normal operation.
Tomas
--
To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] Undefined references to pango?
[EMAIL PROTECTED] wrote: I am trying to build clutter 0.8, I have pango 1.20.5. Configure succeeds but compiling gives the following errors: ../clutter/.libs/libclutter-glx-0.8.so: undefined reference to `pango_cairo_font_get_scaled_font' ../clutter/.libs/libclutter-glx-0.8.so: undefined reference to `pango_layout_iter_get_line_readonly' ../clutter/.libs/libclutter-glx-0.8.so: undefined reference to `pango_extents_to_pixels' Do I need a newer version of pango (1.21)? The first of these functions is available as of 1.18 and the other two since 1.16 (the configure check is for 1.18); I just run a test build of the 0.8 tarball against pango 1.20.5, and it was fine, so chances are there is something not entirely right with your Pango install. Is it possible you have more than one version of Pango installed (e.g., one under /usr and one under /usr/local) ? Tomas -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] Modification needed in odo program
dilip devaraj wrote: Hello Clutter Team I found a small bug in odo program which I downloaded from SVN The original program is if (!strncmp (argv[i], --tile-height, 13)) tile_height = atoi (argv[i] + 14); Nope, that code is correct: --tile-height=X 012345678901234 i.e., X is at position +14. Tomas -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] Sample Clutter Shader program
dilip devaraj wrote: Hello Clutter Team I am not able to find out which graphics card I have in my machine In that case we are not able to answer your question (it all comes down to the capabilities of your HW and drivers). I want to know if clutter is designed to run on mobiles using ARM compiler then how will Clutter based shader programs work.Is there any workaroung for that. ARM is such a broad term, I am afraid the above answer applies here as well. Tomas -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] FW: Welcome to clutter@o-hand.com
HASWANI HARISH-VCKR47 wrote: Hi , I want to have Sine wave effect ( Water wave ) on a picture. Steps I followed - Image size id 512x1024. And Sine wave Effect is to be given in z direction. - Divided Imaged in 1024 actors. - Applied the sinusoidal effect on each actor. - I have attached My C code with this mail. I am using Fedora8. Issue: while execution as there are 1024 actors all are moving in sinusoidal fashion, I am able to see background colour of stage, which is blue in my case. So along with sine effect there are many blue stripes coming in between. Ques : Do we have anything in clutter to give Sinusoidal effect to a image. You probably want to do something like toys/odo does, rather than splitting the image into a myriad of actors. Tomas -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] Problem with get_abs_position
Hi, Bob Dickinson wrote: I've run into a problem, either with get_abs_position, or with my understanding of it. I have been using get_abs_position in order to do coordinate transformations to position actors relative to each other. I have a lot of little spacing problems, which I have tracked down to get_abs_position returning values with a higher granularity than get_position (on the order of 3-4 pixels when the stage is full screen). Is get_abs_position broken, or am I using it incorrectly? The docs say Gets the absolute position of an actor, in pixels, relative to the stage, which does not seem to be the case. The error is inherent to the nature of the problem, and the function cannot be expected to be pixel perfect, so that any code that uses it needs to allow for the inherent error. In any case, you should not need it to position actors, since actors are always placed relative to their parent, not the stage. If you need to coordinate the actor positions relative to some other ancestor than the immediate parent, then as you mentioned you need to walk the ancestor hierarchy and do the adding up. Tomas -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] Undefined reference error in many clutter/toy apps
Erik Karlsson wrote: I just did a checkout from the SVN for clutter. After installing the library I noticed a common error message in many of the clutter/toys applications when compiling them (at least in odo and astro-desktop) : The toys are always meant to be built against the latest stable release of clutter, not against svn trunk. Tomas -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] transient allocations
Matthew Allum wrote: Also its worth noting now in trunk clutter group size querying is fixed to correctly take into account child transforms now. The code is there (clutter_group_query_coords), but is not enabled. Also, the group only resizes itself right/down, so even if the code is enabled, the returned size is still not guaranteed to be the real size of the box, as it is possible to have an actor sticking out over the left/top edge of the group box. Making the group to expand in all directions comes with side effects, as the position and size of the group is then dependent on the state of its children, which complicates things if the children or the group are animated in any way. From my experiments I am inclined to think that it will be very difficult to devise a way to make a generic container that will just work in different scenarios. So, I am really wondering, especially since ClutterGroup is a very simple layout-less container, whether we should not stick to the original behaviour and leave it to higher level containers to implement behaviour specific to the intended use. We can add convenience API to ClutterGroup that will calculate the actual size of the box relative to the ClutterGroup top-left corner, but I would leave it to the sub classes to decide what should be done with that information. Tomas -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] transient allocations
Matthew Allum wrote: Hi; I cant really comment as I really know little about deeper layout workings and how they should be. What I can say though is we tried to add layouts to clutter but when you throw in all the translations and 3D space and the kind of 'freeform' nature of Clutter we reached the conclusion it was pretty much impossible to come up with some totally generic that would cover all cases (at least that was sane API wise). Therefor we decided to at least provide enough hooks in Clutter to make it easy for layouts (and policy) to be implemented outside of Clutter for a specific use case - we've kind of started doing this in Tidy for example, and for this kind of thing its probably worth sending patches there. It would be nice however to have some very simple layout stuff in clutter itself (maybe) On Wed, 2008-02-13 at 09:27 -0500, Havoc Pennington wrote: Another thought related to this, it seems that get_size() combined with set_scale() already somewhat implements a transient allocation; because get_size() and query_coords() ignore any scaling. I _believe_ this is true even for group bounds; if I scale everything inside a group, the group's bounding box is still based on the unscaled child sizes (right? am I reading that code correctly?) This sounds like a bug - will look into it. That is by design; the get_size() functions always return untransformed sizes; the get_abs_size () return size as they end up on the screen, so get_abs_size () should return the absolute size of the group as projected on screen, but I suspect it might be broken, just projecting the group bounding box calculated by query_coords(), which is not the actual bounding box of the group if the actors in it are transformed. We probably need another function here alongside the get_size() and get_abs_size () that will calculate the actual bounding box of the group taking into account the transformations applied to the actors. Tomas -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] transient allocations
Matthew Allum wrote: On Wed, 2008-02-13 at 17:33 +, Tomas Frydrych wrote: This sounds like a bug - will look into it. That is by design; As I understand it; - get_size() should return the 'true' bounding box of its children by calling abs_size|get_vertices on each child. The problem with this is that it introduces inconsistency into the get_size() API; for some actors it will return values that are untransformed, and for some values that are semi-transformed. If nothing else, it will be impossible to document easily, and the users will end up doing tests for actor type to ensure they are getting what they want. - We have a catch22 in that get_abs size will take into account the size of all parents, but this is fixed by having a get_abs_size_in_respect_to_a_specific_parent kind of addition (hopefully better naming). Yes, we need a third size function, maybe call it clutter_actor_get_size_relative_to_ancestor (ClutterActor *self, ClutterActor *ancestor, ...) but I do not think we should mix this with the existing abs_size() and size() functions at all; let the abs_size() be always the size projected on screen (and let us fix this, so it works for the groups), and let the normal size () be untransformed (it might not be much use for groups, but it will be consistent), and let's add a third function, maybe specific for containers: clutter_container_get_real_size (ClutterConainer *), which should take into account *both* the transformation of the children, *and* those applied to the container. If we do this, we should probably add a fast path to abs_size for untransformed actor case. Yes. Tomas -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] Can i use opengl apis in clutter program
Hi, varun shrivastava wrote: is there a way to use opengl or glut APIs in a clutter program In principle yes; it really depends on what you are trying to do. Tomas -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] Can i use opengl apis in clutter program
varun shrivastava wrote: thanks but where i can find some tutorial about that? There isn't one; if you want to use OpenGL to design a custom actor, then the best thing to do is to have a look at how the existing clutter actors are implemented. If you want to use OpenGL directly outside of a custom actor, then you will need to know enough about OpenGL not to need a tutorial. Tomas On Jan 31, 2008 3:07 PM, Tomas Frydrych [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, varun shrivastava wrote: is there a way to use opengl or glut APIs in a clutter program In principle yes; it really depends on what you are trying to do. Tomas -- To unsubscribe send a mail to [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] clutter_effect_scale in 0.5
Thomas Van Machelen wrote: Hi All, I was trying to port the foofone toy to the new 0.5 api today, and i noticed a strange behaviour with clutter_effect_scale. When the function is called on an actor with CLUTTER_GRAVITY_CENTER, the actor first shifts and then starts scaling. I created a small test to reproduce the behaviour (see attachment), maybe i'm missing something obvious; but i don't know what. Please see http://lists.o-hand.com/clutter/0608.html. Tomas -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] ClutterBehaviourEllipse: angles 359
Murray Cumming wrote: What is the intended meaning of angles of 360 degrees or more with ClutterBehaviourEllipse? For instance, I see that a clockwise ellipse with a start angle of 360 and end angle of 90 causes an item to move through 360 and then an extra 90, though I'd expect it to just move 90 degrees. I could see the sense of moving through 360 degrees if the end angle was larger than the start, or if I was moving anti-clockwise, but the current behaviour seems odd. That is a bug; the big question is whether when start end for CW movement the start should be reduced to 0,360), or simply whether this should be disallowed. My inclination would be for the latter, as the former is contra-intuitive and specifying start end for CW make very little sense. Tomas -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] 2.5D?
Just make it clear that objects are 2D, with no depth, but that they move in 3D space. That's not strictly the case, and perhaps needs further clarification: ClutterActors are *abstracted* as having no depth, for reasons Matthew explained, and clutter UIs are built from the actors on the base of that abstraction. However, you can create custom actors that have 'depth' if you want them to (e.g., toys/odo), indeed any actor group will have implicit z dimension if you rotate any of its children along x or y axis. Tomas -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] 2.5D?
For instance, how hard would it be to add the possibility of applying video textures on a regular cylinder ? I would be glad to know more about custom OpenGL primitives... That really depends how hard you think OpenGL programing is. Second that, it would be nice to have one example of ClutterActor that would paint itself using GL directly. Not sure I understand what you mean by directly, but there is an example of an actor that paints a texture on a 3D mesh in toys/odo. Tomas -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] ClutterColor API bindings questions
Jonathon Jongsma wrote: Hello all. I've been thinking about playing with clutter lately, so I started working on some C++ bindings. I've got a couple of questions about the ClutterColor API. There are several functions which take a src and a dest color argument. For this email, I'll just focus on clutter_color_darken(), but the issues apply to several other functions as well. If I was to wrap this API directly into an object-oriented style, I would end up with something like: void Color::darken(Color dest) const; [A] or alternately Color Color::darken() const; [B] The problem with wrapping these functions in this way is that it seems to lose some of the flexibility of the C version. For example, with the C version, you can darken a color directly, or save a darkened version of the src color in another Color object. For example: // foo and bar are ClutterColor objects // darken foo directly: clutter_color_darken(foo, foo); // make bar a darkened version of foo clutter_color_darken(foo, bar); Now, with version A above, we could do both of these cases as well, but it seems quite awkward to do something like this in C++: foo.darken(foo); Version B above is a more natural syntax, but makes it impossible to modify the color itself -- the darkened color is always a copy (which could have some performance implications as well). This also makes for slightly awkward code in the case where you just want to work with the darkened color and don't want to keep around the original, e.g.: Color foo; Color bar = foo.darken(); // don't care about foo anymore So I had an idea to just modify the src object directly and omit the dest parameter, e.g.: void Color::darken(); [C] This means that if you wanted to create a darkened copy of the original color, you would have to make the copy yourself, e.g.: Color foo; Color dark_foo = foo; dark_foo.darken(); There are drawbacks to all of these options, but I'm leaning towards wrapping it using version [C]. I looked at what other bindings did, and it seems that the vala and C# bindings both chose version [A], the python and ruby bindings both chose [B], and I couldn't figure out what the perl bindings did :) So I guess my question is, which version most closely satisfies the intent of the API? Is modifying a color directly (e.g. clutter_color_darken(foo, foo)) an expected and common use case? (i looked at the implementation and it seems that src == dest should be safe at least). Any other bindings authors care to share why they made the decisions they did? The beauty of C++ is that you can have all three functions, although I personally would just do B and C. Of course, whether there is anything other than overhead to be gained by C++ bindings for a C library is open to question. Tomas -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] Lots of questions: GstVideoTexture cloning, strange rotation, offscreen rendering to onscreen displaying, more gobject signals...
Florent THIERY wrote: Thanks for all your answears, i'll try to follow your advices. i expected the texture to be invisible (or a mere line) when -90° orientation, but it's somewhat biased... Any hints? It should be invisible when rotated by 90 degress if, and only if, the center of the rotation is dead in the center of the stage; if it is not in the center of the stage, then it will some kind of a generic quadrangle, depending on where it is on the stage and how the perspective is set up. Yes; that's what i tried to do, but about rotation center tweaking (through rotate_center(x,y,z)), i thought it was relative to the actor (in terms of referential), is it relative to the scene? I'll post the snippet when i get my hands on it again (and if i don't manage to fix it). The rotation center is relative to the actor, but how the actor is projected on the stage is given by the position of the actor on the stage and how the perspective is set up (i.e., where the notional eye is relative to the stage and the viewing angle; in clutter the eye x,y coords match the center of the stage, and the default viewing angle is 60 degrees). Tomas -- To unsubscribe send a mail to [EMAIL PROTECTED]
