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 111960 - Keep Form/Window/Dialog inside Screenbounds
Keep Form/Window/Dialog inside Screenbounds
Status: RESOLVED DUPLICATE of bug 92094
Product: gtk+
Classification: Platform
Component: .General
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2003-04-30 22:56 UTC by Ali Akcaagac
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Screenshot of the forced Scenario (695.20 KB, image/png)
2003-04-30 22:57 UTC, Ali Akcaagac
Details
Screenshot 1 (313.56 KB, image/png)
2003-05-01 12:28 UTC, Ali Akcaagac
Details
Screenshot 2 (432.79 KB, image/png)
2003-05-01 12:28 UTC, Ali Akcaagac
Details
Screenshot 3 (509.06 KB, image/png)
2003-05-01 12:30 UTC, Ali Akcaagac
Details

Description Ali Akcaagac 2003-04-30 22:56:29 UTC
Hello,

There is a problem that keeps bothering me for a long time now and this is
specially annoying in Applications that open a lot of little Forms (From
here I continue saying Form for Window/Dialogs).

Specially noticable when e.g. opening the GIMP and dealing with various
Forms you see after some time that some Forms are being opened out of the
bounds of the Windowmanager (regardless which one it followed me on
SawFish, KWIN, MetaCity and so on). Say you want to use GIMP for creating
all sorts of graphics or any other application GTK+ related that you like
to normally work with then it's highly annoying if a Form pops up outise
the Windowmanager boundary e.g. at the far bottom, then you need to drag
with the mouse on the Title of that Form and drag it inside the
Screenboundaries again to work normally with it. I hope you can follow what
I like to explain. Attached is a png Screenshot of my Desktop describing
this 'poping up' outside the Screen a bit better. On the Screenshot you see
a forced scenario where the Fileselector pops up outside the boundary. I
know that the Windowmanager is responsible for dealing with these things
correctly but I also know from Motif (a Toolkit that I used long time ago)
is able to force Forms to override the Windowmanager.
Comment 1 Ali Akcaagac 2003-04-30 22:57:45 UTC
Created attachment 16158 [details]
Screenshot of the forced Scenario
Comment 2 Michael Natterer 2003-05-01 12:12:34 UTC
How did you "force" the scenario in the screenshot?

Just FYI: GIMP remembers the positions of many windows,
but not the position of the File->Open dialog. It is just
hidden when you close it and gtk_widget_show()n again
when you open it again.

BTW, what GIMP/GTK+ versions are these?
Comment 3 Ali Akcaagac 2003-05-01 12:27:16 UTC
> How did you "force" the scenario in the screenshot?

I manually moved the FileSelector to that location only to demonstrate
how this looks like. But look at the other 3 attachments these are
real work scenarios not cheated.

> Just FYI: GIMP remembers the positions of many windows, but not the
> position of the File->Open dialog. It is just hidden when you close
> it and gtk_widget_show()n again when you open it again.

Yes but The GIMP was just an example, this is valid for a lot of GTK+
related applications. The GIMP was choosen by me because of it's
nature dealing with a lot of windows.

> BTW, what GIMP/GTK+ versions are these?

CVS HEAD of everything but If you recall I mentioned that this was
following me for a long time now (I even recall this on my early GTK+
1.x days) regardless if I use stable or not stable.
Comment 4 Ali Akcaagac 2003-05-01 12:28:00 UTC
Created attachment 16166 [details]
Screenshot 1
Comment 5 Ali Akcaagac 2003-05-01 12:28:53 UTC
Created attachment 16167 [details]
Screenshot 2
Comment 6 Ali Akcaagac 2003-05-01 12:30:00 UTC
Created attachment 16168 [details]
Screenshot 3
Comment 7 Ali Akcaagac 2003-05-01 12:33:50 UTC
Ok I want to precise again:

I use CVS HEAD of GTK, GNOME, GIMP and my current WM is Metacity HEAD.

But regardless to my current setup this also happened with GTK+ 1.x
and was following me for a long time now but I assume no one really
paid attention for this situation. The same I get with different WM's,
with GNOME or without GNOME and it doesn't matter if I use the GIMP
for this cases or not, this also happens with DIA, Sodipodi and so on.

SS1:

I loaded a picture, pressed 'save as' the fileselector pops up on the
bottom and outside the physical screen and then the png dialog far
more outside.. A natural behave without cheating or manual movement.
Even removing the bottom panel still shows the Frame outside of the
physical screen.

SS2:

I wanted to close the Picture and the little top right dialog shows up
outside of the physical screen.

SS3:

see SS1
Comment 8 Ali Akcaagac 2003-05-01 12:56:56 UTC
I have just talked with various people and they are getting the same
annoying behaviour with GTK+ applications doing this. No matter what
WM with or without GNOME.

A fine solution would be a 'force on Physical display' option or
something that places Forms inside the boundary of the Physical Screen
(where doesn't matter) it only should force them to completely show up
there from the top(x/y) till bottom(x(y) if possible a WMHINT is
required that even takes panels into consideration so that the Panel
either KDE or GNOME doesn't overlap that too.
Comment 9 Johannes Rebhan 2003-05-01 13:00:59 UTC
Hi

I recognized the same problem with GIMP...
like when i create a new layer, sometimes the create a new layer
dialog is opened out of the window boundaries and i have to drag in
into the screen before i can use it..

or when i want to save my picture sometimes the save dialog is out of
the window boundaries but mostly then not on the bottom of the screen
but on the top.. so i have to use ALT + LeftMouse to get the window
into the boundaries again..

Greets
Waldgeist
Comment 10 Havoc Pennington 2003-05-01 13:37:13 UTC
There's a GTK bug open about how GTK sets USPosition too often;
this bug is a duplicate of that one. However, I can't find it.
Comment 11 Matthias Clasen 2003-05-05 12:03:50 UTC
Maybe bug 92094 is what you meant ? Its about PPosition, not 
USPosition, though.
Comment 12 Havoc Pennington 2003-05-05 18:34:07 UTC
Right, PPosition. I thought I'd filed a bug myself on this; 
maybe not. Anyhow, seems to be a dup of bug #92094 in any case.


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