After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 559034 - gtk_window_set_postion not working with a gtk_file_chooser_dialog
gtk_window_set_postion not working with a gtk_file_chooser_dialog
Status: RESOLVED DUPLICATE of bug 549403
Product: gtk+
Classification: Platform
Component: Widget: GtkFileChooser
2.14.x
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
Federico Mena Quintero
Depends on:
Blocks:
 
 
Reported: 2008-11-03 02:53 UTC by Ian Puleston
Modified: 2008-12-23 01:40 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Simple program to demo the problem (1.09 KB, application/x-compressed-tar)
2008-11-03 04:10 UTC, Ian Puleston
  Details
Patch to gtkfilechooserdialog.c (1.20 KB, patch)
2008-11-20 07:46 UTC, Ian Puleston
none Details | Review
Alternate patch to gtkfilechooserdialog.c (978 bytes, patch)
2008-11-20 07:57 UTC, Ian Puleston
none Details | Review

Description Ian Puleston 2008-11-03 02:53:38 UTC
Please describe the problem:
I see this problem in Windows but not in a Linux version of the same program.

I'm using gtk_window_set_postion() to try to align a gtk_file_chooser_dialog, and it doesn't. With either GTK_WIN_POS_CENTER_ON_PARENT or GTK_WIN_POS_CENTER it gets aligned so that its top left corner is kinda near the center of the parent window, and because the file chooser window is pretty big it extends off the bottom of the screen. So every time you use it you have to drag it up to get access to the buttons.

I tried catching "map_event" and "configure_event" on the file chooser dialog (emitted when it is realized and on window size changes respectively) and printing the window size on each, and this is what I get as the window
opens:

Map event
Configure event 265 x 220
Configure event 265 x 220
Configure event 804 x 653

So I then took a screenshot to see exactly where it is positioned, and its top left corner is 132 pixels left of center and 110 pixels up from it - i.e. it's at the point that would center a Window sized 264 x 220.

So it looks like it's centering the file chooser window on one of those first two configure events, and then resizing it bigger without re-centering it.


Steps to reproduce:
1. Call gtk_window_set_position with GTK_WIN_POS_CENTER_ON_PARENT on a file chooser dialog window.
2. Run the program and open the file chooser. It is not centered.



Actual results:
The file chooser dialog is not centered.

Expected results:
The file chooser dialog should be centered.

Does this happen every time?
Yep (in Windows).

Other information:
This is the code that I use in the program that shows this:

fileDlg = gtk_file_chooser_dialog_new("Select Race", GTK_WINDOW(mainWin),
                                      GTK_FILE_CHOOSER_ACTION_SELECT_FOLDER,
                                      GTK_STOCK_OK, GTK_RESPONSE_ACCEPT,
                                      GTK_STOCK_CANCEL, GTK_RESPONSE_REJECT,
                                      NULL);
gtk_file_chooser_set_current_folder(GTK_FILE_CHOOSER(fileDlg), pStartDir);
gtk_window_set_position(GTK_WINDOW(fileDlg), GTK_WIN_POS_CENTER_ON_PARENT);

ret = gtk_dialog_run(GTK_DIALOG(fileDlg));
Comment 1 Ian Puleston 2008-11-03 04:10:47 UTC
Created attachment 121848 [details]
Simple program to demo the problem

I've attached a simple program to demo the problem. Build and run it in Linux and the file chooser dialog opens nicely centered on the program window. Build and run it in Windows and it does not.

Note - the Makefile is for Windows - to build in Linux remove the "-mwindows -mms-bitfields" from it.
Comment 2 Ian Puleston 2008-11-20 07:16:44 UTC
I've been doing some digging into this putting debug messages into gtkfilechooserdialog.c and gtkwindow.c and I've found basically why it is happening.

As the file chooser dialog window opens, first gtk_window_compute_configure_request() is called from gtk_window_show(), and it actions the GTK_WIN_POS_CENTER_ON_PARENT. But at this point the window size is only 205x200 pixels.

Then, shortly after that, gtk_file_chooser_dialog_map() is called, it maps the chooser widget, and then file_chooser_widget_default_size_changed() is called. The latter calculates the new window size as 744 x 720, and calls gtk_window_resize() to resize it to that.

So, the basic problem here is that the centering was done by GtkWindow before the chooser dialog was mapped, but the chooser does not set its final size until it is mapped, so the centering is wrong.
Comment 3 Ian Puleston 2008-11-20 07:21:10 UTC
A work around is to call gtk_widget_set_size_request(dlg, 800, 600), or similar values, on the chooser dialog window before calling gtk_dialog_run. Its probably not ideal though because from the source code it looks like the default size can come from the style, so that would get overidden. 
Comment 4 Ian Puleston 2008-11-20 07:46:15 UTC
Created attachment 123089 [details] [review]
Patch to gtkfilechooserdialog.c 

I've attached a patch to gtkfilechooserdialog.c that fixes this problem. It pre-sets the window size before it is centered by doing it in the constructor. The code I've added in there is a copy of that which sets the window size in file_chooser_widget_default_size_changed().
Comment 5 Ian Puleston 2008-11-20 07:57:32 UTC
Created attachment 123090 [details] [review]
Alternate patch to gtkfilechooserdialog.c 

I've also attached an alternate patch to gtkfilechooserdialog.c. This one does the same but achieves it by calling file_chooser_widget_default_size_changed() from the constructor. This is cleaner than the first patch, but it could be argued that we should not be calling a signal handler function directly like this.

Both patches seem to work fine.
Comment 6 Milan Bouchet-Valat 2008-12-22 22:01:32 UTC
Looks like you've provided nice fixes. So stupid that nobody read this report: the same patch was proposed in bug 549403, but they were not sure it would be the best solution to fix this bug. And since then the bug has been forgotten...

Marking as duplicate, but please comment on the other bug and provide as many ideas as you can, some maintainers are subscribed there.
Comment 7 Milan Bouchet-Valat 2008-12-22 22:03:17 UTC
Actually, I cannot mark it has duplicate of bug 549403 since I'm not the reporter... Could you do so?
Comment 8 Christian Dywan 2008-12-23 01:40:57 UTC

*** This bug has been marked as a duplicate of 549403 ***