Created attachment 96995 [details]
Screenshot of gcalctool in advanced mode with registers inside window

Created attachment 96996 [details]
Screenshot of gcalctool in scientific mode with registers inside window

Created attachment 96998 [details] [review]
Patch moving register window into main window

Note I am not sure about the use of v->rstate and R_REGS - these should be checked by a gcalctool expert.

Created attachment 97001 [details]
Screenshot in Scientific mode with accuracy at 9 places and memory registers containing large and small numbers.

Hi Robert,

Thanks for your work on this, but I think I'm going to close it as
WILLNOTFIX. 

As you can see from the last screen shot, if you increase the number 
of significant places and have both large and small values stored 
in the memory registers, the size of the gcalctool window gets
very large. It also looks misshapen. Note that with the latest version
of gcalctool, it's possible to have upto 99 significant places and for
numbers to be displayed with upto 200 digits. If this is the case, then
gcalctool won't fix on the screen. (There's a potential bug there, even
with a separate memory window -- I'm going to have to check that out).

And the simple clincher for me is that if you loose the Memory registers, 
you can find them again by giving focus to the gcalctool window and 
entering Alt-F6.

Calum, can I get your thoughts on this patch please?

Thanks.

If I was going to do something like this, I'd maybe suggest going down the more standard dockable toolbar route, so that you could either dock the registers window under the menubar (with a layout similar to that proposed here), or undock it so that it floats it the way it does now.  That way users can use whichever layout they prefer.  Although I'm not sure about the future status of dockable toolbars... at one point they were threatening to remove them.

First, though, it's probably worth exploring the assertion that the registers window is 'easy to lose'-- in what way is this true? You shouldn't be able to lose it behind other windows, as it always pops to the front when you focus the calculator, so all you need to do is keep them side-by-side and it should always be visible.  In what circumstances might you lose it?

Hi guys,

The normal way I use the calculator is much like I use a physical calculator in that I move it around my desktop frequently. One case where the register window is lost is if you move the calculator window between workspaces - the register window does not follow. Or moving the calculator between monitors causes me visually to do a "where has the register window gone".

It feels to me like the register values are only useful in context of the main window and thus should be attached to it. Having to keep moving the register window each time the calculator moves is tiring. I can't think of a use case where it is useful having it separate.

The width problem is certainly an issue, I found the current location to be the best of a bad selection (tried it on the left/right first, this caused the window to be too tall in advanced mode).

This report is very much an "itch scratching" in that it was annoying me last night. So I made the patch and did a blind test on my flatmate to see which one he preferred (he also preferred it attached). I also got the itch to convert all that gtk code to a .glade file... :)

Hi Robert,

> One case where the register window is lost is if you move the calculator 
> window between workspaces - the register window does not follow.

Yup. I see that problem too. One quick workaround is to go to the View
menu and toggle the "Show Memory registers" menu item twice. In fact, it's
even easier than that. Just type Control-m twice.

I also noticed that if you start gcalctool with the memory register 
displayed, the check box beside the memory item is not checked. I'll 
look to fix that sub-problem today.

> Or moving the calculator between monitors causes me
> visually to do a "where has the register window gone".

I'll have to take your word for that. ;-) Does typing Control-m twice
fix that too?

> I also got the itch to convert all that gtk code to a .glade file... :)

Now that is a patch I'd gratefully accept (assuming it worked well) 8-).
 
It's been on my to do list for years. And if done, it would certainly 
make it easier for others to contribute.

(In reply to comment #8)
> > Or moving the calculator between monitors causes me
> > visually to do a "where has the register window gone".
> 
> I'll have to take your word for that. ;-) Does typing Control-m twice
> fix that too?

For whatever it's worth, I have a tri-head system with the center monitor being a wide-screen display, so I sometimes suffer from the "where has <whatever> gone?" problem. :-)  Typing Control-m twice does indeed cause the register window to appear right next to the main gcalctool window regardless of the head and workspace.

Rich, I'd support you closing this now:

The ctrl-m workaround always returns the window but feels clunky (Doesn't feel like it fits with the Gnome "just works" idea). However I'd agree that the window being too wide is a bigger problem and there is no clever UI solution I can think of that works around this (aside from truncating the display).

Well, maybe there is something we can do. Joanie pointed out
that OOo Writer and its Navigator windows are "locked" together
and when you move oowriter to a new virtual workspace and/or desktop, 
the other window magically follows. I've just noticed the gnome-termal
and its Edit->Current Profile... do the same.

There must be some magic window manager hint we can provide to the
Memory Register window (and gcalctool's other sub-windows) to make this
happen.

I'll investigate further on Monday.

Created attachment 97256 [details] [review]
Patch to make the memory register window "follow" the main gcalctool window.

Thanks to Christian Persch, for a pointer to the approriate Gtk
routine to use.

The attached patch I believe does what you want. Could you confirm
please Robert?

If it is a winner, I'll knock up a patch that does this for all
the other windows that gcalctool can potentially display.

I suspect there is an option that can be set on all these
dialogs that's the equivalent for Glade created dialogs...

Apparently all the other dialog windows that gcalctool can create are 
already using gtk_window_set_transient_for(), so I've just committed 
this patch to SVN trunk and am closing the bug as FIXED.

If you notice any problems, please comment and I'll investigate further.

Thanks.

Rich this works really well for the two windows in question.  I did find a case, however, where things don't follow.  The trick seems to be combining two things:  

1. Having more than two windows open, and
2. Choosing "move to workspace <whatever>" from a window OTHER than
   the main gcalctool window.

Examples:  Launch gcalctool, show the registers, and bring up the Insert ASCII Value window.

1. Choose move to workspace <whatever> in the main window.
   Results:  All three windows move as expected.

2. Choose move to workspace <whatever> in the Insert ASCII Value 
   window. 
   Results:  The registers window gets left behind.

3. Choose move to workspace <whatever> in the registers window.
   Results:  The Insert ASCII Value window gets left behind.

I'm not sure how much this matters as one can do the moving from the main gcalctool window....

Thanks for testing.

> I'm not sure how much this matters as one can do the moving from the main
> gcalctool window...

I'm also not sure how much we can do about this. Try this.

1. Startup gnome-terminal
2. Display Edit->Profiles... and Edit->Current Profile...
3. Move main gnome-terminal window to another workspace
   (the other two windows follow).
4. Go to that other workspace and move the Profiles... window
   back to the first workspace. (the Profiles... window goes
   and so does the main gnome-terminal window, but the "Current
   Profile" window does not).

Seems to be a generic Gtk+ transcient window limitation.

True.... Okay, never mind. :-)

I believe the register would fit nicely in a totem/pychess like sidepanel.

This is something that we could definitely consider 
in the future once the whole gcalctool GUI has been 
Glade'd (see bug #485919).

One step at a time though. ;-)

Thanks for the suggestion.