Re: DLL Hell on Windows..
Hello, I have figured out I require 2.4.0 of libatk (by reading headers). Who can give me libatk 2.4.0 prebuild for Windows (x86)? Thanks -- Kind Regards, Robin Vossen Please avoid sending me Word, Excel or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html On 31 July 2012 15:47, Robin Vossen ro...@codeinject.org wrote: Thanks, but I forgot to add. I am using GTK3 for this. I downloaded the (gtk3)bundle. Also I've included the libatk that was shipped with it. But it didn't seem to work. -- Kind Regards, Robin Vossen Please avoid sending me Word, Excel or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html On 31 July 2012 15:03, Gabriele Greco gabriele.gr...@darts.it wrote: The issue being that I just can't seem to find the right version of the libatk library. I hope somebody can give me the right version. Or maybe a way to determine the right version. Download the official bundle version (http://ftp.gnome.org/pub/gnome/binaries/win32/gtk+/2.24/gtk+-bundle_2.24.10-20120208_win32.zip), that contains all the DLLs GTK is made of and all the external dependencies. -- Bye, Gabry ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GtkIMContext popup for on-screen-keyboard
Hello, I've tried everything I could but could not find any solution to this: I use a GtkIMContext to pop up a button to active the on-screen-keyboard via dbus (without any intention to actually do any IM communication). However, if that GtkIMContext gets activated, it subsequently renders the entry unusable because (apparently I can't just create a transparent GtkIMContext). Any ideas how to solve that? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: next steps for touch support in GTK+
hi; once again, from the department of I didn't bother to ask, so I'll make stuff up... On 2 August 2012 13:52, Morten Welinder mort...@gnome.org wrote: === 4. Which GTK+ widgets break with touch === The SpinButton item from above is one example of those. I really hope the solution is neither remove anything that doesn't work with touch or parallel widget hierarchy. GtkSwitch bugs me. It really should just have been a styling of the toggle button since it performs the same function with a different look. it does not perform the same action. But no, it is currently a totally separate widget not even derived from GtkButton. a GtkButton is a GtkContainer; adding widgets inside a light switch is pointless: how would that even work? not everything has to inherit from existing classes, *especially* if the behaviour is different (both from the user interaction standpoint *and* from the API standpoint). as a side question: do you think that I, and everyone who reviewed that patch, is stupid and doesn't know about the existence of GtkButton? really? all those questions have been posed and answered in the bug report that handled the introduction of the GtkSwitch widget. you may question the appearance of the widget (labels in, labels out, colors) but at least credit the people that wrote it some level of intelligence. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: next steps for touch support in GTK+
hi; and yet another case of I don't know that, so I'll make stuff up. On 2 August 2012 14:11, Paul Davis p...@linuxaudiosystems.com wrote: === 3. SpinButton === [ ... ] Another option is introducing a complete new widget targeted at touch usage (similar to the one in iOS Garageband) [4] which Carlos implemented already [5]. The issue is here the height, which at least in a Sugar toolbar could be not as ideal and introducing a new widget. votes++. The spin button in gtk3 has already been bastardized from its original mouse/kbd/space-friendly form. yes, because 6x6 pixel targets are *so* mouse friendly. not. if you're gifted by an overabudance of fine motor skills, you'll also want to reduce all pointer targets to 2x2 pixels; if, on the other hand, you're like the rest of the human inhabitants of this planet, you'll see that small pointer targets are *bad*, and that even before touch enters the equation. to be honest, the current spin button is better, but designed for touch. no, not yet. add TouchSpinButton or something and leave the old one alone. I have a brilliant idea instead: why don't you write your own widget if you are relying on specific appearance and behaviour? ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: next steps for touch support in GTK+
hi; On 4 August 2012 00:05, Michael Natterer mi...@gimp.org wrote: On Thu, 2012-08-02 at 08:52 -0400, Morten Welinder wrote: GtkSwitch bugs me. It really should just have been a styling of the toggle button since it performs the same function with a different look. But no, it is currently a totally separate widget not even derived from GtkButton. I could not agree more. and I could agree with you, but then we'd both be wrong. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: deprecating gdk threads
On Fri 03 Aug 2012 16:24, Pavel Holejsovsky pavel.holejsov...@gmail.com writes: I'd like to bring up the issue of how language bindings should cope with this. It is indeed pretty nasty, especially if you got used to a solution like the java-gnome one. One way to solve this would be to put the burden on the bindings implementation, and force the bindings to queue g_object_unref() calls using g_idle_add() to be executed in the main thread. This seems to be rather ineffective though. Why do you consider it to be ineffective? It seems to me that it would work just as well (or poorly) as cross-thread signal marshalling. Andy -- http://wingolog.org/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: next steps for touch support in GTK+
hi; On 4 August 2012 14:14, Paul Davis p...@linuxaudiosystems.com wrote: On Sat, Aug 4, 2012 at 3:50 AM, Emmanuele Bassi eba...@gmail.com wrote: [ ... ] and yet another case of i'm so nervous and irritated by criticism of our design decisions that i'll resort to calling people stupid ... design has nothing to do with it, sorry to disappoint the conspiracy theorists. just another case of somebody is wrong on the Internet that I should know better not to reply to. and yet another case of I don't know that, so I'll make stuff up. On 2 August 2012 14:11, Paul Davis p...@linuxaudiosystems.com wrote: === 3. SpinButton === Another option is introducing a complete new widget targeted at touch usage (similar to the one in iOS Garageband) [4] which Carlos implemented already [5]. The issue is here the height, which at least in a Sugar toolbar could be not as ideal and introducing a new widget. votes++. The spin button in gtk3 has already been bastardized from its original mouse/kbd/space-friendly form. yes, because 6x6 pixel targets are *so* mouse friendly. My remark consisted of a triple: mouse/kbd/space-friendly. What that meant, if you want it fully decomposed was: its original form that was very favorable in terms of the space it used and the amount of mouse/pointer motion required to move the value in two different directions, and was clearly oriented towards being controlled by either a mouse, whose pointer focus is small enough that the design worked, or a keyboard (where the on-screen display size is irrelevant). the one thing that it was not absolutely friendly towards is touch control, for obvious reasons just FYI, if you have a point to make, it helps actually making it - not writing down half-formed sentences and expecting people to deduce what you meant. the previous design worked: here is where you and I completely disagree. moving the controls on the horizontal axis from the vertical does not impinge in the ability to change the values; it does allow increasing the target area to the height of the entry, instead of splitting it in half. it makes the target immediately recognisable and improves the chances of hitting the desired target. it also adds the ability to do things like a proper focus ring without cramming it in with the icon. if, with the older widget layout, you could hit either the up or down arrows at first sight, just by moving the pointer without fine control, then congrats: you either have a precise control on the pointer, or you have an accurate pointer device. neither of those two conditions are a given - and, actually, the latter is becoming the norm given the incredibly crappy trackpads that are now commonplace everywhere that does not have an Apple logo. if keyboard navigation is broken, that would warrant a bug, as it would be a pretty serious regression. touch had a factor in changing the layout of the SpinButton, but less than the considerations on accessibility and input devices that I outlined above; gtk+, unlike some applications, has the challenge of working on different form factors as well as different input methods, so we need to be touch-friendly - even if we're not touch-driven (and we most definitely are not). adding a TouchSpinButton would still be recommended, and probably will happen at some point; but it would also very likely have a *very* different layout than the current SpinButton anyway. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: deprecating gdk threads
hi; On 3 August 2012 15:24, Pavel Holejsovsky pavel.holejsov...@gmail.com wrote: On 7/29/2012 12:09 PM, Matthias Clasen wrote: I've put patches for deprecating the gdk threading api at https://bugzilla.gnome.org/show_bug.cgi?id=680754 Review appreciated. I'd like to bring up the issue of how language bindings should cope with this. thanks for sending the email - it's very appreciated. I'd like to point out that all of this applies only to GTK+, given that the GDK lock is available only (well, obviously) in GDK; this means that any other GObject-based API will be problematic from a thread perspective, if you're trying to access some global state. sadly, the situation with GDK (as well as Clutter, which is not only limited by the X11 threading model, but also by the GL one) is a bit thorny in any case. Basically, the consensus from previous discussions even in language bindings, it is up to application authors to handle callbacks coming in another threads by wrapping code which needs to manipulate GTK into function/closure and schedule its execution via GLib.idle_add(). While this works generally pretty well (except that it puts the burden of knowing that the callback might be invoked in non-main thread to the application developer), there is unresolved issue with regard to destructors/finalizers. the callback for idle_add() will be invoked in the main thread - if we assume that the main thread is the one that called gtk_init()/gtk_main(), which is usually the assumption under which we generally operate. that's the whole point of using the idle_add() function to schedule an UI update. Higher level languages typically use some form of garbage collection and thus the time when finalizers are invoked are not deterministic. AFAIK python invokes finalizer callbacks from separate thread, Lua uses the same thread which is currently executing the Lua context, I'm not sure about other languages but I guess that it is similar. In the end, this means that finalizers (which typically invoke g_object_unref()) can be invoked in the context of any thread and application/binding has generally little control over this. AFAICS, this does not play nice with gdk threads deprecation, because one way to solve the GC finalization problems was to gdk_threads_enter() before entering g_object_unref() call. that would have only worked for specific classes, namely the ones that manage GDK resources; dispose and finalize should be thread safe in GObject, as far as GObject is concerned. using threads_enter()/unref()/leave() would also have worked only on X11, and assuming that the support for threading in Xlib was enabled. otherwise, it simply was working by sheer accident. One way to solve this would be to put the burden on the bindings implementation, and force the bindings to queue g_object_unref() calls using g_idle_add() to be executed in the main thread. This seems to be rather ineffective though. can you explain why would it be ineffective? keeping the GObject instance alive until needed would be fine; this obviously assumes that there is a main loop still spinning, but if you don't have one you can use g_main_context_invoke() to schedule the destruction of every widget from the main context. Another way to solve this problem might be inside GDK itself, which might check whether native window disposal function needs to be transferred to the main thread and if yes, do it internally and transparently. The advantages are: + it is done only when needed (eg only on Win32/Quartz/whatever, only when called from 'bad' thread, only when g_object_unref() actually results in window destruction) + much more error prone - the actual native window destroy function can be called 'asynchronously' from the POV of the caller. - someone has to implement this :-( scheduling the destruction for the next main loop iteration could be feasible, but it would need to be implemented as you correctly pointed out. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: next steps for touch support in GTK+
On Sat, Aug 4, 2012 at 3:44 AM, Emmanuele Bassi eba...@gmail.com wrote: GtkSwitch bugs me. It really should just have been a styling of the toggle button since it performs the same function with a different look. it does not perform the same action. That is a baseless assertion. Of course it does. And stop misquoting me, please. We're talking about two widgets that are both used to turn something off or on. And nothing else. How is that not the same function? In other words, is there a place where one of them is used that would not function right if the other one was substituted? as a side question: do you think that I, and everyone who reviewed that patch, is stupid and doesn't know about the existence of GtkButton? Nope, I don't. M. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: next steps for touch support in GTK+
hi; On 4 August 2012 15:18, Morten Welinder mort...@gnome.org wrote: On Sat, Aug 4, 2012 at 3:44 AM, Emmanuele Bassi eba...@gmail.com wrote: GtkSwitch bugs me. It really should just have been a styling of the toggle button since it performs the same function with a different look. it does not perform the same action. That is a baseless assertion. Of course it does. And stop misquoting me, please. I do not misquote you, but I may be misunderstanding you: what do you mean what you say performs the same function? see below. We're talking about two widgets that are both used to turn something off or on. And nothing else. How is that not the same function? one implies a soft action (GtkToggleButton), whereas the other implies something similar of a hardware switch (GtkSwitch). they both have their use cases which are not interchangeable: https://live.gnome.org/GnomeOS/UX/Guidelines/SwitchWidget the page above should become part of the new Human Interface guidelines/design patterns. not every application should use switches, nor existing applications should be mindlessly migrated to moving from toggle and/or check buttons to switches. In other words, is there a place where one of them is used that would not function right if the other one was substituted? hopefully, the page above answers your questions; it can be improved if it doesn't. the short takeaway is that the switch should be used in specific cases, and that the way its been defined as a widget does not allow inheritance from GtkToggleButton or GtkButton (no label, no children, styling of trough and handle). ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: next steps for touch support in GTK+
On Sat, Aug 04, 2012 at 03:39:05PM +0100, Emmanuele Bassi wrote: one implies a soft action (GtkToggleButton), whereas the other implies something similar of a hardware switch (GtkSwitch). As every user knows, widgets relay wishes to magic pixies. I wonder if that is soft or hard action, maybe it depends on how hard you need to beat the pixies to do what you want. Do you actually expect different kinds of on/off controls to be mixed wildly because each was selected based on how soft is the action it implies? they both have their use cases which are not interchangeable: https://live.gnome.org/GnomeOS/UX/Guidelines/SwitchWidget the page above should become part of the new Human Interface guidelines/design patterns. not every application should use switches, nor existing applications should be mindlessly migrated to moving from toggle and/or check buttons to switches. All cases listed there as good use cases of GtkSwitch would be – for me – improved by using a plain toggle button. It would take less horizontal space, it would be less wordy, it would not leave me wondering whether it shows ON when it is on or whether I should move it to ON if I want it ON (yes, I still do not remember it), it would not look trendy, and it would not have translation issues. In fact, even the ‘wrong’ checkbuttons would represent an improvement for me. I would also say the widgets are completely interchangeable, but forced to interpret the statement ‘their use cases are not interchangeable' somehow I would have to conclude that GtkSwitch has no meaningful use case at all. Could the page be improved to include this? In my opinion it could lead to a considerable simplification of the guidelines. the short takeaway is that the switch should be used in specific cases, and that the way its been defined as a widget does not allow inheritance from GtkToggleButton or GtkButton (no label, no children, styling of trough and handle). I am sorry but, again, this is just a recapitulation of the status quo. Stating it a hundered times does not make problems vanish magically even if you beat the pixies really hard with a switch. Yeti ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: next steps for touch support in GTK+
=== 6. OSK widget context provider (e.g. search vs open vs go...) === Matthias said there was a patch floating around for that. I looked in the bugs with patches attached in bugzilla but could not find it. If someone knows where it is would be great. https://bugzilla.gnome.org/show_bug.cgi?id=651244 is the bug I had in mind. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Bug #679291 (please review)
hi John; On 4 August 2012 21:43, John Lindgren john.lindg...@aol.com wrote: About a month ago I sent a patch to the bug tracker to fix a problem where GtkTreeView would emit signals, thereby executing user code, during its destroy cycle. This is a potentially serious problem as the state of the GtkTreeView is more or less undefined as it is being destroyed. One André Klapper (never heard of him before and don't know his email) closed the bug as a duplicate but did nothing further to resolve it. Can someone please review the patch [1] and commit it? André is our resident bug master. I left a comment in bug 671939, but I can also repeat it here. the patch in attachment 217892 looks okay - but what I'd like to see: a) bisecting to see what commit broke this; b) a test case for the TreeView test suite, to ensure we don't regress again; c) a patch done using git format-patch or git bz, so that we can credit the author. John, would you be so kind to look at this? that would be stellar. thanks again for the patch. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Bug #679291 (please review)
On 08/04/2012 04:58 PM, Emmanuele Bassi wrote: hi John; (snip) I left a comment in bug 671939, but I can also repeat it here. the patch in attachment 217892 looks okay - but what I'd like to see: a) bisecting to see what commit broke this; b) a test case for the TreeView test suite, to ensure we don't regress again; c) a patch done using git format-patch or git bz, so that we can credit the author. John, would you be so kind to look at this? that would be stellar. I can write a test case and do a bisect, I think. Are there any instructions around as to how the test case should be encapsulated (stand-alone program, C function)? -- John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Bug #679291 (please review)
On Sat, Aug 4, 2012 at 4:58 PM, Emmanuele Bassi eba...@gmail.com wrote: the patch in attachment 217892 looks okay - but what I'd like to see: a) bisecting to see what commit broke this; b) a test case for the TreeView test suite, to ensure we don't regress again; c) a patch done using git format-patch or git bz, so that we can credit the author. The behaviour change was introduced during the heavy refactoring of treeview a11y done by Benjamin last winter. We've talked about 'fixing' this (ie suppressing the signal in the destroy path), but there's a more general question here: do we want to add tons of special-cases to prevent this kind of noise in destroy paths ? There's plenty of other places where this could happen. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
roadmap for 3.6
Here are my thoughts about what we can achieve between now and 3.6: - Fix animations (make spinners spin again): Benjamin is working on this - Fix state propagation (the notorious grayed-out labels): Benjamin is working on this - Review and merge Owen's animation / paint clock work: Owen is going to post information about this here any day now - Review and merge Carlos' touch selection work: I hope that Carlos will push his updates to the touch-text-selection branch soon - Add the entry hints for input methods and onscreen keyboards: https://bugzilla.gnome.org/show_bug.cgi?id=651244 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Bug #679291 (please review)
On 08/04/2012 05:54 PM, Matthias Clasen wrote: On Sat, Aug 4, 2012 at 4:58 PM, Emmanuele Bassi eba...@gmail.com wrote: the patch in attachment 217892 looks okay - but what I'd like to see: a) bisecting to see what commit broke this; b) a test case for the TreeView test suite, to ensure we don't regress again; c) a patch done using git format-patch or git bz, so that we can credit the author. The behaviour change was introduced during the heavy refactoring of treeview a11y done by Benjamin last winter. We've talked about 'fixing' this (ie suppressing the signal in the destroy path), but there's a more general question here: do we want to add tons of special-cases to prevent this kind of noise in destroy paths ? There's plenty of other places where this could happen. What do you suggest as an alternative? I don't think it's reasonable to require every GTK+ client to disconnect every signal handler from every object before it is destroyed, in fear of the handler being called from the destroy path, when the internal state of the object is more or less undefined. How about disconnecting all signal handlers on the GTK+ side immediately after emitting the destroy signal? It seems reasonable to me that no signal should ever be emitted after destroy, but I could be overlooking something. -- John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: next steps for touch support in GTK+
Toggle buttons and the switch widget both suffer usability problems for me. The visual look of a button represents an action to be performed in my mind, perhaps why it was referred to it as a soft-action? So when a button is stateful it can create ambiguity depending on the text of the button. The old, Does it perform the action shown on the label or does the label reflect the current state? This causes dissonance in my mind which can hopefully be resolved by the widget having another visual indication of the state (the depressed look). A typical example of this failure is with Glades usage of toggle buttons on a selected widgets properties (don't mean to offend anyone here, just stating my experience!). This is further confused by the text changing when you press the button to Yes or No. Moving on to the switch widget, I think it mostly suffers the same issues I've described. Does the text on the switch widget represent the current state or the action of setting the state to on or off. Again the visual indication barely saves me here (having it highlighted to blue). Given this, the visual indication aside from the text is what I use to determine the state of either a toggle or switch. This makes me think the text on the widget only confuses things and the widget could simply be a checkbox which would resolve all visual ambiguity. However, I do see value in what is described in the UX guidelines regarding the switch widget and associating it with things that take time (not just a simple checkbox state). The guidelines also don't describe explicit styling of the switch which is my problem with it. I think the visual ambiguity could easily be fixed by showing both available states, looks like it is already being discussed here: https://bugzilla.gnome.org/show_bug.cgi?id=644658 -Simon On Sat, Aug 4, 2012 at 8:47 AM, David Nečas y...@physics.muni.cz wrote: On Sat, Aug 04, 2012 at 03:39:05PM +0100, Emmanuele Bassi wrote: one implies a soft action (GtkToggleButton), whereas the other implies something similar of a hardware switch (GtkSwitch). As every user knows, widgets relay wishes to magic pixies. I wonder if that is soft or hard action, maybe it depends on how hard you need to beat the pixies to do what you want. Do you actually expect different kinds of on/off controls to be mixed wildly because each was selected based on how soft is the action it implies? they both have their use cases which are not interchangeable: https://live.gnome.org/GnomeOS/UX/Guidelines/SwitchWidget the page above should become part of the new Human Interface guidelines/design patterns. not every application should use switches, nor existing applications should be mindlessly migrated to moving from toggle and/or check buttons to switches. All cases listed there as good use cases of GtkSwitch would be – for me – improved by using a plain toggle button. It would take less horizontal space, it would be less wordy, it would not leave me wondering whether it shows ON when it is on or whether I should move it to ON if I want it ON (yes, I still do not remember it), it would not look trendy, and it would not have translation issues. In fact, even the ‘wrong’ checkbuttons would represent an improvement for me. I would also say the widgets are completely interchangeable, but forced to interpret the statement ‘their use cases are not interchangeable' somehow I would have to conclude that GtkSwitch has no meaningful use case at all. Could the page be improved to include this? In my opinion it could lead to a considerable simplification of the guidelines. the short takeaway is that the switch should be used in specific cases, and that the way its been defined as a widget does not allow inheritance from GtkToggleButton or GtkButton (no label, no children, styling of trough and handle). I am sorry but, again, this is just a recapitulation of the status quo. Stating it a hundered times does not make problems vanish magically even if you beat the pixies really hard with a switch. Yeti ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: roadmap for 3.6
Maybe not directly related, but will gtjk+ gain the animation capabilities of Clutter (via merging with Clutter or layering on top of Clutter), such that gtk+ widgets can behave like Clutter actors? On Sat, Aug 4, 2012 at 3:13 PM, Matthias Clasen matthias.cla...@gmail.comwrote: Here are my thoughts about what we can achieve between now and 3.6: - Fix animations (make spinners spin again): Benjamin is working on this - Fix state propagation (the notorious grayed-out labels): Benjamin is working on this - Review and merge Owen's animation / paint clock work: Owen is going to post information about this here any day now - Review and merge Carlos' touch selection work: I hope that Carlos will push his updates to the touch-text-selection branch soon - Add the entry hints for input methods and onscreen keyboards: https://bugzilla.gnome.org/show_bug.cgi?id=651244 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Andy Tai, a...@atai.org, Skype: licheng.tai Year 2012 民國101年 自動的精神力是信仰與覺悟 自動的行為力是勞動與技能 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
