Re: Qt on Mac (was: Getting ready to put out a 4.6 release candidate)

[Ethan A M. <sf...@us...>]

> On 01/05/2012 01:35 AM, Daniel J Sebald wrote:
> 
> Be that as it may, it might pay to step back a bit and consider just 
> what the QApplication is doing.
> 
> But first, let me ask whether
> 
>                 // Start
>                 application.exec();
>                 exit(0);
> 
> should be _exit(0) instead of exit(0).

Good point.  But that wouldn't help if there is an exit() call
inside application.exec() somewhere, e.g. from an error.

> Also, these lines of code:
> 
>                 // Make sure the forked copy doesn't trash the history file
>                 cancel_history();
> 
> and
> 
>         // The creation of a QApplication mangled our locale settings
> #ifdef HAVE_LOCALE_H
>         setlocale(LC_NUMERIC, "C");
>         setlocale(LC_TIME, current_locale);
> #endif
> 
> are somewhat kluge-like in the sense they shouldn't be necessary.  (I 
> wonder if the mangled locale settings is because the child code used 
> exit() instead of _exit().)

You are absolutely right that both of these are empirical fixes
(kluges if you like), and it would seem that there should be a cleaner solution.  
I would be happy to apply any better solution you can suggest!  
In the case of normal program execution, your suggestion to
use _exit(0) would make the call to cancel_history() unnecessary.
If there's an error exit, I'm not so sure.


> J�r�me, do you think it would make sense to set up initialization of the 
> Qt terminal similar to the gplt_x11 terminal for better organization and 
> enable function under OS X at the same time?  

Wouldn't the IPC channel have to be revised as well?
See the comments at the top of qt_flushOutBuffer() in qt_term.cpp

	Ethan



> That is, put these lines 
> into a small separate C executable:
> 
> main(appropriate vectors)
> {
>                 signal(SIGINT, SIG_IGN); // Do not listen to SIGINT signals anymore
> 
> #ifndef HAVE_QT_47
>                 /*
>                  * FIXME: EAM Nov 2011
>                  * It is better to use environmental variable
>                  * QT_GRAPHICSSYSTEM but this requires qt >= 4.7
>                  * "raster" is ~5x faster than "native" (default).
>                  * Unfortunately "opengl" isn't recognized on my test systems :-(
>                  */
>                 // This makes a huge difference to the speed of polygon rendering.
>                 // Alternatives are "native", "raster", "opengl"
>                 QApplication::setGraphicsSystem("raster");
> #endif
> 
>                 QtGnuplotApplication application(argc, (char**)( NULL));
> 
>                 // Make sure the forked copy doesn't trash the history file
>                 cancel_history();
> 
>                 // Load translations for the qt library
>                 QTranslator qtTranslator;
>                 qtTranslator.load("qt_" + QLocale::system().name(), 
> QLibraryInfo::location(QLibraryInfo::TranslationsPath));
>                 application.installTranslator(&qtTranslator);
> 
>                 // Load translations for the qt terminal
>                 QTranslator translator;
>                 translator.load("qtgnuplot_" + QLocale::system().name(), 
> QTGNUPLOT_DATA_DIR);
>                 application.installTranslator(&translator);
> 
>                 // Start
>                 application.exec();
>                 exit(0);
> 
> }
> 
> And in the qt_init() have something like the following (I left out 
> details, but they are available in x11.trm file):
> 
>         if (pid < 0)
>                 fprintf(stderr, "Forking error\n");
>         else if (pid == 0) // Child: start the GUI
>         {
>                 execvp(qtterm_full_command_path, optvec);
>                 _exit(0);
>         }
> 
> The advantage of using execvp is that it sort of wipes the slate clean 
> for creating the QApplication.
> 
> Please give us your thoughts.
> 
> Dan
> 
> ------------------------------------------------------------------------------
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual 
> desktops for less than the cost of PCs and save 60% on VDI infrastructure 
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta