Discussion:
[sage-devel] GSoC Idea: Cross Platform Native GUI
Shadab Zafar
2015-02-01 05:52:10 UTC
Permalink
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/
--
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.
Vincent Delecroix
2015-02-01 09:55:50 UTC
Permalink
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.
Post by Shadab Zafar
"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.
Post by Shadab Zafar
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
--
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.
Nathann Cohen
2015-02-01 10:34:10 UTC
Permalink
Post by Vincent Delecroix
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
--
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
2015-02-01 15:00:22 UTC
Permalink
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.
Post by 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?
---
https://docs.google.com/document/d/15v7lXZR1U4H2pT21d2fyPduYGb74JAFjkXJ6CWYmYfw/pub
Guru: https://github.com/rljacobson/Guru
Lorien Labs: http://sourceforge.net/projects/lorienlabs
---
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/
--
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.
William Stein
2015-02-01 15:39:28 UTC
Permalink
Post by 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.
+1
Post by Volker Braun
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+***@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
2015-02-01 15:55:21 UTC
Permalink
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..
Post by Volker Braun
Post by Volker Braun
IMHO that is out of scope for a GSoC project. Maybe somebody with a lot
of
Post by Volker Braun
experience could do it, but a sound MVC framework with robust test
coverage
Post by Volker Braun
is IMHO going to take more effort. Sure, you can slap together a GUI,
but
Post by Volker Braun
that'll just be another me-too notebook that'll soon be as
unmaintainable as
Post by Volker Braun
SageNB.
+1
Post by Volker Braun
Having said that, if you are going to write a proposal that covers
details
Post by Volker Braun
like, say, unlimited undo/redo and testing in a believable way then I'm
sure
Post by Volker Braun
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
- find all existing "open source Python (or IPython) Cross Platform
- 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+***@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.
William Stein
2015-02-01 16:06:37 UTC
Permalink
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
Post by William Stein
Post by 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.
+1
Post by Volker Braun
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
- find all existing "open source Python (or IPython) Cross Platform
- 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
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
--
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+***@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
2015-02-01 16:13:20 UTC
Permalink
Post by William Stein
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
Post by William Stein
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
--
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.
William Stein
2015-02-01 16:47:32 UTC
Permalink
Post by Volker Braun
Post by William Stein
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.
Post by Volker Braun
Post by William Stein
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.
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
Post by Volker Braun
--
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
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
--
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+***@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
2015-02-01 16:54:22 UTC
Permalink
Post by William Stein
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.
--
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.
Shadab Zafar
2015-02-03 17:06:45 UTC
Permalink
I hadn't heard of spyder <https://code.google.com/p/spyderlib/> 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
<https://bitbucket.org/spyder-ide/spyderlib/src/46ad228e4fad/spyderlib/plugins/?at=default>,
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
<https://code.google.com/p/spyderlib/issues/detail?id=851> (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?
Post by Volker Braun
Post by Volker Braun
IMHO that is out of scope for a GSoC project. Maybe somebody with a lot
of
Post by Volker Braun
experience could do it, but a sound MVC framework with robust test
coverage
Post by Volker Braun
is IMHO going to take more effort. Sure, you can slap together a GUI,
but
Post by Volker Braun
that'll just be another me-too notebook that'll soon be as
unmaintainable as
Post by Volker Braun
SageNB.
+1
Post by Volker Braun
Having said that, if you are going to write a proposal that covers
details
Post by Volker Braun
like, say, unlimited undo/redo and testing in a believable way then I'm
sure
Post by Volker Braun
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
- find all existing "open source Python (or IPython) Cross Platform
- 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+***@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.
Continue reading on narkive:
Loading...