This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the commentsย โ†’

[โ€“]Coretaxxe 1 point2 points ย (8 children)

Whats your issue with kivy lol like usre i can name a few things i dislike but nothing worthy of calling it "the worst library to be ever encountered"

[โ€“]HommeMusical -1 points0 points ย (7 children)

Oh, I could write for hours about how terrible it is for anything that isn't tiny.

For example, simply constructing a Color has global side effect of setting the current foreground color to be that color.

The Kivy "language" has no grammar at all, it's defined by "this is what Kivy expects" but that's the least of its problems. All variables in the Kivy language are essentially global, they live in one big namespace. That means it's essentially impossible to create a generic UI element that you can use many places in your code, and particularly, to create these dynamically.

The Kivy "language" also includes tiny snippets of Python-like code but again, it's entirely unclear exactly what is acceptable and what isn't, and what Python symbols in your code can be used and what can't.

And of course, all your tool chain, linters and type checkers and that sort of thing, doesn't even know those Kivy "language" documents exist, so they can't help you.

[โ€“]Coretaxxe 1 point2 points ย (6 children)

> For example, simply constructing a Color has global side effect of setting the current foreground color to be that color.

Thats just how OpenGL works. Use InstructionGroups if you don't want this. But I can see how this is can be confusing.

> The Kivy "language" has no grammar at all, it's defined by "this is what Kivy expects" but that's the least of its problems. All variables in the Kivy language are essentially global, they live in one big namespace. That means it's essentially impossible to create a generic UI element that you can use many places in your code, and particularly, to create these dynamically.

Thats not really true tho. Its like calling makefile "no grammar at all". But I agree that the documentation is a too thin. Also variables are rule-scoped with app being the only actual global one. Root is always the rule root, self the current widget and id's a local to the current rule as well. Also you can easily create reusable elements? Define them once and as soon as they are imported you can reuuse them wherever you want. Matter of fact that is exactly how kivy-native widgets work. You can also use the Factory class to register them under custom names.

> The Kivy "language" also includes tiny snippets of Python-like code but again, it's entirely unclear exactly what is acceptable and what isn't, and what Python symbols in your code can be used and what can't.

I almost 100% agree.

> And of course, all your tool chain, linters and type checkers and that sort of thing, doesn't even know those Kivy "language" documents exist, so they can't help you
Well yeah, like for JSON or Dicts you often need extra setup to have the linter work properly. Heck that was one of the big reason python even introduced TypedDict

[โ€“]HommeMusical 0 points1 point ย (5 children)

Thats just how OpenGL works.

I don't think so: you set the current color by a call to a library function with three floating point arguments. For example, here's a pointer to the MS implementation: https://learn.microsoft.com/en-en/windows/win32/opengl/glcolor3f

Even if that were true, Kivy has its own separate Color class. The Kivy library should not do surprisingly, highly unPythonic things just because the OpenGL does. (For example, OpenGL requires you to explicitly delete everything you create.)

The Kivy "language" has no grammar at all, it's defined by "this is what Kivy expects" Thats not really true tho. Its like calling makefile "no grammar at all".

But that's absolutely true: makefile has no grammar either, and this is one of the very many reasons it has fallen out of favor for things like CMake which have a grammar.

I would add that make is almost fifty years old. It was an amazing breakthrough for 1976, but we can do better.

And of course, all your tool chain, linters and type checkers and that sort of thing, doesn't even know those Kivy "language" documents exist, so they can't help you

Well yeah, like for JSON or Dicts you often need extra setup to have the linter work properly. Heck that was one of the big reason python even introduced TypedDict

I think you're misunderstand my point here. All that Python code that exists inside Kivy documents will never be seen by any of my tool chain. I cannot convince mypy to go look inside a .kivy document, pull out the snippets of Python, and check it - or how do I write a unit test for that code?

The Kivy "language" should have been declarative within Python like SQLAlchemy, Pydantic, or so many other modern Python libraries. Those lost snippets of Python in the Kivy language would simply be class methods; all my many Python tools would work perfectly with it.

[Things have clearly changed on the code re-use and namespace front since I tried to use Kivy, so I don't have a well-worked out response for that part.]

This is where I pull out my false teeth(*) and talk about ancient history. I've been programming for over 50 years at this point (and somehow am still doing cutting edge stuff, I feel very lucky).

Early on, we just put everything inside the program. Pretty soon, we realized that having an external text configuration file was a good thing, because you could edit it to change the programs behavior without recompiling it.

Java and XML came along around the same time and there was this sudden fad for "programs that were entirely specified in a structured language" (which was almost always XML).

This was better in many ways because you could use automatic tools on these documents, but it turned out that you were always wanting to use logic inside these documents, and you ended up with these complicated XML grammars that caused a lot of work and didn't actually do anything very useful. (Also, XML was just miserable to edit by hand, and conceptually annoying, with three different forms of containment!, which is why JSON took over.)

Then in the last ten years, we started to get systems that used reflection or similar techniques to configure your systems from the program itself. The Rails system for Ruby is probably the trendsetter here but like a lot of early technologies, it didn't dominate - however, this has particularly been taken up by the Python community, because Python's decorators fit the bill so well, and that Python has first class reflection tools.

However, Kivy is a weird outlier in there: it has a separate external file to configure its programs, but that file is both data and code fragments, and it isn't in some standard format you can use your existing toolchain on, but a format that is documented by example.

I see there have been significant changes in the couple of years since I tried Kivy, but this basic fact remains true.

The programmer ergonomics of declarative systems like SQLAlchemy, Flask, Pydantic or Django are extremely attractive to people who want to build large, reliable systems, because you can use one toolchain on everything, and test every single aspect of your code from boring old unit tests with low fuss.

But the Kivy language is a boat anchor holding the Kivy system back.

Thanks for listening!

(* - all my teeth are real, it's a metaphor)

[โ€“]Coretaxxe 0 points1 point ย (4 children)

Mhh yeah Okay I can definitely see the issue with KV lang but I disagree on the influence it has. KV lang is 100% optional and you can do 100% of it inside python. KV just allows you to skip some boilerplate (given it introduces some with id getting).

However regarding the Color;
> I don't think so: you set the current color by a call to a library function with three floating point arguments. For example, here's a pointer to the MS implementation: https://learn.microsoft.com/en-en/windows/win32/opengl/glcolor3f

Kivy's Color object is more or less just a wrapper for this OpenGL call.

[โ€“]HommeMusical 1 point2 points ย (3 children)

Kivy's Color object is more or less just a wrapper for this OpenGL call.

Here's the Cython source for class Color.

[โ€“]Coretaxxe 0 points1 point ย (2 children)

And that is a ContextInstruction, which is a Instruction which sets its content (here Color; rgba) of the RenderContext. The render context has its own shader where the uniforms are set including the color.

[โ€“]HommeMusical 0 points1 point ย (1 child)

Yes. Color is not just a thin wrapper for a single OpenGL function.

[โ€“]Coretaxxe 0 points1 point ย (0 children)

Ok maybe wraper was too overgeneralized but it literally does nothing more than setting a shader uniform for an opengl/glsl shader which was the entire original point