[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] WCOWORK implementation : conclusions.
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?
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)
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",
...
};
Yes I see you are talking of "Components" this a very good idea, but
perhaps a idea from a dreamer ;-)
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!
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.
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
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!
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!
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.
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.
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.
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!
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!
Regards
Olivier