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.

Reply via email to