From mint-bounce@lists.fishpool.fi Sun Jul 24 22:28:12 2005 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Date: Sun, 24 Jul 2005 22:25:16 +0200 From: "Arnaud BERCEGEAY" To: "MiNT List" Subject: Re: [MiNT] WCOWORK vs WINDOM for components References: <1122144091.42e28f5b54c69@imp2-q.free.fr> <1122227578.5660.520.camel@linuxbox> Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 Message-ID: In-Reply-To: <1122227578.5660.520.camel@linuxbox> User-Agent: Opera M2/8.01 (Linux, build 1204) X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: arnaud.bercegeay@free.fr Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: 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=1.9 tagged_above=-50.5 required=7.0 tests=AWL, BAYES_00, RCVD_IN_SORBS X-Spam-Level: * Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by wh58-508.st.uni-magdeburg.de id j6OKSC3M025061 Hello, >> (IMHO) because this new xaaes feature is something that windom >> developpers >> already experience for years. > > I didnt know that. What new XaAES feature do you mean? merging of differents "objects" (Text editor and HTML viewer for example) in one window. That is frames and inplace drawing. > I didnt know windom could do OS housekeeping needed to make this work > smooth. I don't know if it's ironic or if you sincerely didn't understand my post. > However, the IPW idea was not the real discussion, True. > WCOWORK was. True, and i try to understand why WCOWORK is needed, what's the benefit behind this implementation. This implement introduce some incompatibilities, so i'd like to know if the benefit is enough to support this feature. I'm sure you haven't introduce WCOWORK just for the fun to break compatibility... And i hope you have others ideas than just "simplify a bit xaaes-only applications that doesn't use libraries". In your answer to Olivier, you post some very nice ideas to justify why we have to use WCOWORK (this is what i ask from the begining of this tooooo long thread). To justify WCOWORK, there is only the feature already describe (merging of different objects). I'm not speaking of the implementation, just the main idea. >> We (windom developpers) find out that "framed" window in windom (wich >> is very >> similar to what you have described in this ML) was not flexible and >> powerfull >> enought, and after hours of discussion, thinking, argmentations, we >> conclude >> that we missed a COMPONENT mechanism, and we spend a lot of time to >> define what >> a COMPONENT should be and what it should not be. At the moment, we are >> about to >> deprecated the "frame" feature because a COMPONENT is much more simple >> to use >> and develop, and it's much more powerful and flexible, only advantages ! > > I can think of several reasons why this conclusion was made. One being > the fact that windom is a library, not part of the OS. Is that ironic too ??? I wonder if i must keep replying to this post... Your argument if for sure not valid ! > I have found out that there is no room for any further development of > XaAES. Reason I say this is that every new development goes on outside > the AES kernel, in the form of libs, etc. NO ! Stuff shall be done in the AES, and other stuff should be done in the user-space in libraries for example. I know we disagree on the scope of AES, and that's why i didn't speak about it. I just tried to give you some tips if you want to introduce the feature discussed in xaaes (i haven't written in that post that i don't want xaaes to have this feature)... If you don't want themm, just ignore them ! Then i'm sure you'll find the same limitations and pb that we (windom developpers) have found. > And when new features like > WCOWORK cannot even see the light of day because "windom already have > it", Very wrong. If you introduce a feature supported by windom "because of AES lack", then i'll try to support it in windom without hesitation. Frames in window may be one of them (windom have its own routines to draw and manage sliders which cannot be consistant with the AES because of the lack of AES). > I no longer see the point. New features seems to belong in > libraries. I dont agree, You're right :) > All new development for our platform seems to be > centered around libraries. This is very wrong. New features NEED the support of the AES... and new AES features need the support of application to be widely spread. Let's work together. best regards, Arnaud.