Since all the existing fractint "dialogs" are just colored text screens like this, it makes sense to continue emulating this in a wxWidgets control until the dialogs are replaced with modern dialogs.

I agree with your 'continue emulating' on this. I feel that the modern dialogs should wait until a later time to be implemented. - Enough changes are already going on right now. - Users will be comfortable seeing the 'same' interface.

I am experimenting with inverting the control from polling to event-driven right now -- that will be the telling factor.

Good luck! I agree with Tim -- who said that that sounds like a non-trivial challenge. - Hal Lane ######################### # hallane@earthlink.net <mailto:hallane@earthlink.net> # #########################

-----Original Message----- From: fractdev-bounces+hallane=earthlink.net@mailman.xmission.com [mailto:fractdev-bounces+hallane=earthlink.net@mailman.xmission.com]On Behalf Of Richard Sent: Tuesday, June 12, 2007 11:53 AM To: Fractint developer's list Subject: Re: [Fractdev] <Richard>Do CGA color text screens support enoughcolors to reproduce...

In article <MDBBJLBFBICIIEIHFBMEGEKMDBAA.hallane@earthlink.net>, "Hal Lane" <hallane@earthlink.net> writes:

...

...

The near term will probably be a wxWidget control that implements a CGA color text screen.

Do CGA color text screens support enough colors to reproduce all the highlighting, underlining, etc. and text colors currently in Fractint? <---<<

Yes, that is what you see now in the text screens in FractInt. FractInt for Windows just emulates the colors available by drawing colored text in a window. (Actually you can edit the colors to be anything you want :-), but I don't know that anyone actually does this because it seems that the colors aren't stored for your next run.)

Since all the existing fractint "dialogs" are just colored text screens like this, it makes sense to continue emulating this in a wxWidgets control until the dialogs are replaced with modern dialogs.

On the other hand, it may be more trouble than its worth.

I am experimenting with inverting the control from polling to event-driven right now -- that will be the telling factor. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html>

Legalize Adulthood! <http://blogs.xmission.com/legalize/>

_______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev

Richard said:

I have a plan for how to do the refactoring. Its a matter of changing the structure of each input screen. For places where computing fractals check for input to abort computation its a little harder. The input screens are easier. Once all the input screens are changed, then I'll look at changing the computation "was a key pressed" checks. Once everything is refactored, then a single event loop can be put in place and then a move to wxWidgets can be made.

A man with a plan! Great! - Hal Lane ######################### # hallane@earthlink.net <mailto:hallane@earthlink.net> # #########################

In article <466DC9D3.28768.F844A4@twegner.swbell.net>, "Tim Wegner" <twegner@swbell.net> writes:

...

First I need to invert the control loop for the I/O from polling to event driven using the existing driver model. Woo hoo.

That does sound challenging :-)

I just thought of an analogy while I was rototilling some garden space. Its similar to the idea that any recursive computation has an equivalent iterative computation. The compute "check for key pressed to stop" loops look like this: while (1) { if (key pressed) { if (escape) { break; } pause computation; while (! key pressed) { wait; } resume computation; } perform computation; } This is equivalent to: bool paused = false; bool done = false; while (!done) { if (key pressed) { handle_key(); } else if (idle) { do_idle_work(); } } do_idle_work() { if (paused) { return; } perform computation; } handle_key() { if (escape) { done = true; } else { paused = !paused; if (paused) { pause computation; } else { resume computation; } } } This involves a restructuring of the existing code by extracting functions (methods) from the existing functions and rearranging how they are called. However, take a look at the first while loop. This is the structure of every event driven application -- it gets events, dispatches them to handlers and if there are no events it does something with the idle time. The "done" flag is eventually set by the user clicking on the close button or selecting File / Exit from a menu. In FractInt, the trigger just happens to be the ESCAPE key instead, but its the same idea. In FractInt, you're "idle" whenever a key isn't pressed. This is why the existing mouse support fakes mouse movement as key presses -- everything is tied to the keyboard. The thing is that this key dispatching code loop is duplicated everywhere in FractInt. Duplicated code is bad. Once the existing processing loops are restructured to look like the event loops in the second code snippet, then the duplication can be eliminated by using a stack of interface pointers. The interface looks something like this: interface IKeyDispatcher { void handle_key_press(int key); void idle_work(); } Then all the duplicated dispatch loops can be collapsed into a single loop with a stack of interface pointers. When you go into a text screen, that amounts to pushing an interface onto the stack. The single event dispatching loop calls through the interface on the top of the stack to dispatch events. When you ESCape from a text screen back to the previous context, it pops its handler off the stack when processing the ESCape key. When you switch contexts you just change the current interface pointer on the top of the stack, such as when you change fractal types and the engine gets switched from standard_fractal() to cellular(). Once you're in a situation like that, then *everything* is dispatching events through a single location and you're ready to swap out your homebrew event dispatcher for the event handling mechanism in wxWidgets. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>