Re: [MiNT] wind_set(WF_TOPMOST) extension

[Odd Skancke <ozk@atari.org>]

man, 01,.05.2006 kl. 00.00 +0200, skrev olivier.landemarre@utbm.fr:
> Quoting Odd Skancke <ozk@atari.org>:
> 
> > søn, 30,.04.2006 kl. 23.04 +0200, skrev olivier.landemarre@utbm.fr:
> > > Quoting Odd Skancke <ozk@atari.org>:
> > >
> > > > søn, 30,.04.2006 kl. 18.48 +0200, skrev olivier.landemarre@utbm.fr:
> > > > > Quoting Odd Skancke <ozk@atari.org>:
> > > > >
> > > > > >  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