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

Re: [MiNT] wind_set(WF_TOPMOST) extension



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.

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

>
> <-snip->
>
> > > >
> > > > In fact this function can be usefull for application.
> > > > One is simply for add a long value link to window, there is no
> interact
> > > with
> > > > aes, this is for user only, for example to put pointer link to window.
> > >
> > >  Ah, I see. Is this available to applications yet? And is there a name
> > > for this mode yet?
> > No absolutly no because I have not put any documentation for this, this is
> add
> > only in first time for internal use, and as I think it could be usefull, I
> just
> > put it.
> >
> > #define WF_USER_POINTER 230
> >
> > long is pass in wind_set() with p1 and p2
> >
> > wind_get() return value in intout[1] and intout[2]
> >
> > >
> > > > Second is to have a child window (only one at this time), when link a
> > > window to
> > > > an other window, if mother window is close, link window is close, and
> if
> > > this
> > > > have itself a link window of course it close etc.
> > >
> > >  Sounds like a good idea actually. This is up and working in MyAES now?
>
> > 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.

>
> > > 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 ;-).
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.

Olivier

>
>
>  Best Regards,
> Odd Skancke
>
>
>
>
>
>


--