boots-developers team mailing list archive

[Eric Day <eday@xxxxxxxxxxxx>]

Hi Ashish,

When dealing with the issue of lines being too long for the display,
we should probably find a way to see that if desired. For example,
you could either wrap the line around to the next, or you could support
horizontal scrolling (say using left/right keys). You could even have
a configuration setting to provide it either way.

-Eric

On Thu, Jun 03, 2010 at 03:50:29AM +0530, Ashish wrote:
>    Hi Eric,
>    A A A A A A A  Thanks for the reply. At first, I was buffering only the
>    raw data. But then it occurred to me that it would take a lot of
>    computation to regenerate lines out of it again and again. So, then I
>    thought of the other way of creating lines of the width same as that of
>    terminal, when they were created. I am the using latter approach right
>    now.
>    Current it works as follows,
>    1. If terminal width is reduced, then the part of line that cannot be
>    displayed is trimmed off and only the part that fits in terminal width is
>    displayed.
>    2. If terminal width is increased, then the previously built lines are
>    used as they are.
> 
>    Both the cases, (decrease and increase in width of terminal) are dealt
>    with easily this way. I'll continue with this approach if you find it
>    right.
> 
>    Best regards,
>    Ashish Sharma
>    http://www.google.com/profiles/eraser029
> 
>    On Thu, Jun 3, 2010 at 3:27 AM, Eric Day <eday@xxxxxxxxxxxx> wrote:
> 
>      Hi Ashish!
> 
>      You might consider buffering the raw data that you use to construct
>      the lines. This way when a resize event occurs you can regerate the
>      lines of any size. I'm guessing you'll want to buffer the entire
>      result set (possibly with some large upper limit to not run out of
>      memory) so you can page back and forth with it. Resizing should not
>      happen too often so it doesn't need to be super fast, I think proper
>      reformatting should take priority.
> 
>      -Eric
>      On Thu, May 27, 2010 at 03:02:54AM +0530, Ashish wrote:
>      > A  A As part of my gsoc project, I've been doing developments on the
>      curses
>      > A  A based UI for boots. My work is available in the branchA
>      > A  A lp:~ashishsharma/boots/cui-main .
>      >
>      > A  A In this part I am now working out the way in which I should
>      handle the
>      > A  A buffer in terminal. In which way should I keep the buffer
>      contents so that
>      > A  A scrolling through it is efficient. I was recently looking at the
>      > A  A gnome-terminal to see how it handles its buffer.
>      > A  A I did the following experiment, I opened a small terminal window,
>      did ls
>      > A  A sometimes. After that I maximized it. Then I did ls some moreA
>      A times and
>      > A  A then un-maximized it. shot1.png is of maximized window and
>      shot2.png is of
>      > A  A un-maximized window. I found that the gnome-terminal maintains a
>      buffer of
>      > A  A fixed-size line .
>      >
>      > A  A So in curses UI also I'm planning to create a buffer that will
>      store
>      > A  A fixed-size lines. On terminal resize the contents of the buffer
>      already
>      > A  A create shall not be changed according to new line size of
>      terminal. The
>      > A  A display will show contents of buffer lines that can be shown
>      (i.e, suppose
>      > A  A you currently have 80 char long lines, ls prints in two lines.
>      Now when a
>      > A  A resize occurs and line size becomes 160 char, then this previous
>      ls output
>      > A  A will not be formatted again.).
>      >
>      > A  A Comments and feedback on this understanding of mine how terminal
>      works
>      > A  A will be highly appreciated.
>      >
>      > A  A Best regards,
>      > A  A Ashish Sharma (_buck)
>      > A  A http://www.google.com/profiles/eraser029
> 
>      > _______________________________________________
>      > Mailing list: https://launchpad.net/~boots-developers
>      > Post to A  A  : boots-developers@xxxxxxxxxxxxxxxxxxx
>      > Unsubscribe : https://launchpad.net/~boots-developers
>      > More help A  : https://help.launchpad.net/ListHelp