kivy language cumbersomeness and rationale behind it

Question

Kivy has this kv language to define the UI , the definition file can become quite complex , There is a kv designer package on github which automates the generation of kv files but is quite buggy and unreliable. So the question is why does kivy want the programmer to manually write those UI definitions like even hardcode the positions and dimensions of UI widgets. Most other libraries like QT, VB etc have a UI designer as the core feature but Kivy did not start with it and expects programmers to hardcode it , I find it pretty cumbersome although I feel I am missing something. Or is it that it is only I who find a steep learning curve for kv language and I don't know about some tools which help in writing kv files.

Answer 1

If you're asking why Kivy wasn't designed around a GUI interface builder:

In their design philosophy doc, they hint at the reason:

Kivy is focused. You can write a simple application with a few lines of code. Kivy programs are created using the Python programming language, which is incredibly versatile and powerful, yet easy to use. In addition, we created our own description language, the Kivy Language, for creating sophisticated user interfaces. This language allows you to set up, connect and arrange your application elements quickly. We feel that allowing you to focus on the essence of your application is more important than forcing you to fiddle with compiler settings. We took that burden off your shoulders.

This implies pretty strongly that they believe that the way to make GUI applications less cumbersome is a text-driven declarative design like the kv language, not a WYSIWYG interface builder. So, that's why they did things this way.

But why would they think that? Well, here things get subjective.

You obviously don't agree with them. Apple doesn't either. Maybe Microsoft doesn't. But it's certainly the trend everyone else is following. People have moved from using graphical HTML designers to using a combination of declarative and procedural design directly in HTML and JS code. Macromedia created Flex to allow people to create Flash apps without having to use Flash Designer. The various cross-platform GUI frameworks (Gtk+, wx, Tk, JUCE, etc.) either don't have an interface builder, or have it as an optional "stepchild" tool; the only exception is Qt, which didn't get a tightly integrated designer until 4.0.

Take a look at how much work goes into Xcode and Visual Studio, and all the extra complex things Apple and Microsoft have to build to enable them (remember, both companies essentially took over and remade a programming language just to work with their interface builders, because the existing mainstream languages didn't fit). Kivy may be a commercially-funded project, but they don't have unlimited resources, and presumably they thought the effort they would have to spend on a doing something like Cocoa and Xcode could be better spent somewhere else.

---

For the side question on why they use static pixel-based layouts, like VB or wx, instead of relative layouts, like Cocoa or Qt… Well, first, it's not requiring that, it's giving you the option. There are advantages to both, but when you're trying to make it easier to design apps that look good on 320x480 screens at a time when everyone is noticing how badly HTML and other tools designed to be "scalable to any size" actually scaled to those sizes, I can see the advantages of pixel-perfect layout winning out. (Notice that HTML/CSS similarly gives you both options. And the earliest websites to make mobile pages took advantage of pixel-layout CSS, but they've gradually evolved as people worked out how to make "scalable" and "small" work together, and as mobile screens have become more variable.)

Answer 2

like even hardcode the positions and dimensions of UI widgets.

You do not have to hardcode the positions and dimensions of UI widgets. Although you can do so, it's not usually the best idea, for the obvious reasons that you're probably thinking.

What you're probably missing is the role of layout classes, which impose some order on their child widgets. For instance, the BoxLayout stacks all its children in a horizontal or vertical row so that together they fill its area, with relative sizes determined by their size_hint properties. Using this and other layouts, you don't have to specify manual sizes and everything will automatically adapt to changes in the window size or the sizes of individual widgets.

As for why we use kv so much, abarnert's answer and discussion covers the philosophy and core reasons pretty well. That said, we aren't against the use of graphical tools, but none of the core devs are that invested in them. Kivy Designer is an early stage project to make such a thing, since it is a popular request, but development has been slow due to few contributions - plus I guess maintaining a gui builder is probably harder than parsing a simple language like kv. We do have a GSoC project on it this year, which hopefully will bring it to a more usable state that may attract more interest.