[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] wind_set(WF_TOPMOST)
Hello!
fre, 14,.04.2006 kl. 09.04 +0200, skrev olivier.landemarre@utbm.fr:
> > >
> > > BTW, if you reserve this feature for "system applications", how do you
> > detect
> > > one?
> >
> > This is something we need to agree on. The details are not even
> > remotely discussed or laid out. Basically I would like for the user to
> > decide which application can use these 'system' features, because if
> > apps only need to call appl_control() and become a system app, we may as
> > well keep such things open as in the original idea by Olivier. Somehow
> > the AES needs the user to 'validate' the programs that have extended
> > access .. also because of security reasons. Perhaps some kind of AES
> > modules? But first we need to agree on the basic things :)
> >
> So ok, there is for me 2 solution:
>
> -First you can put in config file that an application allowed to do this sort of
> things, so aes reject or not ask for this.
>
> -Second first time an application some of this feature, a form_alert() can be
> display to ask user if it accept this feature for this software, aes save this
> params somewhere for next use.
>
> In this 2 cases there is no need a new aes call for this, this is an internaly
> problem for AES. Probably after, aes should provide a tool to change database
> if aes save itself the data for this feature. So for me extension is good
> enough, this is only a problem of implementation, each aes should do by itself
> solution for this, there is no API problem, application know nothing about this.
Both good solutions, Olivier :) Been giving this more thought, and the
best solution is indeed a solution that doesnt involve applications
awareness of such feature. I have the following proposal;
- We add a 'window context' adjustmets to windows through which users
can choose window behaviour like on KDE and I think Windows. For normal
apps this is the best way I think.
- For 'system apps', like taskbars etc, the API to control such things
from the application becomes available. If an 'unauthorized' application
tries to use these things, your second proposal about alerting and
letting user authorize it is a good solution.
What do you think about this, Olivier?
Best Regards,
Odd Skancke