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

RE: MysterX Message Loop?




>> Anyway, I get the general idea, I'll work something out. But doesn't
this
>> seem wrong? Don't you think
>> you should be able to run a MysterX app just as you can a MrEd
app--create
>> a window and automatically
>> get a message loop running?

> I think what you're asking that MrEd not shut down as long as there's
> a MysterX browser running.  In order for that to happen, either 1) MrEd
would
> have to have special knowledge of Mysterx, which is not desirable, or
> 2) MrEd would need some mechanism that MysterX could use to notify MrEd
> that there's an active browser.  Actually, Windows does something like
this:
> When it wants to shutdown, it asks all clients whether that's OK; if any
> refuse, Windows stays running.  Something to think about ...

You're thinking about the problem differently than I am. The pdf on MysterX
points out that in some ways MysterX is superior to MrEd. If you follow
that line of thinking, creating a user interface with MysterX should be
similar to creating one with MrEd. So... why does MysterX actually force
its windows to be created in a separate thread? Why not create them in the
main thread unless the user specifies otherwise, just as MrEd does?

There may be a technical reason behind the decision, but maybe not. You
pointed out that you always launch the demo from the REPL, and that seems
natural to you; I'm thinking in terms of double-clickable apps, and that
seems natural to me. Different premises, different conclusions.

ps: Presumably MrEd already has a concept similar to your "I'm alive" idea,
because it doesn't shutdown until the last window is gone. Something may
need to change to expose that, but the concept seems to already exist
somewhere. Ah... but that still presupposes that MysterX launches in the
main thread!