What is the goal number and "depth" of Widgets?

[adammj]

I searched for project goals, but couldn't find these particular details.

The goals are related, but I'm curious 1) if there is a goal for the diversity of "General Widgets", and 2) for the current Widgets, at least, is there a desire to flesh them out more--or does the filled black circle represent that it's "done"?

I'll give an example that I'm more familiar with and curious about. I believe the MultilineTextInput is equivalant to QTextEdit (in Qt) and Text (in Tk). Both of those toolboxes not only have vastly more features than just plain text editing, but both come with completely different "document" models. I like that Toga is still pre-1.0, so I'm kinda curious if the MultilineTextInput is going to get a cumbersome/rediculous document model added to it (which has caused me no ends of headaches in Qt/Tk translations) of if it'll be the API consumers that each define their own model and all of the other additional features (fonts, spacing, etc.)?

This question obviously applies for other Widgets, but I needed a concrete example.

[freakboy3742]

Good question - and apologies that Toga's docs don't answer it for you. We've been intending to update our roadmap for a while, and haven't gotten to it yet.

In the long term, the goal would be for Toga to have a widget for every need - but that doesn't mean that all the widgets need to be in Toga's core. You can already see the initial manifestations of this strategy - toga-chart, for example, is an official Toga widget; but it is maintained as a standalone repository.

In terms of the specific widgets that are in core, I would say we're getting fairly close to the final set. There's still a couple of obvious widgets missing - RadioButton, VideoView and maybe Map (although that might end up as an external widget) are the ones that jump to mind; plus a couple of navigation widgets (in particular, multi-page, and list/detail navigation), and some "meta" level features (like a Settings/preferences API, and improved support for app-level login). However, Toga's core is not going to grow to encompass all possible things. We intend to leverage Python's excellent packaging infrastructure to allow the core to remain small and well constrained, while allowing the full officially maintained feature set to grow.

The black circle on the widget state chart isn't really an indicator of "final feature completeness" - it's more of an indicator that what is there is fully tested. However, it's also an indication that it is probably close to feature complete - say, at least 80%, possibly more. It's also an indicator that the "shape" of the API is close to it's final form - so it's unlikely to have any radical backwards incompatible changes (unlikely, but not impossible, until we hit 1.0).

Taking MultilineTextInput as an example - I don't have any difficulty imagining that it might gain some additional features - but it definitely isn't going to turn into an "all singing, all dancing text editing widget". I definitely don't envisage a full "Document model" - at best, it might switch to allowing the use of a ValueSource (the single value equivalent of the TableSource and TreeSource that is used on Table and Tree, respectively). However, that's more about providing a way to separate the widget's value from its rendering, not about providing a rich content model. I wouldn't, for example, expect to see support for setting the font on part of a block of text in a MultilineTextInput. It's a widget for displaying multiple lines of text with the same font, not a rich editing widget.

That said, I would like to see a standalone CodeEditor widget at some point - something that provides syntax highlighting, line numbering, syntactic block collapse, and so on. I'd also like to see a RichTextEditor widget as a standalone, to cover the "writing a formatted block of text" use case. However, in both cases, those would be standalone widgets like toga-chart, not something built into Toga's core, with APIs focused on specific functions (displaying/editing code, or editing Markdown/ReST), rather than building abstract document models.

I hope that provides some guidance on our thinking; if you'd like any other clarifications, let me know.

[adammj]

Thank you—that's a very thorough reply! (which is also why I wanted to ask here, so there were some insights for others) And I think those sound like well-reasoned positions to keep the core tight, while also providing the "stand alone" widgets that others would probably want as well.

Now I'll have to give some thought to how I could contribute, as I think this project really reasonates with my own interests.

[freakboy3742]

If you're keen to contribute, I'm sure we can find some way to keep you busy :-) There's plenty of work be done; and depending on the platforms you use (or have access to), your interests, and your level of experience, we have a range of possible tasks. If you join our Discord, we can help guide to towards a project that might be of interest.