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

Re: Version 5: Dashes, Monochrome, Postscript

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

On Monday, 23 June, 2014 14:20:48 Philipp K. Janert wrote:
> On Mon, 23 Jun 2014 23:10:32 +0200
> Christoph Bersch <us...@be...> wrote:
> 
> > Zitat von "Philipp K. Janert" <ja...@ie...>:
> > >
> > > Is there a way to turn on "dashed" plot styles
> > > again, without having to individually set each
> > > line separately?
> > 
> > You can use
> > 
> > set for [i=1:8] linetype i dashtype i
> 
> Thanks, that (mostly) works.

For now I recommend
   load '.../share/colors_mono.gp'

There was some discussion of building this in somehow
rather than requiring a separate "load" command.
One option is to add a "mono" option to the new
"set colors" command.

The drawback there is possible confusion that the existing
options (default | podo | classic) affect _only_ color, whereas
"mono" would affect color and linewidth and dash pattern.

Also related:

There is a proposal to add a command that would set
a repeat cycle for dashtypes, so that patterns 1-N would
be repeated for linetypes N+1 - 2N and so on.

We currently have such a command for linetypes 
"set linetype cycle"
but not for point types or dash patterns.

> For some reason, solid black (lt 1) seems
> twice as thick in postscript output than
> the dashed lines. Should I expect that?

That is a known [unintended] problem. 
It's not obvious to me how to fix it, but I hope something will
be possible for -rc2.

> Also: there used to be a special line type 0
> (for grid lines, and such). Does that still 
> exist?

Yes. 


	Ethan

> Finally: To drop "solid|dashed" from terminal
> specifications is a MAJOR breakage of backwards
> compatibility. Should that not be made optional?
> (At the very least, it should be included in the
> list of "incompatible changes".)
> 
> > 
> > for this.
> > 
> > Christoph

Re: Version 5: Dashes, Monochrome, Postscript

[Philipp K. J. <ja...@ie...>]

On Mon, 23 Jun 2014 23:10:32 +0200
Christoph Bersch <us...@be...> wrote:

> Zitat von "Philipp K. Janert" <ja...@ie...>:
> >
> > Is there a way to turn on "dashed" plot styles
> > again, without having to individually set each
> > line separately?
> 
> You can use
> 
> set for [i=1:8] linetype i dashtype i

Thanks, that (mostly) works.

For some reason, solid black (lt 1) seems
twice as thick in postscript output than
the dashed lines. Should I expect that?

Also: there used to be a special line type 0
(for grid lines, and such). Does that still 
exist?

Finally: To drop "solid|dashed" from terminal
specifications is a MAJOR breakage of backwards
compatibility. Should that not be made optional?
(At the very least, it should be included in the
list of "incompatible changes".)

> 
> for this.
> 
> Christoph
> 
> 
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and
> Eclipse Turn processes into business applications with Bonita BPM
> Community Edition Quickly connect people, data, and systems into
> organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: How to get key information from qt terminal to gnuplot

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

----- Original Message -----
> From: Tait
> To: gnuplot-bet
> Cc: 
> Date: 2014/6/24, Tue 05:32
> Subject: Re: How to get key information from qt terminal to gnuplot
> 
> Ethan A Merritt said (on 2014/06/23):
>>  Isn't it true that all terminals already do the necessary key-code
>>  processing so that they can send key events to the core code in mouse.c?
>> 
>>  For example, does  "mouselabels.dem" work on MSWin?   That demo 
> reads
>>  keystrokes in the plot window, turns them into labels in the core code, and 
> then
>>  replots with the new label.   If the demo works, it shows that keycodes 
> including
>>  the space-key are correctly transmitted to the core code.
>> 
>>      Ethan
> 
> The mouselabels demo does work* on Windows in wxt and windows terms,
> although one cannot create a label containing a space (because the
> space brings up the console) or q (it is ignored).
> 
> * for some value of "works"... The Windows terminal tends to eat
> keystrokes unless they're typed much more slowly than a normal typing
> pace. The wxt terminal places the red text on top of the black, making
> it impossible to read either, and sometimes (I haven't figured out how
> to replicate it on-demand) backspace doesn't work. Both seem to add an
> extra "\033" label after hitting ESC to end label input. None of 
> the
> Windows builds have a qt terminal to try.


Tait is right.
For qt on windows, mouselabels demo does not work.

As the first work, I will try to mouselabels demo to wrok on qt for windows.

Tatsuro

Re: Version 5: Dashes, Monochrome, Postscript

[Christoph B. <us...@be...>]

Zitat von "Philipp K. Janert" <ja...@ie...>:
>
> Is there a way to turn on "dashed" plot styles
> again, without having to individually set each
> line separately?

You can use

set for [i=1:8] linetype i dashtype i

for this.

Christoph

Version 5: Dashes, Monochrome, Postscript

[Philipp K. J. <ja...@ie...>]

As of version 5, the "solid/dashed" specifiers
to "set terminal" are ignored (and all lines are
by default drawn solid).

That's probably fine for color terminals, but
it's a real problem for monochrome terminals.

In particular when preparing graphs for printing
(using the postscript terminal), that produces
graphs with all lines being indistinguishably
solid black.

That breaks A LOT of saved plot commands. (For
me personally, it is a fiasco. I don't know
about others.)

Is there a way to turn on "dashed" plot styles
again, without having to individually set each 
line separately?

Best,

		Ph.



 

Re: How to get key information from qt terminal to gnuplot

[Tait <gnu...@t4...>]

Ethan A Merritt <sf...@us...> said (on 2014/06/23):
> Isn't it true that all terminals already do the necessary key-code
> processing so that they can send key events to the core code in mouse.c?
> 
> For example, does  "mouselabels.dem" work on MSWin?   That demo reads
> keystrokes in the plot window, turns them into labels in the core code, and then
> replots with the new label.   If the demo works, it shows that keycodes including
> the space-key are correctly transmitted to the core code.
> 
> 	Ethan

The mouselabels demo does work* on Windows in wxt and windows terms,
although one cannot create a label containing a space (because the
space brings up the console) or q (it is ignored).

* for some value of "works"... The Windows terminal tends to eat
keystrokes unless they're typed much more slowly than a normal typing
pace. The wxt terminal places the red text on top of the black, making
it impossible to read either, and sometimes (I haven't figured out how
to replicate it on-demand) backspace doesn't work. Both seem to add an
extra "\033" label after hitting ESC to end label input. None of the
Windows builds have a qt terminal to try.

Re: How to get key information from qt terminal to gnuplot

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

On Tuesday, 24 June, 2014 04:49:36 Tatsuro MATSUOKA wrote:
> 
> ----- Original Message -----
> > From: sfeam 
> > To: gnuplot-beta
> > Cc: Petr Mikulik 
> > Date: 2014/6/23, Mon 14:52
> > Subject: Re: How to get key information from qt terminal to gnuplot
> > 
> Although Ethan's idea is attractive, I will try console raise feature for qt terminal by Petr's way at this moment.
> To implement Ethan's idea, we have to have wrapper function to get keycode.
> This is because each terminal implements the way to get keycode diffident way and keycode map for each the terminal is different (especially of windows).
> 
> I will wait that someone who has good knowledge inter platform try to implement.

Isn't it true that all terminals already do the necessary key-code
processing so that they can send key events to the core code in mouse.c?

For example, does  "mouselabels.dem" work on MSWin?   That demo reads
keystrokes in the plot window, turns them into labels in the core code, and then
replots with the new label.   If the demo works, it shows that keycodes including
the space-key are correctly transmitted to the core code.

	Ethan

Re: How to get key information from qt terminal to gnuplot

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

----- Original Message -----
> From: sfeam 
> To: gnuplot-beta
> Cc: Petr Mikulik 
> Date: 2014/6/23, Mon 14:52
> Subject: Re: How to get key information from qt terminal to gnuplot
> 
Although Ethan's idea is attractive, I will try console raise feature for qt terminal by Petr's way at this moment.
To implement Ethan's idea, we have to have wrapper function to get keycode.
This is because each terminal implements the way to get keycode diffident way and keycode map for each the terminal is different (especially of windows).

I will wait that someone who has good knowledge inter platform try to implement.

Regards

Tatsuro

Re: How to get key information from qt terminal to gnuplot

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

Correction


----- Original Message -----
> From: Tatsuro MATSUOKA
> To: Merritt Ethan ; gnuplot-bet
> Cc: Petr Mikulik 
> Date: 2014/6/23, Mon 18:23
> Subject: Re: How to get key information from qt terminal to gnuplot
> 
> ----- Original Message -----
> 
>>  From: sfeam 
>>  To: gnuplot-beta
>>  Cc: Petr Mikulik 
>>  Date: 2014/6/23, Mon 14:52
>>  Subject: Re: How to get key information from qt terminal to gnuplot
>>  
>  
>>  That may have been true at the time, but currently the main program is 
> linked
>>  against both gdk and X11 when it is built on linux.  So the same call
>>  that wxt uses could be placed in the main code. 
> 
>>  I do not know about MSWin.
> 
> For windows terminal (but no wxt on windows), 
> SPACE_RAISES_CONSOLE feature is implemented in wgraph.c
> 
> Key code is obtained in windows way.
> 
> *************************************************************
> 
> case WM_CHAR:
> /* All 'normal' keys (letters, digits and the likes) end up
> * here... */
> #ifndef DISABLE_SPACE_RAISES_CONSOLE
> if (wParam == VK_SPACE) {
> WinRaiseConsole();
> return 0L;
> }
> *************************************************************
> 
> WinRaiseConsole() is described in winmain.c
> 
> 
> 
> 
> 
> *************************************************************
> 
> void
> WinRaiseConsole(void)
> {
> HWND console = NULL;
> #ifndef WGP_CONSOLE
> console = textwin.hWndParent;
> #else
> console = GetConsoleWindow();
> #endif
> if (console != NULL) {
> ShowWindow(console, SW_SHOWNORMAL);
> BringWindowToTop(console);
> }
> }
> *************************************************************
> 
> 
> 
> 
> In wxt terminal on windows (wxt_gui.cpp), key code scan seems to be wrapped by 
> event.GetKeyCode()
> 
> Using the keycode
> *************************************************************
> switch (keycode) {
> 
> 
> #ifndef DISABLE_SPACE_RAISES_CONSOLE
> case WXK_SPACE :
> if ((wxt_ctrl==yes && event.ControlDown())
> || wxt_ctrl!=yes) {
> RaiseConsoleWindow();
> return;
> } else {
> gp_keycode = ' ';
> break;
> }
> #endif /* DISABLE_SPACE_RAISES_CONSOLE */
> *************************************************************
> Function RaiseConsoleWindow() is described in winmain.c


should be 
 Function RaiseConsoleWindow() is described in wxtPanel::RaiseConsoleWindow()


> wxtPanel::RaiseConsoleWindow() is described dependent on platform,
> 
> 
> The wxt terminal for windows uses  WinRaiseConsole() in winmain.c.
> 
> For windows terminal it should be required to write wrapper function to keycode 
> to implement the Ethan's idea.
> 
> Tatsuro 
> 
> 

Re: How to get key information from qt terminal to gnuplot

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

----- Original Message -----

> From: sfeam 
> To: gnuplot-beta
> Cc: Petr Mikulik 
> Date: 2014/6/23, Mon 14:52
> Subject: Re: How to get key information from qt terminal to gnuplot
> 
 
> That may have been true at the time, but currently the main program is linked
> against both gdk and X11 when it is built on linux.  So the same call
> that wxt uses could be placed in the main code. 

> I do not know about MSWin.

For windows terminal (but no wxt on windows), 
SPACE_RAISES_CONSOLE feature is implemented in wgraph.c

Key code is obtained in windows way.

*************************************************************

case WM_CHAR:
/* All 'normal' keys (letters, digits and the likes) end up
* here... */
#ifndef DISABLE_SPACE_RAISES_CONSOLE
if (wParam == VK_SPACE) {
WinRaiseConsole();
return 0L;
}
*************************************************************

WinRaiseConsole() is described in winmain.c





*************************************************************

void
WinRaiseConsole(void)
{
HWND console = NULL;
#ifndef WGP_CONSOLE
console = textwin.hWndParent;
#else
console = GetConsoleWindow();
#endif
if (console != NULL) {
ShowWindow(console, SW_SHOWNORMAL);
BringWindowToTop(console);
}
}
*************************************************************




In wxt terminal on windows (wxt_gui.cpp), key code scan seems to be wrapped by 
event.GetKeyCode()

Using the keycode
*************************************************************
switch (keycode) {


#ifndef DISABLE_SPACE_RAISES_CONSOLE
case WXK_SPACE :
if ((wxt_ctrl==yes && event.ControlDown())
|| wxt_ctrl!=yes) {
RaiseConsoleWindow();
return;
} else {
gp_keycode = ' ';
break;
}
#endif /* DISABLE_SPACE_RAISES_CONSOLE */
*************************************************************
Function RaiseConsoleWindow() is described in winmain.c



wxtPanel::RaiseConsoleWindow() is described dependent on platform,


The wxt terminal for windows uses  WinRaiseConsole() in winmain.c.

For windows terminal it should be required to write wrapper function to keycode to implement the Ethan's idea.

Tatsuro 

Re: How to get key information from qt terminal to gnuplot

[sfeam <sf...@us...>]

On Monday, 23 June 2014 12:08:51 AM Petr Mikulik wrote:
> > Why does the "raise console" function use different code for each
> > terminal type?  The console is the same no matter what terminal is
> > in use.  Am I missing something?
> >
> > My current thinking is that the special code to raise the console
> > should be removed from all terminals.
> > Instead we could add a routine in mouse.c that responds to the
> > keystroke after it is passed to the gnuplot core.  This would be
> > shared by all terminals.
> 
> At the time I've implemented it, I've found it is not possible.
> 
> The gnuplot executable is a console application, while the graphic window is 
> X11, OS/2 Presentation Manager, Windows etc. application (communicating via 
> different ways) and thus compiled and linked differently. So gnuplot binary is 
> not linked to the respective X11/os2/... libraries needed to call the window 
> manager in order to manipulate another window.

That may have been true at the time, but currently the main program is linked
against both gdk and X11 when it is built on linux.  So the same call
that wxt uses could be placed in the main code.  I do not know about MSWin.

	Ethan

Re: How to get key information from qt terminal to gnuplot

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

> Why does the "raise console" function use different code for each
> terminal type?  The console is the same no matter what terminal is
> in use.  Am I missing something?
>
> My current thinking is that the special code to raise the console
> should be removed from all terminals.
> Instead we could add a routine in mouse.c that responds to the
> keystroke after it is passed to the gnuplot core.  This would be
> shared by all terminals.

At the time I've implemented it, I've found it is not possible.

The gnuplot executable is a console application, while the graphic window is 
X11, OS/2 Presentation Manager, Windows etc. application (communicating via 
different ways) and thus compiled and linked differently. So gnuplot binary is 
not linked to the respective X11/os2/... libraries needed to call the window 
manager in order to manipulate another window.

---
Petr

Re: How to get key information from qt terminal to gnuplot

[sfeam <sf...@us...>]

On Monday, 23 June 2014 04:59:06 AM Tatsuro MATSUOKA wrote:
> ----- Original Message -----
> 
> > From: Tatsuro MATSUOKA 
> > To: Merritt Ethan ; gnuplot-beta
> > Cc: 
> > Date: 2014/6/23, Mon 04:13
> > Subject: Re: How to get key information from qt terminal to gnuplot
> > ----- Original Message -----
> >>  From: sfeam 
> >>  To: gnuplot-beta Tatsuro MATSUOKA 
> >>  Cc: 
> >>  Date: 2014/6/23, Mon 01:37
> >>  Subject: Re: How to get key information from qt terminal to gnuplot
> >> 
> >>  On Sunday, 22 June 2014 05:36:20 PM Tatsuro MATSUOKA wrote:
> >>>   Hello
> >>> 
> >>> 
> >> 
> > http://gnuplot.10905.n7.nabble.com/Spacebar-does-not-raise-command-window-with-wxt-terminal-td18540.html
> >>> 
> >>> 
> >>>   For qt terminal, this feature seems not to be implemented. (Right?)
> >>>   Although I do not have enough knowledge, I tried to implement it.
> >>>   I looked into qt_term.cpp and QtGnuplotScene.cpp.
> >>> 
> >>>   In QtGnuplotScene.cpp, qt terminal seems to return key information in 
> >>> 
> >>>   void QtGnuplotScene::keyPressEvent(QKeyEvent* event)
> >>>   <snip>
> >>>   live = m_eventHandler->postTermEvent(GE_keypress,
> >>>   int(m_lastMousePos.x()), int(m_lastMousePos.y()), key, 0, m_widget);
> >>> 
> >>>   While in qt_term.cpp,
> >>> 
> >>>   /*-------------------------------------------------------
> >>>    * Communication terminal -> gnuplot
> >>>    *-------------------------------------------------------*/
> >>> 
> >>>   bool qt_processTermEvent(gp_event_t* event)
> >>>   <snip>
> >>>   if ((event->type == GE_keypress) && (paused_for_mouse & 
> > 
> >>  PAUSE_KEYSTROKE) && (event->par1 > '\0'))
> >>> 
> >>> 
> >>>   However,
> >>>   'struct gp_event_t' has no member named 'key'
> >>> 
> >>> 
> >>>   How I do get key information from qt terminal to gnuplot?
> >> 
> >>  The simplest way is
> >>  gnuplot>  bind "<key>" "command to execute"
> >> 
> >>  No code change to the qt terminal is needed. However there is not
> >>  currently a "command to execute" that raises the console window.
> >>  The "raise" command acts on the plot window, not the console 
> > window.
> >> 
> >>  Why does the "raise console" function use different code for each
> >>  terminal type?  The console is the same no matter what terminal is
> >>  in use.  Am I missing something?  
> >> 
> >>  My current thinking is that the special code to raise the console
> >>  should be removed from all terminals.
> >>  Instead we could add a routine in mouse.c that responds to the
> >>  keystroke after it is passed to the gnuplot core.  This would be
> >>  shared by all terminals.  
> >> 
> >>      Ethan
> > OK. I agree with you.
> > Thanks for the pointer.
> 
> 
> Although I agree with Ethan, it is important to know the code to get information what key pressed 
> from gnuplot_qt to gnuplot. I will appreciate that some will show the way.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
QtGnuplotScene.cpp (line 965)
        live = m_eventHandler->postTermEvent(GE_keypress,
                int(m_lastMousePos.x()), int(m_lastMousePos.y()), key, 0, m_widget);

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
QtGnuplotEvent.cpp:
bool QtGnuplotEventHandler::postTermEvent(int type, int mx, int my, int par1, int par2, QtGnuplotWidget* widget)
{
        if ((m_socket == 0) || (m_socket->state() != QLocalSocket::ConnectedState) || (widget && !widget->isActive()))
                return false;

        gp_event_t event;
        event.type = type;
        event.mx = mx;
        event.my = my;
        event.par1 = par1;
        event.par2 = par2;
        event.winid = 0; // We don't forward any window id to gnuplot
        m_socket->write((char*) &event, sizeof(gp_event_t));

        return true;
}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%
qt_term.cpp:
/*-------------------------------------------------------
 * Communication terminal -> gnuplot
 *-------------------------------------------------------*/

bool qt_processTermEvent(gp_event_t* event)
{
 [...]
 do_event(event);

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
mouse.c:  do_event(struct gp_event_t *ge)

    case GE_keypress:
        event_keypress(ge, TRUE);
        break;

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
mouse.c: event_keypress()



           Ethan

Re: How to get key information from qt terminal to gnuplot

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

----- Original Message -----

> From: Tatsuro MATSUOKA 
> To: Merritt Ethan ; gnuplot-beta
> Cc: 
> Date: 2014/6/23, Mon 04:13
> Subject: Re: How to get key information from qt terminal to gnuplot
> ----- Original Message -----
>>  From: sfeam 
>>  To: gnuplot-beta Tatsuro MATSUOKA 
>>  Cc: 
>>  Date: 2014/6/23, Mon 01:37
>>  Subject: Re: How to get key information from qt terminal to gnuplot
>> 
>>  On Sunday, 22 June 2014 05:36:20 PM Tatsuro MATSUOKA wrote:
>>>   Hello
>>> 
>>> 
>> 
> http://gnuplot.10905.n7.nabble.com/Spacebar-does-not-raise-command-window-with-wxt-terminal-td18540.html
>>> 
>>> 
>>>   For qt terminal, this feature seems not to be implemented. (Right?)
>>>   Although I do not have enough knowledge, I tried to implement it.
>>>   I looked into qt_term.cpp and QtGnuplotScene.cpp.
>>> 
>>>   In QtGnuplotScene.cpp, qt terminal seems to return key information in 
>>> 
>>>   void QtGnuplotScene::keyPressEvent(QKeyEvent* event)
>>>   <snip>
>>>   live = m_eventHandler->postTermEvent(GE_keypress,
>>>   int(m_lastMousePos.x()), int(m_lastMousePos.y()), key, 0, m_widget);
>>> 
>>>   While in qt_term.cpp,
>>> 
>>>   /*-------------------------------------------------------
>>>    * Communication terminal -> gnuplot
>>>    *-------------------------------------------------------*/
>>> 
>>>   bool qt_processTermEvent(gp_event_t* event)
>>>   <snip>
>>>   if ((event->type == GE_keypress) && (paused_for_mouse & 
> 
>>  PAUSE_KEYSTROKE) && (event->par1 > '\0'))
>>> 
>>> 
>>>   However,
>>>   'struct gp_event_t' has no member named 'key'
>>> 
>>> 
>>>   How I do get key information from qt terminal to gnuplot?
>> 
>>  The simplest way is
>>  gnuplot>  bind "<key>" "command to execute"
>> 
>>  No code change to the qt terminal is needed. However there is not
>>  currently a "command to execute" that raises the console window.
>>  The "raise" command acts on the plot window, not the console 
> window.
>> 
>>  Why does the "raise console" function use different code for each
>>  terminal type?  The console is the same no matter what terminal is
>>  in use.  Am I missing something?  
>> 
>>  My current thinking is that the special code to raise the console
>>  should be removed from all terminals.
>>  Instead we could add a routine in mouse.c that responds to the
>>  keystroke after it is passed to the gnuplot core.  This would be
>>  shared by all terminals.  
>> 
>>      Ethan
> OK. I agree with you.
> Thanks for the pointer.


Although I agree with Ethan, it is important to know the code to get information what key pressed 
from gnuplot_qt to gnuplot. I will appreciate that some will show the way.

Tatsuro 

Re: How to get key information from qt terminal to gnuplot

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

----- Original Message -----
> From: sfeam 
> To: gnuplot-beta Tatsuro MATSUOKA 
> Cc: 
> Date: 2014/6/23, Mon 01:37
> Subject: Re: How to get key information from qt terminal to gnuplot
> 
> On Sunday, 22 June 2014 05:36:20 PM Tatsuro MATSUOKA wrote:
>>  Hello
>> 
>> 
> http://gnuplot.10905.n7.nabble.com/Spacebar-does-not-raise-command-window-with-wxt-terminal-td18540.html
>> 
>> 
>>  For qt terminal, this feature seems not to be implemented. (Right?)
>>  Although I do not have enough knowledge, I tried to implement it.
>>  I looked into qt_term.cpp and QtGnuplotScene.cpp.
>> 
>>  In QtGnuplotScene.cpp, qt terminal seems to return key information in 
>> 
>>  void QtGnuplotScene::keyPressEvent(QKeyEvent* event)
>>  <snip>
>>  live = m_eventHandler->postTermEvent(GE_keypress,
>>  int(m_lastMousePos.x()), int(m_lastMousePos.y()), key, 0, m_widget);
>> 
>>  While in qt_term.cpp,
>> 
>>  /*-------------------------------------------------------
>>   * Communication terminal -> gnuplot
>>   *-------------------------------------------------------*/
>> 
>>  bool qt_processTermEvent(gp_event_t* event)
>>  <snip>
>>  if ((event->type == GE_keypress) && (paused_for_mouse & 
> PAUSE_KEYSTROKE) && (event->par1 > '\0'))
>> 
>> 
>>  However,
>>  'struct gp_event_t' has no member named 'key'
>> 
>> 
>>  How I do get key information from qt terminal to gnuplot?
> 
> The simplest way is
> gnuplot>  bind "<key>" "command to execute"
> 
> No code change to the qt terminal is needed. However there is not
> currently a "command to execute" that raises the console window.
> The "raise" command acts on the plot window, not the console window.
> 
> Why does the "raise console" function use different code for each
> terminal type?  The console is the same no matter what terminal is
> in use.  Am I missing something?  
> 
> My current thinking is that the special code to raise the console
> should be removed from all terminals.
> Instead we could add a routine in mouse.c that responds to the
> keystroke after it is passed to the gnuplot core.  This would be
> shared by all terminals.  
> 
>     Ethan
OK. I agree with you.
Thanks for the pointer.

Thanks!

Re: How to get key information from qt terminal to gnuplot

[sfeam <sf...@us...>]

On Sunday, 22 June 2014 05:36:20 PM Tatsuro MATSUOKA wrote:
> Hello
> 
> http://gnuplot.10905.n7.nabble.com/Spacebar-does-not-raise-command-window-with-wxt-terminal-td18540.html
> 
> 
> For qt terminal, this feature seems not to be implemented. (Right?)
> Although I do not have enough knowledge, I tried to implement it.
> I looked into qt_term.cpp and QtGnuplotScene.cpp.
> 
> In QtGnuplotScene.cpp, qt terminal seems to return key information in 
> 
> void QtGnuplotScene::keyPressEvent(QKeyEvent* event)
> <snip>
> live = m_eventHandler->postTermEvent(GE_keypress,
> int(m_lastMousePos.x()), int(m_lastMousePos.y()), key, 0, m_widget);
> 
> While in qt_term.cpp,
> 
> /*-------------------------------------------------------
>  * Communication terminal -> gnuplot
>  *-------------------------------------------------------*/
> 
> bool qt_processTermEvent(gp_event_t* event)
> <snip>
> if ((event->type == GE_keypress) && (paused_for_mouse & PAUSE_KEYSTROKE) && (event->par1 > '\0'))
> 
> 
> However,
> 'struct gp_event_t' has no member named 'key'
> 
> 
> How I do get key information from qt terminal to gnuplot?

The simplest way is
gnuplot>  bind "<key>" "command to execute"

No code change to the qt terminal is needed. However there is not
currently a "command to execute" that raises the console window.
The "raise" command acts on the plot window, not the console window.

Why does the "raise console" function use different code for each
terminal type?  The console is the same no matter what terminal is
in use.  Am I missing something?  

My current thinking is that the special code to raise the console
should be removed from all terminals.
Instead we could add a routine in mouse.c that responds to the
keystroke after it is passed to the gnuplot core.  This would be
shared by all terminals.  

	Ethan

How to get key information from qt terminal to gnuplot

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

Hello

http://gnuplot.10905.n7.nabble.com/Spacebar-does-not-raise-command-window-with-wxt-terminal-td18540.html


For qt terminal, this feature seems not to be implemented. (Right?)
Although I do not have enough knowledge, I tried to implement it.
I looked into qt_term.cpp and QtGnuplotScene.cpp.

In QtGnuplotScene.cpp, qt terminal seems to return key information in 

void QtGnuplotScene::keyPressEvent(QKeyEvent* event)
<snip>
live = m_eventHandler->postTermEvent(GE_keypress,
int(m_lastMousePos.x()), int(m_lastMousePos.y()), key, 0, m_widget);

While in qt_term.cpp,

/*-------------------------------------------------------
 * Communication terminal -> gnuplot
 *-------------------------------------------------------*/

bool qt_processTermEvent(gp_event_t* event)
<snip>
if ((event->type == GE_keypress) && (paused_for_mouse & PAUSE_KEYSTROKE) && (event->par1 > '\0'))


However,
'struct gp_event_t' has no member named 'key'


How I do get key information from qt terminal to gnuplot?

Thank you in advance.

Tatsuro

Re: build problems with wxGTK 3.0

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

On Friday, 20 June, 2014 23:58:28 Mojca Miklavec wrote:
> 
> Before we even start discussing any further ... I just realized that
> the whole discussion is moot. Gnuplot doesn't currently support GTK 3
> at all. I tried to compile it and gnuplot uses a bunch of functions
> that no longer exist in GTK 3.
> 
> The compile errors come from the code that explicitly says:
> 
> /* FIXME : this code should be deleted, and the feature removed or
> handled differently,
>  * because it is highly platform-dependant, is not reliable because
>  * of a lot of factors (WINDOWID not set, multiple tabs in
> gnome-terminal, mechanisms
>  * to prevent focus stealing) and is inconsistent with global bindings
> mechanism ) */

Yeah, I already pointed that out.
But the code in question is only used for the "raise console" and
"raise plot window" functionality, which various people are reporting
as being broken anyhow.   It wouldn't be a big deal to disable the
code on systems where it isn't working anyhow.

> ../../src/wxterminal/wxt_gui.cpp:1417:20: error: use of undeclared
> identifier 'gdk_window_foreign_new'
>                 gdk_window_raise(gdk_window_foreign_new(windowid));
>                                  ^
> 
> 
> It looks like function being used in there explicitly depend on
> gdk/gdkx.h from GTK 2 (no longer present in GTK 3), so they explicitly
> depend on X11(?) or something like that.

As I understand it these functions used to be public but are now private.
For wx3/gtk3 you need to call some wrapper function instead.
Not a big deal, and can be deferred until the rest of it is working.

> It's also not wxWidgets' fault if gnuplot source code uses GTK
> functions that depend on X11.

Huh?   The X11 problem comes in when you _don't_ configure
X11 into gnuplot.   wxWidgets  tries to use it anyway
and complains that gnuplot didn't initialize properly.  It is exactly
wxWidgets fault.     We added the XInitThreads() call to gnuplot
because wxWidgets insisted.  Otherwise we wouldn't call this at all.


> (Disclaimer: I don't know much about GTK and X11. I might be wrong
> about diagnoses, but it looks like someone should definitely clean up
> the code saying "FIXME".)

By "clean up" you mean "delete or remove", as the FIXME says?
I think Petr would be unhappy, since apparently it does work in
KDE3 and OS/2.  It's the newer systems that are having problems.

	Ethan

Re: build problems with wxGTK 3.0

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

On Fri, Jun 20, 2014 at 6:52 PM, Allin Cottrell wrote:
> On Fri, 20 Jun 2014, Mojca Miklavec wrote:
>
>> Can you please write in pseudocode what exactly you mean / based on
>> what would you pick wxWidgets then and how?
>
>
> Well, I'm not sure if this answers all cases, but what I have in mind is as
> follows (where, e.g., "gtk2" means that gtk+-2.0 is available on the host as
> revealed by pkg-config):
>
> if user-says-prefer-gtk2
>   if gtk2 && wx-gtk2
>     use wx-gtk2
>   elif gtk3 && wx-gtk3
>     use wx-gtk3
>   endif
> else
>   if gtk3 && wx-gtk3
>     use wx-gtk3
>   elif gtk2 && wx-gtk2
>     use wx-gtk2
>   endif
> endif

Before we even start discussing any further ... I just realized that
the whole discussion is moot. Gnuplot doesn't currently support GTK 3
at all. I tried to compile it and gnuplot uses a bunch of functions
that no longer exist in GTK 3.

The compile errors come from the code that explicitly says:

/* FIXME : this code should be deleted, and the feature removed or
handled differently,
 * because it is highly platform-dependant, is not reliable because
 * of a lot of factors (WINDOWID not set, multiple tabs in
gnome-terminal, mechanisms
 * to prevent focus stealing) and is inconsistent with global bindings
mechanism ) */


../../src/wxterminal/wxt_gui.cpp:1417:20: error: use of undeclared
identifier 'gdk_window_foreign_new'
                gdk_window_raise(gdk_window_foreign_new(windowid));
                                 ^


It looks like function being used in there explicitly depend on
gdk/gdkx.h from GTK 2 (no longer present in GTK 3), so they explicitly
depend on X11(?) or something like that.

It's also not wxWidgets' fault if gnuplot source code uses GTK
functions that depend on X11.

(Disclaimer: I don't know much about GTK and X11. I might be wrong
about diagnoses, but it looks like someone should definitely clean up
the code saying "FIXME".)

Discussing configuration for GTK 3 makes no sense if the source code
isn't even compatible with GTK 3. I wasn't able to build gnuplot
against wxGTK on Mac yet because I need to recompile wxWidgets first
(to link against GTK 2).

Mojca

Re: Spacebar does not raise command window with wxt terminal (also qt)

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

> So there  is no wxt terminal support for raise console window on linux unless
> you are using  gtk2 and either  KDE3 or the Gnome console terminal.
> I will add this to the docs somewhere (maybe "known limitations"?)

Spacebar raises the window on KDE3 as well as KDE4 using both x11 and wxt 
terminals, but not qt. It works with xterm, konsole, gnome-terminal.
I don't use gnome, but it worked there as well when I try the last time.

One has to set (the window manager) "prevent steal focus" to "none".
(Crazy option ... for some items it event prevents any window to pop up.)

Further, the window is raised correctly on OS/2 and Windows (thanks to unified 
window manager ... unless something is broken in newer Windows).

On KDE3, it can browse find the correct tab in multitab Konsole. 
Unfortunately, KDE4 removed the "dcop" command and replaced it by something 
else (dbus*?) which is still not completely ported from KDE3 (at least it was 
when I tried the last time - if you know whether it has been fixed, please 
tell me).

Trying to find the same "dcop" trick for gnome, noone could tell me whether 
something similar as "dcop" exists there, so the tab search was never 
implemented.

> As to the qt terminal, Tatsuro Matsuoka is correct that despite what the
> terminal help text says there is no special treatment of the space key
> in the actual code.

I think it is enough to copy the code from x11 client or from wxt terminal.

> So basically this feature exists consistently only on Windows or X11.
> And even the X11 support may depend on the window manager being used.
> The documentation should be amended to note that it is not generally
> available on linux.

It would be worth to note that this feature may be blocked by the window 
manager if "prevent steal focus" is set to something else then "none".

---
Petr

Re: Spacebar does not raise command window with wxt terminal (also qt)

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

[sigh] a correction after more testing:

If I force the definition of HAVE_GTK in config.h, then it does work
for
	KDE4 + wxWidgets 2.8 + gdk2

(the actual raise is done by a call into gdk2)
I'm not certain why the autoconfigure script wasn't setting HAVE_GTK
in my earlier tests.

So the coverage is a little better than I thought, although the 
configure script may need some tweaking.

	Ethan



On Friday, 20 June, 2014 09:53:36 Philipp K. Janert wrote:
> On Fri, 20 Jun 2014 09:33:17 -0700
> Ethan A Merritt <sf...@us...> wrote:
> 
> > 
> > I looked into this a bit.
> 
> Thanks for doing the research. I think
> this clarifies a lot. 
> 
> Is there any hope to fix this? I think this
> should treated as a bug. (It also USED to 
> work, sometime ago, if my memory serves me 
> right...)
> 
> > Here is a the relevant section of code in wxt_gui.cpp:
> > 
> > =====
> > /* FIXME : this code should be deleted, and the feature removed or
> > handled differently,
> >  * because it is highly platform-dependant, is not reliable because
> >  * of a lot of factors (WINDOWID not set, multiple tabs in
> > gnome-terminal, mechanisms
> >  * to prevent focus stealing) and is inconsistent with global
> > bindings mechanism ) */ void wxtPanel::RaiseConsoleWindow()
> > {
> > #ifdef USE_GTK
> >    [...  special case code for KDE3]
> >    [...  special case code for Gnome console]

         [ ...  code for gdk2/gtk2]

> > #endif
> >    [...  special case code for Win32]
> >    [...  special case code for OS2]
> > =======
> > 
> > Furthermore the definition of USE_GTK depends on configuration tests
> > for the locally installed gdk.h/gtk.h headers, if any.   I have tried
> > building against gtk3 headers -  no success.
> > 
> > So there  is no wxt terminal support for raise console window on
> > linux unless you are using  gtk2 and either  KDE3 or the Gnome
> > console terminal. I will add this to the docs somewhere (maybe "known
> > limitations"?)
> > 
> > 
> > As to the qt terminal, Tatsuro Matsuoka is correct that despite what
> > the terminal help text says there is no special treatment of the
> > space key in the actual code. 
> > 
> > So basically this feature exists consistently only on Windows or X11.
> > And even the X11 support may depend on the window manager being used. 
> > The documentation should be amended to note that it is not generally
> > available on linux.
> > 
> > 	Ethan
> > 
> > 
> > 
> > 
> > 
> 
> 
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: build problems with wxGTK 3.0

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

On Friday, 20 June, 2014 09:59:17 Mojca Miklavec wrote:
> On Fri, Jun 20, 2014 at 12:43 AM, Allin Cottrell wrote:
> > On Thu, 19 Jun 2014, Ethan A Merritt wrote:
> >> On Thursday, 19 June, 2014 22:27:46 Mojca Miklavec wrote:
> >>> On Thu, Jun 19, 2014 at 9:31 PM, Ethan A Merritt
> >>
> >>>>> So please also check whether wxWidgets are using gtk2 or gtk3 before
> >>>>> calling pkg-config to supply build flags.
> >>>>
> >>>>
> >>>> That's a chicken-or-egg dilemma.
> >>>> wx-config is supposed to tell us the version, but we need the version in
> >>>> order to call the correct wx-config.
> >>>
> >>>
> >>> I don't see any chicken here ;)
> >>>
> >>> Once gnuplot calls
> >>>     WX_CXXFLAGS="`$WX_CONFIG --cxxflags
> >>> it already knows which $WX_CONFIG it is calling.
> >>>
> >>> The problematic line is only
> >>>     PKG_CHECK_MODULES(GTK, [gtk+-2.0], have_gtk=yes, have_gtk=no)
> >>>
> >>> Gnuplot should run
> >>>     "$WX_CONFIG" --basename | <grep something>
> >>> before asking for gtk+-2.0.
> >>
> >>
> >> On linux (at least on my machines) there are two different wx-configs,
> >> one for wx2 and one for wx3.   You need to pick up the version from
> >> somewhere
> >> before you even know which one to run.
> >
> >
> > Running on Mac, Mojca may or may not realize that most, if not all, modern
> > Linux distros pack both gtk2 and gtk3,
> 
> Yes, I know that. I have both gtk2 and gtk3 installed myself (on a Mac).
> 
> > and therefore both variants of
> > wxWidgets may also be present.
> 
> (Theoretically the number of wxWidgets installations is only limited
> by the disk space.) So yes, I'm aware that one can have both gtk2 and
> gtk3 installed. What I don't believe though is that any linux
> distribution would ship two copies of wxWidgets30 distribution, once
> compiled against GTK 2 and once compiled against GTK 3.

Believe it or not as you choose, but the wxWidgets 3.0 package I have
here doesn't make a choice between gtk2 and gtk3 until the application
is compiled.   You have to tell it which to use.

> But for the sake of argument let's assume that a machine has all of
> the following installed:
> - wxWidgets 2.8 with GTK 2
> - wxWidgets 2.8 with GTK 3 (maybe that's not possible)
> - wxWidgets 3.0 with GTK 2
> - wxWidgets 3.0 with GTK 3
> 
> Can you please write in pseudocode what exactly you mean / based on
> what would you pick wxWidgets then and how?
> 
> > Software that supports both variants must therefore establish a policy. The
> > software that I work on, gretl, has chosen (bowing to the apparently
> > inevitable) to make gtk3 the default, if available, but we have a configure
> > option
> >
> > --enable-gtk2
> >
> > Most users won't have to worry about this. If they only have gtk2, that will
> > be used regardless; if they only have gtk3, that will be used regardless; if
> > they have both, gtk3 will be used unless they apply this "enable" flag when
> > configuring.
> 
> In the ConTeXt of gnuplot this would translate to:
> - if user has only wxWidgets 3.0, use 3.0
> - if user has only wxWidgets 2.8, use 2.8
> - if user has both, pick wxWidgets 3.0
> 
> Or what else exactly would you do with GTK versions?

I don't think any of us can provide you with pseudo-code for how to make
this work, because I don't think anyone has succeeded in getting wxWidgets3
(or gtk3?) to work on linux.    I can tell you that on my test machine

wxWidgets 3.0 + gtk3   fails to compile because of header conflicts.
wxWidgets 3.0 + gtk2   compiles but gives errors at run time.

FWIW the choice of gtk2 or gtk3 is determined by a compile-time flag.
the wx headers check this flag and then do different things depending
on which gtk version they are [trying to be] compatible with.

So far as I can see the current state of wxt on linux is 
"wxWidgets 3.0 is not supported".
That is unfortunate, since apparently Debian is planning to drop wxWidgets 2.8
and that means they will also drop the wxt version of gnuplot.

Some quick but by no means definitive poking around in the Release Notes for
wxWidgets 3.0 suggests to me that we would have to make significant changes
to the wxt terminal in order to make it work.  I don't think that's going to happen
for version 5.  The only mitigating factor may be that a bug-fix version of
wxWidgets was released last week.  I see 2 items listed that might possibly
be relevant to our problems, but it could be quite a while before this new version
actually appears in linux distro packages for testing.

	Ethan

Re: Spacebar does not raise command window with wxt terminal (also qt)

[Philipp K. J. <ja...@ie...>]

On Fri, 20 Jun 2014 09:33:17 -0700
Ethan A Merritt <sf...@us...> wrote:

> 
> I looked into this a bit.

Thanks for doing the research. I think
this clarifies a lot. 

Is there any hope to fix this? I think this
should treated as a bug. (It also USED to 
work, sometime ago, if my memory serves me 
right...)

> Here is a the relevant section of code in wxt_gui.cpp:
> 
> =====
> /* FIXME : this code should be deleted, and the feature removed or
> handled differently,
>  * because it is highly platform-dependant, is not reliable because
>  * of a lot of factors (WINDOWID not set, multiple tabs in
> gnome-terminal, mechanisms
>  * to prevent focus stealing) and is inconsistent with global
> bindings mechanism ) */ void wxtPanel::RaiseConsoleWindow()
> {
> #ifdef USE_GTK
>    [...  special case code for KDE3]
>    [...  special case code for Gnome console]
> #endif
>    [...  special case code for Win32]
>    [...  special case code for OS2]
> =======
> 
> Furthermore the definition of USE_GTK depends on configuration tests
> for the locally installed gdk.h/gtk.h headers, if any.   I have tried
> building against gtk3 headers -  no success.
> 
> So there  is no wxt terminal support for raise console window on
> linux unless you are using  gtk2 and either  KDE3 or the Gnome
> console terminal. I will add this to the docs somewhere (maybe "known
> limitations"?)
> 
> 
> As to the qt terminal, Tatsuro Matsuoka is correct that despite what
> the terminal help text says there is no special treatment of the
> space key in the actual code. 
> 
> So basically this feature exists consistently only on Windows or X11.
> And even the X11 support may depend on the window manager being used. 
> The documentation should be amended to note that it is not generally
> available on linux.
> 
> 	Ethan
> 
> 
> 
> 
> 

Re: build problems with wxGTK 3.0

[Allin C. <cot...@wf...>]

On Fri, 20 Jun 2014, Mojca Miklavec wrote:

> On Fri, Jun 20, 2014 at 12:43 AM, Allin Cottrell wrote:
>> On Thu, 19 Jun 2014, Ethan A Merritt wrote:
>>> On Thursday, 19 June, 2014 22:27:46 Mojca Miklavec wrote:
>>>> On Thu, Jun 19, 2014 at 9:31 PM, Ethan A Merritt
>>>
>>>>>> So please also check whether wxWidgets are using gtk2 or gtk3 before
>>>>>> calling pkg-config to supply build flags.
>>>>>
>>>>>
>>>>> That's a chicken-or-egg dilemma.
>>>>> wx-config is supposed to tell us the version, but we need the version in
>>>>> order to call the correct wx-config.
>>>>
>>>>
>>>> I don't see any chicken here ;)
>>>>
>>>> Once gnuplot calls
>>>>     WX_CXXFLAGS="`$WX_CONFIG --cxxflags
>>>> it already knows which $WX_CONFIG it is calling.
>>>>
>>>> The problematic line is only
>>>>     PKG_CHECK_MODULES(GTK, [gtk+-2.0], have_gtk=yes, have_gtk=no)
>>>>
>>>> Gnuplot should run
>>>>     "$WX_CONFIG" --basename | <grep something>
>>>> before asking for gtk+-2.0.
>>>
>>>
>>> On linux (at least on my machines) there are two different wx-configs,
>>> one for wx2 and one for wx3.   You need to pick up the version from
>>> somewhere
>>> before you even know which one to run.
>>
>>
>> Running on Mac, Mojca may or may not realize that most, if not all, modern
>> Linux distros pack both gtk2 and gtk3,
>
> Yes, I know that. I have both gtk2 and gtk3 installed myself (on a Mac).
>
>> and therefore both variants of
>> wxWidgets may also be present.
>
> (Theoretically the number of wxWidgets installations is only limited
> by the disk space.) So yes, I'm aware that one can have both gtk2 and
> gtk3 installed. What I don't believe though is that any linux
> distribution would ship two copies of wxWidgets30 distribution, once
> compiled against GTK 2 and once compiled against GTK 3.
>
> But for the sake of argument let's assume that a machine has all of
> the following installed:
> - wxWidgets 2.8 with GTK 2
> - wxWidgets 2.8 with GTK 3 (maybe that's not possible)
> - wxWidgets 3.0 with GTK 2
> - wxWidgets 3.0 with GTK 3
>
> Can you please write in pseudocode what exactly you mean / based on
> what would you pick wxWidgets then and how?

Well, I'm not sure if this answers all cases, but what I have in mind is 
as follows (where, e.g., "gtk2" means that gtk+-2.0 is available on the 
host as revealed by pkg-config):

if user-says-prefer-gtk2
   if gtk2 && wx-gtk2
     use wx-gtk2
   elif gtk3 && wx-gtk3
     use wx-gtk3
   endif
else
   if gtk3 && wx-gtk3
     use wx-gtk3
   elif gtk2 && wx-gtk2
     use wx-gtk2
   endif
endif

Allin Cottrell

Re: Spacebar does not raise command window with wxt terminal (also qt)

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

I looked into this a bit.
Here is a the relevant section of code in wxt_gui.cpp:

=====
/* FIXME : this code should be deleted, and the feature removed or handled differently,
 * because it is highly platform-dependant, is not reliable because
 * of a lot of factors (WINDOWID not set, multiple tabs in gnome-terminal, mechanisms
 * to prevent focus stealing) and is inconsistent with global bindings mechanism ) */
void wxtPanel::RaiseConsoleWindow()
{
#ifdef USE_GTK
   [...  special case code for KDE3]
   [...  special case code for Gnome console]
#endif
   [...  special case code for Win32]
   [...  special case code for OS2]
=======

Furthermore the definition of USE_GTK depends on configuration tests for
the locally installed gdk.h/gtk.h headers, if any.   I have tried building against
gtk3 headers -  no success.

So there  is no wxt terminal support for raise console window on linux unless
you are using  gtk2 and either  KDE3 or the Gnome console terminal.
I will add this to the docs somewhere (maybe "known limitations"?)


As to the qt terminal, Tatsuro Matsuoka is correct that despite what the
terminal help text says there is no special treatment of the space key
in the actual code. 

So basically this feature exists consistently only on Windows or X11.
And even the X11 support may depend on the window manager being used. 
The documentation should be amended to note that it is not generally
available on linux.

	Ethan