Have definitely had an excellent experience using an experimental MVC setup in Kivy. Can't chip into any MVC death exclamations. First I should mention that Kivy uses data-binding liberally. It's not events, it's publisher-subscriber where bound functions receive the changes as their arguments. This fixes many things, but Kivy uses a widget tree. Trees are great for reasoning about context, scope, relationship etc between graphics elements in layouts.
Trees are also an awful topology when something has a relationship to an element in another branch. The controllers as I'm using them are globally visible and thus don't need to be passed. This would pollute namespaces except that a minimal number of controllers will recreate the topology of the problem space and not in tree-space. The whole application can see "out" of the 2D tree into a graph that connects things with many fewer connections. These few controllers have tons of logic, but it's all program. There's very little related to how widgets display themselves, so this fat code is also very high-calorie, rich or whatever.
Fat controllers make me happy. My program, the part that I think of as the program, exists all in one place and the bits that control how everything looks all belong in the tree. Widgets don't send events to my controllers often. Occasionally it's easier to reason through a problem using the property/data-binding system, but more often the data already exists in the on_press callback of the widget or whatever and there's no need to secondarily send it through more sub/pub plumbing when I can just call a function of my global controller on the data.
I'm busy getting my code cleaned up and contributed. It has really saved me untold time even in it's nascent stages because of the fundamental topology conveniences.
Trees are also an awful topology when something has a relationship to an element in another branch. The controllers as I'm using them are globally visible and thus don't need to be passed. This would pollute namespaces except that a minimal number of controllers will recreate the topology of the problem space and not in tree-space. The whole application can see "out" of the 2D tree into a graph that connects things with many fewer connections. These few controllers have tons of logic, but it's all program. There's very little related to how widgets display themselves, so this fat code is also very high-calorie, rich or whatever.
Fat controllers make me happy. My program, the part that I think of as the program, exists all in one place and the bits that control how everything looks all belong in the tree. Widgets don't send events to my controllers often. Occasionally it's easier to reason through a problem using the property/data-binding system, but more often the data already exists in the on_press callback of the widget or whatever and there's no need to secondarily send it through more sub/pub plumbing when I can just call a function of my global controller on the data.
I'm busy getting my code cleaned up and contributed. It has really saved me untold time even in it's nascent stages because of the fundamental topology conveniences.