From mint-bounce@lists.fishpool.fi Fri Apr 14 09:09:20 2006 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Message-ID: <1144998269.443f497de58c5@webmail1.utbm.fr> Date: Fri, 14 Apr 2006 09:04:29 +0200 From: "olivier.landemarre@utbm.fr" To: MiNT List Subject: Re: [MiNT] wind_set(WF_TOPMOST) References: <443E1915.5090804@utbm.fr> <443E9A2B.6680.17817B8@localhost> <1144969895.25823.119.camel@linuxbox> In-Reply-To: <1144969895.25823.119.camel@linuxbox> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 User-Agent: Internet Messaging Program (IMP) 3.2.8 X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: Olivier.Landemarre@utbm.fr Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: X-Virus-Scanned: by amavisd-new at relay.boerde.de X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on relay.boerde.de X-Spam-Status: No, hits=-0.6 tagged_above=-50.5 required=7.0 tests=AWL, BAYES_00 X-Spam-Level: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by wh58-508.st.uni-magdeburg.de id k3E79Kwo006074 > > > > 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. Olivier