Re: [MiNT] WCOWORK implementation : conclusions.

[Odd Skancke <ozk@atari.org>]

ons, 20,.07.2005 kl. 14.13 +0200, skrev Olivier Landemarre:
> Hello
> 
> >-----BEGIN PGP SIGNED MESSAGE-----
> >Hash: SHA1
> >
> >Hi!
> >
> >I followed the thread all the time and as there was the question for
> >some comments, so here are my thougths on the topic.
> >
> >I understand the need for the WCOWORK-mode and i second it. As i started
> >to code some smaller programs i found it quite anoying to convert
> >between FULL an WORK-areas. WORK area was/is the area i cared about,
> >FULL was what the AES told my about the windows. If there is a
> >function-mode where a application only has to care about the WORK-area,
> >i think this would be a clarifying and easier to handle step.
> >  
> >
> This thread is long, I can't read all and I was on hollyday's
> 
> I just wan't to know exactly why WCOWORK-mode is for. I think only Odd 
> can explain it, is there a link for this that explain this? because when 
> I read some message it's not quite comprensive for me. Example here if 
> it's only to be more easy to convert from full to work area, there is no 
> interest it's less than 10 lines in a code, I don't think Odd add this 
> only for this! I suppose it was to be possible change at fly windframe, 
> I am wrong? If it is I think it's a way to do this (but I don't think 
> it's the best way). So if someone can explain exactly and simply.

 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.

 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.

 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.

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

 struct iws_register
{
  short iws_class;
  short iws_type;
  short iws_capabilities;
  char  iws_name[32];
  ....
};

 iws_class is a class code indicating what kind of service this
applications provides, like;
 IWSC_VIEWER, IWSC_EDITOR, etc. etc.

 iws_type indicates what type of data or files it can work with, like;
 IWST_HTML, IWST_TEXT, IWST_WORD, IWST_JPG, IWST_HYP, IWST_IMG, etc.
etc.

 iws_capabilities indicates what capabilities the server has, and
iws_name is the name of the application.

 Now imagine HighWire and Qed each having structures like this;

 struct iws_server
{
  IWSC_HTML,
  IWST_VIEWER,
  0,
  "HigWire",
 ...
};

 struct iws_server
{
 IWSC_TEXT,
 IWST_EDITOR|IWST_VIEWER,
 0,
 "Qed",
...
};

 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.

 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;

 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.


 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.

 4. Virtual desktops. This really falls into category 1, about offscreen
bitmaps.

 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 :/


 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.

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



 Best Regards
Odd Skancke