Hi Mirko, 
Glad to see some work being done :)
Someone reported this issue again yesterday on the forums and considering how 
many people have dual screens I guess the priority of this bug is 
increasing, so let's try to find a solution.
First thing to do would be to talk to the Tk developers on IRC at #tcl, they'll 
know what's the best solution or they could give you a hint on which 
hack is better.
My opinion would be to first check the coordinates of the window we want to 
move to the screen. For sure the upper/left corner is in the screen, we 
know that (either a new window or the smiley window will always appear in the 
screen). The problem and purpose of the [moveinscreen] proc is to make 
sure that the 'whole window' fits inside the screen.
There are multiple possible hacks, here's what comes to my mind right away :
1 - check if the top/left corner of the window is inside the [winfo screenwidth 
.], if it is, then we know we're in the primary display, if not, 
then we could just abort and not do anything (most chances are that the smiley 
menu will appear completely)
2 - do the [wm maxsize .] and if it's not the same as [winfo screenwidth .] 
then we know that we have dualscreen, and the second display's 
resolution would b $maxsize - $screenwidth. Use the suggestion in point (1) to 
know if we should move the window to the first or second display.
3 - note that moveinscreen is used for new windows (preferences, skins 
selector, plugin selector...) and rarely (I guess only once) for 
mouse-pointer-dependant windows (smielys menu). All new windows could go into 
the primary display, that's not an issue, that's why it's called 
"primary", so the issue is mainly for the smileys menu (we could grep for 
moveinscreen to make sure of that)... not a solution, but info..
4 - we could make sure that the distance from which we move the window is 
always less than the width/height. If the smiley window is not in screen, 
it means only part of it is not displayed, so the max distance to move it 
horizontally is $width, the max distance vertically is $height, so if it 
moves more than that, then we're doing something wrong... not solution again 
but useful robustness check.

I have to go now, so I'll think of more solutions later.
Mirko, after you talk to the #tcl guys, can you report back here, so we can 
discuss it further? 
Thanks!

KaKaRoTo


On Tue, Nov 27, 2007 at 12:46:58PM +0100, Mirko Hansen wrote:
> Yeah, that would be a great solution for the smiley menu, I didn't think of
> that before. But we should solve the problem for other windows, too, that's
> why I'm looking for an entire solution. It's really annoying when you are
> using amsn on a not-primary screen and *every* window is opening on the
> primary screen.
> 
> Mirko
> 
> 
> 2007/11/27, Sander Hoentjen <[EMAIL PROTECTED]>:
> >
> > On Tue, 2007-11-27 at 12:15 +0100, Mirko Hansen wrote:
> > > Hey guys,
> > >
> > > I just tried to fix the multi-screen bug mentioned here:
> > > http://www.amsn-project.net/forums/viewtopic.php?p=23738 ... but I
> > > think we won't be able to fix this. The problem is, that always after
> > > creating a window the proc moveinscreen is called that places the
> > > window on the primary screen again. So we need to get the whole
> > > geometry of all screens. Therefor [winfo screenwidth .] is useless, it
> > > always returns the width of the primary screen, independant of where
> > > the window to check is positioned. A call of [wm maxsize .] returns
> > > the geometry of all screen, but we only get the complete geometry, not
> > > only of one screen, and we don't get where the other screen(s) is/are
> > > positioned. It always returns the absolute size, but if the second
> > > screen is positioned left beside the primary screen, we would need
> > > negative coordinates to successfully move a window on that screen, but
> > > this information doesn't tell us anything about that. The other
> > > problem would be that we get "dead corners" in the case that the
> > > screens have different resolutions: The [wm maxsize .] merges the
> > > screens into one big rectangle, so there will be at least one corner
> > > that no screen can display. So we need another solution or we are
> > > unable to fix that bug. Does anyone have an idea how to be able to get
> > > the resolution and position of the other screens? I only found one
> > > article about that problem telling that tcl doesn't seem to support it
> > > and it uses some kind of dirty hack to detect how many screens are
> > > used but it doesn't really help. One way would be to let the user
> > > manually enter his screens and the fitting geometry or letting him
> > > turn off the moveinscreen-proc. Both ways are very user-unfriendly and
> > > not really safe but it would be a last resort ...
> >
> > What about checking if it is in the chatwindow first? If it is, don't
> > move it.
> >
> > Sander
> >
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2005.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Amsn-devel mailing list
> > Amsn-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/amsn-devel
> >

> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Amsn-devel mailing list
> Amsn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amsn-devel


-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Amsn-devel mailing list
Amsn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amsn-devel

Reply via email to