octave-patch-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-patch-tracker] [patch #8532] Use conventional signaling to modif


From: Dan Sebald
Subject: [Octave-patch-tracker] [patch #8532] Use conventional signaling to modify Readline term size rather than callback.
Date: Fri, 12 Sep 2014 03:23:21 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0 SeaMonkey/2.15

URL:
  <http://savannah.gnu.org/patch/?8532>

                 Summary: Use conventional signaling to modify Readline term
size rather than callback.
                 Project: GNU Octave
            Submitted by: sebald
            Submitted on: Fri 12 Sep 2014 03:23:19 AM GMT
                Category: None
                Priority: 5 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

In main-window.cc is the following line which I believe is meant to force the
Octave core to update the Readline terminal size so that Octave properly
formats its output:

+verbose+
octave_link::post_event (this, &main_window::resize_command_window_callback);
-verbose-

Currently if the window is resized then the terminal will properly adjust. 
The reason it doesn't work on the first resize due to restoring user settings
is that QTerminal code has this conditional:


  _resizing = (oldlin!=_lines) || (oldcol!=_columns);

  if ( _resizing )
    {
...
    }


which I presume cuts down on kernel traffic a little bit since it changes the
scale from pixels to characters.  (I.e., sizing isn't changed with every pixel
change.)

Attached is a changeset that removes the use of a callback function and
instead raises a signal at a location hopefully after the GUI objects are
initialized and the Octave core has reached the point where it is capable of
recognizing kernel signals.  Now, whether that is true and is still open for
timing problems I'm not sure because kernal signals isn't something I've
worked with a lot.  But I think the signal approach is just about right and a
more conventional way of doing this.

What the ramifications are for Windows systems I'm not sure.  Perhaps it isn't
even a problem problem for Windows.




    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Fri 12 Sep 2014 03:23:19 AM GMT  Name:
octave-terminal_size_signal-2014sep11.patch  Size: 2kB   By: sebald

<http://savannah.gnu.org/patch/download.php?file_id=32079>

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/patch/?8532>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]