Re: [MiNT] WCOWORK Alternatives - long post warning

[Odd Skancke <ozk@atari.org>]

ons, 13,.07.2005 kl. 20.10 -0500, skrev Evan Langlois:
> On Thu, 2005-07-14 at 00:14 +0200, Ingo Schmidt wrote:
> > Ok, what do you propose? What features do you want?
> 
> Expandability!   Possibility of a work-area-origin drawing system in the
> future without another damn mode!   If we are gonna move forward, I want
> to go all the way and allow LOTS of features.

 This is what we all want, I think.

> 
> > What are your suggestions for improvements in a new AES? How would you
> > change the window API in an AES so that programming it would be
> > easier? Lets hear your proposals!
> 
> Let me jump in and make my own suggestions.  This is just a rough
> outline off the top of my head based on what people have been saying on
> the strengths and benefits of WCOWORK, and the need for a more modeless
> operation, and my own wants for something that can be expanded however
> we need it.  Feedback welcome as its taken me a couple hours to write!

 We need the two modes, if transition is to be smooth and not exclude
all existing applications.

> 
> First, I do understand that there can be problems with wind_calc().
> However, as long as it used sparingly and the results are not remembered
> by the application, then the call should work properly even during a
> theme change.  The speed should be fine as long as the AES keeps the
> values precalculated for each theme.  I would however still want to have
> the newer W2F and F2W wind_xget() calls for completeness, and they
> should be used when a window handle is available.

 For old applications, nothing changes. The problem with old apps is
that they precalc the geometrics of its windows, and theme changes can
not affect non-WCOWORK applications because of that. Altho many apps do
this correctly, there is no way for the AES to know.

> 
> Second, don't change existing calls, but add new ones.  Don't make
> WF_CURRXYWH work any different.  For wind_create and stuff, if you want
> a version that works with working areas instead of full areas, lets make
> a new call.  This may help prevent confusion.

 WF_CURRWYWY wont change. No matter if AES is in WCOWORK mode or not, if
you set CURRent coordinates, CURRent coordinates it is :-) I would not
object if the name was WF_BORDERXYWH.

> 
> Third, don't implement "modes".  I have a feeling that operating modes
> may be problematic, and might contribute to development problems that we
> haven't yet forseen.

 I dont think so. This is the only way to make a smooth transition. I'm
all ears if anyone have other ideas, tho.

> 
> Next, to keep everyone happy about how the AES messages are handled,
> lets not change how messages are received by evnt_multi().  All AES
> messages stay the same.  Anything new that wants a different coordinate
> system should have its coordinates modified by the AES at queue
> insertion time.

 Exactly!

> 
> I find it really difficult to believe that there would be many
> circumstances where the event sent from one application to another would
> be different for full or working coordinates.  Applications don't tend
> to move each other around or resize each other.  Redraws and things of
> that sort are more common, and that doesn't change the coordinates
> returned, so it should be quite possible to have the AES do any
> FULL->WORK coordinate conversion as the message is added to the
> application's queue.

 This is true. And considering WM_REDRAW messages already only contains
WORK area coordinates (as stated by Atari's docs), there is no problem.

> 
> Instead of a mode, lets have a new call for processing the event queue.
> This would obviously be for new XaAES applications (and anyone else that
> implements the new calls) and aren't worried about compatibility with
> unsupported operating systems.  The goal is to make the capabilities
> offered be beneficial enough to the developer that they would consider
> the use for new programs.

 A new event mount-point? No, that would complicate things. Altho when
the kernel gets kqueue()/keven() functionality, that will be implemented
as soon as possible. The idea of WCOWORK is to allow apps to be unaware
of its window's surroundings. No need to change more that necessary.
however, if you have a decent implementation idea, please let me know.
Keep in mind that applications should be able to use WCOWORK when
available as painless as possible.

> 
> However, while a kernel level implementation of the proposed API would
> be most efficient, its assumed that the following represents the
> user-level C API and it does not have to have a perfect mapping to
....


 Very much what I have in mind, but its gonna take time. Besides, for a
decent event handling system, the kernel must have kqueue()/kevent()
functionality. Hopefully, this is not too far away ,-))


 Odd Skancke