Re: GTK signals question.
Do you have an other thread? May be concurrency problems? On Wed, 2014-03-05 at 01:43 -0500, Chris Moller wrote: Okay, I'm out of ideas... I'm writing an app, that among a lot of other stuff, has three mutually interacting spinbuttuns, i.e., if I increment spinbutton A, its callback then updates values in B and C. B and then would try to update A, and C, etc., resulting in a bottomless recursion. So, what I need to do is, while I'm in A's callback, block the B and C callbacks; while in in B, block A and C and so on. Every combination of g_signal_handler_block(), g_signal_handlers_block_matched(), etc, I've tried just results in seg faults--all that stuff works fine outside the callbacks, but the moment I stick them in a callback, death happens. Any suggestions? Thanks. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK signals question.
On Tue, Mar 4, 2014 at 10:43 PM, Chris Moller mol...@mollerware.com wrote: Okay, I'm out of ideas... I'm writing an app, that among a lot of other stuff, has three mutually interacting spinbuttuns, i.e., if I increment spinbutton A, its callback then updates values in B and C. B and then would try to update A, and C, etc., resulting in a bottomless recursion. So, what I need to do is, while I'm in A's callback, block the B and C callbacks; while in in B, block A and C and so on. Every combination of g_signal_handler_block(), g_signal_handlers_block_matched(), etc, I've tried just results in seg faults--all that stuff works fine outside the callbacks, but the moment I stick them in a callback, death happens. Any suggestions? I'm surprised g_signal_handler_block() or g_signal_stop_emission() didn't work. This was actually a concern when we added the GBinding code to GObject - making sure that these kinds of signal loops were well documented and that you have to prevent against them yourself using one of these methods. My first suggestion would be to post a minimal test case demonstrating how this failed for you - might have stepped on a bug, but either way it'd make it easier to see why it failed for you. My second suggestion is along the same line as Tristan's suggestion: create a GObject that holds the value as a property (the model), and bind the property to the views instead of binding the views' values together. (I think this object would be more boilerplate than code, woe is our lives as Gtk+ C developers.) You can use the GBinding code with an appropriate GBindingTransformFunc applied to scale the value correctly for each view, which cuts down the amount of code this approach would take. If these controls are in the same place in the UI, you could bake it all (the three spin buttons, any labels, and the one true value property) into one composite GtkWidget and save yourself a bit of boilerplate too. -A. Walton Thanks. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK signals question.
Dne 05.03.2014 (sre) ob 18:38 +1100 je Chris Angelico napisal(a):
On Wed, Mar 5, 2014 at 6:29 PM, Tristan Van Berkom
tris...@upstairslabs.com wrote:
Interesting, if I were you I would try to share the same adjustment
between all of your views.
I.e. I would keep the adjustment in the finest grained unit of each
unit you want to display, and have your spin buttons format the value
differently depending on what they are used for (or perhaps use GtkScale
if that makes sense in your UI).
Now *that* is an elegant solution, if it can be done!
Sure it can;) In the code below, this sharing is implemented between
spin buttons in first row. Beware though that now both widgets increment
for the same angle - increment in fixed to 0.1 radians.
If you need more flexibility, you can use 2 adjustments and bind their
value property through simple transformation. This method is
implemented in second row. Now incrementing can be done independently in
both widgets (first widgets increments in 0.1 radians, second in 1
degree steps).
--8-
#include gtk/gtk.h
static gboolean
cb_output (GtkSpinButton *spin)
{
GtkAdjustment *adj = gtk_spin_button_get_adjustment (spin);
double val = gtk_adjustment_get_value (adj);
gchar *text = g_strdup_printf (%d, (gint)(val * 180 / G_PI + .5));
gtk_entry_set_text (GTK_ENTRY (spin), text);
g_free (text);
return TRUE;
}
static gint
cb_input (GtkSpinButton *spin,
gdouble *value)
{
gchar const *text = gtk_entry_get_text (GTK_ENTRY (spin));
double val = g_strtod (text, NULL);
*value = val * G_PI / 180;
return TRUE;
}
static gboolean
rad_to_deg (GBinding *bind G_GNUC_UNUSED,
const GValue *from,
GValue *to,
gpointer data G_GNUC_UNUSED)
{
double val = g_value_get_double (from);
g_value_set_double (to, val * 180 / G_PI);
return TRUE;
}
static gboolean
deg_to_rad (GBinding *bind G_GNUC_UNUSED,
const GValue *from,
GValue *to,
gpointer data G_GNUC_UNUSED)
{
double val = g_value_get_double (from);
g_value_set_double (to, val / 180 * G_PI);
return TRUE;
}
int
main (intargc,
char **argv)
{
GtkWidget *window, *grid, *s1, *s2, *s3, *s4;
GtkAdjustment *adj, *adj1, *adj2;
gtk_init (argc, argv);
window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
g_signal_connect (window, destroy, gtk_main_quit, NULL);
grid = gtk_grid_new ();
gtk_container_add (GTK_CONTAINER (window), grid);
/* Use single adjustment: both spin buttons use radians as the data
* storage, second one converts radians to degrees on input/output */
adj = gtk_adjustment_new (1, 0, 2 * G_PI, 0.1, 0.5, 0);
s1 = gtk_spin_button_new (adj, 0.5, 2);
g_object_set (s1, expand, TRUE, NULL);
gtk_grid_attach (GTK_GRID (grid), s1, 0, 0, 1, 1);
s2 = gtk_spin_button_new (adj, 0.5, 2);
g_object_set (s2, expand, TRUE, NULL);
g_signal_connect (s2, output, G_CALLBACK (cb_output), NULL);
g_signal_connect (s2, input, G_CALLBACK (cb_input), NULL);
gtk_grid_attach (GTK_GRID (grid), s2, 1, 0, 1, 1);
/* Use 2 adjustments: one in radians and one in degrees. GBinding
* keeps values of those adjustments in sync */
adj1 = gtk_adjustment_new (3.14, 0, 2 * G_PI, 0.1, 0.5, 0);
s3 = gtk_spin_button_new (adj1, 0.5, 2);
g_object_set (s3, expand, TRUE, NULL);
gtk_grid_attach (GTK_GRID (grid), s3, 0, 1, 1, 1);
adj2 = gtk_adjustment_new (100, 0, 360, 1, 5, 0);
s4 = gtk_spin_button_new (adj2, 0.5, 0);
g_object_set (s4, expand, TRUE, NULL);
gtk_grid_attach (GTK_GRID (grid), s4, 1, 1, 1, 1);
g_object_bind_property_full (adj1, value, adj2, value,
G_BINDING_BIDIRECTIONAL |
G_BINDING_SYNC_CREATE,
rad_to_deg, deg_to_rad,
NULL, NULL);
gtk_widget_show_all (window);
gtk_main ();
return 0;
}
--8---
Cheers,
Tadej
--
Tadej Borovšak
tadej.borov...@gmail.com
tadeb...@gmail.com
blog.borovsak.si
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK signals question.
I was actually writing that testcase when I found a correlation: I'm using gcc and my callbacks were nested functions. Pull the callbacks out and make them normal, top-level, functions, and it all works even without no blocking of any kind. So, if this is a bug at all, I suppose it could be a compiler bug. One way or the other, thanks for all the responses. -cm On 03/05/14 04:21, A. Walton wrote: On Tue, Mar 4, 2014 at 10:43 PM, Chris Moller mol...@mollerware.com mailto:mol...@mollerware.com wrote: Okay, I'm out of ideas... I'm writing an app, that among a lot of other stuff, has three mutually interacting spinbuttuns, i.e., if I increment spinbutton A, its callback then updates values in B and C. B and then would try to update A, and C, etc., resulting in a bottomless recursion. So, what I need to do is, while I'm in A's callback, block the B and C callbacks; while in in B, block A and C and so on. Every combination of g_signal_handler_block(), g_signal_handlers_block_matched(), etc, I've tried just results in seg faults--all that stuff works fine outside the callbacks, but the moment I stick them in a callback, death happens. Any suggestions? I'm surprised g_signal_handler_block() or g_signal_stop_emission() didn't work. This was actually a concern when we added the GBinding code to GObject - making sure that these kinds of signal loops were well documented and that you have to prevent against them yourself using one of these methods. My first suggestion would be to post a minimal test case demonstrating how this failed for you - might have stepped on a bug, but either way it'd make it easier to see why it failed for you. My second suggestion is along the same line as Tristan's suggestion: create a GObject that holds the value as a property (the model), and bind the property to the views instead of binding the views' values together. (I think this object would be more boilerplate than code, woe is our lives as Gtk+ C developers.) You can use the GBinding code with an appropriate GBindingTransformFunc applied to scale the value correctly for each view, which cuts down the amount of code this approach would take. If these controls are in the same place in the UI, you could bake it all (the three spin buttons, any labels, and the one true value property) into one composite GtkWidget and save yourself a bit of boilerplate too. -A. Walton Thanks. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org mailto:gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK signals question.
On Thu, Mar 6, 2014 at 1:44 AM, Chris Moller mol...@mollerware.com wrote: I was actually writing that testcase when I found a correlation: I'm using gcc and my callbacks were nested functions. Pull the callbacks out and make them normal, top-level, functions, and it all works even without no blocking of any kind. So, if this is a bug at all, I suppose it could be a compiler bug. This is another reason to write GTK application code in Python or Pike rather than C :) First-class functions make life ever so much easier. ChrisA ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK signals question.
On Wed, 05 Mar 2014 09:44:48 -0500 Chris Moller mol...@mollerware.com wrote: I was actually writing that testcase when I found a correlation: I'm using gcc and my callbacks were nested functions. Pull the callbacks out and make them normal, top-level, functions, and it all works even without no blocking of any kind. So, if this is a bug at all, I suppose it could be a compiler bug. Your question contained references to GTK+'s C interface. If that means that you are using C or C++ for your program, those languages do not have a syntax for nested functions, so what you say does not really make sense. If you are simulating them in C++ using static methods of a nested struct, in C++98 you have undefined behaviour if you try to use them as a callback, because static member functions of classes with local scope have no linkage (this follows because §3.5/5 of the standard provides that a member function of class scope has external linkage if the name of the class has external linkage, which it doesn't in the case of local nested structs, and §3.5/8 provides that Names not covered by these rules have no linkage). So it is most likely a misunderstanding on your part rather than a compiler bug, but you would need to post your code to be sure. Chris ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK signals question.
Le 05/03/2014 18:07, Chris Vine a écrit : On Wed, 05 Mar 2014 09:44:48 -0500 Chris Moller mol...@mollerware.com wrote: I was actually writing that testcase when I found a correlation: I'm using gcc and my callbacks were nested functions. Pull the callbacks out and make them normal, top-level, functions, and it all works even without no blocking of any kind. So, if this is a bug at all, I suppose it could be a compiler bug. Your question contained references to GTK+'s C interface. If that means that you are using C or C++ for your program, those languages do not have a syntax for nested functions, so what you say does not really make sense. […] GCC does, to some extent, accept nested functions in C as an extension. But of course, they are not real closures so even though they have access to the parent scope, the symbols from there will not be valid after the parent returned. http://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html Regards, Colomban ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK signals question.
On 03/05/14 12:07, Chris Vine wrote: On Wed, 05 Mar 2014 09:44:48 -0500 Chris Moller mol...@mollerware.com wrote: I was actually writing that testcase when I found a correlation: I'm using gcc and my callbacks were nested functions. Pull the callbacks out and make them normal, top-level, functions, and it all works even without no blocking of any kind. So, if this is a bug at all, I suppose it could be a compiler bug. Your question contained references to GTK+'s C interface. If that means that you are using C or C++ for your program, those languages do not have a syntax for nested functions, so what you say does not really make sense. If you are simulating them in C++ using static methods of a nested struct, in C++98 you have undefined behaviour if you try to use them as a callback, because static member functions of classes with local scope have no linkage (this follows because §3.5/5 of the standard provides that a member function of class scope has external linkage if the name of the class has external linkage, which it doesn't in the case of local nested structs, and §3.5/8 provides that Names not covered by these rules have no linkage). So it is most likely a misunderstanding on your part rather than a compiler bug, but you would need to post your code to be sure. gcc supports nested functions as an extension to standard C. I tend to use them a lot because they operate within the stack frame of the enclosing function, thereby minimising the amount of information you have to pass. This is especially valuable in GTK callbacks where you can only pass one pointer/int. Chris ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK signals question.
Le 05/03/2014 19:43, Chris Moller a écrit : [...] gcc supports nested functions as an extension to standard C. I tend to use them a lot because they operate within the stack frame of the enclosing function, thereby minimising the amount of information you have to pass. This is especially valuable in GTK callbacks where you can only pass one pointer/int. Well, yes, but beware: the parent function's stack is not valid if the parent function exited. So for asynchronous callbacks, you can only use it in the function managing the loop (e.g. main). Otherwise they will be called after the parent function exited, and so any access you do on its stack will only lead to a crash in the best case. In short, they are nested functions, but *not* closures. Regards, Colomban ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK signals question.
On Thu, Mar 6, 2014 at 5:43 AM, Chris Moller mol...@mollerware.com wrote: gcc supports nested functions as an extension to standard C. I tend to use them a lot because they operate within the stack frame of the enclosing function, thereby minimising the amount of information you have to pass. This is especially valuable in GTK callbacks where you can only pass one pointer/int. That's a nice idea as long as you don't let the calling function return. As far as I know, gcc nested functions don't in any way hold onto the outer state, so there'll be a pile of segfaults waiting for you if the outer function has returned - like returning a pointer to an automatic variable. Is there a reason you're trying to write high-level code in C? Give Python or Pike a shot - both have GTK bindings and are way WAY easier to write code in. Believe me, I've written plenty of C code (including GUI handling), and life is just so much better when memory management isn't part of your daily keyboarding regimen. ChrisA PS. Has anyone else noticed that this thread is more than half by people named Chris? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK signals question.
On Wed, 05 Mar 2014 13:43:29 -0500 Chris Moller mol...@mollerware.com wrote: On 03/05/14 12:07, Chris Vine wrote: On Wed, 05 Mar 2014 09:44:48 -0500 Chris Moller mol...@mollerware.com wrote: I was actually writing that testcase when I found a correlation: I'm using gcc and my callbacks were nested functions. Pull the callbacks out and make them normal, top-level, functions, and it all works even without no blocking of any kind. So, if this is a bug at all, I suppose it could be a compiler bug. Your question contained references to GTK+'s C interface. If that means that you are using C or C++ for your program, those languages do not have a syntax for nested functions, so what you say does not really make sense. If you are simulating them in C++ using static methods of a nested struct, in C++98 you have undefined behaviour if you try to use them as a callback, because static member functions of classes with local scope have no linkage (this follows because §3.5/5 of the standard provides that a member function of class scope has external linkage if the name of the class has external linkage, which it doesn't in the case of local nested structs, and §3.5/8 provides that Names not covered by these rules have no linkage). So it is most likely a misunderstanding on your part rather than a compiler bug, but you would need to post your code to be sure. gcc supports nested functions as an extension to standard C. I tend to use them a lot because they operate within the stack frame of the enclosing function, thereby minimising the amount of information you have to pass. This is especially valuable in GTK callbacks where you can only pass one pointer/int. Having read Columban's posting, I see that the gcc documentation on this extension explicitly rules out the use of nested functions as pseudo-closures: If you try to call the nested function through its address after the containing function exits, all hell breaks loose. If you try to call it after a containing scope level exits, and if it refers to some of the variables that are no longer in scope, you may be lucky, but it's not wise to take the risk. If, however, the nested function does not refer to anything that has gone out of scope, you should be safe. This is equivalent to the position with nested structs: they have no linkage. Presumably that was your problem in this case. Chris ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK signals question.
On 03/05/14 13:52, Chris Angelico wrote: On Thu, Mar 6, 2014 at 5:43 AM, Chris Moller mol...@mollerware.com wrote: gcc supports nested functions as an extension to standard C. I tend to use them a lot because they operate within the stack frame of the enclosing function, thereby minimising the amount of information you have to pass. This is especially valuable in GTK callbacks where you can only pass one pointer/int. That's a nice idea as long as you don't let the calling function return. As far as I know, gcc nested functions don't in any way hold onto the outer state, so there'll be a pile of segfaults waiting for you if the outer function has returned - like returning a pointer to an automatic variable. I'm exploring a bit the circumstances when to, or not to, use nested fcns. What it's beginning to look like is that they'll work fine in top-level fcns, and, apparently, GTK modal dialogues, but everything else is open to question. Is there a reason you're trying to write high-level code in C? Habit, mostly. I've been coding in C since the early 80s and I can do it in my sleep. Python's okay, but I tend to think of it more as a scripting language rather than something I want to write a 50k-line application in. (Actually, the app I'm writing now uses Python as it's scripting language...) I'd never heard of Pike but, looking it up, the interpreted bit makes me wonder about performance. Give Python or Pike a shot - both have GTK bindings and are way WAY easier to write code in. Believe me, I've written plenty of C code (including GUI handling), and life is just so much better when memory management isn't part of your daily keyboarding regimen. ChrisA PS. Has anyone else noticed that this thread is more than half by people named Chris? Years ago, I worked in a lab where about a third of the people were named Ron. Confusion reigned... ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK signals question.
On Thu, Mar 6, 2014 at 6:27 AM, Chris Moller mol...@mollerware.com wrote: On 03/05/14 13:52, Chris Angelico wrote: Is there a reason you're trying to write high-level code in C? Habit, mostly. I've been coding in C since the early 80s and I can do it in my sleep. Python's okay, but I tend to think of it more as a scripting language rather than something I want to write a 50k-line application in. (Actually, the app I'm writing now uses Python as it's scripting language...) I'd never heard of Pike but, looking it up, the interpreted bit makes me wonder about performance. You're writing a GUI program, which normally means it'll be waiting for the user most of the time. There's a lot you can do without even nudging a CPU monitor. Interpreted languages were fairly slow a few decades ago, but these days, the difference isn't that great - and computers are so much faster, anyway. It's usually a good tradeoff to save development time by spending a smidge more on an interactive action. I mean, let's just suppose that C code is a hundred times faster than Python (which it usually isn't, but let's pretend, as Alice said). In most cases, that'll mean Python will take 10ms and C would take 0.1ms to respond to a user action - that is to say, the difference between immeasurably fast and immeasurably fast. And in reality, the difference isn't nearly that great; if it's even ten to one for anything other than heavy numerical computation, I'd be amazed. And Pike's faster than Python overall, reducing the difference further. Happy to talk to you on- or off- list about Pike or Python. They're both excellent languages. PS. Has anyone else noticed that this thread is more than half by people named Chris? Years ago, I worked in a lab where about a third of the people were named Ron. Confusion reigned... Heh, it's weird how that goes. I have a brother named Michael who's a rail enthusiast, and one time he was car-pooling his way to some rail event or something, and all four occupants of the car had the same name. One was Mike, one was Mick, I can't remember who the other was, and my brother goes by Michael, so it wasn't confusing, but it was amusing. I find that people named Chris are often geeks. We can have long sub-threads on python-list between Chrises, and every list I join seems to have at least a couple more. Rather neat, actually. ChrisA ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK signals question.
On Wed, 2014-03-05 at 18:01 +1100, Chris Angelico wrote: On Wed, Mar 5, 2014 at 5:43 PM, Chris Moller mol...@mollerware.com wrote: I'm writing an app, that among a lot of other stuff, has three mutually interacting spinbuttuns, i.e., if I increment spinbutton A, its callback then updates values in B and C. B and then would try to update A, and C, etc., resulting in a bottomless recursion. So, what I need to do is, while I'm in A's callback, block the B and C callbacks; while in in B, block A and C and so on. Are you simply setting the three to the same value? If so, just check first to see if it's already that value, and if it is, don't set it. That's a technique that's worked for me since my earliest GUI programming days on VX-REXX... great system, that, pity it's bound to the obscure and forgotten platform of OS/2! :) In case this is of any help, the GtkAdjustment::value-changed signal does this check for this exact reason (to avoid some unneeded feedback when the value has not actually changed). Cheers, -Tristan ChrisA ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK signals question.
On Wed, Mar 5, 2014 at 6:20 PM, Chris Moller mol...@mollerware.com wrote: No, they're not the same value. They're all for setting an angle, in radians, pi-radians, and degrees, and I want the user to be able to set the angle in any unit and have the equivalent angle in the other units show up in the other spinbuttons. Ah, okay. Same consideration does apply, though - if you query first and then set, you avoid spurious signal delivery much more conveniently than fiddling with signal blocking. In the specific case cited, Tristan's solution is likely what you want, but for generalities, the query-before-set model is always there as a fall-back. ChrisA ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK signals question.
On Wed, 2014-03-05 at 02:20 -0500, Chris Moller wrote: On 03/05/14 02:01, Chris Angelico wrote: On Wed, Mar 5, 2014 at 5:43 PM, Chris Moller mol...@mollerware.com wrote: I'm writing an app, that among a lot of other stuff, has three mutually interacting spinbuttuns, i.e., if I increment spinbutton A, its callback then updates values in B and C. B and then would try to update A, and C, etc., resulting in a bottomless recursion. So, what I need to do is, while I'm in A's callback, block the B and C callbacks; while in in B, block A and C and so on. Are you simply setting the three to the same value? If so, just check first to see if it's already that value, and if it is, don't set it. That's a technique that's worked for me since my earliest GUI programming days on VX-REXX... great system, that, pity it's bound to the obscure and forgotten platform of OS/2! :) No, they're not the same value. They're all for setting an angle, in radians, pi-radians, and degrees, and I want the user to be able to set the angle in any unit and have the equivalent angle in the other units show up in the other spinbuttons. Interesting, if I were you I would try to share the same adjustment between all of your views. I.e. I would keep the adjustment in the finest grained unit of each unit you want to display, and have your spin buttons format the value differently depending on what they are used for (or perhaps use GtkScale if that makes sense in your UI). The idea of multiple GtkAdjustments holding separate values when you really only want a single value that is displayed differently by different widgets - is a bit maddening. Note that this might prove challenging with the way GtkAdjustment is designed, I was just speculating that this approach of multiple adjustments is not ideal... ideally these views should share the same value. Cheers, -Tristan ChrisA ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK signals question.
On Wed, Mar 5, 2014 at 6:29 PM, Tristan Van Berkom tris...@upstairslabs.com wrote: Interesting, if I were you I would try to share the same adjustment between all of your views. I.e. I would keep the adjustment in the finest grained unit of each unit you want to display, and have your spin buttons format the value differently depending on what they are used for (or perhaps use GtkScale if that makes sense in your UI). Now *that* is an elegant solution, if it can be done! ChrisA ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
