On Aug 22, 6:18 pm, David Philp <[EMAIL PROTECTED]> wrote: > The weakness of this approach is that sage is running the main > application loop. I.e. if f.derivative() takes its time, then there's > a spinning beachball. I assume the big M's overcome this by > separating their GUIs from their kernels. > > The big strength is much the same. Because sage is running the main > application loop, you don't have to think about message passing of any > sort. It should be easy enough to subclass NSView or something to > display plots. Etc. > > If anyone's interested in kicking around ideas or explaining why this > is a dumb idea, please go for it. If you want the boilerplate code > you are welcome, but it was mostly hard hacks to get things working, > and is utterly specific to my system.
Here's a suggestion to (possibly) make it even better. IPython (the package that Sage uses to handle the "sage: " prompt) has support for running the sage: prompt concurrently with GUI application loops. If you could get this to work with Cocoa, then you could probably pop up new GUI windows from the sage: prompt and keep typing at the sage: prompt while the window is up. (It does this by starting a new Python thread to run readline; then once a command is entered, it is sent over to the main thread to execute. The main thread runs the GUI loop, but periodically polls for new commands (using a timer).) There's about 100 lines of platform-specific code in IPython for each GUI library that it currently supports (GTK, wxWidgets, QT3, QT4) to make all this happen; you could try to figure out the corresponding 100 lines of code for Cocoa and submit it to IPython. Carl --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
