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

Re: [MiNT] WCOWORK implementation : conclusions.

Quoting "olivier.landemarre@utbm.fr" <Olivier.Landemarre@utbm.fr>:



 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?
I think that moving to a WORKAREA-only coordinate system is desireable. I don't 
believe that the implementation of WCOWORK is the best way.  I understand that
using new calls is a way to force the application to only use WORK coordinates, 
but it should also be possible for application to set the FULL window size in
some situations.  There is also the library issue, which I won't argue here
again.

For the "sub-window" idea, its very simple.   There are no window borders or
widgets around the sub-window, no their size is 0, so naturally wind_calc and
the wind_xget conversaions should simply return the original coordinates that
were passed into them when used with a sub-window. WCOWORK is cleaner, but the 
method I suggested is more likely to be acceptable by everyone.


Yes it is first step and yes it is a long road.
Your talking about a complete API change, using the existing API calls. I would 
much rather see the new API be new calls.  Mixing would be discouraged, but it
would still be entirely possible so that linking with old libraries would work
just fine.


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 understand your concern.  But I think if you look into it, the problems of
mixing the two can be solved easily, especially if you use the API I outlined
which completely seperates the two APIs.

I'd be happy to address specific issues you have with the implementation I
suggested.  You have already had plenty of uproar against your current method.


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


Can be done I think as long as the application doesn't store the results of
wind_calc.   We've already been shown that windom allows this.   If you switch
solutions to one that windom developers are okay with, all that is needed is a
"I can handle a theme change" call of some such, and I bet they would be more
than willing to add a call that proclaimed they could handle on-the-fly theme
changes.
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.


I agree.


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.


Imagine multiple windows right up against each other, with no lines seperating
them and only 1 set of window widgets (one windframe) for all the window areas
it contains.  The application sees its own working area, but the user sees 1
window with multiple applications in it.


 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)


The issue here is Qed wants to save the window contents to a file, and it
expects its own menu bar.   The mailer ideally, would just want a pointer to
the data being held by Qed when you click "Send" or whatever. This is more of 
a component system.  I have my own ideas on how component systems should work
internally, but have not yet decided on the display semantics.  You've got the
display semantics, but haven't considered internal interaction.   It will be a
bit more complex than you describe since something has to share the data!
I also think if you rewrite these apps to act as a component system to share the 
data, then sharing the window is just as simple and can be done in userspace.


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


The only reason the AES has to do it instead of the application is because you
are trying to glue independant applications together by having more than 1
window per window handle.  You haven't addressed data sharing at all,nor have
you addressed the menu bar.   This seems like a hack more than what you really
want, which is a clean component system with the abstractions required to do it 
right.


> > XaAES will deliver WM_REDRAWS, WM_MOVED, WM_REPOSED, etc. etc. to the
> >correct application upon actions performed on the parent window.


And in this "HW displays the rendered version of Qed" application, how does HW
get the data that exists in Qed's edit buffer, and which menu bar is displayed? 
If there is a toolbar, which one is displayed and where?
It looks like we have three people or more that want the features of a component system, windom wants the same thing, but implemented differently. This is where 
all the arguments come from.