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

Re: [MiNT] wind_set(WF_TOPMOST) extension



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

If possible send me all need
>
> >
> > >
> > > >
> > > > >
> > > > > >
> > > > > > 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;

At this time to much work to do more, in futur I think it was a step to manage
frame, but perhaps there is better way than this. Really I don't know if it is
usefull except for me internally, it's why I never speek about this before.

>
> 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
>                          */
Yes why not

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



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


--