When you change from Scientific mode to any other mode, and back, it will always revert to Decimal and Fixed.  For Financial and Advanced it always works ie. Dec and Fix are selected, and the correct numeric buttons are visible. For Basic it has Dec and Fix selected, but the numeric buttons available are somehow related to  what you had selected the last time you were in scientific mode.

I think that going into Scientific should always default to Decimal and Fixed. 

I made the following changes to gtk.c, this forces the base to be Decimal, and numeric to be set to Fix when we enter Scientific mode. 
It also calls the grey_buttons() function to grey out all except the Decimal buttons.

I have tested the above fix and it works without any side effects.

static void
reset_mode_display(int toclear)
{

/* If the new mode is BASIC, then we need to dismiss the memory register
 * window (if it's being displayed), as there is no way to interact with it.
 */

    g_object_set(gtk_ui_manager_get_action(X->ui, "/MenuBar/ViewMenu/Trailing"),
                 "sensitive", (v->modetype == SCIENTIFIC), NULL);
    g_object_set(gtk_ui_manager_get_action(X->ui, "/MenuBar/ViewMenu/Memory"),
                 "sensitive", (v->modetype != BASIC), NULL);
    if (v->modetype == BASIC) {
        dismiss_rframe(NULL, NULL, NULL);
    }


+
+/* cosmo bugzilla 485918
+if the new mode is Scientific, we need to set the Base to Decimal
+the Numbers to Fixed, and the accuracy to 9. Need to make sure that
+the correct keys are displayed. We dont want to pick up any
+Scientific settings that we used the last time we were in that mode. Because
+when we last changed out, the Base was reset to Decimal, but nothing else
+was changed.  */
+    if (v->modetype == SCIENTIFIC){
+        /* set fix and dec */
+        set_item(BASEITEM, DEC);
+        grey_buttons(v->base);
+        set_item(NUMITEM, FIX);
+        v->accuracy = 9;
+
+}
+
+

    switch (v->syntax) {
        case npa:
            show_display(v->MPdisp_val);
            break;

        case exprs:
            refresh_display();
            break;
    }

    make_registers();
    do_mode(toclear);
}

Thanks Brian. Appears to work nicely with the new 
Glade'd version of gcalctool as well. Patch applied 
to SVN trunk. Closing as FIXED.

After further testing, I've found that unfortunately this fix isn't
correct. At least with the new Glade'd version. If you go from
one mode to another, reset_mode_display() is called twice. So if you
go from Basic to Scientific then back to Basic, the accuracy is finally
ending up with 9 significant places. 

I don't know why it's calling reset_mode_display() twice, but it needs
to set accuracy correctly when we go back to Basic.

Investigating further...

Here's what should happen when the user presses the Okay button 
on the ChangeMode display. It has the following side-effects:

   * Clears the display
   * Sets the base to decimal
   * Sets the numeric display to fixed
   * Sets the accuracy to nine places after the numeric point.
   * Clears the display of the thousands separator
   * Clears the display of trailing zeroes after the numeric point.

   and dismisses the register window if the new mode is Basic.

Most of this should be done in the reset_mode_values() routine in gtk.c.
There should be a need to add an extra chunk:

    if (v->modetype == SCIENTIFIC){
        /* set fix and dec */
        set_item(BASEITEM, DEC);
        grey_buttons(v->base);
        set_item(NUMITEM, FIX);
        v->accuracy = 9;
    }

in the reset_mode_display() routine.

Still investigating...

Okay, I've pulled Brian's fix out. I had to look at the code to
refresh my memory, but this is the way that it's designed. From the
comment in the mode_radio_cb() routine in gtk.c:

/* If the user has completed a calculation and we are going to a
 * new mode that is "compatible" with this one, then just change
 * modes. Otherwise display a dialog warning the user that the
 * current calculation will be cleared.
 *
 * Incompatible modes are:
 *
 * Scientific -> Basic
 * Scientific -> Advanced
 * Scientific -> Financial
 *
 * (unless we are in Scientific mode with Decimal numeric base and Fixed).
 */

In other words, if you are just going back from Basic to Scientific,
then it does not adjust the accuracy.

So this just leaves fixing the original problem that Robert reported.

Back to the original problem:

  To reproduce:
  1. Open gcalctool
  2. Got to scientific mode
  3. Select binary display mode
  4. Go to basic mode
  5. Go back to scientific mode
  The buttons are set so only binary can be entered but the radio button is on
  "Dec"
  Expected behaviour: the buttons are correct but the radio button should be set
  to "Bin".

For me, when I do back to Scientific mode in step #5, the radio button is
set to DEC, the correct "digits" are greyed out (just the six hex buttons),
it's in FIXED mode.

It doesn't cleverly remember that you were in Bin mode and reset that.
Perhaps is should, but when we (Calum my HCI guy and myself) initially
put this together, this was thought to be the best all round solution.

So Robert, are you still seeing "The buttons are set so only binary can 
be entered"? 

If so, that's a bug, but I'm not seeing that.

Rich, not seeing the problem in the current gcalctool svn head. It does still occur in 5.20.1.

The reset_mode_display() was being called twice because it was getting the toggle event from the radio buttons. I've now fixed this on the head (see the attached patch).

Created attachment 97720 [details] [review]
Stops gcalctool acting on toggle events when radio buttons deactivated

Is this chunk correct?

/*ARGSUSED*/
 void
-inv_cb(GtkToggleButton *button)
+inv_cb(GtkWidget *button)
 {
     v->inverse = !v->inverse;
 }
@@ -2407,6 +2409,9 @@
     int immediate = 0;    /* Set if we can change mode without warning user. */
     int complete = 0;     /* Set if the user has completed a calculation. */
 
+    if (!gtk_check_menu_item_get_active(GTK_CHECK_MENU_ITEM(radio)))
+	return;
+
     if (!v->started) {
 	return;
     }

----

You've got "button" in the function prototype, but you are checking
against "radio".

Ugh! That'll teach me to look at diffs really early in the morning.
That's two different diffs. Sorry for the confusion. Patch looks fine.

So is this bug FIXED now? If so, feel free to close it out Robert.

Thanks.

Well the problem still exists in 2.20 but I have no intention of fixing it (it's not a critical problem). So I'll close it as fixed in 2.22.

Thanks. That seems very reasonable. I've only been backporting critical
fixes to the gnome-2-20 branch, and this isn't one of them.