Prompt in MPL - NEVER MIND

I just saw in the code:
if event.key is None: # simulate backspace
So it works properly,
Mark

···

On 6/5/07, Mark Bakker < markbak@…287…> wrote:

I notice the alignment problem.
But it looks like you are close.

On my machine (win32), the ‘enter’ key didn’t work either. It works like a backspace. That sounds like what Matthias reported.
Mark

On 6/5/07, John Hunter <jdh2358@…287…> wrote:

On 6/5/07, John Hunter <jdh2358@…287…> wrote:

I worked on this some time ago, I never got to the point where I

thought it was ready for production but it is close. There is a

problem if usetex is enabled, because partial tex strings will cause
errors. But you can use it with regular text or plain text.

Typo: “plain text” was meant to be “math text”

Now I remember what really bothered me about this widget, and it
wasn’t just the usetex problem. The problem is that mpl has three
different vertical alignment methods for text: top, bottom and center.

None of them are right for a text box: you want baseline. Try typing

“thinking” into the text box and watch what happens when you add and
remove the “g”. We do need to support baseline alignment for text, so
if someone has an interest in adding this it would be a very useful

feature, not just for a text box for for text alignment (eg tick
labels) in general.

See the image of the “g” at

http://freetype.sourceforge.net/freetype2/docs/glyphs/glyphs-3.html

for a visual representation – hwat I am calling the “baseline” they
refer to as the “origin” in that graph. Our default alignment should
be “origin” or “baseline” but we don’t have support for that.

JDH

Hello everybody,

first of all I want to thank John for his work on the textbox - it really
looks better than mine.

I just saw in the code:
if event.key is None: # simulate backspace
So it works properly,
Mark

In my opinion it would be a better soluton to generally add some more
key-events (e.g. enter and backspace) than to simulate backspace with
all 'None'-keys.

Some time ago I posted a suggestion to that (subject: 'additional key
events'), which may be got lost among the lots of mpl-mails.
I just send the patch once more, because I think it would be helpful
for such a prompt.

best regards,
Matthias

key_event_add.patch (6.2 KB)

···

On Tuesday 05 June 2007 19:16, Mark Bakker wrote:

On 6/5/07, Mark Bakker <markbak@...287...> wrote:
> I notice the alignment problem.
> But it looks like you are close.
> On my machine (win32), the 'enter' key didn't work either. It works like
> a backspace. That sounds like what Matthias reported.
> Mark
>
> On 6/5/07, John Hunter <jdh2358@...287...> wrote:
> > On 6/5/07, John Hunter <jdh2358@...287...> wrote:
> > > I worked on this some time ago, I never got to the point where I
> > > thought it was ready for production but it is close. There is a
> > > problem if usetex is enabled, because partial tex strings will cause
> > > errors. But you can use it with regular text or plain text.
> >
> > Typo: "plain text" was meant to be "math text"
> >
> > Now I remember what really bothered me about this widget, and it
> > wasn't just the usetex problem. The problem is that mpl has three
> > different vertical alignment methods for text: top, bottom and center.
> > None of them are right for a text box: you want baseline. Try typing
> > "thinking" into the text box and watch what happens when you add and
> > remove the "g". We do need to support baseline alignment for text, so
> > if someone has an interest in adding this it would be a very useful
> > feature, not just for a text box for for text alignment (eg tick
> > labels) in general.
> >
> > See the image of the "g" at
> > FreeType Glyph Conventions
> > for a visual representation -- hwat I am calling the "baseline" they
> > refer to as the "origin" in that graph. Our default alignment should
> > be "origin" or "baseline" but we don't have support for that.
> >
> > JDH

Thanks for the reminder -- this is indeed a useful patch. I just
committed it.

I'd like to do a few enhancements to the text box widget and then add
it to svn.

JDH

···

On 6/6/07, Matthias Michler <MatthiasMichler@...361...> wrote:

Some time ago I posted a suggestion to that (subject: 'additional key
events'), which may be got lost among the lots of mpl-mails.
I just send the patch once more, because I think it would be helpful
for such a prompt.

Hello John,

first of all thank you very much for adding this patch.

By the way: What do you think about the "insert a 'l' or 'g' into your TextBox
and get a grid or log-scale"-issue? Is there a possibility to switch the
mpl-meaning of 'l', 'g' and 'f' off?

best regards,
Matthias

···

On Wednesday 06 June 2007 16:19, John Hunter wrote:

On 6/6/07, Matthias Michler <MatthiasMichler@...361...> wrote:
> Some time ago I posted a suggestion to that (subject: 'additional key
> events'), which may be got lost among the lots of mpl-mails.
> I just send the patch once more, because I think it would be helpful
> for such a prompt.

Thanks for the reminder -- this is indeed a useful patch. I just
committed it.

I'd like to do a few enhancements to the text box widget and then add
it to svn.

JDH

Yes, this is clearly an issue that has to be dealt with in a cleanup.
The current implementation has no concept of whether the text box is
the active widget. We would need to do something like activate the
text box when you click on it (and figure out the right cursor
location based on the click if there is already text in there) and
deactivate it on a carriage return or click in another axes. The
current implementation was only a proof of concept.

JDH

···

On 6/6/07, Matthias Michler <MatthiasMichler@...361...> wrote:

By the way: What do you think about the "insert a 'l' or 'g' into your TextBox
and get a grid or log-scale"-issue? Is there a possibility to switch the
mpl-meaning of 'l', 'g' and 'f' off?

Hello John,
Hello all,

I thought once more about the textbox and added some of your (Johns) features
to my class 'InputButton'. Probably my solution isn't the best possible, but
I attached this version to express what I'm thinking of and to see what
others think about my solution and needed skills of the textbox .

Could this be helpful / useful for others?

best regards,
Matthias

InputButton_mpl.py (15.1 KB)

···

On Wednesday 06 June 2007 17:25, John Hunter wrote:

On 6/6/07, Matthias Michler <MatthiasMichler@...361...> wrote:
> By the way: What do you think about the "insert a 'l' or 'g' into your
> TextBox and get a grid or log-scale"-issue? Is there a possibility to
> switch the mpl-meaning of 'l', 'g' and 'f' off?

Yes, this is clearly an issue that has to be dealt with in a cleanup.
The current implementation has no concept of whether the text box is
the active widget. We would need to do something like activate the
text box when you click on it (and figure out the right cursor
location based on the click if there is already text in there) and
deactivate it on a carriage return or click in another axes. The
current implementation was only a proof of concept.

JDH

Hello everybody,

in my last version I forgot to include a very useful function (it is
comparable with the 'Button.on_clicked' function). I added it now. It allows
the user to interact with other widgets ( I needed it to interact with the
Silder) or his own program (e.g. updating external values or plots).

I attached this new version.

best regards,
Matthias

InputButton_mpl2.py (15.8 KB)

···

On Tuesday 26 June 2007 19:46, Matthias Michler wrote:

Hello John,
Hello all,

I thought once more about the textbox and added some of your (Johns)
features to my class 'InputButton'. Probably my solution isn't the best
possible, but I attached this version to express what I'm thinking of and
to see what others think about my solution and needed skills of the textbox
.

Could this be helpful / useful for others?

best regards,
Matthias

On Wednesday 06 June 2007 17:25, John Hunter wrote:
> On 6/6/07, Matthias Michler <MatthiasMichler@...361...> wrote:
> > By the way: What do you think about the "insert a 'l' or 'g' into your
> > TextBox and get a grid or log-scale"-issue? Is there a possibility to
> > switch the mpl-meaning of 'l', 'g' and 'f' off?
>
> Yes, this is clearly an issue that has to be dealt with in a cleanup.
> The current implementation has no concept of whether the text box is
> the active widget. We would need to do something like activate the
> text box when you click on it (and figure out the right cursor
> location based on the click if there is already text in there) and
> deactivate it on a carriage return or click in another axes. The
> current implementation was only a proof of concept.
>
> JDH

Hello everybody,

first of all I hope my mails on the issue 'Prompt/TextBox/InputButton' don't
become to many.
But I had one more idea and I want to share it with you.
If you don't like my usage of lists as a pointer to variables, one could
replace this in two steps:
1) Adding a new method 'get_text' to get the actual label text
(def get_text(self):
     return self.label.get_text() )
2) In the example one would include a function to set one's variable to the
evaluated label-text. Than one would add this function into the
self.observers and so call it after every finished typing mode.

This new behaviour has the big advance that error-handling during evaluation
of the text is a task for users and not to mpl.

I hope I could explain my idea ...

best regards,
Matthias

···

On Wednesday 27 June 2007 18:19, Matthias Michler wrote:

Hello everybody,

in my last version I forgot to include a very useful function (it is
comparable with the 'Button.on_clicked' function). I added it now. It
allows the user to interact with other widgets ( I needed it to interact
with the Silder) or his own program (e.g. updating external values or
plots).

I attached this new version.

best regards,
Matthias

On Tuesday 26 June 2007 19:46, Matthias Michler wrote:
> Hello John,
> Hello all,
>
> I thought once more about the textbox and added some of your (Johns)
> features to my class 'InputButton'. Probably my solution isn't the best
> possible, but I attached this version to express what I'm thinking of and
> to see what others think about my solution and needed skills of the
> textbox .
>
> Could this be helpful / useful for others?
>
> best regards,
> Matthias
>
> On Wednesday 06 June 2007 17:25, John Hunter wrote:
> > On 6/6/07, Matthias Michler <MatthiasMichler@...361...> wrote:
> > > By the way: What do you think about the "insert a 'l' or 'g' into
> > > your TextBox and get a grid or log-scale"-issue? Is there a
> > > possibility to switch the mpl-meaning of 'l', 'g' and 'f' off?
> >
> > Yes, this is clearly an issue that has to be dealt with in a cleanup.
> > The current implementation has no concept of whether the text box is
> > the active widget. We would need to do something like activate the
> > text box when you click on it (and figure out the right cursor
> > location based on the click if there is already text in there) and
> > deactivate it on a carriage return or click in another axes. The
> > current implementation was only a proof of concept.
> >
> > JDH