Re: [MiNT] WCOWORK implementation : conclusions.

[Odd Skancke <ozk@atari.org>]

tor, 21,.07.2005 kl. 09.13 +0200, skrev Olivier Landemarre:
> Hello Odd
> 
> ...
> 
> > I will try to explain a few things that will be possible with WCOWORK
> >mode. Mind you, these things have to be implemented first. This fact,
> >that things have to be implemented first, is what makes certain ppl not
> >see the benefit. New features or new things that dont have effect NOW is
> >called incomatible, and of no use. Some of the things (altho not yet
> >existing), will not be possible without WCOWORK mode.
> >  
> >
> 
> Thanks a lot, I have think to your answer and have only technical 
> discution with you.
> 
> > 1. The AES can setup offscreen bitmaps for the windows opened by the
> >application. These 'window-bitmaps' only contains the WORK area of a
> >given window, and this can be used for multitude of things. For example
> >effectful windowing on hardware capable of it, or having the output sent
> >over the network in a server/client solution. Ofcourse, much of this
> >also needs VDI support.
> >  
> >
> 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? 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.

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

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

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

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

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

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

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

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

> 
> > 4. Virtual desktops. This really falls into category 1, about offscreen
> >bitmaps.
> >  
> >
> Virtual desktop is easy to do, I not see why you  need WCOWORK, the AES 
> can do what it wan't this exactly like when you have a wind_close() 
> without destroy, you simply ignore windows, in this case you have ignore 
> some applications windows, change probably focus and menu when you 
> change virtual desktop thats all.

 yes, agreed, this was not the best thing to mention.

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

> 
> >
> > 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 have my own gem library since 10 years, I have correct it with the 
> >>time, I not write any GEM code in my applications all interface is write 
> >>with GEM graphic C generator. As I can remember, I never look for wich 
> >>AES I use even use appl_getinfo (except perhaps for CICON support), I 
> >>look only if I use Mint or not for execution problems and at my know it 
> >>work fine on all AES (Even on single tos system), now I'm not against 
> >>new features, but I think it should be only new feature that are not 
> >>possible to add for a GEM client, the AES is a manager and should stay 
> >>manager. Perhaps now we should add new higher level feature as Windom 
> >>can provide, but it should be possible to add this on other older AES if 
> >>possible, I think it should stay GEM and not a clone of what it can be 
> >>find on X11, Windows or OSX (notice I dislike WDIALOG extension for this 
> >>and not support it in MyAeS)
> >>
> >>Just my opinion
> >>    
> >>
> >
> > appl_getinfo() is what should be used :)
> >
> > 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.



 Regards
Odd skancke