[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] wind_set(WF_TOPMOST) extension



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.

> 
> >
> > >
> > > 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 :)

> 
> >
> > > Yes of course for a very long time (since hierarchical menu are
> > implemented
> > > because I use it internaly for this)
> >
> >  Hmm... isnt it dangerous to use it internally while it is accessible
> > 'from the outside'? Isnt it harder to maintain this?
> No in fact I use it for internal window, like for popup or menu, this is not
> client  windows, client don't know it manage this windows.

 Ok.

> 
> >
> > > > What is the function name, if any?
> > >
> > > #define WF_WIND_ATTACH 231
> > >
> > > in p1 there is the number of the window to attach to the target window
> > design
> > >
> > > wind_get() return in intout[1] if there is the window attach
> > > and in intout[2] if target window is itself an attach window the window on
> > wich
> > > it is attach, 0 of course for a standard window
> >
> >  This attachment, is it related to the open/closed status of the parent
> > window? I mean, the window(s) attached this way will be slaves of the
> > parent window when closing/opening(), right? Incase this is to be
> > extended later, perhaps it would be a good idea to indicate what kind of
> > attachment one wants by selecting this;
> >
> > 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...

> 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?



 Best Regards,
Odd Skancke