Re: [MiNT] WCOWORK implementation : conclusions.

[Odd Skancke <ozk@atari.org>]

tor, 21,.07.2005 kl. 17.48 -0600, skrev evan@coolrunningconcepts.com:
> 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.

 What other ways would be better than WCOWORK, then? WCOWORK is a very
simple thing, it is about having the windowing work with WORK area of
windows instead of the FULL extent. That it. Apps can set the FULL area
of windows, and this is done like so; App knows the area onscreen it
wants to cover with a window - convert that to the corresponding WORK
area (wind_get(handle, WF_CALCF2w,...)) then wind_set(handle,
WF_CURRXYWH, ...). I've said this a million times now, what is the
problem?


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

 wind_calc() cannot be used here, because now you have two different
window types and wind_calc() is contextless. No way for the AES to know
which window type you mean. This is why I want wind_calc() depreciated.

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

 No. Either the application is a WCOWORK client or it is not. Lets keep
things simple and clean. I'm not even gonna open for possible havoc like
this by allowing the app to use one and the other. Only one or the other
is acceptible.

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

 This would completely work agains having WCOWORK in the first place.

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

 Yes, I'd like to hear your issues. But keep in mind that I want WCOWORK
ONLY and not keep the old way by making it available when WCOWORK is
enabled by the application. This is vital, and the only sensible thing
to do. If not, apps cannot benefit WCOWORK, because the AES has to take
into account that they MAY use the old-style even now. This would
encourage continuous use of the old-way, which definately is not a goal.
This adds complexity to both the AES and the application. So, no way I'm
gonna be talked into mixing ;-)

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

 Again, this is not true. It would work as long as apps dont store
values. Problem is, they do store values. If keeping the FULL oriented
way of today and theme changes was the only goal, it would be enough for
clean apps (not storing values). But how does the AES know?

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

 I do not agree. In a perfect world it would be possible, but as it is
now its not possible.

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

 First of all, this "pointer to the data being held by Qed" philosophy
is what keep our system from being workable under MP and gonna make VM
hard to implement. By these words you just showed me that your ideas
need to be really examined before evaluated.

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

 While you could do so, it would add alot more complexity to existing
applications than WCOWORK would. I'm also very instersted in knowing how
you want to share data? Please dont say 'pointers'!
 
> 
> >>  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.

 what are you talking about here? Having more than one window per handle
is impossible. What data sharing is needed by this implementation is
exactly the reason the AES has to deal with it. And what does the menu-
bar have to do with this? You obviously dont know what you're talking
about here ;-)

 The idea is that a subwindow is, to the application bound to it, just
another window, and thats final.

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

 The owner of the window ontop's menu-bar is shown. The data edited by
qed is loaded by HW when told so by Qed using AES messages. Ofcourse, a
set of messages related to 'inplace windowing' would be necessary. This
way Qed can tell HW whenever it should rerender the data held in a file.

 If HW has a toolbar, that toolbar will show up in the subwindow,
because, once again, the subwindow is just another window to the
applications bound to it.

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

 Be very careful how you design the components system, and how they
share data. Lets try clean methods for once.



 Regards
Odd Skancke