Re: Gtk over DirectFB - Moving mouse pointer through API
Hi, I figured out what my second problem was. It's a ridiculous problem so thought I'd let people know in case they face a similar problem. Since I'm developing on a VirtualBox Ubuntu, it is a virtual environment. Mouse integration was turned ON (mouse integration is a feature so that your mouse pointer can shift between host and virtual OS without having to release). Once I turned it off, my mouse pointer movement was working. Hi lkcl, I am trying to use uinput to make my mouse pointer move and register keystrokes. However, when I compile the program you have linked to (this seems to be the most popular program example on the web), everytime I run it, when it asks me for an input, I enter 'A' for example and my system crashes and restarts. I also tried using another example which moved the mouse pointer every couple of seconds. Now I found it strange that the mouse pointer doesn't physically move, but there is some virtual unseen pointer which keeps moving (I know this because I get mouse rollover effects every couple of seconds). The 2nd question isn't as important as the first, as I cannot figure out why the program is crashing. Why did the author use a getchar() to ask for input? I am very confused as to how this program works. Any help would be appreciated. Thanks a lot. -- View this message in context: http://www.nabble.com/Gtk-over-DirectFB---Moving-mouse-pointer-through-API-tp22635749p25963223.html Sent from the Gtk+ - General mailing list archive at Nabble.com. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Gtk-WARNING **: Locale not supported by C library.
Hello. When I run linphone I get the error: korn...@korenwork:~$ linphone-3 ** Message: Found lang ru (process:11306): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale. I tried to ask at linphone mailing list and got reply that it has nothing to do with linphone. Googling it didn't gave any success either. I tried to set LANG to ru, ru_RU, ru_RU.UTF-8, ru_RU.utf8, ru_RU.cp1251, ru_RU.koi8r, that is all locales I have under /usr/lib/locale (I'm using Slackware 13.0). All the answers found at Google only suggest to play with LANG variable or to recompile Libc. Since the distro contains glibc-i18n package I suspect it has all locales correctly compiled. Not sure how to check for sure. I hope you can direct me to the docs describing what can cause this particular Gtk-WARNING. Today I've read gettext documentation, did a test localization for ru, and that worked fine. Thanks. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Gtk-WARNING **: Locale not supported by C library.
As I said, I created an i18n application with gettext. It works fine. Thus, I think that means my Glibc build does support ru_RU.UTF-8. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Is GtkStyle freed properly?
Hi list, while testing some GTK code, I noticed that the style objects of widgets are not getting freed properly (or so it seems to me). I'm no expert in GTK, so I might be totally wrong here or maybe the current behavior is intended as it is? So please feel free to enlighten me :) What I think is happening is this: gtk_widget_reset_rc_style() gets called during the creation of a new widget. This function calls gtk_rc_get_style() to get the new style for a widget. If the style differs from the current one, it gets applied by gtk_widget_set_style_internal, which then calls g_object_ref on it to get the ownership of the style for the widget. That is all fine, apart from one thing. gtk_rc_get_style() returns either a new GtkStyle object or an already existing cached one. In case it returns a new style object, the ref count is 1 (isn't?) and unfortunately nobody will call g_object_unref for it. That is because gtk_widget_reset_rc_style() does not now, if it just got a new ownership (in case of a new GtkStyle object) or not (in case when it gets a cached GtkStyle object). I think this behavior of gtk_rc_get_style(), to return new objects and cached ones, is the root of the problem. If it would always pass the ownership of the returned style to the caller (e.g. by calling g_object_ref on cached styles), the caller could then always call g_object_unref to "free" it. Any thoughts? Best regards, Henry -- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Is GtkStyle freed properly?
Hi again, strange that you always start seeing new things just after you wrote an e-mail about it :) Looks like the styles are all getting put into a hash table (realized_style_ht) and freed (or unref'ed) in gtk_rc_style_finalize(). So that changes my question to "When is gtk_rc_style_finalize called", or rather why is it not called in my case. But anyway, thanks for your help :) Henry -- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
