Re: Regarding example code (was Why is ChangeValue reentrant)
Michael Cronenworth wrote: > $ rpm -q gtk2 > gtk2-2.16.5-1.fc11.x86_64 Yup, that's it. 2.16 is the latest stable GTK+ available (2.18 isn't quite released yet) ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Regarding example code (was Why is ChangeValue reentrant)
Boggess Rod on 08/13/2009 10:39 AM wrote: > It's either already be resolved in a newer release, or it > exists only as an HPUX implementation issue. I may contact HP, but it > doesn't belong on the Gtk bug list. > HP provides an update. I'd get off version 2.6 and onto 2.16 ASAP. Tell your superiors there's security fixes and less customer support calls if you update. ;) http://hpux.connect.org.uk/hppd/hpux/Gtk/Development/gtk+2-2.16.4/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
RE: Regarding example code (was Why is ChangeValue reentrant)
LOL. Yes, of course there is. In the real-world code, it only pops up if you've changed some text in one of the entry boxes without saving. But that wasn't germane to the bug, so I stripped it out. (I never really imagined what the bug code would look like to an end user -- thank you for that image, I needed a laugh.) This was the bare bones to demonstrate the problem. If you can click either button on the popup dialog, and the dialog goes away and stays away, that's what I would expect. So, thank you, that answers my question. It's either already be resolved in a newer release, or it exists only as an HPUX implementation issue. I may contact HP, but it doesn't belong on the Gtk bug list. > -Original Message- > From: Michael Torrie [mailto:torr...@gmail.com] > Sent: Thursday, August 13, 2009 11:32 AM > To: Boggess Rod > Cc: Gtk app list > Subject: Re: Regarding example code (was Why is ChangeValue reentrant) > > Boggess Rod wrote: > >> In cases like this, you probably have to hack around the > problem/bug. > >> IE solve your use case in a different way. > > > > Already have. Instead of using the response from gtk_dialog_run, I > > gtk_widget_show_all the dialog window and return TRUE from the > > change-value callback of hscale. Then I decide on the > action within > > the clicked callback of the Ok and Cancel buttons. It > means manually > > adding the buttons, but that's not a big deal. > > > > Thanks. > > The code in bug.c runs fine for me. OK allows the change, > Cancel prevents the change. I'm on Fedora 11 with GTK 2.18 I think. > > That said, if this example is in anyway how your program > expects to work, I highly recommend you take a different > approach to the UI. It's a very unnatural way of working > with a GUI element. Personally if I had to click OK or > Cancel after each single movement of a slider I'd be driven > crazy (you mentioned multiple sliders too!). If I needed to > change the value from 1 to 20, for example, I have to click > OK 20 times! >I didn't learn much in my UI class, but I'm pretty sure > there has to be a better way. > > Now I don't know what you are trying to accomplish, but if I > were writing a program that needed to verify that a user > really wanted to change a value, I'd do it *after* the value > had been changed. On other words, I'd let the user change > the sliders to his hearts content and then, depending on the > scenario, either have a "revert" button that undid everything > and canceled the operation, or have an "apply" button that > would make the changes active (either for the slider itself > or for the dialog box as a whole). If necessary I'd have the > UI highlight which UI elements had been changed (in case the > user accidentally changed a slider or something). > > In other words, there has to be a better way! > ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Regarding example code (was Why is ChangeValue reentrant)
Michael Torrie on 08/13/2009 10:31 AM wrote: > I'm on Fedora 11 with GTK 2.18 I think. $ rpm -q gtk2 gtk2-2.16.5-1.fc11.x86_64 ;) ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Regarding example code (was Why is ChangeValue reentrant)
Boggess Rod wrote: >> In cases like this, you probably have to hack around the problem/bug. >> IE solve your use case in a different way. > > Already have. Instead of using the response from gtk_dialog_run, I > gtk_widget_show_all the dialog window and return TRUE from the > change-value callback of hscale. Then I decide on the action within the > clicked callback of the Ok and Cancel buttons. It means manually adding > the buttons, but that's not a big deal. > > Thanks. The code in bug.c runs fine for me. OK allows the change, Cancel prevents the change. I'm on Fedora 11 with GTK 2.18 I think. That said, if this example is in anyway how your program expects to work, I highly recommend you take a different approach to the UI. It's a very unnatural way of working with a GUI element. Personally if I had to click OK or Cancel after each single movement of a slider I'd be driven crazy (you mentioned multiple sliders too!). If I needed to change the value from 1 to 20, for example, I have to click OK 20 times! I didn't learn much in my UI class, but I'm pretty sure there has to be a better way. Now I don't know what you are trying to accomplish, but if I were writing a program that needed to verify that a user really wanted to change a value, I'd do it *after* the value had been changed. On other words, I'd let the user change the sliders to his hearts content and then, depending on the scenario, either have a "revert" button that undid everything and canceled the operation, or have an "apply" button that would make the changes active (either for the slider itself or for the dialog box as a whole). If necessary I'd have the UI highlight which UI elements had been changed (in case the user accidentally changed a slider or something). In other words, there has to be a better way! ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Regarding example code (was Why is ChangeValue reentrant)
Boggess Rod wrote: > It should be attached to one of the messages I posted on this thread. > If you're interested, here's another copy of it. Will take a brief look at it. > I have NOT tested this on a newer version of Gtk (can't). I'm hoping > someone else out there will be kind enough to test this on newer > software and alternate hardware. I'm just a contractor working for a > company that resells process automation hardware with our software on > it. The computer doesn't belong to us, so even if my contractor was ok > with me spending time working on this more, it's not their computer, > either. Too much red-tape to upgrade from Gtk 2.6. Gotcha. If it is a bug in GTK 2.6 on HPUX, then there's not chance of fixing it either way, since you can't change GTK on the client machine. In cases like this, you probably have to hack around the problem/bug. IE solve your use case in a different way. > If you're kind enough to run this, let me know what you find out, would > you? I'd appreciate it. Will do ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Regarding example code (was Why is ChangeValue reentrant)
Boggess Rod wrote: > Sorry, I did post a small example that demonstrates the unusual (buggy?) > behavior in a follow-up post. The more I dug into it, the weirder it > became, and the more convinced I am that it's a bug in Gtk. Or at > least, a bug in the HPUX implementation of it. I'm waiting about a week > to see if I hear back from anyone on the list that they can reproduce > the problem in their environment. Did you post this code somewhere? Also did you try a newer version of GTK just as a sanity check? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
RE: Regarding example code (was Why is ChangeValue reentrant)
Sorry, I did post a small example that demonstrates the unusual (buggy?) behavior in a follow-up post. The more I dug into it, the weirder it became, and the more convinced I am that it's a bug in Gtk. Or at least, a bug in the HPUX implementation of it. I'm waiting about a week to see if I hear back from anyone on the list that they can reproduce the problem in their environment. In the example code, it came down to adding a gtk_widget_set_size_request. If that line is in the code, then when you gtk_dialog_run, it immediately re-executes the change-value signal callback. Comment it out, recompile, and it works as you'd expect. I continued to play with it a bit. I can make other calls besides gtk_widget_set_size_request that will also make change-value reentrant, but I couldn't see any clear pattern. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
