[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] Trans.: Re: WM_REPOSED implementation



On Sat, 2005-12-10 at 17:56 +0100, olivier.landemarre@utbm.fr wrote:

> > > as I already said, because if window is bigger than dialog box, after first
> > > WM_SIZER, Windom will change size to have correct size, then when WM_MOVED
> > > occur, it not look on size, and put value from gem message, so windows size
> > > will not resize it, and will be too large, so a part of window will not be
> > > redraw.

Let's break this down ...

1 - AES sends WM_SIZED
2 - Windom sees new size < required
3 - Windom calls wind_set with new minimum size
5 - AES send WM_MOVED
6 - Windom calls wind_set

Now ... there would be a problem if the rectangle were the same for both
SIZED and MOVED.  However, you leave out step $4

At step #3 you just called the AES. and told it your new size!  If you
cached the information, do NOT go to step 4 or 5 until the application
calls wind_set and responds.

Step #4 - tha AES looks at your new window coordinates to see what to do
next.  

The AES knows if you changed the X/Y like you were supposed to - if so,
it doesn't have to send a WM_MOVED at all.  If it does need to send this
message, you've already given the AES your new minimum size that you
want, so pass the new WH set in SIZED back to the application in the
WM_MOVED.  The AES doesn't have to make the SIZE and MOVE rectangles the
same, nor does it have to send the MOVE if the program does its job.

> >  Then I think we can conclude with the fact that XaAES's method work?

If it works and no applications are using REPOSED, then the conclusion
is that either ..

A - It doesn't work or you wouldn't need a new message
B - It does work, and the new message isn't needed.
C - A better solution is needed.  I'd prefer the solution above to a new
message.

And before someone says soemthing about snapping the coordinates, I
realize that during a SIZE or MOVE you might snap any coordinates.  In
the above, if you are snapping XY and they change at step #3, then the
app knows they changed.  Coordinate snapping doesn't change the
algorithm

> Yes for me, I do the same at this time, with no implementation of WM_REPOSED, I
> don't know if I will implement or not this message, if I can't do better, I
> probably add it, if I can find better (with no trouble display (dual redraw at
> this time with some applications)), I don't know, but it's easy to do, in all
> case no compatibility trouble should appear. Wind_set(OPTS) is enough good for
> me, I will use it.

If you have visual problems, just cache the information the AES sends
you and call the AES with the new values after a timeout.  Then it
doesn't matter what the AES sends you.