GSoC Idea: Cross Platform Native GUI

[Shadab Zafar]

I saw this idea mentioned in the previous year's idea list, but no one picked
it up. So I was wondering if people still want to get this done.

I am interested in the project as I have some experience with Qt and part of
my previous GSoC project was modifiying a PyQt based application.

I looked around for available sage frontends and apart from the sage-notebook,
the only working thing I found is KDE Cantor among other proof of concepts
like Guru and Lorien Labs.

I really liked Guru's concept (and how it differs from the existing things) -
"No user accounts, no data stored in the cloud, just .sws files on the user's
local machine."

But considering that sage notebook has a lot of features, would it be
worthwile to work on another frontend?

---

2014 Ideas: https://docs.google.com/document/d/15v7lXZR1U4H2pT21d2fyPduYGb74JAFjkXJ6CWYmYfw/pub

Guru: https://github.com/rljacobson/Guru

Lorien Labs: http://sourceforge.net/projects/lorienlabs

---

About me:

I am a 3rd year Computer Engineering student from Jamia Millia Islamia, India.
I found out about sage while searcing for 'S-boxes in python' and have
understood a lot of concepts by reading the code (mostly crypto.mq.sbox module.)

I have an academic interest in Cryptography and Security and am currently
working on creating improved sboxes.

Github Profile: https://github.com/dufferzafar/

[Vincent Delecroix]

Hello,

Thanks for your interest in Sage. That might be a good idea to have a
native GUI for Sage. If it is possible to adapt Sage kernel to various
frontends it is a proof that it is robust. Note also that we do not
have yet a list of projects for GSoC 2015.

And as I discussed recently in Bordeaux, the notebook mode is not very
clean since you can execute commands in any order. An other idea might
be to have a new mode for the IPython notebook that would oblige the
execution of commands from top to bottom. That would allow much more
reproducible computations.

Considering the GUI, you should also have a look at spyder:
https://code.google.com/p/spyderlib/
which is an interactive Python environment. It is very much used in
scientific community. And moreover programmed in PyQt.

> "No user accounts, no data stored in the cloud, just .sws files on the
> user's
> local machine."

.sws might not be the best way to store data.

> But considering that sage notebook has a lot of features, would it be
> worthwile to work on another frontend?

You might want 3d-graphics to be faster and have some interactions
(like interactive editing of graphs drawings). In the notebook, it
would be a much harder task than in a native GUI.

Best
Vincent

[Nathann Cohen]

> You might want 3d-graphics to be faster and have some interactions
> (like interactive editing of graphs drawings). In the notebook, it
> would be a much harder task than in a native GUI.

There is quite a lot of things you can do with javascript, though.

Nathann

[Volker Braun]

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. 

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.

[William Stein]

On Sun, Feb 1, 2015 at 7:00 AM, Volker Braun <vbrau...@gmail.com> 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

[Volker Braun]

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..

[William Stein]

On Sun, Feb 1, 2015 at 7:55 AM, Volker Braun <vbrau...@gmail.com> wrote:
> 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.

Is GTK "cross platform"? That's a core requirement...

http://stackoverflow.com/questions/14079909/is-gtk-3-x-a-real-cross-platform-solution

I would say that very good Windows support for a GUI would be a bare
minimum requirement. Even if Sage doesn't run natively under MS
Windows, a GUI could, with the Sage process running in a VM and
communication over a local network connection (or a remote cloud
service like with the native Sage android/iphone apps).

>
> 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.

You're right that this is an important problem, but I'm not convinced
that *every* UI does it as an afterthought. This is the first thing
both IPython and SageMathCloud already do very much not as an
afterthought -- they make it so Python is called as a library
asynchronously in a separate process. For example, that's what this
code [1] does for SMC, and it's kind of the main point of the
ZMQ-based architecture of IPython to solve this problem (which was key
in them moving forward past their command-line only UI years ago).

> 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..

Totally agree. With SMC 3d plotting, I just wrote everything
completely outside the sage library [2] and 100% ignore anything
involving sagenb directly in the library.

[1] https://github.com/sagemath/cloud/blob/master/sage_server.py
[2] https://github.com/sagemath/cloud/blob/master/graphics.py

> --
> 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+...@googlegroups.com.
> To post to this group, send email to sage-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.

[Volker Braun]

On Sunday, February 1, 2015 at 11:07:19 AM UTC-5, William wrote:

Is GTK "cross platform"?  That's a core requirement...

IMHO yes. Gtk 2 is pretty complete, Gtk 3 might need some more love on lesser platforms (Windows) but since the stackoverflow question you linked to there is now an official Windows binary etc. But, really, the View part is just a small piece of what a GUI has to do and could reasonably be implemented natively on other platforms later. Assuming that the whole architecture is sane, of course.

You're right that this is an important problem, but I'm not convinced
that *every* UI does it as an afterthought.   This is the first thing
both IPython and SageMathCloud already do very much not as an
afterthought -- they make it so Python is called as a library
asynchronously in a separate process.

IPython can't even capture stderr / stdout from the child process: https://github.com/ipython/ipython/issues/1230

[William Stein]

On Sun, Feb 1, 2015 at 8:13 AM, Volker Braun <vbrau...@gmail.com> wrote:
> On Sunday, February 1, 2015 at 11:07:19 AM UTC-5, William wrote:
>>
>> Is GTK "cross platform"? That's a core requirement...
>
>
> IMHO yes. Gtk 2 is pretty complete, Gtk 3 might need some more love on
> lesser platforms (Windows) but since the stackoverflow question you linked
> to there is now an official Windows binary etc. But, really, the View part
> is just a small piece of what a GUI has to do and could reasonably be
> implemented natively on other platforms later. Assuming that the whole
> architecture is sane, of course.

Thanks for the clarification and update; that said, I personally
wouldn't suggest that a person start with a graphical toolkit that
doesn't even support native rendering on a critical target platform.

>
>> You're right that this is an important problem, but I'm not convinced
>> that *every* UI does it as an afterthought. This is the first thing
>> both IPython and SageMathCloud already do very much not as an
>> afterthought -- they make it so Python is called as a library
>> asynchronously in a separate process.
>
>
> IPython can't even capture stderr / stdout from the child process:
> https://github.com/ipython/ipython/issues/1230

It would be worth taking that his rather than trying to reinvent
something from scratch that does the same thing. This is not a huge
problem in practice: data point -- I think SMC worksheets have
precisely the same issue (despite not using IPython at all), and I've
not once received a question or complaint about it in 2 years. And
9,347 people (=distinct browsers) used SageMathCloud last week, with a
bounce rate of 2.24%. That doesn't make it a non-issue, but one has
to chose priorities carefully to win at this game, where the game is
to create things of value for the world.

-- William

[Volker Braun]

On Sunday, February 1, 2015 at 11:48:14 AM UTC-5, William wrote:

problem in practice: data point -- I think SMC worksheets have
precisely the same issue (despite not using IPython at all), and I've
not once received a question or complaint about it in 2 years.  

IMHO thats the difference between a teaching tool and a serious programming environment. Maybe not many need the latter, but I do.

[Shadab Zafar]

I hadn't heard of spyder before Vincent mentioned it so I looked into it and it seemed quite impressing.

It runs on all platforms (including Windows), supports both Python 2.7 and 3 and is actively being developed.

Spyder is quite modular in that every part of the UI is created as a separate plugin (importable Python module), and while going through the existing plugins codebase, I felt that integrating sage console wouldn't be too hard.

There's also support for remote ipython kernels, so for people who don't have sage installed (like Windows users), support for interaction with remote sage server (sagecell?) could be added.

I also happened upon this sypder issue (created in 2011) which wished for sage console integration but was tagged wontfix as spyder's team felt it was out of their scope. So I guess doing this would make some people happy.

Would integrating sage into spyder make sense as a project?