Re: [MiNT] WM_REPOSED implementation

[Odd Skancke <ozk@atari.org>]

tor, 08,.12.2005 kl. 20.49 +0100, skrev Arnaud BERCEGEAY:
> Hello,
> 
> >> I have aready defined bit 1 in wisgr to NM_INHIBIT_HIDE.
> > 
> > Ok so I can't use it, do you have other define bit for this?
> > Arnaud can you add this in gemlib documentation?
> 
> Just done in CVS :)
> 
> > I think a bit to tell WM_REPOSED is support can be put here, this is a 
> > general config for windows, wind_set is for specific windows, here it 
> > will be for all windows, more simple for applications.
> 
> I agree. For that particular feature, i think it is a parameter global 
> to the application: either the application is ready to be resized by any 
> border, or the application is only prepared to be resized from the 
> bottom right corner. I don't think this must be tunable per window.

 You're right, it _must_ not be tunable on a per window basis. But still
this is an option that belong to a given group of options, namely window
options. I find it a lot less frustrating as an application programmer
when I find all things related in the same place. This is also why I
want to keep this setting via wind_set(WF_OPTS), but if you insist on
adding it somewhere else, I will add that too, just to be compatible.

> 
> I see only two choices: an application is ready to catch WM_REPOSED for 
> all its windows, or it is not. I really don't see why a developper may 
> choice to manage WM_REPOSED for some windows, and choice to not manage 
> WM_REPOSED for others... it's so simple to support WM_REPOSED !

 Yes. If the _only_ new thing was WM_REPOSED (and that we never ever
wanted more window options) I would agree. But since there are already a
few window options the AES provides providing the application supports
it, I feel its a good idea to make those available via one call,
documented on the same page. It really is frustrating to programmers (at
least to me) to have to look for 'window related options' all over the
place. I agree that WM_REPOSED most probably never will be set on a per-
window basis, and for that wind_set(WF_OPTS, -1,...) is indented -> set
initial window options global to all application windows.

> 
> > My point of view, 
> > or we should add a wind_set() option to do general config if you prefer, 
> > in this case windows number will have no effect.
> > I think we should ask to devloppers what they prefer, shel_write() or 
> > wind_set(NEWMSG,..) specific.
> 
> Just my opinion on the general meaning of each ""partial lib" of gemlib:
> 
> shel_xxx() function are reserved for "desktop" functionalities, this is 
> stuff like lauching another application, creating a thread (which may 
> become another AES application), desktop configuration of monoTOS 
> desktop... the inhibit_hide feature is at the right place imo :)

 Agreed.

> 
> wind_xxx() are for functions to get/set datas and features of a window.

 Agreed.

> 
> In my opinion, none of these "libs" are the right place to tell the AES 
> that WM_REPOSED is supported by the application. So... where ? well, i 
> don't know. I see two options:

 Not agreed :-)

> - an appl_xxx() function because this must be global for the whole 
> application.

 appl_options() is in the pipeline. But this has a whole different
meaning, I think. appl_options() should be used to set runtime options
on a per-application basis. I think that theme handling may come under
this category.

> - an evnt_xxx() function because we command the AES to send 
> WM_MOVED+WM_SIZED or WM_REPOSED to the application... it's just a choice 
> of the *event* to be generated by the AES, so it's evnt_xxx stuff.

 evnt_xxx() should only deal with the different types of events. That
is, keyboard, messages, mouse, timers, etc. Whatever kind of messages,
or groups of messages sent should not be 'filtered' or in anyway
modified by the event_xxx() functions.

> 
> Which one of appl_xxx() or evnt_xxx() function ? i really have no idea ATM.

 Neither, in my optinion. wind_set(WF_OPTS) sets window related things
which are private to each individual application. appl_options() sets
application related options, and may not be private to applications.
That is, an 'aes system' application should be able to use appl_options
(), for example, to give a new theme to another application, or change
what AES does when that apps last window is closed, for example. See the
'app_options' configuration variable in the example xaaes.cnf for an
idea of what appl_options() is intended to do.

> 
> BTW, wind_xxx() is not so bad, but i don't like the support of that 
> feature per window basis.

 But the support on a per-window basis doesnt mean you _have_to_ do this
one setting on a per-window basis :)


 Best Regards,
Odd Skancke