#9340·kivy

Feature Proposal: `EventProperty` and Declarative Event Definitions

Author: kudomarkosCreated Jul 10, 2026Updated Jul 10, 2026
LabelsComponent: KV-langType: FeatureComponent: core-app

Hello Kivy team,

First of all, thank you for all the work you have put into Kivy over the years. I have been learning more about EventDispatcher, and while I now understand how it works, I noticed that defining custom events requires a significant amount of boilerplate code.

I would like to propose a feature that could make custom events more declarative and easier to use, especially for new users.

Current approach

Today, defining a custom event typically requires something like this:

python
class MyClass(EventDispatcher):

    def __init__(self, **kwargs):
        super().__init__(**kwargs)
        self.register_event_type("on_whatever")

    def on_whatever(self, *args):
        pass

Although this is perfectly functional, the same pattern has to be repeated for every custom event:

  • register the event
  • create an empty default handler
  • remember both steps every time

Proposed Python API

A new property could simplify this considerably:

python
class MyClass(EventDispatcher):

    on_whatever = EventProperty()

Internally, EventProperty could automatically:

  • register the event (register_event_type)
  • create the default empty handler (on_whatever)
  • expose the event exactly as existing custom events do

From the developer's perspective, the behavior would remain identical, but with much less boilerplate.

Proposed KV syntax

An even more declarative approach could be allowing custom events to be declared directly in KV:

kv
<MyClass@EventDispatcher>:
    events:
        - on_whatever
        - on_finished
        - on_cancelled

The KV parser could automatically generate the equivalent registration internally.

This would allow developers creating widgets entirely in KV to define custom events without writing additional Python code.

Benefits

  • Less repetitive boilerplate.
  • Easier to learn for new users.
  • More declarative API.
  • Better integration between KV and Python.
  • Custom events become as simple to declare as Kivy Property objects.

In my opinion, this would feel similar to how StringProperty, BooleanProperty, and the other Kivy properties already simplify observable state.

Backward compatibility

This proposal would not require changing the existing API.

The current approach using register_event_type() would continue to work exactly as it does today.

EventProperty and the events: KV syntax would simply provide a higher-level, optional way to declare custom events.

Alternatives

  • ListEventsProperty and ListNegableEventProperty: This alternative only requires a list of new event names, without the on_ keyword, and performs the registration and checks if a method with that name already exists and has code, in which case it doesn't overwrite it. The second "negable" list also implements a boolean property to negate that event, as happens in Scatter with do_scale. This would emulate
python
class MyClass(EventDispatcher):
    do_whatever = BooleanProperty(True)
    def __init__(self, **kwargs):
        super().__init__(**kwargs)
        self.register_event_type("on_whatever")
        self.register_event_type("on_other")

    def on_whatever(self, *args):
          if not do_whatever:    
           ....      
    def on_other(self, *args):
          ....

in this way:

python
class MyClass(EventDispatcher):
    widget_events = ListEventsProperty(['other', ........])
    widget_negable_events =ListNegableEventsProperty(['whatever', .......])

Well, ultimately, I don't know all the possibilities and setbacks, but I would like it to be considered.

So, Thank you for considering this idea. I would be interested to know whether this has been discussed before, or whether there are technical reasons that would make such a feature difficult to implement.