Re: vertical scale display; button prelighting
Maybe we disagree with the notion of indicating the mouse cursor location by changing the appearance of a widget. For me, that disagreement is independent of however the appearance is changed. OK, so this is just I disagree with the theme. No, its much more than that. I don't think that the toolkit should ever change the state of a widget to PRELIGHT. we already have the enter_notify and leave_notify events if the widget wants to respond to cursor entry and exit. The toolkit should keep its nose out of it. I don't care what the theme does with the state - I don't want the state to exist at all! I don't think adding a function to enforce a certain theme behavior on the user makes any sense. I agree. My use of a function call was mostly a bad attempt at sarcastic wit. Yes, a user setting in ~/.gtkrc would be much better. --p ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: vertical scale display; button prelighting
Paul Davis [EMAIL PROTECTED] writes: Maybe we disagree with the notion of indicating the mouse cursor location by changing the appearance of a widget. For me, that disagreement is independent of however the appearance is changed. OK, so this is just I disagree with the theme. No, its much more than that. I don't think that the toolkit should ever change the state of a widget to PRELIGHT. we already have the enter_notify and leave_notify events if the widget wants to respond to cursor entry and exit. The toolkit should keep its nose out of it. I don't care what the theme does with the state - I don't want the state to exist at all! Consider the case of a child widget of a button, and I think you'll see that toolkit involvement in the propagation of the PRELIGHT state is necessary. The idea of a user setting (a programatic setting is indeed non-sensical), would be that the button widget would obey the setting and not put itself into the PRELIGHT state. If you read gtkbutton.c, you'll see that GtkButton is putting itself into the prelight state in response to enter/exit. Of course, with GTK+-2.0, setting the color of the prelight to the same as the normal color works quite nicely for disabling prelight. Its also quite conceivable to me that someone would want the subtle changing coloration of toolbar icons effect, but not the larger changes of background color, so I'm not sure that a global toggle of prelight is the right way to configure this. Regards, Owen P.S. - the prelight state indicates not the mouse cursor location, but that the location where the mouse is active and responsive to clicking. ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
vertical scale display; button prelighting
1.) set up vertical scale to display digit 0-10,but the scale works backwards. when the slider moved up, the digits decrease; when moved down, it increases. didn't see an option to reverse the order. 2.) how is button prelighting turned off? one suggestion was to use stop_signal_by_name(...entry_notify_event) the signal can be stopped, but so is the button function(clicking button has no affect). thanks in advance, tom begin:vcard n:Lewis;Thomas tel;work:607-721-5887 x-mozilla-html:FALSE org:L-3 Communications;Link Simulation Training adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Principal Software Engineer fn:Thomas Lewis end:vcard
Re: vertical scale display; button prelighting
Thomas J Lewis [EMAIL PROTECTED] writes: 1.) set up vertical scale to display digit 0-10,but the scale works backwards. when the slider moved up, the digits decrease; when moved down, it increases. didn't see an option to reverse the order. There is no option. There is in GTK 2 though. 2.) how is button prelighting turned off? one suggestion was to use stop_signal_by_name(...entry_notify_event) the signal can be stopped, but so is the button function(clicking button has no affect). Just set the prelight color to the same as the normal color. http://pobox.com/~hp/gtk-colors.html Havoc ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: vertical scale display; button prelighting
2.) how is button prelighting turned off? one suggestion was to use stop_signal_by_name(...entry_notify_event) the signal can be stopped, but so is the button function(clicking button has no affect). Just set the prelight color to the same as the normal color. if its a toggle button, there are *2* normal colors. what then? --p gtk_init (argc, argv); gtk_allow_prelight (false); ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: vertical scale display; button prelighting
Paul Davis [EMAIL PROTECTED] writes: Just set the prelight color to the same as the normal color. if its a toggle button, there are *2* normal colors. what then? I'm sure you could hack something, e.g. change prelight color when toggled. (I see the issue here now, Thomas sent me mail earlier and I was thinking check button and didn't get it.) --p gtk_init (argc, argv); gtk_allow_prelight (false); I'd need some convincing on why this is useful. I do see that various people are trying to do it, but is it just I don't like the theme, let's hardcode stuff or is it for a reason. i.e. if you had the option to just switch to a win32 lookalike theme that didn't have prelight, would you still want gtk_allow_prelight()? Making it possible to include a nonstandard theme as part of your app binary might help a good bit with this issue. Another option is to make prelight a user setting that all themes would then honor (because GTK wouldn't pass them GTK_STATE_PRELIGHT). Havoc ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
