Re: [MiNT] WCOWORK implementation : conclusions.

[Odd Skancke <ozk@atari.org>]

fre, 22,.07.2005 kl. 00.25 +0200, skrev olivier.landemarre@utbm.fr:
> Hello
> ...
> > > >
<...>
> > > But why not but I not see what WCOWORK mode do in this, probably an id
> > > v_opnbm() for each window is enough no?
> >
> >  Others have commented on this, all I want for now is to establish the
> > fact that this is not possible with todays handling of window
> > coordinates. Do we agree that WCOWORK is the first step on the long road
> > to such functionality?
> Yes it is first step and yes it is a long road.

 I'm not even saying that all the fancy stuff being talked about here
will ever see the light on our platform, but one thing is for sure,
WCOWORK makes it much, much easier to have things like that implemented
later, when more apps use WCOWORK. This is called looking forward :-)

> >Also keep in mind that a 'mix' of WCOWORK and
> > normal operation is not an option. I think that bring unnecessarily
> > complexity to both the AES and the applications. Therefore I will not
> > invent new functions for WCOWORK. Unless someone convince me otherwise.
> Ok I have to do some try soon.

 I would love to hear the theory behind your ideas, tho. Could you
enlighen us?

> 
> >
> > >
> > >
> > >
> > > > 2. Themes and changes thereof, as dicussed before, becomes
> > > >unrestricted. The AES gains total control of a windows outer area
> > > >without breaking anything within the application.
> > > >
> > > >
> > > I agree this is a possible solution, but only application supporting can
> > > have this feature, I will experiment my idea on this soon on MyAeS, I
> > > thing no API modification is need and all application could have this
> > > feature (even I think it's not usefull except for some extra feature I
> > > wan't to test)
> >
> >  By definition of WCOWORK, the AES can perform themechanges on any
> > window immediately. This is the nature of windowing systems where apps
> > only control the 'output' area (WORK) of windows.
> I think only it should be possible already to change themechange(with widframe
> with different size of course) for older applications without adding WCOWORK I'm
> perhaps wrong but I think be able do it.

 Dont look at one thing alone. The thing is that all things are made
possible AT ONCE by going WCOWORK should be the issue. Look at the big
picture, where WCOWORK makes each single issues easier, and much more
importantly ALL issues possible, and throw this "This issue could be
made to work without WCOWORK mode" mentality out the door. Dont get hung
up on what could work with todays implementation and try to look
ahead :-)


> >
> > >
> > > > 3. 'inplace windowing' -- in lack of a better term. This is an idea I
> > > >have which I will test. Remeber that this is NOTHING DEFINATE, it is an
> > > >idea I have which I will test out. Altho the stuff below is not defined
> > > >in anyway it roughly outlines what its about. The idea is this; Each
> > > >WCOWORK capable application can select to register itself as a IWS
> > > >(Inplace Window Server, again lack of better term) by passing a
> > > >structure like below to appl_register() (yes, a new call, which isnt
> > > >only for this idea, or not at all. All hypothetical atm);
> >
> > > >
> > > >
> > > Yes I see you are talking of "Components" this a very good idea, but
> > > perhaps a idea from a dreamer ;-)
> >
> >  These are not components, at least not by my definition of
> > 'components'. Now I also need to say that I'm not sure about what can be
> > classified as 'components' :-)
> >
> >  And no, this is not a dream. Infact, Qed/HW tests will be done in the
> > forseeable future, and very little additional support is needed by those
> > applications. Only the appl_register(), WM_SUBWIN (or something) and a
> > flag to skip wind_create/wind_open() is needed. At least theoretically.
> > The AES will do the housekeeping here. Again, things like this is
> > possible as soon as apps only regards WORK area of windows, which is the
> > whole purpose of WCOWORK.
> Ok, if I anderstand, for example you ask HW to draw in a part a windows as if it
> was an entire window(you probably need sliders), it should work, but I don't
> know relation with WCOWORK, you have already wind_get(WF_WORKXYWH), for a entire
> window, and if you need a part, you should probably extent this with a part
> number with a wind_get(WF_WORKXYWH_PART) or something like this. There is
> nothing more to do, and it's quite more logical than add a new mode, this is
> only a default application design if software not use it and compute diffrence
> beetween fullarea and workingarea (my own softwares do this :-( ), as most
> software patch themself RSC for example select an object not the best but there
> is already functions to do this.

 No, you do not ask HW to draw in a part of a window. My idea is that HW
uses a pre-created window which is (perhaps) already opened. Thats it.
The only thing HW cannot do to this window is to create/open/close it.
When HW deletes the window, the ownership of the subwindow goes back to
the owner of the parent window. Apart from this, HW sees the window as
it would any other window.

> 
> >
> > > look at dynamic library there is this sort of avaible for more than 10
> > > years, and how many lib does exist that are use than more than one
> > > applications? 10? 15? not more perhaps less, do a component is more hard
> > > than to do a dynamic lib!
> >
> >  Things like this cannot be done in user-space. Therefore the AES has to
> > support this for it to be a clean solution. The reason for this is that
> > each subwindow, or frame if you will, of a window is bound to the
> > application with the required service.
> I not said to use dynamic, I just said how it's difficult to have components,
> because we are not so many to still developp. But I said just after :-(
> 
> I not anderstand you speek of user-space, what you can't do in user-space? Do
> you think about memory protection? Or have you an other idea?

 Why not try to make the implementation as application-author friendly
and complete as possible? This will, in the end, be of a great benefit
for the USERS. And the idea I have make us have functionality seen on
other GUI's at a very low cost I think. Ok, perhaps hard for us AES
developers, but that is part of the fun, right?

 And yes, memory protection and related things GOT TO be at number 1 on
the priority list when implementing new schemes like this. Lets keep
things simple, clean and understandable.

> 
> >
> > > Is it only for display? So it's quite more easy but perhaps you wan't
> > > edit with component and here problems are very hard. Good idea but I
> > > would like see it implement. If it's only  for display simple dynamic
> > > lib with good design interface is enough.
> >
> >  Its for editing too. Lets take an emailer for example using Qed to
> > compose messages. To Qed, the only difference between one of its own
> > windows and a window handle received via WM_SUBWIN is that the SUBWIN
> > isnt created/opened by Qed. Now the emailer can just forward kbd events
> > to the service bound to the subwindow. Or perhaps the AES can housekeep
> > topped subwindows, as if parent window was root window, this is a detail
> > needing discussion, but in that case the AES sends the kbd directly to
> > the 'owner' of the subwindow (which is the application 'bound' to that
> > subwindow)
> Ok perhaps.

 The design of my idea has not yet started. I have the idea laid out in
my head and have to conduct tests. But I hope we can work together on a
clean implementation. Therefore I would like to know what your idea is,
the theory you have. Could you share some light on this?

> >
> > >
> > > > In addition to this, XaAES supports defining areas of an existing
> > > >windows to be 'subwindows'. These 'subwindows' are 'windows in a
> > > >window'. Each subwindow can be 'bound' to an IWS server.
> > > >
> > > >
> > > Yes you speek of "frame", a lib like windom do this I think but I don't
> > > know how is manage sliders inside window, if you wan't add this, this
> > > could be interesting to speek about how implement it
> >
> >  Yes, it is sort of a frame. But this is something a lib cannot
> > housekeep. The AES has to support this at a low level for implementation
> > to be 'complete'.
> Possible, do you think about something?

 Since the applications should have as little to do with the
housekeeping (such as sending WM_REDRAWS, WM_MOVED, etc) of subwindows,
the AES should do this automatically. And since this is a OS context
job, only the AES can do it. Furthermore, user moves a window (lets say
a window where qed has lower-part bound to HW), the AES sends WM_MOVED
to qed (the parent window). Qed then does a wind_set(handle,
WF_CURRXYWH, ..) which will now generate a WM_MOVED for the subwindow
and sent to HW. The subwindow will not change size, but is clipped
agains the parent window with  regards to its rectangle list as seen by
HW, until HW performs a wind_set(handle, WF_CURRXYWH, ..). This is
housekeeping the AES must do. We could take this one step further by
making the subwindow a complete slave of the parent window in which case
the AES resizes the subwin immediately and implement new _informative
only_ messages like WM_HASMOVED, WM_HASRESIZED, WM_HASREPOSED, etc. Much
like the WM_ONTOP and WM_TOPPED messages. One is user action, the other
is informative, that is, your window got topped because another window
was bottomed.


> >
> > >
> > > >which will do the following;
> > > >
> > > >
> > > This is exactly HTML facilities!
> >
> >  Not sure what you mean?
> In HTML you can subdivide the Window that's all I wan't to said.

 Ah, ok. I dont know html at all :)

> >
> > >
> > > > Send a WM_WINDOW which contains the handle of the window the server
> > > >should use. And here is the whole point of this idea; The only thing a
> > > >WCOWORK client needs to do now is to NOT CREATE/OPEN the window for
> > > >itself. It is already done. But the rest of the functions the server use
> > > >for its own windows can now be used WITHOUT MODIFICATION. That is, the
> > > >only thing necessary for HW to support to make this work is to skip
> > > >wind_create() and wind_open() in its 'new_window()' function when
> > > >'new_window()' is called as a result of receiving WM_WINDOW.
> > > >
> > > > XaAES will deliver WM_REDRAWS, WM_MOVED, WM_REPOSED, etc. etc. to the
> > > >correct application upon actions performed on the parent window.
> > > >
> > > >
> > > >
> > > >
> > > I have some difficult to handerstand!
> >
> >  Lets imagine this (which is the first test I'll attempt, when I get
> > around to it); html editing in Qed. Qed opens a window. Then defines the
> > lower half of the window to be a subwindow. Qed then binds HighWire to
> > this window. As you edit the html in the upper part, HighWire renders
> > the html in the lower. Now, if you drag another window infront of this
> > Qed window, WM_REDRAW messages are generated. The AES will then send
> > WM_REDRAW messages for the subwindow directly to Qed, and for the upper
> > part to Qed. Same with clicks. Those are handled as if the subwindow was
> > a standalone Highwire window.
> Ok this more clear for me, so the part is as if an HW Window and AES send
> messages to HW, this is interesting, I suppose HW have an ID windows diffrent to
> the Qed ID window, I think it's more easy than add any second number so
> wind_get(WF_WORKXYWH) is enough for HW, who decide if there is slider or not,
> toolbar? When you move Window,is there any message to HW, HW should each time
> ask to get workarea?

 yes, subwindows have their own window handles, ofcourse. Slider,
widgets, etc. etc. is pre-set by the subwindow creator. So, if the
creator creates a window wthout sliders, no sliders will be available.
Toolbars will be there as it would be in any other windows created by
the app useing the subwindow. And we could have an element in the
iws_register structure holding the window widgets (sliders, etc) which
this server wishes to have on its subwindows.

> >
> > >
> > > > Please dont make comments about the hypothetical implementation above,
> > > >unless one see something that may be a large, large problem. The idea is
> > > >to illustrate what WCOWORK mode can do to our system while making it
> > > >very easy for application authors to support.
> > > >
> > > >
> > > Ok no comment.
> >
> >  You do not see big problems then? ;-)
> I not said this, just I not comment something hypothecal as you ask me, I not
> think it's so easy to adapt a software to this system, but I not see real
> problem on it too.

 Okie :)

> >
> > > >
> > the application is converted to FULL extent. Yes, XaAES internally works
> > with the full extent.
> I agree with you, when AES was write they should do it, but it was not
> unfortunatly :-(

 That does not mean we should not attempt to change that :-)

> 
> ...
> 
> 
> > many restrictions it amaze me. I cannot think of any remaining
> > restrictions future extentions/functionality WCOWORK applications will
> > hit.
> >
> I try my own solution, the best win!
> Let me 2 weeks, I test, if it work I send you a version and explain how I do, if
> not work I had WCOWORK in MyAeS!

 Please let us know the theory behind your ideas. I very much would love
to hear it :-)


> 
> I try not continue answer on it on this mailing list, because it take the few
> time I have to work on MyAeS.

 Ah, let me promise you that I know exactly what you are talking about
here! I was badmouthed because I just went ahead and implemented WCOWORK
(well, as of yet it is more experimental than an established solution)
so be careful ,-)



 Best Regards
Odd Skancke