Re: [MiNT] XaAES and objc_xedit

["Standa Opichal" <opichals@seznam.cz>]

Hi!

> > Comments?
> 
> I am currently working on objc_data() function calls whose intention is
> to hide the object tree from user programs. I found out that in order to
> support decent editing, we may as well create a standard API for
> application to use, and leave the object structures to the AES. This
> will enable us to do enhancement to the AES objects without having to
> worry about application modifying the objects without the AES knowing
> it. I have changed CF-lib to support this when available, and the
> current available modes works like a charm with Qed and TosWin2 .. but
> since this work is not finished its not into the cvs yet. 

Makes sense, however very few apps would ever use it. Buy yeah, it should
have been there from the very beginning and the OBJECT specification should
have never been published. Almost every application uses that directly
however in today's GEM world...

> What this has to do with objc_edit? Well, i think that decent editing in
> AES objects wont be possible without extended information in TEDINFO
> structure for example. But just adding and maintaining such info about 
> objects is next to impossible due to the fact that apps can modify the
> trees in all directions without the AES knowing it. I want to change
> that.

Nice goal... ambitious indeed. :) Once I have the API for editting of the
OBJECT tree I would probably use it if appropriate.

>  But until this is a reality, i think you should solve your problem by
> using objc_wedit()... if I aint missing something vital :)

I cannot use AES window handle. I don't have one. Until there is the above
mentioned change in AES I would just not care about that. We all have
enough time... nothing goes to production in FreeMiNT world any time soon
;)))

>  Btw, have a look at http://ae.dhs.nu/xaaes/snap_32b.png for a preview
> of the window/object renders progress. This will be extremely
> configurable. In relation to this, I would encourage everyone to NOT,
> NOT, NOT use progdef's to draw AES objects, as those will destroy
> themes!

Looks nice. Yes, it would make sense to leave the whole theme thing to the
AES
once there is one :)

STanda


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________