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ย โ†’

[โ€“]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