Re: [MiNT] WCOWORK implementation : conclusions.

[evan@coolrunningconcepts.com]

Quoting Odd Skancke <ozk@atari.org>:

> Not sure what you mean here. I'm still interested in information about
> things you've done, tho

As for things I've written in the past ... I wish I could show you the 
source to
iSecure - that was a fun project, basically a transparent ethernet bridge that
filters out DoS attacks without signatures or baselines.   Maybe I'll put the
video we did for it up somewhere - I got one that compressed pretty 
small.  Can
you view DivX format files?    Hmm .. oh yeah, check the MiNT 
changelog!!  Grep
for either Evan or ekl, that was about 12 years ago.  I think I was still a
teenager back then.

Okay, enough of that.  I think we are getting somewhere.  These two sections
give me an idea of where you are coming from.

>  One of the key points when applications want to, for example, keep the
> same WORK area after changing the window-layout (widgets) is to use
> wind_get(handle, WF_CALCx2x) to get the corresponding WORK area, and
> never store this for itself. This was going to be new programming
> guidelines for WCOWORK. I know that WinDom linked apps is clean in this
> respect, and allowing some things intended for WCOWORK only would break
> loads of apps that is NOT WCOWORK aware and not linked against WinDom. I
> wanted to keep 100% compatible here. Thats why I wanted a new 'mode' in
> which the API have different programming documentation. And this also
> makes sure the already documented API's dont change.

<< stuff deleted >>

>  Because the application does not control the FULL area. That is, there
> are no 'offsets' from FULl to WORK. The biggest problem today is that
> many apps store this offset. And because of this, a window's deltas
> cannot change. One of the foundations of WCOWORK was to remove such
> considerations completely, allowing the AES to do whatever it wanted to
> areas around the WORK area without the application needing to know. This
> fact alone opens up for a lot of possibilities. If there was even the
> slightest possibility that the application _could_ use the old api in a
> mixed api solution, the AES needs to consider this, and either disable
> functions/features depending on this, or send messages to the
> application when FULL/WORK relations change.

OK, I think I see where we differ ...

1 - You say that if the AES changes the windframe or anything else related to
the FULL area that it needs to somehow either compensate the API, send
messages, etc, to inform the application of the change, or compensate for the
fact that the application doesn't know about the change.   This would be
necessary because of the number of poorly written applications that do things
such as saving AES information and offsets.   To avoid this, WCOWORK removes
the FULL area as much as possible from the programmer as well as being a new
mode, assuming that anyone using the new mode is responsible enough not 
to save
AES data and offsets and should be writing properly behaving applications, and
so its safe for the AES to manipulate the FULL area like theme changes.

2 - My manner of thinking is to publish the correct way of doing things, allow
both APIs, and simply have an AES call that says "Hey, I don't save AES data,
trust me", instead of a "mode".  I can understand your view especially since
you know the platform better and evidently most applications are still not
following the rules even after 12 years.  I still think mine could work, and
that there is still a good possibility some idiot will screw up your WCOWORK
and save data about window relationships between AES calls anyway!  Neither is
foolproof, just a different set of drawbacks.   My way would have some
additional advantages (such as allowing mixed APIs and behavior that respects
modular programming since behaviors of API calls never change), but also some
additional dangers since it would be much easier for developers to screw it up
and indeed, more API calls to choose from often means choosing the wrong one,
and people would blame XaAES and not the application developer since they were
just using the calls that were there (in spite of the documentation about when
a call was appropriate).

Are we finally on the same page?   We aren't going to come to an agreement on
which is better, and we could debate this for ever, but as long as I 
understand
things correctly, then I'm fine with things as they stand.  Is #1 and #2 above
basically correct?

> > This is possible by replacing evnt_multi() with a new, more flexible API
> > allowing event_multi() to continue to work as before.  This would be 
> > of great
> > benefit for a number of applications outside the scope and purpose 
> > of WCOWORK,
> > such as the ability to add new message types like the KEY_UP and 
> > KEY_DOWN that
> > was discussed before, and possibly IO events when we get that afar.
>
>  You now have two event points. And this is not adding complexity?

Two event points?  How do you mean?  I don't want to get into a big 
argument on
this one, but I do still see some advantages to providing a more flexible
evnt_multi() that can handle more event types than the current, especially if
it doesn't require passing so many arguments every time its called.   I 
suppose
I'll just wait for kqueue()!

> > deal of thought into how to get all the best features of COM/DCOM and CORBA
> > without nearly the amount of code complexity and bloat.  I've spent years
> > looking looking into solutions before finalizing the details of my plans.  I
>
>  Do you have any documents describing your plans? I would be interested,
> honestly.

Mostly just stacks and stacks of notebooks.  No document would ever be up to
date or complete.  Anything that hits the PC tends to change quite erradically
as I've only recently begun actual coding now that I finally found the data
structures I want to use to be acceptable in size and performance.   I have a
tendency to over-design and over-analyze and attempt to optimize before the
code gets written - all very bad habits.   Basically the component/object
system is part of a programming language that is highly experimental with some
somewhat odd and bizarre features, but everything is callable from C too, and
this is the point that tends to change often as I really don't like the
interfaces and speed tradeoffs made in argument passing, but this is 
one of the
important concerns that makes the system possible at all.

Basically its all building blocks with the focus on polymorphism and
interchangability of component objects.  Interface objects are also separated
from the data they are meant to display, allowing changing the view without
changing the data, and also allowing multiple views of the same data.  Change
notification signals allow all views to update at once.  Getting it all 
to work
and be A - Scalable, B - Efficient, C - Safe (so everything doesn't crash
together), is why I have more notebooks than you can imagine.

Anyway - before I ramble on, once I have something showable, I'll let 
you know.

> > 1 - A way for MiNT to load plugins, even if they are just LDG plugins,
> > having a
> > real API for this instead of a cookie would quite helpful.

>  This is out of scope from the work I was doing. WCOWORK would have
> helped here, I'm sure, but the above are things not really concerning
> the AES kernel.

Ah yes .. plugin system with name spaces is a wish-item for MiNT, not an AES
item.  I think it will make dynamic loaded plugins (like zview codecs for
example) easier to deal with since a program can pick a category of codecs and
assume they all behave the same way, so you will know if you can use 
them, even
if they were written after the application.   Since its controlled by 
the kernel
sharing and MP issues can be dealt with.  May look into hacking this into the
/SHM driver myself some day.

I'd also like to see Howard Chu's point about relinkable libs instead 
of dynamic
libs, as used on AIX.  Maybe someone that knows more about the executable
formats and symbol tables will look into this, or at least I hope, since I
REALLY like this idea.  Its odd that I was wondering if it was possible to do
just the day before Howard mentioned it.  Glad he was around to point 
that out.

> > 2 - A multi-line editor buffer GEM object just like the single line one
> > but with
> > some extra editing capability.  I know you'd rather embed a full application
> > like QED for this, but you could also simply make it a plugin that
> > XaAES itself

>  Yes, agreed here. I dont think my IPW should be used by the AES kernel.
> The reason for this I think that would create security holes big enough.
> A plugin or something trusted by the OS (loaded at boottime) is the best
> solution here.

> > 3 - A "canvas" widget.  Basically a GEM object like any other, 
> > except that you
> > can give it VDI calls which should be relative to the object itself and not
> > based on screen coordinates.  There should be an explicit "clear" to 
> > empty the

>  I'm not sure I understood this.

A canvas widget ... Instead of writing VDI calls to a window, you give them to
the canvas, and the canvas stores them all and takes care of redraws and all
that.  Its just for code reuse and making the programmers job easier.  It has
no extra features of its own, but lots of graphics systems use similar 
widgets.

> > based on the work area, but that requires VDI support - and I think Klockars
> > may actually add that in a such a way that you simply take the X + Y 
> > from the
> > WORK area when the window is moved or changed coordinates and set the
> > origin in
> > the VDI, then you only need to worry about the w + h of your work area.  The
> > area of user drawing would be from (0,0) to (w,h).   SWEET!
>
>  Yes. I thought WCOWORK would be very nice related to such things.

This is definately something that would help a great deal.  I think he 
mentioned
it would just be adding 1 VDI call.  It would make lots of things much simpler
and cleaner!

>  You're right, I dont. WCOWORK is not needed in your sceme. The ONLY
> benefit WCOWORK has in a mixed API is less complexity for application
> authors. It cannot be used for features I thought it would unlock then.

Depending on if you can trust the application and when and under what 
terms you
can trust it, seems to be where we had the issues, and not any particular
fundamental benefit or disadvantage that would be different between the
approaches if all programs were well written.

>  You have XaAES sources at hand. Start working.

I have more than enough to do!  Thanks!