Sidebars!
Owen Taylor
spent some time over the last week or so implementing sidebars, and
just landed that in my git tree. Screenshot attached. (Thanks to
Robert for helping me figure the details of how things should position
- a lot of the behavior comes straight from his suggestions.)
The basic usage, as you can see in the screenshot is:
build replot.Axes(display='side') as p:
p.set_title('Odd Harmonics')
for i in xrange(1,7,2):
y += sin(i*x) / i
p.plot(x, y.copy(), label=str(i))
p.legend(loc='upper right')
Issues at the current point:
* The setup is pretty useful on my 1400x900 laptop, but would likely
be too cramped at 1024x768. For such a screen, you'd likely want to
decrease the font size in preferences.
* The way I add space in the buffer to provide room for an earlier
plot is to use the GtkTextView "space before lines" feature. This
works great _except_ when selecting in the next paragaph, when things
look pretty odd, - my idea of the way to fix this is to simply "white
out" that region in the expose event region after GTK+ draws the
selection.
* When working on something like the above, you definitely notice that
completion is to the _previous_ scope - so inside the block,
p.set<...> doesn't complete. I think we just can change things so that
when the current chunk has previously been executed, we complete
against the old values from itself.
* The fact that replot.Axes() doesn't copy it's arguments but just
logs them causes some surprises - that's why y.copy() is needed in the
above.
* I haven't implemented printing yet... shouldn't be too hard, but
needs a bit of thinking about exactly what it should look like:
- If there is a sidebar, do you reserve space down the entire page
for it or just right next to the sidebar?
- Do we automatically want to print a worksheet with sidebars in
landscape mode? Just pages where sidebars appear in landscape mode?
- Is printing sidebar results as sidebars even right? - the main
point of sidebars is to improve interactive use. The main reason _not_
to do them inline seems to be that if you have code like the above
with display='side' and the display isn't side when printed out, it
reads weird.
Definitely interested in people's opinion about how this works out in
practical use.
- Owen
Robert Schroll
Unfortunately, when I try to use them, I get:
AttributeError: 'Sidebar' object has no attribute 'get_mapped'
I think this is a pyGTK version issue -- the docs say this was added to
Widget in 2.22; I'm still on 2.21.1. Is there an easy work-around?
Looking forward to trying this out,
Robert
Owen Taylor
w.flags() & gtk.MAPPED
should work.
- Owen
> --
> You received this message because you are subscribed to the Google Groups
> "Reinteract" group.
> To post to this group, send email to reint...@googlegroups.com.
> To unsubscribe from this group, send email to
> reinteract+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/reinteract?hl=en.
>
>
Robert Schroll
> Oops - sort of hard to predict what is missing in older versions. I think:
>
> w.flags()& gtk.MAPPED
>
> should work.
That does it. (For those playing along at home, that's
'self.sidebar.flags() & gtk.MAPPED'.) Some assorted early thoughts:
- Mousewheel scrolling no longer works in the worksheet.
- The sidebar appears as soon as the first CustomResult is put in the
worksheet. Should it wait until a CustomResult uses the sidebar?
Should it disappear when there's nothing in it?
- There's some odd behavior of chunks after the last sidebar-using
chunk, if they appear in the space to the left of that result:
- If there are no lines after a chunk, its result moves below the
bottom of the result in the sidebar. Adding a new line moves it back to
the expected location.
- In this case, there's extra whitespace at the bottom when scrolling.
- Sometimes, the cursor jumps back and forth between the expected
location and a place below the sidebar result, at a frequency that
varies between a few Hz and tens of Hz.
- Should there be a mechanism for CustomResults to find out the width of
the sidebar? If so, should their widgets get notified when it changes?
- The scrolling mechanism of meld [http://meld.sourceforge.net/] could
be appropriated for sidebars. Both the worksheet and sidebar would have
separate scrollbars, but their motion would be linked so that chunks and
their results are even. This would avoid some of these problems with
extra vertical space.
Thanks,
Robert
Kai
> On 10/22/2011 09:29 PM, Owen Taylor wrote:
>>
>> Oops - sort of hard to predict what is missing in older versions. I think:
>>
>> w.flags()& gtk.MAPPED
>>
>> should work.
>
> That does it. (For those playing along at home, that's
> 'self.sidebar.flags() & gtk.MAPPED'.) Some assorted early thoughts:
>
> - Mousewheel scrolling no longer works in the worksheet.
>
> - The sidebar appears as soon as the first CustomResult is put in the
> worksheet. Should it wait until a CustomResult uses the sidebar? Should it
> disappear when there's nothing in it?
>
> - There's some odd behavior of chunks after the last sidebar-using chunk, if
> they appear in the space to the left of that result:
> - If there are no lines after a chunk, its result moves below the bottom
> of the result in the sidebar. Adding a new line moves it back to the
> expected location.
> - In this case, there's extra whitespace at the bottom when scrolling.
> - Sometimes, the cursor jumps back and forth between the expected
> location and a place below the sidebar result, at a frequency that varies
> between a few Hz and tens of Hz.
>
> - Should there be a mechanism for CustomResults to find out the width of the
> sidebar? If so, should their widgets get notified when it changes?
>
> - The scrolling mechanism of meld [http://meld.sourceforge.net/] could be
Oh god don't link there. I feel bad every time I see a link to that page.
> appropriated for sidebars. Both the worksheet and sidebar would have
> separate scrollbars, but their motion would be linked so that chunks and
> their results are even. This would avoid some of these problems with extra
> vertical space.
Meld's scrolling mechanism is... interesting. Also: old and needs
cleaning up. It's not that hard to implement, but you need to have a
good way of mapping location between the panes. Looking at the sidebar
code I think it meets the requirements, though I won't venture an
opinion on whether it's a good idea or not.
cheers,
Kai
Owen Taylor
> That does it. (For those playing along at home, that's
> 'self.sidebar.flags() & gtk.MAPPED'.) Some assorted early thoughts:
Pushed a fix for that to the repo, thanks for testing
> - Mousewheel scrolling no longer works in the worksheet.
Fixed.
> - The sidebar appears as soon as the first CustomResult is put in the
> worksheet. Should it wait until a CustomResult uses the sidebar? Should it
> disappear when there's nothing in it?
This was just a leftover line in my tree - had noticed it myself last
night and and had a fixed locally.
> - There's some odd behavior of chunks after the last sidebar-using chunk, if
> they appear in the space to the left of that result:
> - If there are no lines after a chunk, its result moves below the bottom
> of the result in the sidebar. Adding a new line moves it back to the
> expected location.
> - In this case, there's extra whitespace at the bottom when scrolling.
> - Sometimes, the cursor jumps back and forth between the expected
> location and a place below the sidebar result, at a frequency that varies
> between a few Hz and tens of Hz.
Fixed (hopefully! definitely much trickiness involved here, and
breakage tends to cause infinite loops, as you've seen.)
> - Should there be a mechanism for CustomResults to find out the width of the
> sidebar? If so, should their widgets get notified when it changes?
I thought about this - it does seem in some ways like a good idea to
let the user pick the width of the sidebar and have things just fit to
that width, rather than adding useless space or a scrollbar.
There's no real problem with implementing resizing the sidebar widgets
when the width changes - the sidebar width is just a fixed width - it
isn't something that depends on the ShellView contents or anything -
so there's no tricky dependencies. But it's possible that when
combined with everything that is going on already, that the result
wouldn't be visually smooth. Only way to know is to try it out :-)
I think the interface would probably just be: if the result widget has
a set_sidebar_width() method, call it when the width changes, and let
the result widget take care of updating and calling .queue_resize() on
itself.
> - The scrolling mechanism of meld [http://meld.sourceforge.net/] could be
> appropriated for sidebars. Both the worksheet and sidebar would have
> separate scrollbars, but their motion would be linked so that chunks and
> their results are even. This would avoid some of these problems with extra
> vertical space.
In my first draft of this, I didn't add the extra vertical space, but
rather shifted the results around so that the result for "the most
relevant" statement was favored in positioning the sidebar results
(most relevant was simply the first statement chunk that was entirely
onscreen)
It didn't feel really bad, but:
- If the worksheet was short enough, you couldn't scroll so that the
chunk you were interested in was "most relevant"
- It wasn't always clear what result corresponded to what statement
or why things were moving around
Rather than spending time making that as good as I could, I decided to
try this approach instead, since it seemed likely to be conceptually
simpler. But it might be interested to try and also push the other
direction and see how good it can be made.
I think I'm pretty much against Meld-style dual scrollbars as being
too intimidating to the user :-) If we went back to autopositioning
the sidebar based on the main view, one possibility would be to make
mousewheel/touchpad/finger scrolling on the sidebar "fine tune" the
autopositioning.
- Owen
Robert Schroll
>> - There's some odd behavior of chunks after the last sidebar-using chunk, if
>> they appear in the space to the left of that result:
>> - If there are no lines after a chunk, its result moves below the bottom
>> of the result in the sidebar. Adding a new line moves it back to the
>> expected location.
>> - In this case, there's extra whitespace at the bottom when scrolling.
>> - Sometimes, the cursor jumps back and forth between the expected
>> location and a place below the sidebar result, at a frequency that varies
>> between a few Hz and tens of Hz.
>
> Fixed (hopefully! definitely much trickiness involved here, and
> breakage tends to cause infinite loops, as you've seen.)
I'm still seeing this behavior, I'm afraid. I'm also seeing errors like:
File "/home/rschroll/reinteract/lib/reinteract/shell_buffer.py", line
248, in __insert_results
chunk.__reset_last_line_tag()
AttributeError: 'StatementChunk' object has no attribute
'_ShellBuffer__reset_last_line_tag'
File "/home/rschroll/reinteract/lib/reinteract/shell_buffer.py", line
838, in set_pixels_below
self.__reset_last_line_tag(chunk)
File "/home/rschroll/reinteract/lib/reinteract/shell_buffer.py", line
398, in __reset_last_line_tag
if isinstance(chunk, StatementChunk) and chunk.results_end_mark is
not None:
AttributeError: 'StatementChunk' object has no attribute 'results_end_mark'
Perhaps something didn't get pushed?
I saw that in shell_buffer.py, there are two lines
"self.__reset_last_line_tag(chunk)" and two lines
"chunk.__reset_last_line_tag()". I tried changing the second two to be
the same as the first. That got rid of the Exceptions, but didn't fix
the behavior.
>
>> - Should there be a mechanism for CustomResults to find out the width of the
>> sidebar? If so, should their widgets get notified when it changes?
>
> I thought about this - it does seem in some ways like a good idea to
> let the user pick the width of the sidebar and have things just fit to
> that width, rather than adding useless space or a scrollbar.
We could also go do the other extreme and force sidebar widgets to have
a fixed width (or perhaps a maximum width). (Arbitrarily-sized widgets
are still available through the traditional mechanism.) This could
eliminate the need for the second horizontal scroll bar, which might
make it look a bit slicker. But it does seem to be a bit harsh to
enforce this, instead of trusting the widgets to be well-behaved.
Robert
Owen Taylor
No, just more bugs, missed in superficial testing - I've pushed a
patch with a bunch more fixes. Let me know where it still breaks :-)
- Owen
Kai
Another pygtk version issue: the sidebar uses gtk.Widget.set_window(),
which was added in GTK+ 2.18. I haven't checked, but given the pygtk
release issues around that time I think that means that the first
stable pygtk release wrapping that API will be 2.22? Having said that,
I believe that pygtk 2.17.x was shipped by some distributions, so if
that wraps set_window(), it might not be an issue for most people.
cheers,
Kai
Robert Schroll
> No, just more bugs, missed in superficial testing - I've pushed a
> patch with a bunch more fixes. Let me know where it still breaks :-)
That seems to take care of most of the problems I was seeing. The only
problem I see now is that a chunk with a result and nothing following it
doesn't have the status bar to its left drawn correctly. It seems to
start at the top of the chunk, but then extend upwards some distance.
Adding a new line after it or moving the chunk below the sidebar result
fixes the display.
Robert
Robert Schroll
> needs a bit of thinking about exactly what it should look like:
>
> - If there is a sidebar, do you reserve space down the entire page
> for it or just right next to the sidebar?
> - Do we automatically want to print a worksheet with sidebars in
> landscape mode? Just pages where sidebars appear in landscape mode?
> - Is printing sidebar results as sidebars even right? - the main
> point of sidebars is to improve interactive use. The main reason _not_
> to do them inline seems to be that if you have code like the above
> with display='side' and the display isn't side when printed out, it
> reads weird.
Two thoughts on printing sidebars:
1) The point of the sidebars is to make better use of the large (and
growing) aspect ratio of monitors. The small aspect ratio of a portrait
page means that the sidebar doesn't really help anything - I would put
it inline. The choice of "display" as the keyword tells me it's about
the monitor, not about printing.
2) Or maybe the point of sidebars is to remove results from the flow of
the worksheet. This suggests that the sidebar result should appear on
its own page. Should these appear interspersed in the worksheet pages,
or should they be gathered at the end? If it's the latter, we might
imagine a mechanism to print only the sidebar. Combine this with a
widget to put formatted text in the sidebar, and you have a mechanism
for producing simple reports. (But does anyone actually want this?)
I don't really have a conclusion here, other than that I don't see the
point of trying to copy the layout of the sidebar in print.
Robert
Owen Taylor
Thanks for this description - it was really helpful! I was seeing this
bug, but I couldn't reproduce it reliably or characterize what was
going on, but when described as above, it was trivial to track down
... the calculations for the range of a chunk with both padding below
and results were just wrong.
I pushed a fix for this - it refactors things a bit so may break a
something else, but hopefully I'm converging here :-)
- Owen
Owen Taylor
>> - Should there be a mechanism for CustomResults to find out the width of the
>> sidebar? If so, should their widgets get notified when it changes?
>
> I thought about this - it does seem in some ways like a good idea to
> let the user pick the width of the sidebar and have things just fit to
> that width, rather than adding useless space or a scrollbar.
>
> There's no real problem with implementing resizing the sidebar widgets
> when the width changes - the sidebar width is just a fixed width - it
> isn't something that depends on the ShellView contents or anything -
> so there's no tricky dependencies. But it's possible that when
> combined with everything that is going on already, that the result
> wouldn't be visually smooth. Only way to know is to try it out :-)
>
> I think the interface would probably just be: if the result widget has
> a set_sidebar_width() method, call it when the width changes, and let
> the result widget take care of updating and calling .queue_resize() on
> itself.
Here's an implementation of this. I don't love the interactive
performance - but it does seem right to be able to drag the sidebar
wider to get a bigger graph, or smaller to save vertical space. I
think the interactive performance is (too some extent) improveable -
the reason that it doesn't relayout when resizing is that we're
putting a higher priority on moving stuff around and redrawing and
never even get to relayout until the user pauses.
- Owen
Robert Schroll
appropriately (see bug 660325). The result looks much better with this
capability.
Resizing the sidebar width does feel sluggish, especially for long help
items. I don't know whether the solution is to call set_sidebar_width
less often, or for my widget to be more intelligent about calling
queue_resize.
I did notice that if the sidebar is resized by maximizing or restoring a
window, the sidebar widgets don't get the new width.
I can see a few possible ways for arbitrarily-sized widgets (like plots)
to behave in the sidebar:
- Fixed size (old replot)
- Fixed aspect ratio, variable size (new replot)
- Fixed height, variable width
I'm wondering if it would be worth it to establish a convention for
choosing between them if an extension offers more than one. (I can see
myself implementing two or all in refigure.) Some ideas: multiple
values for the display key ('side-fixed', 'side-liquid'?) or an
additional keyword pair only used with display='side'.
Thanks,
Robert
Michael Johnson
sidebar functionality.
I personally think that "2) Or maybe the point of sidebars is to
remove results from the flow of the worksheet" is what I would find
most useful in the sidebar functionality. I would like to see the
sidebar be a tabbed list of plots that I could select one tab to stay
"on top" so that I could interleave plots of intermediate results
useful for understanding an algorithm. Once I have an algorithm
instrumented with plots I would like to select a plot that is
instructive, modify code (anywhere) rerun and see the result in the
plot. (while perhaps flipping to other plots to see results of the
change down stream).
Typically what prevents me from using reinteract for larger/more
complicated algorithm analysis is that I love using plots to
understand what is going on. In reinteract they take up so much room
that I am constantly scrolling around to get at the code. What I
described above would be my "sidebar nirvana" but simply having an
option to remove the extra space that has been added in the current
incarnation would get me about 90% of the way there.
-MAJ
On Oct 24, 7:47 pm, Robert Schroll <rschr...@gmail.com> wrote:
> On 10/22/2011 05:14 PM, Owen Taylor wrote:
>
> > * I haven't implemented printing yet... shouldn't be too hard, but
> > needs a bit of thinking about exactly what it should look like:
>
> > - If there is asidebar, do you reserve space down the entire page
> > for it or just right next to thesidebar?
> > - Do we automatically want to print a worksheet with sidebars in
> > landscape mode? Just pages where sidebars appear in landscape mode?
> > - Is printingsidebarresults as sidebars even right? - the main
> > point of sidebars is to improve interactive use. The main reason _not_
> > to do them inline seems to be that if you have code like the above
> > with display='side' and the display isn't side when printed out, it
> > reads weird.
>
> Two thoughts on printing sidebars:
>
> 1) The point of the sidebars is to make better use of the large (and
> growing) aspect ratio of monitors. The small aspect ratio of a portrait
> page means that thesidebardoesn't really help anything - I would put
> it inline. The choice of "display" as the keyword tells me it's about
> the monitor, not about printing.
>
> 2) Or maybe the point of sidebars is to remove results from the flow of
> the worksheet. This suggests that thesidebarresult should appear on
> its own page. Should these appear interspersed in the worksheet pages,
> or should they be gathered at the end? If it's the latter, we might
> imagine a mechanism to print only thesidebar. Combine this with a
> widget to put formatted text in thesidebar, and you have a mechanism