|
From: Daniel J S. <dan...@ie...> - 2012-08-22 08:22:10
|
On 08/22/2012 02:37 AM, Mojca Miklavec wrote: > On Wed, Aug 22, 2012 at 5:39 AM, Daniel J Sebald wrote: >> What is the status of the Qt terminal? It easily builds and works on >> linux systems. How about Apple? > > The trunk code finally compiles (since the patch on "2012-06-23 > Jérôme lodewyck"), but it would be nice if that commit could be > included in branch-4-6-stable before next release. I assume there is a Qt init step that will check that the system has Qt support available and active. > It works automatically on (for example) MacPorts-based Qt via > pkg-config. When users install Qt from official installers, it is > necessary to manually specify QT_LIBS and QT_CFLAGS even though it > would be easy enough to check for system-wide installation and a > single extra set of flags. (There is only one official installer, so > anyone using that requires the same flags.) > > There are some issues with forking, most annoying is that printing > crashes while opening printing dialog. (If I try to circumvent the > printing dialog, it prints fine.) I have no idea where to look to fix > it. Two programs open on dock, but one icon gets hidden. Suboptimal, > but acceptable. The fork influences Qt printing? Strange. > Overall it works nicely and Qt terminal is also available as an > optional install on MacPorts. It sounds to me like Qt for Windows hasn't been tested yet. Should I seek out a volunteer? The way it appears, my guess is the fork won't compile under Windows. The wxWidgets terminal appears to conditionally deal with fork when it isn't available. > PS: Personally I would like to see the icon change (use a higher > resolution at least) and there's a slightly annoying "jumping" canvas > (not mac-specific) when resizing/increasing the plot area. It seems as > if plot area tries to be centered and alternates between Qt moving > existing plot to center of the new bigger area and gnuplot resizing > the image after some time (short time interval, but long enough to > generate some jumping visible.) I've seen that. In some cases it is too fast to tell exactly what is happening, but it is discombobulating. The last gnuplot demo is a big polygon rendering and in between renderings when resizing the window the image moves to the center temporarily. If it were to stay put then expand, it wouldn't look so bad. Perhaps there is something with rescale/no-rescale that Qt hasn't worked out exactly right. Thanks Mojca, Dan |