Re: When will the new GUI be ready?

[Israel Herraiz]

Excerpts from Jordi Gutiérrez Hermoso's message of Mon Oct 29 15:41:18 +0100 
2012:
> It is? Neat. Israel, did you fix the race conditions it had? I'll be
> inspecting your patches later today.

I am not sure the race conditions you refer to :). But I have found
problems with the GUI when compiling in Windows.

For the workspace and the history command list, he timers are started
and re-started from different threads, at least in Windows. This means
that those Windows did not work under Windows. I had to move all the
code starting and re-starting the timers to the same thread (that is,
moving all the code inside the corresponding classes).

When I did that, sometimes (not always) the windows stopped being
refreshed after a while.

To fix that, what I have done is putting a lock to all the "refresh"
code. That means, if there is still an event trying to refresh the
workspace, the current event is ignored or rejected. The problem with
this approach is having a mismatch between the workspace (or the
history command list) and the state in Octave. But as everything is
polled every 500 ms, if something has changed, it will not take long
until the GUI is synchronized. I think Jacob's code was similar to
this, he posted events to the queue, and the events might be rejected
if there were too many events. But for some reason, this did not work
well in Windows.

Also, I changed the workspace model in Qt. Now it is only
updated when the workspace has changed in Octave. The model has been
simplified too. Instead of a tree, my model is just a list of
variables. I don't differentiate between global, local, etc. I just
show the same as the "whos" command does. This makes the model code
much easier.

The truth is that the original GUI in Windows was quite unstable. But
I think it was because it was continuously refreshing the
workspace. Also, the tree workspace model was sometimes trying to read
from null pointers to update the window, which caused segmentation
faults. I don't know exactly why or when. But changing the model to be
plain solved this issue.

With the changes in the workspace model, changing the places
where the timers are touched, and putting a lock around all the
"refresh" code, the GUI is quite stable and requires very little
(negligible?) CPU.

But bear in mind that my code uses the original events queue
programmed by Jacob. I think jwe changed that part of the code some
weeks ago. I have not integrated those changes with my changes,
neither I have tested them. Maybe the GUI is now more stable in
Windows.

Please also note that in my GNU/Linux system (Archlinux), everything
worked like a charm, without touching the original code at all.

> Btw, just by way of comparison, here is a success story for using
> Python for scientific computing and making students install Ubuntu
> instead of trying to get everything to work on Windows:
> 
>     http://hplgit.github.com/edu/uiopy/uiopy.html

Good to know, thanks for the pointer. I have a very constrained
environment though. The labs I have available to teach are all running
Windows, and the truth is that most of my students are previously
Windows users. I provide Ubuntu, Debian and Archlinux packages in any
case. I also provide a GNU/Linux image for VirtualBox for Mac users,
because I have not compiled the GUI in Mac (I could try to gain access
to a Mac in my university, but it is only a minority of users, so it's
not worth the effort).

In previous years, the class was taught using only MATLAB. The sad
truth is that many of the students got cracked licenses from the
Internet to be able to follow the exercises and assignments. Or simply
attempted to follow everything in their spare time in the labs, that
are always overcrowded.

We have around 500 students enrolled in the course, and I only teach
100 of those 500 students. One of the requirements is that all the
students "get the same course". So I have to teach "MATLAB", or at
least, something highly compatible with MATLAB, because I don't decide
what's in the course.

Hence my interest in providing a GUI that is similar to MATLAB, and
that is able to run MATLAB code. Now around 200 of the 500 students
are running Octave (my group, and another group I managed to convince
:). They think of this as a sort of "MATLAB-like" free (as in freedom)
environment. I tell them that this is Octave (not MATLAB), that is
free software and that is very similar to MATLAB, and that we have
customized the GUI to suit it to the needs of the course, thanks to
the availability of the source code and the license under it is
distributed.

Most of them are happy using this version instead of trying to get
MATLAB by themselves.

As a side effect, I also have an invaluable group of testers to see
what works and what does not :). They make lots of comments about how
they would like the program to be, and find lots of bugs too. This is
actually the main force driving my changes.

Cheers,
Israel