Re: [MiNT] WM_REPOSED implementation

[Odd Skancke <ozk@atari.org>]

tor, 08,.12.2005 kl. 09.54 +0100, skrev Olivier Landemarre:
> Hello all
> 
> I'm quite surprising of the implementation in XAAES of new message 
> WM_REPOSED, I think WM_REPOSED is a very good way to change position and 
> size in same time, and I totaly agree with this, because change position 
> then change size is some time not very beautifull on screen. But I'm 

 Thanks :)

> quite surprising, that this message is send only if application have 
> done a wind_set(WF_OPTS) so for all windows that need support this, this 
> is a general message, and more simple for application should to use 
> shel_write(SWM_NEWMSG,wisgr,...) with wisgr  with bit 1 to 1 if 
> WM_REPOSED is support, I 'm going to add this in myaes.

 I have aready defined bit 1 in wisgr to NM_INHIBIT_HIDE. I did this in
relation to the 'inhibit_hide' argument to 'app_options' configuration
variable, see the example xaaes.cnf file in cvs source tree and lookup
'inhibit_hide'. The idea was to provide a way for apps that want to be a
'system app', to tell the AES that it never wants to be hidden. I should
have notified all about this, but sometimes I just forget, sorry :) If
there are better ways to provide this, please dont hesitate to add your
views.

 Anyway, I do prefer keeping WM_REPOSED support in the way it is now.
That is, in the correct context via wind_set(WF_OPTS), as this is an
option specific to windows. In addition to that, wind_set(WF_OPTS) allow
apps to set options like this on each single window instead of affecting
all windows, if it chooses. It would allow us to let application like
Taskbar that set NM_INHIBIT_HIDE to use wind_set(WF_OPTS) to allow the
AES to hide only selected windows.

 Basically I think this; shel_write(SWM_NEWMSG,wisgr,...) should be used
to indicate generic message types, which doesnt fall into categories
like WM_xxx which are window messages. This is why AP_TERM is defined
here, and this is why I added MN_INHIBIT_HIDE here. Other messages which
fall into a specific category should be configurable via the relevant
calls, to keep things neat and tidy :)

 What do you think?

 Best Regards,
Odd Skancke