Re: [MiNT] usage of wind_calc()

[evan@coolrunningconcepts.com]

Quoting Odd Skancke <ozk@atari.org>:

>  Sorry if you dont like it. This new model is here to stay, just thought
> you'd have some constructive views instead of "will break compaibility"
> panics.

I'd like to say that I'm not totally against the new mode.  I would like to
encourge more discussion though before its set in stone.  If such a change is
introduced, its a good excuse to insert any other changes we may need that
weren't executed due to compatibility reasons.   Once this option is turned
all, we don't have to worry about "Old Apps".  A clean slate it a good thing,
provided the slate is really clean.  Lets not leave anything out.

>  Yes, if we accept that one application never ever in the future can
> deal with more than one theme (or even window-type). I dont accept that,
> hence WCOWORK.

I don't think an application should ever have multiple windows open with
different themes.   That doesn't seem like a good user interface idea.   Being
able to cope with it if the user wants to do it is certainly fine.

Have you considered allowing themes to have different window widgets 
entirely -
meaning not just the look of the widget, but the function.  So, a theme could
be designed that has the "window shade" widget, double clicking the title bar
could act differently, or a theme could have a drop-down menu for a list of
possible actions.

You'd define what the widget looks like (TBD), and then what "action" 
to assign
to each event, such as click, doubleclick, drag, or maybe even mousein, and
mouseout.  An "action" of "menu" gives a menu of actions.  The theme should be
defined by the system as whole, but having it possible for an application to
set its own theme might be nice as well.

Anyway ... getting to the point now - one of the actions can be "Change 
theme".
For older applications that aren't using the new WCOWORK mode, this option
should be ineffective when assigned to a widget, and should be greyed out in
menus.

> > > This work is
> > > experimental, and far from perfect, but I seriously think this is the
> > > route to take,
> >
> > i do not...
>
>  I do.

The main problem I see with wind_calc is that it encourages the application to
care about window geometry.  Its like a web page that lays everything out in
pixel coordinates.  Works fine until you try to view it on some other device.
The less dependant you are on details, the better.

> are handled here, except from cases where the application needs to
> modify the new positions. For example snap this is what is needed now;

That brings me to the next issue.  Snapping window interiors to 8 or 16 pixel
boundaries isn't going to make things faster when operating in certain 
graphics
modes or certain graphics cards.  For example, a 256 color system using a
non-planar, packed-pixel mode might be sped up slightly on a 16 bit system by
aligning to even pixel boundaries, but on 32 bit systems may require a 4 pixel
boundary.

I suppose you could always align on 16 pixel boundaries, but I think it 
would be
best if you specify that applications should not set this information 
themself.
The AES should do it by modifying the message to the application.  Some people
could set very chunky alignment if they wanted to make it easier to line up
windows should they want them neatly arranged.  This makes applications
simpler, removed redundant code and helps make application behavior more
consistent.

>  1. new_pos = WM_MOVED coordinates
>  2. snap(new_pos)
>  3. wind_set(handle, WF_CURRXYWH, new_pos)

In the non-WCOWORK mode, you can't have the AES snap positions since you never
know if the application will try to do this adjustment itself.   Let 
the AES do
it, and the above becomes just 2 steps!   Considerably less than 5.

>  Now, there are cases where the FULL extent of a window is needed by the
> application. However, this is more like a 'special' case, and only used

Assuming the AES takes care of reducing the window coordinates if the user or
application try to make the window larger than the full screen.

>  For applications that need to autoposition windows, there is one change
> only, and that is WORK coordinates need to be translated using
> WF_CALCW2F, modified, translated back using WF_CALCF2W. This is exactly
> the same amount of work as today, except that wind_calc() is replaced by
> wind_xget() calls, so that correct results are guaranteed no matter what
> the window's geometrics at the time of the 'window-position actions'.

Can we let the AES translate these messages?   It would know the mode of the
source and destination and could translate accordingly, and the application
wouldn't have to do anything special.

I would like to propose that WF_CURRXYWH not be changed to the working area,
duplicating WF_WORKXYWH in the WCOWORK mode.

>  I have implemented a cache for this, but with WCOWORK mode it is not
> used because reasons said above.

Indeed, the cache would be wasted memory as any application written for 
WCOWORK
shouldn't be using wind_calc much if at all.

>  Please explain to me why you would need all that to service WM_REDRAW
> messages?

Good question.  I'd like to know too.

>  It is now reliable, and can be used. However, since this is as 'new' as
> the wind_xget(WF_CALCx2x), why not use those instead? Those can
> calculate any WORK<->FULL conversions taking into the toolbar. And those
> two wind_xget() modes does not change behaviour depening on operating
> mode (WCOWORK or not).

since when has wind_get (WF_WORKXYWH) been unreliable?   And why do you 
need it
for redraws?

>  Besides, it would be handy for 3rd kind applications to be able to
> place windows by WORK area too.

I'm wondering what other additions would be useful.  Are you familiar with X's
DAMAGE extension?

>  This is a very good point. How about wind_get(handle, WF_OPTS)?

or let the AES translate.

>  One application can only deal with windows having the same gemotetrics.
> This is a restriction. And it can be removed. Wether or not this is
> usable "right now" is another question.

Again - apps shouldn't have different themes in different windows especially
within the same app - but applications should still be able to deal with it
without error.

>  In WCOWORK mode there is only WORK area to consider by applications. In
> rare situations wind_xget() will get you FULL area.

Is there a difference between wind_get() and wind_xget() ?   I don't quite
understand the difference there.

>  Here we have the reason we never get anywhere in a nutshell. Please
> dont introduce new features, it makes my life hard. Goddamned, I'm tired
> of this.

Well, I think this WCOWORK mode should be application wide, not per-window.
Call it once to say "Hey, I do things the new way", and thats it.  The fact
that Windom doesn't support the new way doesn't seem like a problem to me.

Every other OS in the world has minimum requirements for applications.  Things
like : "This application requires at least a 68020 processor and 4MB of RAM"
seems like its acceptable in the Atari community.   Every other system can say
, "This application need Windows 98 or higher", or "Requires MAC OS X 
10.0.1 or
higher".  If you dump all the cruft for supporting 3 VDIs, a couple different
version of GEMDOS (MiNT or various TOS versions), and 3 different AESs and
countless add-ons and all the code branches and just have 1 release ... how
much smaller and faster will an application be?

"This program requires MiNT/XaAES 1.14 or higher" or whatever.   I'm perfectly
in favor of this, and I'm sure if Windom doesn't support the new XaAES
features, someone will fork it.

>  Well, the only real reason I get from you 'added complexity' supporting
> this in WinDom. So, I think that this is a fight I will be having for
> every new feature I add. Too bad, this situation.

Windom will continue to work in the old mode.  I don't see a problem.

>  I'm tired of being told that 'new' features add complexity. I mean,
> wind_get(WF_WORKXYWH) cannot be used under other AES's, but under XaAES.
> I dont see a complexity-difference wether you use wind_xget() or
> wind_get() here. Either can only be used on XaAES (as of now) anyway!

So wind_xget() isn't the same as wind_get()?  Whats wind_xget?

>  No, it wont. In that case the lib would use WCOWORK mode by default.
> And the application author would know. The lib would be a LOT cleaner,
> because all hacks could be taken out.

Exactly!  I'm all for a unified API instead of the current "test every 
function
before you use it and apply a workaround if its not there or has bugs"
approach.