[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Current docking limitations (was Re: Some questions....) (fwd)
From:       Aaron Levinson <alevinsn () inetarena ! com>
Date:       1999-04-10 16:55:36
[Download RAW message or body]

Sending this again via kde-devel@kde.org alias so that it doesn't take
three days to get through....

---------- Forwarded message ----------
Date: Sat, 10 Apr 1999 08:55:11 -0700 (PDT)
From: Aaron Levinson <alevinsn@inetarena.com>
To: kde-devel@alpha.tat.physik.uni-tuebingen.de
Subject: Re: Current docking limitations (was Re: Some questions....)

On Sat, 10 Apr 1999, Carsten Pfeiffer wrote:

> there is - not nice, but it works:
> 
>   menu->move(-1000,-1000);
>   menu->show();
>   menu->hide();
> 
>   QRect  g = KWM::geometry(this->winId());
> 
>   if (g.x() > QApplication::desktop()->width()/2 &&
>       g.y()+menu->height() > QApplication::desktop()->height())
>     menu->popup(QPoint(g.x(), g.y()-menu->height()));
>   else menu->popup(QPoint(g.x()+g.width(), g.y()+g.height()));
> 
> Matthias Ettrich did all this magic a good while ago and it works
> perfectly.
> 
> Ultimately, this should go into some generic docking baseclass, so not
> every dock-app has to do this.

I'll try this out (I'm sure it works), but doesn't it seem a bit of a
kludge?  Wouldn't it be a lot nicer to have something like
KWM::positionDockingMenu(...)?  Also, is this solution guaranteed to work
with window managers other than kwm?  This sort of thing could very well
require a window manager hint.

Aaron Levinson

[prev in list] [next in list] [prev in thread] [next in thread]