On 14 February 2016 at 23:29, Gabriel Dos Reis <g...@integrable-solutions.net> wrote: > > ... The QT front-end is what I would want as replacement for the > existing X11-based HyperDoc and Graphics component, because it is > cross-platform (unlike X11), well-supported with high-level abstraction > primitives for writing a good GUI. It is also now standard in the *nix > world. > > However, it is at this point a work-in-progress and I would very much like > to see it progress at a faster pace. >
Yes a QT interface would be nice but (re-)implementing HyperDoc and Graphics in QT seems to me like a lot of effort. The current fashion trend however seems to be browser-based interfaces like Jupyter. There is already a reasonably functional version of a Jupyter kernel (interface) for FriCAS. This should be fairly easily adaptable to OpenAxiom though unfortunately for the OpenAxiom development strategy it is based rather centrally on a Lisp implementation of the kernel. Probably a C++ implementation of a Jupyter kernel based on some of the interface that you have already done for QT would not be too difficult. > On the other hand we have the QT4 vs. QT5 split. When I wrote the original > skeleton, QT-4.8.something was all rage. My 2-3 years hiatus haven't helped > keeping pace. I would like to use QT5 as an axiomatic requirement. Is that > too much of a burden? > Probably QT5 is a reasonable target. > My personal development environment these days is OS X El Capitan, I can > have access to OpenSUSE Tumbleweed but only sporadically. I would have to > rely on you for OpenSUSE Leap -- I am not familiar with its characteristics. > I can try. >> ... >> With this patch I was able to compile open-axiom but I did not get the >> QT front end. Checking config.log, I noticed that it was expecting to >> find. qmake. > > That is correct. Testing for QT currently relies on finding qmake (and > moc). If that utility isn't in the path, then the configuration script just > assumes that QT isn't there. It can be a problem on some platforms like > yours, but also OS X with QT5 installed via MacPorts which will put it in > an odd place without the appropriate symlinks. On OpenSUSE > Tumbleweed and a couple of linux platforms, it wasn't a problem. > Were you able to build and run the gui on OpenSUSE Tumbleweed? >> >> Unfortunately qmake is only available with QT4. So I >> installed QT4 and tried again. >> >> This time the compile worked and I apparently got the QT front end >> built and installed but when I run 'open-axiom' terrible things >> happen. > > Ouch! Does not sound good. > At this point I have *both* QT4.8 and QT5 installed. Maybe that is a problem? >> >> My desktop becomes non-responsive and I see about three or >> four windows with the gui open. If I cntl-alt-F1 and 'killall -9 >> AXIOMsys', I can return to my desktop and continue. But I am not >> longer able to start open-axiom sucessfully no matter which option I >> choose (e.g. --no-gui still fails in the same way). > > Ouch, this is bizarre, and I don't think it is related to the QT > front-end... > If you build with QT, and you just start OpenAxiom with > > $ open-axiom > > you will NOT get the QT front-end, because it is sill a work-in-progress, > so it is not enabled by default. Hmm, that is not what I observe. In my current build if I type $ open-axiom just before everything goes bad I do get what appears to be a gui interface pop-up. In fact I get two such windows opened. Then the desktop freezes (only mouse movement is possible). When I open a terminal with Cntl-Alt-F1 the command # ps -A -f | grep open-axiom shows a process named 'open-axiom' and five instances of 'AXIOMsys' : wspage 3236 3216 0 09:17 pts/0 00:00:00 open-axiom wspage 3239 3236 2 09:17 pts/1 00:00:01 /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/AXIOMsys -- --role=server wspage 3240 3236 0 09:17 pts/0 00:00:00 /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/lib/session wspage 3241 3236 0 09:17 pts/0 00:00:00 /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/clef -f /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/lib/command.list -e /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/lib/spadclient wspage 3242 3236 0 09:17 pts/0 00:00:00 /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/lib/hypertex wspage 3243 3236 0 09:17 pts/0 00:00:00 /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/lib/viewman wspage 3244 3241 0 09:17 pts/2 00:00:00 /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/lib/spadclient wspage 3246 3239 35 09:17 pts/1 00:00:22 /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/AXIOMsys -- --role=server -- --role=server wspage 3248 3246 1 09:17 pts/1 00:00:01 /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/AXIOMsys -- --role=server -- --role=server -- --role=server wspage 3250 3248 32 09:17 pts/1 00:00:20 /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/AXIOMsys -- --role=server -- --role=server -- --role=server -- --role=server wspage 3251 3236 0 09:17 pts/0 00:00:00 open-axiom wspage 3253 3250 0 09:17 pts/1 00:00:00 /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/AXIOMsys -- --role=server -- --role=server -- --role=server -- --role=server -- --role=server wspage 3255 3253 0 09:17 pts/1 00:00:00 /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/AXIOMsys -- --role=server -- --role=server -- --role=server -- --role=server -- --role=server -- --role=server root 3307 3260 0 09:18 tty1 00:00:00 grep --color=auto open-axiom Clearly something has gone wrong. > If you start OpenAxiom with > > $ open-axiom --gui > > then you get a QT window front-end for OpenAxiom. It works on relatively > simple stuff, but it is not stable regarding all kinds of error handles and > system-level commands. In my case the behavior is very similar to what I described before except I see one more gui window open but fewer open-axiom processes running. wspage 3335 3216 35 09:20 pts/0 00:00:09 /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/open-axiom wspage 3337 3335 5 09:20 pts/0 00:00:01 /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/AXIOMsys -- --role=server wspage 3339 3337 31 09:20 pts/0 00:00:08 /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/AXIOMsys -- --role=server -- --role=server wspage 3341 3339 0 09:20 pts/0 00:00:00 /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/AXIOMsys -- --role=server -- --role=server -- --role=server wspage 3343 3341 0 09:20 pts/0 00:00:00 /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/AXIOMsys -- --role=server -- --role=server -- --role=server -- --role=server root 3348 3260 0 09:21 tty1 00:00:00 grep --color=auto open-axiom # killiall AXIOMsys leaves one gui window open but it is non-responsive except to Quit. > >> >> Should I expect this to work? > > Yes, to some degree. Certainly, I expect it NOT to freeze your system. > Is it possible that the QT4 package itself is so old that it is causing > problems? Yes it is possible. > From what you've described with other components such as Xt, it sounds to > me as if this is a "unique" system setup? > Yes that seems odd. How is it that this typo did not cause problems on a build when QT was completely absent from my system? Bill. ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ open-axiom-devel mailing list open-axiom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open-axiom-devel
