Version: (using KDE KDE 3.2.1) Installed from: SuSE RPMs Compiler: doesn't matter. OS: Linux Whenever I try to move a dialog with move() to a QPoint position or to a int x int y, the window still gets positioned on the center of parent widget. It only applies to the case when window is move()d before show()ing. Example piece of code: window->setCaption("My dialogus"); QPoints pos = config->readPointEntry("window position"); window->move(pos); window->show(); would provide window in the center of the parent widget. I did double and triple test saving of the position, asked users to check on any distro of Linux. This type of behaviour appear since 3.2.0. In 3.1.x it works properly, and it works properly on any version of Gnome. Thanks in advance for lookking into this.
That's intentional. Why exactly should that be a problem?
Hmm, any ways to override this? I have some windows which I want to enforce position of. Like, if the user moved them during use, I store the position, and then restore it upon application restart. Now I can't do that without flickering. (i.e. if i move() after show()ing)
The kind of windows you describe don't seem to be dialog windows but rather utility windows. You should use KWin::setType( w->winId(), NET::Utility ).
There are other situations when kwin's behavior of ignoring initial position requested by the app if the _NET_WM_WINDOW_TYPE_DIALOG hint was set can be pretty annoying. For example, if the app needs to popup a dialog at mouse position -- in GTK+, you can do it easily using gtk_window_set_position(win, GTK_WIN_POS_MOUSE), assuming the WM will respect initial position request (which kwin won't). One example of affected app is a help browser that has list of index items and if you click on an item that has several pages associated with it, a dialog box pops up to let the user select the page to display. This dialog should ideally pop up near the mouse cursor, so that you can quickly click on item in it, but Kwin will show it in the center of parent window, which can be rather far from mouse cursor. Is there any reason why can't Kwin center the dialog on parent if the position wasn't explicitly requested and respect the request if it was? That should cover all cases: do a sensible thing by default (i.e., center on parent) but don't stay in the way if the apps knowns better what to do.
That indeed sounds sensible, the problem is just that applications almost always specify position of their dialogs, so KWin can't tell the difference between cases when the dialog should be positioned where the app says and cases when the app specifies some funny position just for the fun of it. And I consider this to be also the case with dialogs showing at the mouse position - I don't want any dialogs showing wherever I left my mouse 2 minutes ago. You can BTW specify placement at mouse position for all dialogs in the window-specific settings, if you force specific placement for all dialogs. But the strict dialog placement will need to be loosened, yes.
I just want to add that this behavior makes Eclipse (http://www.eclipse.org/) almost unusable with detached windows. Whenever a detached window is redisplayed/opened, KDE decides to reposition the detached view. Very very annoying. https://bugs.eclipse.org/bugs/show_bug.cgi?id=52669
Note: Eclipse works around this by using code like: get window position open window if windowing system==KDE and window position changed restore window position endif ...but hacks like this shouldn't be necessary.
For me it would be sufficient to have a function to disable the strict positioning before moving and showing the dialog, something like KWin::disableStrictPositioning().
CVS commit by lunakl: Giving up on #78082, at least temporarily. Don't force using placement policy for dialogs if they request a specific geometry. Too bad apps always specify geometry for dialogs, so if they specify silly positions like under mouse or centered on the screen the only solution for now is choosing ignoring requested position in window-specific settings. BUG: 78082 M +12 -0 manage.cpp 2.70 --- kdebase/kwin/manage.cpp #2.69:2.70 @@ -229,5 +229,17 @@ bool Client::manage( Window w, bool isMa { if( mainClients().count() >= 1 ) + { +#if 1 + // TODO #78082 - Ok, it seems there are after all some cases when an application has a good + // reason to specify a position for its dialog. Too bad other WMs have never bothered + // with placement for dialogs, so apps always specify positions for their dialogs, + // including such silly positions like always centered on the screen or under mouse. + // Using ignoring requested position in window-specific settings helps, but at least + // for Qt apps this should work better. + usePosition = true; +#else ; // force using placement policy +#endif + } else usePosition = true;
@lubos lunak: that's a good decision. Also QT programs which save the last position fo dialogs which were dragged from the user will benefit from this change! harald