Live slider updating (gtk help)

  I think the slider should update with the display if

    > the dragging is enabled, so the slider value stays in
    > sync. The typical user will understand that things will
    > be a little sliggish when plotting insane data such as
    > you example. I am wanting to create a simple text/value
    > entry field, but I noticed that the backends don't
    > support the delete key in events. Are there issues
    > across platforms with this? If not, I will probably add
    > this.

Yes, you should add the delete key. I was hacking a little bit
yesterday on text entry. An alternative to creating a text widget is
to simply require each backend to define a few gui dependent functions
that we don't to get involved with (get_filename, get_text, etc..) and
then connect these to a button. The button could say something like

···

--------------------

xlabel: volts(s) |

--------------------

and when you click on it calls get_text from the backend and updates
"volts(s)" with the text you supply (and in this example would update
the xlabel too).

Below is a buggy and incomplete example of using the region/cache/copy
stuff I mentioned before to type into an axes. As before, it is
gtkagg only at this point. In particular, the cursor is pretty
crappy. Note I am using "None" which is what backspace currently
defines, to indicate the backspace key. One thing that would make
this work better is to predefine the region the text goes into (an
Axes presumably) and just blit the entire axes bbox before
re-rendering the string with each character. This would solve the
cursor erase on backspace bug you will notice if you try it.

This was just screwing around and not meant for public consumption,
but since you brought it up :slight_smile:

Anyone want to write a word processor in matplotlib <wink>?

## Example text entry ##

from pylab import *
from matplotlib.transforms import lbwh_to_bbox, identity_transform

class TextBox:
    def __init__(self, canvas, s='Type: '):
        self.canvas = canvas
        self.text = text(0.5, 0.5, s)
        draw()
        canvas.mpl_connect('key_press_event', self.keypress)
        self.region = canvas.copy_from_bbox(self.get_padded_box())
        l,b,r,t = self.get_cursor_position()
        self.cursor, = plot([r,r], [b,t])

    def keypress(self, event):
        if event.key is not None and len(event.key)>1: return

        t = self.text.get_text()
        if event.key is None: # simulate backspace
            if len(t): newt = t[:-1]
            else: newt = ''
        else:
            newt = t + event.key
            
        oldbox = self.get_padded_box()
        self.text.set_text(newt)
        newbox = self.get_padded_box()

        l,b,r,t = self.get_cursor_position()
        self.cursor.set_xdata([r,r])
        self.cursor.set_ydata([b,t])
        
        canvas = self.canvas
        canvas.restore_region(self.region)
        self.region = canvas.copy_from_bbox(newbox)
        f.draw_artist(self.text)
        f.draw_artist(self.cursor)
        canvas.blit(oldbox)
        canvas.blit(newbox)
        
    def get_padded_box(self, pad=5):
        l,b,w,h = self.text.get_window_extent().get_bounds()
        return lbwh_to_bbox(l-pad, b-pad, w+2*pad, h+2*pad)

    def get_cursor_position(self):
        l,b,w,h = self.text.get_window_extent().get_bounds()
        r = l+w+5
        t = b+h
        l,b = self.text.get_transform().inverse_xy_tup((l,b))
        r,t = self.text.get_transform().inverse_xy_tup((r,t))
        return l,b,r,t
        
ion()
f = figure()
title('Start typing')
axis([0, 2, 0, 1])
box = TextBox(f.canvas)
axis([0, 2, 0, 1])

show()

John Hunter wrote:

"Charles" == Charles Moad <cmoad@...209...> writes:

    > I think the slider should update with the display if
    > the dragging is enabled, so the slider value stays in
    > sync. The typical user will understand that things will
    > be a little sliggish when plotting insane data such as
    > you example. I am wanting to create a simple text/value
    > entry field, but I noticed that the backends don't
    > support the delete key in events. Are there issues
    > across platforms with this? If not, I will probably add
    > this.

Yes, you should add the delete key. I was hacking a little bit
yesterday on text entry. An alternative to creating a text widget is
to simply require each backend to define a few gui dependent functions
that we don't to get involved with (get_filename, get_text, etc..) and
then connect these to a button. The button could say something like

Since I can't really offer much help on this topic (outside of my field of expertise), I'd be glad to assist with the PR effort for the upcoming MDE release. I know you guys will be quite busy with the code, so I can work on writing the release announcements. A first draft for your consideration:

···

------------------------
MDE: the Matplotlib Desktop Environment

John D. Hunter and the Matplotlib team proudly announce the dawn of a new era in interactive graphical desktops: MDE, the Matplotlib Desktop Environment, is coming! Are you tired of the endless Qt/GTK, KDE/Gnome/OSX debates? Cry no more! MDE is here, to provide a fully anti-aliased destkop environment with run-time backend selection (Tk, GTK, WX, Qt, FLTK and even CocoaAgg are supported, so there is room for all).

The first (alpha) release of MDE will include full scientific plotting capabilities, a testament to the vision of the core team. Secondary utilities like file managers, web browsers and a python-based Office Suite (MatPlotOffice -- in development at the MPL underground laboratories), will come later...

So stop using KDE/Gnome now, and join the MDE fun! You haven't really experienced modern computing until you've used MDE...
------------------------

I know it's a bit hyperbolic, but isn't that what a PR release is supposed to do? Besides, we want the KDE and Gnome teams to take notice of the new kid on the block ASAP, so we better be loud from day one.

:wink:

Cheers,

f

John,
Attached is an updated QT backend (I started from a CVS sync yesterday). I can send you diffs if you like.

The main driver is to fix the problem with the plot not being the requested size when drawn on the screen. The toolbar was implemented as a dockable QToolbar whose location cannot be predicted until drawing time. This caused the toolbar to overlay the plot so the result was always a plot that was slightly shorter in height than the requested amount.

The following changes were made:

1) Changed the toolbar to be a horizontal bar of push buttons instead of a QToolbar and updated the layout algorithms in the main window accordingly. This eliminates the ability to drag and drop the toolbar and detach it from the window.

2) Updated the resize algorithm in the main window to show the correct size for the plot widget as requested. This works almost correctly right now. It looks to me like the final size of the widget is off by the border of the main window but I haven't figured out a way to get that information yet. We could just add a small margin to the new size but that seems a little hacky.

3) Changed the x/y location label to be in the toolbar like the Tk backend instead of as a status line at the bottom of the widget.

4) Changed the toolbar pixmaps to use the ppm files instead of the png files. I noticed that the Tk backend buttons looked much nicer and it uses the ppm files so I switched them.

Ted

backend_qt.py (11.4 KB)

backend_qt.py (11.4 KB)