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

Re: [MiNT] WM_REPOSED implementation



lør, 10,.12.2005 kl. 00.29 +0100, skrev olivier.landemarre@utbm.fr:
> >
> > >
> > > I do exactly this actually except I prefer WM_MOVED before WM_SIZED, this
> > what I
> > > do on CVS, and it work not so bad, in official 0.70 version I do only
> > WM_MOVED.
> >
> >  MyAES sources are available via CVS? Please let me know how to check
> > the sources out if they are! ;-)
> 
> For private use actually, source have to be clean up a lot, it's something near
> war in it. But if you wan't a part I can send you.
> In fact it's not CVS but subversion.

 Ah, well, I can wait until the CVS sources go public, then :)

> 
> >
> > > redraw at all, because it correct size only on WM_SIZED. So prefer WM_MOVED
> > > before WM_SIZED.
> >
> >  And all of these problem are solved by the method I use in XaAES.
> 
> I'm agree with your solution, but I'm not agree with this line, you not solve
> anything except some contradiction documentations. The problem is not with new
> applications, because if it support WM_REPOSED, this application is also able
> to solve it in WM_SIZED. For older they still continue to received 2 messages

 Yes, and in this case, as I stated in another posting, we could replace
all, keeping only one message. Since both coordinate pairs can change
(but not always) in WM_SIZED in this scenario, we can remove the other
two when apps support it. But since SIZED/MOVED are already defined, I
just added a third in addition to the possibility of resizing using
top/left, left borders. This gives us 3 messages, MOVED (only x/y),
SIZED (only w/h) and the new REPOSED (x/y and w/h). Since two already
existed and have a defined use, why not solve a lot of problems adding
one message and let the existing one comply to their names? This is the
cleanest, least confusing and most robust way. Even apps knowing REPOSED
will benefit when it needs to know which coordinate pair changed, since
SIZED/MOVED wont change behaviour compared to other AES's.

> and perhaps not understand it correctly (in fact I can't find programs that not
> support WM_MOVED then WM_SIZED if we not change W&H for WM_MOVED and X&Y for
> WM_SIZED, I prefer change twice at this moment so perhaps it can cause some
> trouble if I find some of them I will change it but visualy this is quite
> better to change all), or more sure have not very pleasant visual redraw, this
> is in fact the real problem, it's possible to solve it but not easy at all to
> do.

 I didnt exactly understand I think, but if you mean that visually the
sending of a MOVED/SIZED pair is not beautiful, I agree. But it works.
Since MOVED/SIZED doesnt change meaning in XaAES, apps will have to tell
the AES that REPOSED is peferred (via wind_set(WF_OPTS, -1,...)) and
then XaAES sends REPOSED when necessary.

 I think this is easier/cleaner than to attempt 'adding' meaning to
SIZED, in that to the enduser, dragging top/left corner of a window is
infact sizing. Its only going to create unnecessary problems trying to
modify existing things to work in both worlds.



 Best Regards,
Odd Skancke