Bug #1093
GUI: bugs and slugs
Description
I know the GUI is on "life support" (or worse), but I'd like to gather in one place some of the problems it has just in case someone wants to improve it (or make a new one).
Related issues
History
#1 Updated by John Abbott almost 7 years ago
- Related to Slug #741: C5 GUI: slow to close added
#2 Updated by John Abbott almost 7 years ago
- Related to Slug #750: C5 GUI: very slow when printing many short lines added
#3 Updated by John Abbott almost 7 years ago
The GUI really seems to have trouble with big outputs; my guess is that this is a QT "feature" :-/
factorial(10^5)
takes a long time to print, and then "fills the screen" with digits.factorial(5*10^6)
produces a "scrambled" line (it looks like overprinting); I think this puts the GUI in a near coma (consuming 99% CPU).factorial(10^7)
causes a complete crash of the GUI; output is a bit more than 64Mbyte on one line.
PS I'm pretty sure that printing out factorial(10^7)
would floor Emacs as well.
#4 Updated by John Abbott almost 7 years ago
I have changed the way CoCoALib handles signals. This forced me to make some changes to the source of the GUI (but without really understanding what the code was supposed to do).
In particular, I replaced two fn calls by calls to GetAndResetSignalReceived
(in lines 80 and 120 of C5.C
).
At two points the GUI also wants to "set" the signal received (lines 1634 and 1922 in C5.C
). I don't know why; anyway I had to make available a public fn for setting the signal received (see SignalWatcher.H
)
It is possible that my "blind" changes have broken something, but I am sure this is unrelated to the problems of large outputs.
#5 Updated by John Abbott over 4 years ago
Ulrich reported that the GUI fails to compile now that we are using nullptr
.
I had a quick search online, and found something on StackOverflow. I tried putting the compilation flag -std=c++14
for the compiler and also c++14
as a CONFIG parameter, but the error persists: it complains that nullptr
is a keyword in C++11 (so is presumably trying to compile as if in c++03 mode... no idea why).
Anyway, I think I shall change the CoCoA-5 configuration so that the user must explicitly request that the Qt GUI be compiled (even if it does not currently work). The current default is that it will attempt to compile the GUI if qmake
was found; so users who have qmake
will see failed compilations even if the normal textual interface compiled fine.
#6 Updated by John Abbott over 4 years ago
- Status changed from New to In Progress
- Assignee set to John Abbott
- % Done changed from 0 to 10
I have changed configure
so that it sets a flag saying whether to build the Qt GUI; this is determined by a command line option (default is NOT to build the GUI).
Configuration will fail if the user requests building the GUI, but qmake
is not found or does not work properly.
I have done some other tidying in the configure
script.
Now testing on my machine...
#7 Updated by John Abbott over 4 years ago
- Related to Support #1393: GUI with Qt5 added
#8 Updated by John Abbott almost 2 years ago
Interrupt messages from CoCoALib functions are discarded/ignored.
There does not appear to be a "kill" option for a running CoCoA-5; the only
way seems to be to kill the whole GUI.