How to set a default option for a Selection element

[sholt6]

I'm making a language learning app which uses a text-to-speech library to pronounce numbers in different languages.

I have the following list of dicts (abridged for brevity):

self.languages = [
  {"name" : "English (United Kingdom)", "lang" : "en", "accent" : "co.uk" },
  {"name" : "English (United States)", "lang" : "en", "accent" : "us" },
  {"name" : "French (France)", "lang" : "fr", "accent" : "fr" },
  {"name" : "Portuguese (Brazil)", "lang" : "pt", "accent" : "com.br" },
  {"name" : "Spanish (Spain)", "lang" : "es", "accent" : "es" },
]

This list is the content of a toga Selection element, as I learned to do from the Toga documentation:

self.language_dropdown = toga.Selection(items=self.languages, accessor="name")

I'm happy that this is properly configured because a function elsewhere in my code makes use of the currently selected language:

tts = gTTS(text=f"{self.number}", lang=f"{self.language_dropdown.value.lang}", tld=f"{self.language_dropdown.value.accent}")

That is to say, the dropdown is doing what I want it to, I have no problem there.
What I am struggling with is setting a default language for the dropdown to use (and later, to have this be user-configurable). I think this should be done using the value parameter, but no matter what I put here I get an error, e.g.:

self.language_dropdown = toga.Selection(items=self.languages, accessor="name", value="French (France)"
self.language_dropdown = toga.Selection(items=self.languages, accessor="name", value=self.languages[2])
self.language_dropdown = toga.Selection(items=self.languages, accessor="name", value="fr")

Whatever I put, I get a ValueError showing that whatever I put in the value attribute is being picked up, but saying it is not a current item in the selection, e.g:

ValueError: {'name': 'English (United Kingdom)', 'lang': 'en', 'accent': 'co.uk'} is not a current item in the selection

I'm a little frustrated to be stuck on something so basic, and would appreciate any advice on this!

[freakboy3742]

In this case, it's not your fault - this is an area of Toga's API that could definitely be improved.

The issue is that the value of value needs to be a Row object - the internal representation of each item of content in the data. The complication is that it's not easy to get a Row object in the constructor.

The best workaround right now is to construct the Selection in two parts. You can do this in one of two ways.

Firstly, you can construct the selection as you have here, then set the value afterward. By setting the data, that will construct the data source, and you can then find the row for the item you want:

self.language_dropdown = toga.Selection(items=self.languages, accessor="name")
self.language_dropdown.value = self.language_dropdown.items.find({"name": "French (France)"})

find() is essentially a search syntax for any data; so you could also ...find({"lang": "fr"}) (or any other value or combination of values that is convenient).

The other approach you can take is to explicitly create your data source, and then provide that to the Selection:

self.languages = toga.source.ListSource(accessors=["name"], data=[ 
  {"name" : "English (United Kingdom)", "lang" : "en", "accent" : "co.uk" },
  ...
])
self.language_dropdown = toga.Selection(
    items=self.languages, 
    accessor="name", 
    value=self.languages.find({"lang": "fr"}
)

I completely agree that neither of these approaches are especially intuitive. However, I think there would be a relatively straightforward fix/enhancement.

The setter for value currently does a find() if you don't specify an accessor (L160 of selection.py). This is only valid if the original data is a simple list of values, but it means you can use the data in the list as values; for all other cases, it uses the value as a Row. However, if we did a check to see if the value was anything other than a Row, and did a find() with the accessor, that would allow the usage that you tried (and, I agree is more intuitive). I've logged this request as #3986; if you'd like to try your hand at a contribution, it should be reasonably approachable.

[sholt6]

Great, thank you so much, the suggested solution works exactly as desired!

I'll definitely take a look at whether I can put together a contribution. I'm short on time this week but I've been having a lot of fun with Toga and it would be awesome to give back to it in some way.

[areslagae]

For what it's worth:

I typically end up wrapping selections as follows (see example below):

• introduce a business logic / domain object (in this case Language)
• as selection items store "pairs" of (label, object reference)
• wrap selection get/set objects to work with business logic / domain
  This makes working with selections easy, decouples ui code from business logic / domain code, and elegantly allows for an empty value as well.

I do realize and appreciate that Toga wants to make it easy to store data directly in the user interface components. But for larger and more complex applications I prefer to decouple user interface and business logic / domain. I do like the approach where you can store additional data in the selection, since it allows to do things like this. I also use such an approach with tables sometimes, where you can simply store an id or an object next to the text fields accessed by the accessors.

This does not solve the value in constructor issue above however, but I just to a set_value after creation.

from dataclasses import dataclass
import toga
from toga.style.pack import Pack

# --------------------------------------------------------------------------------
# business logic / domain specific

@dataclass
class Language:
    name: str
    lang: str
    acccent: str
    @staticmethod
    def as_selection_item(language):
        assert language is None or isinstance(language, Language)
        if language is not None:
            return {'label': language.name, 'language': language} 
        else:
            return {'label': '', 'language': None}

en_co_uk  = Language("English (United Kingdom)", "en", "co.uk")
en_us     = Language("English (United States)", "en",  "us")
fr_fr     = Language("French (France)", "fr", "fr")
pt_com_br = Language("Portuguese (Brazil)", "pt", "com.br")
es_es     = Language("Spanish (Spain)", "es", "es")

languages = [None, en_co_uk, en_us, fr_fr, pt_com_br, es_es]

# --------------------------------------------------------------------------------

class App(toga.App):

    def startup(self):
        self.main_window = toga.MainWindow(title=self.formal_name, size=(640, 480))
        language_selection_items = [Language.as_selection_item(language) for language in languages]
        self.language_selection = toga.Selection(style=toga.style.Pack(margin=8), items=language_selection_items, accessor='label', on_change=self.language_selection_on_change)
        self.language_selection_set_value(fr_fr)
        self.language_label = toga.Label(style=toga.style.Pack(margin=8), text='-')
        self.main_window.content = toga.Box(style=Pack(direction='column', align_items='center', justify_content='center'), children=[
            self.language_selection,
            self.language_label,
            toga.Button(style=toga.style.Pack(margin=8), text='set language to en_us', on_press=self.set_to_en_us_button_on_press),
            toga.Button(style=toga.style.Pack(margin=8), text='set language to None', on_press=self.set_to_none_button_on_press),
            toga.Button(style=toga.style.Pack(margin=8), text='set language to pt_com_br', on_press=self.set_to_pt_com_br_button_on_press),
        ])
        self.main_window.show()

    def language_selection_on_change(self, selection):
        language = self.language_selection_get_value()
        self.language_label.text = language if language is not None else 'None'

    def language_selection_get_value(self):
        return self.language_selection.value.language

    def language_selection_set_value(self, language):
        self.language_selection.value = self.language_selection.items.find(Language.as_selection_item(language))
 
    def set_to_en_us_button_on_press(self, button):
        self.language_selection_set_value(en_us)

    def set_to_none_button_on_press(self, button):
        self.language_selection_set_value(None)

    def set_to_pt_com_br_button_on_press(self, button):
        self.language_selection_set_value(pt_com_br)

if __name__ == "__main__":
    app = App("App", "org.beeware")
    app.main_loop()

# --------------------------------------------------------------------------------

[freakboy3742]

I do realize and appreciate that Toga wants to make it easy to store data directly in the user interface components.

To be clear - that's the exact opposite of what Toga is trying to do, especially on the Selection, Table and Tree widgets.

What you've described here is exactly what the Source API is designed to manage - providing a way to define a Source of data that is completely independent of the widget, so that the widget becomes a "view" of the data, rather than an encapsulation of both data and visualisation.

The TableSource and TreeSource examples show two examples of this in practice.

TreeSource defines a data source that is a reflection of the filesystem. When the tree tries to display, it asks the filesystem for what nodes and children exist, rather than maintaining a parallel representation of the file system.

TableSource is an example of a single data source being visualised on two widgets. There's 2 data sources; but the second one is a filtered version of the first one; so there's only one "true" source of data.

Toga does let you store data directly in the user interface components - but that's entirely a convenience to make the simple case trivial. Behind the scenes, when you provide a Python list of tuples to be displayed, that list is converted into a ListSource, and all the operations on the data are performed on the ListSource, not the original values provided as data. If you're doing anything even remotely complicated, defining and using a DataSource should be your preferred approach.

Two related notes on this:

1. The fact that this wasn't obvious clearly indicates a gap in our documentation. We have a topic guide for sources; but the Tree and Table docs don't really mention Sources except in passing.
2. This separation of widget and data currently only true for Table, DetailedList and Selection using ListSource and Tree using TreeSource. ValueSource is defined, but isn't currently used anywhere. Ideally every value of every widget would be backed by a source, and it would be possible to provide an external Source representation. That's a known gap that we'd like to address.

[areslagae]

Very interesting discussion ....

With "directly in the user interface components" I actually meant "in the Toga layer of the application". I am looking from the application perspective of course and I still consider the Source API as Toga. I probably do not understand the Source API correctly, but I (maybe wrongfully) did not give it too much attention since I do not want to couple my model/domain/business logic layer tightly with my user interface/presentation layer. I do not know if the Source API allows that.

The application I am working on follows a library <> apps (ui, command line, ...) approach and I need a fallback for Toga (tkinter, which I hope I will not need). In my example above, it means that Language is a model/domain/business logic object that lives in the library (anyway) and also needs to work with a tkinter or command line app. The example is a bit misleading because it is so simple, but Language could also be a ResultSet class with 1M complex records that requires pagination to display. So maybe I should look into building a custom ListSource that bridges between my library / ResultSet on the one side and Toga on the other side. But I have not looked into that yet. One reason is that my datasets are too large for a Toga table to efficiently display. To be completely honest, I also did not want to spend the time to reverse-engineer ListSource from the source code (because docs are not great, which given the < 1.0 state of the project is of course fully acceptable) to come to the conclusion it would not support my use case. Especially if a custom layer on top would also easily support tkinter. But again, our perspectives of course differ.

What I guess I meant to say is that the Source API is great, but for larger / more complex applications you will probably have to build a layer on top or extend it anyway? It would be great of course if both use cases are supported well. But again, I might not be understanding the Source API correctly. I will happily look into it in the future if you think it can support a use case like mine (lazy loading, pagination, lazily converting rows to display values, custom filtering and sorting). It would make life easier in fact, except if it turns out that I will not be able to use Toga in the end, which was in fact a second reason for not diving into it, since my current code should be easily portable to tkinter.

[freakboy3742]

We might not have the implementation 100% correct (in fact, from a quick look I'm almost certain of that), but the setup you've described is absolutely the intention of the Source API. Source isn't (or shouldn't be) a base class that you have to subclass. It's a Protocol to which any source of data could conform. For the most part, it's an extension of Sequence/Iterator type protocols, with the addition of some explicit listener mechanisms. Whether that data is paginated, stored locally, or retrieved via API call is entirely up to the implementation.

The intention of the design is that it should be entirely possible to implement the Protocol without ever using Toga code explicitly. Subclassing might make an implementation a little easier, but it shouldn't be required.

The place I'm aware the design falls down at present is that Table/Tree etc do use isinstance() checks against the actual Source class; that's primarily because the implementation predates the introduction of features like structural typing via @runtime_checkable. That is something I'd like to correct. It's logged as #3760; although that's described as a documentation task, looking at the code there's likely also some changes required to use full structural subtyping.

[sholt6]

Thanks for the continued discussion, I think I'm starting to get a sense of what I need to do here.
Indeed I haven't seen the Data Sources documentation up to now, much less the ListSource page which seems to be what I should be using here.

I have two questions if I may impose further:

1. The Data Sources page says "Although Toga provides these built-in data sources, in general, you shouldn't use them directly. " Would it be fair to say that my use case here is still simple enough to get away with using the built in?
   In any case, is there a super simple example of a custom Data Source usage you're aware of which I could refer to?

2. Regardless of how I do this, would you tend to recommend moving away from hardcoding my language dictionary and having it stored in something else? Would this be a CSV file?
   What about coding the LanguageSource custom data source, importing this to app.py and having the languages hardcoded in there? Again, an example to refer to would be much appreciated if there is anything applicable!

[freakboy3742]

If you don't have any special needs beyond "a list of data, each entry of which is a row", then I'll doubt you'll get much out of re-implementing

The best example of a custom data source that I can think of is the TreeSource example - that is an example of a source that is populated on demand from filesystem operations.

As for whether you should move away from hard-coding - that depends on the use case itself. However, it sounds like your use case has a relatively static use case has a relatively static list of language entries. On that basis, I don't think you need to worry too much about finding an alternate representation. For that use case, other than the original "how to select a row" issue that started this conversation, you're not really gaining any additional capabilities beyond what passing in a "list of dictionaries" gave you. The real value for a custom Source is when there's an alternate backing representation - such as the file system, or a HTTP API - and the Source API provides a way to hide the complexity of that data storage mechanism from the display of that data.