Have I just found a bug in GTK+ ComboBox?
Hello! Context: https://bitbucket.org/p2t2p/gtkcombodemo/src/19be8dfe788c1aec1 a5384eb107facaa38e121ff/main.js?at=master=file-view-default TL;DR GTK+ renders ComboBox popup off-screen if the item is too low in the list. Help needed: * Please confirm if it is a bug or if there is such a bug. * How do I figure out the version of GTK+ installed? * What environment data GTK+ team needs to confirm if this is a bug? Long story I'm writing a small utility which uses GTK+ ComboBox widget. I have a pretty long list of 2 cells in that ComboBox. First cell is a GIcon Second cell is text (gchar* I think). I'm showing a list of apps installed on a machine in that ComboBox. I think I'm doing something wrong or I've discovered a bug: Whenever I select an item in this ComboBox popup which is located at certain "distance" from the top in the list of all items, this ComboBox stops showing the popup. Whenever I click on the ComboBox it highlights itself but the popup is invisible. It reacts to arrow keys, though. If I press arrow key and then if I press enter the selection changes. I believe it renders the popup off-screen. That happens only if I pick an item at certain distance from the top in the list. If I pick an item which is closer to the top it works fine. Also it seems that this distance depends on the window position on the screen - the lower window on the screen, the longer the "failure" distance. I've prepared a short demo which reproduces the behaviour on _my_ machine: https://bitbucket.org/p2t2p/gtkcombodemo/src/19be8dfe7 88c1aec1a5384eb107facaa38e121ff/main.js?at=master=file-view- default Thank you! ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Could this be a background-color bug in GTK+3.22?
Dear all,
I'm a user of the document viewer Zathura
(https://pwmt.org/projects/zathura/) which uses GTK+ for its interface
Since upgrading to GTK+ 3.22 it has suffered from a background color
bug/issue. The developers are not
giving this high priority (which is fair enough) so I'm trying to
investigate it. Now asking your mailing list for input.
Please bear with me as I'm not GTK+ developer.
This video/gif demonstrates the issue: http://i.imgur.com/xcCgB03.mp4
What you see is this:
# 1. Zathura on the left with no document open, running in debug mode
with GTK+ Inspector open on the top right.
The background is green because I've specified 'default-bg' as "green"
in a config file and the application has this CSS rule:
#@session@ * {
color: @default-fg@;
background-color: @default-bg@;
background-image: none;
}
#2: I turn the background brown by specifying "* { background: brown; }"
in the interactive debuggers CSS tab.
#3: Then a pdf file is opened and zoomed until it overflows the top and
bottom of the window. This cause the window
background to turn black, and when I zoom out again the background stays
black.
#4: I change the CSS specification in the interactive debugger and the
background color reappears as it is intended.
I assume this triggers a reload/reapplication of the CSS.
Could that be a GTK bug? It appears as a rendering issue. When the
background appears black GTK+ Inspector reports
the 'background-color' property as green or brown as I specified, not
black as is displayed/rendered.
I'm afraid I don't have a minimal working example reproducing the
problem. I would just like your input on whether it could be
a GTK bug or not.
Thank you for your input!
/ Jonas
P.S. Should anyone be interested in the application's code or CSS it is
available here:
git clone https://git.pwmt.org/pwmt/girara.git
git clone https://git.pwmt.org/pwmt/zathura.git
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: A bug in Gtk+?
Zeeshan Ali wrote: Hello, On Tue, 22 Feb 2005 15:22:50 +0100, Stefan Kost [EMAIL PROTECTED] wrote: Are you sure? Yeah I am sure and thats why i suspect that it may be pointing to a bug in gtk+. Why don't you try it youself? Shouldn't take 15 mins. :) Hi :) When you create main loop with NULL as context parameter, main loop gets shared default context. Before you create your main loop, default context was populated with functions from gtk/gdk. The blocker is gdk_event_prepare (it just locks the global mutex), GLib code call it because the event source is not removed by gtk_main_quit. You may: 1. Create separate context (this looks like the best solution). 2. Use gdk_threads_leave() before your g_main_loop_run() call. Are you really need to use smth like that in your code ? Olexiy ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: A bug in Gtk+? (+ OT suff)
Zeeshan Ali ha scritto lo scorso 23/02/2005 10:31: [...] Yep, in a software of mine that is for ATM machines. You mean to ask why i am using both the GMainLoop and gtk_main* in the same software, right? At one hand i dont want to bring in gtk+ (glib only) into the card-reader interfacing module and OTOH i need nested main loops inside the gui module, for which IMHO i'll need to do some more labour if done using GMainLoop way. You may call it a nessecity of my laziness :) Please, forgive my OT question, but I'm going to start a gtk+ project involving the use of a smart card reader and I'd very happy to know your suggestions about linux supported hardware. TIA ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: A bug in Gtk+?
Zeeshan Ali wrote: You may call it a nessecity of my laziness :) Sure, L:) Laziness is great power and the reason of why there're so many programming tools and libs avalaible. BTW, you can debug deadlocks with gdb. You just need to attach it to running process. 1. Compile program with '-g' (have a libs with debug info around). 2. Run program. Wait when it hang. 3. Run 'gdb program pid' (and be sure that you dont have a pid file in local dir). 4. Do 'bt', etc in gdb. Olexiy ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: A bug in Gtk+? (+ OT suff)
Hello, Please, forgive my OT question, but I'm going to start a gtk+ project involving the use of a smart card reader and I'd very happy to know your suggestions about linux supported hardware. Welcome to the gang! Sorry to dissappoint you but I too am very new to all this. So far i've only interfaced only one card-reader (ICT3K5 by Custom) device and one printer (VKP80 from Custom again). If you need help on these devices or want to know how i am doing the gtk+ part, we can continue our conversation about it in private :) Bye. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: A bug in Gtk+?
On Wed, 2005-02-23 at 14:31 +0500, Zeeshan Ali wrote: Hello, On Wed, 23 Feb 2005 10:12:07 +0200, Olexiy Avramchenko [EMAIL PROTECTED] wrote: When you create main loop with NULL as context parameter, main loop gets shared default context. Before you create your main loop, default context was populated with functions from gtk/gdk. The blocker is gdk_event_prepare (it just locks the global mutex), GLib code call it because the event source is not removed by gtk_main_quit. Thanks. Got it :) You may: 1. Create separate context (this looks like the best solution). 2. Use gdk_threads_leave() before your g_main_loop_run() call. I'll go for #1 i think. Note that if you want to integrate your own callbacks with GTK+ GUI callbacks in the same thread (like repaint events), you need to do 1... you can only have one running contex per thread. And in fact, what gtk_main() looks like is basically: gtk_threads_leave(); g_main_loop_run(); gtk_threads_enter(); So it's very much the normal way things work. Regards, Owen ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: A bug in Gtk+?
Hi Ali, your attachment seems missing. Can you put it on a webserver and post the link? Stefan Hello, In a gtk+ app of mine, i was facing strange dead-locks problems. I was astonished to see that just removing the call to gdk_threads_init, the problems vanished. I am attaching a sample test program that re-produces the same problem. It seems more like a bug in the gtk+ rather than my logic. Please have a look at it and tell me it that's the case so I can file it as a bug. I just dont want to file another 'NOT A BUG' :) ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: A bug in Gtk+?
Hello, Hmm.. I thought that email with attachments goes through the moderation. Anyway, I have uploaded it here: http://www.geocities.com/zeelists/thread-problem.c . Kindly have a look at it. Thanks. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: A bug in Gtk+?
Hello, On Tue, 22 Feb 2005 15:22:50 +0100, Stefan Kost [EMAIL PROTECTED] wrote: Are you sure? Yeah I am sure and thats why i suspect that it may be pointing to a bug in gtk+. Why don't you try it youself? Shouldn't take 15 mins. :) ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
A bug in Gtk+?
Hello, In a gtk+ app of mine, i was facing strange dead-locks problems. I was astonished to see that just removing the call to gdk_threads_init, the problems vanished. I am attaching a sample test program that re-produces the same problem. It seems more like a bug in the gtk+ rather than my logic. Please have a look at it and tell me it that's the case so I can file it as a bug. I just dont want to file another 'NOT A BUG' :) ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
