[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Qt/gui on MacOSX (was: 4.0 release goals)
From: |
Ben Abbott |
Subject: |
Re: Qt/gui on MacOSX (was: 4.0 release goals) |
Date: |
Mon, 05 Nov 2012 17:00:57 -0500 |
On Nov 5, 2012, at 4:57 PM, Michael Goffioul wrote:
> On Mon, Nov 5, 2012 at 3:58 PM, Ben Abbott <address@hidden> wrote:
>
> On Nov 5, 2012, at 3:50 PM, Michael Goffioul wrote:
>
> > On Mon, Nov 5, 2012 at 3:45 PM, Ben Abbott <address@hidden> wrote:
> > Octave exists during the call "QApplication application (argc, argv);" at
> > line 87 in libgui/src/octave-gui.cc
> >
> > 80 int
> > 81 octave_start_gui (int argc, char *argv[])
> > 82 {
> > 83 dissociate_terminal ();
> > 84
> > 85 setenv ("GNUTERM", "qt", 1);
> > 86
> > 87 QApplication application (argc, argv);
> >
> > With lack of experience with c++, I don't know how to go further.
> >
> > It looks like yet another hard limitation of Mac OS X. If Qt decides to
> > exit the app, there's probably a good reason for it, and it's also probably
> > difficult (or impossible) to work around as-is. You might try to debug
> > further with debug version of Qt, but I'm not sure it's worth. Now I'm
> > wondering what can be done to make it work under Mac OS X. Maybe we should
> > simple re-exec octave with a specific flag to avoid re-forking?
> >
> > Michael.
>
> Gnuplot overcame the same (similar?) problem. I asked Ethan Merritt for an
> overview. See below.
>
> Yes, I've read if from one of your previous mails, but that's not really a
> "solution". It involves running the graphics system in a separate process and
> communicate with the base program through pipes. That's typically what we
> tried to avoid by using a in-process separate thread. Note that using that
> approach in gnuplot actually doubles the data transfer when using it from
> octave: first to transfer data from octave to gnuplot, then to transfer data
> from gnuplot to the separate process running the Qt terminal.
>
> Michael.
The gui did work on MacOS X before the build process was integrated with the
CLI. I assume that indicates there is a solution to the problem?
Ben
- Re: 4.0 release goals, (continued)
- Re: 4.0 release goals, Ben Abbott, 2012/11/04
- Re: 4.0 release goals, Michael Goffioul, 2012/11/04
- Re: Qt/gui on MacOSX (was: 4.0 release goals), Ben Abbott, 2012/11/04
- Re: Qt/gui on MacOSX (was: 4.0 release goals), Michael Goffioul, 2012/11/04
- Re: Qt/gui on MacOSX (was: 4.0 release goals), Ben Abbott, 2012/11/05
- Re: Qt/gui on MacOSX (was: 4.0 release goals), Michael Goffioul, 2012/11/05
- Re: Qt/gui on MacOSX (was: 4.0 release goals), Ben Abbott, 2012/11/05
- Re: Qt/gui on MacOSX (was: 4.0 release goals), Michael Goffioul, 2012/11/05
- Re: Qt/gui on MacOSX (was: 4.0 release goals), Ben Abbott, 2012/11/05
- Re: Qt/gui on MacOSX (was: 4.0 release goals), Michael Goffioul, 2012/11/05
- Re: Qt/gui on MacOSX (was: 4.0 release goals),
Ben Abbott <=
- Re: Qt/gui on MacOSX (was: 4.0 release goals), Ethan A Merritt, 2012/11/05
- Re: Qt/gui on MacOSX (was: 4.0 release goals), Michael Goffioul, 2012/11/05
- Re: Qt/gui on MacOSX, Daniel J Sebald, 2012/11/06
- Re: Qt/gui on MacOSX, sfeam (Ethan Merritt), 2012/11/06
Re: 4.0 release goals, Ben Abbott, 2012/11/04
Re: 4.0 release goals, Rik, 2012/11/01