Rur-ple: time to drop the browser?

After spending some time writing my python tutorial included with rur-ple in html+css, I have started getting even more annoyed with the simple html browser included with wxPython. I am thinking of dropping it altogether (or perhaps only use it to display some introductory message) and require the use of a standard browser to read the lessons in a separate window. While I have written a simple program that does the html+css -> simple html conversion, it is rather tedious to have to do this, lesson by lesson, every time I update a lesson. Of course, I could change it to process files in batch I suppose, but I'm not sure it's worth the effort.

This would have the added benefits that 1) I could do separate releases for the lessons and the main app, and 2) I could start adding "fancy css tricks" to make the lessons even more visually interesting.

In addition to dropping the browser, I have had to modify the "python editor" window so that programs are not run from it using "exec", as I found out that one cannot make use of "raw_input()" in code that's run by exec or other family members. I have had to embed a second python shell and programs are now run via an import/reload done at the push of a button. I looked briefly at how Idle runs programs, but it was rather convoluted and didn't seem worth the effort to implement. Perhaps someone reading this will have a better idea... [I have not looked yet at the possibility of using popen(), which I have never used, but is apparently used by Makebot; Makebot seems to be doing exactly what I would like to do.].

I'm almost ready for a new release (0.9.5?) of rur-ple, which should now work under MacOS (as well as Windows and Linux). The new release should include about 40 lessons; 10 more lessons or so and it will be finally release 1.0; next will be an introduction to designing games with Pygames!

Reading about browsers, I found out that 20% of users still use screen sizes of 800x600 only. Rur-ple's interface has grown so that it currently needs at least 900x700 for sub-windows to be displayed in a large enough size to be fully useful. One solution might be to reduce the button sizes; however I am afraid that they would become too small at much larger screen sizes. Of course, a way out would be to have multiple image sizes for the buttons, depending on the screen size ... but that somehow seems excessive. I wonder what Joel would think of this.