I wrote a basic Python + GTK Gui a while ago https://github.com/vbraun/notebook. IMHO Gtk is more suitable because Python is a first-class supported language, whereas Qt is C++ with a handful of competing Python bindings of various levels of incompleteness. But that isn't even relevent at this point.
What I took away from the exercise is that we first should write a reliable way to call Sage as a library. And asyncronously, in a separate process/container/vm, with support for interactive widgets. With a documented and stable protocol, and ideally client libraries in more than one language. This is really the basis of a GUI and we need a good solution there first before we should think about writing another GUI. Right now every UI does that as an afterthought and in various sucky ways. Part of it is that graphics (in particular 3d plots) are a mess with various SageNB crap hardcoded in the Sage library, which is what I'm trying to address at #17234 in my negative spare time.. On Sunday, February 1, 2015 at 10:40:10 AM UTC-5, William wrote: > > On Sun, Feb 1, 2015 at 7:00 AM, Volker Braun <vbrau...@gmail.com > <javascript:>> wrote: > > IMHO that is out of scope for a GSoC project. Maybe somebody with a lot > of > > experience could do it, but a sound MVC framework with robust test > coverage > > is IMHO going to take more effort. Sure, you can slap together a GUI, > but > > that'll just be another me-too notebook that'll soon be as > unmaintainable as > > SageNB. > > +1 > > > Having said that, if you are going to write a proposal that covers > details > > like, say, unlimited undo/redo and testing in a believable way then I'm > sure > > we would pick it up. > > If there were already a good Python (or IPython) Cross Platform Native > GUI (is there?), then a viable project would be to take it and make it > actually useful for Sage too. You should: > > - find all existing "open source Python (or IPython) Cross Platform > Native GUI's": > - what's their current status? > - how widely used are they > - how's the code quality > - etc. > > Such a list would include IDLE [1]. > > Then take the best existing one, and if it **doesn't totally suck**, > make a plan to extend it to make it useful for Sage. > If there is nothing like the above, after 20 years of Python (and 10+? > years of IPython), with millions of users, then you're probably not > going to write something better for Sage="Python+a massively > complicated library" in 2 months. Or, if you could, then you should > do it for millions of Python users first, not just for Sage. > > (Aside: I agree with Nathann's skepticism about this statement: "In > the notebook, it would be a much harder task than in a native GUI." > Good cross platform native GUI's are also very, very hard to write...) > > William > > [1] http://en.wikipedia.org/wiki/IDLE_%28Python%29 > > -- > William Stein > Professor of Mathematics > University of Washington > http://wstein.org > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.