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