gnuplot-beta — Developers and beta testers of new gnuplot code

patch for fonts on Mac OS X

[Mojca M. <moj...@gm...>]

Hello,

browsing through my MacPorts (actually, I was unsuccessfully trying to
figure out how to convince Octave to use a different gnuplot binary,
so that I wouldn't have to use X11 for plotting), I figured out that
MacPorts keep patching gnuplot with the following:

http://trac.macports.org/changeset/76048

--- src/variable.c.orig	2010-10-18 15:41:53.000000000 +0200
+++ src/variable.c	2010-10-18 15:42:11.000000000 +0200
@@ -244,13 +244,13 @@
 };
 #endif

-#if defined(_Macintosh) && !defined(FONTPATHSET)
+#if defined(__APPLE__) && !defined(FONTPATHSET)
 #  define FONTPATHSET
 static const struct path_table fontpath_tbl[] =
 {
-    { "/System/Library/Fonts!" },
-    { "/Library/Fonts!" },
-    { "$(HOME)/Library/Fonts!" },
+    { "/System/Library/Fonts" },
+    { "/Library/Fonts" },
+    { "$(HOME)/Library/Fonts" },
     { NULL }
 };
 #endif

I'm not sure how this influences terminals (which terminals are
influenced). If I try Zapfino font, I get mixed results:
- AquaTerm: works properly
- X11: font is change to some random font (but that is almost ok,
there's a chance that it is not easy to configure X11 to use that
font)
- wxt: (process:9969): Pango-WARNING **: couldn't load font "Zapfino
Not-Rotated 200", falling back to "Sans Not-Rotated 200", expect ugly
output.
  This should probably not have happened. The font should work. (But
I'm not sure which libraries are trying to find fonts.) The same
behaviour is observed even if I apply the patch.
- png:
> set term png
Terminal type set to 'png'
Could not find/open font when opening font "arial", using internal
non-scalable font
  (which means that there is something wrong with fonts, but I
remember asking for a patch of gd library, but the library is probably
still at 36 RC1 and even though patched, the patch has never been
released together with a library; maybe I could ask MacPorts team to
patch their library in the same way to see if anything gets improved)
- qt: works, but look awful since the font is not antialiased (that
might be an easy patch - just a boolean value to set somewhere)

About the patch: as already discussed, "defined(_Macintosh)" has zero
influence. (See GP archives "Identifying system with macro":
http://thread.gmane.org/gmane.comp.graphics.gnuplot.devel/9978,
http://thread.gmane.org/gmane.comp.graphics.gnuplot.devel/9988). There
is no _Macintosh defined anywhere.

The three folders are relevant for modern OS, but honestly I don't
know how that code influences any terminal to be able to test if
patching the code actually makes any difference.

If nothing else it would be great in MacPorts wouldn't need the above
mentioned patch any more.



About the remaining "_Macintosh" entries:

1.) in term.h:

/* Apple Macintosh */
#ifdef _Macintosh
# include "mac.trm"
#endif

1.a) Can somebody please explain me where any of the functions like
MAC_text are defined? It seems to me as if term/mac.trm does nothing.
I must be blind, but I don't find any function implemented anywhere.

1.b) Obviously that doesn't hurt anyone since _Macintosh isn't defined
anywhere but on ancient machines. But what's the point in keeping it
if mac.trm is empty anyway? (I suspect that there was some other
mac-specific source somewhere that got lost in years.)

2.) in plot.c:

#if defined(_Windows) || defined(_Macintosh)
int
gnu_main(int argc, char **argv)
#else
int
main(int argc, char **argv)
#endif

I don't understand what this does, but gnu_main is probably not needed
on Apple (modern Mac OS X), so "|| defined(_Macintosh)" may probably
go away if there is no code to support the old macintosh anyway.

3.) in command.c:

    if (sleep_time < 0) {
#if defined(_Windows)
...
#elif defined(_Macintosh)
  if (strcmp(term->name, "macintosh") == 0 && sleep_time < 0)
      Pause( (int)sleep_time );

This also seems to be related to the old _Macintosh. But if there is
no code for the old mac, there is little point in keeping this one as
well.

Mojca

Re: Handling zooming (pinch) with mouse (multi-touch gestures) on OS X

[Mojca M. <moj...@gm...>]

On Mon, Jan 9, 2012 at 00:33, Ethan Merritt wrote:
> On Sunday, 08 January 2012, Mojca Miklavec wrote:
>> 4.) I would like to understand what part of gnuplot's source code is
>> aware of mouse scrolling events (is receiving signals from operating
>> system, so that GE_buttonrelease is set for example).
>
> The terminals notifies the core mousing routines by filling in an
> event structure and calling do_event() in mouse.c.
>
> For the qt terminal the sequence of calls is
> thread 1:
> m_eventHandler->postTermEvent( event_type, x, y, parameter1, parameter2, winid )
>
> thread 2:
> qt_waitforinput()
> -> qt_processTermEvent(gp_event_t* event)
> -> do_event()
>
> The methods for specific event types are defined in QtGnuplotScene.cpp:
> QtGnuplotScene::wheelEvent(QGraphicsSceneWheelEvent* event)
> QtGnuplotScene::keyPressEvent(QKeyEvent* event)
> QtGnuplotScene::mouseReleaseEvent(QGraphicsSceneMouseEvent* event)
> and so on.
>
> Does that answer the question?

Yes, thank you. That piece of information makes it perfectly clear.
Now I see that in order to add extra event, I need a new class,
QtGnuplotGesture (in addition to QtGnuplotScene) for example. I might
need more information later, but for now this is enough to start
experimenting.

Mojca

Re: [ gnuplot-Bugs-3468950 ] Qt, moc and uic not found on Mac OS X

[Ethan M. <merritt@u.washington.edu>]

On Sunday, 08 January 2012, Jérôme Lodewyck wrote:
> Hi,
> 
> 	what about this new patch ? (I'm not even sure it compiles, because it 
> makes use of the cocoa API which I cannot test here)
> 
> Jérôme


I have been running with this one (version 2) under linux.
It looks pretty good.  Over the day or so of testing I've accumulated
3 zombie gnuplot_qt processes, however.  So there's a termination 
condition that's being missed somewhere.

	Ethan 

Re: borders.dem fails in the current cvs tip

[sfeam (E. Merritt) <eam...@gm...>]

On Sunday, 08 January 2012, Tatsuro MATSUOKA wrote:
> Hello
> 
> borders.dem fails in the current cvs tip
> 
> ********************** file borders.dem *********************
> 
>         border is not drawn
> 
> 
> ;
>     set border bb;
>     show border;
>     set label 1 "Border = %.0f",bb  at 5,5 center;
                  ^^^^^^^^^^^^^^^^^^      
Deprecated syntax.

I added that syntax to the set of deprecated constructions
covered by ./configure --with-backwards-compatibility
but I didn't realize any of the demos used it.

The demo should now be updated to 

      set label 1 sprintf("Border = %.0f",bb) at 5,5 center


	Ethan


>     plot 1/0 notitle;
> 
>                                                                      ^
> line 15: ';' expected
> 
> This happens in both MinGW and Cygwin.
> 
> Regards
> 
> Tatsuro

borders.dem fails in the current cvs tip

[Tatsuro M. <tma...@ya...>]

Hello

borders.dem fails in the current cvs tip

********************** file borders.dem *********************

        border is not drawn


;
    set border bb;
    show border;
    set label 1 "Border = %.0f",bb  at 5,5 center;
    plot 1/0 notitle;

                                                                     ^
line 15: ';' expected

This happens in both MinGW and Cygwin.

Regards

Tatsuro

Re: Qt terminal

[Ethan M. <merritt@u.washington.edu>]

On Sunday, 08 January 2012, Mojca Miklavec wrote:
> PS: what exactly is -DXAPPLRESDIR=\"/etc/X11/app-defaults/\"? That
> folder doesn't exist.

Only relevant to the x11 terminal.
It points to the folder where the system keeps default Xresource files.
There doesn't seem to be any standard place even for linux/unix systems,
so if you care about this (most people don't) you can configure it
correctly for your system.   The mechanism of configuring application
behaviour via Xresources seems to have fallen out of favor, so most
people can safely ignore all of this.
	
	Ethan

Re: Handling zooming (pinch) with mouse (multi-touch gestures) on OS X

[Ethan M. <merritt@u.washington.edu>]

On Sunday, 08 January 2012, Mojca Miklavec wrote:
> 4.) I would like to understand what part of gnuplot's source code is
> aware of mouse scrolling events (is receiving signals from operating
> system, so that GE_buttonrelease is set for example).

The terminals notifies the core mousing routines by filling in an
event structure and calling do_event() in mouse.c.    

For the qt terminal the sequence of calls is
thread 1:
m_eventHandler->postTermEvent( event_type, x, y, parameter1, parameter2, winid )

thread 2:
qt_waitforinput() 
-> qt_processTermEvent(gp_event_t* event) 
-> do_event()

The methods for specific event types are defined in QtGnuplotScene.cpp:
QtGnuplotScene::wheelEvent(QGraphicsSceneWheelEvent* event)
QtGnuplotScene::keyPressEvent(QKeyEvent* event)
QtGnuplotScene::mouseReleaseEvent(QGraphicsSceneMouseEvent* event)
and so on.

Does that answer the question?

Re: Handling zooming (pinch) with mouse (multi-touch gestures) on OS X

[Mojca M. <moj...@gm...>]

On Sun, Jan 8, 2012 at 20:28, Ethan Merritt wrote:
> On Sunday, 08 January 2012, Mojca Miklavec wrote:
>> PS: Qt terminal is a tiny bit buggy. Scrolling left/right results in
>> scrolling of graph up/down. Even if scrolling left/right is not yet
>> supported, it should at least not try to be clever and scroll up/down.
>
> Both right/left and up/down scroll work fine for me.

I wasn't clear enough (I find it difficult to explain).

1.) Scrolling up/down (read as: sliding two fingers up/down) works properly.
2.) Holding Shift + scrolling up/down (sliding two fingers up/down)
correctly moves the plot left/right.

However, while regular mouses only provide scroll wheels for
one-dimensional moves (up and down), trackpad on Mac OS X enables one
to scroll in 2D (both up/down and left/right, or actually in arbitrary
directions in plane).

3.) Scrolling left/right (sliding two fingers left/right) moves the
plot up/down which is wrong and should not happen.

4.) I would like to understand what part of gnuplot's source code is
aware of mouse scrolling events (is receiving signals from operating
system, so that GE_buttonrelease is set for example).

> Could it be a problem of key mapping?
> The behaviour you see might be explained by a failure to
> distinguish <shift-scroll> from <scroll>.

No, shift-scroll works fine as explained above. It is only a bit
annoying that left-right generates up-and-down movements in the plot.

Mojca

Re: Qt terminal

[Mojca M. <moj...@gm...>]

On Sun, Jan 8, 2012 at 20:25, Ethan Merritt wrote:
> On Sunday, 08 January 2012, Mojca Miklavec wrote:
>> My only remaining question that is pretty relevant for the user
>> experience: How can I convince the cursor to stay in terminal (text
>> mode) after entering some plotting command (and optionally still make
>> the plotting window pop in front of the screen)?
>
>> If I load "all.dem", I have to keep switching back to terminal to be
>> able to hit enter to continue after a pause. In X11 that is not
>> necessary (but I don't know how gnuplot with X11 works on Linux).
>
> I do not have this problem with the qt terminal under linux, but to
> the best of my knowledge this is because of the setting "do not steal
> focus" in the window manager. I have no idea how you set the
> equivalent on OSX.  The converse problem - sending the focus back to
> the terminal while you are trying to work with the plot window -
> is equally annoying but can be disabled by  ./configure --disable-raise-console.

I hope that somebody else will have more ideas. Now that Jérôme is
playing with application settings like hiding windows, he might have
seen something about switching focus as well. (But behaviour of focus
of applications in Lion is somewhat buggy anyway. There are some
aspects that I really hate. I'm unable to open a new window with
apple+N in - say - web browser without the latest minimized window
popping up as well.)

> Yeah, I also would prefer a different default aspect ratio.
> But there is plenty of precedent for 640x480 being the default size.

What about other's opinions?

> Maybe we could make it a user-settable preference in the tool widget.
> The wxt terminal maintains a preference file ~/.gnuplot-wxt so that the
> widget settings are persistent.  I suppose the qt terminal could do the same.

Where does Qt terminal store background color?

>> - I'm able to set arbitrary background color and it is remembered.
>> However I cannot change plot size, font size somewhere in settings and
>> ask gnuplot/qt to remember that. That would be much more useful for me
>> than background color. (Yes, I know that I can always use "set term qt
>> <whatever> to do that, but that's not the point.")
>
> See above.

1.) I'm still curious to know where Qt terminal stores background color.
2.) It would be *really really really* nice if it was doable via GUI,
in the same way as for background color. Yes, ~/.gnuplot<something> is
always an option, but if some options like color can be configured in
gui, I don't see a reason why others (plot size, font face & size)
couldn't be.

Mojca

Re: Qt terminal

[Mojca M. <moj...@gm...>]

2012/1/8 Jérôme Lodewyck wrote:
> Le Dimanche 8 Janvier 2012 17:45:08 vous avez écrit :
>> I had to replace Cocoa/Cocoa.h with Carbon/Carbon.h. Import of Cocoa
>> doesn't work and I have no idea why (maybe because it is in Objective
>> C and some compiler flags bail?). I also have no idea how safe it is
>> to use Carbon, but apparently it worked this time.
>
> Just for the fun, here is a version that should compile with Cocoa.

Thank you very much. It compiles and works fine (not that I understand
what is the difference since AquaTerm is also using Objective C and
there is no special compiler, maybe only some different flags).

> Beware it
> breaks the build systems on non-OSX systems (I don't know how to conditionally
> add sources for a given OS in Makefile.am...). As far as I understand, the
> problem with Carbon is that it is somehow obsolete and apperently does not
> work on 64 bits systems.

I'm not sure what is going one. I also believed that Carbon was 100%
forbidden in 64-bit applications, but your previous code with
Cocoa->Carbon worked and:

> file /System/Library/Frameworks/Carbon.framework/Carbon
/System/Library/Frameworks/Carbon.framework/Carbon: Mach-O universal
binary with 2 architectures
/System/Library/Frameworks/Carbon.framework/Carbon (for architecture
x86_64):	Mach-O 64-bit dynamically linked shared library x86_64
/System/Library/Frameworks/Carbon.framework/Carbon (for architecture
i386):	Mach-O dynamically linked shared library i386

Maybe there is some core part of functionality in Carbon that still
works, but even that might easily disappear at any given moment
without notice. My bet is that next OS version won't ship Carbon at
all.

Mojca

PS: what exactly is -DXAPPLRESDIR=\"/etc/X11/app-defaults/\"? That
folder doesn't exist.

Re: Qt terminal

[Jérôme L. <lod...@us...>]

Le Dimanche 8 Janvier 2012 17:45:08 vous avez écrit :
> I had to replace Cocoa/Cocoa.h with Carbon/Carbon.h. Import of Cocoa
> doesn't work and I have no idea why (maybe because it is in Objective
> C and some compiler flags bail?). I also have no idea how safe it is
> to use Carbon, but apparently it worked this time.

Just for the fun, here is a version that should compile with Cocoa. Beware it 
breaks the build systems on non-OSX systems (I don't know how to conditionally 
add sources for a given OS in Makefile.am...). As far as I understand, the 
problem with Carbon is that it is somehow obsolete and apperently does not 
work on 64 bits systems.

Jérôme

Re: Qt terminal

[sfeam (E. Merritt) <eam...@gm...>]

On Sunday, 08 January 2012, Ethan Merritt wrote:
> > - Bug report: clipping part of plot with mouse in backwards direction
> > (starting at some point and then moving up and/or left) is buggy. It
> > works (clips properly), but displays in a weird way and leaves some
> > weird traces.
> 
> Hmm. You are right.
> I don't remember this being a problem before. 
> Could it have been broken by a recent change?

Mea culpa.
Jérôme fixed this earlier, but I inadvertently reverted his fix
when I did a too-broad commit of the source tree I was working from.
I have just now restored the working version.

	Ethan

Re: Handling zooming (pinch) with mouse (multi-touch gestures) on OS X

[Ethan M. <merritt@u.washington.edu>]

On Sunday, 08 January 2012, Mojca Miklavec wrote:
> PS: Qt terminal is a tiny bit buggy. Scrolling left/right results in
> scrolling of graph up/down. Even if scrolling left/right is not yet
> supported, it should at least not try to be clever and scroll up/down.

Both right/left and up/down scroll work fine for me.
Could it be a problem of key mapping?
The behaviour you see might be explained by a failure to 
distinguish <shift-scroll> from <scroll>.

	Ethan

Re: Qt terminal

[Ethan M. <merritt@u.washington.edu>]

On Sunday, 08 January 2012, Mojca Miklavec wrote:
> My only remaining question that is pretty relevant for the user
> experience: How can I convince the cursor to stay in terminal (text
> mode) after entering some plotting command (and optionally still make
> the plotting window pop in front of the screen)?
 
> If I load "all.dem", I have to keep switching back to terminal to be
> able to hit enter to continue after a pause. In X11 that is not
> necessary (but I don't know how gnuplot with X11 works on Linux).

I do not have this problem with the qt terminal under linux, but to
the best of my knowledge this is because of the setting "do not steal
focus" in the window manager. I have no idea how you set the 
equivalent on OSX.  The converse problem - sending the focus back to
the terminal while you are trying to work with the plot window -
is equally annoying but can be disabled by  ./configure --disable-raise-console.
 
> - Plot size for qt is 640x480, for x11 it is 640x463, for wxt it is
> 640x402, but default font size in Qt is some 20-30 % smaller than in
> x11, and x11 also contains coordinates in lower left corner;
> consequently plot size in qt is 593x456, while for x11 it is 584x415
> (didn't measure for wxt); bottomline: in Qt the window looks somewhat
> too high. Would it be possible to make it smaller in y direction?
> (Optimally the same size as wxt, but it doesn't have to be that
> strict.)

Yeah, I also would prefer a different default aspect ratio.
But there is plenty of precedent for 640x480 being the default size.
That's what all of the bitmap terminals [use to] have.

Maybe we could make it a user-settable preference in the tool widget.
The wxt terminal maintains a preference file ~/.gnuplot-wxt so that the
widget settings are persistent.  I suppose the qt terminal could do the same.
 
> - I'm able to set arbitrary background color and it is remembered.
> However I cannot change plot size, font size somewhere in settings and
> ask gnuplot/qt to remember that. That would be much more useful for me
> than background color. (Yes, I know that I can always use "set term qt
> <whatever> to do that, but that's not the point.")

See above.

> - Feature request (not sure about it): I really like menu-based
> commands in windows. So even newbies are able to figure out some
> commands without having to read help. Do others think that this would
> make sense in Qt terminal?

Ugh, no.

> - Bug report: clipping part of plot with mouse in backwards direction
> (starting at some point and then moving up and/or left) is buggy. It
> works (clips properly), but displays in a weird way and leaves some
> weird traces.

Hmm. You are right.
I don't remember this being a problem before. 
Could it have been broken by a recent change?

> - I would expect the files (see list on the bottom***) to end up under
> src/qtterminal or some under src/qtterminal/trans and not under src,
> but that is just cosmetics. That way it is also easier to list them in
> .cvsignore (I don't use cvs and I don't know any tool to translate
> .cvsignore into .gitignore automatically, so that doesn't affect me
> directly).

I suggest to you that this is an example of why it is better not to
configure + build on top of your primary source directory.  I realize that
different people have different work-flows, but messing up the contents
of the directory tree you are using for source control strikes me as
a poor choice.  Perhaps you could use "make clean" or even 
"make distclean" before trying to commit any changes?


	Ethan

Handling zooming (pinch) with mouse (multi-touch gestures) on OS X

[Mojca M. <moj...@gm...>]

Hello,

I would like to ask just for a few pointers, not any real code.
Gnuplot supports Shift+scroll up/down to move left/right on the graph.

However the trackpad on Mac OS X is capable of scrolling left/right as
well, as well as zooming in/out. That would be a lot more handly than
trying to remember which key to press along with a mouse.

Here are some references from Apple & Qt documentation for zoom in/out (pinch):

http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/NSResponder_Class/Reference/Reference.html#//apple_ref/occ/instm/NSResponder/magnifyWithEvent:

http://doc.qt.nokia.com/4.7-snapshot/qpinchgesture.html
http://doc.qt.nokia.com/4.7-snapshot/gestures-overview.html

... ok, maybe after all I was wrong about horizontal scrolling if I'm
looking at the right document:
https://bugreports.qt.nokia.com/browse/QTBUG-9054, but at least pinch
should work.


My question is: where exactly could I plug in the Cocoa or Qt code if
I want to play with gestures? In particular, I don't understand where
for example GE_buttonrelease comes from (what triggers it).

Mojca

PS: Qt terminal is a tiny bit buggy. Scrolling left/right results in
scrolling of graph up/down. Even if scrolling left/right is not yet
supported, it should at least not try to be clever and scroll up/down.

Qt terminal

[Mojca M. <moj...@gm...>]

(I'm renaming the thread from "[ gnuplot-Bugs-3468950 ] Qt, moc and
uic not found on Mac OS X" since I have made it so long and the
discussion has departed from moc/uic long time ago already.)

Dear Jérôme,

I would like to sincerely thank you for the patches you sent me. It
seems that the terminal finally works normally now.

2012/1/8 Jérôme Lodewyck wrote:
> Hi,
>
>        what about this new patch ? (I'm not even sure it compiles, because it
> makes use of the cocoa API which I cannot test here)

I had to replace Cocoa/Cocoa.h with Carbon/Carbon.h. Import of Cocoa
doesn't work and I have no idea why (maybe because it is in Objective
C and some compiler flags bail?). I also have no idea how safe it is
to use Carbon, but apparently it worked this time.

Now there are still two windows popping up, but the first one gets
closed soon afterwards and the second one gets a gnuplot icon. So it
only remains a matter of neglegible cosmetic issue (it would be better
not to display the first window at all, but it is perfectly fine the
way it is working now). If it works fine on other operating systems,
this might be the solution to go for and if it ever turns out in
future that forking is not needed or that there is a better proposal
for communication with Qt, it can be changed at any later time.


Here is what gets written out when I start plotting:

> plot sin(x)
qt_init() ""
execGnuplotQt()
Remove the application icon fom the MAC OS X dock
qt_connectToServer "qtgnuplot42894" false


I can now also quit the Qt window which prints out:

> Quit application 42894 false
Qt terminal communication error: select() error 9 Bad file descriptor

gnuplot> plot cos(x)
qt_connectToServer "qtgnuplot42894" false
Could not connect gnuplot_qt "" . Staring a new one
execGnuplotQt()
qt_connectToServer "qtgnuplot42895" false
gnuplot>


My only remaining question that is pretty relevant for the user
experience: How can I convince the cursor to stay in terminal (text
mode) after entering some plotting command (and optionally still make
the plotting window pop in front of the screen)?

If I load "all.dem", I have to keep switching back to terminal to be
able to hit enter to continue after a pause. In X11 that is not
necessary (but I don't know how gnuplot with X11 works on Linux).


Other, less important issues:

- Trivial change: I would like to request renaming "gnuplot_qt" window
into something more descriptive and more like human-readable
application name. Even if that is just "Gnuplot" or maybe some mention
of Qt.

- Printing doesn't work, but I would not bother about that now; it
might be pretty complex to make it work; it might also be trivial, but
it is of much lower priority now.

- Plot size for qt is 640x480, for x11 it is 640x463, for wxt it is
640x402, but default font size in Qt is some 20-30 % smaller than in
x11, and x11 also contains coordinates in lower left corner;
consequently plot size in qt is 593x456, while for x11 it is 584x415
(didn't measure for wxt); bottomline: in Qt the window looks somewhat
too high. Would it be possible to make it smaller in y direction?
(Optimally the same size as wxt, but it doesn't have to be that
strict.)

- I would prefer slightly bigger default font size, but that is just
me. On my screen numbers in Qt terminal are 7 pixels high and on 800
pixels/177 mm that makes each number 1.55 mm. (In my editor I use 11
pixels.) I don't know what others think of that since it highly
depends on monitor resolution and operating system and one may always
argue that it is configurable. It seems that font size is declared to
be 9pt (at least I get the same result if I try "set term qt font
',9'"), but it is 7 pixels high. Just to make it clear: it *is*
readable, it is extremely well hinted (it's not antialiased), but it
is a tiny bit too small. My favourite size would be 12 (which would
make numbers 9 pixels high). I don't know which font is being used by
default though.

- I'm able to set arbitrary background color and it is remembered.
However I cannot change plot size, font size somewhere in settings and
ask gnuplot/qt to remember that. That would be much more useful for me
than background color. (Yes, I know that I can always use "set term qt
<whatever> to do that, but that's not the point.")

- I would expect the files (see list on the bottom***) to end up under
src/qtterminal or some under src/qtterminal/trans and not under src,
but that is just cosmetics. That way it is also easier to list them in
.cvsignore (I don't use cvs and I don't know any tool to translate
.cvsignore into .gitignore automatically, so that doesn't affect me
directly).

- Feature request (not sure about it): I really like menu-based
commands in windows. So even newbies are able to figure out some
commands without having to read help. Do others think that this would
make sense in Qt terminal?

- Feature request: I would like to have zoom in & left/right sliding
using mouse gestures, but this is something that I need to investigate
myself based on Qt tutorials. In contrast to wxWidgets, Qt has native
support for them. This means that gnuplot should not only listen to
scrolling wheel, but also to other more advanced events.

- Bug report: clipping part of plot with mouse in backwards direction
(starting at some point and then moving up and/or left) is buggy. It
works (clips properly), but displays in a weird way and leaves some
weird traces. I can create a screenshot if others are unable to
reproduce it. Clipping into the fourth quadrant (from upper left to
lower right corner) works and displays as expected.

- Request: This is the same with all interactive terminals though: I
would like to see current terminal options listed somewhere. For
example:

> set term png
Terminal type set to 'png'
Could not find/open font when opening font "arial", using internal
non-scalable font
Options are 'nocrop medium size 640,480 '
> set term pdfcairo
Terminal type set to 'pdfcairo'
Options are ' transparent fontscale 0.5 size 5.00in, 3.00in '

but

> set term x11
Terminal type set to 'x11'
Options are ' nopersist'
> set term wxt
Terminal type set to 'wxt'
Options are '0'
> set term qt
Terminal type set to 'qt'
Options are '0'

I find the listed options very helpful to help me decide which options
are available and which ones are the default. (Now, if I want to
figure out current window size, I need to create a screenshot, exact
crop and ask for number of pixels.)

>> (I don't particularly like the fact that I now
>> have to install gnuplot before running it, but if that is what it
>> takes, so let it be.
>
> You don't have to install it. You can define the environment variable
> export GNUPLOT_DRIVER_DIR=./src/
> to point to the directory where the gnuplot_qt executable is.

Thank you for the information.

>
>> (Where should the image
>> from    setWindowIcon(QIcon(":/images/gnuplot")); come from?)
>
> the image is in the src/qtterminal/images/ directory, and is included in the
> executable by qrc using the configuration file QtGnuplotResource.qrc

Oh, thank you. Now I understand how it works. I will also start a new
thread about the icon. On Mac OS X the icon size 32x32 is way too
small (see attachments on
https://sourceforge.net/tracker/?func=detail&aid=3469808&group_id=2055&atid=352055;
on Mac it is suggested to provide icons of size up to 512x512). I
would like to suggest creating an official vector icon. (I have one
gnuplot-generated proposal in PDF; manually generated SVG clone is
attached on the link above; another option would be creating a 3D
model with PovRay and I'm willing to help with that, but I would need
to know what you think of that.)

Mojca

*** files in src:
#	src/QtGnuplotApplication.o
#	src/QtGnuplotEvent.o
#	src/QtGnuplotItems.o
#	src/QtGnuplotScene.o
#	src/QtGnuplotWidget.o
#	src/QtGnuplotWindow.o
#	src/moc_QtGnuplotApplication.cpp
#	src/moc_QtGnuplotApplication.o
#	src/moc_QtGnuplotEvent.cpp
#	src/moc_QtGnuplotEvent.o
#	src/moc_QtGnuplotScene.cpp
#	src/moc_QtGnuplotScene.o
#	src/moc_QtGnuplotWidget.cpp
#	src/moc_QtGnuplotWidget.o
#	src/moc_QtGnuplotWindow.cpp
#	src/moc_QtGnuplotWindow.o
#	src/qrc_QtGnuplotResource.cpp
#	src/qrc_QtGnuplotResource.o
#	src/qt_term.o
#	src/qtgnuplot_fr.qm
#	src/qtgnuplot_ja.qm

Re: [ gnuplot-Bugs-3468950 ] Qt, moc and uic not found on Mac OS X

[Jérôme L. <lod...@us...>]

Hi,

	what about this new patch ? (I'm not even sure it compiles, because it 
makes use of the cocoa API which I cannot test here)

> (I don't particularly like the fact that I now
> have to install gnuplot before running it, but if that is what it
> takes, so let it be. 

You don't have to install it. You can define the environment variable
export GNUPLOT_DRIVER_DIR=./src/
to point to the directory where the gnuplot_qt executable is.

> (Where should the image
> from    setWindowIcon(QIcon(":/images/gnuplot")); come from?)

the image is in the src/qtterminal/images/ directory, and is included in the 
executable by qrc using the configuration file QtGnuplotResource.qrc

Jérôme

Re: screendump and Qt - Re: Getting ready to put out a 4.6 release candidate

[Petr M. <mi...@ph...>]

> >> I really like the fact that it has "export to PDF", "Print" functionality
> >> and auto-resize the plot, none of which is present in wxt.
> >
> > I like it too. It remembers me that gnuplot on MSW has command "screendump"
> > which invokes the print dialog. What about making this command working also
> > for Qt?
> 
> What is the difference between screendump and print then?

"screendump" is the command to do the print action (instead of clicking the 
icon)

---
Petr

Re: [ gnuplot-Bugs-3468950 ] Qt, moc and uic not found on Mac OS X

[Daniel J S. <dan...@ie...>]

On 01/07/2012 03:00 PM, Daniel J Sebald wrote:
> On 01/07/2012 02:52 PM, Daniel J Sebald wrote:
>
> + * QT_GRAPHICSSYSTEM but this requires qt >= 4.7
>
> I assume you are saying that although Qt added the setGraphicsSystem()
> routine in version 4.5, it wasn't until version 4.7 that an environment
> variable was added. But I think that is an easy fix if gnuplot Qt term
> were to program it:

I guess this doesn't make enough sense because it is only 4.5 where 
setGraphicsSystem exists:

      get version from aboutQt
      if version >= Qt 4.5
         if QT_GRAPHICSSYSTEM does not exist
            pick highest rendering in order of
            "openvg", "opengl", "raster", "native"
         else
            setGraphicsSystem(QT_GRAPHICSSYSTEM);
         endif
      endif

The version test could be dropped.

If one doesn't want to force the upgrade of Qt then:

#if QT_VERSION >= 0x040500
    if QT_GRAPHICSSYSTEM does not exist
       pick highest rendering in order of
       "openvg", "opengl", "raster", "native"
    else
       setGraphicsSystem(QT_GRAPHICSSYSTEM);
    endif
#endif

Re: [ gnuplot-Bugs-3468950 ] Qt, moc and uic not found on Mac OS X

[Daniel J S. <dan...@ie...>]

On 01/07/2012 02:52 PM, Daniel J Sebald wrote:

+    * QT_GRAPHICSSYSTEM but this requires qt >= 4.7

I assume you are saying that although Qt added the setGraphicsSystem() 
routine in version 4.5, it wasn't until version 4.7 that an environment 
variable was added.  But I think that is an easy fix if gnuplot Qt term 
were to program it:

     get version from aboutQt
     if version >= Qt 4.5
        if QT_GRAPHICSSYSTEM does not exist
           pick highest rendering in order of
           "openvg", "opengl", "raster", "native"
        else
           setGraphicsSystem(QT_GRAPHICSSYSTEM);
        endif
     endif

Dan

Re: [ gnuplot-Bugs-3468950 ] Qt, moc and uic not found on Mac OS X

[Daniel J S. <dan...@ie...>]

On 01/07/2012 07:43 AM, Jérôme Lodewyck wrote:
> Hi,
>
> 	here is an update patch. It implement the idea mentioned in previous mails
> of an auxiliary program started by exec after the fork. On my Linux system,
> with this patch, the Qt terminal works as well as before.

Thanks Jérôme.  From Mojca's comments, it sounds like this has addressed 
the major OS X issue of CoreFoundation access.  I've looked through the 
code and all seems straightforward.  I guess I like the fact that 
gnuplot_qt is now similar to the X11 terminal.  Did you have to do 
anything special with the communication channel?  Or did that just work 
out on its own?

...

Ethan/Jérôme, I have one comment about the hunk of code conditionally 
compiled into the program:

+#if QT_VERSION < 0x040700
+	/*
+	* 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

I'm wondering if instead of conditionally compiled code, whether maybe 
this would be better done as simple conditional code statements.  That 
way the binary would be portable across some compatible systems in which 
perhaps the only thing different is that one computer has a different Qt 
version than another.

There is an aboutQt() public function in the Qt utility:

http://developer.qt.nokia.com/doc/qt-4.8/qapplication.html#aboutQt

One could search the returned string for the version number and use that 
to conditionally call the setGraphicsSystem() function.  More than that, 
it might be nice if somehow one could get information from the Qt 
utility about the optional graphics selections.  (Anyone see how?)  That 
way one could select the most efficient graphics rendering and prioritize.

http://developer.qt.nokia.com/doc/qt-4.8/qapplication.html#setGraphicsSystem

I wonder if there might now be a fourth option, "openvg" which uses any 
available GPU.  Check this discussion:

http://juhaturunen.com/blog/2010/12/how-to-enable-hardware-accelerated-qml-rendering/

and

http://qtunderground.org/wiki/OpenVG

There is an interesting comment that "raster" is much slower than 
"openvg".  (And apparently Ethan found "raster" is faster than "native", 
which must really means something.)  So, with the EAM conditionally 
compiled code as it stands, "raster" is the best and only that the user 
will get.  Also, forcing "raster" as it does, there is no way to 
optionally control the choice with an environment variable.

So, I would think that the roll of this little hunk of code would be to 
achieve the greatest rendering speed, but not override any global 
environment settings for Qt.  How about something as follows

    get version from aboutQt
    if version >= Qt 4.5
       if QT_GRAPHICSSYSTEM does not exist
          pick highest rendering in order of
          "openvg", "opengl", "raster", "native"
       endif
    endif

How exactly to do the inner part, I'm not sure given no way of querying 
the Qt core.  Also, it'd be nice if setGraphicsSystem returned an error 
status, in which case one could try "openvg", if it fails try "opengl", 
if it fails try "raster".

Does this sound logical and easy to do?  If coded, is there someone with 
a GPU accelerated video card that could experiment with the 
QT_GRAPHICSSYSTEM environment variable to see how well this works.

...

One last item, once this has stabilized, check whether this line is 
necessary:

  		// Make sure the forked copy doesn't trash the history file
  		cancel_history();

Dan

Re: [ gnuplot-Bugs-3468950 ] Qt, moc and uic not found on Mac OS X

[Mojca M. <moj...@gm...>]

2012/1/7 Jérôme Lodewyck :
> Hi,
>
>        here is an update patch. It implement the idea mentioned in previous mails
> of an auxiliary program started by exec after the fork. On my Linux system,
> with this patch, the Qt terminal works as well as before.
>
> Le Vendredi 6 Janvier 2012 15:14:47 vous avez écrit :
>> It has its flaws, but I can finally see it plot a graph.
>>
>> So, here's a list of problems:
>>
>> 1.) Your headers don't compile
>
> That should be fixed in the new patch
>
>> 2.) When I plot something, two windows pop up in "dashboard" (or
>> however the space is called). The first one doesn't respond to
>> anything and I can only force-quit it (resulting in "Qt terminal
>> communication error: select() error Killed: 9"), but the second one
>> works fine. If I quit the second one (it allows me to do that
>> gracefully), I get
>>
>> > Quit application 23586
>>
>> Quit application 23605
>> Qt terminal communication error: select() error
>>
>> and gnuplot is still alive, except that at the next "plot <something>"
>> it enters some infinit loop without doing anything. Only killing the
>> first window also kills gnuplot itself.
>>
>> Is there a way to help you debug the problem?
>
> In the constructor, QtGnuplotApplication sets
> setQuitOnLastWindowClosed(false);
> which forbids the program to quit when you close the terminal window.

Just to make it clear: if I just close the window, there is no error
at all, but the application keeps running. But if I explicitly ask it
to quit (which it allows me to do without a problem), I get the
following:

    > Quit application 34327 false
    Qt terminal communication error: select() error 9 Bad file descriptor

    gnuplot>

and if I try to plot something again, it just takes forever and
doesn't do anything at all. If I exit AquaTerm or X11, there are no
such problems and next plot open AquaTerm or X11 again. Oh, wait, I
checked again. If I exit X11 I get:

    > XIO:  fatal IO error 35 (Resource temporarily unavailable) on X
server "/tmp/launch-QIgba0/org.x:0"
          after 544 requests (532 known processed) with 0 events remaining.

but next plot command reopens it and continues as if nothing happened.


> This
> way, the program is still listening to events from gnuplot, and can open new
> windows when a new plot is requested. The application only quits when gnuplot
> exits. Apparently, this process is broken on OS X since the destructor of the
> QtGnuplotApplication (which prints the "Quit application 23605" mesage) is
> called when you close the terminal window.

When I exit the application actually, not just close the window.

> I have added the value of
> quitOnLastWindowClosed to this message to check whether this property is
> broken or overridden. Could you try again ?

See above. The ps now says:

mojca          34327   0,0  0,4  2540360  22876 s024  S+    4:30pm
0:02.07 gnuplot_qt
mojca          34326   0,0  0,4  2531780  21640 s024  S+    4:30pm
0:00.44 ./inst/bin/gnuplot

> As for the additional window, I have no clue... Is there a way in OS X to find
> out the pid of a window, to check whether it is open by gunplot or gnuplot_qt
> ? Could you send the output of "ps auxwww" (or rather the lines that contain
> "gnuplot") ?

One window bears the name gnuplot (the non responsive one) and the
other one gnuplot_qt (the responsive one with the plot and proper
icon).

After I exit the gnuplot_qt window the ps shows me:

mojca          34326   0,0  0,4  2531780  21728 s024  S+    4:30pm
0:11.01 ./inst/bin/gnuplot
mojca          34327   0,0  0,0        0      0 s024  Z+    4:30pm
0:00.00 (gnuplot_qt)

Thank you very much for fixing QTVER.


Oh, I just realized. I can comment out
    QApplication* application = new QApplication(argc, (char**)( NULL));
in qt_term.cpp and then I don't get the second unresponsive window.
But then I get warnings
    QFont: Must construct a QApplication before a QFont
for every plot command. Apart from that, most things seem to work just
fine (mouse clipping works, resizing works apart from zillions of
warning about QFont).

And for a change, now I can use Shift+scrolling, Alt+Scrolling, ...
for zoom in/out, slide left/right, ... (maybe I didn't get the order
right, but that's not important) which didn't work yesterday. All I
was able to get to work yesterday way scrolling up and down.


One semi-nasty problem is that when loading a demo and when I get a
request to hit enter, I need to manually switch back to window with
terminal (with mouse or apple-tab) to be able to enter something into
terminal. X11 works optimally. I always see the graphic on top (if
plotting window was hidden, it gets displayed on top), but keyboard
focus stays in terminal.

Another funny experience: I switched from qt to x11. I then tried to
manipulate focus on window with qt plot, but of course nothing worked.
Then I switched back to qt and terminal started rolling (trying to
obey all the previous scrolling commands that I tried to use while
they didn't work).

Apart from that ... it looks a lot better now after commenting out
that line (still many glitches, but a good start).

Mojca

Re: [ gnuplot-Bugs-3468950 ] Qt, moc and uic not found on Mac OS X

[Mojca M. <moj...@gm...>]

2012/1/7 Jérôme Lodewyck:
> Hi,
>
>        here is an update patch. It implement the idea mentioned in previous mails
> of an auxiliary program started by exec after the fork. On my Linux system,
> with this patch, the Qt terminal works as well as before.
>
> Le Vendredi 6 Janvier 2012 15:14:47 vous avez écrit :
>> It has its flaws, but I can finally see it plot a graph.
>>
>> So, here's a list of problems:
>>
>> 1.) Your headers don't compile
>
> That should be fixed in the new patch

Thank you for the patch. I will test it now. (Where should the image
from 	setWindowIcon(QIcon(":/images/gnuplot")); come from?)

> As for the additional window, I have no clue... Is there a way in OS X to find
> out the pid of a window, to check whether it is open by gunplot or gnuplot_qt
> ? Could you send the output of "ps auxwww" (or rather the lines that contain
> "gnuplot") ?

>From the old patch:

mojca          27697   0,0  0,4  2538428  20716 s024  S+    2:51pm
0:00.43 gnuplot_qt
mojca          27696   0,0  0,4  2533056  21648 s024  S+    2:51pm
0:00.36 ./inst/bin/gnuplot

If I close the window with the plot (and one "window" remains):

mojca          27697   0,0  0,0        0      0 s024  Z+    2:51pm
0:00.00 (gnuplot_qt)
mojca          27696   0,0  0,4  2532008  21648 s024  S+    2:51pm
0:00.37 ./inst/bin/gnuplot

It looks to me as if one non-functional "window" belongs to gnuplot
(when you fork and so on) and the working one belongs to gnuplot_qt.

Let me be clear: there are two windows/programs displayed in dock. The
real window cannot be seen if I try to "apple-tab" to it and it is not
responding to anything.

>> 3.) Print! WOW! I was really happy about that. However:
>> > Jan  6 15:11:53 smurfette.local gnuplot_qt[23619] <Error>:
>> > kCGErrorIllegalArgument: _CGSFindSharedWindow: WID -1
>> Jan  6 15:11:53 smurfette.local gnuplot_qt[23619] <Error>:
>> kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to catch
>> errors as they are logged.
>> Jan  6 15:11:53 smurfette.local gnuplot_qt[23619] <Error>:
>> kCGErrorIllegalArgument:
>> CGSSetWindowShadowAndRimParametersWithStretch: Invalid window
>> 0xffffffff
>
> Is the "print" window displayed or not ?

Print dialog box listing printers etc.? No, it isn't.

>> (Export to PDF create A4 instead of what's on screen, but that's not
>> related to your patch.)
>
> Yes, I have scratched my head about this one, but did not find any solution.

I can also take a look, but that is a much lower priority.

Mojca

Re: [ gnuplot-Bugs-3468950 ] Qt, moc and uic not found on Mac OS X

[Jérôme L. <lod...@us...>]

Hi,

	here is an update patch. It implement the idea mentioned in previous mails 
of an auxiliary program started by exec after the fork. On my Linux system, 
with this patch, the Qt terminal works as well as before.

Le Vendredi 6 Janvier 2012 15:14:47 vous avez écrit :
> It has its flaws, but I can finally see it plot a graph.
> 
> So, here's a list of problems:
> 
> 1.) Your headers don't compile

That should be fixed in the new patch

> 2.) When I plot something, two windows pop up in "dashboard" (or
> however the space is called). The first one doesn't respond to
> anything and I can only force-quit it (resulting in "Qt terminal
> communication error: select() error Killed: 9"), but the second one
> works fine. If I quit the second one (it allows me to do that
> gracefully), I get
> 
> > Quit application 23586
> 
> Quit application 23605
> Qt terminal communication error: select() error
> 
> and gnuplot is still alive, except that at the next "plot <something>"
> it enters some infinit loop without doing anything. Only killing the
> first window also kills gnuplot itself.
> 
> Is there a way to help you debug the problem?

In the constructor, QtGnuplotApplication sets
setQuitOnLastWindowClosed(false);
which forbids the program to quit when you close the terminal window. This 
way, the program is still listening to events from gnuplot, and can open new 
windows when a new plot is requested. The application only quits when gnuplot 
exits. Apparently, this process is broken on OS X since the destructor of the 
QtGnuplotApplication (which prints the "Quit application 23605" mesage) is 
called when you close the terminal window. I have added the value of 
quitOnLastWindowClosed to this message to check whether this property is 
broken or overridden. Could you try again ?

As for the additional window, I have no clue... Is there a way in OS X to find 
out the pid of a window, to check whether it is open by gunplot or gnuplot_qt 
? Could you send the output of "ps auxwww" (or rather the lines that contain 
"gnuplot") ?

> 3.) Print! WOW! I was really happy about that. However:
> > Jan  6 15:11:53 smurfette.local gnuplot_qt[23619] <Error>:
> > kCGErrorIllegalArgument: _CGSFindSharedWindow: WID -1
> Jan  6 15:11:53 smurfette.local gnuplot_qt[23619] <Error>:
> kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to catch
> errors as they are logged.
> Jan  6 15:11:53 smurfette.local gnuplot_qt[23619] <Error>:
> kCGErrorIllegalArgument:
> CGSSetWindowShadowAndRimParametersWithStretch: Invalid window
> 0xffffffff

Is the "print" window displayed or not ?

> (Export to PDF create A4 instead of what's on screen, but that's not
> related to your patch.)

Yes, I have scratched my head about this one, but did not find any solution.

Jérôme

Re: screendump and Qt - Re: Getting ready to put out a 4.6 release candidate

[Mojca M. <moj...@gm...>]

On Sat, Jan 7, 2012 at 01:12, Petr Mikulik wrote:
>> I really like the fact that it has "export to PDF", "Print" functionality
>> and auto-resize the plot, none of which is present in wxt.
>
> I like it too. It remembers me that gnuplot on MSW has command "screendump"
> which invokes the print dialog. What about making this command working also
> for Qt?

What is the difference between screendump and print then?

Mojca