From mint-bounce@lists.fishpool.fi Mon May 1 01:17:32 2006 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Subject: Re: [MiNT] wind_set(WF_TOPMOST) extension From: Odd Skancke To: MiNT List In-Reply-To: <1146434422.445533769381d@webmail2.utbm.fr> References: <200604171528.p46480@b.maus.de> <1145293368.4443ca38d6ec4@webmail2.utbm.fr> <1146334431.5682.94.camel@linuxbox> <1146380727.445461b7b0355@webmail1.utbm.fr> <1146413337.5682.101.camel@linuxbox> <1146415707.4454ea5b874cc@webmail2.utbm.fr> <1146429628.5682.118.camel@linuxbox> <1146431040.44552640f046a@webmail2.utbm.fr> <1146432908.5682.132.camel@linuxbox> <1146434422.445533769381d@webmail2.utbm.fr> Content-Type: text/plain; charset=utf-8 Date: Mon, 01 May 2006 01:07:44 +0200 Message-Id: <1146438464.5682.154.camel@linuxbox> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: ozk@atari.org 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.2 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 k3UNHWl7008780 man, 01,.05.2006 kl. 00.00 +0200, skrev olivier.landemarre@utbm.fr: > Quoting Odd Skancke : > > > søn, 30,.04.2006 kl. 23.04 +0200, skrev olivier.landemarre@utbm.fr: > > > Quoting Odd Skancke : > > > > > > > søn, 30,.04.2006 kl. 18.48 +0200, skrev olivier.landemarre@utbm.fr: > > > > > Quoting Odd Skancke : > > > > > > > > > > > Hi, > > > > > > > > > > > > I have just checked in my first implementation of WF_TOPMOST. I > > think > > > > > > the test applications work as expected, but it would be nice to get > > some > > > > > > feedback from you who know how it should work :) > > > > > > > > > > If you send me directly xaaes binary, I try to test it. > > > > > > > > I can send you a binary, ofcourse. If you already have an XaAES > > > > installation, what do you have installed? > > > > > > yes on Aranym, I suppose I can replace an old one with a new one. > > > > How old installation do you have? Just so that I know what I have to > > send. > > 29 january 2006 0.997 Alpha Okie. Should I send you a complete update or do you update to the latest alpha release first? I am going to bed now, and will send it to you tomorrow... > > > > > > > > > > > > > > > > > > > > I have just to see a bug for this part in myaes unfortunatly :-( > > > > > > > > Oh.. > > > > > > Now it's fix! > > > > > > I can send you if you wan't you can launch myaes from xaaes, should work > > (not > > > test for a long time) > > > > Yes, I can try :) > > So I send you in private patch for 0.81 version Okie, thanks :) < SNIP > > > > > > > wind_set(handle, WF_WIND_ATTACH, phandle,type,0,0) > > > > > > > > where handle is the handle of the window to attach to phandle, and type > > > > is bitmask indicating attach-links, For example OPEN(1), FOCUS(2), etc. > > > > Just an idea. > > > > > > > In fact like it is done, it's phandle attach to windows handle, this is > > more > > > logical ;-). > > > > Ah, okie. Altho I dont agree it is more logical, since it looks more > > logical to; > > > > wind_set(take_this_window, ATTACH_IT_TO, this_window, mode,0,0); > > > > which is more in the spirit of the rest of wind_set(take_this_window, > > AND_DO_THIS,...) style. But this is perhaps just me... > > strange for me because alway's wind_set() is apply to a specific window. I not > see this like this when I write this, because I would attach a window to a > specific window, I think it was to this specific window to apply the wind_set(). > really I don't know what is more logical! I see it like this; You take_this_window (the window you want to do something with) and attach it _somewhere_. The destination of the attach does not have to be another window, just that in this specific case it is in the form of this_window (the 'mount point' so to speak). In the event WF_WIND_ATTACH is extended (see below), it would make more sense to follow the existing style of wind_set/get(). > > > > > > For other I not understand what you would like to do with type, I suppose > > we can > > > add some specification to said for example to have relative position to > > the > > > mother window, to sty above etc... Actually it's only an attachment, I > > don't > > > know if this feature is interesting or not. > > > > Perhaps I have misunderstood. What exactly is the behaviour of a window > > attached to another? What relations are made via this attachment? > > Here it was only an automatic close of child windows, if mother windows is > closed, child and sub childs are close in the same time. It not do anything > more. Ok. No plans to ever extend the possible 'attach links'? Because if so, perhaps it would be a good idea to use a parameter telling the AES what links the attachment should set up. For example; wind_set(handle, WF_WIND_ATTACH, phandle, type,0,0); where type is a bitmask in which we have only one bit defined as of yet; #define WF_ATTACH_OC 1 /* Window attached is linked to the parents * open/close state. That is, when parentwindow * closes, child closes too, when parent opens, * child reopens as well */ I dont think it will hurt doing this even tho no other uses are apparent right now. I just feel it doesn hurt to open up for more uses/easier future extensions, when we invent new things like this. Allows us to group functions around one function mode as well. Anyway, off to be here ... Best Regards, Odd Skancke