gcalctool 6.6.2 on Fedora 18 has this problem too.

It should either remember it's position or the executable should accept a geometry/positioning argument like gnome-terminal.

gnome-calculator 3.10.2 on Fedora always puts window in the top left corner when start up.

Maybe just center on the screen or restore its position and calculate mode(basic, programming, etc.)

Created attachment 337259 [details] [review]
Solution to remembering window position

Comment on attachment 337259 [details] [review]
Solution to remembering window position

First of all, thanks for your contribution and for your effort.
I would like to have this, but there are a couple of minor issues that need to be taken care of:
* usually patches should apply against master, the latest version available in the repository, this patch seems to be created for an older version
* in case of opening multiple calculator windows, all windows will be open in the same location, overlapping and hiding the other ones (I'm not sure how we should handle this situation, the default gtk handling is well-thought, it opens the new window with some vertical and horizontal offset, compared to the previous window)
Maybe saving an array of window positions would work: when opening a new window, take the positions from the next index, or if there is no next index, then use current_position + e.g. 64px offset (both vertical and horizontal). When saving, always save. This way if I set up a calculator grid with 10 windows, i can easily recreate the grid next time, but it also works if I'm only using a single window.

@Robert Roth, thanks for your comments. I'm trying to understand how saving an array of positions should behave in the following situation: Imagine three window positions have been saved in the settings. A user opens three windows, all of which will use the settings to load their positions. Now, the user closes the window that was opened second. And then the user opens a new window. What position should this newly created window use? The position of the second window? The position of the third window plus an offset? Any other value?

(In reply to Bahodir Mansurov from comment #5)
> @Robert Roth, thanks for your comments. I'm trying to understand how saving
> an array of positions should behave in the following situation: Imagine
> three window positions have been saved in the settings. A user opens three
> windows, all of which will use the settings to load their positions. Now,
> the user closes the window that was opened second. And then the user opens a
> new window. What position should this newly created window use? The position
> of the second window? The position of the third window plus an offset? Any
> other value?

Hmmm... good question, hard to answer. I would say the newly created window should use the position of the already closed window (the second from the original layout). That will mean we never delete any positions from the array, so we will have in the array a number of positions to the maximum  number of calculator windows ever opened. 
On new window open, calculator would have to find the next unused position (I would suggest here saving the window positions array on each window close, moving the position of the closed window to the end of the list of opened windows = with index [number of open applicationwindows]). What do you think?
Maybe this is a bit too much, and saving only one window position + adding offsets when opening additional windows would also work, but if we do save window position, we should not open all windows at the same position, that's a fact.

I agree that we should not open all new windows at the same position. On the other hand, I have some doubts about saving all window positions and its usefulness for users.

As we have seen in the above example, the situation with restoring window positions gets tricky when multiple windows are involved and I can't say one approach makes more sense to users than another. For example, it's not clear in what order windows need to be restored if the user closes the second window first, and then the first and third windows. The next time the user opens the application and creates three windows, should the first window position from the original layout (because it was created first) be restored or the third (because it was closed the last)?

Also I'm not sure how many users open multiple calculator windows at once. Maybe saving multiple window positions is not needed until there is a feature request from users?

I suggest we only save the first window position. We'll then let GTK+ decide what to do with subsequent window positioning. If we add an offset ourselves, at some point when the windows reach the bottom right of the screen they will start showing on top of each other. That's why I think not tinkering with offets is also important. What do you think? Sounds like a plan?

(In reply to Bahodir Mansurov from comment #7)

> I suggest we only save the first window position. We'll then let GTK+ decide
> what to do with subsequent window positioning. If we add an offset
> ourselves, at some point when the windows reach the bottom right of the
> screen they will start showing on top of each other. That's why I think not
> tinkering with offets is also important. What do you think? Sounds like a
> plan?

Yes, let us do that: save one position, open the first window at that position, and let GTK+ position the other ones. On closing the windows, we'll save the position of the last one open.

Created attachment 338789 [details] [review]
save the last window position and use it as the first window position

Comment on attachment 337259 [details] [review]
Solution to remembering window position

>From c2a167d21dd117523c76ad171edc0cecdc10bcd0 Mon Sep 17 00:00:00 2001
>From: Bahodir Mansurov <bahodir@mansurov.org>
>Date: Sat, 8 Oct 2016 17:27:14 -0400
>Subject: [PATCH] Remember window position
>
>Save the window position before quitting the application. Then
>restore this position the next time the application starts.
>
>This will allow users to always start the application in a
>predefined position on the screen. The feature is especially
>useful when multiple windows are configured to open at set
>locations so that they can be viewed without overlapping
>each other.
>
>https://bugzilla.gnome.org/show_bug.cgi?id=632965
>---
> data/org.gnome.calculator.gschema.xml |  5 +++++
> src/gnome-calculator.vala             | 29 +++++++++++++++++++++++++++++
> 2 files changed, 34 insertions(+)
>
>diff --git a/data/org.gnome.calculator.gschema.xml b/data/org.gnome.calculator.gschema.xml
>index 45f95ab..45aa4e9 100644
>--- a/data/org.gnome.calculator.gschema.xml
>+++ b/data/org.gnome.calculator.gschema.xml
>@@ -87,5 +87,10 @@
>       <summary>Internal precision</summary>
>       <description>The internal precision used with the MPFR library</description>
>     </key>
>+    <key type="ai" name="window-position">
>+      <default>[]</default>
>+      <summary>Window position</summary>
>+      <description>Window position (x and y).</description>
>+    </key>
>   </schema>
> </schemalist>
>diff --git a/src/gnome-calculator.vala b/src/gnome-calculator.vala
>index 2cc325c..3f879b2 100644
>--- a/src/gnome-calculator.vala
>+++ b/src/gnome-calculator.vala
>@@ -74,6 +74,12 @@ public class Calculator : Gtk.Application
>         add_action_entries (app_entries, this);
> 
>         window = new MathWindow (this, equation);
>+        load_window_position ();
>+        window.delete_event.connect (() => {
>+            save_window_position ();
>+            return false;
>+        });
>+
>         var buttons = window.buttons;
>         buttons.programming_base = number_base;
>         buttons.mode = button_mode; // FIXME: We load the basic buttons even if we immediately switch to the next type
>@@ -258,9 +264,32 @@ public class Calculator : Gtk.Application
> 
>     private void quit_cb ()
>     {
>+        save_window_position ();
>         window.destroy ();
>     }
> 
>+    /**
>+     * Load window position from the settings
>+     */
>+    private void load_window_position () {
>+        var window_position = settings.get_value ("window-position");
>+        if (window_position.n_children () == 2) {
>+            window.move (
>+                window_position.get_child_value (0).get_int32 (),
>+                window_position.get_child_value (1).get_int32 ()
>+            );
>+        }
>+    }
>+
>+    /**
>+     * Save window position to the settings
>+     */
>+    private void save_window_position () {
>+        int32 x, y;
>+        window.get_position (out x, out y);
>+        settings.set_value ("window-position", new int32[] {x, y});
>+    }
>+
>     public static int main (string[] args)
>     {
>         Intl.setlocale (LocaleCategory.ALL, "");
>-- 
>2.10.0
>

Review of attachment 338789 [details] [review]:

Thanks for the patch. This one looks fine, and it seems to work fine (I have tried it on two computers actually, that is why it took so long, as on the first one the window position save did not really work, maybe it has something to do with wayland, or my strange setup).

This problem has been fixed in the unstable development version. The fix will be available in the next major software release. You may need to upgrade your Linux distribution to obtain that newer version.