正如您在source中看到的那样,该set_edit_text
方法发出您的"change"
事件,然后立即将 设置_edit_text
为实际值。*
您也可以验证这一点,例如,input_line.edit_text
在您更改后立即登录set_edit_text
以查看您是否成功更改了它。
您需要在这里做的是子类化Edit
小部件,并覆盖set_edit_text
,** 不处理"change"
信号。然后很容易。
例如:
def set_edit_text(self, text):
if text.endswith('\n'):
super().set_edit_text('')
else:
super().set_edit_text(text)
如上所述,GUI 框架有一个很好的理由在应用更改之前触发事件:这为您的事件处理程序提供了一种查看当前值和新值的方法。
当然,GUI 框架在应用更改后触发事件也是有充分理由的。
一些框架同时提供。例如,在 Cocoa 中,您通常会在更改之前收到一条fooWillChange:
消息,然后在更改fooDidChange:
之后收到一条消息。此外,在某些框架中,“之前”事件为您提供了一种影响事件处理方式的方法(替换它的一个值、吞下事件以使其不会向上传递等)。然后是 Tkinter,它提供了一些方法来完成所有这些不同的事情,但它们彼此完全不同,并且因小部件而异……</p>
框架没有所有可能的选项是一个错误吗?嗯,框架太大太笼统有一个缺点。它更难开发和维护,更糟糕的是,更难学习。我认为 urwid 在这里做出了合理的选择。特别是因为它是用相对简单的纯 Python 编写的,具有类层次结构,可以轻松覆盖您不喜欢的任何行为。
但是,您可以将其称为文档错误,Urwid 没有告诉您使用哪种信号逻辑(不可变的“之前”事件),并且几乎没有提供关于覆盖什么以自定义行为的指导。
* 还值得注意的是,您的change
处理程序在set_edit_text
. 在 urwid 中,set_edit_text
从此处理程序调用不是问题,但在许多其他 UI 库中,它可能导致无限递归或奇怪的行为。
** 您当然可以使用monkeypatchEdit
而不是子类化,除非您有特殊的理由这样做,否则我不会。