Re: How do I request a patch review?
On Fri, 2010-03-19 at 18:31 +0100, Philip Van Hoof wrote: > On Mon, 2010-03-08 at 09:44 +0100, Andre Klapper wrote: > > Am Sonntag, den 07.03.2010, 19:56 -0800 schrieb MPR: > > > My assumption is that there must be some patch review process that was > > > not followed. > > > > No, there's not. > > And this isn't a good thing To be clear there *is* a patch review process. You file your patch in bugzilla and the maintainer reviews it. There's no point in having to "request" a review of something - if something is submitted to bugzilla it needs to be reviewed. So, all we can be talking about is whether there's some sort of "exception" process when the maintainer isn't handling submitted patches and can't be contacted or when contacted has no time to do reviews. - Owen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: How do I request a patch review?
On Mon, 2010-03-08 at 09:44 +0100, Andre Klapper wrote: > Am Sonntag, den 07.03.2010, 19:56 -0800 schrieb MPR: > > My assumption is that there must be some patch review process that was > > not followed. > > No, there's not. And this isn't a good thing > andre Cheers, Philip -- Philip Van Hoof freelance software developer Codeminded BVBA - http://codeminded.be ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
On Fri, 2010-03-19 at 16:28 +, Bastien Nocera wrote: > On Fri, 2010-03-19 at 15:25 +, Martyn Russell wrote: I tried to sent this several times, but it looks like GMANE is not working for me today ... And Evolution has its "reply to all" feature all wrong too, apparently. [CUT] > > What I mean is, what difference does it make if the data is readonly or > > readwrite? > > I'm mentioning read-only because I believe it would be possible to > implement with your current architecture. If you want read/write access, > it would probably involve file locking, and all sort of nastiness that I > understand might be problematic. > > Reading the data through a native API instead of through D-Bus would > mean being able to shift very large amounts of data without the > marshalling/demarshalling (say, loading 100k audio tracks' metadata > would probably take a large amount of time over D-Bus, where it would be > of negligeable duration through a more direct API). This isn't as easy at it sounds, I posted a comment on the bug you reported explaining what the difficulty is. https://bugzilla.gnome.org/show_bug.cgi?id=613255#c1 > > Surely applications would want ONE method not two for > > communicating with Tracker's. Or did I misunderstand somehow? > > This would all be hidden behind the tracker libraries for most > developers, so it shouldn't matter. You'd get the same result, just much > faster. Cheers, Philip -- Philip Van Hoof freelance software developer Codeminded BVBA - http://codeminded.be ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
On Fri, 2010-03-19 at 12:59 +, Bastien Nocera wrote: > On Sun, 2010-02-21 at 18:12 +0200, Zeeshan Ali wrote: > > Hi, > > > 2 things come to mind: > - Tracker shouldn't need to use D-Bus to access its database read-only: > https://bugzilla.gnome.org/show_bug.cgi?id=613255 This isn't as easy at it sounds, I posted a comment on the bug you reported explaining what the difficulty is. https://bugzilla.gnome.org/show_bug.cgi?id=613255#c1 Cheers, Philip -- Philip Van Hoof freelance software developer Codeminded BVBA - http://codeminded.be ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
On Fri, 2010-03-19 at 15:25 +, Martyn Russell wrote: > On 19/03/10 13:56, Bastien Nocera wrote: > > On Fri, 2010-03-19 at 13:36 +, Martyn Russell wrote: > >> On 19/03/10 12:59, Bastien Nocera wrote: > >>> On Sun, 2010-02-21 at 18:12 +0200, Zeeshan Ali wrote: > >>> > >>> 2 things come to mind: > >>> - Tracker shouldn't need to use D-Bus to access its database read-only: > >>> https://bugzilla.gnome.org/show_bug.cgi?id=613255 > >> > >> Well, D-Bus provides a single entry point for any requests to the data. > >> If we then provide some direct access using a library, that complicates > >> things further. At this point we are not threaded, however, we are > >> currently looking into the possibility of doing this due to recent events. > >> > >> What is so bad about using D-Bus? > > > > See the original mail. It's pushing data over D-Bus that already went > > through the bus in a different form. > > > >> What is the relevance of read-only? > > > > I don't understand the question, or how it relates to the point I was > > making. > > What I mean is, what difference does it make if the data is readonly or > readwrite? I'm mentioning read-only because I believe it would be possible to implement with your current architecture. If you want read/write access, it would probably involve file locking, and all sort of nastiness that I understand might be problematic. Reading the data through a native API instead of through D-Bus would mean being able to shift very large amounts of data without the marshalling/demarshalling (say, loading 100k audio tracks' metadata would probably take a large amount of time over D-Bus, where it would be of negligeable duration through a more direct API). > Surely applications would want ONE method not two for > communicating with Tracker's. Or did I misunderstand somehow? This would all be hidden behind the tracker libraries for most developers, so it shouldn't matter. You'd get the same result, just much faster. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
On Fri, 2010-03-19 at 16:56 +0200, Zeeshan Ali (Khattak) wrote: [CUT] Short note on... > Actually this issue is partly solved. I made sure that tracker guys > have the right ontology ..metadata keys Let's just call these things ontologies. That's just what everybody in RDF calls it. And those alternative versions of the word like "the metadata keys", "the fields", "the schema", "description of the things" ... are just confusing. It's called an ontology. It wont hurt you. It wont rot your brain. It's terminology that everybody in RDF uses. Let's get over it. Cheers, Philip -- Philip Van Hoof freelance software developer Codeminded BVBA - http://codeminded.be ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
On 19/03/10 13:56, Bastien Nocera wrote: On Fri, 2010-03-19 at 13:36 +, Martyn Russell wrote: Well, D-Bus provides a single entry point for any requests to the data. If we then provide some direct access using a library, that complicates things further. At this point we are not threaded, however, we are currently looking into the possibility of doing this due to recent events. What is so bad about using D-Bus? See the original mail. It's pushing data over D-Bus that already went through the bus in a different form. Ah I see your point now. Even at this point there is no direct access API to Tracker, it is all done over d-bus. Performance wise, we don't have problems generally. Perhaps this is a reason to seriously consider a direct access library. I don't think it will happen before 0.8 however. -- Regards, Martyn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
On 19/03/10 13:56, Bastien Nocera wrote: On Fri, 2010-03-19 at 13:36 +, Martyn Russell wrote: On 19/03/10 12:59, Bastien Nocera wrote: On Sun, 2010-02-21 at 18:12 +0200, Zeeshan Ali wrote: 2 things come to mind: - Tracker shouldn't need to use D-Bus to access its database read-only: https://bugzilla.gnome.org/show_bug.cgi?id=613255 Well, D-Bus provides a single entry point for any requests to the data. If we then provide some direct access using a library, that complicates things further. At this point we are not threaded, however, we are currently looking into the possibility of doing this due to recent events. What is so bad about using D-Bus? See the original mail. It's pushing data over D-Bus that already went through the bus in a different form. What is the relevance of read-only? I don't understand the question, or how it relates to the point I was making. What I mean is, what difference does it make if the data is readonly or readwrite? Surely applications would want ONE method not two for communicating with Tracker's. Or did I misunderstand somehow? -- Regards, Martyn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
Le vendredi 19 mars 2010, à 17:17 +0200, Zeeshan Ali (Khattak) a écrit : > On Fri, Mar 19, 2010 at 4:53 PM, Vincent Untz wrote: > > I didn't see your request for help on irc, and I'm sure many people > > didn't. > > Thats ok, people have better things to do. :) Just to be clear, I > didn't mean to insult anyone, was just telling my excuse. :) Oh sure, there was no insult. My point was that if nobody can help you at a given time on irc, then it doesn't mean it's impossible to do ;-) Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
On Fri, Mar 19, 2010 at 4:53 PM, Vincent Untz wrote: > Le vendredi 19 mars 2010, à 16:39 +0200, Zeeshan Ali (Khattak) a écrit : >> I didn't miss that. :) If you read carefully he said "just to be >> safe" and hence it's not so important. Still, I tried to setup the > > I said "on the safe side" because I've no good example of when those > strings would appear. But I would expect them to be translatable :-) These are error messages mostly what gnome apps/libs spew out on console using g_critical/warning/error functions. >> translation framework, got into some weird autofoo issues, asked some >> gnome developers (including you) to help me out on IRC and when nobody >> replied, I gave-up and started working on something more useful: unit >> tests. > > Do you have a bug report somewhere with the issues that you had? No but I can file a bug report and assign it to you if you like. :) Try building that rygel branch i linked to and you'll see what the problem is. If you feel lazy, just ping me in private on irc and I'll provide the details of the issue. > I didn't see your request for help on irc, and I'm sure many people > didn't. Thats ok, people have better things to do. :) Just to be clear, I didn't mean to insult anyone, was just telling my excuse. :) -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New external dependencies for 2.32: telepathy-logger
Le vendredi 19 mars 2010 à 11:39 -0300, Jonh Wendell a écrit : > I know we have gains, but we also have cons, with the desktop full of > processes. Perhaps we should only activate the daemon when needed by > some application, and deactivate it when the application closes? That's almost already the case here. The tp-logger daemon is automatically launched when first conversation is started. It's currently not automatically stopped but I just talked to the tp-logger developers and they will consider stopping it after some time of inactivity. G. -- Guillaume Desmottes Jabber GPG 1024D/711E31B1 | 1B5A 1BA8 11AA F0F1 2169 E28A AC55 8671 711E 31B1 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
Hi Bastien, On Fri, Mar 19, 2010 at 2:59 PM, Bastien Nocera wrote: > > 2 things come to mind: > - Tracker shouldn't need to use D-Bus to access its database read-only: > https://bugzilla.gnome.org/show_bug.cgi?id=613255 I couldn't agree more. So here is my plan: I will go with all plugin[1] external approach using the new D-Bus spec[2] . This will mean SLOW (its already very slow with my queries that has lots of optionals) tracker backend but I leave that for tracker guys to solve. They can either do what you asked for above or they can implement this D-Bus interface directly. > - The way you currently use Tracker means that there's no way to > differentiate between videos that I want indexed and searchable, and the > ones that I want to export. This is a privacy problem and could be > solved by making applications provide their catalogues instead (which > could be powered by Tracker). Actually this issue is partly solved. I made sure that tracker guys have the right ontology ..metadata keys for this. However, there is currently no UI for user to be able to mark media to be exported. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 [1] Except the ones that serve gstreamer source elements & hence must be in-process but these are developer/test oriented. [2] http://live.gnome.org/Rygel/MediaServer2Spec ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
Le vendredi 19 mars 2010, à 16:39 +0200, Zeeshan Ali (Khattak) a écrit : >I didn't miss that. :) If you read carefully he said "just to be > safe" and hence it's not so important. Still, I tried to setup the I said "on the safe side" because I've no good example of when those strings would appear. But I would expect them to be translatable :-) > translation framework, got into some weird autofoo issues, asked some > gnome developers (including you) to help me out on IRC and when nobody > replied, I gave-up and started working on something more useful: unit > tests. Do you have a bug report somewhere with the issues that you had? I didn't see your request for help on irc, and I'm sure many people didn't. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New external dependencies for 2.32: telepathy-logger
On Fri, 2010-03-19 at 11:39 -0300, Jonh Wendell wrote: > I know we have gains, but we also have cons, with the desktop full of > processes. Perhaps we should only activate the daemon when needed by > some application, and deactivate it when the application closes? Pretty much all of the per-user daemons are started on demand, and if they don't kill themselves when not in use for a while then that is generally a bug. Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New external dependencies for 2.32: telepathy-logger
Hello, folks. My comment bellow is not about the proposal itself, but about the desktop as a whole. Em Sex, 2010-03-19 às 14:39 +0100, Guillaume Desmottes escreveu: > This module has 2 part: > - A daemon used to logs messages (but will gain support for logging more > events such as calls in the future). I'm a bit worried about more and more deamons running in the desktop. We are getting fat over and over. GNOME Journal needs a daemon, same for tracker, now empathy. Even gwibber (which was supposed to be a simple frontend to microbloggin services and now is getting really fat) needs some daemons to run properly. I know we have gains, but we also have cons, with the desktop full of processes. Perhaps we should only activate the daemon when needed by some application, and deactivate it when the application closes? As an observation, here in Brazil we have lots of massive users in 'Telecentros' (social entities that offer computer access to poor people) that don't have great machines. Actually they use old donated machines, and running a desktop full of daemons on these machines can be a pain. Cheers, -- Jonh Wendell http://www.bani.com.br ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
Hi, On Fri, Mar 19, 2010 at 2:56 PM, Frederic Peters wrote: > Zeeshan Ali (Khattak) wrote: > >> > Heh, the logic should be reversed :-) It can't be approved (or likely to >> > be approved) until the app is translatable. >> >> Since me and Bastien (based on Lennart's arguments on this thread) >> agreed to kill the preferences UI in favor of some simple options to >> be added to gnome-user-share dialog, do I still need to do this for my >> proposal to be considered? > > In another branch of this thread, Vincent Untz gave you an answer: > > | > Yeah something like that. However most of the errors/warnings are > | > sent over to the (remote) client as well and it all depends on the > | > client whether it shows them to user or not. > | > | In this case, it probably makes sense to have them translated, to be > | on the safe side. > > And that makes me think the preferences UI was not all there was to > Rygel, other parts should be translatable as well. I didn't miss that. :) If you read carefully he said "just to be safe" and hence it's not so important. Still, I tried to setup the translation framework, got into some weird autofoo issues, asked some gnome developers (including you) to help me out on IRC and when nobody replied, I gave-up and started working on something more useful: unit tests. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 P.S. In case you are interested, here is my attempt: http://gitorious.org/rygel/rygel/commits/l10n ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
On Fri, 2010-03-19 at 13:36 +, Martyn Russell wrote: > On 19/03/10 12:59, Bastien Nocera wrote: > > On Sun, 2010-02-21 at 18:12 +0200, Zeeshan Ali wrote: > > > > 2 things come to mind: > > - Tracker shouldn't need to use D-Bus to access its database read-only: > > https://bugzilla.gnome.org/show_bug.cgi?id=613255 > > Well, D-Bus provides a single entry point for any requests to the data. > If we then provide some direct access using a library, that complicates > things further. At this point we are not threaded, however, we are > currently looking into the possibility of doing this due to recent events. > > What is so bad about using D-Bus? Perhaps the fact that D-Bus wasn't meant as a "super fast"-IPC and the fact that having to do two task switches + all the associated wire overhead to retrieve a piece of data will be quite slow? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
On Fri, 2010-03-19 at 13:36 +, Martyn Russell wrote: > On 19/03/10 12:59, Bastien Nocera wrote: > > On Sun, 2010-02-21 at 18:12 +0200, Zeeshan Ali wrote: > > > > 2 things come to mind: > > - Tracker shouldn't need to use D-Bus to access its database read-only: > > https://bugzilla.gnome.org/show_bug.cgi?id=613255 > > Well, D-Bus provides a single entry point for any requests to the data. > If we then provide some direct access using a library, that complicates > things further. At this point we are not threaded, however, we are > currently looking into the possibility of doing this due to recent events. > > What is so bad about using D-Bus? See the original mail. It's pushing data over D-Bus that already went through the bus in a different form. > What is the relevance of read-only? I don't understand the question, or how it relates to the point I was making. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
New external dependencies for 2.32: telepathy-logger
Hi, I'd like to make Empathy depends on the telepathy-logger [1] during the 2.31 cycle. This module has 2 part: - A daemon used to logs messages (but will gain support for logging more events such as calls in the future). - A library to allow client to easily access logs. This approach has the following advantages: - Ensuring that all the conversations are properly logged; even when using another Telepathy client or if Empathy crashed. - Allow other applications to retrieve logs; this will be used by gnome-shell. - More code shared between Telepathy clients. - Better Telepathy integration. - New fancy feature such as displaying the list of contacts to who user recently talked for example. Empathy has currently an optional dependency on tp-logger (used by MeeGo). I plan to remove it to reduce #ifdef in code and be able to properly implement Approvers [2] in Empathy. G. [1] http://telepathy.freedesktop.org/wiki/Logger [2] https://bugzilla.gnome.org/show_bug.cgi?id=599158 -- Guillaume Desmottes Jabber GPG 1024D/711E31B1 | 1B5A 1BA8 11AA F0F1 2169 E28A AC55 8671 711E 31B1 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
On 19/03/10 12:59, Bastien Nocera wrote: On Sun, 2010-02-21 at 18:12 +0200, Zeeshan Ali wrote: 2 things come to mind: - Tracker shouldn't need to use D-Bus to access its database read-only: https://bugzilla.gnome.org/show_bug.cgi?id=613255 Well, D-Bus provides a single entry point for any requests to the data. If we then provide some direct access using a library, that complicates things further. At this point we are not threaded, however, we are currently looking into the possibility of doing this due to recent events. What is so bad about using D-Bus? What is the relevance of read-only? -- Regards, Martyn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
On Sun, 2010-02-21 at 18:12 +0200, Zeeshan Ali wrote: > Hi, > > - Original message - > > > > The only comments I would make are: > > - The preferences UI is pretty horrible > > I agree but I really suck at UIs so if you could list specific issues, > I promise to fix them soon. As you recall you filed some bugs > regarding this and I fixed them all soon after except for the one I > didn't understand. BTW that bug is still waiting for your > explaination. > > > - The plugin API should instead be a convenience library around > using > > the D-Bus API, which would make implementing other front-ends to > those > > plugins easier. I guess it wouldn't be powerful enough for some > plugins > > though, so maybe it should be an interface with 2 possible > > implementations, and the more powerful one having some extra > > functionality. > > In theory I agree but in practice this will mean double d-bus round > trips in case of tracker (a backend very important for maemo > uses-case) unless/until tracker guys agree to implement the > MediaServer spec. Last I talked to Ivan about this, he didn't seem > very enthusiastic about this. :( 2 things come to mind: - Tracker shouldn't need to use D-Bus to access its database read-only: https://bugzilla.gnome.org/show_bug.cgi?id=613255 - The way you currently use Tracker means that there's no way to differentiate between videos that I want indexed and searchable, and the ones that I want to export. This is a privacy problem and could be solved by making applications provide their catalogues instead (which could be powered by Tracker). ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
Zeeshan Ali (Khattak) wrote: > > Heh, the logic should be reversed :-) It can't be approved (or likely to > > be approved) until the app is translatable. > > Since me and Bastien (based on Lennart's arguments on this thread) > agreed to kill the preferences UI in favor of some simple options to > be added to gnome-user-share dialog, do I still need to do this for my > proposal to be considered? In another branch of this thread, Vincent Untz gave you an answer: | >Yeah something like that. However most of the errors/warnings are | > sent over to the (remote) client as well and it all depends on the | > client whether it shows them to user or not. | | In this case, it probably makes sense to have them translated, to be | on the safe side. And that makes me think the preferences UI was not all there was to Rygel, other parts should be translatable as well. Cheers, Frederic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
Hi, On Mon, Feb 22, 2010 at 4:17 PM, Vincent Untz wrote: >> > We have pride in our incredible translation teams; it would be really >> > nice if Rygel had the infrastructure in place to be translated. >> > >> > Is this planned? >> >> It most certainly is and if it starts to become very likely that my >> proposal will be approved, I'll put this in my high-priority todo >> list. > > Heh, the logic should be reversed :-) It can't be approved (or likely to > be approved) until the app is translatable. Since me and Bastien (based on Lennart's arguments on this thread) agreed to kill the preferences UI in favor of some simple options to be added to gnome-user-share dialog, do I still need to do this for my proposal to be considered? -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: bumping clutter's external dependencies for 2.30
On Thu, 2010-03-18 at 23:20 -0500, Jason D. Clinton wrote: > On Thu, Mar 18, 2010 at 6:51 PM, Jason D. Clinton > wrote: > If there's some reason to bump that I don't know about, then > we can, of course, but everything will need to be checked and > I don't have time for that until this weekend. > > > I briefly compiled clutter-1.2 HEAD and clutter-gtk-0.10 HEAD and > tried everything. Aisleriot has some new rendering artifacts but other > than that, I'm cautiously optimistic that it would be safe to bump the > dependency. It appears to be needed anyway since older > clutter-gtk-0.10 doesn't compile against GTK+ 2.19.ish. (Two cherry > picks were enough to fix it.) yep, the main reason for asking to bump from clutter-gtk 0.10.2 to 0.10.4 is because of the fixes that went into making clutter-gtk compile against the version of gtk+ that's going to ship with Gnome 2.30. this brings clutter-1.2 along because of the changes in dealing with input device state which affect embedding a stage into another toolkit like gtk+. the proposed bumps for 2.30 are: clutter >= 1.2.0 clutter-gtk >= 0.10.4 the artifacts might be due to the new sub-region update code, or if aisleriot is reading back texture data from cogl; we have two fixes already in the pipeline for that that will be backported to clutter-1.2 today. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
