QWidgte::move(int x, int y) beyond the screen boundaries

**momesana** · 15th February 2007, 16:51

Originally Posted by December

I was just about to ask exactly the same question.. am doing the same thing!

I see no reason why it would not be allowed, as I can physically move a QT window half off the screen.. but using the move( x, y) function wont let me do it :-(

The same thing with Gnome! Although slightly different in behaviour.
Here a little video showing off the issue:
http://www.informatik.uni-bremen.de/...ing_window.ogg
Btw, I thing we are working on the same feature ... :-D

**momesana** · 15th February 2007, 23:11

Hi,

I've attached a file (main.h) to this post which contains a complete example app for the purpose of illustrating the issue.
compile it as usual: qmake -project && qmake && make
place the slidewidget somewhere in the middle of the screen and repeatedly press the showbutton on the other window. Then try the same thing when the slidewidget is at the alined against the top or bottom of the screen.

cheers
momesana

p.s. The issue doesn't show up on windows.

**December** · 16th February 2007, 03:11

I don't think its the windows manager.. as I've seen it done pretty well with GTK (gaim guifications does it), and that program works fine under Gnome and KDE (I don't have Windows, so can't test that).

It looks like if you manually move the window so it overlaps the edge of the screen, the slide-out works fine, but otherwise, even though the Y position is being changed, the widget refuses to move!

Anyone got any ideas here?

**momesana** · 16th February 2007, 21:14

Originally Posted by December

I don't think its the windows manager.. as I've seen it done pretty well with GTK (gaim guifications does it), and that program works fine under Gnome and KDE (I don't have Windows, so can't test that).

That's wrong. It definetly _is_ the window manager! I've just tested it with KDE in combination with Beryl and even more interesting, I tested it with the default wm shipped with X.org (xwm?) and there is works (though the animation has a million other issues on xwm...). It is _only_ because of the policy of the window manager.

Below is a list of desktop environments/wm's that I've tested:

Enlightenment 17 (works)
Gnome-2.16.2 / Metacity (doensn't work)
KDE-3.5.5 / kwin (doesn't work)
KDE-3.5.5 / Beryl (does work)
KDE-3.5.5 / Metacity (doesn't work)
X11/xwm or whatever its called (works)
Win2k (works)
WinXP (works)

However this does not mean that it is a bug. It's just the way they behave and there must be a way to tell the wm how you want the window to work. I was on the kde irc channels and they told me I should look into NETWM check for details here and here.

Thas may be the way the other apps (gaim, forecastfox etc.) achieve this effect. Tell me if you make any progress :-)

cheers
momesana

**December** · 19th February 2007, 16:28

Well, I ended up doing it by making a frame that filled my whole widget, and then resizing and moving the widget at the same time until it reached 1px high, then hiding it.

This looks exactly the same as sliding the window out, and seems to work fine.

Now if only I could figure out how to get rid of the taskbar entry when the window shows.. the main application window is already hidden, but when I show the popup it adds a mew taskbar entry. I think there are some flags to deal with that somewhere..

**momesana** · 20th February 2007, 10:12

I will try out your solution with the frames. As for the taskbar entry, one can avoid to have a Taskbar entry for a Widget/Dialog by making sure the dialog has a parent. In this case the dialog would share the same taskbar entry as the parent (mostly a QMainWindow). But I don't know how the whole think behaves if the parents taskbar entry is hidden.

cheers
momesana