Re: [MiNT] WCOWORK implementation : conclusions.

["olivier.landemarre@utbm.fr" <Olivier.Landemarre@utbm.fr>]

Hello
...
> > >
> > Ok I handerstand this, I would like too, have this sort
> > "windows-bitmaps" this will be easier for AES do some operations on
> > windows like moving it. Praticaly the application should have a VDI ID
> > v_opnbm() for each windows (it's suppose have a lot of memory (>128Mo)),
> > but when AES should draw it? I suppose when application finish to draw
> > application should send to AES that AES should draw it (probably with a
> > clipping value). Now you want have a network display solution, so you
> > have send bitmap throw network, this will be slow unfortunatly, it's
> > like VNC, if I compare this solution to X11 and more powerfull Windows
> > (sorry!) network display solution this slow (Windows solution is very
> > very fast, notice that protocole for this is open (I can't remember
> > name) for client (there is Linux solution client), so before doing this
> > perhaps we should look on existing solution, and I think it's vectorial
> > solution use and not bitmap). Notice too that solution can't use
> > hardware acceleration, for opengl for example this will be a problem.
> > 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.
>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.

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

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

>
> > 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.
>
> >
> > > 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?
>
> >
> > > Now lets think about how an email program could use this, for example.
> > >The email program scans the available IWS servers installed in the
> > >system, and finds TEXT, HTML (and possibly JPG, IMG, PNG, etc). The
> > >emailer creates a window like normal. Then it defines a part of that
> > >window to be a subwindow for the message body, lets say x = 50%, y =
> > >50%, w = 100%, h = 50%. This will make the subwindow relative to its
> > >parent, and resize accordingly. The rest of the window is used by the
> > >email program to show message-list. When the user reads a plain text
> > >message, the corresponding server is 'bound', using a wind_bind() call,
> > >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.
>
> >
> > > 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?
>
> >
> > > 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.

...

> >
> > > 5. Ease normal application programming. This has been seen as the only
> > >reason I've implemented WCOWORK mode. Not even I am stupid enough to put
> > >hours into an implementation if it only removes some, as someone so
> > >adequately put it, window calculation logics. I had hoped you gave me
> > >greater credit than that :/
> > >
> > >
> > I not think that! I just notice that some looks have retained this.
>
>  Not sure what you mean here?
Not important, I forget a word, some people looks have retained this.
>
> >
> > >
> > > These are things I can think of right now. There are definately more
> > >things I cannot think of right now. If you see a problem that may appear
> > >in the future (other than it breaking compatibility with n.aes/magic, or
> > >making libprogramming harder), or have ideas about implementation or
> > >other features that may be wished for, I'm all ears. What I do know is
> > >that the above ideas will NEVER happen without WCOWORK mode. I also know
> > >that WCOWORK mode will make it very easy for application programmers to
> > >actually support new functionality that appear because WCOWORK makes it
> > >possible. .. oh, ok, not WinDom linked apps, as this will not support
> > >XaAES.
> > >
> > >
> > Don't forget your are not the only AES devloppers at this time, I have
> > my own AES ;-) I didn't wan't complicate too much my code!
>
>  As of now the only thing needed when WCOWORK is active, from the AES's
> point of view, is to make sure all window rectangles going out to the
> application is the WORK coordinates, and all coordinates coming in from
> 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 :-(

...


> > >
> > > The biggest problem with WCOWORK mode as I see it, is that applications
> > >that want to support WCOWORK and still be usable on older AES's need to
> > >do extra checks. This will complicate writing applications, and one
> > >needs access to both the older AES and XaAES. But I wont listen to
> > >arguments of that sort, because WCOWORK removes so many restrictions it
> > >deserves a shot.
> > >
> > >
> > I think you have not think to all solutions, I try soon test an other
> > but it's summer I prefer benefit from my garden at this time!
>
>  Perhaps I havent thought about all solutions. I know the goal I have is
> to have apps control WORK area of window only, and thats it. All the
> above examples are things that will NOT be possible without this basic
> change in windowing. If such features ever get implemented or not
> depends largely on application developers. This simple goal lifts so
> 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!

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

Regards
Olivier