What's on the Kivy Roadmap?

[baseplate-admin]

Hi,

I think it's better if there's a road map for kivy.

[Julian-O]

Psssst! Comrades! Do you hear that silence? Do you know what that sounds like? Opportunity!

The Core Developer(s) are too busy dealing with an upcoming release to be focussed on the big picture, so now is the time to strike! What do you WANT the Kivy Roadmap to look like?

Hint: It has to be bigger than your single pet idea, and it isn't enough to make the product more versatile for expert users . Think about ideas that will relieve the most pain from current users, open it up to the most new users, and foresees where the pain points are in the future?

It should look forward at least a couple of years, and consider more than just the Kivy framework.

[baseplate-admin]

Psssst! Comrades! Do you hear that silence? Do you know what that sounds like? Opportunity!

👀

[Julian-O]

My two cents:

I think the next 12 months should be focussed on dot releases, addressing existing technical debt.

Let's reduce the number of outstanding defects (especially the "missing stairs" that the experts no longer notice), refactor (too many God objects), and add unit tests (Coverage figures are woeful), and get it ready for some bigger changes.

One broad audience that I think is being under-served is users of languages which aren't based on the Latin alphabet.

A smaller one is Windows developers of mobile apps.

I think the documentation needs work on: Too many missing minor details. The tutorials miss too many core concepts, and should be extended. There should be more support for people who want to implement extensions: Garden widgets, Recipes for p4a and Kivy for iOS, bootstraps for p4a.

Much of support seems to be dealing with cryptic error messages - we need a better way of mapping from those to the causes - and uninstalled dependencies.

None of this Big Picture enough. There are no new technologies. (Huh? I haven't even mentioned AI?!) I haven't considered what the competitors are doing. There might need to be some more pizzazz to retain developer interest.

[baseplate-admin]

A smaller one is Windows developers of mobile apps.

This is not fully necessary, since wsl can fully support kivy and buildozer

[Julian-O]

I have replied to that elsewhere in the issue database. wsl adds at least a 20% cost to development for me - and at unpredictable times, it adds extra hours of development.

[Julian-O]

focussed on dot releases

Sorry, this was sloppy wording. I should have said "focussed on maintenance releases".

Semver has a lot of advantages, but one downside is a bump in the major version number to 3.0.0 might mean "The culmination of years of planning and development, this release includes 6 new backends, support 8 new operating systems, incorporate speech-recognition and ChatGPT and can all the widgets are now 3D!" or it might mean "We renamed a someTrivialClass to SomeTrivialClass and that breaks the API, so we had to bump the major version."

So, I understand maintenance releases might involve bumping the major version.

That said, there is a risk with my proposal: If there are lots of API breakages and zero snazzy new features that developers are salivating over, more than the typical number of existing developers may prefer to just pin their code to the old version and not bother to upgrade.

[baseplate-admin]

To be honest, I want kivy to be a viable framework for building applications, currently it's possible but everything is kinda messy. So here are what i think kivy should add :

1. Better Documentation : For now the way I see it, kivy documentation can take some inspiration from svelte documentation. Everything is so well documented and in simple language. kivy documentation feels out-dated at times. The points document should include :

• Platform specific codes ( kivy documentation should include android and ios specific examples )
• How to integrate kivy in java projects ( similar to flutter platform channels )
• Document how to use GLSL shaders.

2. Refractor kivy codebase: Most of the codes around kivy are baggage of old days. This can be refractored to modern python codes.
3. Create Ecosystem around kivy: kivy should create best practices for using the framework. For example there's no way to share data among components ( well there is but it would be different from project to project ). kivy developers should develop a package to :

• Share data among components ( what i am talking about is following stores approach from svelte )

4. Develop Some Cool Projects: Often time I see people asking if this is possible to do in kivy ( me included ).kivy should promote some applications created in kivy. @HeaTTheatR has some cool projects around kivy + kivymd. Maybe showcase them in kivy documentation ( with a permissive license ) ?
5. Async Support: Core kivy should be refractored to use async codes. This is a breaking change, but this could massively increase the performance of kivy along with making it a vastly superior platform to create applications. Most of the current frameworks ( react-native, flutter ) are fully asynchronous. It should be straped on like the example app. Ideally this transition should be smooth and transparent.
6. Typing Support: Core kivy framework should be typed. Since cython would soon pick up types ( dont quote me on this. I heard rumors by snooping 'round forums ), I think it would be better if kivy followed the approach

[Julian-O]

Thanks for this!

The items that stood out to me here that may need more explanation:

• GLSL shaders - never heard of them. Why are they important to you?

• Ecosystem - Kivy already has a huge ecosystem around it. This may turn out to be a documentation/marketing issue.

• Showcase - Kivy.org already has a showcase. This may turn out to be a marketing issue.

• Async Support - Kivy already supports asyncio. What else are you looking for?

[baseplate-admin]

GLSL shaders - never heard of them. Why are they important to you?

kivy itself is built on glsl.
Why are they important:

• I want to add shader effect to my android app. If i want to do these in python, it will be far more taxing on cpu.
  For example this is a shader effect
  

Ecosystem - Kivy already has a huge ecosystem around it. This may turn out to be a documentation/marketing issue.

Ecosystem is horribly outdated. Some of the modules dont work with modern kivy, some of them lacks documentation. What i am proposing is unifying them under kivy umbrella and uh..maybe write some documentation?

Showcase - Kivy.org already has a showcase. This may turn out to be a marketing issue.

I was thinking more exotic examples. Like a game, a complex real world app ( eg: youtube, facebook like ). Something that can be benchmarked, has best practices.

Async Support - Kivy already supports asyncio. What else are you looking for?

This is not a proper implementation (or am i missing something?) I meant the entire stack from ground up. Like dispatching events in a a asynchronous way, rendering widgets in a asynchronous way....

I mean the entire kivy core should be async

[misl6]

Psssst! Comrades! Do you hear that silence? Do you know what that sounds like? Opportunity!

I will voluntarily keep myself silent on this topic until Kivy 2.3.0 is released, as I see this one as a perfect exercise for our community. (and that's the feedback we need as core devs)

After Kivy 2.3.0 is released, we can have a "hackathon-like" event to discuss about all the proposals and later define the roadmap for the following months.

I've already seen a lot of interesting things, so keep thinking 💭

I think the next 12 months should be focussed on dot releases, addressing existing technical debt.

Just consider, during this discussion, that we likely need to break the API to address some long-standing issues.

[Julian-O]

More proposals to think about:

• What can we remove/archive? What is no longer worth supporting? No longer worth even having on our books, so we can make space for better things? My suggestions:

  • kivy-ideas
  • kivy-launcher
  • condiment
  • ncis et. al
  • web-site wiki
  • Buildozer's remote.py (it is stopping me from doing a refactor, and I doubt anyone is using it)
  • kivy-server and/or pythonar
  • I suspect an audit of the popularity of the widgets would reveal a few that could be pushed to kivy-garden.
  • plyer_demo

  Warning: If you say "Oh, that is really important!", I am going to say "Great. Then whip it into shape, please."

• Draft PEP 730 and Draft PEP 738 have dropped, proposing to make CPython "support" iOS and Android better. We shouldn't bet the "company" on them passing, but they are likely to have a big impact on Kivy for iOS and python-for-android if they become proper PEPs. Not only will they make things easier for our code, they will lower the cost of entry and encourage more competitors. What will be interesting is if they encourage major library providers to support Android/iOS wheels, hopefully reducing the need for recipes.

• Do we want to take inspiration from the Tiered list, and start supporting Kivy on all of the Tier 1 and Tier 2 platforms, and perhaps more of the Tier 3 platforms? (I think that largely means a bigger test matrix to run Kivy and Buildozer against.)

• The current advice Android developers are given is "Don't use emulators. It is just one more thing to go wrong." Bad answer. We need a short list of supported emulators for mobile platforms. Emulators that we test every release on.

• Recipes is an area I think needs a major rethink on a roadmap level:

  1. Recipes seem to be harder to write than they need to be. They are instances of a class with arbitrary field that need to be set.
     Recipes should be a subclass of BaseRecipe (or one of its subclasses). The constructor should take all the parameters required, with suitable defaults, so a developer is filling in the blanks rather than guessing the fields (and not noticing spelling errors).

  2. Recipes are super-fragile. They might depend on the build platform (which might be more than Linux and macOS), the destination architecture, the library version, the Python version, the p4a/kivy-ios version. That is almost an inevitable consequence of the recipe approach. However, there should be better matrix testing leading to better meta-information in a database, so we know at all times what combinations are known to work.

  3. Related to that, the current philosophy is "Drive-by developers chuck half-formed recipes into our backyard, and we leave them there, rusting, until they break. Then we add them to a secret "Yeah, they don't work, so stop testing them" list, and let them rot further. We need a better answer. (Did I just hear someone say "Let's have Tier 1, Tier 2 and Tier 3 recipes, and push the Tier 3 recipes into the Garden?" Oooh, that's an idea. Wish I thought of it. Integration tests for every single recipe we support? Of course!)

  4. I think I have suggested elsewhere that there should be a public list showing the top few hundred PyPI packages by download, and test results showing whether they build (automatic) and run (manual, or custom integration tests), and any additional meta information like restrictions on Python versions or library versions.

  5. Recipes should be named after the PyPI package they support. Exactly. No guessing.

• Take Coverage seriously, like oscpy does.

• Introduce black and isort.

[baseplate-admin]

Recipes is an area I think needs a major rethink on a roadmap level:

If the pep-730 and pep-738 is accepted, we might not even need recipes anymore

[Julian-O]

I assume we will continue to need them to account for (at a minimum) (a) packages that contain C code that isn't written in a way that runs on ios or Android, and (b) packages with custom installers that assume a particular platform. I don't think making CPython run natively on mobile will fix that, although it may encourage library developers to support ios/Android wheels, think about the issue or to treat bug reports with higher priority.

[baseplate-admin]

packages with custom installers that assume a particular platform. I don't think making CPython run natively on mobile will fix that, although it may encourage library developers to support ios/Android wheels, think about the issue or to treat bug reports with higher priority.

Correct. Then we can ask developers to ship arm/arm-64 wheels and use that instead of the linux version that kivy is currently using

[Julian-O]

@baseplate-admin: I think you and I are on the same page about the technical side. I think I am being a little more pessimistic about the priorities of other developers.

Right now, I think every recipe could be replaced by persuading the package maintainers to change their code, but there is an understanding that it isn't a priority for many package developers, so it is better for the Android App developers to accept the onus.

In the new world, it will be easier to explain what is wanted - change the package code until ios/Android wheels can be generated, but I think there may still be package developers not prioritising this work.

[Julian-O]

Why do we even need a roadmap anyway?

I think it serves three key roles:

• Reassuring the users that we hear their needs and are going to meet them soon: e.g. "We hear you want Support for Python 3.14 and for apps to run on the UberCloud, and we will support that in Kivy 4.3. No need to leave us for a competitor; it won't be long now."

• Co-ordinating API breakages with developers: e.g. "We are only going to have a major release in June 2024 and June 2025, so if you want to implement any fixes - even tiny ones - that involve API breakages, submit them by May 2024, or they won't be merged for a year."

• Co-ordinating changes that have broad impact on a lot of code: "We are removing Clock and moving to Trio in December 2025, so every single widget needs to stop using it. We need to clear our PR queue first, because the merge conflicts are going to be impossible."

Most issues don't need to be considered or mentioned by the roadmap. If someone cares enough to fix them before a release's code freeze, they will be merged into the next minor/major release. If no-one cares enough to fix them, they will be left behind.

Some issues may be severe enough that they deserve a mention: e.g. "We won't be releasing until this is fixed." and/or "Once this is fixed, it will trigger a release, to get it out as soon as possible." However, this is rare.

Which leaves us with the issues that need coordinating.

---

I just did a quick skim through Kivy, Buildozer, python-for-android and Kivy for iOS, looking for the issues that may meet those criteria. This is just one quick pass, I no doubt missed some items, I am no doubt biased towards the issues I care about, and it is probably wrong for many reasons, but I wanted to get the discussion started. I am NOT arguing that any of these are worthy, just that I suspect that, if we were to go ahead with them, we would need co-ordination.

• Support international languages kivy#8444
• Proposal for a Theme manager kivy#691
• longtap detection kivy#1587 and [Feature request] on_double_tap for Widgets like Label kivy#4630
• KEP001: Instantiate things other than widgets from kv kivy#2061
• Feature request: Separate order-fixed properties kivy#4717
• Allow SVG construction on canvas in KV file kivy#6102
• Plug and play support for input devices kivy#6140
• Revive discussion about bringing kivy to the web, technology favors it now. kivy#7898
• Inconsistent Rotation Handedness kivy#7920
• Adopt buildozer-action buildozer#1747
• Create PyPi Package compatibility chart buildozer#1744 and Feature Request: Need a list of python modules which can or cannot be used with buildozer to build apps buildozer#533
• Reduce/Eliminate need for Internet during build buildozer#1727
• [IDEA]: host a pip repo buildozer#1697
• To make android build through buildozer work in native Windows without WSL2/ VirtualBox etc buildozer#1651
• [Feature Requests] Change pyo to other format?  buildozer#1479
• [Feature Request] Rebuild options ? buildozer#1478
• [Feature] Buildozer AVD (Android Virtual Device) emulator support buildozer#702
• Services should support intent-filters python-for-android#2877
• [Request]: Skia-python python-for-android#2898
• To make android build through p4a work in native Windows without WSL2/ VirtualBox etc python-for-android#2872
• Feature request - better package management interfaze python-for-android#2427
• Discussion: introducing Black code formatter python-for-android#1950
• Change of backend PL kivy-ios#742

[Julian-O]

Let me dream for a second about a potential strand on the roadmap.

Step 1:

Imagine if the python-for-android project declared an officially supported Android emulator: AnBox, Genymotion, Android x86, NoxPlayer, LambdaTest, whatever.

The tests could be slowly updated - it wouldn't be enough for a feature to build. The resulting binary would need to run on emulated Android and work as expected.

Note: Tests would be slow because creating the environment and launching another OS would be slow. LambdaTest might be faster but would be less flexible in later steps.

Note: There may turn out to be some weird emulation issues, where something works on real Android devices but not the emulator. We would be need to be committed to producing suitable workarounds.

Advantages: Would increase python-for-android code quality - it would find bugs in existing code.

Step 2:

When enough tests (and work arounds) were in place, users could test their own apps on the emulator, improving the development time (and letting them try different Android versions without buying multiple hardware devices).

Advantages: The code quality of users' apps would improve.

Step 3:

From then on, it would not be enough to create a recipe without also creating tests that the package would actually run on Android. Each recipe would need to provide a test_smoketest.py that was a pytest that was run on Android to ensure the library had been loaded successfully, and could carry out basic functions.

Advantages: Code quality of recipes would improve.

Step 4:

With smoke-tests in place, it would be easier to go through the hardcoded version numbers for recipe libraries, update them to the latest and ensure they still pass their smoke test.

Advantages: Recipes wouldn't hold back users to use old libraries.

Step 5:

The recipe system could be refactored - recipes wouldn't need to be tied to one particular version. They could have a separate file: libraryversions.py that contains a list of PyPI versions that the recipe supported - with associated recommended Python, Android API and dependency versions.

Advantages: Recipes wouldn't force users to arbitrarily upgrade to new libraries (at the risk of dependency hell)

Step 6:

Automated test systems could run recipes against every single version on PyPI, and check whether the recipe passed the smoke-test. It could generate new libraryversions.py files and submit PR requests to update them.

Advantages: Recipes that didn't need work would automatically be marked up-to-date when new library versions were released. Recipes that did need work would automatically be marked as failing when new library versions were released.

Step 7:

Automated doc generation systems could examine all the libraryversions.py and generate reports of PyPI packages that are supported by python-for-android.

Similarly, reports of recipes that had stopped working and need attention.

Advantages: Users could start their projects confident that their favourite libraries were supported. python-for-android developers would know where to focus their attention.

[Julian-O]

I plan to share a document shortly that summarises the survey suggestions. I have tried to keep my personal opinions out of it. Here are the personal opinions I have been trying not to let interfere:

One-Stop Solution? Customisable infrastructure? Somewhere in between?

I think a lot of the suggestions we got can be classed as either:

• Kivy should have many of the widgets currently in KivYMD or Kivy Garden, or
• Kivy should support this esoteric widget that I need.

To me, this suggests "I should be able to find everything I need in the Kivy repository. It should be a one-stop shop."

I don't think that should be the approach. Kivy should be extensible, and we should encourage extensions. I think there is room to make extensions more discoverable, although clearly there have been attempts.

We could go the other direction, and say "Kivy is only the absolute fundamentals, and we should push anything we can out of the framework, to keep the code-based more agile and to avoid technical debt. You can't actually do anything with Kivy alone."

Somewhere in between is probably the sweet spot. You can find just enough widgets, behaviours, recipes, and the like to build say 25% of the most basic apps, but you will need to look elsewhere, or extend it yourself, to go further.

Targeting our documentation

There were many requests to improve documentation.

It is worth noting that documentation is one of those areas (like database reports for managers!) where there is always demand for more. We need to focus the efforts on where we can do the most good for with the resources we have.

A common theme was "Kivy is too hard for beginners." This is tricky. In order to use Kivy, you need to be on top of UI design, Python, Python packaging, concurrency, cross-platform development, the quirks of mobile platforms (where applicable). In order to contribute to Kivy, you need to be on top of Git branches, Pytesting, GitHub actions, etc. To what degree is it the job of Kivy's documentation to get new developers to understand all these other technologies? To what degree can we just say "You need to be this tall to ride. We expect you to understand these fundamentals before you read these documents." I want to be careful we don't spend our limited resources on explaining how Python works.

[I think there is overlap here between the one-stop shop for widgets above and the one-stop shop for all the information you need to get a Kivy app running.]

WYSIWYG Editor

There were many requests for an WYSIWYG IDE. @m1sl6 suggested that should be a separate project, and I concur.

I have developed IDEs before, and my experience suggests that what people are imagining an IDE might do, and the reality of what they can do, is going to have quite a chasm. This is not a statement that it shouldn't go ahead, just a warning that it isn't going to be smooth.

The biggest issue that I recommend be tackled early is: Where is the primary copy of the UI design being kept? If you are thinking that the IDE will be able to "round-trip" an existing Kivy app (with UI design stored in KV files (with embedded Python code), Python instances, third-party widgets, custom widgets) into a UI where you can edit it and regenerate the original code with modifications, you're dreaming.

If you are aiming for an IDE with a short fixed list of known widgets, layouts and behaviours, that can be used to generate a KV file and some basic infrastructure, but can't handle the Python file then being modified, I think it is feasible.

Existing Features

There were a number of features requested that already existed.

This might just be a naive user still on their Kivy learning journey.

This might be that Kivy has a discoverability issue - features can't be found by motivated users trying to learn about them.

This might be a user who understands exactly what is available, and is unhappy with it and wants more.

This might be a user who wants something else, but I have miscategorised their request.

My point is, when we see such a request, we shouldn't simply discard it as ignorant, but ask what we can do to make sure the existing feature meets peoples needs and they can learn about it.

[Julian-O]

Attached is a summary of the suggestions from the recent survey - I expect them to be very helpful in determining the roadmap going forward.

Categorized Survey Suggestions.pdf