[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] some gem question



Hi Philipp,

> Why doesn't anyone propose an "object oriented" approach? I learned this
approach with the introduction of WDIALOG. But as many people in 
> the community hate anything related to it... (Probably only because the
wdialog routines don't belong into system space but into a user
> space library.)

> Here how it works:
> One "main event loop" dispatches the handling of events to the appropriate
"object handler": menu bar handler, window handler (which can
> be different for each window), dialog handler, fileselector handler,
font-dialog handler, ...
> Depending on the type of the event different "handler" get the chance to
process the event.
> I used this approach in all of my GEM applications (MagiC- Configurator,
ArcView, HypView). Sadly I didn't yet finish the transition to
> "non WDIALOG AES".
> As much as I saw in other public sources (GTK, GLUT, ...) it's rather
common to have one main event loop which coordinates the system.

You only wrote this because you perhaps never had a look on WinDom design?
:)

> IMO this is a better approach than introducing a thread for each dialog.

I would not say better but far easier for a common fellow to implement.

> BTW I thought it is still not possible on MiNT systems to create AES
threads
> (because MiNT does the process/thread handling on GEMDOS level and
therefore incompatible to the AES threads MagiC provides).
> Or am I wrong?

No non-magic-AES seems to be getting this feature in the near future.

On the other hand you should be able to use fork() with gemlib (and WinDom
soon) in FreeMiNT.
It is all about the context isolation and no static variables used in those.

Best Regards

STanda